Ingegneria della Progettazione (Design Engineering) G. Berio

Design and 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) tenendo presente che – Parte dei requisiti funzionali potrebbero essere influenzati dalla presenza di alcuni requisiti non funzionali

Cosa guida la progettazione: 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

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

Architectural views Overview of Design Engineering Organisation Requirement engineering Design engineering Architecture design Component design Architectural patterns Architectural styles Design patterns Quality attributes (stakeholders) Increment and tranformation guidelines Detailed Comp. design Design principles

(software) architecture—the overall structure and behavior of the software patterns—”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 Elaborated from Pressman

Qualità del software: guida e monitoraggio del progetto Gli attributi di qualità del software (es. correttezza) sono utili per guidare il progetto (cioè ogni principio di progettazione quando usato privilegia o è orientato verso uno o più attributi di qualità) 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): tale valutazione non è fatta tipicamente sul software (che non è ancora disponibile) ma su modelli/diagrammi

Qualità del processo 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à)

Progettare un’architettura, usando uno stile architetturale (usando, il più possibile, trasformazioni sistematiche, 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 parti dell’architettura, usando pattern di progettazione e, in generali, i principi di progettazione Tipici passi 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

Componente 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 sottosistema – Una combinazione di questi – 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ù o meno formali) indicate come ADL Ma storicamente si è sempre parlato di moduli!!

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

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

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 of a computer-based system. 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 system is structured and how its components (or modules) work together” [BAS03]. From Pressman

