Intro to Software Engineering - Software Design

Software design
McGill ECSE 321
Intro to Software Engineering
Radu Negulescu
Fall 2003

McGill University ECSE 321 © 2003 Radu Negulescu
Introduction to Software Engineering Software design—Slide 2
About this module
Software should be designed not just for performance, but also for
maintainability! Why?
• Save on maintenance costs
Post-release defect removal
Minor adjustments
• Save on verification costs
Higher pre-release fault detection and removal rate
• Save on development costs
Lower fault injection rate
• Facilitate teamwork
Software that is more maintainable is also easier to understand
Design for maintainability requires special techniques
• Message of the textbook’s cover picture?

Basic concept: modularity
A software system should be split into modules
• To facilitate future change
By minimizing the scope of change
• To avoid need for future change
By containing change within isolated modules
• To reduce development time and effort
By simplifying the system
By postponing design decisions until optimal time, and avoiding some
expensive optimizations
By allowing comprehension and reasoning on modules and interfaces

Modularity
Two main criteria:
• Cohesion: a measure of tightness of relationships within a module
• Coupling: a measure of tightness of relationships among modules
Tradeoff:
• Strong cohesion:
Focused modules
More granularity
• Loose coupling:
Isolated modules
Less granularity (to avoid split dependencies)
• Optimum: around 7+-2 modules at each level of abstraction
This holds for large modules (subsystems) and small modules (individual
objects or routines) alike
This is just an estimate, not an absolute rule

Cohesion
“Single-minded functionality”: operations in a module should be strongly
related
Types of cohesion:
(HIGH)
• Functional: perform one function only
• Communicational: use the same data
• Sequential: an incomplete sequence of causally-related actions
• Procedural: sequence of non-causally-related actions
• Temporal: actions that are performed at the same time
• Logical: decision branches
• Coincidental: no discernable relationship
(LOW)

Strong cohesion
Heuristics
• Partition the system according to dependency clusters
• Isolate presentation, data management, and processing
MVC architectures
• Isolate control from work
Focus on control-only or work-only
High-cohesion “control-only” modules
Dispatching events
Startup and shutdown routines (delegate the individual tasks)
• Isolate main functionality from auxiliary functionality
Exception throwing
Garbage collection
• A complex name usually indicates poor cohesion
Split “getAndSet” routines

Example of strong cohesion
From [BD]:
Alternative
Decision
Criterion
subtasks
*
SubTask
ActionItem
DesignProblem
Task
assesses
solvableBy
resolvedBy
based-on
* * *
implementedBy
DecisionSubsystem
RationaleSubsystem
PlanningSubsystem

Decoupling
“Aversion to interaction”: different modules should be detached
Types of coupling:
• Simple-data ("normal"): non-structured parameter list
• Data-structure ("stamp"): structured parameter
• Control: select a callee task by a flag parameter
Logical cohesion
• External: the program is tied to a particular device or environment
=> non-portable
• Global-data ("common"): two routines access the same global data
At least make it read-only
• Pathological ("content"): use internal data of a different module
E.g. via pointers

Loose coupling
Heuristics:
• Small interfaces: few parameters
• Adapted interfaces: convenient for the callee
• Flexible interfaces: convenient for many callers
Orthogonality
• Visible interfaces: no direct access to protected data
• Avoid pathological coupling: pass parameters through interfaces
float[][] A;
x = det(A);
• Avoid stamp coupling: decompose bundles of parameters into basic
types or very-high-cohesion parameters (e.g. events)
• Avoid external coupling: use IDEs that produce portable code
• Avoid global-data coupling: In object-oriented programs, use “get”
and “set” methods to read and modify object attributes

Example of loose coupling
Adapted from [BD]: change from binary tree to linked list
• Parse tree for a + b + c
add1:Node
add2:Node
c:Nodeb:Node
a:Node
add:Node
c:Nodeb:Nodea:Node
Sharing through attributes
class Node {
Node left;
Node right;
String name;
}
Sharing through operations
class Node {
Enumeration getArguments();
String getName();
}
Sharing through attributes
class Node {
Node next;
String name;
}
Sharing through operations
class Node {
Enumeration getArguments();
String getName();
}

