Design and Software Architecture

Outline
What is design How can a system be decomposed into modules What is a module s 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

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 the activity

Two meanings of "design activity in our context

Activity that acts as a bridge between requirements and 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 to understand and evolve

The sw design activity

Defined as system decomposition into modules Produces a Software Design Document
describes system decomposition into modules

Often a software architecture is produced prior to a software design

Software architecture
Shows gross structure and organization of the system to be defined Its description includes description of
main components of a system relationships among those components Basis for decomposition into its components constraints that must be respected by any design of the components

Guides the development of the design

Two important goals

Design for change
designers tend to concentrate on current needs special effort needed to anticipate likely changes

Product families
think of the current system under design as a member of a program family

Sample likely changes? (1)

Algorithms
e.g., replace inefficient sorting algorithm with a more efficient one

Change of data representation

e.g., array vs linked list }17% of maintenance costs attributed to data representation changes (Lientz and Swanson, 1980) Thereby changes in methods that handles the data Faculty profile example

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)

Product families
In some cases, changes consists of building new versions. Set of these versions constitutes a family Newer version supersedes older one (removes erros, add new features) Reason for treating diff. versions of a s/w product as one family
They have much common, only partially diff. Share same architecture Common architecture should be designed

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)

Design goal for family

Design the whole family as one system, not each individual member of the family separately

Sequential completion: the wrong way

Design first member of product family Modify existing software to get next member products

Sequential completion: a graphical view

Requirements Requirements 1 Requirements 1 1
intermediate design

2 2 Version 1 3 3 Version 1 Version 2 5 4 4 Version 2 5 Version 1 4

2
final product

Version 3

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

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 modules may use

Questions
How to define the structure of a modular system? What are the desirable properties of that structure?

TDN & GDN

Illustrate how a notation may help in documenting design Illustrate what a generic notation may look like Are representative of many proposed notations TDN inherits from modern languages, like Java, Ada,

An example
module X uses Y, Z exports var A : integer; type B : array (1. .10) of real; procedure C ( D: in out B; E: in integer; F: in real); Here is an optional natural-language description of what A, B, and C actually are, along with possible constraints or properties that clients need to know; for example, we might specify that objects of type B sent to procedure C should be initialized by the client and should never contain all zeroes. implementation If needed, here are general comments about the rationale of the modularization, hints on the implementation, etc. is composed of R, T end X

Comments in TDN
May be used to specify the protocol to be followed by the clients so that exported services are correctly provided
e.g., a certain operation which does the initialization of the module should be called before any other operation e.g., an insert operation cannot be called if the table is full

Example (cont.)
module R uses Y exports var K : record . . . end; type B : array (1. .10) of real; procedure C (D: in out B; E: in integer; F: in real); implementation
. . .

end R module T uses Y, Z, R exports var A : integer; implementation

. . .

end T

Benefits
Notation helps describe a design precisely Design can be assessed for consistency
having defined module X, modules R and T must be defined eventually
if not incompleteness

R, T replace X
either one or both must use Y, Z

Example: a compiler
module COMPILER exports procedure MINI (PROG: in file of char; CODE: out file of char); MINI is called to compile the program stored in PROG and produce the object code in file CODE implementation A conventional compiler implementation. ANALYZER performs both lexical and syntactic analysis and produces an abstract tree, as well as entries in the symbol table; CODE_GENERATOR generates code starting from the abstract tree and information stored in the symbol table. MAIN acts as a job coordinator. is composed of ANALYZER, SYMBOL_TABLE, ABSTRACT_TREE_HANDLER, CODE_GENERATOR, MAIN end COMPILER

module MAIN uses ANALYZER, CODE_GENERATOR exports procedure MINI (PROG: in file of char; CODE: out file of char); end MAIN module ANALYZER uses SYMBOL_TABLE, ABSTRACT_TREE_HANDLER exports procedure ANALYZE (SOURCE: in file of char); SOURCE is analyzed; an abstract tree is produced by using the services provided by the tree handler, and recognized entities, with their attributes, are stored in the symbol table. ... end ANALYZER

Other modules

Other modules
module CODE_GENERATOR uses SYMBOL_TABLE, ABSTRACT_TREE_HANDLER exports procedure CODE (OBJECT: out file of char); The abstract tree is traversed by using the operations exported by the ABSTRACT_TREE_HANDLER and accessing the information stored in the symbol table in order to generate code in the output file. end CODE_GENERATOR

GDN description of module X

M odu le Y M odu le X

M odu le R

M odu le T

C M odu le Z

X's decomposition
M o d u le Y

M o d u le X K M o d u le R M o d u le T

A M o d u le Z

Categories of modules
Functional modules
traditional form of modularization provide a procedural abstraction encapsulate an algorithm
e.g. sorting module, fast Fourier transform module,

Categories of modules (cont.)

