Progettazione dettagliata delle Progettazione dettagliata delle ComponentiComponenti

Cosa significa progettare in Cosa significa progettare in dettaglio una componentedettaglio una componente

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, focalizzandosi sugli attributi di qualità di interesse

Analizzare l’architettura, relativamente alla valutazione previsionale della qualità del software (ed ai costi)

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

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

(Ri-)Progettazione delle componenti (refactoring)Valutazione previsionale della qualitàDescrizione dettagliata delle componenti

iterativo

Tipologie di ComponenteTipologie di Componente

Componenti convenzionali (funzioni, procedure, programmi…)

Componenti object-oriented (classi, insiemi di classi, oggetti)

Specifica di una ComponenteSpecifica di una Componente La specifica di una componente è una definizione di cosa

necessita e di cosa produce/garantisce (senza dire esattamento come la componente lavora)

Tale definizione può essere scritta in una notazione (informale, formale o semiformale); tale definizione dovrebbe essere legata in qualche modo ai requisiti (oppure ad altre componenti)

Ad esempio, un modulo che corrisponde a varie funzioni (in un DFD) potrebbe avere una specifica in termini di linguaggio comune ovvero di pre e post condizioni

Una componente object-oriented può essere specificata attraverso “classi” ed anche attraverso l’introduzione di diagrammi di sequenza, ove sia classi che diagrammi di sequenza sono legati al modello analitico (oppure ad altre componenti)

(Ri-)Progettazione delle Componenti(Ri-)Progettazione delle Componenti La ri-progettazione lavora sulle componenti ed in

particolare sulla loro specifica Nel caso della progettazione strutturata, la

progettazione delle componenti procede applicando di fatto i design principles classici di astrazione, raffinamento, information hiding, indipendenza funzionale, modularità

Nel caso di componenti orientate agli oggetti il modo più efficace è l’uso di design pattern

In entrambe i casi, se la qualità previsionale risultante non è sufficiente, è ragionevole, applicare il refactoring (ristrutturazione) per migliorare il risultato mantenendo l’”equivalenza”

Esempi di ProgettazioneEsempi di Progettazione

Valida Opzioni di Costo

Calcola Costo

root

Get… Prenotare&Pagare Put…

raff

inam

ento

Ascensore Partire

Subject

Piano

Observer

Fermare

Design pattern Observer (applicato internamento alla componente Movimento)

Valutazione previsionale della Valutazione previsionale della qualità delle componenti: qualità delle componenti: il caso della indipendenza il caso della indipendenza

funzionale tra le componentifunzionale tra le componenti

Functional Independence:Functional Independence:Two Views of a Two Views of a

ComponentComponent

MODULE

What's inside??

How big is it??

Functional IndependenceFunctional Independence

COHESION - the degree to which a module performs one and only one

functionality.

COUPLING - the degree to which a module is "connected" to other modules in the software.

Low Coupling and High Cohesion

For each Module is the Design Principle enabling better maintaneability, evolvibiliy, reusability (and not only)

Elaborated From Pressman

Partially, functional independence is guaranteed by a well defined requirement specification, but may be destroyed by bad components

Degrees of CohesivenessDegrees of Cohesiveness

coincidental

logical

temporal

procedural

sequential

communicational

functional

Degree of cohesion

High

Low

Degrees of couplingDegrees of coupling

content

common

stamp

control

data

Degree of coupling

Low

High

Coincidental cohesionCoincidental cohesion

The module allows to perform a set of functions which relate to each other very loosely, if at all: – The module contains a random collection of

parts.

– Several parts have been put in the module out of pure coincidence without any thought or design.

Logical cohesionLogical cohesion

All elements of the module perform similar operations

Examples: – unique error handling, data input, data output, etc.– a set of print functions to generate an output

report, arranged into a single module;– visualising distinct messages with similar layout

Temporal cohesionTemporal cohesion

The module contains functions that must be executed in the same time span.

Example:– A unique module responsible for

initialization, start-up, shut-down of some process, etc.

Procedural cohesionProcedural cohesion

The parts of the module are involved in sequences of steps are carried out in a certain order for producing results

Example:

Get Tariffe, Rete

PagareTariffetariffe

Rete

rete

Communicational cohesionCommunicational cohesion

All parts of a module reference or update the same data structure

Example:

PagareTariffetariffe

Get Tariffe

Get Treno-Tariffe

Get Regole

Sequential cohesionSequential cohesion

A module is composed of different parts of a specific sequence, output from one element of the sequence is input to the next

Example: Valida Opzioni

di Costo

Calcola CostoCliente/Utente

PagareViaggio+OpzioniCosto

Costo

ViaggioPrenotato

Prenotare&Pagare

Functional cohesionFunctional cohesion

Different parts of a module cooperate to achieve a single functionality

When a module displays functional cohesion, we can describe its functionality using a single sentence

Data couplingData couplingTwo modules are data coupled, if they

