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. 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 Tipici compiti di Progettazione

4. An Architectural Design Method: Structured Design "four bedrooms, three baths, lots of glass..." customer requirements 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. Structure Chart Notation Fan out=2 Fan out=1 Fan in=1 Fan in=2 Fan out=0 Non ammesso!! (constraints) c,d a,b c,d 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. Usually all flows are required One module = several functions in the DFD

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

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

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 A B D C U T a b d c e f

16. A B D C U T a b d c e f g Suggerimento: come prima ma è necessario leggere g root Get g 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 sort input or filter data from it are.

18. Example 1: RMS Calculating Software Compute- RMS 0 User Data- items 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 Data- items result Read- numbers 0.1 Validate- numbers 0.2 Compute- rms 0.3 Display 0.4 RMS numbers Valid - numbers error

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 Get-good-dataCompute-solutionDisplay-solution Get-data Validate-data Valid-numbers rms

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 Human Player Tic-tac-toe software 0 game result move

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

26. Example 2: Derived Structure Chart root Get-good-moveCompute-gameDisplay Get-move Validate- move play-move Check- winner 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 Red flows are alternative and exclusive, therefore only one output flow will be produced Transaction center A guideline to find transaction centers

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

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

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

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: A T a b c d

34. Structured Design and Extended DFD

35. 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-return implemented 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? Add intermediate lower layers Add back-end lower layers Add front-end lower layers ANALYSIS MODEL DESIGN

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

42. 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 level persistence 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 – A broker 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 Get… Prenotare Put… Pagare Get…Put… FarePrenotazione EseguirePagamento Transaction analysis

47. Example – Lift Control layered

48. Example – Lift Control Add replication

49. Analyzing Architectural Design by using Quality 1.Collect scenarios. 2.Elicit requirements, constraints, and environment description. 3.Describe the architectural styles/patterns that have been chosen to address the scenarios and requirements 4.Evaluate quality attributes (quality forecasting) by considering each attribute in isolation. 5.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)

51. Sintesi A B D C U T a b d c e f Fan out=2 Fan out=1 Fan in=1 Fan in=2 Fan out=0 c,dc,d a,ba,b c,dc,d Fan out=2 Fan out=1 Fan in=1 Fan in=2 Fan out=0 c,dc,d a,ba,b c,dc,d Fan out=2 Fan out=1 Fan in=1 Fan in=2 Fan out=0 c,dc,d a,ba,b c,dc,d Quality Analysis Styles+ Patterns Link di tracciabilità tra RE e DE

52. Sintesi UI AKA Presentation,View) Application (AKA Workflow,Process, Mediation,App Controller) Domain (AKA Business, Application Logic,Model) Technical Services (AKA Technical Infrastructure, High-level Technical Services) Foundation (AKA Core Services,Base Services, Low-level Technical Services/Infrastructure) Business Infrastructure (AKA Low-level Business Services) Styles Patterns Links di tracciabilità tra RE e DE

53. Conclusioni 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