La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

Progettazione dettagliata delle Componenti. Cosa significa progettare in dettaglio una componente Progettare unarchitettura, usando uno stile architetturale.

Presentazioni simili


Presentazione sul tema: "Progettazione dettagliata delle Componenti. Cosa significa progettare in dettaglio una componente Progettare unarchitettura, usando uno stile architetturale."— Transcript della presentazione:

1 Progettazione dettagliata delle Componenti

2 Cosa significa progettare in dettaglio una componente Progettare unarchitettura, usando uno stile architetturale (usando, il più possibile, passaggi o incrementi sistematici, dal modello analitico) Completare larchitettura, usando alcuni pattern architetturali, focalizzandosi sugli attributi di qualità di interesse Analizzare larchitettura, relativamente alla valutazione previsionale della qualità del software (ed ai costi) Progettare in dettaglio le singole componenti dellarchitettura, 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

3 Tipologie di Componente Componenti convenzionali (funzioni, procedure, programmi…) Componenti object-oriented (classi, insiemi di classi, oggetti)

4 Specifica 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 lintroduzione di diagrammi di sequenza, ove sia classi che diagrammi di sequenza sono legati al modello analitico (oppure ad altre componenti)

5 (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 è luso di design pattern In entrambe i casi, se la qualità previsionale risultante non è sufficiente, è ragionevole, applicare il refactoring (ristrutturazione) per migliorare il risultato mantenendo lequivalenza

6 Esempi di Progettazione Valida Opzioni di Costo Calcola Costo root Get…Prenotare&PagarePut… raffinamento AscensorePartire Subject Piano Observer Fermare Design pattern Observer (applicato internamento alla componente Movimento)

7 Valutazione previsionale della qualità delle componenti: il caso della indipendenza funzionale tra le componenti

8 Functional Independence: Two Views of a Component

9 Functional 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

10 Degrees of Cohesiveness coincidental logical temporal procedural sequential communicational functional Degree of cohesion High Low

11 Degrees of coupling content common stamp control data Degree of coupling Low High

12 Coincidental 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.

13 Logical 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

14 Temporal 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.

15 Procedural 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

16 Communicational cohesion All parts of a module reference or update the same data structure Example: Get Tariffe Get Treno-Tariffe Get Regole

17 Sequential 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 Costo Prenotare&Pagare

18 Functional 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

19 Data 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.

20 Stamp 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 parts of the structure are not used Examples of composite data items: – record in PASCAL – structure in C – class in Java

21 Control coupling Data from one module is used to direct order of instruction execution in another Example: – a flag set in one module and tested in another module root Get…Prenotare&PagarePut… Prenotare?

22 Common coupling Two modules are common coupled if they share some global data. Example: – Directly referring to the same database or variable Get TariffeGet Rete

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

24 Evaluating Quality by using Function Indipendence Metrics: one example MetricsQuality attributes Metrics Maintainability; Evolvabilty; Reusability; Comprehensibility; Low Coupling High Cohesion Fan-in, Fan-out Limited 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

25 Evaluating Quality by using Function Indipendence Metrics: one 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&Pagare Put 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)

26 Altre metriche sulla specifica di una componente sequential cohesion

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

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

29 Refactoring: 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

30 Refactoring in Structured Design Generally 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

31 Refactoring (Online Train Tickets) root Get Viaggio, Opzioni di Costo, Opzioni di Prenotazione, Rete, Tariffe, Prenotazioni, Dati CC Prenotare&Pagare Put Costo, Viaggio, Posti, Riepilogo, Prenotazioni, Biglietti Cohesion : Communication Coupling: Cohesion: Procedural Coupling: Control (with GetPut), Control (with Prenotare&Pagare) Cohesion: Procedural Coupling: Control (with GetPut), Control (with Prenotare&Pagare) Get All Tables Put All Tables PrenotarePagare Abstraction Refinement Cohesion : Functional Coupling: Data (with Get and Put)

32 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!

33

34 Refactoring Class Diagram Example ViaggioTreno Prenotazione Treno Viaggio 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

35 Descrizione dettagliata delle componenti

36 Describing the internal structure of conventional components 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 From Pressman

37 Flow 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=20P=80 Print yesno dummy yes no From Pressman

38 Flow Chart versus Structure 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

39 Decision Table From Pressman

40 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

41 Describing the internal structure 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 well Data types for class attributes must be defined Associations should be implemented Inheritance and polymorphism can be used as well (and Framework)

42 Inheritance 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

43 Polymorphism case of graphtype: if graphtype = linegraph then DrawLineGraph (data); if graphtype = piechart then DrawPieChart (data); if graphtype = histogram then DrawHisto (data); if graphtype = kiviat then DrawKiviat (data); end case; All of the graphs become subclasses of a general class called graph. Using a concept called overloading [TAY90], each subclass defines an operation called draw. An object can send a draw message to any one of the objects instantiated from any one of the subclasses. The object receiving the message will invoke its own draw operation to create the appropriate graph. graphtype draw Conventional approach … From Pressman

44 Object 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

45 Conclusioni Requirement engineering Design engineering Architecture design Component design Architectural patterns Architectural styles Design patterns Quality attributes Architectural views (stakeholders) Increment and tranformation guidelines/rules Detailed comp. design Design principles FI,R,A,M,H

46 Conclusioni 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) Funzione (Modello analitico) Classe (Modello analitico) Classe (Modello di progetto) Modulo (Modello di progetto)


Scaricare ppt "Progettazione dettagliata delle Componenti. Cosa significa progettare in dettaglio una componente Progettare unarchitettura, usando uno stile architetturale."

Presentazioni simili


Annunci Google