Ingegneria della Progettazione (Design Engineering)

1. Ingegneria della Progettazione(Design Engineering) G. Berio

2. Esempi di regole sistematiche per definire un’architettura, dato uno stile architetturale ed un modello analitico

3. Tipici compiti di Progettazione • 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 generali, i principi di progettazione

4. An Architectural Design Method: Structured Design customer requirements "four bedrooms, three baths, lots of glass ..." architectural design

5. Structured Design • Seeks to conquer the complexity of large software through partitioning and hierarchical structuring. • Uses graphical tools to render software architecture more understandable.

6. Structured Design • Offers a set of strategies for developing a design solution from a well-defined requirement DFD specifications. • Offers a set of objectives and empirically justified criteria for forecasting some quality attributes of a given design solution.

7. Structured Design • DFD transformed by using rules and guidelines to structure chart – a hierarchical representation – a specific notation for representing a call-return architectural style (and often called a program structure) • The resulting call-return architecture is controlled and refined by using quality attributes metrics

8. Fan out=2 c,d Non ammesso!! (constraints) a,b c,d Fan out=1 Fan in=1 Fan in=2 Fan out=0 Structure Chart Notation Module (component) Arrows and parameters (connectors) Control hierarchy (semantic model of the style)

9. Characteristics of Structure Chart • Realises abstraction (may improve reusability and maintainability): • Low levels modules cannot invoke higher level modules • Fan-out (control reusability and maintainability): • Indicates how many modules are directly invoked by a given module; therefore, • Low fan-out represents modules with simple functionality • Fan-in (control reusability and maintainability) • indicates how many modules directly invoke a given module; therefore • High fan-in represents code reuse and is in general encouraged (but not in the initial steps of the design)

10. DFD diagrams to Structure Charts • Two strategies exist to guide transformation of a DFD in a structure chart: • Transformational Analysis • Transaction Analysis • These two strategies are usually mixed for making the transformation of the whole DFD

11. Transformational Analysis • The first step in transformational analysis requires to divide the DFD into 3 parts: • input, • logical processing, • output. One module = several functions in the DFD Usually all flows are required Usually all flows are required

12. Transformational Analysis • Grouped functions in the middle are called the transformation center Transformation center afferent efferent All flows are required

13. Transformational Analysis: details C c B d A b Root becomes c b a b c Get b B Put c c d Get a A C Put d d Get and Put modules can be interfaces to terminators (read and write) or modules to read and write data stores B is the transformation center

14. Transformational Analysis • The last step is to derive structure chart by drawing functional components for • the transformation center, • each afferent branch, • each efferent branch.

15. Esempio: trasformare il seguente DFD usando l’analisi trasformazionale C c B e d b D U f A T a

16. Esempio: trasformare il seguente DFD usando l’analisi trasformazionale C c B e d b D U f A T a g g root Suggerimento: come prima ma è necessario leggere g Get g

17. Transformational Analysis: find a transformation center • Identifying the highest level input and output transforms: • requires experience and skill. • Then: • follow on the DFD (some) inputs until a function is found whose output cannot be evaluated from these inputs alone. • functions which validate input are not central transforms. • functions which sortinput or filterdata from it are.

18. Example 1: RMS Calculating Software Compute- RMS0 Data-items User result Context Diagram

19. Example 1: RMS Calculating Software • From a cursory analysis of the problem description, easy to see that the system needs to perform: • accept the input numbers from the user, • validate the numbers, • calculate the root mean square of the input numbers, • display the result.

20. Example 1: RMS Calculating Software numbers Read-numbers0.1 Validate-numbers0.2 Valid -numbers Data-items error Compute-rms0.3 Display0.4 result RMS

21. Example 1: RMS Calculating Software • By observing the level 1 DFD: • identify read-number and validate-number functions as the afferent branch • display as the efferent branch.

22. Example 1: RMS Calculating Software root Valid-numbers rms rms Valid-numbers Get-good-data Compute-solution Display-solution Get-data Validate-data

23. Example 2: Tic-Tac-Toe Computer Game • As soon as either of the human player or the computer wins, • a message congratulating the winner should be displayed. • If neither player manages to get three consecutive marks along a straight line, • and all the squares on the board are filled up, • then the game is drawn. • The computer always tries to win a game.

24. Example 2:Context Diagram Tic-tac-toe software0 game result move Human Player

25. Example 2: Level 1 DFD game result Display-board-formatting move Validate-move Check-winner board Play-move

26. root Get-good-move Compute-game Display Validate-move Check-winner Get-move play-move Example 2:Derived Structure Chart Simplified SC (not showing Put modules)

27. Transaction Analysis • Transaction-driven software • one of several possible paths through the DFD is traversed depending upon the input flow data value. • Transform-centered software • characterized by similar processing steps for every data item processed by input, process, and output functions.

28. Transaction Analysis • Transaction: • Any input data value (indicated by regular expression on flow) that triggers functions. • For instance, selected menu options (various distinct flows with associated an option-value regular expression) might trigger different functions. • Transaction analysis divides software architecture (call-return) in: • several transaction modules • one transaction-center module.

29. Transaction Analysis A guideline to find transaction centers Transaction center Red flows are alternative and exclusive, therefore only one output flow will be produced