Libraries
a group of related procedural abstractions
e.g., mathematical libraries
implemented by routines of programming languages

Common pools of data

data shared by different modules
e.g., configuration constants
the COMMON FORTRAN construct

Categories of modules (cont.)

Abstract objects
Objects manipulated via interface functions Data structure hidden to clients

Abstract data types

Many instances of abstract objects may be generated

Abstract data types (ADTs)

A stack ADT
module STACK_HANDLER exports type STACK = ?; This is an abstract data-type module; the data structure is a secret hidden in the implementation part. procedure PUSH (S: in out STACK ; VAL: in integer); procedure POP (S: in out STACK ; VAL: out integer); function EMPTY (S: in STACK) : BOOLEAN; end STACK_HANDLER
. . .

indicates that details of the data structure are hidden to clients

ADTs
Correspond to Java and C++ classes Concept may also be implemented by Ada private types and Modula-2 opaque types May add notational details to specify if certain built-in operations are available by default on instance objects of the ADT
e.g., type A_TYPE: ? (:=, =) indicates that assignment and equality check are available

An example: simulation of a gas station

module FIFO_CARS uses CARS exports type QUEUE : ?; procedure ENQUEUE (Q: in out QUEUE ; C: in CARS); procedure DEQUEUE (Q: in out QUEUE ; C: out CARS); function IS_EMPTY (Q: in QUEUE) : BOOLEAN; function LENGTH (Q: in QUEUE) : NATURAL; procedure MERGE (Q1, Q2 : in QUEUE ; Q : out QUEUE); This is an abstract data-type module representing queues of cars, handled in a strict FIFO way; queues are not assignable or checkable for equality, since := and = are not exported. end FIFO_CARS

Generic modules (templates)

They are parametric wrt a type
generic module GENERIC_STACK_2 ... exports procedure PUSH (VAL : in T); procedure POP_2 (VAL1, VAL2 : out T); end GENERIC_STACK_2

Instantiation
Possible syntax:
module INTEGER_STACK_2 is GENERIC_STACK_2 (INTEGER)

More on genericity
How to specify that besides a type also an operation must be provided as a parameter
generic module M (T) with OP(T) uses ... ... end M

Instantiation
module M_A_TYPE is M(A_TYPE) PROC(M_A_TYPE)

Specific techniques for design for change

Use of configuration constants
factoring constant values into symbolic constants is a common implementation practice
e.g., #define in C #define MaxSpeed 5600;

Specific techniques for design for change (cont.)

Conditional compilation
...source fragment common to all versions... # ifdef hardware-1 ...source fragment for hardware 1 ... # endif #ifdef hardware-2 ...source fragment for hardware 2 ... # endif

Software generation
e.g., compiler compilers (yacc, interface prototyping tools)

Stepwise refinement
A systematic, iterative program design technique that unfortunately may lead to software that is hard to evolve At each step, problem P decomposed into
sequence of subproblems: P1; P2; Pn a selection: if (cond) then P1 else P2 an iteration: while (cond) do_something

Decomposition tree
Stepwise refinement process may be depicted by a decomposition tree (DT)
root labeled by name of top problem subproblem nodes labeled as children of parent node corresponding to problem children from left to right represent sequential order of execution if and while nodes denoted by suitable decoration

Top-down vs. bottom-up

Information hiding proceeds bottom-up Iterated application of IS_COMPOSED_OF proceeds top-down
stepwise refinement is intrinsically top-down

Which one is best?

in practice, people proceed in both directions
yo-yo design

organizing documentation as a top-down flow may be useful for reading purposes, even if the process followed was not topdown

oop
Generalization and specialization
Is a Has a

Object-oriented design
One kind of module, ADT, called class A class exports operations (procedures) to manipulate instance objects
often called methods

Instance objects accessible via references

Syntactic changes in TDN

No need to export opaque types
class name used to declare objects

If a is a reference to an object
a.op (params);

A further relation: inheritance

ADTs may be organized in a hierarchy Class B may specialize class A
B inherits from A

conversely, A generalizes B A is a superclass of B B is a subclass of A

An example
class E M P LO YE E expo rts func tion FIR S T _N A M E (): string_of_char; func tion LA S T _N A M E (): string_of_char; func tion A G E (): natural; func tion W H E R E (): S IT E ; func tion S A LA R Y : M O N E Y ; proce dure H IR E (FIR S T _N : string_of_char; LA S T _N : string_of_char; IN IT _S A LA R Y : M O N E Y ); Initializes a n ew E M P LO Y E E , assigning a new identifier. proce dure FIR E (); proce dure A S S IG N (S : S IT E ); A n em ployee cannot be assigned to a S ITE if already assigned to it (i.e., W H E R E m ust be diffe rent from S ). It is the clients responsibility to ensure this. The effect is to delete the em ployee from those in W H E R E , add the em ployee to those in S , generate a new id card w ith security cod e to access the site overnight, and update W H E R E . end E M P LO YE E

