Designing Architecture

1. Designing Architecture Chapter 4

2. Building analogy Simply having a set of power tools and a lofty vision for a skyscraper is not adequate for creating a fifty-story building which effectively integrates with a city's electrical, water, data, and wastewater infrastructures.

3. Goal of the chapter: Examine a variety of approaches to designing software systems • Basics of design process • Foundational conceptual tools • Refined experience • Domain-specific software architectures • Architectural patterns and styles • Design discovery

4. The design process Software design can proceed in the same general manner of architectural or engineering design which has these four stages: 1. Feasibility stage - Identifying a set of feasibility concepts 2. Preliminary design stage - Development of engineering descriptions of the concept 3. Detailed design stage - Development of engineering descriptions of the concept 4. Planning stage - Evaluating and altering the concept to suit the requirements of production, distribution, consumption and product retirement

5. The design process This approach to design is completely consistent with common, broader notions of software engineering processes, such as the waterfall and spiral methods of development. Such universal use indicates that it is a very effective strategy in many situations. It is important to note that this is not the only approach even though it is pervasive in the software development world. This is important because the standard approach does not always work.

6. Conditions under which the standard process may not work The success of this approach is predicated on the success of the first step. If the designer is unable to produce a set of feasibility concepts, progress stops. Step two is historically done by one person, but as projects grow in size this will become an issue. Having a team do this step creates its own set of issues.

7. As complexity increases, or the experience of the designer is not sufficient for the challenge, alternate approaches to the design process must be adopted These are some alternate design strategies: • Standard – Described earlier. • Cyclic - As problems or infeasible approaches are identified in stages 2-4 of the standard model, the process reverts to an earlier stage. • Parallel - After stage one of the standard model, independent alternatives are explored in parallel. • Adaptive - The design strategy to follow in the next stage of the design activity is decided at the end of a given stage. "Lay track as you go." • Incremental - Design at each stage of development is treated as a task of incrementally improving whatever design or previous product exists after a preceding stage.

8. Architectural Conception Feasibility Stage Identifying a feasible set of "alternative arrangements for the design as a whole," choosing one of those arrangements, and then proceeding to refine and elaborate it. The standard approach does not tell us how to identify that set of viable arrangements. A simple answer is to "apply the fundamental design tools of engineering: abstraction and modularity.“ Another simple answer is to say "inspiration.“ A common, effective, and appropriate answer is applying experience.

9. Architectural Conception Fundamental Conceptual Tools • Separation of concerns • Abstraction • Modularity • "first principles of software engineering," such as anticipation of change and design for generality.

10. Abstraction and the simple machines Abstraction is usually seen as a process that moves upward from details to summarizing concepts. In design, it usually moves downward: a set of concepts is chosen to allow discussion of an idea--an arrangement of abstract parts that constitutes a solution, though still at a high level.

11. Abstraction and the simple machines The design then moves further downward as the concepts of abstraction are reified (created or made real) into more concrete structures--a more complex whole. Ultimately the reification process ends with the production of source code. Abstraction is often used because the intent is to create source code for which abstraction is an accurate and useful characterization.

12. Abstraction and the simple machines The goal here is to turn a complex system into a "simple machine:" A simple description to get a better understanding of the problem and to provide a plausible first conception of how an application might be built.

13. Separation of Concerns The subdivision of a problem into independent parts. For instance, the visual interface the customer sees at a bank's ATM is independent from the logic used to control operation on that customer's accounts.

14. Separation of Concerns Difficulties arise when issues are either actually or apparently intertwined. For example, a common word such as "account" may be used to describe what are different entities in different parts of an application. In other cases, concepts may be intertwined because of solution efficiency. For example, the presence of numeric keys in user records may simply reflect prior database implementation strategies and may not be intrinsic information about the user.

15. Separation of Concerns Separation of concerns frequently involves many tradeoffs: total independence of concepts may not be possible. The designer must assess performance costs, appearance, or functional trade-offs between competing conceptions.

16. The Grand Tool: Refined Experience This section is about something that is completely intuitive and mostly goes without saying: Experience leads to better design. Design experience successes and failures can and will guide you in new projects. Experience must be reflected upon and refined to understand the central issues and lessons from prior work. This applies not only to your own experience, but also that of others. There is no virtue in reinventing wheels, broken or otherwise. Applying established approaches is not an entirely risk free strategy, however. Once one has a favorite hammer, everything starts to look like a nail.

17. Refined Experience in Action: Styles and Architectural Patterns Styles are designed to capture knowledge of effective designs for achieving specified goals within a particular application context. Using a building analogy, the goal might be providing a house for a single family in the in a Mediterranean climate using stone and tile as principal building materials. The appropriate style might be a single-story villa.

18. Refined Experience in Action: Styles and Architectural Patterns For software, the goal might be providing a secure instant messaging system to operate between remote sites of a global company. The style might be client-server. Again, using a building analogy, one can characterize a pattern for determining the appropriate overhang of a tiled roof over an entryway. Similarly, one can characterize a provision of elevator service in a 90-story skyscraper. Patterns and styles have been developed for small and large, complex applications.

19. Domain Specific Software Architectures • Reference architecture for an application domain. • A library of reusable software components. • A method of choosing and configuring components to work within an instance of the reference architecture.

20. Again with the building analogies DSSAs are akin to the generic design of tract houses. The homes are similar but can have different options. The difficulty with DSSAs is that they are specialized for a particular domain and cannot be adapted easily. DSSAs are common in industry.

21. Architectural Patterns Much like DSSAs, but applied in a much narrower scope. Definition from chapter 3: a named collection of architectural design decisions that are applicable to a recurring design problem, parameterized to account for different software development contexts in which that problem appears.

22. Introduction to styles An architectural style is a named collection of architectural design decisions that (1) are applicable in a given development context, (2) constrain architectural design decisions that are specific to a particular system within that context, and (3) elicit beneficial qualities in each resulting system.