Example of bad modularity
/* If 'direction' is 0, input n rows
into array 'lines';
otherwise output n rows from array 'lines'.
Pre: 0 <= n <= length(lines).
*/
in_out (
int n, /* number of rows, input or output */
int direction /* control flag: 0 = in, 1 = out */
) {
int i;
for (i = 0; i < n; i ++) {
if (direction == 0) {
read one input row into lines[i];
} else {
write lines[i];
}
}
}
/* Read n lines of input.
Output the lines in sorted order.
Pre: 0 <= n <= length(lines).
*/
input_sort_echo(
int n /* number of rows to be sorted */
) {
int i, j;
in_out(n, 0);
for (i = 0; i < n - 1; i ++) {
for (j = i + 1; j < n; j ++) {
if (lines[j] <= lines[i] alphabetically) {
copy string lines[j] into string temp;
copy string lines[i] into string lines[j];
copy string temp into string lines[i];
}
}
}
in_out(n, 1);
}

Improving modularity
Global-data coupling:
• Both routines access array lines
• Fix: the access to array lines and string temp can be made explicit in
the routine interfaces
Logical cohesion:
• The same routine (in_out) performs unrelated operations
• Fix: split into an input routine and an output routine
Communicational or temporal cohesion:
• The same routine (input_sort_echo) controls the flow and does the
sorting
• Fix: call sorting as a sub-routine