c la ss A D M IN IS T R A T IV E _ S T A F F in h e rits E M P L O Y E E e x p o rts p ro c e d u re D O _ T H IS (F : F O LD E R ); T h is is a n a dd ition a l o p e ratio n th a t is sp e cific to a d m in istra to rs ; o th e r op e ra tio n s m a y also be a d d ed . e n d A D M IN IS T R A T IV E _ S T A F F c la ss T E C H N IC A L _S T A F F in h e rits E M P L O Y E E e x p o rts fu n c tio n G E T _ S K ILL (): S K ILL ; p ro c e d u re D E F _ S K IL L (S K : S K IL L ); T h es e a re a dd ition a l o p e ratio n s th a t are sp e cific to te ch n icia n s; o the r o p era tio n s m a y a lso b e ad d e d . e n d T E C H N IC A L _S T A F F

Inheritance
A way of building software incrementally A subclass defines a subtype
subtype is substitutable for parent type

Polymorphism
a variable referring to type A can refer to an object of type B if B is a subclass of A

Dynamic binding
the method invoked through a reference depends on the type of the object associated with the reference at runtime

How can inheritance be represented?

We start introducing the UML notation UML (Unified Modeling Language) is a widely adopted standard notation for representing OO designs We introduce the UML class diagram
classes are described by boxes

UML representation of inheritance

EMPLOYEE

ADMINISTRATIVE_STAFF

TECHNICAL_STAFF

UML associations
Associations are relations that the implementation is required to support Can have multiplicity constraints
TECHNICAL _STAFF * project_member 1..* manages MANAGER 1 1 PROJECT

Aggregation
Defines a PART_OF relation
Differs from IS_COMPOSED_OF Here TRANGLE has its own methods It implicitly uses POINT to define its data attributes
TRIANGLE

1 3 POINT

More on UML
Representation of IS_COMPONENT_OF via the package notation

package_name Class 1 Class 2

Class 3

Software architecture
Describes overall system organization and structure in terms of its major constituents and their interactions Standard architectures can be identified
pipeline blackboard event based (publish-subscribe)

Standard architectures
Pipeline Sub-sys processing elements Blackboard comm. Between several Sub-sys event based Event detection by sensor or mesg arrival

The software production process

Questions
What is the life cycle of a software product? Why do we need software process models? What are the goals of a software process and what makes it different from other industrial processes?

Outline
Traditional answer: "waterfall" lifecycles Flexible, incremental processes Case studies
"synchronize-and-stabilize" (Microsoft) the "open source" development model

Organizing the process

software methodologies the "Unified Process"

Organizing artifacts: configuration management Standards

Life cycle
The life cycle of a software product
from inception of an idea for a product through
requirements gathering and analysis architecture design and specification coding and testing delivery and deployment maintenance and evolution retirement

Software process model

Attempt to organize the software life cycle by
defining activities involved in software production order of activities and their relationships

Goals of a software process

standardization, predictability, productivity, high product quality, ability to plan time and budget requirements

Code&Fix
The earliest approach No distinction between end user & programmer. End user scientist or engineer s/w development activity - Write code Model code & fix Fix it to eliminate any errors that have been detected, to enhance existing functionality, or to add new features Source of difficulties and deficiencies
impossible to predict impossible to manage

 Consequences of growth in h/w capacity Separation between s/w developer & user. E.g. sales agent or personnel admin. Economic, organizational, physiological issues.
Black berry torch ex.

Intolerance of end user.

High quality, reliable s/w

Fields where system failure have sever consequences. Code & fix was inadequate due to
Increased size, difficult to manage Frequent discovery

Models are needed

Symptoms of inadequacy: the software crisis
scheduled time and cost exceeded user expectations not met poor quality

The size and economic value of software applications required appropriate "process models
Cost benefit analysis.

Process model goals

(B. Boehm 1988)
"determine the order of stages involved in software development and evolution, and to establish the transition criteria for progressing from one stage to the next. These include completion criteria for the current stage plus choice criteria and entrance criteria for the next stage. Thus a process model addresses the following software project questions: What shall we do next? How long shall we continue to do it?"

Process as a "black box"

Informal Requirements Process Product

Problems
The assumption is that requirements can be fully understood prior to development Interaction with the customer occurs only at the beginning (requirements) and end (after delivery) Unfortunately the assumption almost never holds

Process as a "white box"

Informal Requirements Process Product

feedback

Advantages
Reduce risks by improving visibility Allow project changes as the project progresses
based on feedback from the customer

The main activities

They must be performed independently of the model The model simply affects the flow among activities

