Ingegneria della ProgettazioneIngegneria della Progettazione(Design Engineering)(Design Engineering)

G. Berio

Design and its ObjectivesDesign and its Objectives the software design must implement all of the explicit

requirements contained in the analysis model, and it must accommodate all of the implicit requirements desired by the customer.

the software design must be a readable, understandable guide for those who generate code and for those who test and subsequently support the software.

the software design should provide a complete picture of the software, addressing the data, functional, and behavioral domains from an implementation perspective.

From Pressman

Punto di Partenza per la Punto di Partenza per la ProgettazioneProgettazione

La specifica dei requisiti (funzionali) (cioè il modello analitico) cioè una rappresentazione orientata alla progettazione del software (e che può essere formale, semiformale o informale)

In generale, la specifica dei requisiti da cui si parte è semiformale (cioè una combinazione di modelli/diagrammi e testo in linguaggio naturale):– D’altra parte ciò che non è stato fatto in termini di modelli/diagrammi

durante l’ingegneria dei requisiti dovrebbe essere fatto ora ma senza l’apporto diretto del committente (assumendo quindi che i requisiti rappresentati dal modello analitico sono sufficientemente precisi)

I requisiti non funzionali (se esistono)

Cosa guida la progettazione (“all Cosa guida la progettazione (“all the implicit requirements”): the implicit requirements”):

la qualità del softwarela qualità del software La qualità del software è tipicamente indicata

attraverso la valutazione di un insieme di attributi di qualità

Buona parte di tali attributi potrebbero essere già parte di requisiti non funzionali (e in tal caso si tratterebbe di requisiti)

Tuttavia, tali attributi sono sempre presenti, indipendentemente dai requisiti non funzionali e dovrebbero essere sempre parte degli obiettivi di progettazione del software

Qualità del software: Qualità del software: guida e monitoraggio del progettoguida e monitoraggio del progetto

Gli attributi di qualità del software (es. correttezza) sono utili per guidare il progetto ma, in seguito, una volta costruito il software, per valutare (metriche) se ciò che è stato fatto in fase di progettazione ha effettivamente prodotto un software di qualità desiderata (quality assessment)

Ciò significa che, durante la progettazione, è possibile usare una valutazione previsionale (metriche) della qualità del software (quality forecasting) che verrà prodotto: tale valutazione non è fatta tipicamente sul software (che non è ancora disponibile) ma su modelli/diagrammi

Qualità del processo Qualità del processo (nella progettazione)(nella progettazione)

Ovviamente, una parte importante è anche la definizione della qualità del processo, di cui si è parlato in generale

La qualità del processo è tendenzialmente legata alla valutazione della capacità di produrre del software (di qualità)

Tipici attributi di Tipici attributi di qualità del softwarequalità del software

Correttezza, affidabilità, robustezza, safety Prestazioni Usabilità Verificabilità (Testabilità) Manutenibilità (Riparabilità) Evolvibilità (Scalabilità) Riusabilità Portabilità Comprensibilità Interoperabilità

La scelta di quali attributi privilegiare e quanto dipende dai costi e tempi finali ma talvolta è obbligata

Attenzione alla loro tipicità: possono essere diversi a seconda della metodologia usata! Ad esempio Pressman usa i FURPS

(software) architecting—indicates the overall structure and behavior of the software

patterns (best practices)—”conveys the essence” of proven design solutions

functional independence—single-minded function (high cohesion) and low coupling

refactoring—a reorganization technique that simplifies the design

abstraction—data, procedure, control modularity—compartmentalization of data and function hiding—controlled interfaces refinement—elaboration of detail for all abstractions

Principi di Progettazione: cioè Principi di Progettazione: cioè come si fa a progettare per la qualitàcome si fa a progettare per la qualità

Elaborated from Pressman

Overview of Design Overview of Design Engineering OrganisationEngineering Organisation

Requirementengineering

Designengineering

Architecture design

Component design

Architecturalpatterns

Architecturalstyles

Design patterns

Quality attributes

Architectural views(stakeholders)

Increment and tranformation guidelines/rules

Detailedcomp. design

Design principles

FI,R,A,M,H

Progettare un’architettura, usando uno stile architetturale (usando, il più possibile, passaggi o incrementi sistematici, dal modello analitico)

Completare l’architettura, usando alcuni pattern architetturali

Analizzare l’architettura, relativamente alla valutazione previsionale della qualità del software

