Software Design - Moodle · 3 5-Apr-05 Software Engineering / Fernando Brito e Abreu 5 Summary...

1

Software Design

Fernando Brito e Abreu ([email protected])Universidade Nova de Lisboa (http://www.unl.pt)QUASAR Research Group (http://ctp.di.fct.unl.pt/QUASAR)

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

SWEBOK: the 10 Knowledge AreasSoftware RequirementsSoftware DesignSoftware ConstructionSoftware TestingSoftware MaintenanceSoftware Configuration ManagementSoftware Engineering ManagementSoftware Engineering ProcessSoftware Engineering Tools and MethodsSoftware Quality

2


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]


SummarySoftware Design FundamentalsKey Issues in Software DesignSoftware Structure and ArchitectureDesign Quality Analysis and EvaluationSoftware Design NotationsSoftware Design Strategies and Methods

3


SummarySoftware Design FundamentalsKey Issues in Software DesignKey Issues in Software DesignKey Issues in Software DesignSoftware Structure and ArchitectureSoftware Structure and ArchitectureSoftware Structure and ArchitectureDesign Quality Analysis and EvaluationDesign Quality Analysis and EvaluationDesign Quality Analysis and EvaluationSoftware Design NotationsSoftware Design NotationsSoftware Design NotationsSoftware Design Strategies and MethodsSoftware Design Strategies and MethodsSoftware Design Strategies and Methods


Software design is a 2-step process

Architectural designArchitectural design describes how software is decomposed and organized into components (the software architecture)

[IEEEP1471-00]

Detailed designDetailed design describes the specific behavior of those components

4


Important design principlesAbstractionCoupling and cohesionDecomposition and modularizationEncapsulation/information hidingSeparation of interface and implementationSufficiency, completeness and primitiveness


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 abstractiondata abstractioncontrol abstraction

Abstraction leads us to different views of a system …

5


Abstraction

Deployment ViewProcess View

Design View ImplementationView

Requirements View

functionalityperformance

scalabilitythroughput

system assemblyconfiguration mgmt.

system topologydistributiondeliveryinstallation

methodspeople

plansactivities

control


Couplingand 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


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


Decomposition and modularization

Advantages:design and develop different parts of the same system by different people / distinct companieshandle 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 partsreuse existing parts in different contextsdivide the system in configuration units to be put under CMrestrict change propagation.

7


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 …


Modularity is often not guided by structural criteria!

00 . 10 . 20 . 30 . 40 . 50 . 60 . 7

S p e c if ic a t io n

IM P _ M M F

O P T _ M M F

8


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


Separation of interfaceand implementation

Involves defining a component by specifying a public interface, known to the clients, separate from the details of how the component is realized

e.g. Web services (WSDL)

9


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


SummarySoftware Design FundamentalsKey Issues in Software DesignSoftware Structure and ArchitectureSoftware Structure and ArchitectureSoftware Structure and ArchitectureDesign Quality Analysis and EvaluationDesign Quality Analysis and EvaluationDesign Quality Analysis and EvaluationSoftware Design NotationsSoftware Design NotationsSoftware Design NotationsSoftware Design Strategies and MethodsSoftware Design Strategies and MethodsSoftware Design Strategies and Methods

10


Design AspectsSome 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 or semantics of the components


Design Aspects (examples)Concurrency

How to decompose the software into processes, tasks, and threadsHow to deal with related efficiency, atomicity, synchronization, and scheduling issues.

Control and Handling of EventsHow to organize data and control flowHow to handle reactive and temporal events through various mechanisms such as implicit invocation and call-backs

Distribution of ComponentsHow to distribute the software across the hardwareHow the components communicateHow middleware can be used to deal with heterogeneous sw

11


Design Aspects (more examples)Error and Exception Handling and Fault Tolerance

How to prevent and tolerate faultsHow to deal with exceptional conditionsHow to degrade nicefully

Interaction and PresentationHow 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 approachNote: specifying user interface details, is a task of user interface design (a part of Sw Ergonomics, not Software Engineering)

Data PersistenceHow long-lived data are to be handled


SummarySoftware Design FundamentalsKey Issues in Software DesignSoftware Structure and ArchitectureDesign Quality Analysis and EvaluationDesign Quality Analysis and EvaluationDesign Quality Analysis and EvaluationSoftware Design NotationsSoftware Design NotationsSoftware Design NotationsSoftware Design Strategies and MethodsSoftware Design Strategies and MethodsSoftware Design Strategies and Methods

12


Software architecture is …… a description of the subsystems and components of a swsystem 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