communicate via a parameter corresponding to:– an elementary data item (e.g an integer, a float, a

character,…)– a composite data item, which contents is fully used

The data item should not be used for control purpose.

Stamp couplingStamp couplingTwo modules are stamp coupled, if they

communicate via a composite data item (i.e. there is a dependency of the structure of data) where some parts of the structure are not used

Examples of composite data items:– record in PASCAL – structure in C– class in Java

Control couplingControl couplingData from one module is used to

direct order of instruction execution in another

Example:– a flag set in one module and tested in another

moduleroot

Get… Prenotare&Pagare Put…

Prenotare?

Common couplingCommon couplingTwo modules are common coupled if

they share some global data.

Example: – Directly referring to the same database or variable

Get TariffePagareTariffetariffe

Rete

rete

Get Rete

Content couplingContent coupling

Content coupling exists between two modules if they share code in a general sense (code accessing the same internal variables, same data, but also the code needs to be maintained the same)

Evaluating Quality by using Evaluating Quality by using Function Indipendence Metrics: Function Indipendence Metrics:

one exampleone exampleMetrics Quality attributes

Metrics

Maintainability; Evolvabilty; Reusability; Comprehensibility;

Low Coupling High Cohesion

Fan-in, Fan-outLimited Fan-out and higher Fan-in for each module

Modules are loosely coupled and highly cohesive

(not sure)

Other Metrics(better)

Degrees of cohesion, coupling

Evaluating Quality by using Evaluating Quality by using Function Indipendence Metrics: Function Indipendence Metrics:

one exampleone example Clearly Fan-in and Fan-out metrics are only very

approximate ways to understand coupling and cohesion of modules; other metrics are required

Example is “online train ticket case study”root

Get Viaggio, ViaggioPrenotato, Opzioni di Costo, Opzioni di Prenotazione, Rete, Tariffe,

Prenotazioni, Dati CC, Biglietti

Prenotare&PagarePut Costo, Viaggio, Posti, Riepilogo,

Prenotazioni, Biglietti

Cohesion : Sequential Coupling: Control (with root)

Cohesion: Procedural

Coupling: Common (with Put), Control (with Prenotare&Pagare)

Cohesion: Procedural

Coupling: Common (with Get), Control (with Prenotare&Pagare)

Altre “metriche” sulla specifica di Altre “metriche” sulla specifica di una componenteuna componente

sequential cohesion

Coupling in OOCoupling in OO Conventional view:

– The degree to which a component is connected to other components and to the external world

OO view:– a qualitative degree to which classes are connected to one another

Level of coupling– Content– Common– Control– Stamp– Data– Routine call– Type use– Inclusion or import– External

From Pressman

A little bit different from the previous list of coupling levels

Sometimes referred to as design pattern (low coupling)

Cohesion in OOCohesion in OO Conventional view:

– the “single-mindedness” of a module OO view:

– cohesion implies that a component or class encapsulates only attributes and operations that are closely related to one another and to the class or component itself

Levels of cohesion– Functional– Layer– Communicational– Sequential– Procedural– Temporal– Utility

From Pressman

A little bit different from the previous list of cohesion levels

Sometimes referred to as design pattern (high cohesion)

Refactoring: Generalised ViewRefactoring: Generalised View Fowler [FOW99] defines refactoring in the following manner:

– "Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code [design] yet improves its internal structure.”

Similar to design patterns but design patterns are for building the (non existing) components while refactoring (patterns) is (are) for changing the existing components

When software is refactored, the existing design model is examined by following empirical ways for– redundancy– unused design elements– inefficient or unnecessary algorithms– poorly constructed or inappropriate data structures– or any other design failure that can be corrected to yield a

better design.Elaborated From Pressman

Refactoring in Structured DesignRefactoring in Structured DesignGenerally speaking, it is a way for increasing

cohesion per module and decreasing the overall coupling with the objective of– minimizing the potential duplication of code in each

module– separating work modules from management

modules (in a structure chart)– providing more generally useful modules– simplifying the future code

management modules

work modules

Refactoring (Online Train Tickets)Refactoring (Online Train Tickets)root

Get Viaggio, Opzioni di Costo, Opzioni di Prenotazione, Rete, Tariffe,

Prenotazioni, Dati CC

Prenotare&PagarePut Costo, Viaggio, Posti, Riepilogo,

Prenotazioni, Biglietti

Cohesion : CommunicationCoupling:

Cohesion: Procedural

Coupling: Control (with GetPut), Control (with Prenotare&Pagare)

Cohesion: Procedural

Coupling: Control (with GetPut), Control (with Prenotare&Pagare)

Get All TablesPut All Tables

Prenotare Pagare

Abstraction

Refinement

Cohesion : FunctionalCoupling: Data (with Get and Put)

Refactoring per componenti OO Refactoring per componenti OO Il refactoring nel caso di componenti OO opera