Feasibility study
Why a new project?
cost/benefits tradeoffs buy vs make
Requires to perform preliminary requirements analysis Produces a Feasibility Study Document
1. Definition of the problem 2. Alternative solutions and their expected benefits 3. Required resources, costs, and delivery dates in each proposed alternative solution

Requirements engineering activities

Requirements engineering
Involves
eliciting understanding analyzing specifying

Focus on
what qualities are needed, NOT on how to achieve them

What is needed
Understand interface between the application and the external world Understand the application domain Identify the main stakeholders and understand expectations
different stakeholders have different viewpoints software engineer must integrate and reconcile them

The requirements specification document (1)

Provides a specification for the interface between the application and the external world
defines the qualities to be met

Has its own qualities

understandable, precise, complete, consistent, unambiguous, easily modifiable

The requirements specification document (2)

Must be analyzed and confirmed by the stakeholders
may even include version 0 of user manual

May be accompanied by the system test plan document

The requirements specification document (3)

As any large document, it must be modular
"vertical" modularity
the usual decomposition, which may be hierarchical

"horizontal" modularity
different viewpoints

Defines both functional and non functional requirements

A case study
railway automation
Who are the stakeholders?
management of the train company train drivers and their unions passengers (customers) contractors

Each has different goals

Case study
how to classify requirements
Safety requirements
the probability of accidents should be less than 10-9 per year

Utility requirements
level of usefulness of the system as perceived by the various stakeholders

Case study
the produced document
Introduction: the mission of the system Architecture: the main structure of the system Specific requirements associated with each subsystem
discussion of how the subsystems requirements guarantee that the overall goals are indeed achieved

Software architecture and detailed design activity

The result of this activity is a Design Specification Document Usually follows a company standard, which may include a standard notation, such as UML

Coding and module testing activity

Company wide standards often followed for coding style Module testing
based on black box/white box criteria

Integration and system test activity

These activities may be integrated with coding and module testing Integration may be done incrementally through subsystems
top down vs. bottom up

The last step is system test

may be followed by alpha testing

Delivery, deployment, and maintenance activities

Delivery
real delivery may be preceded by beta testing

Deployment
components allocated on physical architecture

Maintenance
corrective, adaptive, perfective

Maintenance
Requirements errors are main cause of maintenance activities Late discovery of requirements errors causes increased costs

Other software activities

Documentation Verification Management They can be considered as parts of any kind of software related activity

Overview of software process models

Waterfall models (1)

Invented in the late 1950s for large air defense systems, popularized in the 1970s They organize activities in a sequential flow Exist in many variants, all sharing sequential flow style

F easib ility study

A waterfall model

R e quirem e nts

D e sign C o din g an d m o dule testing

Integ ratio n and syste m testing

D e live ry, deploym e nt, a nd m a inten an ce

Waterfall models (2)

Organizations adopting them standardize the outputs of the various phases (deliverables) May also prescribe methods to follow in each phase
organization of methods in frameworks often called methodology

Example: Military Standard (MIL-STD2167)

Critical evaluation of the waterfall model

+ sw process subject to discipline, planning, and management + postpone implementation to after understanding objectives linear, rigid, monolithic
no feedback no parallelism a single delivery date

Waterfall with feedback

Feasibility study R equirem ents

D esign

C oding and m odule testing Integration and system testing D elivery, deploym ent, and m aintenance

Problems with waterfall

Estimates made when limited knowledge available Difficult to gather all requirements once and for all
users may not know what they want requirements cannot be frozen

Evolutionary models
Many variants available Product development evolves through increments
"do it twice" (F. Brooks, 1995) evolutionary prototype

Evolutionary process model (B. Boehm, 1988)

"model whose stages consist of expanding increments of an operational software product, with the direction of evolution being determined by operational experience"

Incremental delivery
Identify self-contained functional units that may be delivered to customers To get early feedback
According to T. Gilb, 1988:
Deliver something to the real user Measure the added value to the user in all critical dimensions Adjust design and objectives

Transformation model
Guided by formal methods Specifications transformed into implementations via transformations Still a theoretical reference model

Transformation model
Decisions & rationale Reusable components

Requirements

Requirements analysis and specification

Formal specifications

Optimization

Lower level specifications

Verification

Tuning

Recording of developmental history

Spiral model
B. Boehm, 1989

Evolution of process models Waterfall documentation driven Evolutionary increment driven Transformation specification driven

A final model assessment(1)

Waterfall
document driven

Transformational
specification driven

Spiral
risk driven

A final model assessment(2)

Flexibility needed to reduce risks
misunderstandings in requirements unacceptable time to market

Waterfall may be useful as a reference structure for documentation

describes the "rationale" a posteriori (Parnas and Clements, 1989)

The process
Planning phase
vision of the product, specification, schedule

Development
team composed of 2 groups
developers and testers (continuous testing)

process prescribes
daily synchronization product stabilization