Architectural Complexity

1. Architectural Complexity • A useful technique for assessing the overall complexity of a proposed architecture is to consider dependencies between components within the architecture. • 3 dependencies: • Sharing dependencies – relationships among consumers who uses the same resource. For example, for two components u and v, if u and v refer to the same global data, then there exists a shared dependence relationship between u and v. • Flow dependencies- relationship between producers and consumers of resources. For example, for two components u and v, if u must complete before control flows into v (prerequisite), or if u communicates with v by parameters, then there exists a flow dependence relationship between u and v.

2. Architectural Complexity 2 • Constrained dependencies – represent constraints on the relative flow of control among a set of activities. For example, for two components u and v, u and v cannot execute at the same time (mutual exclusion), then there exists a constrained dependence relationship between u and v.

3. Architectural Description Languages 3 • The architect of a house has a set of standardized tools and notation that allow the design to be represented in an unambiguous, understandable fashion. • Architectural description language (ADL) provides a semantics and syntax for describing a software architecture. • Hofmann and his colleagues [Hof01] suggest that an ADL should provide the designer with the ability to decompose architectural components, compose individual components into larger architectural blocks, and represent interfaces (connection mechanisms) between components

4. ARCHITECTURAL MAPPING USING DATA FLOW 4 There is no practical mapping for some architectural styles, and the designer must approach the translation of requirements to design for these styles in using the techniques discussed To illustrate one approach to architectural mapping, consider the call and return architecture—an extremely common structure for many types of systems. In order to perform the mapping, the type of information flow must be determined. One type of information flow is called transform flow and exhibits a linear quality. Data flows into the system along an incoming flow path where it is transformed from an external world representation into internalized form.

5. ARCHITECTURAL MAPPING USING DATA FLOW 5 Once it has been internalized, it is processed at a transform center. Finally, it flows out of the system along an outgoing flow path that transforms the data into external world form.

6. Transform Mapping 6 Transform mapping is a set of design steps that allows a DFD with transform flow characteristics to be mapped into a specific architectural style. To illustrate this approach, we again consider the SafeHome security function One element of the analysis model is a set of data flow diagrams that describe information flow within the security function. To map these data flow diagrams into a software architecture, you would initiate the following design steps: i) Step 1. Review the fundamental system model.

7. Transform Mappingi) Step 1. Review the fundamental system model.The fundamental system model or context diagram depicts the security function as a single transformation, representingthe external producers and consumers of data that flow into and out of the function. Next picture shows refined data flow for the security function Context-level DFD for the SafeHome Security function 7

8. Transform Mappingi) Step 1. Review the fundamental system model cont.refined data flow for the security function 8

9. Transform Mappingii) Step 2. Review and refine data flow diagrams for the softwareInformation obtained from the requirements model is refined to produce greater detail. For example, the level 2 DFD for monitor sensors is examined 9

10. Transform Mappingii) Step 2. Review and refine data flow diagrams for the softwareAt level 3, each transform in the data flow diagram exhibits relatively high cohesion That is, the process implied by a transform performs a single, distinct function that can be implemented as a component in the SafeHome software.Therefore, the DFD in Figure below contains sufficient detail for a “first cut” at the design of architecture for the monitor sensors subsystem, and we proceed without further refinement 10

11. Transform Mappingii) Step 3. Determine whether the DFD has transform or transaction flow characteristics.Evaluating the DFD (Figure below, we see data entering the software along one incoming path and exiting along three outgoing paths. Therefore, an overall transform characteristic will be assumed for information flow. 11

12. Transform Mappingii) Step 4. Isolate the transform center by specifying incoming and outgoing flow boundariesIncoming data flows along a path in which information is converted from external to internal form.outgoing flow converts internalized data to external form. Incoming and outgoing flow boundaries are open to interpretation- That is, different designers may select slightly different points in the flow as boundary locations 12

13. Transform Mappingii) Step 5. Perform “first-level factoring.”-The program architecture derived using this mapping results in a top-down distribution of control.- Factoring leads to a program structure in which top-level components perform decision making and lowlevelcomponents perform most input, computation, and output work-Middle-level components perform some control and do moderate amounts of work. 13

14. Transform Mappingii) Step 5. Perform “first-level factoring.”- This first-level factoring for the monitor sensors subsystem is illustrated in Figure below. main controller (called monitor sensorsexecutive) resides at the top of the program structure and coordinates the following subordinate control functions:An incoming information processing controller, called sensor input controller, coordinates receipt of all incoming data transform flow controller, called alarm conditions controller, supervises all operations on data in internalized form (e.g., a module that invokes various data transformation procedures).An outgoing information processing controller, called alarm output controller, coordinates production of output information 14

15. 15

16. Transform Mappingii) Step 6. Perform “second-level factoring.”Second-level factoring is accomplished by mapping individual transforms (bubbles) of a DFD into appropriate modules within the architecture.Beginning at the transform center boundary and moving outward along incoming and then outgoing paths, transforms are mappedinto subordinate levels of the software structure. The general approach to secondlevel factoring is illustrated in Figure below 16

