SE2AA4 Intro to Design & Modules
Transcript of SE2AA4 Intro to Design & Modules
-
7/28/2019 SE2AA4 Intro to Design & Modules
1/23
107
Architecture & Design
What is design How can a system be decomposed into modules What is a modules interface What are the main relationships among modules Prominent software design techniques and information hiding The UML collection of design notations Design of concurrent and distributed software Design patterns Architectural styles Component based software engineering
108
What is design?
Provides structure to any artifact Decomposes system into parts, assigns
responsibilities, ensures that parts fit together to
achieve a global goal
Design refers to both an activity and the result of theactivity
-
7/28/2019 SE2AA4 Intro to Design & Modules
2/23
109
Two meanings of "design activity in
our context
Activity that acts as a bridge between requirementsand the implementation of the software
Activity that gives a structure to the artifact e.g., a requirements specification document must be
designed
must be given a structure that makes it easy tounderstand and evolve
110
Two meanings of "design activity in
our context
Activity that gives a structure to the artifact
Requirements
Decomposed so
domain experts
can read &understand it
easily
SDD
Decomposed so
software will be
structured for
easy maintenance
-
7/28/2019 SE2AA4 Intro to Design & Modules
3/23
111
The sw design activity
Defined as system decomposition into modules Produces a Software Design Document
describes system decomposition into modules Often asoftware architecture is produced prior to a
software design
112
Software architecture
Shows gross structure and organization of thesystem to be defined
Its description includes description of main components of a system relationships among those components rationale for decomposition into its components constraints that must be respected by any design of the
components
Guides the development of the design
-
7/28/2019 SE2AA4 Intro to Design & Modules
4/23
113
Two important goals
Design for change (Parnas) designers tend to concentrate on current needs special effort needed to anticipate likely changesInformation hiding - this is one of the most important
ideas in software design. Defined by Parnas in the
early 1970s. Identify requirements/design decisions
likely to change (calledsecrets), and encapsulate them
inside module never on the interface
Product families (Parnas) think of the current system under design as a member
of a program family
114
Sample likely changes? (1)
Algorithms e.g., replace inefficient sorting algorithm with a more
efficient one
Change of data representation e.g., from binary tree to a threaded tree (see example) 17% of maintenance costs attributed to data
representation changes (Lientz and Swanson, 1980)
-
7/28/2019 SE2AA4 Intro to Design & Modules
5/23
115
Example
116
Sample likely changes? (2)
Change of underlying abstract machine new release of operating system new optimizing compiler new version of DBMS
Change of peripheral devices Change of "social" environment
new tax regime
EURO vs national currency in EU Change due to development process (transform prototype
into product)
-
7/28/2019 SE2AA4 Intro to Design & Modules
6/23
117
Product families
Different versions of the same system e.g. a family of mobile phones
members of the family may differ in network standards,end-user interaction languages,
e.g. a facility reservation system for hotels: reserve rooms, restaurant, conference space,
, equipment (video beamers, overhead projectors, )
for a university many functionalities are similar, some are different (e.g.,
facilities may be free of charge or not)
118
Design goal for family
Design the whole family as one system, not eachindividual member of the family separately
-
7/28/2019 SE2AA4 Intro to Design & Modules
7/23
119
Sequential completion:
the wrong way
Design first member of product family Modify existing software to get next member products
120
How to do better
Anticipate definition of all family members Identify what is common to all family members, delay
decisions that differentiate among different members
We will learn how to manage change in design
-
7/28/2019 SE2AA4 Intro to Design & Modules
8/23
121
Module
A well-defined component of a software system A part of a system that provides a set of services to
other modules
Services are computational elements that other modulesmay use
A work assignment (Parnas)
122
Questions
How to define the structure of a modular system? What are the desirable properties of that structure?
-
7/28/2019 SE2AA4 Intro to Design & Modules
9/23
123
Modules and relations
Let S be a set of modulesS = {M1, M2, . . ., Mn}
A binary relation r on S is a subset ofS x S
If Mi and Mj are in S, r can be written asMi r Mj
124
Relations
Transitive closure r+ of rMi r
+ Mj iff
Mi r Mj or Mkin S s.t. Mi r Mk and Mkr+ Mj
(We assume our relations to be irreflexive)
r is a hierarchy iff there are no two elementsMi, Mj s.t. Mi r
+ Mj Mj r+ Mi
-
7/28/2019 SE2AA4 Intro to Design & Modules
10/23
125
Relations
Relations can be represented as graphs A hierarchy is a DAG (directed acyclic graph)
M1
M2M3
M4
M1,1 M1,2 M1,3
M1,2,1 M1,2,2
M1,2,1,1
M
M M
M M
M
1
2 3
4 5
6
a) b)
a graph
a DAG
126
The USES relation
A uses B A requires the correct operation of B A can access the services exported by B through its
interface
it is statically defined A depends on B to provide its services
example: A calls a routine exported by B A is a client of B; B is a server
-
7/28/2019 SE2AA4 Intro to Design & Modules
11/23
127
Desirable property
USES should be a hierarchy Hierarchy makes software easier to understand
we can proceed from leaf nodes (who do not use others)upwards
They make software easier to build They make software easier to test
128
Hierarchy
Organizes the modular structure through levels ofabstraction
Each level defines an abstract (virtual) machine forthe next level
levelcan be defined precisely Mi has level 0 if no Mj exists s.t. Mi r Mj let k be the maximum level of all nodes Mj s.t. Mi r Mj.
Then Mi has level k+1
-
7/28/2019 SE2AA4 Intro to Design & Modules
12/23
129
Module Decomposition (Parnas)
App
H/Whiding
S/Wdecision
Behav.hiding
Conceptualmodules
Leaf modulescontain
code
130
Module Fundamentals
NameInterface
TypesConstants
Access programs
-
7/28/2019 SE2AA4 Intro to Design & Modules
13/23
131
Module Fundamentals
NameInterface
TypesConstants
Access programs
ImplementationTypesConstants
VariablesDetails of access programs &local programs
Hiddenfrom
everyone
other
than the
designersof the
module
132
Module Fundamentals
Module Aint getS1int getS2setValues(int v1,v2)
int S1, S2.setValues(int v1,v2)
q = B.getVS1 = v1S2 = v2*q
Module Bint getVsetValue(int n)
int V.setValue(int n)
V = n
-
7/28/2019 SE2AA4 Intro to Design & Modules
14/23
133
IS_COMPONENT_OF
Used to describe a higher level module as constituted by anumber of lower level modules
A IS_COMPONENT_OF B B consists of several modules, of which one is A
B COMPRISES A MS,i={Mk|MkSMkIS_COMPONENT_OF Mi}
we say that MS,i IMPLEMENTS Mi
134
A graphical view
M1
M M
M MM M M
2 4
5 67 8 9
M3
M MM M M5 67 8 9
M2 M3 M4
M1
(IS_COMPONENT_OF) (COMPRISES)
They are hierarchies
-
7/28/2019 SE2AA4 Intro to Design & Modules
15/23
135
Product families
Careful recording of (hierarchical) USES relation andIS_COMPONENT_OF supports design of program
families
136
Interface vs.
implementation (1)
To understand the nature of USES, we need to knowwhat a used module exports through its interface
The client imports the resources that are exported byits servers
Modules implementthe exported resources Implementation is hidden to clients
-
7/28/2019 SE2AA4 Intro to Design & Modules
16/23
137
Interface vs.
implementation (2)
Clear distinction between interface andimplementation is a key design principle
Supports separation of concerns clients care about resources exported from servers servers care about implementation
Interface acts as a contract between a module and itsclients
138
Interface vs.
implementation (3)
interface is like the tip of the iceberg
-
7/28/2019 SE2AA4 Intro to Design & Modules
17/23
139
Interface vs.
implementation (3)
interface is like the tip of the iceberg- need to include effects as well
140
Interface vs.
implementation (4)
To describe the interface, we need to describe therelationship between outputs (responses) to inputs(stimuli).
One way is to use a black-box model, from HarlanMills Box Structures.
This is a history-based approach.
-
7/28/2019 SE2AA4 Intro to Design & Modules
18/23
141
Interface vs.
implementation (5)
R = f ( S, Sh )S is the set of stimuli, Sh the set of
stimulus history, R the set of responses
(S1-1 is previous instance of S1, etc.)
R1
R2
R1-1
R2-1
S1
S2S2-1
S1-1
S3
S2-1
S3-1
System
Mills, H.D.: Stepwiserefinement and
verification in box-structured systems.
Computer 21 (1988)23-36
142
Interface vs.
implementation (6)
When we use an infinite history as in the Millsblack-box description, we can describe Ri in termsof any Sj and their history.
We can include statements such as most recentvalue of Sk, for example.
If we describe the behaviour solely in terms ofSand Sh, i.e. externally visible behaviour, we will
not include any implementation details.
-
7/28/2019 SE2AA4 Intro to Design & Modules
19/23
143
Interface vs.
implementation (7)
There are a couple of problems with a history-basedapproach:
Infinite history is not practical when it comes tobuilding an implementation (my opinion - its onereason why it is great for describing requirements, andthe interface represents requirements for the module).
Some people find it difficult to write history-baseddescriptions.
144
Interface vs.
implementation (8)
An alternative to the black-box description is a state-box description (almost identical to a finite statemachine FSM)
S R
state
next state
output
functions
data
-
7/28/2019 SE2AA4 Intro to Design & Modules
20/23
145
Interface vs.
implementation (9)
FSM Assume FSM has a clock that ticks at
t0, t1, t2, t3, , tk, tk+1,
At each clock tick we evaluateR(tk) = f( S(tk), X(tk) )
X(tk+1) = g( S(tk), X(tk) )
where
X is the state dataand X(t0) must be known.
k=0,1,2,3,
output function
next state function
146
Interface vs.
implementation (10)
The state in the FSM captures the effect of historyin the black-box representation.
We have to be careful in describing interfaces using aFSM - dont give away how the state data is storedetc.
We do this by keeping the state data simple - usuallyjust the previous value of a stimulus or response.
-
7/28/2019 SE2AA4 Intro to Design & Modules
21/23
147
Remember -
Information hiding
Basis for design (i.e. module decomposition) Implementation secrets are hidden to clients They can be changed freely if the change does not
affect the interface
Golden design principleINFORMATION HIDING
Try to encapsulate changeable (requirements &) designdecisions as implementation secrets within module
implementations
148
Interface design
Interface should not reveal what we expect maychange later
It should not reveal unnecessary details Interface acts as a firewall preventing access to hidden
parts
-
7/28/2019 SE2AA4 Intro to Design & Modules
22/23
149
Prototyping
Once an interface is defined, implementation can bedone
first quickly but inefficiently then progressively turned into the final version
Initial version acts as a prototype that evolves into thefinal product
150
More on likely changes
an example
Policies may be separated from mechanisms mechanism
ability to suspend and resume tasks in a concurrent systempolicy
how do we select the next task to resume? different scheduling policies are available they may be hidden to clients they can be encapsulated as module secrets
-
7/28/2019 SE2AA4 Intro to Design & Modules
23/23
151
Design notations
Notations allow designs to be described precisely They can be textual or graphic We illustrate three sample notations
Parnas Rational Design Process (MG, MIS, MID) TDN (Textual Design Notation) We discuss the notations provided by UML