Choosing an Architectural style

1. Choosing an Architectural style

2. Rules of Thumb for Choosing Styles The goal of style catalogs is to develop a design handbook: �If your problem looks like x, use style y.� The practice is not that advanced yet. The best that we can do is offer rules of thumb. The problem with the table on the preceding slide is that it is not repeatable, at least not without deep knowledge of the various architectural styles, their costs and benefits, and an understanding of how each style accommodates the problem at hand. This appears to be in conflict with one of the goals of using a style catalog to enable designing with patterns and styles: that a novice should be able to easily apply expert knowledge, as encapsulated and represented by these designs. In practice, however, it is not as simple as using a handbook that will tell you to use style �y� if your problem looks like �x�. The practice is not yet that advanced; the best we can do is offer rules of thumb for choosing styles. The next section of the lecture offers a quick look at the rules of thumb for choosing styles and substyles discussed previously in this lecture. The problem with the table on the preceding slide is that it is not repeatable, at least not without deep knowledge of the various architectural styles, their costs and benefits, and an understanding of how each style accommodates the problem at hand. This appears to be in conflict with one of the goals of using a style catalog to enable designing with patterns and styles: that a novice should be able to easily apply expert knowledge, as encapsulated and represented by these designs. In practice, however, it is not as simple as using a handbook that will tell you to use style �y� if your problem looks like �x�. The practice is not yet that advanced; the best we can do is offer rules of thumb for choosing styles. The next section of the lecture offers a quick look at the rules of thumb for choosing styles and substyles discussed previously in this lecture.

3. Data-Flow Style Use if it makes sense to view your system as one that produces a well-defined, easily-identified output that is the direct result of sequentially transforming a well-defined, easily-identified input in a time-independent fashion integrability (in this case, resulting from relatively simple interfaces between components) is important Use the data-flow style if it makes sense to view your system as one that produces a well-defined, easily-identified output that is the direct result of sequentially transforming a well-defined, easily-identified input in a time-independent fashion. integrability (in this case, resulting from relatively simple interfaces between components) is important.Use the data-flow style if it makes sense to view your system as one that produces a well-defined, easily-identified output that is the direct result of sequentially transforming a well-defined, easily-identified input in a time-independent fashion. integrability (in this case, resulting from relatively simple interfaces between components) is important.

4. Data-Flow Substyles Pipe and filter: the computation involves transformations on continuous streams of data Closed loop control: your system involves controlling continuing action, is embedded in a physical system, and is subject to unpredictable external perturbation so that preset algorithms go awry Use the dataflow network substyle if the input and output both occur as a recurring series (in which the output of one is the input of the next), and there is a direct correlation between corresponding members of each series. Use the pipeline, UNIX pipe-and-filter substyle if the computation involves transformations on continuous streams of data, or if the transformations are incremental (one transformation can begin before the previous step is completed). Use the closed loop control substyle if your system involves controlling continuing action, is embedded in a physical system, and is subject to unpredictable external perturbation so that preset algorithms go awry.Use the dataflow network substyle if the input and output both occur as a recurring series (in which the output of one is the input of the next), and there is a direct correlation between corresponding members of each series. Use the pipeline, UNIX pipe-and-filter substyle if the computation involves transformations on continuous streams of data, or if the transformations are incremental (one transformation can begin before the previous step is completed). Use the closed loop control substyle if your system involves controlling continuing action, is embedded in a physical system, and is subject to unpredictable external perturbation so that preset algorithms go awry.

5. Call-and-Return Style Use if the order of computation is fixed, and components can make no useful progress while awaiting the results of requests to other components Use the call-and-return style if the order of computation is fixed, and components can make no useful progress while awaiting the results of requests to other components (that is, if there is no parallelism).Use the call-and-return style if the order of computation is fixed, and components can make no useful progress while awaiting the results of requests to other components (that is, if there is no parallelism).

