se ppt

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

1

2

3

Version 1

Version 1

Version 25

Requirements

1

2

3

4 6

7 Version 3

4

Requirements

1

2

3

Version 2 5

Version 1

4

intermediate design

finalproduct

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 compilermodule COMPILERexports 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

implementationA 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

Other modulesmodule MAINuses ANALYZER, CODE_GENERATORexports procedure MINI (PROG: in file of char;

CODE: out file of char);…end MAIN

module ANALYZERuses SYMBOL_TABLE, ABSTRACT_TREE_HANDLERexports 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

module CODE_GENERATORuses SYMBOL_TABLE, ABSTRACT_TREE_HANDLERexports 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

X

Y

Z A B

R T Module Module

Module

Module

Module

C

X's decomposition

X

Y

Z B C

R T Module Module

Module

Module

Module

A

K

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 thedata 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_CARSuses CARSexports

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. . .

exportsprocedure 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

• Instantiationmodule 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 top-down

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 exampleclass EMPLOYEE exports

function FIRST_NAME(): string_of_char; function LAST_NAME(): string_of_char; function AGE(): natural; function WHERE(): SITE; function SALARY: MONEY; procedure HIRE (FIRST_N: string_of_char;

LAST_N: string_of_char; INIT_SALARY: MONEY);

Initializes a new EMPLOYEE, assigning a new identifier. procedure FIRE(); procedure ASSIGN (S: SITE); An employee cannot be assigned to a SITE if already assigned to it (i.e., WHERE must be different from S). It is the client’s responsibility to ensure this. The effect is to delete the employee from those in WHERE, add the employee to those in S, generate a new id card with security code to access the site overnight, and update WHERE.

end EMPLOYEE

class ADMINISTRATIVE_STAFF inherits EMPLOYEE exports

procedure DO_THIS (F: FOLDER); This is an additional operation that is specific to administrators; other operations may also be added.

end ADMINISTRATIVE_STAFF class TECHNICAL_STAFF inherits EMPLOYEE exports

function GET_SKILL(): SKILL; procedure DEF_SKILL (SK: SKILL); These are additional operations that are specific to technicians; other operations may also be added.

end TECHNICAL_STAFF

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

TECHNICAL_STAFF ADMINISTRATIVE_STAFF

UML associations

• Associations are relations that the implementation is required to support

• Can have multiplicity constraints

TECHNICAL

_STAFF

MANAGER

PROJECT * 1 project_member

1

1..* manages

Aggregation

• Defines a PART_OF relationDiffers from IS_COMPOSED_OF

Here TRANGLE has its own methods

It implicitly uses POINT to define

its data attributes

TRIANGLE

POINT

1

3

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

event based

Event detection by sensor or mesg arrival

Blackboard

comm. Between several Sub-sys

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"

Product

Process

Informal Requirements

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"

Product

Process

Informal Requirements

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 Document1. Definition of the problem2. Alternative solutions and their expected benefits3. 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 studyhow 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 studythe 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

Feasibility study

Requirements

Design

Coding and module testing

Integration and system testing

Delivery, deployment, and maintenance

A waterfall model

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-STD-2167)

Critical evaluation of the waterfall model

+ sw process subject to discipline, planning, and management

+ postpone implementation to after understanding objectives

– linear, rigid, monolithicno feedbackno parallelisma single delivery date

Feasibility study

Requirements

Design

Coding and module testing

Integration and system testing

Delivery, deployment, and maintenance

Waterfall with feedback

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

Requirements analysis and specification

OptimizationRequirements

Formal specifications

Verification Tuning

Lower level specifications

Recording of developmental history

Reusable components

Decisions & rationale

Transformation model

Spiral modelB. 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