Post on 28-Dec-2015
© Anthony J H Simons, 2008
Ship image © Heritage Discovery Center
SoftwareEngineering
From Bespoke Systems to Reusable Components
© Anthony J H Simons, 2008 2
The Business ClimateThen in the 1960s and 70s:
automate existing pen-and-paper solutions
update and rationalise older software systems
provide bespoke software at any price
Now in the 21st Century:achieve faster, cheaper turnaround to delivery
allow reuse, extension of old solutions
promote a component-based software industry
Analogiesbespoke tailors vs. off-the-shelf mix-and-match
cottage crafts vs. mass production
© Anthony J H Simons, 2008 3
Programming in the 1970sLatest idea: block structure
Dijkstra: “Goto considered harmful”
block-structured languages Pascal, C
have single entry and exit points
Everything is a blockmain program
subroutine – procedure, function
control – if, case, while loops
idea of block scope – local variables
© Anthony J H Simons, 2008 4
Pascal Example
procedure countChars(infile : text; var count : integer)var
ch : char;begin
count := 0;reset(infile);read(infile, ch);while not eof(infile) dobegin
count := count + 1;read(infile, ch);
endend;
© Anthony J H Simons, 2008 5
Design in the 1970s
Latest idea: structure chartsdiagrams – boxes represent blocks
Jackson’s JSP; deMarco’s method
simple, hierarchical, nested diagrams
Design based on functionsvariables attached to procedures
procedures are the “active part”
data is the “passive part”
data passed to and from procedures
© Anthony J H Simons, 2008 6
JSP Design Example
file
line *
text term
tchar *
while not eof
while not term
eof o eol o
count++
a file is made up of…
many lines, made of…
some text, followed by a terminator
which is either end-of-file, or end-of-line
© Anthony J H Simons, 2008 7
Structured Methods
Why was it this way?emphasising the program notion of block
led to notion of functional design, which
led to notion of process and dataflow analysis
Conceptual biasprocess analysis and design: first priority
data analysis and design: second priority
separation of concerns
© Anthony J H Simons, 2008 8
Strengths of the Method
Strategy for development:decompose system around functions
what processes? then, what data?
top-down design and step-wise refinementmain program, subroutines, procedures
easy to break down levels of abstraction
turn-the-handle approach – know when finished
products based on analysing one systemdesign is a close fit to the requirements
so long as they don’t change!
© Anthony J H Simons, 2008 9
Vulnerability to ChangeMajor partitions of design are volatile:
major partitions are the procedures
procedures are fragile (break, change)main function must change if requirements change
functional decomposition may change if main function changes (new viewpoints, insights)
every procedure must change if a new datum must be supplied (passing in arguments)
Can structured designs be reused?See following JSP examples
© Anthony J H Simons, 2008 10
JSP: Count Characters
file
char *
while not eof
count++
a file is made up of…
multiple characters
Very simple model of the data; so very simple procedural breakdown.
Can this be extended in a straightforward way to count words, or count lines?
© Anthony J H Simons, 2008 11
JSP: Count Words
file
char *
while not eof
count++
file
word *
text space
tchar * schar *
while not eof
while not schar while schar
count++
a file is made up of…
multiple words
More complex model of the data; procedural breakdown requires insertion of new subroutines.
© Anthony J H Simons, 2008 12
JSP: Count Lines
file
word *
text space
tchar * schar *
while not eof
while not schar while schar
count++
file
line *
text term
tchar *
while not eof
while not term
eof o eol o
count++
Fundamentally different view of the data; leads to a different program structure with different functional decomposition
© Anthony J H Simons, 2008 13
Fragility: the Inquest
Why are functional designs fragile?breakdown of procedures closely follows the shape of the data (JSP principle)
the ideal data structure changes depending on what processing is to be done
so altering the task will radically alter the data structures and break the procedures
designs based on one system do not generalise
© Anthony J H Simons, 2008 14
Programming in the 1990s
Latest idea: encapsulationGoldberg: “Object-oriented programming”
OO languages Simula, Smalltalk, Flavors, CLOS, C++, Objective C, Delphi, Eiffel, Java, C#
hidden state variables, public interfaces
Everything is an objectapplication, subsystem, component, datatype
metaphors – window, stream, menu, …
generality – classes, interfaces, polymorphism
scalability – inheritance, composition
© Anthony J H Simons, 2008 15
Java Exampleclass Word extends TextUnit {
private StringBuffer text;
public Word() { text = new StringBuffer(); } public void readFrom(MyFileReader mfr) { char ch = mfr.next(); while (ch != space && ch != eol && ch != eof) { text.append(ch); ch = mfr.read(); } }…}
© Anthony J H Simons, 2008 16
Design in the 1990s
Latest idea: Unified Modelling Languageboxes represent classes, objects
arrows represent associations, dependency
sequence diagrams – message interactions
Design based on objectsmethods attached to the classes
objects “active”, combine data and functions
notion of distributed control, collaboration
system an interaction of components
© Anthony J H Simons, 2008 17
UML Class Diagram
ClosedShape
area() : intmove(int, int)
Rectangle
width, height : int
CircleSquare
Point
move(int, int)
x, y : int
Movable
move(int, int)
area() : int
radius : intside : int
area() : intarea() : int
origin
1 0..1
abstract
generalisation
aggregation
© Anthony J H Simons, 2008 18
Object-Oriented Methods
Why is it this way?emphasising the program notion of object
led to UML class and object designsfocus on software components, characteristic behaviours
led to agile development techniquessoftware reuse, bottom-up assembly
libraries of ready-made components
conceptual analysis of problem as objectsseamless transition: analysis design program
but – is it natural to think of all problems as objects?
© Anthony J H Simons, 2008 19
Strengths of the Method
Strategy for development:decompose system around objects
what objects? and how do they collaborate?
mixture of bottom-up and top-down designwhy bottom-up? “Real systems have no top” - Meyer
assemble system from ready-made components
top-down architecting – with Design Patterns
not systematic, based on intuition, experience
products based on the analysis of 3+ systemsdesign is robust and general – Frameworks
more amenable to extension, adaptation
© Anthony J H Simons, 2008 20
Resilience to ChangeMajor partitions of design are stable:
major partitions are the objects
objects are stable (don’t change)basic payroll system has employees, timesheets
Mgt. Info. Sys. still has employees, timesheets
if the main function changes, the objects stay the same (but they may interact in different ways)
Can object-oriented designs be reused?UML design based on 3+ systems:
design program to count characters in a file
generalise initial design to count words in a file
generalise initial design to count lines in a file
© Anthony J H Simons, 2008 21
UML: High-Level Design
WordChar Line
TextUnit
read()
read() read() read()
Counter
count()
1 *
counting characters, words, lines…
…generalise as counting TextUnits
© Anthony J H Simons, 2008 22
UML: Low-Level Reuse
WordChar Line
Tchar Schar
Text
Space
read() read() read()
Term
Words
*
* 1 1
1*
words made up of characters lines made up of words
© Anthony J H Simons, 2008 23
Framework: Count TextUnits
WordChar Line
TextUnit
read()
Tchar Schar
Text
Space
read() read() read()
Term
Words
*
* 1 1
Counter
count()
1 *
1*
© Anthony J H Simons, 2008 24
Reuse: the Inquest
Why are object-oriented designs reusable?objects are modelled independently of any one particular system in which they are used
easier to identify all object behaviours, anticipate functions used in other systems
designs based on many systems are likely to lead to a more flexible control framework
What is the cost of object-oriented reuse?more advance planning required
suboptimal algorithms with composed systems
mix-and-match isn’t always a perfect fit
© Anthony J H Simons, 2008
Ship image © Heritage Discovery Center
Any questions?
© Anthony J H Simons, 2008 26
Reuse of SoftwareComponents
plug and play – object substitutabilityenabled through interfaces, polymorphism
granularity of objects – suitable sizebetter than text, function or library reuse
COM/Java Beans – dynamic configurationenabled through introspection, visual wiring tools
Frameworks (and Toolkits)flexible shells for a family of applications
large scale – big coding investment
domain-dependent – for niche software market
language-specific – in Java, C++, Smalltalk, Eiffel…
© Anthony J H Simons, 2008 27
Reuse of Designs
Design PatternsGamma, Helm, Johnson, Vlissides
idea of architect’s plans, the ideal arch, or bridge
distil the best design elements from many systems
23 common design solutions (+/-)medium-scale – local collaborations of classes
domain-independent – not tied to any application
language-neutral – code into any OOL
Coding Idiomsgood coding style guidelines
language-specific
recommended reading
© Anthony J H Simons, 2008 28
Migrating to Object Technology
Level 1: programming flexibilityuseful to have inheritance, polymorphism
eg: CAD systems, GUIs, MS-Windows, ...
Level 2: design encapsulationbetter factorisation of designs, if O-O approach adopted for all in-house software
promotes reuse of components, frameworks
Level 3: process institutionalisationestablish new developer roles: application scavenger, librarian, reuse manager
purchase and sales of software components
reward mechanisms based around reuse