Software Design Software Design Process Process A solution to satisfy the requirements ◦ Design process and methods ◦ Design strategies including object- oriented design and functional decomposition ◦ Design quality attributes Reference: Software Engineering , by Ian Sommerville Modified by Dan Li, 2012
33
Embed
Software Design Process A solution to satisfy the requirements ◦ Design process and methods ◦ Design strategies including object-oriented design and functional.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Software Design Software Design ProcessProcess
A solution to satisfy the requirements◦ Design process and methods
◦ Design strategies including object-oriented design and functional decomposition
◦ Design quality attributes
Reference: Software Engineering, by Ian SommervilleModified by Dan Li, 2012
Design processDesign processAny 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
From informal to formal From informal to formal designdesign
Informaldesignoutline
Informaldesign
Moreformaldesign
Finisheddesign
Phases in the design processPhases in the design process
Top-down designTop-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
Design methodsDesign methodsStructured 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
Method componentsMethod componentsMany 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
Method deficienciesMethod deficienciesThey 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
Design descriptionDesign descriptionGraphical notations. Used to display
component relationshipsProgram description languages. Based on
programming languages but with more flexibility to represent abstract concepts
◦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 functionObject cohesion (strong)
◦Each operation provides functionality which allows object attributes to be modified or inspected
Cohesion as a design Cohesion as a design attributeattributeNot well-defined. Often difficult to classify
cohesionInheriting attributes from super-classes
weakens cohesionTo understand a component, the super-
classes as well as the component class must be examined
Object class browsers assist with this process
CouplingCouplingA measure of the strength of the inter-
connections between system componentsLoose coupling means component changes
are unlikely to affect other componentsShared variables or control information
exchange lead to tight couplingLoose coupling can be achieved by state
decentralisation (as in objects) and component communication via parameters or message passing
Tight couplingTight coupling
Module A Module B
Module C Module D
Shared dataarea
Loose couplingLoose coupling
Module A
A’s data
Module B
B’s data
Module D
D’s data
Module C
C’s data
Coupling levelsCoupling levelsAltering 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
Coupling levelsCoupling levelsProcedure 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
Coupling levelsCoupling levelsPassing 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
Coupling and inheritanceCoupling and inheritanceObject-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
UnderstandabilityUnderstandabilityRelated 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
AdaptabilityAdaptabilityA 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
Design traceabilityDesign traceability
P O R
D
A
B
F
C
D Object interactionlevel
Object decompositionlevel
Adaptability and inheritanceAdaptability and inheritanceInheritance 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)