Transcript Ingegneria della progettazione I: introduzione, architetture e

Ingegneria della Progettazione
(Design Engineering)
G. Berio
Design 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
Progettazione


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
the implicit requirements”):
la 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:
guida 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
(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
qualità del software










Correttezza, affidabilità, robustezza, safety
La scelta di quali attributi
Prestazioni
privilegiare e quanto dipende
Usabilità
dai costi e tempi finali ma
Verificabilità (Testabilità)
talvolta è obbligata
Manutenibilità (Riparabilità)
Evolvibilità (Scalabilità)
Riusabilità
Attenzione alla loro tipicità:
Portabilità
possono essere diversi a seconda
Comprensibilità
della metodologia usata! Ad
Interoperabilità
esempio Pressman usa i FURPS
Principi di Progettazione: cioè
come si fa a progettare per la qualità

(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
Elaborated from Pressman
Overview of Design
Engineering Organisation
Requirement
engineering
Increment and
tranformation
guidelines/rules
Design
engineering
Quality
attributes
Design principles
Architectural views
(stakeholders) Architecture
design
Architectural
patterns
Architectural
styles
Detailed
Component comp.
design
design
Design patterns
FI,R,A,M,H
Tipici compiti di Progettazione
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

(Software) Architecture
“The overall structure of the software and the ways in
which that structure provides conceptual integrity for a
system.”
Structural and behavior properties. This aspect of the architectural design
representation defines the modules of a system (e.g., components, objects, filters)
and the manner in which those modules are packaged and interact with one
another. For example, objects are packaged to encapsulate both data and the
processing that manipulates the data and interact via the invocation of methods
Extra-functional properties. The architectural design description should address
how the design architecture achieves requirements for performance, capacity,
reliability, security, adaptability, and other characteristics.
Families of related systems. The architectural design should draw upon repeatable
patterns that are commonly encountered in the design of families of similar systems.
In essence, the design should have the ability to reuse architectural building blocks.
From Pressman
Replaced by term component


Componente
Consideriamo componente come un’astrazione architetturale
Un componente può essere:
–
–
–
–
–
–
–
–
–



Una procedura
Una classe
Ma storicamente si è
Un tipo/interfaccia
sempre parlato di
Un tipo di dato astratto
moduli!!
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
Componente 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 components
for a specific software design?
component development cost
cost of
software
component
integration
cost
optimal number
of components
From Pressman
number of components
Why Architecture?
The architecture is not the operational software.
Rather, it is a representation that enables a software
engineer to:
(1) analyze the effectiveness of the design in meeting its
stated requirements,
(2) consider architectural alternatives at a stage when
making design changes is still relatively easy, and
(3) reduce the risks associated with the construction of the
software.
From Pressman
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
(Architectural Views)
Customer: delegates
1.Schedule and budget estimation.
2.Feasibility and risk assessment.
3.Requirements traceability.
4.Progress tracking
Architect
1.
2.
3.
4.
Customer: involved participants
Softw.
Arch.
1. Consistency with req. and
usage scenarios.
2. Future req. growth
accommodation.
3. Performance, reliability,
interoperability.
Developer
1.Sufficient detail for
component design.
2.Reference for selecting and
assembling components.
3.Maintain interoperability with
existing software.
Requirement traceability.
Support of Trade-off-Analysis.
Completeness.
Consistency.
Guidance on software modification, architecture evolution and interoperability
Maintainer
Stili e pattern architetturali
Pattern di progettazione
Architectural Styles
Each style describes a system category that encompasses: (1) a set of
component types (e.g., a database, computational modules) that perform
a function required by a system, (2) a set of connectors that enable
“communication, coordination and cooperation” among components, (3)
constraints that define how components can be integrated to form the
software, and (4) semantic models that enable a designer to understand
the overall properties of a software by analyzing the known properties of
its constituents.


Data-centered architectures
Data flow architectures
Call and return architectures
Object-oriented architectures
Layered architectures

others



Elaborated from Pressman
Not
unique!!
Data-Centered Architecture
From Pressman
Data Flow Architecture
From Pressman
Usual Call and Return
Architecture
From Pressman
Layered Architecture
From Pressman
Architectural 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 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 patterns

Adapter
 Factory
 Observer
 Cache
 Failure
They may be represented as class diagrams and sequence diagrams,
associated with the problem description
Esempio di pattern OO
(Observer)
Problema:
comunicare la
variazioni di stato di
un oggetto
a tutti gli oggetti
interessati
Esempio di pattern OO
(Adapter)
Problema: adattare
diverse interfacce di
componenti che,
tuttavia, hanno
qualche similarità.
TaxMasterAdapter
«interface»
ITaxCalculatorAdapter
getTaxes( Sale ) : List<TaxLineItems>
GoodAsGoldTaxPro
Adapter
<???>Adapter
...
...
getTaxes( Sale ) : List<TaxLineItems>
getTaxes( Sale ) : List<TaxLineItems>
By Polymorphism, multiple tax calculator adapters have
their own similar, but varying behavior for adapting to
different external tax calculators.
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
Esempio di pattern OO
(Adapter)
Adapters use interfaces and
polymorphism to add a level of
indirection to varying APIs in other
components.
«interface»
ITaxCalculatorAdapter
getTaxes( Sale ) : List of TaxLineItems
Si può applicare anche per software preesistenti!
TaxMasterAdapter
GoodAsGoldTaxPro
Adapter
getTaxes( Sale ) : List of TaxLineItems
getTaxes( Sale ) : List of TaxLineItems
«interface»
IAccountingAdapter
postReceivable( CreditPayment )
postSale( Sale )
...
«interface»
ICreditAuthorizationService
Adapter
requestApproval(CreditPayment,TerminalID, MerchantID)
...
«interface»
IInventoryAdapter
SAPAccountingAdapter
postReceivable( CreditPayment )
postSale( Sale )
...
GreatNorthernAccountingAdapter
postReceivable( CreditPayment )
postSale( Sale )
...
...