Progettare in dettaglio le singole componenti dell’architettura, usando pattern di progettazione e, in generali, i principi di progettazione

Tipici compiti di ProgettazioneTipici compiti di Progettazione

(Software) Architecture(Software) Architecture““The overall The overall structurestructure of the software and the of the software and the ways in which that structure provides ways in which that structure provides conceptual integrityconceptual integrity for a system.” for a system.”

Structural and behavior properties.Structural and behavior properties. This aspect of the This aspect of the architectural architectural designdesign representation defines the representation defines the modules of a systemmodules of a system (e.g., (e.g., components, objects, filters) and components, objects, filters) and the manner in which those modules are the manner in which those modules are packagedpackaged and and interactinteract with one another. For example, objects are with one another. For example, objects are packaged to encapsulate both data and the processing that manipulates packaged to encapsulate both data and the processing that manipulates the data and interact via the invocation of methods the data and interact via the invocation of methods Extra-functional propertiesExtra-functional properties.. The architectural design description should The architectural design description should address how the design architecture achieves requirements for address how the design architecture achieves requirements for performanceperformance, , capacitycapacity, , reliabilityreliability, , securitysecurity, , adaptabilityadaptability, and other , and other characteristics.characteristics.Families of related systems.Families of related systems. The architectural design should draw upon The architectural design should draw upon repeatable patternsrepeatable patterns that are commonly encountered in the design of that are commonly encountered in the design of families of similar systems. In essence, the design should have the ability families of similar systems. In essence, the design should have the ability

to reuse to reuse architectural building blocksarchitectural building blocks.. From Pressman

Replaced by term componentcomponent

ComponenteComponente Consideriamo componente come un’astrazione architetturale Un componente può essere:

– Una procedura– Una classe – Un tipo/interfaccia– Un tipo di dato astratto– Un valore (oggetto)!– Un processo – Un intero e non qualificato codice software– Una combinazione dei precedenti– Etc.

Un componente può contenere altri componenti; in generale, un componente ha relazioni con altri componenti

I componenti possono essere raggruppati usando come “package” (nella maggior parte dei casi)

Esistono notazioni specifiche (più formali) indicate come ADL

Ma storicamente si è sempre parlato di moduli!!

Componente in UMLComponente in UML

“… a modular, deployable, and replaceable part of a software that encapsulates implementation and exposes a set of interfaces.”

What is the "right" number of componentsWhat is the "right" number of componentsfor a specific software design?for a specific software design?

optimal numberoptimal number of componentsof components

cost ofcost of softwaresoftware

number of componentsnumber of components

componentcomponentintegrationintegration

costcost

component development cost component development cost

From Pressman

Why Architecture?Why Architecture?

The architecture is not the operational softwareThe architecture is not the operational software..

Rather, it is a representation that enables a Rather, it is a representation that enables a software engineer to: software engineer to:

(1) analyze the effectiveness of the design (1) analyze the effectiveness of the design in in meeting its stated requirementsmeeting its stated requirements, ,

(2) consider (2) consider architectural alternativesarchitectural alternatives at a stage at a stage when making design changes is still relatively easy, when making design changes is still relatively easy, and and

(3) (3) reduce the risksreduce the risks associated with the associated with the construction of the software.construction of the software.

From Pressman

Why is Architecture Important?Why is Architecture Important? Representations of software architecture are an enabler for

communication between all parties (stakeholders) interested in the development.

The architecture highlights early design decisions that will have a profound impact on all software engineering work that follows and, as important, on the ultimate success of the system as an operational entity.

Architecture “constitutes a relatively small, intellectually understandable model of how the software is structured and how its components (or modules) work together” [BAS03].

From Pressman

Stakeholders in (Software) Architectures Stakeholders in (Software) Architectures (Architectural Views)(Architectural Views)

Softw.Arch.

1.Schedule and budget estimation.2.Feasibility and risk assessment.3.Requirements traceability.4.Progress tracking

1. Consistency with req. and usage scenarios.2. Future req. growth accommodation.3. Performance, reliability, interoperability.

1. Requirement traceability.2. Support of Trade-off-Analysis.3. Completeness.4. Consistency.

1.Sufficient detail for component design.2.Reference for selecting and assembling components.3.Maintain interoperability with existing software.

Guidance on software modification, architecture evolution and interoperability

Customer: delegates Customer: involved participants

Architect Developer