Stakeholders in (Software) Architecture 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 design. 2.Reference for selecting and assembling components. 3.Maintain interoperability with existing system. Guidance on software modification, architecture evolution and interoperability CustomerUser Architect Developer Maintainer

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 modules (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 system, and (4) semantic models that enable a designer to understand the overall properties of a system by analyzing the known properties of its constituent parts. 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 ad tutti gli oggetti interessati

Esempio di pattern OO (Adapter) Si potrebbe applicare nel caso del treno, quando si deve calcolare l’IVA su tratte internazionali (anche se attualmente sulle tratta internazionali si evita l’applicazione dell’IVA) oppure per costruire in software indipendente dal paese d’utilizzo Problema: adattare diverse interfacce di componenti che, tuttavia, qualche similarità.

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

Tipici passi di Progettazione Progettare un’architettura, usando uno stile architetturale (usando, il più possibile, trasformazioni sistematiche, 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 parti dell’architettura, usando pattern di progettazione e, in generali, i principi di progettazione

Qualità del software: guida e monitoraggio del progetto Gli attributi di qualità del software (es. correttezza) sono utili per guidare il progetto (cioè ogni principio di progettazione quando usato privilegia o è orientato verso uno o più attributi di qualità) 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): tale valutazione non è fatta tipicamente sul software (che non è ancora disponibile) ma su modelli/diagrammi

An Architectural Design Method: Structured Design "four bedrooms, three baths, lots of glass..." customer requirements architectural design

Structured Design Seeks to conquer the complexity of large systems through partitioning and hierarchical structuring. Uses graphical tools to render systems more understandable.

Structured Design Offers a set of strategies for developing a design solution from a well-defined requirement specifications. Offers a set of objective and empirically justified criteria for evaluating the quality of a given design solution with respect to the problem on hand.

Structured Design DFD transformed to structure chart – a tree like representation - (representing a call-return architecture) (and often called a program structure) Control hierarchy defined (semantic model) Resultant structure refined (set of components) Architectural description is refined according functional independence (a quality attribute)

Structure Chart A structure chart has three constituents: Modules Connections between modules Interactions between modules throughout parameter (data) passing and call/return among different module (which constitutes the “semantic model” of the architecture). Procedural (internal) aspects of modules (e.g, how a particular functionality is realised with programming languages) are not represented. Structure charts are easily turned in to software code using programming languages.

Structure Chart Notation Fan out=2 Fan out=1 Fan in=1 Fan in=2 Fan out=0 Non ammesso!!

Characteristics of Structure Chart Abstraction: – Low levels modules cannot invoke higher level modules Fan-out: – Indicates how many modules are directly invoked by a given module – Low fan-out represents modules with simple functionality Fan-in: – indicates how many modules directly invoke a given module. – High fan-in represents code reuse and is in general encouraged (but not in the initial steps of the design).

Transformation of DFD diagrams in Structure Charts Two strategies exist to guide transformation of a DFD into a structure chart: – Transform Analysis – Transaction Analysis These two strategies are usually mixed for making the transformation of the whole DFD

Transform Analysis The first step in transform analysis: – divide the DFD into 3 parts input, logical processing, output. Usually all flows are required

The first step in transform analysis: – Find the transformation center where outputs flows are alternatives Usually all flows are required Usually flows are alternative based on the input flows and values Transformation center Transform Analysis afferent efferent

Transform Analysis: details A B C a b c d Root Get b Get aA BPut c Put dC b bc c c d d B is the transformation center Get and Put modules can be interfaces to terminators (read and write) Or can be modules to read and write data stores becomes

Transform Analysis Derive structure chart by drawing one functional component for: – the transformation center, – each afferent branch, – each efferent branch.

Esempio: trasformare il seguente DFD A B D C U T a b d c e f

Transform Analysis Identifying the highest level input and output transforms: – requires experience and skill. Some guidelines: – follow (some) inputs until a function is found whose output cannot be deduced from these inputs alone. – functions which validate input are not central transforms. – functions which sort input or filter data from it are.

Transform Analysis First level of structure chart: – draw a module for each input and output function in the DFD – a module for the central transform. Next, refine the structure chart: – add sub modules required by each high-level module. – Many levels of modules may required to be added. Finally check: – whether all functions in the DFD have been mapped to modules.

Example 1: RMS Calculating Software Compute- RMS 0 User Data- items result Context Diagram

Example 1: RMS Calculating Software From a cursory analysis of the problem description, easy to see that the system needs to perform: accept the input numbers from the user, validate the numbers, calculate the root mean square of the input numbers, display the result.

Example 1: RMS Calculating Software Data- items result Read- numbers 0.1 Validate- numbers 0.2 Compute- rms 0.3 Display 0.4 RMS numbers Valid - numbers error

Example 1: RMS Calculating Software By observing the level 1 DFD: – identify read-number and validate-number functions as the afferent branch – display as the efferent branch.

Example 1: RMS Calculating Software root Get-good-dataCompute-solutionDisplay-solution Get-data Validate-data Valid-numbers rms

Example 2: Tic-Tac-Toe Computer Game As soon as either of the human player or the computer wins, – a message congratulating the winner should be displayed. If neither player manages to get three consecutive marks along a straight line, – and all the squares on the board are filled up, – then the game is drawn. The computer always tries to win a game.

Example 2: Context Diagram Human Player Tic-tac-toe software 0 display move

Example 2 : Level 1 DFD board Display- board Check- winner Validate- move Play- move move result game

Example 2: Derived Structure Chart root Get-good-moveCompute-gameDisplay Get-move Validate- move play-move Check- winner

Transaction Analysis Useful for designing transaction processing programs. – Transform-centered systems: characterized by similar processing steps for every data item processed by input, process, and output functions. – Transaction-driven systems, one of several possible paths through the DFD is traversed depending upon the input data value.

Transaction Analysis Transaction: – Any input data value that triggers functions. – For example, selected menu options might trigger different functions. Transaction analysis uses this tag to divide the system into: – several transaction modules – one transaction-center module.

Transaction Analysis These flows may be alternative and therefore only one output flow will be produced Transaction center A guideline to find transaction centers

Transaction analysis Transaction- center trans 1 trans 2 trans 3 type 1type 2type 3

Example 3: Level 1 DFD Accept- order Process- order Handle- indent- request Handle- query pending-order Sales-statistics inventory Vendor-list Customer-file Item-file Customer-history Indent-request Indents Accepted-orders query order statistics

Example 3: Derived Structure Chart root Handle-orderHandle-indentHandle-query Get-order Accept- order Process- order orderquery indent

Structured Design and Extended DFD

It starts from an extended DFD Structure charts can be employed but they are not really suitable because the “control flow” (i.e. part of the “semantic model”) is fixed (and not defined in the DFD) while the “control flow” is explicitly provided in the extended DFD In principle an extended DFD can be mapped on process and event architectures

The usual OO Design Model From Pressman

Architectures in OO The main architectural style is layered (by definition), incrementing the class diagrams (from the analytical model) The structure of the architecture is usually represented by using components and package diagrams The “semantic model” of the architecture can be represented throughout sequence diagrams

Why layered? Add intermediate lower layers Add back-end lower layers Add front-end lower layers ANALYSIS DESIGN

Layers are Named! Add intermediate lower layers Add back-end lower layers Add front-end lower layers DESIGN InterfaceApplication Core/Utility

Architectural Patterns Concurrency—applications must handle multiple tasks in a manner that simulates parallelism – task scheduler pattern Persistence—Data persists if it survives past the execution of the software that created it. Two patterns are common: – a database management system pattern that applies the storage and retrieval capability of a DBMS to the application – an application level persistence pattern that builds persistence features into the application Distribution (and replication)—the manner in which systems or components within systems 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 in OO Design patterns in OO are the main mechanism for incrementing the class diagrams The same difference found when relating distinct notations in structured analysis and object-oriented requirement engineering is also found in the transition between requirement engineering and design engineering i.e. class diagrams are usually incremented, DFD are usually transformed

Typical OO design patterns Adapter Factory Observer Cache Failure They are represented as class diagrams and sequence diagrams, with the problem description

Analyzing Architectural Design 1.Collect scenarios. 2.Elicit requirements, constraints, and environment description. 3.Describe the architectural styles/patterns that have been chosen to address the scenarios and requirements 4.Evaluate quality attributes by considered each attribute in isolation. 5.Identify the sensitivity of quality attributes to various architectural attributes for a specific architectural style. 6. Critique candidate architectures (developed in step 3) using the sensitivity analysis conducted in step 5. From Pressman