Example of improved modularity
/* Input n rows to 'lines';
Pre: 0 <= n <= length(lines). */
in(
int n, /* number of rows to be input */
StringArray lines /* storage */
) {
int i;
for (i = 0; i < n; i ++) {
input lines[i]; /* read one row */
}
}
...
sort(
StringArray lines /*
) { ...
...
out(
StringArray lines /*
) {...
/* Read n rows and output them sorted.
Pre: n >= 0
*/
input_sort_echo(
int n /* number of rows to handle */
) {
Declare and allocate StringArray lines;
in(n, lines);
sort(n, lines);
out(n, lines);
}

Design process
Design: blackbox model full-detail (clearbox, whitebox, glassbox)
• Choose among several alternatives
Consider solutions permitted by the analysis model
Heuristics, patterns
Constraints, invariants
Optimize design goals tradeoffs
Select and prioritize goals: maintainability, usability, performance, etc.
• Iterate through the design
Why?
Brainstorming and consolidation
Prototypes to clear out technical risks
Several levels of abstraction
Several viewpoints, design goals
Fixing defects
Know where to stop
Review criteria

Overview of software design
System-level
• Using the analysis model as a starting point, take high-level decisions
to optimize the selected design goals
Object-level
• “Close the gap” between the architecture model and the deployment
platform
Detailed
• Organize and build code in a way that supports change and reasoning
Specialized design
• UI design
• Function-oriented design
• Real-time, etc.

System-level design
System-level design typically comprises the following activities:
• Identifying design goals and constraints
• Defining the architecture
Decomposing the system into subsystems
Selecting system-wide conventions and policies:
Persistency
Security
Global control flow
Boundary conditions: start-up, shut-down, error handling
• Selecting reusable components, libraries, etc.
• Mapping to hardware

Object design
The following activities are typically performed at this level:
• Identifying design objects: implementation-specific classes
• Service specification: precisely describe interfaces
• Component selection: find pre-made parts that are suitable for the
functionality of the system
• Object model restructuring: optimize maintainability
Reduce multiplicity
Implement binary associations as references
Merge similar classes
Collapse trivial classes into attributes
Split complex classes
• Object model optimization: optimize performance
Use different algorithms / data structures
Add or remove redundant associations
Add derived attributes
“Open up” the architecture

Design goals
First thing: determine goals and priorities
• Include viewpoints of several stakeholders
• See [BD, sect.6.4.2] for a comprehensive list of software design goals
• Relative importance varies depending on the nature of the application

Design goals
End-user / customer / sponsor Developer / maintainer
scope x
low cost/effort x x
low dev. time x x
low defect rate x x
modifiability x
comprehensibility x x
reliability x
robustness x
user-friendliness x
documentation x x
reusability x
adaptability x
portability x
backward compatibility x
performance x
memory efficiency x

Performance measures
Running time is not a single, well-defined measure
• Consider all input data and internal non-determinism
• Worst-case: maximum value
E.g. car airbag controller: worst-case is critical
Polling: time = (#sensors) * (time per sensor) + (alarm time)
Interrupts: time = (interrupt path length) * (hub delay) + (alarm time)
• Average-case : weighted by operation frequency (operational profile)
E.g. text editor: average-case is more important than worst-case
E.g. videophone image compression: both worst-case and average-case are
important
• Amortized: mean taken over an operating cycle
E.g. the average number of bit flips in an n-bit number
Answer: 2! (Why?)

Performance measures
Many performance measures
• Latency vs. throughput
E.g., an IDE that does background compilation performs more work to
improve average latency
E.g., a web service might have a fixed limit on the response time (latency),
and optimize the maximum number of simultaneous requests (throughput)
• Memory requirements
Data storage: scalability, garbage collection
• Number of expensive operations (function calls, multiplications, etc.)
• Number of accesses to communications, external storage, or I/O
resources
E.g. a trip planner might allow increased response time to minimize wireless
communication time

Design tradeoffs
Typical design tradeoffs:
• Rapid development vs. scope
• Performance vs. maintainability
Orders of growth
• Performance vs. portability
• Backward compatibility vs. comprehensibility
• Cost, delivery time vs. robustness, reusability
Not to be confused with cost vs. other quality parameters
• Space vs. speed
Why operating systems, IDEs, etc. will fill up hard drives of any sizes?
Not easily traded:
• Quality vs. effort
Low defect rate, maintainability, comprehensibility, documentation
Early in the project: non-tradeable
Late in the project: tradeable to a small extent
• Delivery time vs. staffing
Only early in the project
Brooks’ law: adding people to a late project only makes it later

Software architecture
Architectural design should address:
• Subsystem decomposition
• System-wide policies
Data organization
Control flow
Communication protocols
Error handling
Mapping to hardware
Security
• NOT development methodology issues, such as object-orientation vs.
function-orientation

Basic definitions
Subsystems
• Parts of a system
• Can be developed and changed independently (more or less)
• Example: UI evolves independently from business logic
Services
• A service provided by a subsystem = a set of operations of that
subsystem that share a common purpose
• Examples: download, upload, notification, management, …
Interfaces
• An interface of a subsystem = a black-box view of that subsystem
As seen by an actor or by another subsystem
• API: operations, signatures, and specifications
Signature = parameter types, return type
Example: doGet method of HttpServlet class
SURWHFWHG YRLGSURWHFWHG YRLGSURWHFWHG YRLGSURWHFWHG YRLG GR*HWGR*HWGR*HWGR*HW+WWS6HUYOHW5HTXHVW+WWS6HUYOHW5HTXHVW+WWS6HUYOHW5HTXHVW+WWS6HUYOHW5HTXHVW UHTUHTUHTUHT +WWS6HUYOHW5HVSRQVH+WWS6HUYOHW5HVSRQVH+WWS6HUYOHW5HVSRQVH+WWS6HUYOHW5HVSRQVH UHVSUHVSUHVSUHVS

WKURZV
6HUYOHW([FHSWLRQ6HUYOHW([FHSWLRQ6HUYOHW([FHSWLRQ6HUYOHW([FHSWLRQ ,2([FHSWLRQ,2([FHSWLRQ,2([FHSWLRQ,2([FHSWLRQ

Defining the architecture
Decomposition into subsystems
• Heuristics
Use variants of Abbott’s lexical rules: nouns, verbs
Identify groups of objects involved in use cases
Encapsulate functionally related classes - Facade pattern
Isolate scope overlaps among use cases
Create dedicated subsystems for moving data among subsystems
Create a separate subsystem for the user interface
Encapsulate legacy code - Adaptor pattern

Layers and partitions
Different ways of decomposing the system:
• Layering: each subsystem provides a level of abstraction
Closed architecture: each layer can access services from the layer
immediately below it. E.g. ISO OSI
Open architecture: each layer can access services from any layers below it
E.g. Motif toolkit for X11
• Partitioning: peer subsystems with as few dependencies as possible
• Not a clear distinction between layering and partitioning
A B C
D E
F G H

Common architectures
Design the data first, then the control
• During analysis, may assume objects run whenever needed
• During design, the object behavior should be determined so that the
object does indeed run whenever needed
Types of data organization schemes:
• Repository
• Model-view-controller (“architecture”, “framework”, “pattern”)
• Client/server
• Peer-to-peer
• Pipe-and-filter / data flow
Types of control flow:
• Centralized
• Event-driven
• Thread-based

Repository architecture
Subsystems interact by sharing data in a central repository
The repository may also implement control flow
• Serialize concurrent accesses of processing subsystems
• Activate subsystems depending on state of data (“blackboard”)
E.g. DBMS, compilers [BD], various CAD tools
LexicalAnalyzer
SyntacticAnalyzer
SemanticAnalyzer
CodeGenerator
SourceLevelDebugger SyntacticEditor
ParseTree SymbolTable
Compiler
Repository
Optimizer

Repository architecture
Pros:
• Decoupled subsystems; easy to add new ones
Cons:
• Repository may become a bottleneck
• Strong coupling between each subsystem and the repository

Model-view-controller
A.k.a. MVC
Partition data representation (model), presentation (view), and control
• One of the first design patterns: model state updates are reported to
all views
Refined to “observer pattern” (will see later)
May use “Listener” objects in Java
• Special case of the repository architecture, if the model is considered
to be the data repository
Controller
Model
subscriber
notifier
initiator
*
repository1
1
*
View

Model-view-controller
Pros:
• Allows independent change of model, view, and controller
• Allows subscription at runtime
• Isolates variability, as the views are less stable than the model
Cons:
• The model may become a performance bottleneck

Client-server
Servers provide services to clients
• E.g. central database
• E.g. communication systems
Web server; DNS
Mail server; news server; ...
• Suitable for distributed systems that process large amounts of data
Why?

Client-server
Three-tiered architecture:
Browser
WebServer
Servlet
DataBase
JDBC
http request
service
query
SQL query table
result set
string
web page

Peer-to-peer
Peer-to-peer:
• Generalize client-server systems
• Each subsystem can request and provide services
E.g. a database that can also notify the application
• More difficult to design
Many possible interleavings of messages/service requests
Many possible modes of failure in concurrent/distributed systems
Deadlock
Unfairness/starvation
Livelock/divergence
...?
Process1
Resource1
Resource2
Process2
1:req
5:req 3:req
4:ack
2:ack
6:req

Pipe-and-filter
Filters: processing subsystems
• Executing concurrently
Pipes: associations between filters
• Data transfer
• Synchronization
E.g. UNIX shell [BD]
ps grep sort more

Centralized control
Two types
• Call-return (procedure-driven): sequential subroutine calls
Rigid = easy to debug, but locks resources
• Manager: one component is designated to control a concurrent
system
E.g.: a repository database that can signal changes
Flexible = Better real-time response, efficiency
More difficult to design = interleaving, modes of failure

Event-driven control
Two types
• Interrupt-driven
Interrupts are serviced immediately (according to priority)
Offers execution time bounds, hence good for real-time systems
• Broadcast
Events are broadcast to several listeners, who will handle them when they
can
Better modularity, but no time bounds
Usually combined with the MVC architecture

Broadcast events example
Events are key to implementing graphical user interfaces
• The broadcast method of the source may be invoked automatically
upon occurrence of an event
Example: ActionEvents are emitted by Button objects
addActionListener(
ActionListener)
removeActionListener(
ActionListener)
...
ActionListener
actionPerformed(
ActionEvent)
MyListener
actionPerformed(
ActionEvent e)
ActionEvent
getActionCommand()
getSource()
e
* 1
1
*
1 *
Button

Broadcast events example
Example: Mouse events are emitted by a Component object
• Applets and other subclasses of Component inherit its methods
• Mouse movement events are sent to a different listener
(MouseMotionListener)
MouseListener
mouseClicked(
MouseEvent)
mousePressed(
MouseEvent)
...
MyListener
MouseEvent
Point getPoint()
setPoint(Point)
* 1
1
*
1 *
mouseClicked(
MouseEvent)
mousePressed(
MouseEvent)
...
addMouseListener(
MouseListener)
addMouseMotionListener(
MouseMotionListener)
…
Component
...
Applet
1 *
MouseMotionListener

Using events
Events ensure communication between source and listener while
effectively decoupling the functionality of source and listener
• None needs to know the details of the other
• The connection can be made and cancelled dynamically
Event queues may be added to further decouple the timing of source and
listener
• Source and listener may operate at different rates

Thread-based control
Thread-based
• Several streams of execution that respond to different users, different
stimuli, different events, etc.
• Example: servlets
Service method
• Issue: mutual exclusion
Communication through shared variables
“synchronize”

Intro to Software Engineering - Software Design

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Intro to Software Engineering - Software Design

Semelhante a Intro to Software Engineering - Software Design (20)

Mais de Radu_Negulescu

Mais de Radu_Negulescu (14)

Último

Último (20)

Intro to Software Engineering - Software Design