La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

Ingegneria della Progettazione (Design Engineering) G. Berio.

Presentazioni simili


Presentazione sul tema: "Ingegneria della Progettazione (Design Engineering) G. Berio."— Transcript della presentazione:

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): – Daltra parte ciò che non è stato fatto in termini di modelli/diagrammi durante lingegneria dei requisiti dovrebbe essere fatto ora ma senza lapporto 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 (software) architectingindicates the overall structure and behavior of the software patterns (best practices)conveys the essence of proven design solutions functional independencesingle-minded function (high cohesion) and low coupling refactoringa reorganization technique that simplifies the design abstractiondata, procedure, control modularitycompartmentalization of data and function hidingcontrolled interfaces refinementelaboration of detail for all abstractions Principi di Progettazione: cioè come si fa a progettare per la qualità Elaborated from Pressman

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

10 Progettare unarchitettura, usando uno stile architetturale (usando, il più possibile, passaggi o incrementi sistematici, dal modello analitico) Completare larchitettura, usando alcuni pattern architetturali Analizzare larchitettura, relativamente alla valutazione previsionale della qualità del software Progettare in dettaglio le singole componenti dellarchitettura, usando pattern di progettazione e, in generali, i principi di progettazione Tipici compiti 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. From Pressman component Replaced by term component

12 Componente Consideriamo componente come unastrazione 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!!

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? optimal number of components of components cost of cost of software software number of components componentintegrationcost component development cost 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) 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: delegatesCustomer: involved participants Architect Developer Maintainer

18 Stili e pattern architetturali Pattern di progettazione

19 Architectural Styles Data-centered architectures Data flow architectures Call and return architectures Object-oriented architectures Layered architectures others 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. Elaborated from Pressman Not unique!!

20

21 Data-Centered Architecture From Pressman

22 Data Flow Architecture From Pressman

23 Usual Call and Return Architecture From Pressman

24

25 Layered Architecture From Pressman

26

27

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

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) Si potrebbe applicare nel caso del treno, quando si deve calcolare lIVA su tratte internazionali (anche se attualmente sulle tratte internazionali si evita lapplicazione dellIVA) oppure per costruire un software indipendente dal paese dutilizzo Problema: adattare diverse interfacce di componenti che, tuttavia, hanno qualche similarità.

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


Scaricare ppt "Ingegneria della Progettazione (Design Engineering) G. Berio."

Presentazioni simili


Annunci Google