Transcript Lecture 16: OOP Design

CS2200 Software Development
Software Design
A. O’Riordan, 2008
C200
Design
Design is the process of originating and developing a plan for an
artistic or functional object, which may require countless hours of
thought, modeling, iterative adjustment, and re-design.
Engineering is often viewed as a more rigorous form of design than
is practiced the arts and crafts.
Some designs are viewed as classic
● [1916] Coca-Cola glass bottle by Root Glass Company
● [1935] Volkswagen Car by Erwin Komenda
● [1984] Apple Macintosh by Apple Computer by Raskin, Atkinson and
Smith and others
Software examples:
● [1979] Model-View-Controller Design Pattern by Reenskaug, Xerox
● [1998] Google Search Page by Larry Page and Sergey Brin
C200
Software Design
● Software designers need knowledge of computer science and basic
engineering design principles.
● Software design encompasses high level specification through to
programming.
● Definition of Software Design: The process of defining the architecture,
components, interfaces, and other characteristics of a system or
component. [IEEE spec. 610.12, 1990]
● In analysis it is possible to produce the correct model of an existing
system. However there is no such thing as a correct design.
● A design should be acceptable to users and easy to implement.
C200
Design Objectives
The design process involves the search for a good design given a set of
objectives that are reasonably static (no sudden changes).
Evolutionary Design: Objectives "evolve" over time.
Design Objectives [Hawryszkiewycz†]
● Functional objectives – new services, security, etc.
● Process improvements – access to data, input/output
● Operational objectives – performance
● Personal & job satisfaction needs – user interface, ergonomics
†Hawryszkiewycz, I. Introduction to Systems Analysis and Design, 5th ed. Prentice-Hall,
2000.
C200
What designers do?
Designers … †
● use abstract "mental models" to simulate the dynamic behaviour of the
eventual system;
● make constraints affecting design explicit when handling an unfamiliar
problem;
● reuse previous design plans - design patterns;
● make notes about future intention of system - aide to expansion of
design.
†Adelson, B. and E. Soloway. The Role of Domain Experience in
Software Design. IEEE Trans. on Software Engineering, V SE-11, N 11, 1985, pp. 1351-1360.
C200
Constraints on Design I
In practice, there are few opportunities to design a system with a free hand.
Design takes place in a context. Examples of constraints:
● operation environment - Linux, Windows, multiplatform, Web
● file structures - storage requirements
● programming language(s) – general purpose, scripting, specialized
● "look and feel" of user interface – Swing, Windows, OS X
● choice of using a single process or several with interprocess
communication; multithreaded
● single machine or distributed application
C200
Constraints on Design II
● choice of software architecture - e.g. client/server or centralised
● standards conformance - ISO, W3C, IETF
● performance and timing criteria – important for real-time systems
● extensibility – future upgrades
● release date
● security and privacy – if data is sensitive or financial tracnsactions
C200
Elements of Software Design
Dijkstra wrote about disentangling intrinsic intricacy from accidental
intricacy. He proposed that the central challenge of computing was “how
not to make a mess” †.
†Dijkstra, E. The next fifty years. EWD1243, http://www.cs.utexas.edu/users/EWD/
● Data Abstraction/Encapsulation
● Modularity and Procedural Abstraction
● Assessing Design: Cohesion and Coupling
We will examine each in turn
C200
Data Abstraction
● Data Abstraction – separate the details of how an object is used from
the primitive data that represent it
● Programs should be designed around an abstract interface
● Don’t assume anything about the details of the data that is not
required to perform the task
● Concrete implementations of the data can then be provided separately,
and can be changed without affecting the rest of the program, i.e. the
interface
C200
Encapsulation
● Encapsulation: hiding implementation details behind a public interface
● In Java there is public, private and protected visibility
● A class is the interface plus the implementation
● interface: the signatures of public methods (and public data)
● implementation: the method bodies, private data (and private
methods)
● May require setters and getters - although we now have the overhead
of extra method invocations, the overhead is small
● Java Bean is a class where field xyz of type T has getter and setter T
getXyz() and setXyz(T t) respectively
C200
Modularity
Modularity - organisation of a program into small independent units called
modules
A module is implemented as a sequence of programming instructions
bounded by an entry point and an exit point, or multiple exit points.
Goals
● decompose program into independent pieces
● divide complex problem into smaller problems
● test part of program independently of it's use as a unit larger system
“We propose … that one begins with a list of difficult design decisions or
design decisions which are likely to change. Each module is then
designed to hide such a decision from the others” [Parnas†]
†On the Criteria to Be Used in Decomposing Systems into Modules.
Communications of the ACM, 15(12), 1972
C200
Procedure Abstraction
● Procedural Abstraction: the organisation of a program into methods
● Factoring: identify recurring segments of code and capture them once
in a single method
● Top-down decomposition or "stepwise refinement" †). : design a
complex method by breaking it up into smaller chunks
● This approach to software design probably originated at IBM.
● Bottom-up composition: write some simple methods and then use
them to design more complex ones
● end product is built by integration
† Wirth N. "Program Development by Stepwise Refinement,"
Communications of the ACM, Vol. 14, No. 4, April 1971.
C200
Assessing Design: Cohesion
● The software quality metrics of coupling and cohesion were invented
by Larry Constantine and others at IBM†.
● Cohesion: the degree to which the computation in a method is directed
towards a single purpose
● High cohesion is desirable
● write separate methods for separate purposes
● convoluted method names are a sign of low cohesion
● Yourdon suggests that an effective way of doing an assessment of
module cohesion is to try to describe the module's function in a single
sentence. If the module is cohesive it should be possible.
†Wayne P. Stevens, Glenford J. Myers, Larry L. Constantine. Structured Design.
IBM Systems Journal 13(2): 115-139 (1974)
C200
Assessing Design: Coupling
● Coupling: the degree to which methods rely on each other
● When there is little interaction between methods, methods are
described as loosely coupled; when there is a great deal of interaction,
they are said to be tightly coupled.
● Low (or loose or weak) coupling is desirable
● Three factors affect the coupling between methods
● Data items passed between methods
● Control data passed between methods
● Global data passed between methods
● Operates are multiple levels of granularity – method, class and
package
C200
Prototyping
Prototyping a design in engineering
● a first of it’s kind
● model produced to scale
● simulation
Prototyping is popular at the moment:
● Iterative lifecycle models
● agile processes
● RAD (Rapid Application Development) method
● interpreted languages, e.g. Java bytecode
● scripting languages (e.g. Javascript, PHP).
C200
Role of Prototyping
Categorised according to the roles they play in the software lifecycle:
Exploratory
● helps evaluate the feasibility of different design alternatives
● may also be used to clarify user requirements
● thrown away
Evolutionary
● form of prototyping closest to actual development
● software is adapted gradually, changing requirements as you go
● prototype may actually become the final released product.
Experimental
● used to evaluate possible solutions to a problem
● developed in advance of large-scale implementation
● may be used for assessment of performance
C200
Benefits of good design
● Greater readability - individual methods may be shorter; the
contribution of a method should be obvious from its signature
● Greater maintainabiltiy - reduced repetition means fewer inconsistent
changes
● Greater testability - smaller independently testable and debuggable
pieces
● Greater reusability - each smaller class/method does some single welldefined task that may be needed in other parts of the project
● Possibly greater performance - it may be easier to find bottlenecks in
the code and remedy them
C200