Ingegneria della Progettazione (Design Engineering)

1. Ingegneria della Progettazione(Design Engineering) G. Berio

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

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

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

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

6. 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à)

7. Tipici attributi di qualità 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

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

9. Architectural views (stakeholders) Overview of Design Engineering Organisation Increment and tranformation guidelines/rules Requirement engineering Quality attributes Design engineering Design principles Detailed comp. design Architecture design Component design Architectural patterns Architectural styles Design patterns FI,R,A,M,H

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

11. (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. Replaced by term component From Pressman

12. Componente Ma storicamente si è sempre parlato di moduli!! • Consideriamo componentecome 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

13. Componente in UML • “… a modular, deployable, and replaceable part of a software that encapsulates implementation and exposes a set of interfaces.”

14. What is the "right" number of components for a specific software design? component development cost cost of software component integration cost optimal number number of components of components From Pressman

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

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

17. Stakeholders in (Software) Architectures (Architectural Views) Customer: delegates Customer: involved participants 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. Softw. Arch. Architect Developer 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 Maintainer

18. Stili e pattern architetturaliPattern di progettazione

19. 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 Not unique!! Elaborated from Pressman

21. Data-Centered Architecture From Pressman

22. Data Flow Architecture From Pressman

23. Usual Call and Return Architecture From Pressman

25. Layered Architecture From Pressman

28. 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 levelpersistence pattern that builds persistence features into the Software • Distribution (and replication) — the manner in which components communicate with one another in a distributed environment • Abroker acts as a ‘middle-man’ between the client component and a server component. From Pressman

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

30. Typical OO design patterns • Adapter • Factory • Observer • Cache • Failure They may be represented as class diagrams and sequence diagrams, associated with the problem description

31. Esempio di pattern OO (Observer) Problema: comunicare la variazioni di stato di un oggetto a tutti gli oggetti interessati

32. Esempio di pattern OO (Adapter) Problema: adattare diverse interfacce di componenti che, tuttavia, hanno qualche similarità. 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

33. Esempio di pattern OO (Adapter) Si può applicare anche per software pre-esistenti!