SEC 308 Yazılım Mühendisliği
Software Design
1
Analysis Model -> Design Model
2
Design and Quality
0 the design must implement all of the explicit requirements
contained in the analysis model,
... and it must accommodate all of the implicit requirements
desired by the customer.
0 the design must be a readable, understandable guide for
those who generate code and for those who test and
subsequently support the software.
0 the design should provide a complete picture of the
software, addressing the data, functional and behavioral
domains from an implementation perspective.
3
Quality Guidelines
0 A design should exhibit an architecture that
0 (1) has been created using recognizable architectural styles or
patterns,
0 (2) is composed of components that exhibit good design
characteristics
0 (3) can be implemented in an evolutionary fashion
0 A design should be modular; that is, the software should be
logically partitioned into elements or subsystems
0 A design should contain distinct representations of data,
architecture, interfaces, and components.
0 A design should lead to components that exhibit
independent functional characteristics.
0 A design should be represented using a notation that
effectively communicates its meaning.
4
Quality Attributes
0 Functionality: assess features & capabilities,
generality of functions, security of overall system
0 Usability: assess human factors, consistency, and
documentation
0 Performance: processing speed, response time,
resource consumption…
0 Supportability: maintainability, compatibility, ease
of configuration, ease of installation
5
Fundamental Design Concepts
0 abstraction—data, procedure, control
0 architecture—the overall structure of the software
0 patterns—”conveys the essence” of a proven design solution
0 modularity—compartmentalization of data and function
0 hiding—controlled interfaces
0 Functional independence—single-minded function and low
coupling
0 refinement—elaboration of detail for all abstractions
0 Refactoring—a reorganization technique that simplifies the
design
6
Data Abstraction
door
Manufacturer
model number
type
swing direction
inserts
lights
type
number
weight
opening mechanism
implemented as a data structure
7
Procedural Abstraction
open
details of enter
algorithm
implemented with a "knowledge" of the
object that is associated with enter
8
Architecture
“The overall structure of the software and the ways in which that
structure provides conceptual integrity for a system.” [SHA95a]
0 Structural properties. This aspect of the architectural design
representation defines the components of a system (e.g., modules,
objects, filters) and the manner in which those components are
packaged and interact with one another. For example, objects are
packaged to encapsulate both data and the processing that manipulates
the data and interact via the invocation of methods
0 Extra-functional properties. The architectural design description should
address how the design architecture achieves requirements for
performance, capacity, reliability, security, adaptability, and other
system characteristics.
0 Families of related systems. The architectural design should draw upon
repeatable patterns that are commonly encountered in the design of
families of similar systems. In essence, the design should have the ability
to reuse architectural building blocks.
9
Patterns
0
0
0
0
0
0
0
0
0
0
Design Pattern Template
Pattern name—describes the essence of the pattern in a short but expressive name
Intent—describes the pattern and what it does
Also-known-as—lists any synonyms for the pattern
Motivation—provides an example of the problem
Applicability—notes specific design situations in which the pattern is applicable
Structure—describes the classes that are required to implement the pattern
Participants—describes the responsibilities of the classes that are required to implement
the pattern
Collaborations—describes how the participants collaborate to carry out their
responsibilities
Consequences—describes the “design forces” that affect the pattern and the potential
trade-offs that must be considered when the pattern is implemented
Related patterns—cross-references related design patterns
10
Modular Design
easier to build, easier to change, easier to fix ...
11
Modularity: Trade-offs
What is the "right" number of modules for a specific software design?
module development cost
cost of
software
module
integration
cost
optimal number
of modules
number of modules
12
Information Hiding
module
controlled
interface
• algorithm
• data structure
• details of external interface
• resource allocation policy
clients
"secret"
a specific design decision
13
Why Information Hiding?
0 reduces the likelihood of “side effects”
0 limits the global impact of local design decisions
0 emphasizes communication through controlled
interfaces
0 discourages the use of global data
0 leads to encapsulation—an attribute of high quality
design
0 results in higher quality software
14
Stepwise Refinement
open
walk to door;
reach for knob;
open door;
walk through;
close door.
repeat until door opens
turn knob clockwise;
if knob doesn't turn, then
take key out;
find correct key;
insert in lock;
endif
pull/push door
move out of way;
end repeat
15
Functional Independence
COHESION - the degree to which a
module performs one and only one
function.
COUPLING - the degree to which a
module is "connected" to other
modules in the system.
16
Sizing Modules: Two Views
What's
inside??
How big
is it??
MODULE
17
Refactoring
0 Fowler [FOW99] defines refactoring in the following
manner:
0 "Refactoring is the process of changing a software system
in such a way that it does not alter the external behavior
of the code [design] yet improves its internal structure.”
0 When software is refactored, the existing design is
examined for
0 redundancy
0 unused design elements
0 inefficient or unnecessary algorithms
0 poorly constructed or inappropriate data structures
0 or any other design failure that can be corrected to yield a
better design.
18
The Design Model
hi g h
a n a ly s is m o d e l
c las s diagr am s
analy s is pac k ages
C RC m o d e l s
c ollabor at ion diagr am s
dat a f low diagr am s
c ont r ol- f low diagr am s
pr oc es s ing nar r at iv es
Re q u ire m e n t s :
us e- c as es - t ex t
c las s diagr am s
us e- c as e diagr am s
analy s is pac k ages
c o n s t ra in t s
ac t iv it y diagr am s
C RC m o d e l s
in t e ro p e ra b ilit y
s w im lane diagr am s
c ollabor at ion diagr am s
c ollabor at ion diagr am s
t a rg e t s a n d
dat a f low diagr am s
s t at e diagr am s
c ont r ol- f low diagr am s
s equenc e diagr am s
pr oc es s ing nar r at iv es
c o n f ig u ra t io n
s t at e diagr am s
s equenc e diagr am s
des ign c las s r ealiz at ions
s ubs y s t em s
c ollabor at ion diagr am s
t ec hnic al int er f ac e
des ign
c om ponent diagr am s
des ign c las s es
Nav igat ion des ign
ac t iv it y diagr am s
GU I d e s i g n
s equenc e diagr am s
des ign c las s r ealiz at ions
s ubs y s t em s
c ollabor at ion diagr am s
c om ponent diagr am s
d e s ig n m o d e l
des ign c las s es
r ef inem ent s t o:
r ef inem ent s t o:
c om ponent diagr am s
des ign c las s r ealiz at ions
lo w
ac t iv it y diagr am s
s equenc e diagr am s
des ign c las s es
s ubs y s t em s
ac t iv it y diagr am s
c ollabor at ion diagr am s
s equenc e diagr am s
deploy m ent diagr am s
ar c hi t ec t ur e
i nt er f ac e
c o m po nent - l ev el
depl o y m ent - l ev el
el em ent s
el em ent s
el em ent s
el em ent s
p r o c e ss d im e n sio n
19
Design Model Elements
0 Data elements
0 Data model --> data structures
0 Data model --> database architecture
0 Architectural elements
0 Application domain
0 Analysis classes, their relationships, collaborations and behaviors are
transformed into design realizations
0 Patterns and “styles” (Chapter 10)
0 Interface elements
0 the user interface (UI)
0 external interfaces to other systems, devices, networks or other producers or
consumers of information
0 internal interfaces between various design components.
0 Component elements
0 Deployment elements
20
Data Design
0 Data design translates data objects defined as part of
the analysis model into
0 Data structures at the software component level
0 A possible database architecture at the application level
0 It focuses on the representation of data structures that
are directly accessed by one or more software
components
0 The challenge is to store and retrieve the data in such
way that useful information can be extracted from the
data environment
0 "Data quality is the difference between a data
warehouse and a data garbage dump"
21
Software Architecture
0 The software architecture of a program or computing
system is the structure or structures of the system which
comprise
0 The software components
0 The externally visible properties of those components
0 The relationships among the components
0 Software architectural design represents the structure of the
data and program components that are required to build a
computer-based system
0 An architectural design model is transferable
0 It can be applied to the design of other systems
0 It represents a set of abstractions that enable software engineers to
describe architecture in predictable ways
22
Example Software Architecture
Diagrams
23
Why Architecture?
0 The architecture is not the operational software.
Rather, it is a representation that enables a software
engineer to:
0 (1) analyze the effectiveness of the design in meeting
its stated requirements,
0 (2) consider architectural alternatives at a stage when
making design changes is still relatively easy, and
0 (3) reduce the risks associated with the construction
of the software.
24
Architectural Styles
Each style describes a system category that encompasses:
(1) a set of components (e.g., a database, computational modules) that perform a
function required by a system,
(2) a set of connectors (subroutine call, remote procedure call, data stream,
socket) that enable “communication, coordination and cooperation” among
components,
(3) semantic constraints that define how components can be integrated to form
the system, and …
•
•
•
•
•
Data flow architectures
Call and return architectures
Data-centered architectures
Virtual Machine architectures
Independent Component architectures
25
A Taxonomy of Architectural Styles
26
Data Flow Architecture
27
Data Flow Architecture
0 Has the goal of modifiability
0 Characterized by viewing the system as a series of transformations on
successive pieces of input data
0 Data enters the system and then flows through the components one at a time
until they are assigned to output or a data store
0 Batch sequential style
0 The processing steps are independent components
0 Each step runs to completion before the next step begins
0 Pipe-and-filter style
0
0
0
0
Emphasizes the incremental transformation of data by successive components
The filters incrementally transform the data (entering and exiting via streams)
The filters use little contextual information and retain no state between instantiations
The pipes are stateless and simply exist to move data between filters
0 Use this style when it makes sense to view your system as one that produces a
well-defined easily identified output
0 The output should be a direct result of sequentially transforming a well-defined easily
identified input in a time-independent fashion
28
Call and Return Architecture
29
Call and Return Architecture
0 Has the goal of modifiability and scalability
0 Has been the dominant architecture since the start of software
development
0 Main program and subroutine style
0 Decomposes a program hierarchically into small pieces (i.e.,
modules)
0 Typically has a single thread of control that travels through various
components in the hierarchy
0 Remote procedure call style
0 Consists of main program and subroutine style of system that is
decomposed into parts that are resident on computers connected via
a network
0 Strives to increase performance by distributing the computations
and taking advantage of multiple processors
0 Incurs a finite communication time between subroutine call and
30
response
Call and Return Architecture
0 Object-oriented or abstract data type system
0 Emphasizes the bundling of data and how to manipulate and access data
0 Keeps the internal data representation hidden and allows access to the object only
through provided operations
0 Permits inheritance and polymorphism
0 Layered system
0 Assigns components to layers in order to control inter-component interaction
0 Only allows a layer to communicate with its immediate neighbor
0 Assigns core functionality such as hardware interfacing or system kernel operations to
the lowest layer
0 Builds each successive layer on its predecessor, hiding the lower layer and providing
services for the upper layer
0 Is compromised by layer bridging that skips one or more layers to improve runtime
performance
0 Use this style when the order of computation is fixed, when interfaces are
specific, and when components can make no useful progress while awaiting the
results of request to other components
31
Data-Centered Architecture
32
Data-Centered Architecture
0 Has the goal of integrating the data
0 Refers to systems in which the access and update of a widely accessed data store
occur
0 A client runs on an independent thread of control
0 The shared data may be a passive repository or an active blackboard
0 A blackboard notifies subscriber clients when changes occur in data of interest
0 At its heart is a centralized data store that communicates with a number of
0
0
0
0
clients
Clients are relatively independent of each other so they can be added, removed,
or changed in functionality
The data store is independent of the clients
Use this style when a central issue is the storage, representation, management,
and retrieval of a large amount of related persistent data
Note that this style becomes client/server if the clients are modeled as
independent processes
33
Virtual Machine Architecture
Program Data
Program
Instructions
Interpretation
Engine
Program
Internal State
34
Virtual Machine Architecture
0 Has the goal of portability
0 Software systems in this style simulate some functionality that is not
native to the hardware and/or software on which it is implemented
0 Can simulate and test hardware platforms that have not yet been built
0 Can simulate "disaster modes" as in flight simulators or safety-critical
systems that would be too complex, costly, or dangerous to test with the real
system
0 Examples include interpreters, rule-based systems, and command
language processors
0 Interpreters
0 Add flexibility through the ability to interrupt and query the program and
introduce modifications at runtime
0 Incur a performance cost because of the additional computation involved in
execution
0 Use this style when you have developed a program or some form of
computation but have no make of machine to directly run it on
35
Independent Component Architecture
Client A
Client B
Server
Client D
Client C
Peer X
Peer W
Peer Y
Peer Z
36
Independent Component Architecture
0 Consists of a number of independent processes that communicate
through messages
0 Has the goal of modifiability by decoupling various portions of the
computation
0 Sends data between processes but the processes do not directly control
each other
0 Event systems style
0 Individual components announce data that they wish to share (publish) with
their environment
0 The other components may register an interest in this class of data
(subscribe)
0 Makes use of a message component that manages communication among the
other components
0 Components publish information by sending it to the message manager
0 When the data appears, the subscriber is invoked and receives the data
0 Decouples component implementation from knowing the names and
locations of other components
37
Independent Component Architecture
0 Communicating processes style
0
0
0
0
0
These are classic multi-processing systems
Well-know subtypes are client/server and peer-to-peer
The goal is to achieve scalability
A server exists to provide data and/or services to one or more clients
The client originates a call to the server which services the request
0 Use this style when
0 Your system has a graphical user interface
0 Your system runs on a multiprocessor platform
0 Your system can be structured as a set of loosely coupled
components
0 Performance tuning by reallocating work among processes is
important
0 Message passing is sufficient as an interaction mechanism among
components
38
Architectural Design Steps
1) Represent the system in context
2) Define archetypes
3) Refine the architecture into components
4) Describe instantiations of the system
39
Architectural Context
0 Use an architectural context diagram (ACD) that shows
0 The identification and flow of all information into and out of a system
0 The specification of all interfaces
0 Any relevant support processing from/by other systems
0 An ACD models the manner in which software interacts with entities
external to its boundaries
0 An ACD identifies systems that interoperate with the target system
0 Super-ordinate systems
0 Use target system as part of some higher level processing scheme
0 Sub-ordinate systems
0 Used by target system and provide necessary data or processing
0 Peer-level systems
0 Interact on a peer-to-peer basis with target system to produce or consume data
0 Actors
0 People or devices that interact with target system to produce or consume data
40
Architectural Context Diagram
41
SafeHome ACD
42
Archetypes
0 Archetypes indicate the important abstractions within the problem
0
0
0
0
domain (i.e., they model information)
An archetype is a class or pattern that represents a core abstraction that
is critical to the design of an architecture for the target system
It is also an abstraction from a class of programs with a common
structure and includes class-specific design strategies and a collection of
example program designs and implementations
Only a relatively small set of archetypes is required in order to design
even relatively complex systems
The target system architecture is composed of these archetypes
0 They represent stable elements of the architecture
0 They may be instantiated in different ways based on the behavior of the
system
0 They can be derived from the analysis class model
0 The archetypes and their relationships can be illustrated in a UML class
diagram
43
Example Archetypes in Humanity
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Addict/Gambler
Amateur
Beggar
Clown
Companion
Damsel in distress
Destroyer
Detective
Don Juan
Drunk
Engineer
Father
Gossip
Guide
Healer
Hero
Judge
King
Knight
Liberator/Rescuer
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Lover/Devotee
Martyr
Mediator
Mentor/Teacher
Messiah/Savior
Monk/Nun
Mother
Mystic/Hermit
Networker
Pioneer
Poet
Priest/Minister
Prince
Prostitute
Queen
Rebel/Pirate
Saboteur
Samaritan
Scribe/Journalist
•
•
•
•
•
•
•
•
•
•
Seeker/Wanderer
Servant/Slave
Storyteller
Student
Trickster/Thief
Vampire
Victim
Virgin
Visionary/Prophet
Warrior/Soldier
(Source: http://www.myss.com/ThreeArchs.asp)
44
Example Archetypes in Software
Architecture
•
•
•
•
•
Node
Detector/Sensor
Indicator
Controller
Manager
•
•
•
•
Moment-Interval
Role
Description
Party, Place or Thing
(Source: Pressman) (Source: Archetypes, Color, and the Domain Neutral Compon
45
Archetypes – their attributes
46
Archetypes – their methods
47
Components
0 Based on the archetypes, the architectural designer refines the software
architecture into components to illustrate the overall structure and
architectural style of the system
0 These components are derived from various sources
0 The application domain provides application components, which are the
domain classes in the analysis model that represent entities in the real world
0 The infrastructure domain provides design components (i.e., design classes)
that enable application components but have no business connection
0 Examples: memory management, communication, database, and task management
0 The interfaces in the ACD imply one or more specialized components that
process the data that flow across the interface
0 A UML class diagram can represent the classes of the refined
architecture and their relationships
48
Instantiations of the System
0 An actual instantiation of the architecture is developed by
applying it to a specific problem
0 This demonstrates that the architectural structure, style and
components are appropriate
0 A UML component diagram can be used to represent this
instantiation
49
Component Structure
Sa f e Ho m e
Ex e c u t iv e
Fu n c t io n
se le c t io n
Ext e r n al
Co m m u n icat io n
Man ag e m e n t
Se c u rit y
GUI
Su rv e illa n c e
Ho m e
m anagem ent
In t e rn e t
In t e rf a c e
Cont r ol
panel
det ec t or
alar m
m anagem ent
pr oc es s ing
pr oc es s ing
50
Refined Component Structure
Saf eHo m e
Exec ut ive
Ex t e r n a l
Com m unic at ion
M anagem ent
Instantiations of the System
Secur it y
GUI
Int er net
Int er f ace
Co n t ro l
d e t e ct o r
alarm
p an e l
m an ag e m e n t
p ro ce ss in g
p ro c e s sin g
K e y p ad
p ro ce ssin g
sc h e d u le r
phone
co m m u n ic at io n
CP d isp lay
f u n c t io n s
alarm
se nn ssoo rr
sor r
ssesee
nnsso
se
sennn
nso
orr rr
se
ssoo
se
se
en
ns
so
or
s
se n so r r
51
Analyzing Architectural Design
0 Describe the architectural styles/patterns that have been
chosen to address the scenarios and requirements:
0 module view
0 process view
0 data flow view
0 Evaluate quality attributes by considering each attribute in
isolation.
•
•
•
•
easier to test
easier to maintain
propagation of fewer side effects
easier to extend
52
Deriving Program Architecture
Program
Architecture
53
Partitioning the Architecture
• “horizontal” and “vertical” partitioning are
required
54
Horizontal Partitioning
• define separate branches of the module
hierarchy for each major function
• use control modules to coordinate
communication between functions
function 3
function 1
function 2
55
Vertical Partitioning: Factoring
• design so that decision making and work are
stratified
• decision making modules should reside at the top of
the architecture
decision-makers
workers
56
Why Partitioned Architecture?
•
•
•
•
results in software that is easier to test
leads to software that is easier to maintain
results in propagation of fewer side effects
results in software that is easier to extend
57
Structured Design
• objective: to derive a program architecture
that is partitioned
• approach:
– the DFD is mapped into a program
architecture
– the PSPEC and STD (state transition
diagram) are used to indicate the
content of each module
• notation: structure chart
58
Flow Characteristics
Transform flow:
•Incoming flow
•Transform center
•Outgoing flow
Transaction flow
•A single data item
59
General Mapping Approach
0 isolate incoming and outgoing flow
boundaries; for transaction flows, isolate the
transaction center
0 working from the boundary outward, map
DFD transforms into corresponding modules
0 add control modules as required
0 refine the resultant program structure using
effective modularity concepts
60
Transform Mapping
b
a
d
e
h
g
f
i
c
j
data flow model
x1
x2
b
x4
x3
c
a
"Transform" mapping
d
e
f
g
i
h
j
61
Factoring
direction of increasing
decision making
typical "decision
making" modules
typical "worker" modules
62
First Level Factoring
main
program
controller
input
controller
processing
controller
output
controller
63
Second Level Mapping
main
D
C
control
B
A
A
B
C
mapping from the
flow boundary outward
D
64
Transaction Flow
incoming flow
action path
T
65
Transaction Example
Control
panel
display
Display
information
Control
panel
Sensors
commands
SafeHome
Software
Sensor status
Alarm Type
Alarm
Telephone
number
tones
Telephone
Line
66
Transaction Mapping Principles
0 isolate the incoming flow path
0 define each of the action paths by looking for the
"spokes of the wheel
0 assess the flow on each action path
0 define the dispatch and control structure
0 map each action path flow individually
67
Transaction Mapping
Data flow model
f
e
a
d
b
mapping
t
x1
program structure
i
g
h
l
k
t
b
j
m
a
n
d
x2
e
x4
x3
f
g
l
x3.1
h
m
n
j
i
k
68
Isolate Flow Paths
error msg
command
produce
error msg
read
command
command validate
command
invalid command
valid command
fixture setting
status
format
setting
read
fixture
status
determine
type
robot control
read
record
combined
status
record
calculate
output
values
send
control
value
start/stop
determine
setting raw setting
assembly
record
values
format
report
report
69
Map the Flow Model
process
operator
commands
command
input
controller
read
command
validate
command
determine
type
produce
error
message
fixture
status
controller
report
generation
controller
send
control
value
each of the action paths must be expanded further
70
Refining the Structure Chart
process
operator
commands
command
input
controller
read
command
validate
command
read
fixture
status
determine
type
produce
error
message
determine
setting
fixture
status
controller
form at
setting
report
generation
controller
read
record
send
control
value
calculate
output
values
form at
report
71
What is a Component?
0 OMG Unified Modeling Language Specification [OMG01]
defines a component as
0 “… a modular, deployable, and replaceable part of a
system that encapsulates implementation and exposes a
set of interfaces.”
0 OO view: a component contains a set of collaborating
classes
0 Conventional view: logic, the internal data structures that
are required to implement the processing logic, and an
interface that enables the component to be invoked and data
to be passed to it.
72
OO Component
a n a l y si s c l a ss
P ri n t J o b
What are the differences?
n u m b e rO f P a g e s
n u m b e rO f S i d e s
p a p e rT y p e
m a g n if ic a t io n
p ro d u c t i o n F e a t u re s
d e si g n c o m p o n e n t
c o m p u t e J o b Co s t ( )
c o m p u t e Jo b
p a s s J o b t o P ri n t e r( )
P ri n t J o b
i n i t i a t e Jo b
Interface=method?
< < in t er f ac e> >
c o m p u t eJ o b
e la b o r a t e d d e s ig n c la s s
Pr in t J o b
c omput ePageC os t
()
c omput ePaper C os t ( )
c omput ePr odC os t ( )
c omput eTot alJ obC os t ( )
number O f Pages
number O f Sides
paper Ty pe
paper W eight
paper Siz e
paper C olor
magnif ic at ion
c olor Requir ement s
pr oduc t ionFeat ur es
< < in t er f ac e> >
in it iat eJ o b
buildW or k O r der ( )
c hec k Pr ior it y ( )
pas s J obt o Pr oduc t ion( )
c ollat ionO pt ions
bindingO pt ions
c ov er St oc k
bleed
pr ior it y
t ot alJ obC os t
OO view: a component
contains a set of collaborating
classes
W O number
c omput ePageC os t ( )
c omput ePaper C os t ( )
c omput ePr odC os t ( )
c omput eTot alJ obC os t ( )
buildW or k O r der ( )
c hec k Pr ior it y ( )
pas s J obt o Pr oduc t ion( )
73
Conventional Component
d esig n co m p o nent
g et Jo b Dat a
Co m p ut ePag eCo st
acc essCo s t s DB
Conventional view:
logic, the internal data structures
that are required to implement the
processing logic, and
 an interface that enables the
component to be invoked and data
to be passed to it.
elab o r at ed m o d ule

Pag eCo st
in: num berPages
in: num berDocs
in: sides= 1 , 2
in: color= 1 , 2 , 3 , 4
in: page size = A , B , C, B
out : page cost
in: j ob size
in: color= 1 , 2 , 3 , 4
in: pageSize
out : B PC
= A , B , C, B
out : SF
g e t Jo b Dat a ( n u m b e rP ag e s , n u m b e rDo cs,
sid e s, co lo r, p ag e S ize , p ag e Co s t )
acce ssCo st sDB (j o b S ize , c o lo r, p ag e S iz e ,
B P C, S F )
co m p u t e P ag e Co st( )
j o b s ize ( JS ) =
n u m b e rP ag e s * n u m b e rDo cs;
lo o ku p b ase p ag e co s t ( B P C) -->
acc e s sCo st sDB ( J S , c o lo r) ;
lo o ku p size f ac t o r ( S F) -->
acc e s sCo st DB ( JS , c o lo r, s ize )
j o b c o m p le xit y f act o r ( J CF) =
1 + [ ( sid e s -1 ) * sid e Co st + S F]
p ag e co st = B P C * JCF
74
Cohesion and Coupling
Cohesion
0 Conventional view:
0 the “single-mindedness” of a module
0 OO view:
0 a component or class encapsulates only attributes and operations that are closely
related to one another Levels of cohesion
0 Functional, Layer, Communicational, Sequential, Procedural, Temporal, utility
Coupling
0 Conventional view:
0
0
OO view:
0
0
The degree to which a component is connected to other components and to the
external world
a qualitative measure of the degree to which classes are connected to one another
Level of coupling
0
Content, Common, Control, Stamp, Data, Routine call, Type use, Inclusion or import, 75
External
Component Level Design
0 Step 1. Identify all design classes that correspond to the problem domain,
infrastructure domain.
0
0
0
0
0
Step 2. Elaborate all design classes (not acquired as reusable components).
Step 2a. Specify message details when classes or component collaborate.
Step 2b. Identify appropriate interfaces for each component.
Step 2c. Elaborate attributes and define data types and data structures.
Step 2d. Describe processing flow within each operation in detail.
0 Step 3. Describe persistent data sources (databases and files) and identify the
classes required to manage them.
0 Step 4. Develop and elaborate behavioral representations for a class or
component.
0 Step 5. Elaborate deployment diagrams to provide additional implementation
detail.
0 Step 6. Factor every component-level design representation and always
consider alternatives.
76
Activity Diagram
v a lid a t e a t t r ib u t e s
in p u t
a c c e s s Pa p e r D B ( w e ig h t )
ret urns
b a s e C o s t p e r Pa g e
p a p e r C o s t p e r Pa g e
=
b a s e C o s t p e r Pa g e
s iz e = B
p a p e r C o s t p e r Pa g e =
p a p e r C o s t p e r Pa g e * 1 . 2
s iz e = C
p a p e r C o s t p e r Pa g e
=
What is this about wrt.
Component-level design?
p a p e r C o s t p e r Pa g e * 1 . 4
s iz e = D
p a p e r C o s t p e r Pa g e
=
p a p e r C o s t p e r Pa g e * 1 . 6
What would be behavioral wrt.
Component-level design?
c o lo r is c u s t o m
p a p e r C o s t p e r Pa g e
=
p a p e r C o s t p e r Pa g e * 1 . 1 4
c o lo r is s t a n d a r d
ret urns
( p a p e r C o s t p e r Pa g e )
77
Statechart
b eh av io r w it h in t h e
s t at e b u ild in g Jo b Dat a
d at aIn p u t In co m p let e
buildingJ obDat a
ent r y / r eadJ obDat a ( )
ex it / dis play J obDat a ( )
do/ c hec k Cons is t enc y ( )
i n c l u d e / d a t a In p u t
d at aIn p u t Co m p let ed [ all d at a
it em s co n sist en t ] / d isp layUserOp t io n s
c om put ingJ obCos t
ent r y / c om put eJ ob
ex it / s av e t ot alJ obCos t
What is this about wrt.
Component-level design?
j o b Co st A ccep t ed [ cu st o m er is au t h o riz ed ] /
g et Elect ro n icS ig n at u re
f or m ingJ ob
ent r y / buildJ ob
e x i t / s a v e W On u m b e r
do/
How does this differ from AD wrt.
Component-level design?
s ubm it t ingJ ob
ent r y / s ubm it J ob
ex it / init iat eJ ob
d o / p l a c e o n J o b Qu e u e
j o b S u b m it t ed [ all au t h o riz at io n s acq u ired ] /
p rin t W o rk Ord er
78
Collaboration Diagram
:ProductionJob
1: buildJob
( WOnumber
)
2: submitJob
( WOnumber
)
What is this about wrt.
Component-level design?
:WorkOrder
: JobQueue
79
Refactoring
co m p ut eJo b
Pr int Jo b
init iat eJ o b
W o r kO r d er
< < int er f ace> >
init iat eJo b
ap p ro p riat e at t rib u t e s
g et Jo b Descr iip t io n
b uild W o r kO r d er ( )
b uild Jo b
p assJ o b T o P ro d u c t io n ( )
Pr o d uct io nJo b
sub m it Jo b
Jo b Q ueue
ap p ro p riat e at t rib u t e s
check Pr io r it y ( )
80
Algorithm Design
0 the closest design activity to coding
0 the approach:
0 review the design description for the
component
0 use stepwise refinement to develop
algorithm
0 use structured programming to implement
procedural logic
0 use ‘formal methods’ to prove logic
81
Stepwise Refinement
Recall:
open
walk to door;
reach for knob;
open door;
repeat until door opens
turn knob clockwise;
walk through; if knob doesn't turn, then
close door.
take key out;
find correct key;
insert in lock;
endif
pull/push door
move out of way;
end repeat
82
Algorithm Design Model
0 represents the algorithm at a level of detail
that can be reviewed for quality
0 options:
At which level?
Component or Class?
0 graphical (e.g. flowchart, box diagram)
0 pseudo code (e.g., PDL) ... choice of many
0 programming language(?)
0 decision table
0 conduct walkthrough to assess quality
At which level?
83
Structured Programming
for Procedural Design
0 uses a limited set of logical constructs:
0 Sequence
“go-to” considered ???
0 Conditional — if-then-else, select-case
0 Loops — do-while, repeat until
0 leads to more readable, testable code
0 can be used in conjunction with ‘proof of
correctness’
What’s more to Structured Programming than the above?
84
A Structured Procedural Design
add a condition Z,
if true, exit the program
a
x1
b
x2
x3
d
f
e
c
Can you add something to
make this “unstructured??
x4
g
x5
85
Decision Tables:
Another Ambiguity Test
 Natural Language
“The system shall report to the operator all faults that originate in
critical functions or that occur during execution of a critical
sequence and for which there is no fault recovery response.”
(adapted from the specifications for the international space station)
 A decision table
originate in critical functions
F
T
F
T
F
T
F
T
Occur during critical sequence
F
F
T
T
F
F
T
T
No fault recovery response
F
F
F
F
T
T
T
T
Report to operator???
86
Decision Table
R u le s
C o n d it io n s
r e g u lar cu st o m e r
1
T
2
3
4
T
T
g o ld cu st o m e r
F
6
T
silv e r cu st o m e r
sp e cial d isco u n t
5
T
F
T
T
T
F
T
R u le s
n o d isco u n t
ap p ly 8 p e r c e n t d isc o u n t
ap p ly 1 5 p e r ce n t d is co u n t
ap p ly ad d it io n al x p e r c e n t d isc o u n t
87
Program Design Language (PDL)
if condition x
then process a;
else process b;
endif
if-then-else
PDL
easy to combine with source code
machine readable, no need for graphics input
graphics can be generated from PDL
enables declaration of data as well as procedure
easier to maintain
88
Interface Design
Easy to learn?
Easy to use?
Easy to understand?
Typical Design Errors
lack of consistency
too much memorization
no guidance / help
no context sensitivity
poor response
Arcane/unfriendly
Any examples?
How about your remote controls?
How about fighter airplanes?
How are Windows OS and MS applications?
How about UTD web sites?
Vending machines?
89
Golden Rules
• Place the user in control
instead of ?
• Reduce the user’s memory load dos vs. windows?
• Make the interface consistent for the user
…but, who’s the user?
Should the user work with the designer, then, during UI
design?
90
Place the User in Control
0 Define interaction modes in a way that does not force
a user into unnecessary or undesired actions.
0 Allow user interaction to be interruptible and
undoable.
0 Streamline interaction as skill levels advance and
allow the interaction to be customized.
linear text
vs. pie chart?
0 Design for direct interaction with objects that appear
on the screen.
how? any examples?
91
Reduce the User’s Memory Load
0 Reduce demand on short-term memory. how
many?
0 Establish meaningful defaults.
0 Define shortcuts that are intuitive.
0 The visual layout of the interface should be
based on a real world metaphor.
0 Disclose information in a progressive fashion.
92
Make the Interface Consistent
0 Allow the user to put the current task into a
meaningful context.
0 Maintain consistency across a family of
applications.
0 If past interactive models have created user
expectations, do not make changes unless
there is a compelling reason to do so.
93
User Interface Design Process
94
Interface Analysis
0 Interface analysis means understanding
0 (1) the users who will interact with the
system through the interface;
0 (2) the tasks that end-users must perform
to do their work,
0 (3) the content that is presented as part of
the interface
0 (4) the environment in which these tasks
will be conducted
95
User Analysis
0 Are users trained professionals, technician, clerical, or
manufacturing workers?
0 Are the users capable of learning from written
materials or have they expressed a desire for
classroom training?
0 Are users expert typists or keyboard phobic?
0 What is the age range, gender, primary spoken
language of the user community?
0 Is the software to be an integral part of the work
users do or will it be used only occasionally?
0 Are users experts in the subject matter that is
addressed by the system?
96
Task Analysis and Modeling
0 Answers the following questions …
0 What work will the user perform in specific circumstances?
0 What tasks and subtasks will be performed as the user does the
work?
0 What specific problem domain objects will the user manipulate as
work is performed?
0 What is the sequence of work tasks—the workflow?
0
0
0
0
Use-cases define basic interaction
Task elaboration refines interactive tasks
Object elaboration identifies interface objects (classes)
Workflow analysis defines how a work process is completed
when several people (and roles) are involved
97
Swimlane Diagram
p at ien t
r e q u e s t s t h at a
p r e s cr ip t io n b e r e f ille d
p h arm acis t
p h ys ic ian
d e t e r m in e s s t at u s o f
p r e s cr ip t io n
n o r e f ills
r e m ain in g
r e f ills
r e m ain in g
ch e c ks in v e n t o r y f o r
ch e ck s p at ie n t
r e co r d s
ap p r o v e s r e f ill
r e f ill n o t
allo w e d
r e f ill o r alt e r n at iv e
e v alu at e s alt e r n at iv e
m e d icat io n
r e c e iv e s o u t o f st o c k
o u t o f st o ck
n o t if ic at io n
a lt e r n a t iv e
a v a ila b le
in st o ck
r e c e iv e s t im e / d at e
none
t o p ic k u p
p ic k s u p
p r e s c r ip t io n
f ills
p r e s c r ip t io n
What kind of diagram is this?
What does this have to do with UI design?
r e c e iv e s r e q u e st t o
c o n t ac t p h y s ic ian
98
Fig u re 1 2 . 2
S w im lan e d iag ram f o r p res c rip t io n ref ill f u n ct io n
Analysis of Display Content
0 Are different types of data assigned to consistent
geographic locations on the screen (e.g., photos
always appear in the upper right hand corner)?
0 Can the user customize the screen location for
content?
0 Will graphical output be scaled to fit within the
bounds of the display device that is used?
0 How will color to be used to enhance understanding?
0 How will error messages and warning be presented to
the user?
99
Descargar

Transparency Masters for Software Engineering: A