30. Transaction- center trans 3 trans 1 trans 2 type 1 type 2 type 3 Transaction analysis

31. Item-file Customer-history query statistics Accept-order inventory Customer-file Handle-query order Process-order Accepted-orders Vendor-list Handle-indent-request Sales-statistics Indent-request Indents pending-order Example 3:Level 1 DFD

32. root order query indent Handle-order Handle-indent Handle-query Accept-order Process-order Get-order Example 3:Derived Structure Chart

33. Suggerimenti • Provare ad applicare, se possible, ad un DFD sia l’analisi trasformazionale che l’analisi transazionale • Provare il punto di cui sopra al seguente DFD: d A b T a c

34. Structured Design and Extended DFD

35. Structured Design and Extended DFD • It starts from one Extended DFD • Structure charts can be employed but they are not really suitable because there the “control flow” (i.e. part of the “semantic model”) is fixed (and not defined in the DFD) while the “control flow” is explicitly provided in the Extended DFD by using statecharts • In principle, an extended DFD can be mapped on process and event (driven) architectures; depending on rule types however, it can also be mapped on rule-based architetures

36. Architectural Patterns and Extended DFD • Concurrency (an explicit event-scheduler over statecharts) • Persistency (events and conditions can be stored persistently; however, events and conditions consumptions should be defined) • Distribution and replication (distribute states with substates)

37. The usual OO Design Model Elaborated from Pressman

38. Architectures in OO • The main architectural style is layered (by definition), incrementing the class diagrams (from the analytical model); however, layered is combined with object-oriented (or call-returnimplemented with objects) to describe inter and intra-layer component behaviour • The structure of the architecture style is usually represented by using components and package diagrams • The “semantic model” of the architecture style can be represented throughout sequence diagrams

39. UML Component Diagram (with Packages

40. Why layered? DESIGN ANALYSIS MODEL Add intermediate lower layers Add back-end lower layers Add front-end lower layers

41. Layers are Named and Conceptual! DESIGN Model Add intermediate lower layers Add back-end lower layers Add front-end lower layers Core/Utility Interface Application

42. GUI windows reports UI Presentation speech interface ( AKA , View ) HTML , XML , XSLT , JSP , Javascript , ... app handles presentation layer requests specific workflow Application session state ( AKA Workflow , Process , y window / page transitions c Mediation , App Controller ) n e consolidation / transformation of disparate d n data for presentation e p e d handles application layer requests implementation of domain rules Domain domain services ( POS , Inventory ) ( AKA Business , - services may be used by just one Application Logic , Model ) application , but there is also the possibility of multi - application services very general low - level business services Business Infrastructure used in many business domains ( AKA Low - level Business Services ) CurrencyConverter ( relatively ) high - level technical services Technical Services and frameworks ( AKA Technical Infrastructure , Persistence , Security High - level Technical Services ) low - level technical services , utilities , Foundation and frameworks ( AKA Core Services , Base Services , data structures , threads , math , Low - level Technical Services / Infrastructure ) file , DB , and network I / O width implies range of applicability N-layers Architecture

43. Architectural Patterns • Concurrency—applications must handle multiple tasks in a manner that simulates parallelism • task scheduler pattern • Persistence—Data persists if it survives past the execution of the software that created it. Two patterns are common: • a database management system pattern that applies the storage and retrieval capability of a DBMS to the application • an application levelpersistence pattern that builds persistence features into the application • Distribution (and replication)—the manner in which systems or components within systems communicate with one another in a distributed environment • Abroker acts as a ‘middle-man’ between the client component and a server component. From Pressman

44. Specify Components • One definition and what a component is and what it provides can be called component specification • A component specification is described by notations (informal, semi-formal, formal) and, if increments and transformations are applied between RE and DE, component specifications are primarily reformulation-aggregation of requirements specifications • For instance, a module corresponding to several functions (in DFD) can be specified by common language or pre and post conditions • Object-oriented classes are already specified during RE but they can be better specified by using UML; groups of classes like packages and components (ports and interfaces) are specified in a way similar to classes (by using UML diagrams)

45. Example – Online Train Ticketing root Get…. Prenota&Paga Put… Prenota&Paga: Pre: Un viaggio è stato scelto, le opzioni di prenotazione sono disponibili; un mezzo di pagamento appropriato è disponibile Post: se pagamento andato a buon fine  posto prenotato per il viaggio scelto Transformation center

46. Example – Online Train Ticketing root Prenotare Pagare Get… FarePrenotazione Put… Transaction analysis Get… EseguirePagamento Put…

47. Example – Lift Control layered

48. Example – Lift Control Add replication

49. Analyzing Architectural Design by using Quality • Collect scenarios. • Elicit requirements, constraints, and environment description. • Describe the architectural styles/patterns that have been chosen to address the scenarios and requirements • Evaluate quality attributes (quality forecasting) by considering each attribute in isolation. • Identify the sensitivity of quality attributes to various architectural characteristics for a specific architectural style. • 6. Critique candidate architectures (developed in step 3) using the sensitivity analysis conducted in step 5. Elaborated from Pressman

50. Analyzing Architectural Design by using Quality • The outcome of the analysis is one architecture, the components with their specifications and possibly groups (packages) of components • Components should be related to requirements (traceability requirements to design)