Architectural Styles vs Design PatternsAn 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


Architectural Styles (examples)General structure

Examples: layers, pipes, and filters, blackboard

Distributed systemsExamples: client-server, three-tiers, broker (CORBA)

Interactive systemsExamples: Model-View-Controller, Presentation-Abstraction-Control

Adaptable systemsExamples: micro-kernel, reflection

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


Design Patterns (examples)Creational patterns

Examples: builder, factory, prototype, and singleton

Structural patternsExamples: adapter, bridge, composite, decorator, façade, flyweight, and proxy

Behavioral patternsExamples: command, interpreter, iterator, mediator, memento, observer, state, strategy, template, visitor

14


Software Product LinesA 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 designsComposing customizable componentsCode generation based on variability specification


Software Product LinesThe main issues addressed are identifying:

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

hardware configurationunderlying operating systemdevices and sensors usedhuman-computer interfacenational language of presentation

See “A Case Study in Successful Product Line Development”(http://www.sei.cmu.edu/plp/)

15


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)…


SummarySoftware Design FundamentalsKey Issues in Software DesignSoftware Structure and ArchitectureDesign Quality Analysis and EvaluationSoftware Design NotationsSoftware Design NotationsSoftware Design NotationsSoftware Design Strategies and MethodsSoftware Design Strategies and MethodsSoftware Design Strategies and Methods

16


Quality attributesDiscernable at run-time

performance, security, availability, functionality, usability

Not discernable at run-timeModifiability, portability, reusability, integrability, testability

Related to the architecture’s intrinsic qualitiesconceptual integrity, correctness, completeness, buildability


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


MeasuresCan 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 measuresDesign 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)


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


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 DesignProposed by Yours truly ☺ in 1994 (MOOD) and 1998 (MOOD2)


SummarySoftware Design FundamentalsKey Issues in Software DesignSoftware Structure and ArchitectureDesign Quality Analysis and EvaluationSoftware Design NotationsSoftware Design Strategies and MethodsSoftware Design Strategies and MethodsSoftware Design Strategies and Methods

19


Design Notations – Static ViewStructural 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 chartsJackson structure diagramsEntity-relationship diagrams (ERDs)Class and object diagramsClass responsibility collaborator cards (CRCs)Interface description languages (IDLs)Component diagramsArchitecture description languages (ADLs)Deployment diagrams


Structure chartsUsed to describe the calling structure of programsStructure charts show how code units (modules) ‘call’each other with inter-module data interfacesThere is a ‘call & wait’relationship between modules

structure charts are used for ‘synchronous interactions’(within one thread).

20


Jackson structure diagramsUsed to describe the data structures in terms of sequence, selection, and iterationMichael 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 SSADMIt uses Entity Structure Diagrams (ESD) and Network Diagrams (ND) to model a system

Entity Structure Diagram (ESD)


Entity-relationship diagrams (ERDs)Used to represent conceptual models of data stored in information systems

R/130R/135

R/109

R/167

inclui /participa em

R/184

R/195 R/197

R/198

R/200 R/201

R/210

inclui /é identificado por

relativo_a

R/213

refere /referente a

R/218

R/222

R/223

R/264

R/276R/277

R/278

R/280

dependentes /depende de

R/282

R/283

R/284

R/286

R/287

R/288