6. Call-and-Return Substyles -1 Object-oriented: overall modifiability and integrability (via careful attention to interfaces) are driving quality requirements Abstract data types: many system data types whose representation is likely to change Objects: many like modules, commonalties could be exploited through inheritance Call-and-return-based client-server: modifiability with respect to the production of data and how it is consumed is important Use the object-oriented substyle if overall modifiability and integrability (via careful attention to interfaces) are driving quality requirements. Use the abstract data types substyle if there are many system data types whose representation is likely to change. Use the objects substyle if information-hiding results in many like modules whose development time and testing time could benefit from exploiting the commonalties through inheritance. Use the call-and-return-based client-server substyle when modifiability with respect to the production of data and how it is consumed is important. Use the object-oriented substyle if overall modifiability and integrability (via careful attention to interfaces) are driving quality requirements. Use the abstract data types substyle if there are many system data types whose representation is likely to change. Use the objects substyle if information-hiding results in many like modules whose development time and testing time could benefit from exploiting the commonalties through inheritance. Use the call-and-return-based client-server substyle when modifiability with respect to the production of data and how it is consumed is important.

7. Call-and-Return Substyles -2 Layered if the tasks in your system can be divided between those specific to the application and those generic to many applications but specific to the underlying computing platform if portability across computing platforms is important if you can use an already-developed computing infrastructure layer (operating system, network management package, etc.) Use the layered substyle if the tasks in your system can be divided between those specific to the application and those generic to many applications but specific to the underlying computing platform; if portability across computing platforms is important; or if you can use an already-developed computing infrastructure layer (operating system, network management package, etc.). Use the layered substyle if the tasks in your system can be divided between those specific to the application and those generic to many applications but specific to the underlying computing platform; if portability across computing platforms is important; or if you can use an already-developed computing infrastructure layer (operating system, network management package, etc.).

8. Independent Component Style Use if your system runs on a multi-processor platform (or may do so in the future) your system can be structured as a set of loosely coupled components meaning that one component can continue to make progress somewhat independently of the state of other components performance tuning is important by re-allocating work among processes Use the independent component style if your system runs on a multi-processor platform (or may do so in the future); if your system can be structured as a set of loosely coupled components (meaning that one component can continue to make progress somewhat independently of the state of other components); if performance tuning (by re-allocating work among processes) is important; or if performance tuning (by re-allocating processes to processors) is important. Use the independent component style if your system runs on a multi-processor platform (or may do so in the future); if your system can be structured as a set of loosely coupled components (meaning that one component can continue to make progress somewhat independently of the state of other components); if performance tuning (by re-allocating work among processes) is important; or if performance tuning (by re-allocating processes to processors) is important.

9. Independent Component Substyles Communicating processes: message-passing is sufficient as an interaction mechanism Lightweight processes: access to shared data is critical to meet performance goals Distributed objects: the reasons for the object-oriented style and the interacting process style all apply Use the communicating processes substyle if message-passing is sufficient as an interaction mechanism. Use the lightweight processes substyle if access to shared data is critical to meet performance goals. Use the distributed objects substyle if the reasons for the object-oriented style and the interacting process style all apply. Use the communicating processes substyle if message-passing is sufficient as an interaction mechanism. Use the lightweight processes substyle if access to shared data is critical to meet performance goals. Use the distributed objects substyle if the reasons for the object-oriented style and the interacting process style all apply.

10. Independent Component Substyles Broadcast: all of the components need to be synchronized from time to time, and/or availability is an important requirement Event systems: you want to decouple the consumers of events from their signalers, or you want scalability in the form of adding processes that are triggered by events already detected/signaled in the system Use the broadcast substyle if all of the components need to be synchronized from time to time, and/or availability is an important requirement. Use the event systems substyle if you want to decouple the consumers of events from their signalers, or you want scalability in the form of adding processes that are triggered by events already detected/signaled in the system. Use the broadcast substyle if all of the components need to be synchronized from time to time, and/or availability is an important requirement. Use the event systems substyle if you want to decouple the consumers of events from their signalers, or you want scalability in the form of adding processes that are triggered by events already detected/signaled in the system.

