ian sommerville 1995 software designslide 1 software design u deriving a solution which satisfies...
DESCRIPTION
©Ian Sommerville 1995 Software DesignSlide 3 Design u Good design is the key to effective engineering u It is not possible to fomalize the design process in any engineering discipline. u A creative process requiring insight and flair u Any design problem must be tackled in three stages: Study and understand the problem Identify gross features of at least one possible solution Describe earch abstraction used in the solutionTRANSCRIPT
![Page 1: Ian Sommerville 1995 Software DesignSlide 1 Software Design u Deriving a solution which satisfies software requirements](https://reader035.vdocuments.mx/reader035/viewer/2022062413/5a4d1b727f8b9ab0599b5fa3/html5/thumbnails/1.jpg)
©Ian Sommerville 1995 Software Design Slide 1
Software Design
Deriving a solution which satisfies software requirements
![Page 2: Ian Sommerville 1995 Software DesignSlide 1 Software Design u Deriving a solution which satisfies software requirements](https://reader035.vdocuments.mx/reader035/viewer/2022062413/5a4d1b727f8b9ab0599b5fa3/html5/thumbnails/2.jpg)
©Ian Sommerville 1995 Software Design Slide 2
Topics covered The design process and design methods Design strategies including object-oriented design
and functional decomposition - briefly Design quality attributes
![Page 3: Ian Sommerville 1995 Software DesignSlide 1 Software Design u Deriving a solution which satisfies software requirements](https://reader035.vdocuments.mx/reader035/viewer/2022062413/5a4d1b727f8b9ab0599b5fa3/html5/thumbnails/3.jpg)
©Ian Sommerville 1995 Software Design Slide 3
Design Good design is the key to effective engineering It is not possible to fomalize the design process in
any engineering discipline. A creative process requiring insight and flair Any design problem must be tackled in three stages:
• Study and understand the problem• Identify gross features of at least one possible solution• Describe earch abstraction used in the solution
![Page 4: Ian Sommerville 1995 Software DesignSlide 1 Software Design u Deriving a solution which satisfies software requirements](https://reader035.vdocuments.mx/reader035/viewer/2022062413/5a4d1b727f8b9ab0599b5fa3/html5/thumbnails/4.jpg)
©Ian Sommerville 1995 Software Design Slide 4
The design process Any design may be modelled as a directed
graph made up of entities with attributes which participate in relationships
The system should be described at several different levels of abstraction
Design takes place in overlapping stages. It is artificial to separate it into distinct phases but some separation is usually necessary
![Page 5: Ian Sommerville 1995 Software DesignSlide 1 Software Design u Deriving a solution which satisfies software requirements](https://reader035.vdocuments.mx/reader035/viewer/2022062413/5a4d1b727f8b9ab0599b5fa3/html5/thumbnails/5.jpg)
©Ian Sommerville 1995 Software Design Slide 5
From informal to formal design
Informaldesignoutline
Informaldesign
Moreformaldesign
Finisheddesign
![Page 6: Ian Sommerville 1995 Software DesignSlide 1 Software Design u Deriving a solution which satisfies software requirements](https://reader035.vdocuments.mx/reader035/viewer/2022062413/5a4d1b727f8b9ab0599b5fa3/html5/thumbnails/6.jpg)
©Ian Sommerville 1995 Software Design Slide 6
Output of Activity A specification of some kind is the output of each
design activity It maybe an abstract, formal specification that is
produced to clarify the requirement Or it maybe a specification of how part of the system
is to be realized Detail will be added to the specification as the design
process continue The final results are precise specification of the
algorithm and data structure to be implemented
![Page 7: Ian Sommerville 1995 Software DesignSlide 1 Software Design u Deriving a solution which satisfies software requirements](https://reader035.vdocuments.mx/reader035/viewer/2022062413/5a4d1b727f8b9ab0599b5fa3/html5/thumbnails/7.jpg)
©Ian Sommerville 1995 Software Design Slide 7
Phases in the design process
Architecturaldesign
Abstractspecificatio
n
Interfacedesign
Componentdesign
Datastructuredesign
Algorithmdesign
Systemarchitecture
Softwarespecification
Interfacespecification
Componentspecification
Datastructure
specification
Algorithmspecification
Requirementsspecification
Design activities
Design products
![Page 8: Ian Sommerville 1995 Software DesignSlide 1 Software Design u Deriving a solution which satisfies software requirements](https://reader035.vdocuments.mx/reader035/viewer/2022062413/5a4d1b727f8b9ab0599b5fa3/html5/thumbnails/8.jpg)
©Ian Sommerville 1995 Software Design Slide 8
Design phases Architectural design Identify sub-systems Abstract specification Specify sub-systems Interface design Describe sub-system interfaces Component design Decompose sub-systems
into components Data structure design Design data structures to hold
problem data Algorithm design Design algorithms for problem
functions
![Page 9: Ian Sommerville 1995 Software DesignSlide 1 Software Design u Deriving a solution which satisfies software requirements](https://reader035.vdocuments.mx/reader035/viewer/2022062413/5a4d1b727f8b9ab0599b5fa3/html5/thumbnails/9.jpg)
©Ian Sommerville 1995 Software Design Slide 9
Hierarchical design structure
System level
Sub-systemlevel
![Page 10: Ian Sommerville 1995 Software DesignSlide 1 Software Design u Deriving a solution which satisfies software requirements](https://reader035.vdocuments.mx/reader035/viewer/2022062413/5a4d1b727f8b9ab0599b5fa3/html5/thumbnails/10.jpg)
©Ian Sommerville 1995 Software Design Slide 10
Top-down design In principle, top-down design involves starting
at the uppermost components in the hierarchy and working down the hierarchy level by level
In practice, large systems design is never truly top-down. Some branches are designed before others. Designers reuse experience (and sometimes components) during the design process
![Page 11: Ian Sommerville 1995 Software DesignSlide 1 Software Design u Deriving a solution which satisfies software requirements](https://reader035.vdocuments.mx/reader035/viewer/2022062413/5a4d1b727f8b9ab0599b5fa3/html5/thumbnails/11.jpg)
©Ian Sommerville 1995 Software Design Slide 11
Design methods Software design is still an ad hoc process, starting from a
set of requirements (usually in natural language), an informal design is prepared.
Structured methods are sets of notations for expressing a software design and guidelines for creating a design
Well-known methods include Structured Design (Yourdon), and JSD (Jackson Method) Can be applied successfully because they support standard notations and ensure designs follow a standard form
Structured methods may be supported with CASE tools
![Page 12: Ian Sommerville 1995 Software DesignSlide 1 Software Design u Deriving a solution which satisfies software requirements](https://reader035.vdocuments.mx/reader035/viewer/2022062413/5a4d1b727f8b9ab0599b5fa3/html5/thumbnails/12.jpg)
©Ian Sommerville 1995 Software Design Slide 12
Method components Many methods support comparable views of a
system A data flow view (data flow diagrams) showing
data transformations An entity-relation view describing the logical
data structures A structural view showing system components
and their interactions An Object-oriented modelling how objects are
composed and used by other objects
![Page 13: Ian Sommerville 1995 Software DesignSlide 1 Software Design u Deriving a solution which satisfies software requirements](https://reader035.vdocuments.mx/reader035/viewer/2022062413/5a4d1b727f8b9ab0599b5fa3/html5/thumbnails/13.jpg)
©Ian Sommerville 1995 Software Design Slide 13
Method deficiencies They are guidelines rather than methods in the
mathematical sense. Different designers create quite different system designs
They do not help much with the early, creative phase of design. Rather, they help the designer to structure and document his or her design ideas
![Page 14: Ian Sommerville 1995 Software DesignSlide 1 Software Design u Deriving a solution which satisfies software requirements](https://reader035.vdocuments.mx/reader035/viewer/2022062413/5a4d1b727f8b9ab0599b5fa3/html5/thumbnails/14.jpg)
©Ian Sommerville 1995 Software Design Slide 14
Design description There are three main types of notation used in design
document Graphical notations. Used to display
component relationships Program description languages. Based on
programming languages but with more flexibility to represent abstract concepts
Informal text. Natural language description. All of these notations may be used in large
systems design
![Page 15: Ian Sommerville 1995 Software DesignSlide 1 Software Design u Deriving a solution which satisfies software requirements](https://reader035.vdocuments.mx/reader035/viewer/2022062413/5a4d1b727f8b9ab0599b5fa3/html5/thumbnails/15.jpg)
©Ian Sommerville 1995 Software Design Slide 15
Design strategies Functional design
• The system is designed from a functional viewpoint. • The system state is centralised and shared between the
functions operating on that state Object-oriented design
• The system is viewed as a collection of interacting objects. • The system state is de-centralised and each object manages
its own state. Objects may be instances of an object class and communicate by exchanging messages
![Page 16: Ian Sommerville 1995 Software DesignSlide 1 Software Design u Deriving a solution which satisfies software requirements](https://reader035.vdocuments.mx/reader035/viewer/2022062413/5a4d1b727f8b9ab0599b5fa3/html5/thumbnails/16.jpg)
©Ian Sommerville 1995 Software Design Slide 16
Functional view of a compiler
AnalyseBuild
symboltable
Scansource
Generatecode
Symboltable
Outputerrors
Sourceprogram
Tokens Tokens Syntaxtree
Objectcode
ErrorindicatorSymbols Symbols
Errormessages
![Page 17: Ian Sommerville 1995 Software DesignSlide 1 Software Design u Deriving a solution which satisfies software requirements](https://reader035.vdocuments.mx/reader035/viewer/2022062413/5a4d1b727f8b9ab0599b5fa3/html5/thumbnails/17.jpg)
©Ian Sommerville 1995 Software Design Slide 17
Object-oriented view of a compiler
Sourceprogram
Tokenstream
Symboltable
Syntaxtree
Grammar Errormessages
Abstractcode
Objectcode
Scan Add
Check Get
Build Print
Generate
Generate
![Page 18: Ian Sommerville 1995 Software DesignSlide 1 Software Design u Deriving a solution which satisfies software requirements](https://reader035.vdocuments.mx/reader035/viewer/2022062413/5a4d1b727f8b9ab0599b5fa3/html5/thumbnails/18.jpg)
©Ian Sommerville 1995 Software Design Slide 18
Mixed-strategy design Although it is sometimes suggested that one
approach to design is superior, in practice, an object-oriented and a functional-oriented approach to design are complementary
Good software engineers should select the most appropriate approach for whatever sub-system is being designed
![Page 19: Ian Sommerville 1995 Software DesignSlide 1 Software Design u Deriving a solution which satisfies software requirements](https://reader035.vdocuments.mx/reader035/viewer/2022062413/5a4d1b727f8b9ab0599b5fa3/html5/thumbnails/19.jpg)
©Ian Sommerville 1995 Software Design Slide 19
Design quality Design quality is an elusive concept. Quality depends
on specific organisational priorities A 'good' design may be the most efficient, the
cheapest, the most maintainable, the most reliable, etc.
The attributes discussed here are concerned with the maintainability of the design
Quality characteristics are equally applicable to function-oriented and object-oriented designs
![Page 20: Ian Sommerville 1995 Software DesignSlide 1 Software Design u Deriving a solution which satisfies software requirements](https://reader035.vdocuments.mx/reader035/viewer/2022062413/5a4d1b727f8b9ab0599b5fa3/html5/thumbnails/20.jpg)
©Ian Sommerville 1995 Software Design Slide 20
Cohesion A measure of how well a component 'fits
together' A component should implement a single logical
entity or function Cohesion is a desirable design component
attribute as when a change has to be made, it is localised in a single cohesive component
Various levels of cohesion have been identified
![Page 21: Ian Sommerville 1995 Software DesignSlide 1 Software Design u Deriving a solution which satisfies software requirements](https://reader035.vdocuments.mx/reader035/viewer/2022062413/5a4d1b727f8b9ab0599b5fa3/html5/thumbnails/21.jpg)
©Ian Sommerville 1995 Software Design Slide 21
Cohesion levels Coincidental cohesion (weak)
• Parts of a component are simply bundled together Logical association (weak)
• Components which perform similar functions are grouped• For example:
output text to screenoutput line to printeroutput record to file
• Seems ok • Problem is it carries out a range of similar but different actions • No single well defined action
![Page 22: Ian Sommerville 1995 Software DesignSlide 1 Software Design u Deriving a solution which satisfies software requirements](https://reader035.vdocuments.mx/reader035/viewer/2022062413/5a4d1b727f8b9ab0599b5fa3/html5/thumbnails/22.jpg)
©Ian Sommerville 1995 Software Design Slide 22
Cohesion levels Temporal cohesion (weak)
• Components which are activated at the same time are grouped
• For example:clear screenopen fileInitialise total
• again not related • solution is to make initialisation module all other
specialised modules: call init_terminal call init_files call init_calculations
![Page 23: Ian Sommerville 1995 Software DesignSlide 1 Software Design u Deriving a solution which satisfies software requirements](https://reader035.vdocuments.mx/reader035/viewer/2022062413/5a4d1b727f8b9ab0599b5fa3/html5/thumbnails/23.jpg)
©Ian Sommerville 1995 Software Design Slide 23
Cohesion levels Procedural cohesion (weak)
• The elements in a component make up a single control sequence
Communicational cohesion (medium)• All the elements of a component operate on the same data• e.g. display and log temperature
Sequential cohesion (medium)• The output for one part of a component is the input to
another part
![Page 24: Ian Sommerville 1995 Software DesignSlide 1 Software Design u Deriving a solution which satisfies software requirements](https://reader035.vdocuments.mx/reader035/viewer/2022062413/5a4d1b727f8b9ab0599b5fa3/html5/thumbnails/24.jpg)
©Ian Sommerville 1995 Software Design Slide 24
Cohesion levels Functional cohesion (strong)
• optimal type of cohesion • performs a single well-defined action on a single data
object • e.g. calculate average • Each part of a component is necessary for the execution
of a single function Object cohesion (strong)
• Each operation provides functionality which allows object attributes to be modified or inspected
![Page 25: Ian Sommerville 1995 Software DesignSlide 1 Software Design u Deriving a solution which satisfies software requirements](https://reader035.vdocuments.mx/reader035/viewer/2022062413/5a4d1b727f8b9ab0599b5fa3/html5/thumbnails/25.jpg)
©Ian Sommerville 1995 Software Design Slide 25
Cohesion as a design attribute Not well-defined. Often difficult to classify
cohesion Inheriting attributes from super-classes
weakens cohesion To understand a component, the super-classes
as well as the component class must be examined
Object class browsers assist with this process
![Page 26: Ian Sommerville 1995 Software DesignSlide 1 Software Design u Deriving a solution which satisfies software requirements](https://reader035.vdocuments.mx/reader035/viewer/2022062413/5a4d1b727f8b9ab0599b5fa3/html5/thumbnails/26.jpg)
©Ian Sommerville 1995 Software Design Slide 26
A measure of the strength of the inter-connections between system components
Loose coupling means component changes are unlikely to affect other components
Shared variables or control information exchange lead to tight coupling
Loose coupling can be achieved by state decentralisation (as in objects) and component communication via parameters or message passing
Coupling
![Page 27: Ian Sommerville 1995 Software DesignSlide 1 Software Design u Deriving a solution which satisfies software requirements](https://reader035.vdocuments.mx/reader035/viewer/2022062413/5a4d1b727f8b9ab0599b5fa3/html5/thumbnails/27.jpg)
©Ian Sommerville 1995 Software Design Slide 27
Tight coupling
Module A Module B
Module C Module D
Shared dataarea
![Page 28: Ian Sommerville 1995 Software DesignSlide 1 Software Design u Deriving a solution which satisfies software requirements](https://reader035.vdocuments.mx/reader035/viewer/2022062413/5a4d1b727f8b9ab0599b5fa3/html5/thumbnails/28.jpg)
©Ian Sommerville 1995 Software Design Slide 28
Loose coupling
Module A
A’s data
Module B
B’s data
Module D
D’s data
Module C
C’s data
![Page 29: Ian Sommerville 1995 Software DesignSlide 1 Software Design u Deriving a solution which satisfies software requirements](https://reader035.vdocuments.mx/reader035/viewer/2022062413/5a4d1b727f8b9ab0599b5fa3/html5/thumbnails/29.jpg)
©Ian Sommerville 1995 Software Design Slide 29
Coupling levels Altering another modules code (LISP, Assembler) Modifying data within another module
• fault that appears in one module may be due to another • complicated understanding and debugging • can be done via global variables or pointers or call be
reference in C++ / Java Shared or global data
![Page 30: Ian Sommerville 1995 Software DesignSlide 1 Software Design u Deriving a solution which satisfies software requirements](https://reader035.vdocuments.mx/reader035/viewer/2022062413/5a4d1b727f8b9ab0599b5fa3/html5/thumbnails/30.jpg)
©Ian Sommerville 1995 Software Design Slide 30
Coupling levels Procedure call with a parameter that is a switch (or a
function pointer in C) • io (command, device buffer, length); • where command is 0,1,2 for read, write open; better to use • read( device, buffer, length);
Procedure call with parameters that are pure data • ideal is call by value, where a small number of parameters
are used and a copy of the data is passed to the procedure invoked
• clear what information is being communicated
![Page 31: Ian Sommerville 1995 Software DesignSlide 1 Software Design u Deriving a solution which satisfies software requirements](https://reader035.vdocuments.mx/reader035/viewer/2022062413/5a4d1b727f8b9ab0599b5fa3/html5/thumbnails/31.jpg)
©Ian Sommerville 1995 Software Design Slide 31
Coupling levels Passing a serial data stream
• most ideal situation• one module passes stream of data to another• once passed data is outside control of process/module• like piping in UNIX• data can be thought of as a temporary intermediate file• only possible in languages that support concurrency such as
Ada and Erlang and Parallel C
![Page 32: Ian Sommerville 1995 Software DesignSlide 1 Software Design u Deriving a solution which satisfies software requirements](https://reader035.vdocuments.mx/reader035/viewer/2022062413/5a4d1b727f8b9ab0599b5fa3/html5/thumbnails/32.jpg)
©Ian Sommerville 1995 Software Design Slide 32
Object-oriented systems are loosely coupled because there is no shared state and objects communicate using message passing
However, an object class is coupled to its super-classes. Changes made to the attributes or operations in a super-class propagate to all sub-classes. Such changes must be carefully controlled
Coupling and inheritance
![Page 33: Ian Sommerville 1995 Software DesignSlide 1 Software Design u Deriving a solution which satisfies software requirements](https://reader035.vdocuments.mx/reader035/viewer/2022062413/5a4d1b727f8b9ab0599b5fa3/html5/thumbnails/33.jpg)
©Ian Sommerville 1995 Software Design Slide 33
Related to several component characteristics• Cohesion. Can the component be understood on its own?• Naming. Are meaningful names used?• Documentation. Is the design well-documented?• Complexity. Are complex algorithms used?
Informally, high complexity means many relationships between different parts of the design. hence it is hard to understand
Most design quality metrics are oriented towards complexity measurement. They are of limited use
Understandability
![Page 34: Ian Sommerville 1995 Software DesignSlide 1 Software Design u Deriving a solution which satisfies software requirements](https://reader035.vdocuments.mx/reader035/viewer/2022062413/5a4d1b727f8b9ab0599b5fa3/html5/thumbnails/34.jpg)
©Ian Sommerville 1995 Software Design Slide 34
A design is adaptable if:• Its components are loosely coupled• It is well-documented and the documentation is up to date• There is an obvious correspondence between design levels
(design visibility)• Each component is a self-contained entity (tightly
cohesive) To adapt a design, it must be possible to trace the
links between design components so that change consequences can be analysed
Adaptability
![Page 35: Ian Sommerville 1995 Software DesignSlide 1 Software Design u Deriving a solution which satisfies software requirements](https://reader035.vdocuments.mx/reader035/viewer/2022062413/5a4d1b727f8b9ab0599b5fa3/html5/thumbnails/35.jpg)
©Ian Sommerville 1995 Software Design Slide 35
Design traceability
P O R
D
A
BF
C
D Object interactionlevel
Object decompositionlevel
![Page 36: Ian Sommerville 1995 Software DesignSlide 1 Software Design u Deriving a solution which satisfies software requirements](https://reader035.vdocuments.mx/reader035/viewer/2022062413/5a4d1b727f8b9ab0599b5fa3/html5/thumbnails/36.jpg)
©Ian Sommerville 1995 Software Design Slide 36
Inheritance dramatically improves adaptability. Components may be adapted without change by deriving a sub-class and modifying that derived class
However, as the depth of the inheritance hierarchy increases, it becomes increasingly complex. It must be periodically reviewed and restructured• new trend in this area known as refactoring, associated
with the lightweight process of Extreme Programming (XP)
Adaptability and inheritance