Software Design Fernando Brito e Abreu (fba@di.fct.unl.pt) - - PDF document

1

Software Design

Fernando Brito e Abreu (fba@di.fct.unl.pt) Universidade Nova de Lisboa (http://www.unl.pt)

QUASAR Research Group (http://ctp.di.fct.unl.pt/QUASAR)

Software Engineering / Fernando Brito e Abreu 2 5-Apr-05

SWEBOK: the 10 Knowledge Areas

Software Requirements Software Design Software Construction Software Testing Software Maintenance Software Configuration Management Software Engineering Management Software Engineering Process Software Engineering Tools and Methods Software Quality

2

Software Engineering / Fernando Brito e Abreu 3 5-Apr-05

Design is …

“the process of defining the architecture,

components, interfaces, and other characteristics of a system or component”

… and “the result of that process.”

[IEEE 610.12-90]

Software Engineering / Fernando Brito e Abreu 4 5-Apr-05

Summary

Software Design Fundamentals Key Issues in Software Design Software Structure and Architecture Design Quality Analysis and Evaluation Software Design Notations Software Design Strategies and Methods

3

Software Engineering / Fernando Brito e Abreu 5 5-Apr-05

Summary

Software Design Fundamentals

• Key Issues in Software Design

Key Issues in Software Design Key Issues in Software Design

• Software Structure and Architecture

Software Structure and Architecture Software Structure and Architecture

• Design Quality Analysis and Evaluation

Design Quality Analysis and Evaluation Design Quality Analysis and Evaluation

• Software Design Notations

Software Design Notations Software Design Notations

• Software Design Strategies and Methods

Software Design Strategies and Methods Software Design Strategies and Methods

Software Engineering / Fernando Brito e Abreu 6 5-Apr-05

Software design is a 2-step process

Architectural design

Architectural design describes how software is

decomposed and organized into components (the software architecture)

[IEEEP1471-00]

Detailed design

Detailed design describes the specific behavior of

those components

4

Software Engineering / Fernando Brito e Abreu 7 5-Apr-05

Important design principles

Abstraction Coupling and cohesion Decomposition and modularization Encapsulation/information hiding Separation of interface and implementation Sufficiency, completeness and primitiveness

Software Engineering / Fernando Brito e Abreu 8 5-Apr-05

Abstraction

… is a concept or idea not associated with any specific instance … is the process of forgetting information so that things that are different can

be treated as if they were the same.

… is the process of combining multiple smaller operations into a single unit

that can be referred to by name.

… is the process of picking out (abstracting) common features of objects and

procedures.

Abstraction can have different flavors: procedural abstraction data abstraction control abstraction Abstraction leads us to different views of a system …

5

Software Engineering / Fernando Brito e Abreu 9 5-Apr-05

Abstraction

Deployment View Process View Design View Implementation View Requirements View

functionality performance scalability throughput system assembly configuration mgmt. system topology distribution delivery installation methods people plans activities control

Software Engineering / Fernando Brito e Abreu 10 5-Apr-05

Coupling and cohesion

Coupling is defined as the strength of the

relationships between modules

High coupling is usually considered harmful

Cohesion is defined by how the elements

making up a module are related

Low cohesion is usually considered harmful

6

Software Engineering / Fernando Brito e Abreu 11 5-Apr-05

Decomposition and modularization

Divide ut regnes ... is a fundamental engineering principle! The “divide-and-conquer” strategy is applied in most industry

fields to deal with complexity, specialization and mass production

This is specially important for breaking large sw products into a

number of smaller independent parts (components)

The decomposition usually aims at placing different functionalities or

responsibilities in different components

Software Engineering / Fernando Brito e Abreu 12 5-Apr-05

Decomposition and modularization

Advantages:

design and develop different parts of the same system by

different people / distinct companies

handle large systems complexity (split, simpler parts, can be

better understood individually)

test systems in a parallel fashion (different people) substitute or repair defective parts of a system without

interfering with other parts

reuse existing parts in different contexts divide the system in configuration units to be put under CM restrict change propagation.

7

Software Engineering / Fernando Brito e Abreu 13 5-Apr-05

Modularity: beware of synonyms!

Categories (Booch) Subsystems (Jacobson) Domains (Page-Jones) Clusters (B. Meyer) Packages (UML) Namespaces (C++) Packages (Java) Units (Delphi) Components ...

All are class aggregates …

Software Engineering / Fernando Brito e Abreu 14 5-Apr-05

Modularity is often not guided by structural criteria!

0 . 1 0 . 2 0 . 3 0 . 4 0 . 5 0 . 6 0 . 7

S p e c if ic a t io n

IM P _ M M F O P T _ M M F

8

Software Engineering / Fernando Brito e Abreu 15 5-Apr-05

Encapsulation / information hiding

Stands for grouping and packaging the elements

and internal details of an abstraction and making those details inaccessible

e.g. C++ include files, Java Interfaces

Software Engineering / Fernando Brito e Abreu 16 5-Apr-05

Separation of interface and implementation

Involves defining a component by specifying a public

interface, known to the clients, separate from the details

• f how the component is realized

e.g. Web services (WSDL)

9

Software Engineering / Fernando Brito e Abreu 17 5-Apr-05

Sufficiency, completeness and primitiveness

A software component should capture all the important

characteristics of an abstraction, and nothing more (aka “separation of concerns”)

e.g. distribution concerns should be treated separately from

security concerns or from transactional concerns

This principle is related with the one of decomposition

and modularization and has given rise to Aspect- Oriented Development

Software Engineering / Fernando Brito e Abreu 18 5-Apr-05

Summary

Software Design Fundamentals Key Issues in Software Design

• Software Structure and Architecture

Software Structure and Architecture Software Structure and Architecture

• Design Quality Analysis and Evaluation

Design Quality Analysis and Evaluation Design Quality Analysis and Evaluation

• Software Design Notations

Software Design Notations Software Design Notations

• Software Design Strategies and Methods

Software Design Strategies and Methods Software Design Strategies and Methods

10

Software Engineering / Fernando Brito e Abreu 19 5-Apr-05

Design Aspects

Some design issues (aka “aspects”) are not

specific to a given application domain

they are “cross-cutting” the system’s functionality

Aspects tend not to be units of software’s

functional decomposition

but rather to be properties that affect the performance

• r semantics of the components

Software Engineering / Fernando Brito e Abreu 20 5-Apr-05

Design Aspects (examples)

Concurrency How to decompose the software into processes, tasks, and threads How to deal with related efficiency, atomicity, synchronization, and

scheduling issues.

Control and Handling of Events How to organize data and control flow How to handle reactive and temporal events through various

mechanisms such as implicit invocation and call-backs

Distribution of Components How to distribute the software across the hardware How the components communicate How middleware can be used to deal with heterogeneous sw

11

Software Engineering / Fernando Brito e Abreu 21 5-Apr-05

Design Aspects (more examples)

Error and Exception Handling and Fault Tolerance How to prevent and tolerate faults How to deal with exceptional conditions How to degrade nicefully Interaction and Presentation How to structure and organize the interactions with users and the

presentation of information

e.g. separation of presentation and business logic using the Model-

View-Controller approach

Note: specifying user interface details, is a task of user interface design

(a part of Sw Ergonomics, not Software Engineering)

Data Persistence

How long-lived data are to be handled

Software Engineering / Fernando Brito e Abreu 22 5-Apr-05

Summary

Software Design Fundamentals Key Issues in Software Design Software Structure and Architecture

• Design Quality Analysis and Evaluation

Design Quality Analysis and Evaluation Design Quality Analysis and Evaluation

• Software Design Notations

Software Design Notations Software Design Notations

• Software Design Strategies and Methods

Software Design Strategies and Methods Software Design Strategies and Methods

12

Software Engineering / Fernando Brito e Abreu 23 5-Apr-05

Software architecture is …

… a description of the subsystems and components of a sw

system and the relationships between them (strict view)

… a discipline involving the study of software structures and

architectures in a more generic way (broader view)

Attempts to describe, and reuse, generic design knowledge Among other things, the Software Architecture discipline gave

birth (during the mid 90’s) to ideas such as:

architectural styles (aka macroarchitectural patterns) design patterns (e.g. GoF) product lines (families of programs with generic design) software frameworks

Software Engineering / Fernando Brito e Abreu 24 5-Apr-05

Architectural Styles vs Design Patterns

An Architectural Style (aka macroarchitectural pattern)

is a set of constraints on an architecture that defines a set or family of architectures that satisfies them

An architectural style can thus be seen as a meta-model which

can provide software’s high-level organization

A Design Pattern (aka microarchitectural pattern) is a

common solution to a common detailed design problem in a given context

Design patterns can be used to describe details at a lower,

more local level

13

Software Engineering / Fernando Brito e Abreu 25 5-Apr-05

Architectural Styles (examples)

General structure

Examples: layers, pipes, and filters, blackboard

Distributed systems

Examples: client-server, three-tiers, broker (CORBA)

Interactive systems

Examples: Model-View-Controller, Presentation-Abstraction-Control

Adaptable systems

Examples: micro-kernel, reflection

Others

Examples: batch, interpreters, process control, rule-based

Software Engineering / Fernando Brito e Abreu 26 5-Apr-05

Design Patterns (examples)

Creational patterns

Examples: builder, factory, prototype, and singleton

Structural patterns

Examples: adapter, bridge, composite, decorator, façade,

flyweight, and proxy

Behavioral patterns

Examples: command, interpreter, iterator, mediator,

memento, observer, state, strategy, template, visitor

14

Software Engineering / Fernando Brito e Abreu 27 5-Apr-05

Software Product Lines

A product line is a group of products sharing a common,

managed set of features that satisfy the needs of a selected market or mission area.

The key to successful software product lines is the systematic

management of planned variations across the product line, while exploiting the commonalities.

When building a new product in a product line, programming is

de-emphasized. This may be achieved by:

Reusing software designs Composing customizable components Code generation based on variability specification

Software Engineering / Fernando Brito e Abreu 28 5-Apr-05

Software Product Lines

The main issues addressed are identifying:

the commonalities among family members the variability among family members, as, for instance:

hardware configuration underlying operating system devices and sensors used human-computer interface national language of presentation

See “A Case Study in Successful Product Line Development”

(http://www.sei.cmu.edu/plp/)

15

Software Engineering / Fernando Brito e Abreu 29 5-Apr-05

Software Frameworks

A framework is a partially complete software subsystem

that can be extended by appropriately instantiating specific plug-ins (also known as hot spots)

Examples:

Eclipse (developer bench) Explorer (browser) … Software Engineering / Fernando Brito e Abreu 30 5-Apr-05

Summary

Software Design Fundamentals Key Issues in Software Design Software Structure and Architecture Design Quality Analysis and Evaluation

• Software Design Notations

Software Design Notations Software Design Notations

• Software Design Strategies and Methods

Software Design Strategies and Methods Software Design Strategies and Methods

16

Software Engineering / Fernando Brito e Abreu 31 5-Apr-05

Quality attributes

Discernable at run-time

performance, security, availability, functionality, usability

Not discernable at run-time

Modifiability, portability, reusability, integrability, testability

Related to the architecture’s intrinsic qualities

conceptual integrity, correctness, completeness, buildability

Software Engineering / Fernando Brito e Abreu 32 5-Apr-05

Quality Analysis and Evaluation Techniques

Software design reviews: informal or semiformal, often group-

based, techniques to verify and ensure the quality of design artifacts

Examples: architecture reviews, design reviews, inspections, scenario-

based techniques, requirements tracing

Static analysis: formal or semiformal static (nonexecutable)

analysis that can be used to evaluate a design

Examples: fault-tree analysis or automated cross-checking

Simulation and prototyping: dynamic techniques to evaluate a

design

Examples: performance simulation or feasibility prototyping

17

Software Engineering / Fernando Brito e Abreu 33 5-Apr-05

Measures

Can be used to assess or to quantitatively estimate various

aspects of a software design’s size, structure, or quality.

Most proposed measures depend on the approach used for

producing the design:

Function-oriented (structured) design measures

Design measures are obtained from structure charts (sometimes called

hierarchical diagrams) which capture functional decomposition

Object-oriented design measures:

Most measures obtained from class diagrams (e.g. MOOD set) Assessing the behavioral aspects of OO design (Aline’s PhD thesis)

Aspect-oriented design measures:

Research has just started (Sérgio Bryton’s MSc Thesis)

Software Engineering / Fernando Brito e Abreu 34 5-Apr-05

OO Measures: MOOD and MOOD2 (*)

intra-specification metrics

Acronym Name AIF Attribute Inheritance Factor OIF Operations Inheritance Factor IIF Internal Inheritance Factor * AHF Attribute Hiding Factor OHF Operations Hiding Factor AHEF Attributes Hiding Effectiveness Factor * OHEF Operations Hiding Effectiveness Factor * BPF Behavioral Polymorphism Factor PPF Parametric Polymorphism Factor * CCF Class Coupling Factor ICF Internal Coupling Factor

18

Software Engineering / Fernando Brito e Abreu 35 5-Apr-05

OO Measures: MOOD and MOOD2 (*)

inter-specification metrics

Acronym Name EIF (S) External Inheritance Factor * ECF (S) External Coupling Factor * PRF(S) Potential Reuse Factor * ARF(S) Actual Reuse Factor * REF(S) Reuse Efficiency Factor *

MOOD = Metrics for Object-Oriented Design Proposed by Yours truly ☺ in 1994 (MOOD) and 1998 (MOOD2)

Software Engineering / Fernando Brito e Abreu 36 5-Apr-05

Summary

Software Design Fundamentals Key Issues in Software Design Software Structure and Architecture Design Quality Analysis and Evaluation Software Design Notations

• Software Design Strategies and Methods

Software Design Strategies and Methods Software Design Strategies and Methods

19

Software Engineering / Fernando Brito e Abreu 37 5-Apr-05

Design Notations – Static View

Structural Descriptions describe and represent the structural

aspects of a software design

including the major components and how they are interconnected

The most widely used notations for static design include:

Structure charts Jackson structure diagrams Entity-relationship diagrams (ERDs) Class and object diagrams Class responsibility collaborator cards (CRCs) Interface description languages (IDLs) Component diagrams Architecture description languages (ADLs) Deployment diagrams

Software Engineering / Fernando Brito e Abreu 38 5-Apr-05

Structure charts

Used to describe the calling

structure of programs

Structure charts show how

code units (modules) ‘call’ each other with inter-module data interfaces

There is a ‘call & wait’

relationship between modules

structure charts are used for

‘synchronous interactions’ (within one thread).

20

Software Engineering / Fernando Brito e Abreu 39 5-Apr-05

Jackson structure diagrams

Used to describe the data

structures in terms of sequence, selection, and iteration

Michael Jackson (not the singer)

created Jackson System Development (JSD) using the principles laid out in Jackson Structured Programming (JSP)

JSD is a structured analysis and

design method similar to SSADM

It uses Entity Structure Diagrams

(ESD) and Network Diagrams (ND) to model a system

Entity Structure Diagram (ESD)

Software Engineering / Fernando Brito e Abreu 40 5-Apr-05

Entity-relationship diagrams (ERDs)

Used to represent

conceptual models of data stored in information systems

• _a

• bserv

• suspenso

21

Software Engineering / Fernando Brito e Abreu 41 5-Apr-05

Class and object diagrams

Used to represent a set of classes (and objects)

and their interrelationships

Many flavors were proposed throughout the late 80’s

and the 90´s, depending on the corresponding method

OMT Booch … UML

Software Engineering / Fernando Brito e Abreu 42 5-Apr-05

• nome
• data_construção
• arqueação
• calado
• andamento
• rumo

+manobrar() +navegar() +aproar() +arribar() +orçar() +abater() +adernar() +fundear() +atracar() +abalroar() Navio

• tipo

Guerra

• armador
• tipo_carga

+estivar() Comércio

• dono

Recreio

• nome
• tipo_vela
• nºmastros
• nºmastaréus

Vela

• fabricante
• nºêmbolos
• cavalos
• consumo
• rotação_máxima

Motor Misto Castelo

• velocidade_cruzeiro
• velocidade_máxima

Aparelho Ponte

• designação
• vencimento

Posto ContraAlmirante CapitãoMarGuerra CapitãoFragata 2ºTenente CapitãoTenente 1ºTenente

• ano_curso

Oficial Sargento Praça 0..* 1

• denominação

Classe Máquinas Marinha Administração

• nome
• morada
• data_nascimento
• estado_civil

+admitir() +dispensar() +reformar() +falecer() Pessoal

• data_última_promoção

+promover() Militar

• categoria
• data_admissão

Civil 1 1..*

• data_embarque
• data_desembarque
• função

+embarcar() +desembarcar() Tripulante 0..1 1 situada barca escuna patacho galera lugre chalupa caíque bergantim

• nº_balizas
• tipo_quilha

casco

• quota
• tipo_pesca

+lançar_rede() +içar_rede() +amanhar() +congelar() Pesca 1 1

• porto_registo
• nº_registo

Outros ViceAlmirante Almirante Médicos

• calibre
• alcance
• ritmo

+carrega() +dispara() Peça 1 * Asa 0..* 1 Camarote 0..* 1

• cupa

tipo_propulsão CargaGeral PortaContentores RollOnRollOff Químico Petroleiro LançaTorpedos LançaMísseis 0..* 1 0..* 1

OMT class diagram

22

Software Engineering / Fernando Brito e Abreu 43 5-Apr-05

Booch class diagram

Software Engineering / Fernando Brito e Abreu 44 5-Apr-05

UML class diagram

23

Software Engineering / Fernando Brito e Abreu 45 5-Apr-05

UML object diagram

Software Engineering / Fernando Brito e Abreu 46 5-Apr-05

Class Responsibility Collaborator cards (CRCs)

Used to denote the names of components (classes), their

responsibilities, and their collaborating components’ names

Kent Beck and Ward Cunningham, 1989

MessageHandler Customer FraudCriterion Report detected frauds Customer FraudCriterion Handle customer-specific criteria for fraud CustomerOrder RiskLevel Determine the risk of a customer

• rder

FraudAgent

Collaborators Responsibilities Class

24

Software Engineering / Fernando Brito e Abreu 47 5-Apr-05

Component diagrams

Used to represent a set of components and their

interrelationships

A component is a physical and replaceable part of a

system that conform to and provide the realization of a set of interfaces

Com ponent Stock_Broker quotes m arket CurrentPrices Process I nstruct ions Offers Com ponent Stock_Exchange broker SEC clear_transaction Prices_Changes buy sell com m it_transaction Offers Status

Software Engineering / Fernando Brito e Abreu 48 5-Apr-05

Interface Description Languages (IDLs)

Programming-like languages used to define the

interfaces (names and types of exported operations) of software components

See example of CORBA IDL: ... stockRef = ... ; //obtain Stock_Exchange reference brokerRef = ... ; //obtain Stock_Broker reference brokerRef->market->connect(“Stock_Exchange”, stockRef); stockRefClearTransaction = stockRef->provide(“clear_transaction”); brokerRef->commit_transaction->connect(“commit_transaction”, stockRefClearTransaction); consumerStock = stockRef->get_consumer(“Offers”); brokerRef->subscribe(“Offers”, consumerStock); consumerBroker = brokerRef->get_consumer(“CurrentPrices”); stockRef->subscribe(“Prices_Changes”, consumerBroker);

25

Software Engineering / Fernando Brito e Abreu 49 5-Apr-05

Architecture Description Languages (ADLs)

Textual, often formal, languages used to describe a software

architecture in terms of components and connectors

Examples:

ACME (http://www-2.cs.cmu.edu/~acme/) Aesop (http://www-2.cs.cmu.edu/Groups/able/aesop/aesop_home.html) UniCon (http://www-2.cs.cmu.edu/afs/cs/project/vit/www/unicon/index.html) Wright (http://www-2.cs.cmu.edu/afs/cs/project/able/www/wright/index.html) Rapide (http://pagv.stanford.edu/rapide/) C2 (http://www.isr.uci.edu/architecture/c2.html) MetaH (http://www.htc.honeywell.com/metah/) … and others such as Adage, Darwin and SADL

Software Engineering / Fernando Brito e Abreu 50 5-Apr-05

Architecture Description Languages (ADLs) Example in ACME / UML 2.0

<<AcmeComponent>> :server receive_request <<AcmeComponent>> :connectionManager external_socket <<AcmeComponent>> :securityManager <<AcmeConnector>> :clearanceRequest requestor grantor securityCheckIntf <<AcmeComponent>> :database <<AcmeConnector>> :SQLQuery caller callee dbQueryIntf <<AcmeConnector>> :securityQuery requestor securityManager securityAuthorization queryIntf credentialQuery securityManagementIntf <<delegate>> // Original Acme specification extract Component server = { Port receiveRequest; Representation serverDetails = { System serverDetailsSys = { Component connectionManager = { Ports { externalSocket; securityCheckIntf; dbQueryIntf } } Component securityManager = {...} Component database = {...} Connector SQLQuery = { Roles { caller; callee } } Connector clearanceRequest = { Roles { requestor; grantor } } Connector securityQuery = { Roles { securityManager; requestor } } Attachments { connectionManager.securityCheckIntf to clearanceRequest.requestor; securityManager.securityAuthorization to clearanceRequest.grantor; ...} Bindings { connectionManager.externalSocket to server.receiveRequest } }

26

Software Engineering / Fernando Brito e Abreu 51 5-Apr-05

Deployment diagrams

Used to represent a set of (physical) nodes and their

interrelationships, and, thus, to model the physical aspects of a system

:kiosk * Deploys user.exe c:console Deploys admin.exe config.exe :RAID farm s:server

processorSpeed=300 mHz memory = 1024 M

Deploys dbadmin.exe tktmstr

«10-T Ethernet» «RS-232» Software Engineering / Fernando Brito e Abreu 52 5-Apr-05

Design Notations – Dynamic View

Behavioral Descriptions describe the dynamic behavior of

software components

most of these notations are useful during detailed design

The most widely used notations for static design include:

Data flow diagrams (DFDs) Pseudocode and program design languages (PDLs) Flowcharts and structured flowcharts Decision tables and diagrams State transition and statechart diagrams Activity diagrams Collaboration diagrams Sequence diagrams Formal specification languages

27

Software Engineering / Fernando Brito e Abreu 53 5-Apr-05

Data flow diagrams (DFDs)

Used to show data flow among a set of

processes

USED AT: AUTHOR: DI-FCT/UNL DATE: REV: PROJECT: Deputados e Legislatura 07-11-2002 09-11-2002 NOTES: 1 2 3 4 5 6 7 8 9 10 WORKING DRAFT RECOMMENDED PUBLICATION READER DATE CONTEXT:

TOP

NODE: TITLE: NUMBER:

Deputados e Legislatura A-0

legislatura id_legislatura dados_encerramento_legislatura sessão_legislativa id_sessão_legislativa dados_encerramento_sessao deputado id_deputado partido id_partido círculo_eleitoral id_circulo_eleitoral órgão id_órgão grupo_parlamentar id_grupo_parlam entar partido_ce id_partido_ce partido_gp id_partido_gp composição_órgão id_composição_órgão dados_encerramento_órgão Deputados e Legislatura 1 Órgão 1 Órgão 1 Órgão 1 Órgão

Software Engineering / Fernando Brito e Abreu 54 5-Apr-05

Decision tables and diagrams

Used to represent complex combinations

• f conditions and actions

Example:

A store wishes to program a decision on non-cash receipts for goods into their intelligent tills. The conditions to check are agreed as:

• 1. Transaction under £50
• 2. Pays by cheque with cheque card

(guarantee £50)

• 3. Pays by credit card

The possible actions that a cashier could take are agreed as:

• 1. Ring up sale
• 2. Check credit card from local

database

• 3. Call a supervisor
• 4. Automatic check of credit card

company database

X Check credit card database X Call Supervisor X Check from local database X Ring up sale

• N

N Unknown customer N Y N Y Pays by cheque N N Y Y Under £50

28

Software Engineering / Fernando Brito e Abreu 55 5-Apr-05

Pseudocode and program design languages (PDLs)

These are structured-programming-

like languages used to describe, generally at the detailed design stage, the behavior of a procedure

• r method.

Program design languages (PDLs)

are very-high-level programming languages.

They express the logic of a program

in narrative form and were first proposed as a replacement for flowcharts.

Set moveCount to 1 FOR each row on the board FOR each column on the board IF gameBoard position (row, column) is occupied THEN CALL findAdjacentTiles with row, column INCREMENT moveCount END IF END FOR END FOR

Software Engineering / Fernando Brito e Abreu 56 5-Apr-05

Flowcharts and structured flowcharts

Used to represent the

flow of control and the associated actions to be performed

29

Software Engineering / Fernando Brito e Abreu 57 5-Apr-05

State transition and statechart diagrams

Used to show the control

flow from state to state in a state machine

Petri nets are sophisticated

state transition diagrams

Software Engineering / Fernando Brito e Abreu 58 5-Apr-05

Activity diagrams

Used to show the

control flow from activity to activity

An activity is a ongoing

non-atomic execution within a state machine

Gestor Produção Cliente Gestor Comercial Registar Briefing Preparar Orçamento (info Comercial) [exige info de produção] Registar Orçamento Preparar Orçamento (info Produção) Pedir Proposta Fechar Orçamento Preparar Proposta Receber Proposta

30

Software Engineering / Fernando Brito e Abreu 59 5-Apr-05

Collaboration diagrams

Used to show the interactions that occur among

a group of objects, where the emphasis is on the

• bjects, their links, and the messages they

exchange on these links

:Client :Transaction p:ODBCProxy

1:«create» 2:setActions(a,d,o) 3:«destroy» {transient} 2.1:setValues(d,3,4) 2.2:setValues(a, “CO”)

Software Engineering / Fernando Brito e Abreu 60 5-Apr-05

Sequence diagrams

Used to show the interactions among a group of objects, with

emphasis on the time ordering of messages

:Client :Transaction :ODBCProxy

«create» «destroy» setActions(a, d, o) setValues(d, 3, 4) commited setValues(a, “CO”) {transient}

31

Software Engineering / Fernando Brito e Abreu 61 5-Apr-05

Formal specification languages

Textual languages that use basic notions from

mathematics (for example, logic, set, sequence) to rigorously and abstractly define software component interfaces and behavior, often in terms of pre- and post- conditions

Examples:

BON (Business Object Notation) OCL (Object Constraint Language)

Software Engineering / Fernando Brito e Abreu 62 5-Apr-05

Expressing formal constraints

Class invariants

are constraints that represent conditions that must be met by all class instances, at all times

Pre-conditions are constraints that must be true

before an operation is executed

Post-conditions are constraints that must be true

when the operation ends its execution

32

Software Engineering / Fernando Brito e Abreu 63 5-Apr-05

Design by Contract

Obligation Right SUPPLIER Right Obligation CLIENT POST-CONDITION PRE-CONDITION

In descendants we can:

weaken pre-conditions

Requiring less from clients

strengthen post-conditions

Giving more to clients

Software Engineering / Fernando Brito e Abreu 64 5-Apr-05

BON (Business Object Notation)

33

Software Engineering / Fernando Brito e Abreu 65 5-Apr-05

OCL (Object Constraint Language)

Invariant example:

LoyaltyProgram

partners->forAll(p: Partner | p.deliveredServices.transactions-> select (OclType = Burning)->collect(points)->sum < 10000)

Post conditions example:

Sequence::prepend(object: T): Sequence(T)

post: result->size() = self@pre->size() +1 post: result->at(1) = object

Software Engineering / Fernando Brito e Abreu 66 5-Apr-05

Summary

Software Design Fundamentals Key Issues in Software Design Software Structure and Architecture Design Quality Analysis and Evaluation Software Design Notations Software Design Strategies and Methods

34

Software Engineering / Fernando Brito e Abreu 67 5-Apr-05

Software Design Strategies

Strategies help guiding the design process Examples:

divide-and-conquer stepwise refinement top-down vs. bottom-up approaches data abstraction and information hiding use of heuristics use of patterns and pattern languages

Software Engineering / Fernando Brito e Abreu 68 5-Apr-05

Software Design Methods

Methods are less ad-hoc than strategies because they

generally suggest or provide:

a set of notations to be used with the method a description of the process to be used when following the

method

a set of guidelines in using the method

Methods are useful because they are:

a means of transferring knowledge a common framework for teams of software engineers

35

Software Engineering / Fernando Brito e Abreu 69 5-Apr-05

Software Design Methods (examples)

Function-Oriented (Structured) Design Data-Structure-Centered Design Object-Oriented Design Component-Based Design (CBD) Aspect-Oriented Design (CBD) Other interesting but less mainstream approaches also

exist

formal and rigorous methods transformational methods

Software Engineering / Fernando Brito e Abreu 70 5-Apr-05

Function-Oriented (Structured) Design

Originated in the 70’s (DeMarco, Yourdon, …) Centers on identifying the major software functions and then

elaborating and refining them in a top-down manner

Structured design is generally used after structured analysis,

thus producing, among other things, data flow diagrams and associated process descriptions

Researchers have proposed various strategies (e.g,

transformation analysis, transaction analysis) and heuristics (for example, fan-in/fan-out, scope of effect vs. scope of control) to transform a DFD into a software architecture generally represented as a structure chart

36

Software Engineering / Fernando Brito e Abreu 71 5-Apr-05

Data-Structure-Centered Design

Also from the 70’s (Jackson, Warnier-Orr, …) Starts from the data structures a program manipulates rather than

from the function it performs

The software engineer first describes the input and output data

structures (e.g. using Jackson’s structure diagrams)

then he develops the program’s control structure based on these data

structure diagrams

Various heuristics have been proposed to deal with special cases

• for example, when there is a mismatch between the input and
• utput structures

Software Engineering / Fernando Brito e Abreu 72 5-Apr-05

Object-Oriented Design

Originated on the work around the Simula language (Norway,

1966), reborn with Smalltalk in the early 80’s

OO design’s roots stem from the concept of data abstraction,

extended with concepts such as inheritance, polymorphism and reflection

Numerous software design methods based on objects were

proposed in the 90’s (OMT, Booch, Objectory, OPEN

OMG’s UML emerged as both de jure and de facto standard

Versions 1.* in the late 90’s Version 2.0 in 2003/2004

37

Software Engineering / Fernando Brito e Abreu 73 5-Apr-05

Aspect-Oriented Design (AOD)

Emerging design paradigm resultant from the proposals

in AOP such as AspectJ or HyperJ

The first PhD on AOP was Portuguese (Crista)

This is a very hot topic of research

The DI/FCT/UNL is actively involved in the “Early Aspects”

movement towards pulling the AO approach to the earlier phases (requirements and design) of the software life-cycle

See the AOSD conference (http://www.aosd.org)

Software Engineering / Fernando Brito e Abreu 74 5-Apr-05

Class D Aspect X Class C Class B Class A

AOP in a Nutshell …

code tangling code scattering

38

Software Engineering / Fernando Brito e Abreu 75 5-Apr-05

Component-Based Design (CBD)

A software component is an independent unit, having

well defined interfaces and dependencies that can be composed and deployed independently

Component-based design addresses issues related to

providing, developing, and integrating such components in order to improve reuse

CBD is highly influenced by System Design!

Software Engineering / Fernando Brito e Abreu 76 5-Apr-05

System Design

An architectural model presents an abstract view of the

sub-systems making up a system

May include major information flows between sub-systems Usually presented as a block diagram, complemented with brief

descriptions of each sub-system

Each sub-system can be decomposed in their sub-

systems until the system is decomposed into functional components

The latter are components that, when viewed from the

perspective of the sub-system, provide a single function

39

Software Engineering / Fernando Brito e Abreu 77 5-Apr-05

Example: Intrusion Alarm System

Alarm controller Voice synthesizer Movement sensors Siren Door sensors Telephone caller External control centre

Software Engineering / Fernando Brito e Abreu 78 5-Apr-05

Sub-system descriptions Makes external calls to notify security, the police, etc Telephone Caller Synthesises a voice message giving the location of the suspected intruder Voice Synthesiser Emits an audible warning when an intruder is detected Siren Controls the operation of the system Alarm Controller Detect door opening in the external doors of the building Door Sensors Detect movement in the rooms monitored by the system Movement Sensors

Example: Intrusion Alarm System

40

Software Engineering / Fernando Brito e Abreu 79 5-Apr-05

Example: Intrusion Alarm System

Component types:

Sensor

Movement sensor, door

sensor

Actuator

Siren

Communication

Telephone caller

Co-ordination

Alarm controller

Interface

Voice synthesizer

Software Engineering / Fernando Brito e Abreu 80 5-Apr-05

Example: Air Traffic Control System

ATC systems engineering Electronic engineering Electrical engineering User interface design Mechanical engineering Architecture Structural engineering Software engineering Civil engineering

41

Software Engineering / Fernando Brito e Abreu 81 5-Apr-05

Data comms. system Transponder system Radar system Aircraft comms. Telephone system Flight plan database Backup position processor Position processor Comms. processor Backup comms. processor Aircraft simulation system Weather map system Accounting system Controller

• info. system

Controller consoles Activity logging system

Example: Air Traffic Control System

Software Engineering / Fernando Brito e Abreu 82 5-Apr-05

Functional System Components

A system architecture should be designed in

terms of functional sub-systems

These can be either hardware or software based

Functional components can be classified:

Sensor components Actuator components Computation components Communication components Co-ordination components Interface components

42

Software Engineering / Fernando Brito e Abreu 83 5-Apr-05

Sensor components

Collect information from the system’s environment

e.g. radars in an air traffic control system

Actuator components

Cause some change in the system’s environment

e.g. valves in a process control system which increase or

decrease material flow in a pipe Computation components

Carry out some computations on an input to produce

an output

e.g. a floating point processor in a computer system

Functional System Components

Software Engineering / Fernando Brito e Abreu 84 5-Apr-05

Communication components

Allow components to communicate with others

e.g. network linking distributed computers

Co-ordination components

Co-ordinate the interactions of other components

e.g. scheduler in a real-time system

Interface components

Facilitate the interactions with other components

e.g. operator interface

All components are now usually sw controlled!

Functional System Components

43

Software Engineering / Fernando Brito e Abreu 85 5-Apr-05

Bibliography

[Bas98] L. Bass, P. Clements, and R. Kazman, Software Architecture in Practice, Addison-Wesley, 1998. [Bas03] L. Bass, P. Clements, and R. Kazman, Software Architecture in Practice, second ed., Addison-Wesley, 2003. [Boo99] G. Booch, J. Rumbaugh, and I. Jacobson, The Unified Modeling Language User Guide, Addison-Wesley, 1999. [Bos00] J. Bosch, Design & Use of Software Architectures: Adopting and Evolving a Product-Line Approach, first ed., ACM Press, 2000. [Bud04] D. Budgen, Software Design, second ed., Addison- Wesley, 2004. [Bus96] F. Buschmann et al., Pattern-Oriented Software Architecture: A System of Patterns, John Wiley & Sons, 1996. [Dor02] M. Dorfman and R.H. Thayer, eds., Software Engineering (Vol. 1 & Vol. 2), IEEE Computer Society Press, 2002. [Fre83] P. Freeman and A.I. Wasserman, Tutorial on Software Design Techniques, fourth ed., IEEE Computer Society Press, 1983. [IEEE610.12-90] IEEE Std 610.12-1990 (R2002), IEEE Standard Glossary of Software Engineering Terminology, IEEE, 1990. [IEEE1016-98] IEEE Std 1016-1998, IEEE Recommended Practice for Software Design Descriptions, IEEE, 1998. [IEEE1028-97] IEEE Std 1028-1997 (R2002), IEEE Standard for Software Reviews, IEEE, 1997. [IEEE1471-00] IEEE Std 1471-2000, IEEE Recommended Practice for Architectural Description of Software Intensive Systems, Architecture Working Group of the Software Engineering Standards Committee, 2000. [IEEE12207.0-96] IEEE/EIA 12207.0-1996/ /ISO/IEC 12207: 1995, Industry Implementation of Int. Std. ISO/IEC 12207:95, Standard for Information Technology-Software Life Cycle Processes, IEEE, 1996. [ISO9126-01] ISO/IEC 9126-1:2001, Software Engineering Product Quality—Part 1: Quality Model, ISO and IEC, 2001. [ISO15026-98] ISO/IEC 15026-1998, Information Technology — System and Software Integrity Levels, ISO and IEC, 1998. [Jal97] P. Jalote, An Integrated Approach to Software Engineering, second ed., Springer-Verlag, 1997. [Lis01] B. Liskov and J. Guttag, Program Development in Java: Abstraction, Specification, and Object-Oriented Design, Addison- Wesley, 2001. [Mar94] J.J. Marciniak, Encyclopedia of Software Engineering, J. Wiley & Sons, 1994. [Mar02] J.J. Marciniak, Encyclopedia of Software Engineering, second ed., J. Wiley & Sons, 2002. [Mey97] B. Meyer, Object-Oriented Software Construction, second ed., Prentice-Hall, 1997. [Pfl01] S.L. Pfleeger, Software Engineering: Theory and Practice, second ed., Prentice-Hall, 2001. [Pre04] R.S. Pressman, Software Engineering: A Practitioner’s Approach, sixth ed., McGraw-Hill, 2004. [Smi93] G. Smith and G. Browne, “Conceptual Foundations of Design Problem-Solving,” IEEE Transactions on Systems, Man and Cybernetics, vol.23, iss.5, 1209-1219, Sep.-Oct.1993