Reuniaocod_sessao_legislativa (FKcod_legislatura (FK)cod_tipo_orgao (FK)cod_orgao (FK)num_reuniao

link_dochora_fim_previstahora_inicio_previstadata_inicio_reuniaodata_previstadata_fim_reuniaocod_gp (FK)local_reuniãocod_tipo_reuniao (FK)

Tipo_Reuniaocod_tipo_reuniao

des_tipo

Sessao_Legislativacod_legislatura (FK)cod_sessao_legislativa

data_iniciodata_fim

Presencanr_id (FK)cod_legislatura (FK)cod_sessao_legislativa (FKnum_reuniao (FK)cod_tipo_orgao (FK)cod_orgao (FK)

cod_tipo_falta (FK)

Tipo_Faltacod_tipo_faltacod_tipo_orgao (FK)

des_tipo_falta

Deputadocod_legislatura (FK)nr_id (FK)

cod_depcod_partido (FK)cod_ce (FK)nr_ordem_ce

Legislaturacod_legislatura

data_iniciodata_fimdata_eleicoesobservacoes

Tipo_Orgaocod_tipo_orgao

des_tipo_orgao

Tipo_Periodocod_periodocod_tipo_orgao (FK)

des_periodo

Intervenientecod_interveniente

tipo_intervenientecod_legislatura (FK)nr_id (FK)cod_gp (FK)cod_cargo (FK)cod_tipo_orgao (FK)

GPcod_gpcod_legislatura (FK)

abreviatura_gpdes_gp

Cargocod_cargocod_tipo_orgao (FK)

des_cargo

Periodo_Reuniaocod_periodo (FK)cod_tipo_orgao (FK)cod_sessao_legislativa (FKcod_legislatura (FK)cod_orgao (FK)num_reuniao (FK)

hora_inicio

Intervencaocod_periodo (FK)cod_tipo_orgao (FK)cod_sessao_legislativa (FKcod_legislatura (FK)num_reuniao (FK)cod_orgao (FK)cod_interveniente (FK)

hora_iniciohora_fim

Cadastronr_id

Membro_Orgaocod_legislatura (FK)cod_tipo_orgao (FK)cod_orgao (FK)nr_id (FK)

Tipo_Situacaocod_situacaocod_tipo_orgao (FK)

des_situacaoactivosuspensoimpedido

Situacao_Cadastrocod_situacao_cadastr

des_situacao_cadastr

Orgaocod_tipo_orgao (FK)cod_orgaocod_legislatura (FK)

des_orgaoinicio_actividadefim_actividadeabreviatura_orgaolocal_reunião_habitualnumero_membroscod_subtipo_orgao (FK

21


Class and object diagramsUsed 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

OMTBooch…UML


-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

PostoContraAlmirante

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ça1 *

Asa0..* 1

Camarote0..* 1

ocupa

tipo_propulsão

CargaGeral

PortaContentores

RollOnRollOff

Químico

Petroleiro

LançaTorpedos

LançaMísseis

0..*1

0..*1

OMT class diagram

22


Booch class diagram


UML class diagram

23


UML object diagram


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

MessageHandlerCustomerFraudCriterion

Report detected frauds

CustomerFraudCriterion

Handle customer-specific criteria for fraud

CustomerOrderRiskLevel

Determine the risk of a customer order

FraudAgent

CollaboratorsResponsibilitiesClass

24


Component diagramsUsed to represent a set of components and their interrelationshipsA component is a physical and replaceable part of a system that conform to and provide the realization of a set of interfaces

ComponentStock_Brokerquotes

market

CurrentPrices

Process Instructions

Offers

ComponentStock_Exchangebroker

SECclear_transaction

Prices_Changes

buy

sell

commit_transaction

OffersStatus


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 referencebrokerRef = ... ; //obtain Stock_Broker referencebrokerRef->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


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


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

requestorsecurityManager

securityAuthorization queryIntf

credentialQuery securityManagementIntf

<<delegate>>

// Original Acme specification extractComponent 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


Deployment diagramsUsed 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:consoleDeploys

admin.execonfig.exe

:RAID farm

s:serverprocessorSpeed=300 mHzmemory = 1024 M

Deploysdbadmin.exetktmstr

«10-T Ethernet»

«RS-232»


Design Notations – Dynamic ViewBehavioral 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 flowchartsDecision tables and diagramsState transition and statechart diagramsActivity diagramsCollaboration diagramsSequence diagramsFormal specification languages

27


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-200209-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_legis lativa

id_sessão_legislativa

dados_encerramento_sessao

deputado

id_deputado

partido

id_partido

círculo_eleitoral

id_c irculo_eleitoral

órgão

id_órgão

grupo_parlamentar

id_grupo_parlamentar

partido_ce

id_partido_ce

partido_gp

id_partido_gp

composição_órgão

id_composição_órgão

dados_encerramento_órgão

0

Deputados e Legis latura

1Órgão

1Órgão

1Órgão

1Órgão


Decision tables and diagramsUsed to represent complex combinations of 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 £502. 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 sale2. Check credit card from local database3. Call a supervisor4. Automatic check of credit card company database

XCheck credit card database XCall Supervisor

XCheck from local database XRing up sale

--NNUnknown customer NYNYPays by chequeNNYYUnder £50

28


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 or 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 1FOR each row on the board

FOR each column on the board IF gameBoard position (row, column) is occupied THEN

CALL findAdjacentTiles with row, columnINCREMENT moveCount

END IF END FOR

END FOR


Flowcharts and structured flowchartsUsed to represent the flow of control and the associated actions to be performed

29


State transition and statechart diagrams

Used to show the control flow from state to state in a state machinePetri nets are sophisticated state transition diagrams


Activity diagramsUsed to show the control flow from activity to activityAn activity is a ongoing non-atomic execution within a state machine

Gestor ProduçãoCliente Gestor Comercial

RegistarBriefing

Preparar Orçamento(info Comercial)

[exige info de produção]

RegistarOrçamento

Preparar Orçamento(info Produção)

PedirProposta

Fechar Orçamento

Preparar PropostaReceberProposta

30


Collaboration diagramsUsed to show the interactions that occur among a group of objects, where the emphasis is on the objects, 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”)


Sequence diagramsUsed 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)

commitedsetValues(a, “CO”)

{transient}

31


Formal specification languagesTextual 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)


Expressing formal constraintsClass 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


Design by Contract

ObligationRightSUPPLIER

RightObligationCLIENT

POST-CONDITIONPRE-CONDITION

In descendants we can:weaken pre-conditions

Requiring less from clients

strengthen post-conditionsGiving more to clients


BON (Business Object Notation)

33


OCL (Object Constraint Language)Invariant example:

LoyaltyProgrampartners->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() +1post: result->at(1) = object


SummarySoftware Design FundamentalsKey Issues in Software DesignSoftware Structure and ArchitectureDesign Quality Analysis and EvaluationSoftware Design NotationsSoftware Design Strategies and Methods

34


Software Design StrategiesStrategies help guiding the design processExamples:

divide-and-conquerstepwise refinementtop-down vs. bottom-up approachesdata abstraction and information hidinguse of heuristicsuse of patterns and pattern languages


Software Design MethodsMethods are less ad-hoc than strategies because they generally suggest or provide:

a set of notations to be used with the methoda description of the process to be used when following the methoda set of guidelines in using the method

Methods are useful because they are:a means of transferring knowledgea common framework for teams of software engineers

35


Software Design Methods (examples)Function-Oriented (Structured) DesignData-Structure-Centered DesignObject-Oriented DesignComponent-Based Design (CBD)Aspect-Oriented Design (CBD)

Other interesting but less mainstream approaches also exist

formal and rigorous methodstransformational methods


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


Data-Structure-Centered DesignAlso 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 output structures


Object-Oriented DesignOriginated 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’sVersion 2.0 in 2003/2004

37


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 researchThe 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-cycleSee the AOSD conference (http://www.aosd.org)


Class DAspect X

Class CClass BClass A

AOP in a Nutshell …

code tanglingcode scattering

38


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!


System DesignAn architectural model presents an abstract view of the sub-systems making up a system

May include major information flows between sub-systemsUsually 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


Example: Intrusion Alarm System

Alarmcontroller

Voicesynthesizer

Movementsensors

Siren

Doorsensors

Telephonecaller

Externalcontrol centre


Sub-system descriptions

Makes external calls to notify security, the police, etcTelephone Caller

Synthesises a voice message giving the location of the suspected intruderVoice Synthesiser

Emits an audible warning when an intruder is detectedSiren

Controls the operation of the systemAlarm Controller

Detect door opening in the external doors of the buildingDoor Sensors

Detect movement in the rooms monitored by the systemMovement Sensors

Example: Intrusion Alarm System

40


Example: Intrusion Alarm SystemComponent types:

SensorMovement sensor, door sensor

ActuatorSiren

CommunicationTelephone caller

Co-ordinationAlarm controller

InterfaceVoice synthesizer


Example: Air Traffic Control System

ATC systemsengineering

Electronicengineering

Electricalengineering

User interfacedesign

Mechanicalengineering

Architecture

Structuralengineering

Softwareengineering

Civilengineering

41


Data comms.system

Transpondersystem

Radarsystem

Aircraftcomms.

Telephonesystem

Flight plandatabase

Backupposition

processor

Positionprocessor

Comms.processor

Backup comms.processor

Aircraftsimulation

system

Weather mapsystem

Accountingsystem

Controllerinfo. system

Controllerconsoles

Activity loggingsystem

Example: Air Traffic Control System


Functional System ComponentsA 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 componentsActuator componentsComputation componentsCommunication componentsCo-ordination componentsInterface components

42


Sensor componentsCollect information from the system’s environment

e.g. radars in an air traffic control system

Actuator componentsCause 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 componentsCarry out some computations on an input to produce an output

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

Functional System Components


Communication componentsAllow components to communicate with others

e.g. network linking distributed computers

Co-ordination componentsCo-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


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

Software Design - Moodle · 3 5-Apr-05 Software Engineering / Fernando Brito e Abreu 5 Summary...

Documents

Transcript of Software Design - Moodle · 3 5-Apr-05 Software Engineering / Fernando Brito e Abreu 5 Summary...