17. Transform Mappingii) Step 6. Perform “second-level factoring.” 17

18. Transform Mappingii) Step 6. Perform “second-level factoring.”-Although Figure above illustrates a one-to-one mapping between DFD transforms and software modules, different mappings frequently occur. -Two or even three bubbles can be combined and represented as one component, or a single bubble may be expanded to two or more components 18

19. Transform Mappingii) Step 7. Refine the first-iteration architecture using design heuristics for improved software quality.Components are exploded or imploded to produce sensible factoring, separation of concerns, good cohesion, minimal coupling, and most important, a structure that can be implemented without difficulty, tested without confusion, and maintained without grief 19

20. Partitioning the Architecture “horizontal” and “vertical” partitioning are required

21. Horizontal Partitioning define separate branches of the module hierarchy for each major function use control modules to coordinate communication between functions function 3 function 1 function 2

22. Vertical Partitioning:Factoring design so that decision making and work are stratified (To form, arrange, or deposit in layers. decision making modules should reside at the top of the architecture decision-makers workers

23. Why Partitioned Architecture? results in software that is easier to test leads to software that is easier to maintain results in propagation of fewer side effects results in software that is easier to extend

24. Structured Design objective: to derive a program architecture that is partitioned approach: the Data Flow Diagram (DFD) is mapped into a program architecture the Process Specification (PSPEC) and STD are used to indicate the content of each module notation: structure chart

25. Structured Design Context-level DFD for the SafeHome Security function 25

26. Flow Characteristics Transform flow Transaction flow

27. Transform flow • Information must enter and exit software in an “external world” form. • Example : data typed on keyboard, tones on telephone line, • Incoming Flow = information enters the system along path that transform external data into external form • Transform centre = transition occurs • Outgoing flow = data begin to lead out the software.

28. Transform Mapping Set of design steps that allow a DFD with transform flow characteristics to be mapped into a specific architectural style. Consider the safe home security function

29. Transform mapping step Transform mapping is a set of design steps that allows a DFD with transform flow characteristics to be mapped into a specific architectural style. Review the fundamental system model - The fundamental system model or context diagram depicts the security function as a single transformation, representing the external producers and consumers of data that flow into and out of the function. Review and refine the DFD for the software- Information obtained from the requirements model is refined to produce greater detail Determine whether the DFD has flow or transaction flow characteristics.

30. Transform mapping step 30 • Isolate the transform centre by specifying outcoming and incoming flow boundaries - Incoming data flows along a path in which information is converted from external to internal form; outgoing flow converts internalized data to external form. Incoming and outgoing flow boundaries are open to interpretation • Perform first level factoring- The program architecture derived using this mapping results in a top-down distribution of control. Factoring leads to a program structure in which top-level components perform decision making and lowlevel components perform most input, computation, and output work. • Perform second level factoring- Second-level factoring is accomplished by mapping individual transforms (bubbles) of a DFD into appropriate modules within the architecture. • Refine the first iteration architecture using design heuristic for improved software quality.

31. General Mapping Approach isolate incoming and outgoing flow boundaries; for transaction flows, isolate the transaction center working from the boundary outward, map DFD transforms into corresponding modules add control modules as required refine the resultant program structure using effective modularity concepts

32. Transform Mapping

33. Factoring

34. First Level Factoring main program controller output input processing controller controller controller

35. Second Level Mapping

36. Transaction Flow incoming flow action path T

37. Transaction Example fixture fixture setting servos commands operator process report display operator screen commands robot control robot control software assembly record in reality, other commands would also be shown

38. Refining the Analysis Model write an English languageprocessing narrative 1. for the level 01 flow model apply noun/verb parse to isolate processes, data 2. items, store and entities develop level 02 and 03 flow models 3. create corresponding data dictionary entries 4. refine flow models as appropriate 5. ... now, we're ready to begin design!

39. Level 1 Data Flow Diagram operator Error msg fixture servos commands status read operator commands analyze fixture status determine command type Fixture setting fixture Valid command display screen select report report control robot generate send control value assembly record robot control

40. Level 2 Data Flow Diagram produce error msg command read command format setting status determine setting validate command read fixture status invalid command raw setting command combined status determine type valid command read record robot control record calculate output values send control value values format report report assembly record start/stop error msg fixture setting

41. Transaction Mapping Principles isolate the incoming flow path define each of the action paths by looking for the "spokes of the wheel" assess the flow on each action path define the dispatch and control structure map each action path flow individually

42. Transaction Mapping In many software application , a single data item triggers one of a number of information flows that effects a functions applied by trigerring the data item.

43. Transaction Mapping Data flow model f e a mapping d b x1 t g i h l k t b j m a x2 x4 x3 n n l x3.1 m g f h d e j i k program structure

44. Isolate Flow Paths error msg produce error msg command read command fixture setting format setting status determine setting validate command read fixture status invalid command raw setting command combined status determine type valid command read record robot control record calculate output values send control value values format report report assembly record start/stop

45. Map the Flow Model process operator commands command determine input type controller produce report read send validate fixture error generation command control command status message controller value controller each of the action paths must be expanded further

46. Refining the Structure Chart