progettazione dettagliata delle componenti. tipologie di componente componenti convenzionali...

Progettazione Dettagliata Progettazione Dettagliata delle Componentidelle Componenti

Tipologie di ComponenteTipologie di Componente

Componenti convenzionali (funzioni, procedure, programmi…)

Componenti OO (classi, insiemi di classi, oggetti)

Components and Components and Design PrinciplesDesign Principles

Several design principles are realised by looking at the concept of component:– Hides Information– Abstracts data, control and function to a certain

degree (and with a certain focus)– Modularises the software– Can be internally refined (as it happens for

architectures)

C IIAn interface usually enables performing functions/procedures

S

Progettazione delle Progettazione delle ComponentiComponenti

Nel caso della progettazione strutturata, la valutazione delle componenti procede applicando di fatto un design principle cioè functional independence

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

In entrambe i casi è ragionevole applicare il refactoring (ovvero ristrutturazione) per migliorare il risultato mantenendo l’”equivalenza”

I tre casi, possono operare su componenti i cui dettagli interni sono completamente noti ma anche componenti sommariamente descritti, come risultato dai precedenti passi di progettazione che hanno introdotto e raffinato un’architettura

Describing the Describing the internal structure of the modulesinternal structure of the modules

The 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

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

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 inherent in a flow chart is suppressed in a structure chart.

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

InheritanceInheritance Design options:

– The class can be designed and built from scratch. That is, inheritance is not used.

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

Frameworks Frameworks (OO)(OO)

A framework (OO) 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 specialized than frameworks

From Pressman

Functional Independence:Functional Independence:Two ViewsTwo Views

MODULE

What's inside??

How big is it??

Functional IndependenceFunctional Independence

COHESION - the degree to which a module performs one and only one function. COUPLING - the degree to which a module is "connected" to other modules in the system.

Low Coupling and High Cohesion

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

Elaborated From Pressman

Partially, the design principle is guaranteed by a well defined requirement specification

Classification of CohesivenessClassification of Cohesiveness

coincidentallogical

temporal

procedural

sequential

communicational

functional

Degree of cohesion

High

Low

Classes of couplingClasses 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 functions.

functions 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:– The set of functions responsible for

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

Procedural cohesionProcedural cohesion

The set of functions of the module certain sequences of steps have to be carried out in a certain order for achieving an objective

Example:

Communicational cohesionCommunicational cohesion

All functions of the module reference or update the same data structure

Example: – the set of functions defined on an array

or a stack.

Sequential cohesionSequential cohesion

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

Example: sort

search

display

Functional cohesionFunctional cohesionDifferent elements of a module cooperate

to achieve a single function

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

Data couplingData coupling

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

Two 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 part are not used

Composite data item:record in PASCAL structure in Cclass in Java

Control couplingControl coupling

Data from one module is used to direct order of instruction execution in another

Example of control coupling:

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

Common CouplingCommon Coupling

Two modules are common coupled if they share some global data.

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 Design PrinciplesDesign Principles

metrics Quality attributes

metrics Quality attributesCoupling and cohesion

Fan-in, Fan-out

Limited Fan-ou and higher Fan-in for each module

Modules are loosely coupled and highly cohesed

(not sure)

Evaluating Quality by using Evaluating Quality by using Design PrinciplesDesign Principles

Clearly Fan-in and Fan-out metrics are only very approximate ways to understand coupling and cohesion of modules

Example is the “online train ticket case study”

A C B

Valutare Costo

Valutare Costo&Disponibilità

Get Costo

Get OpzioniViaggio

costoOpzioni+Viaggio

Valutare Costo

I1 I2

Cohesion? Coupling?

Valutare la coesione non Valutare la coesione non necessita la rappresentazione necessita la rappresentazione dettagliata di una componentedettagliata di una componente

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

A C B

Valutare Costo

Valutare Costo&Disponibilità

Get Costo

Get OpzioniViaggio

costoOpzioni+Viaggio

Valutare Costo

I1 I2

Valutare Costo

Opzioni+Viaggio

M

costo

costo costocosto

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

ConclusioniConclusioni

Architectural views

Requirementengineering Design

engineering

Architecture design

Component design

Architecturalpatterns

Architecturalstyles

Design patterns

Quality attributes

(stakeholders)

Increment and tranformation guidelines

DetailedComp. design

Design principles

ConclusioniConclusioni Gli approcci proposti hanno la caratteristica della

sistematicità e, quindi, della precisa realizzazione della tracciabilità dai requisiti al modello di progetto

Un processo di sviluppo prevede quindi 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)