Maintainer

Stili e pattern architetturaliStili e pattern architetturaliPattern di progettazionePattern di progettazione

Architectural StylesArchitectural Styles

Data-centered architectures Data flow architectures Call and return architectures Object-oriented architectures Layered architectures others

Each styleEach style describes a system category that encompasses: (1) a describes a system category that encompasses: (1) a set of component typesset of component types (e.g., a database, computational (e.g., a database, computational modules) that perform a function required by a system, (2) a modules) that perform a function required by a system, (2) a set of connectorsset of connectors that enable “communication, coordination that enable “communication, coordination and cooperation” among components, (3) and cooperation” among components, (3) constraintsconstraints that that define how components can be integrated to form the software, define how components can be integrated to form the software, and (4) and (4) semantic modelssemantic models that enable a designer to understand that enable a designer to understand the overall properties of a software by analyzing the known the overall properties of a software by analyzing the known properties of its constituents. properties of its constituents.

Elaborated from Pressman

Not unique!!

Data-Centered ArchitectureData-Centered Architecture

From Pressman

Data Flow ArchitectureData Flow Architecture

From Pressman

Usual Call and Return Usual Call and Return ArchitectureArchitecture

From Pressman

Layered ArchitectureLayered Architecture

From Pressman

Architectural PatternsArchitectural Patterns Concurrency — Software must handle multiple tasks in a

manner that simulates parallelism – task scheduler pattern

Persistence —Data persists if it survives past the execution of the component that created it. Two patterns are common: – a database management system pattern that applies the storage and

retrieval capability of a DBMS to the Software– an application level persistence pattern that builds persistence features

into the Software Distribution (and replication) — the manner in which

components communicate with one another in a distributed environment– A broker acts as a ‘middle-man’ between the client component and a

server component.

From Pressman

Design PatternsDesign Patterns The best designers in any field have an uncanny ability to see

patterns that characterize a problem and corresponding patterns that can be combined to create a solution

A description of a design pattern may also consider a set of design forces. – Design forces describe non-functional requirements – quality attributes -

(e.g., ease of maintainability, portability) associated the software for which the pattern is to be applied.

The pattern characteristics indicate the attributes of the design that may be adjusted to enable the pattern to accommodate a variety of problems.

From Pressman

Typical OO design patternsTypical OO design patterns

AdapterFactoryObserverCacheFailure

They may be represented as class diagrams and sequence diagrams, associated with the problem description

Esempio di pattern OO Esempio di pattern OO (Observer)(Observer)

Problema: comunicare la variazioni di stato di un oggetto a tutti gli oggetti interessati

Esempio di pattern OO Esempio di pattern OO (Adapter)(Adapter)

TaxMasterAdapter

getTaxes( Sale ) : List<TaxLineItems>

GoodAsGoldTaxProAdapter

getTaxes( Sale ) : List<TaxLineItems>

«interface»ITaxCalculatorAdapter

getTaxes( Sale ) : List<TaxLineItems>

By Polymorphism, multiple tax calculator adapters have their own similar, but varying behavior for adapting to different external tax calculators.

<???>Adapter

...

...

Si potrebbe applicare nel caso del treno, quando si deve calcolare l’IVA su tratte internazionali (anche se attualmente sulle tratte internazionali si evita l’applicazione dell’IVA) oppure per costruire un software indipendente dal paese d’utilizzo

Problema: adattare diverse interfacce di componenti che, tuttavia, hanno qualche similarità.

Esempio di pattern OO Esempio di pattern OO (Adapter)(Adapter)

TaxMasterAdapter

getTaxes( Sale ) : List of TaxLineItems

GoodAsGoldTaxProAdapter

getTaxes( Sale ) : List of TaxLineItems

«interface»ITaxCalculatorAdapter

getTaxes( Sale ) : List of TaxLineItems

Adapters use interfaces andpolymorphism to add a level ofindirection to varying APIs in othercomponents.

SAPAccountingAdapter

postReceivable( CreditPayment )postSale( Sale )...

GreatNorthernAccountingAdapter

postReceivable( CreditPayment )postSale( Sale )...

«interface»IAccountingAdapter

postReceivable( CreditPayment )postSale( Sale )...

«interface»IInventoryAdapter

...

«interface»ICreditAuthorizationService

Adapter

requestApproval(CreditPayment,TerminalID, MerchantID)...

Si può applicare anche per software pre-esistenti!