1. Progettazione Dettagliata delle Componenti

2. Tipologie di Componente Componenti convenzionali (funzioni, procedure, programmi…) Componenti OO (classi, insiemi di classi, oggetti)

3. Components and Design 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 I I An interface usually enables performing functions/procedures S

4. Progettazione delle Componenti 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

5. Describing the internal 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

6. 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 yes no dummy yes no

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

8. Decision Table From Pressman

9. Program Design Language (PDL) From Pressman

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

11. Inheritance 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

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

13. Frameworks (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

14. Functional Independence: Two Views

15. Functional Independence 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

16. Classification of Cohesiveness coincidental logical temporal procedural sequential communicational functional Degree of cohesion High Low

17. Classes of coupling content common stamp control data Degree of coupling Low High

18. 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 functions. functions have been put in the module out of pure coincidence without any thought or design.

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

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

21. Procedural 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:

22. Communicational 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.

23. Sequential 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

24. Functional cohesion Different 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.

25. 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.

26. 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 part are not used Composite data item: record in PASCAL structure in C class in Java

27. Control 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

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

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

30. Evaluating Quality by using Design Principles metricsQuality attributes metrics Quality attributes Coupling 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)

31. Evaluating Quality by using Design 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” ACB Valutare Costo Valutare Costo& Disponibilità Get Costo Get OpzioniViaggio costo Opzioni+Viaggio Valutare Costo I1I2 Cohesion? Coupling?

32. Valutare la coesione non necessita la rappresentazione dettagliata di una componente

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

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

35. 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 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

36. 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

37. Refactoring (Online Train Tickets) ACB Valutare Costo Valutare Costo& Disponibilità Get Costo Get OpzioniViaggio costo Opzioni+Viaggio Valutare Costo I1I2 Valutare Costo Opzioni+Viaggio M costo

38. 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!

40. 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

41. Conclusioni Architectural views Requirement engineering Design engineering Architecture design Component design Architectural patterns Architectural styles Design patterns Quality attributes (stakeholders) Increment and tranformation guidelines Detailed Comp. design Design principles

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