Transcript object

Software
Engineering
From Bespoke Systems to
Reusable Components
Ship image © Heritage Discovery Center
© Anthony J H Simons, 2008
The Business Climate
Then 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
Analogies
bespoke tailors vs. off-the-shelf mix-and-match
cottage crafts vs. mass production
© Anthony J H Simons, 2008
2
Programming in the 1970s
Latest idea: block structure
Dijkstra: “Goto considered harmful”
block-structured languages Pascal, C
have single entry and exit points
Everything is a block
main program
subroutine – procedure, function
control – if, case, while loops
idea of block scope – local variables
© Anthony J H Simons, 2008
3
Pascal Example
procedure countChars(infile : text; var count : integer)
var
ch : char;
begin
count := 0;
reset(infile);
read(infile, ch);
while not eof(infile) do
begin
count := count + 1;
read(infile, ch);
end
end;
© Anthony J H Simons, 2008
4
Design in the 1970s
Latest idea: structure charts
diagrams – boxes represent blocks
Jackson’s JSP; deMarco’s method
simple, hierarchical, nested diagrams
Design based on functions
variables attached to procedures
procedures are the “active part”
data is the “passive part”
data passed to and from procedures
© Anthony J H Simons, 2008
5
JSP Design Example
a file is made up of…
file
many lines, made of…
while not eof
line *
text
count++
some text, followed by
a terminator
term
which is either end-offile, or end-of-line
while not term
tchar *
eof o
eol o
© Anthony J H Simons, 2008
6
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 bias
process analysis and design: first priority
data analysis and design: second priority
separation of concerns
© Anthony J H Simons, 2008
7
Strengths of the Method
Strategy for development:
decompose system around functions
what processes? then, what data?
top-down design and step-wise refinement
main program, subroutines, procedures
easy to break down levels of abstraction
turn-the-handle approach – know when finished
products based on analysing one system
design is a close fit to the requirements
so long as they don’t change!
© Anthony J H Simons, 2008
8
Vulnerability to Change
Major 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
9
JSP: Count Characters
a file is made up of…
file
while not eof
multiple characters
char *
count++
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
10
JSP: Count Words
file
while not eof
a file is made up of…
file
while not eof
char *
word *
count++
multiple words
count++
text
while not schar
tchar *
space
while schar
More complex model of the
data; procedural breakdown
requires insertion of new
subroutines.
schar *
© Anthony J H Simons, 2008
11
JSP: Count Lines
file
file
while not eof
word *
count++
text
Fundamentally different
view of the data; leads
while not eof
to a different program
structure with different
line *
functional decomposition
count++
space
while not schar while schar
tchar *
schar *
text
term
while not term
tchar *
© Anthony J H Simons, 2008
eof o
eol o
12
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
13
Programming in the 1990s
Latest idea: encapsulation
Goldberg: “Object-oriented programming”
OO languages Simula, Smalltalk, Flavors, CLOS, C++,
Objective C, Delphi, Eiffel, Java, C#
hidden state variables, public interfaces
Everything is an object
application, subsystem, component, datatype
metaphors – window, stream, menu, …
generality – classes, interfaces, polymorphism
scalability – inheritance, composition
© Anthony J H Simons, 2008
14
Java Example
class 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
15
Design in the 1990s
Latest idea: Unified Modelling Language
boxes represent classes, objects
arrows represent associations, dependency
sequence diagrams – message interactions
Design based on objects
methods 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
16
UML Class Diagram
abstract
Movable
generalisation
move(int, int)
Point
x, y : int
move(int, int)
ClosedShape
origin
1
area() : int
move(int, int)
0..1
aggregation
Square
Circle
Rectangle
side : int
radius : int
width, height : int
area() : int
area() : int
area() : int
© Anthony J H Simons, 2008
17
Object-Oriented Methods
Why is it this way?
emphasising the program notion of object
led to UML class and object designs
focus on software components, characteristic behaviours
led to agile development techniques
software reuse, bottom-up assembly
libraries of ready-made components
conceptual analysis of problem as objects
seamless transition: analysis  design  program
but – is it natural to think of all problems as objects?
© Anthony J H Simons, 2008
18
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 design
why 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+ systems
design is robust and general – Frameworks
more amenable to extension, adaptation
© Anthony J H Simons, 2008
19
Resilience to Change
Major 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
20
UML: High-Level Design
Counter
1
*
count()
TextUnit
…generalise as
counting TextUnits
read()
Char
Word
Line
read()
read()
read()
counting characters,
words, lines…
© Anthony J H Simons, 2008
21
UML: Low-Level Reuse
words made up of
characters
lines made up of words
Char
Word
read()
read()
Tchar
Schar
*
1
Line
*
Space
read()
1
Words
*
1
Text
© Anthony J H Simons, 2008
Term
22
Framework: Count TextUnits
Counter 1
*
count()
TextUnit
read()
Char
Word
read()
read()
Tchar
Schar
*
1
Line
*
Space
read()
1
Words
*
1
Text
© Anthony J H Simons, 2008
Term
23
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
24
Any questions?
Ship image © Heritage Discovery Center
© Anthony J H Simons, 2008
Reuse of Software
Components
plug and play – object substitutability
enabled through interfaces, polymorphism
granularity of objects – suitable size
better than text, function or library reuse
COM/Java Beans – dynamic configuration
enabled 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
26
Reuse of Designs
recommended
reading
Design Patterns
Gamma, 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 Idioms
good coding style guidelines
language-specific
© Anthony J H Simons, 2008
27
Migrating to Object Technology
Level 1: programming flexibility
useful to have inheritance, polymorphism
eg: CAD systems, GUIs, MS-Windows, ...
Level 2: design encapsulation
better factorisation of designs, if O-O approach adopted for
all in-house software
promotes reuse of components, frameworks
Level 3: process institutionalisation
establish new developer roles: application scavenger,
librarian, reuse manager
purchase and sales of software components
reward mechanisms based around reuse
© Anthony J H Simons, 2008
28