Software Architecture in Practice

1. Software Architecture in Practice Part One: Envisioning Architecture 2nd Ed. Len Bass, Paul Clements, Rick Kazman

2. Ch 1: The Architecture Business Cycle • For decades, software designers have been taught to build systems based exclusively on the technical requirements. • Software architecture encompasses the structures of large software systems: • abstract view • eliminates details of implementation, algorithm, & data representation • concentrates on the behavior & interaction of “black box” elements

3. Definition • The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.

4. Architecture Business Cycle (ABC) • Quick Exercise : • What is the relationship of a system’s software architecture to the environment in which the system will be constructed and exist?

5. Architecture Business Cycle (ABC) • Answer: • Software architecture is a result of technical, business, and social influences. • In turn, it affects each of these environments.

6. Where do Architectures Come From? • The result of a set of business and technical decisions. • In any development effort, the requirements make explicit some - but only some - of the desired properties of the final system. • Failure to satisfy non-documented constraints can cause as many problems as if it functioned poorly.

7. Figure 1.2 Influence of stakeholders on the architect

8. Architectural Influences • Stakeholders • each stakeholder has different concerns & goals, some contradictory • Development Organization • immediate business, long-term business, and organizational (staff skills, schedule, & budget) • Background & Experience of the Architects • repeat good results, avoid duplicating disasters • The Technical Environment • standard industry practices or common SE techniques

9. Ramifications of Influences • Almost never are the properties required by the business & organizational goals consciously understood, let alone fully articulated. • Architects need to know & understand the nature, source, and priority of constraints on the project as early as possible. • Architects must identify & actively engage the stakeholders to solicit their needs & expectations. • Use architecture reviews & iterative prototyping.

11. Book’s Main Message • Architectures affect the factors that influence them. • The relationships among business goals, product requirements, architects’ experience, architectures, and fielded systems form a cycle with feedback loops that a business can manage: • to handle growth, to expand enterprise area, and to take advantage of previous investments in architecture & system building.

13. Software Processes & the ABC • What activities are involved in creating a software architecture, using that architecture to realize a design, and then implementing or managing the evolution of a target system or application?

14. Quick Exercise • How do you • Design one? • Build one? • Modify one?

15. Architectural Activities • Creating the Business Case for the System • Understanding the Requirements • Creating or Selecting the Architecture • Communicating the Architecture • Analyzing or Evaluating the Architecture • Implementing Based on the Architecture • Ensuring Conformance to an Architecture

16. What makes a Good Architecture? • No such thing as an inherently good or bad architecture. • Architectures are more or less fit for some stated purpose. • Architectures can be evaluated - one of the great benefits of paying attention to them - but only in the context of specific goals. • Rules of Thumb: process & product (structural) recommendations

17. Rules of Thumb (pp 15 & 16) • Process Recommendations: • include functional requirements and a prioritized list of quality attributes the system must satisfy • analyze & formally evaluate before it is too late to change • Product Recommendations: • well-defined modules using principles of information hiding & separation of concerns • separate modules that produce data from those that consume data to increase modifiability & staged upgrades • write tasks or processes to allow easy reallocation, perhaps at runtime

18. Prop Loss Model (MODP) ReverbModel (MODR) NoiseModel(MODN) Ch 2: What is Software Architecture? • Quite often shown as box-and-arrow diagrams. Control Process (CP) Figure 2.1

19. What’s Missing? • What is the nature of the elements? • What are the responsibilities of the elements? • What is the significance of the connections? • What is the significance of the layout? • Unless we know precisely what the elements are & how they cooperate to accomplish the purpose of the system, this diagram is unhelpful!

20. Definition Again • The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, an the relationships between them. • We see the elements (CP, MODP, MODR, MODN), but what properties do they or their relationships have?

21. Externally Visible Properties • The assumptions that other elements can make of an element, such as: • its provided services, • performance characteristics, • fault handling, • shared resource usage, • etc.

22. Definition Implications 1 - architecture defines software elements. 2 - systems can and do comprise more than one structure, all are part of the architecture. 3 - every computing system with software has an architecture. 4 - the behavior of each element is part of the architecture as far as its behavior can be observed or discerned from the point of view of another element. 5 - the definition doesn’t judge goodness or badness.

23. Useful Concepts • Three stages that capture characteristics of an architecture, on the way from box-and-arrow to full software architectures: • Architectural Patterns • Reference Models • Reference Architectures Reference Model ReferenceArchitecture Software Architecture ArchitecturalPattern Figure 2.2

24. Architectural Patterns • A description of element & relation types together with a set of constraints on how they may be used. • These constraints on an architecture define a set or family of architectures. • For example, the client-server pattern has 2 element types (?); their relationship is a protocol that the server uses to communicate with each of its clients, the clients don’t communicate directly. Functionality is excluded.

25. Value of Patterns • They exhibit known quality attributes, and are a reuse of experience. • Some patterns solve performance problems, others apply to high-security systems, or high-availability goals. • Often the architect’s first major design decision. • Also referred to as architecturalstyles.

26. Reference Models • A division of functionality together with data flow between the pieces. • A standard decomposition of a known problem into parts that cooperatively solve the problem. • They arise from experience, and are thus a characteristic of mature domains. • For example, the standard parts of a compiler or database management system & how they work together.

