progettazione dettagliata delle componenti. tipologie di componente componenti convenzionali...
TRANSCRIPT
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
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)