11. Data-Centered Style Use if central issue is the storage, representation, management, and retrieval of a large amount of related long-lived data transactional database/repository: order of component execution is determined by a stream of incoming requests to access/update the data, and the data is highly structured blackboard: you want scalability in the form of adding consumers of data without changing the producers; or you want modifiability in the form of changing who produces and consumes which data Use the data-centered style if central issue is the storage, representation, management, and retrieval of a large amount of related long-lived data. Also used for integrability where communication among components is via data. Use the transactional database/repository substyle if the order of component execution is determined by a stream of incoming requests to access/update the data, and the data is highly structured. Use the blackboard substyle if you want scalability in the form of adding consumers of data without changing the producers; or you want modifiability in the form of changing who produces and consumes which data. Use the data-centered style if central issue is the storage, representation, management, and retrieval of a large amount of related long-lived data. Also used for integrability where communication among components is via data. Use the transactional database/repository substyle if the order of component execution is determined by a stream of incoming requests to access/update the data, and the data is highly structured. Use the blackboard substyle if you want scalability in the form of adding consumers of data without changing the producers; or you want modifiability in the form of changing who produces and consumes which data.

12. Virtual Machine Style Use if you have designed a computation, but have no fixed machine to run it on Use the virtual machine style if you have designed a computation, but have no fixed machine on which to run it. An example of this use of virtual machine is Java machine. This style is also used to allow portability, such as hiding details of an operating system to allow for change in the operating system or hiding details of the user interface toolkit to allow for change in toolkit. (See layered style.)Use the virtual machine style if you have designed a computation, but have no fixed machine on which to run it. An example of this use of virtual machine is Java machine. This style is also used to allow portability, such as hiding details of an operating system to allow for change in the operating system or hiding details of the user interface toolkit to allow for change in toolkit. (See layered style.)

13. Unit operations Codification of design operations applied to an architecture. Include: abstraction compression part-whole decomposition is-a decomposition replication resource sharing

14. Abstraction Creates a virtual component. Used for: simulated target platform layered systems common interface to heterogeneous set of underlying implementations

15. Compression Combines two components into a single component Used to: enhance performance speed up system development

16. Decomposition Breaks up a large component into smaller pieces. Part-whole Decomposition Components are built from a fixed small set of subcomponents (e.g: model view controller). For integrability, extensibility, and understandability

17. Decomposition Is-a Decomposition A subcomponent represents a specialization of its parent's functionality (e.g.: class hierarchies). Used for reuse by increments.

18. Replication Exact duplication of a component Used for enhancing reliability (redundant operation) performance enhancement (data caching)

19. Resource Sharing Encapsulates either data or services and shares them among multiple independent consumers (examples: shared databases, servers in client/servers). Used for: integrability portability modifiability

20. Unit Operations and Qualities We are interested not only in the ways in which unit operations help or hinder the achievement of qualities, but also in the manner in which quality attributes interact. It is obvious that one cannot maximize all quality attributes. In the realm of software, we are interested in understanding the effect and interactions of unit operations with respect to scalability, integrability, portability, performance (sequential and concurrent), fault tolerance, ease of system creation, overall system modifiability, individual component modifiability, and reusability. Based on surveys of expert software designers, we can summarize the gross relationships among the six unit operations just discussed and the 11 distinct quality attributes mentioned in this paragraph. A �+� in the table indicates a positive relationship between an operation and a quality attribute: that is, the use of this operation aids in the achievement of the quality goal. A �-� in the table indicates the opposite effect. Finally, a blank cell indicates that, depending on the context of use, the operation might have a positive or negative effect. For example, part-whole decomposition aids in portability if and only if the portions that change from platform to platform have been isolated into a single part. Otherwise, the decomposition actually hinders decomposition because the changes to be made are nonlocal; they are spread out among the parts. Similarly, the blank in the portability entry for resource sharing is because portability is enhanced when the shared resource is the only thing that needs to be ported (and hence the changes are local) and is reduced when both the shared resource and the users of the resource need to be changed (so changes are nonlocal). This table is not meant to present a final authority with respect to unit operations and quality attributes. The point is that these operations have complex interactions, and the effect of a unit operation in terms of a quality attribute is not a simple one.We are interested not only in the ways in which unit operations help or hinder the achievement of qualities, but also in the manner in which quality attributes interact. It is obvious that one cannot maximize all quality attributes. In the realm of software, we are interested in understanding the effect and interactions of unit operations with respect to scalability, integrability, portability, performance (sequential and concurrent), fault tolerance, ease of system creation, overall system modifiability, individual component modifiability, and reusability. Based on surveys of expert software designers, we can summarize the gross relationships among the six unit operations just discussed and the 11 distinct quality attributes mentioned in this paragraph. A �+� in the table indicates a positive relationship between an operation and a quality attribute: that is, the use of this operation aids in the achievement of the quality goal. A �-� in the table indicates the opposite effect. Finally, a blank cell indicates that, depending on the context of use, the operation might have a positive or negative effect. For example, part-whole decomposition aids in portability if and only if the portions that change from platform to platform have been isolated into a single part. Otherwise, the decomposition actually hinders decomposition because the changes to be made are nonlocal; they are spread out among the parts. Similarly, the blank in the portability entry for resource sharing is because portability is enhanced when the shared resource is the only thing that needs to be ported (and hence the changes are local) and is reduced when both the shared resource and the users of the resource need to be changed (so changes are nonlocal). This table is not meant to present a final authority with respect to unit operations and quality attributes. The point is that these operations have complex interactions, and the effect of a unit operation in terms of a quality attribute is not a simple one.

