Post on 01-May-2015
transcript
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
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)