soprattutto a livello di codice (cioè una volta che le componenti sono state completamente descritte ovvero codificate in qualche linguaggio di programmazione)

Un esempio è presentato nel trasparente successivo

E’ comunque possibile fare del refactoring durante il progetto (cioè operando su rappresentazioni quali il diagramma delle classi, gli statechart etc., ed è forse anche meglio!

Refactoring Class Diagram Refactoring Class Diagram ExampleExample

Viaggio Treno

Prenotazione

TrenoViaggio

Prenotazione

A limited definition of each class is needed

Partially, the need of refactoring the design model may be decreased by a well defined requirement specification

Descrizione dettagliata Descrizione dettagliata delle componentidelle componenti

Describing the Describing the internal structure of conventional internal structure of conventional

componentscomponentsThe objective is to define the alghoritms and the

data types (by reusing th existing alghoritms and data types)

Flow chart, PDL and Decision Tables (see Pressman) can be employed

From Pressman

Flow ChartFlow Chart We are all familiar with the flow chart representations:

– Flow chart is a convenient technique to represent the flow of control in a system.

A=B if(c == 100) P=20 else p= 80 while(p>20) print(student mark)

A=B

P=20 P=80

Print

yes no

dummy

yes no

From Pressman

Flow Chart versus Flow Chart versus Structure ChartStructure Chart

A structure chart differs from a flow chart in three principal ways:– It is difficult to identify modules of a software from

its flow chart representation.– Data interchange among the modules is not

represented in a flow chart.– Sequential ordering of tasks/steps inherent in a flow

chart is suppressed in a structure chart.

From Pressman

Decision TableDecision TableConditions

regular customer

silver customer

gold customer

special discount

Rules

no discount

apply 8 percent discount

apply 15 percent discount

apply additional x percent discount

T

F

T

T

T

T

T

F

1 3 5 64

F

T T

T

2

Rules

From Pressman

Program Design Language (PDL)Program Design Language (PDL)

if-then-else

if condition x then process a; else process b; endif

PDL

easy to combine with source code machine readable, no need for graphics input

graphics can be generated from PDL enables declaration of data as well as procedure

easier to maintain

From Pressman

Describing the internal Describing the internal structure of classesstructure of classes

Operations (and how they can be used) must be defined: detailed statecharts for the class are the support for this purpose; however, in simple case, operations can be synthesized from pre and post conditions

Class invariants can be used as wellData types for class attributes must be definedAssociations should be implementedInheritance and polymorphism can be used as

well (and Framework)

Inheritance OptionsInheritance Options An existing class hierarchy can be searched to

determine if a class higher in the hierarchy (a superclass) contains most of the required attributes and operations. The new class inherits from the superclass and additions may then be added, as required.

The class hierarchy can be restructured so that the required attributes and operations can be inherited by the new class.

Characteristics of an existing class can be overridden and different versions of attributes or operations are implemented for the new class.

From Pressman

PolymorphismPolymorphism

case of graphtype:case of graphtype:

if graphtype = linegraph then DrawLineGraph (data);if graphtype = linegraph then DrawLineGraph (data);

if graphtype = piechart then DrawPieChart (data);if graphtype = piechart then DrawPieChart (data);

if graphtype = histogram then DrawHisto (data);if graphtype = histogram then DrawHisto (data);

if graphtype = kiviat then DrawKiviat (data);if graphtype = kiviat then DrawKiviat (data);

end case;end case;

All of the graphs become subclasses of a general class All of the graphs become subclasses of a general class called graph. Using a concept called overloading [TAY90], called graph. Using a concept called overloading [TAY90], each subclass defines an operation called each subclass defines an operation called drawdraw. An object . An object can send a can send a drawdraw message to any one of the objects message to any one of the objects instantiated from any one of the subclasses. The object instantiated from any one of the subclasses. The object receiving the message will invoke its own receiving the message will invoke its own drawdraw operation operation to create the appropriate graph. to create the appropriate graph.

graphtype drawgraphtype draw

ConventionalConventional approach …approach …

From Pressman

Object Oriented FrameworksObject Oriented Frameworks A object-oriented framework is not an architectural

pattern, but rather a skeleton with a collection of “plug points” (also called hooks and slots) that enable it to be adapted to a specific problem domain

It is like the earlier concept of library of modules Gamma et al. note that:

– Design patterns are more abstract than frameworks.– Design patterns are smaller architectural elements than

frameworks– Design patterns are less specialised than frameworks

From Pressman

ConclusioniConclusioni

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

ConclusioniConclusioni Le strategie proposte hanno la caratteristica della

sistematicità e, quindi, realizzano la tracciabilità dai requisiti al modello di progetto

Un processo di sviluppo del software prevede a questo punto la costruzione e il test del software costruito

reqX (doc. requisiti) reqX (doc. requisiti)

Funzione (Modello analitico)

Classe (Modello analitico)

Classe (Modello di progetto)

Modulo (Modello di progetto)