21. Software Architecture Evaluation

22. When and Why To Analyze Architecture -1 When building a system Architecture is the earliest artifact where tradeoffs are visible. Analysis should be done when deciding on architecture. The reality is that analysis is often done during damage control, later in the project.

23. When and Why To Analyze Architecture -2 When acquiring a system Architectural analysis is useful if the system will have a long lifetime within organization. Analysis provides a mechanism for understanding how the system will evolve. Analysis can also provide insight into other visual qualities.

24. Architectural Reviews Questioning techniques: to evaluate any aspect of an architecture for any given reason Scenario-based techniques (e.g: SAAM) Questionnaire-based techniques Measuring techniques: to answer questions about a specific quality Metrics: quantitative interpretations of observable measures (e.g: complexity metrics, performance metrics) Simulations, prototypes, experiments: domain-specific models of an architecture or performance model

25. Review Process Preconditions Understand the context of the review Planned review vs Unplanned review Timing of the review (early, full) Assemble the right people Set organizational expectations and support Prepare for review (Read-Ahead Material) Obtain representation of the architecture

26. Review Process Activities of the review itself Evaluate e.g: "run" the scenarios, answer the items in checklist, perform experiments, execute the prototypes Record issues (and members comments) Rank the issues (project-threatening, major, minor)

27. Review Process Activities of the review itself Watch Warning signs architecture forced to match organization top-level components number over 25 one requirement drives entire design architecture depends on alternatives in the operating system choice of software components is dictated by hardware personnel redundancy not needed for reliability design is exception driven no identifiable architect

28. Review Process Report of review results Set of ranked issues Enhanced system documentation Set of scenarios for future use Identification of potentially reusable components Estimation of costs and benefits

29. Architecture Analysis Method (SAAM) Most useful in evaluating non-runtime qualities Specifies context through scenarios. SAAM steps Identify and assemble stakeholders Develop and prioritize scenarios Describe candidate architecture(s) Classify scenarios as direct or indirect Perform scenario evaluation Reveal scenario interactions Generate overall evaluation

30. SAAM Analysis produces Technical results: provides insight into system capabilities Social results forces some documentation of architecture acts as communication vehicle among stakeholders

31. Scenarios A scenario is a brief description of a stakeholder�s interaction with a system. When creating scenarios, it is important to consider all stakeholders, especially end users developers maintainers system administrators

32. Step 1: Identify and Assemble Stakeholders -1

33. Step 1: Identify and Assemble Stakeholders -2

34. Step 1: Identify and Assemble Stakeholders -3

35. Step 2: Stakeholders Develop and Prioritize Scenarios Scenarios should be typical of the kinds of activities that the system must support: functionality development activities change activities Scenarios also can be chosen to give insight into the system structure. Scenarios should represent tasks relevant to all stakeholders. Rule of thumb: 10-20 scenarios

36. Step 3: Describe Candidate Architectures -1 It is frequently necessary to elicit appropriate architectural descriptions. Structures chosen to describe the architecture will depend on the type of qualities to be evaluated. Static structures will be used to evaluate modification scenarios. Dynamic structures will be used to evaluate runtime qualities.