27. Reference Architectures • A reference model mapped onto software elements and the data flows between them. The elements must cooperatively implement the functionality defined in the reference model. • The mapping may be 1-1, but an element may implement a part of a function or several functions.

28. Why is Architecture Important? • Three fundamental reasons from a technical perspective: • Communication among stakeholders • a basis for mutual understanding, negotiation, & consensus • Early design decisions • earliest point at which decisions can be analyzed • Transferable abstraction of a system • can promote large-scale reuse

29. Early design decisions • The architecture: • defines constraints on implementation • dictates organizational structure • inhibits or enables a system’s quality attributes • some details on next slide, more on p. 30 • studying it can predict system qualities • easier to reason about and manage change • helps in evolutionary prototyping • enables more accurate cost & schedule estimates

30. Quality Attributes

31. Architecture: a Transferable, Reusable Model • The earlier in the lifecycle re-use is applied, the greater the benefit. • Software Product Lines share a common architecture. • Composing with large, externally developed elements. • Restrict the vocabulary of design alternatives: patterns. • Architecture permits template-based development. • Used as the basis for training.

32. Structures and Views • A view is a representation of a coherent set of architectural elements, consisting of: • a set of elements • the relationships among them • A structure is the set of elements itself, as they exist in software or hardware. • Often used interchangeably, text will distinguish.

33. Groups of Architectural Structures • Module structures • units of implementation with assigned areas of functionality - usually static • Component-and-connector structures • runtime components (principal units of computation) and connectors (communication vehicles) • Allocation structures • show relationships between software elements & external environments (creation or execution)

34. Three Types of Structures • Correspond to the three broad types of decisions that architectural design involves: • How is the system to be structured as a set of code units (modules?) • How is the system to be structured as a set of elements that have runtime behavior (components) and interactions (connectors)? • How is the system to relate to non-software structures in its environment (i.e., CPUs, file systems, networks, development teams, etc. - allocation)?

35. Figure 2-3

36. Non-functional Properties • Each structure provides a method for reasoning about some of the relevant quality attributes, for example: • the uses structure, must be engineered to build a system that can be easily extended or contracted • the process structure is engineered to eliminate deadlock and reduce bottlenecks • the module decomposition structure is engineered to produce modifiable systems, etc.

37. Value of Structures • Each structure provides the architect with a different view into the system & a different leverage point for design. • Table 2.1 on page 39-40 should be useful in your class project...

38. Relating Structures to Each Other • Although the structures give different system perspectives, they are not independent. • Elements of one structure are related to elements in another, and we need to reason about these relationships. • For example, a module in a decomposition structure may map to one, part of one, or several, components in a component-and-connector structure at runtime. • In general, mappings are many-many.

39. Choosing Structures • Kruchten’s Four + One Views: • Logical - elements are “key abstractions” that are objects or classes in OO. This is a module view. • Process - addresses concurrency & distribution of functionality. This is a C&C view. • Development - shows organization of software modules, libraries, subsystems, and units of development. This is an allocation view. • Physical - maps other elements onto processing & communication nodes, also an allocation view, but usually referred to specifically as the deployment view.

40. Quick Exercise • Please read “Architecture Deja Vu” on pages 43-45. • What do you think? Do you agree or disagree? Why?

41. Ch 3: A-7E Avionics System • Architecture is focused on three structures: • Decomposition into modules • Uses – how the modules relate • Process – components and connectors

42. Decomposition • Information hiding: • Also foundation to OO design, • Except information hiding modules are derived by identifying expected changes over the system’s lifecycle • A module may have submodules

43. Specific goals • Simple enough to understand fully • Change one module without knowing or impacting others • Most likely changes should be easiest • Possible to make major changes as a set of independent changes to individual modules • If the interfaces are not changed, any combination of old and new should run

44. A-7E Module Decomposition Structure • Architects observed that, in similar systems, changes tend to come from three areas: • Hardware • Required externally visible behavior • Decisions controlled by the developer

45. Uses Structure • Runtime execution information – the authoritative picture of how the software interacts • Uses relation: • Procedure A is said to use procedure B if a correctly functioning procedure B must be present in order for A to meet its requirements.

46. Uses Relation • Allows rapid identification of functional subsets • The uses (allowed-to-use) structure is documented in a table – see Table 3.4 for an example

47. Process Structure • Implemented as a set of cooperating sequential processes that synchronize with each other to cooperatively use shared resources • Pre-runtime scheduling produced a single executable thread

48. Processes • A set of programming steps that are repeated in response to a triggering event or to a timing constraint • It has its own thread of control, and can suspend by waiting for an event

49. A-7E Processes • Written for two main purposes • For the functional drivers to compute the output values of the avionics software • Less frequently, they can implement expensive access procedures – continuously compute in the background, returning the most recent value when called • See their conceptual structures on pp 63-64

50. Processes • Contains the “synchronizes-with” relation • Based on events that one process signals and one or more processes await • Used as the primary input to the scheduling activity, which includes deadlock avoidance • Process structure has two types of information: • What procedures are included in each process, identifying threads and re-entrant requirements • Which processes cannot execute simultaneously