37. Step 3: Describe Candidate Architectures -2 Typically, the architect is asked to bring the following documentation to an evaluation, as a starting point: a description of the logical or module structure, with a clear definition of the responsibilities of each component a description of the process structure a data flow diagram showing how the modules interact at run time a description of the interconnection mechanism(s) used to distribute data and control among architectural components at run time a description, if needed, of the �uses� structure, showing how potential subsets will be realized

38. Step 4: Classify Scenarios There are two classes of scenarios. Direct scenarios are those that can be executed by the system without modification. Indirect scenarios are those that require modifications to the system. The classification depends upon both the scenario and the architecture. The classification should have gradations. indirect: How hard is the change? (SAAM elicits this information.) direct: How hard is it to execute? (SAAM does not consider this.)

39. Step 5: Perform Scenario Evaluation For each indirect scenario identify the components, data connections, control connections, and interfaces that must be added, deleted, or modified estimate the difficulty of modification Difficulty of modification is elicited from the architect and is based on the number of components to be modified and the effect of the modifications. A monolithic system will score well on this step, but not on next step.

40. Step 6: Reveal Scenario Interactions When multiple indirect scenarios affect the same components, this could indicate a problem. could be good, if scenarios are variants of each other change background color to green change background color to red could be bad, indicating a potentially poor separation of concerns change background color to red port system to a different platform

41. Step 7: Generate Overall Evaluation Not all scenarios are equal. The organization must determine which scenarios are most important. Then the organization must decide as to whether the design is acceptable �as is� or if it must be modified.

42. Interaction of SAAM Steps

43. Example 1: KWIC Two architectures: shared memory and abstract data type (ADT) Four scenarios 1. Operate in an incremental rather than a batch fashion. Program to accept one sentence at a time. 2. Program to eliminate entries beginning with �noise� words. 3. Change the internal representation of sentences (e.g., compressed or uncompressed). 4. Change the internal representation of the intermediate data structure (e.g., store indexes as shifted sentences or as pointers to input).

44. Solution 1:Shared Memory

45. Solution 2: Abstract Data Types

46. Evaluation of architectures Scenario 1 (operate in incremental mode) Shared-Memory - Modification of Input to yield control after each sentence Master Control (routines are called repetitively) Alphabetizer to be incremental (e.g. insertion sort) Abstract Data Type Input to yield control after each sentence Master Control (routines are called repetitively) Alphabetizer to be incremental (e.g. insertion sort) Tie for both architectures

47. Evaluation of architectures Scenario 2 (elimination of noise words) Shared-Memory � Modification of Circular Shift to eliminate shifted sentences beginning with noise words Abstract Data Types � Modification of Circular Shift to eliminate shifted sentences beginning with noise words

48. Evaluation of architectures Scenario 3 (modify internal representation of input sequence) Shared-Memory � Modification of All except Master Control Abstract Data Types � Modification of Characters abstraction Abstract Data Types architecture scores better

49. Evaluation of architectures Scenario 4 (modify representation of intermediate data structures) Shared-Memory � Modification of Circular Shift Alphabetizer Output Abstract Data Types � Modification of Circular Shift Alphabetizer Abstract Data Types architecture scores better

50. Shared Memory KWIC

51. ADT KWIC

52. Scenario Interaction Analysis ADT is better Both architectures show scenario interaction in same number of components Shared-Memory: Contention is among 3 of the scenarios in 2 components (Circular Shift, Alphabetizer) ADT: no component has contention for more than 2 scenarios

53. Evaluation of This Scenario Set

54. Example 2: SAAM Applied to Revision Control System �WRCS� is a large, commercially-available revision control system.

55. Architectural Representation of WRCS

56. Scenarios Used in WRCS User scenarios compare binary file representations configure the product�s toolbar Maintainer port to another operating system make minor modifications to the user interface Administrator change access permissions for a project integrate with a new development environment

57. Scenario Interactions Each indirect scenario necessitated a change in some modules. This can be represented either tabularly or visually. The number of scenarios that affected each module can be shown with a table or graphically, with a fish-eye view. A fish-eye view uses size to represent areas of interest.

58. Scenario Interaction Table

59. Scenario Interaction Fish-Eye