What is Software Architecture?

1. What is Software Architecture?

2. An Example Architecture??? Control Process (CP) Prop Loss Model (MODP) Reverb Model (MODR) Noise Model (MODN)

3. Why Can the Previous Diagram Be Called an Architecture? • It identifies components • It indicates relationships among the components.

4. What Does this Picture Fail to Show? • The nature of the elements • What is the significance of their separation? • Do they run on separate processors? • Do they run at different times? • Do they represent ways in which the project labor will be divided? • Are they objects, tasks, functions, processes, programs, or something else?

5. What Does this Picture Fail to Show? (Cont’d) • The responsibilities of the elements • What do they do? • What is their function in the system? • The significance of the connections • Do the connections mean that the elements communicate with each other, control each other, send data to each other, use each other, invoke each other, synchronize with each other, share some information-hiding secret with each other, or some combination of these relations?

6. What Does this Picture Fail to Show? (Cont’d) • The significance of the layout • Why is CP on a separate level? • Does it call the other three elements, and are they not allowed to call it? • Does it contain the other three in an implementation unit sense?

7. Definition of a Software Architecture 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.

8. Architectures Affect the Factors that Influence Them • The architecture affects the structure of the developing organization. • The architecture can affect the goals of the developing organization. • The architecture can affect customer requirements for the next system. • The architecture will affect the architectures of future systems. • The architecture may affect the software engineering culture.

9. Software Architecture Specifics • Architecture defines software elements. • It embodies information about how the elements relate to each other. • It is an abstraction, i.e., it omits certain information about the elements that does not pertain to their interaction. • Architecture is a not a single structure, but a collection of structures • E.g., runtime vs. implementation

10. Software Architecture Specifics (Cont’d) • All computing systems have architectures. • They may not be known to anyone. • The architecture of a system is different from its representation. • The behavior of each element is part of the architecture. • The behavior, and only the behavior, that influences how another element interacts with it or influences the system as a whole, is part of the software architecture.

11. Software Architecture Specifics (Cont’d) • Architectures can be good or bad. • The careful design and evaluation of architectures is essential for producing good architectures.

12. Other Definitions of Software Architecture • Architecture is high level design. • Architecture is the overall structure of the system. • Architecture is the structure of the components of a program or system, their interrelationships, and the principles and guidelines governing their design and evaluation over time. • Architecture is components and connectors

13. Architectural Patterns • An architectural pattern is a description of element and relation types together with a set of constraints on how they may be used. • Client-server is an example of an architectural pattern. • Picking a pattern is often the architects first major design choice.

14. Reference Models • A reference model is a division of functionality together with data flows between the pieces. • For example a database management system might have a reference model. • It is a standard division of a known problem into parts that cooperatively solve the problem.

15. Reference Architecture • A reference architecture is a reference model mapped onto software elements and the data flows between them. • The software elements cooperatively implement the functionality defined in the reference model. • That is,it maps the functionality of a reference model onto a system decomposition.

16. From Models and Patterns to Architecture Reference Model Reference Architecture Software Architecture Architectural Pattern

17. Why is Software Architecture Important? • Communication among stakeholders • Early design decisions • Transferable abstraction of a system

18. Stakeholder Communication • Different stakeholders are concerned with different system characteristics. • Architecture provides a common language in which different concerns can be expressed, negotiated and resolved.

19. Early Design Decisions • These are the most difficult to get correct. • They are the hardest to change later in the development process. • They have the most far-reaching effects.

20. Early Design Decisions • The architecture defines constraints on implementation. • The architecture dictates organizational structure. • The architecture inhibits or enables a system’s quality attributes. • Predicting system qualities by studying architecture.

21. Early Design Decisions (Cont’d) • The architecture makes it easier to reason about and manage change. • The architecture helps in evolutionary prototyping. • The architecture enables more accurate cost and schedule estimates.

22. Transferability/Re-usability • Software product lines share a common architecture. • Systems can be built using large, externally developed elements. • Less is more: it pays to restrict the vocabulary of design alternatives. • An architecture permits template-based development. • An architecture can be the basis for training.

23. Architectural Views and Structures • Architectural structures can be divided into three groups • Module structures – How is the system to be structured as a set of code units? • Component-and-connector structures – How is the system to be structured as a set of elements that have running behavior and interactions? • Allocation structures – How is the system to relate to nonsoftware structures in its environment?

24. Common Software Architecture Structures Component- And-Connector Module Allocation Client- Server Shared Data Decomposition Process Class Deployment Uses Concurrency Implementation Layered Work Assignment

25. Module-Based Structures • Decomposition – the units are modules related by the “is a submodule of” relation. • Uses – the units are modules, procedures or resources on the interfaces of modules related by the “uses” relation. • Layered – when the uses relations are controlled in a particular way a system of layers emerges in which layer is a coherent set of related functionality.

26. Module-Based Structures (Cont’d) • Class or Generalization – the module units are classes and the relation is “inherits-from or “is-an-instance of”.

27. Component-and-Connector Structures • Process or Communicating Processes– deals with the dynamic aspects of a running system and the relation is “attachment”. It shows how processes (the units) are connected by communication, synchronization, and/or exclusion operations. • Currency – the units are components and the connectors are “logical threads”. It allows determination of opportunities for parallelism and locations of resource contention.

28. Component-and-Connector Structures (Cont’d) • Shared Data or repository – comprises components and connectors that create store and access persistent data. • Client-Server – components are the clients and servers and the connectors are the protocols and messages they share.

29. Allocation Structures • Deployment – shows how software is assigned to hardware-processing and communication elements and the relations are “allocated to” and “migrate to”. • Implementation – shows how software elements (modules) are mapped to the file structure(s) in the system’s development, integration, or configuration control environments.

30. Allocation Structures (Cont’d) • Work Assignment – assigns responsibility for implementing and integrating the modules to the appropriate development teams.

31. Relating Structures to Each Other • Each of these structures provides a different perspective and design handle on a system. • Each is valid and potentially useful in its own right • They are not independent but highly interrelated. • Often the module structure is dominant, but not always.

32. Relating Structures to Each Other (Cont’d) • Not all systems warrant consideration of many architectural structures. • The larger the systems the more dramatic the differences between these structures tend to be. • Structures represent the primary engineering leverage point for satisfying quality attributes. • Multiple structures represent a powerful separation-of-concerns approach for creating the architecture.

33. Which Structures to Choose? • Kruchten’s “four plus one” approach recommends four views (structures): • Logical – the elements are “key abstractions” (a module structure) • Process – addresses concurrency and distribution of functionality (a component-and-connector structure) • Development – organization of software modules, libraries, subsystems, and units of development (an allocation structure)

34. Which Structures to Choose? (Cont’d) • Kruchten’s approach (cont’d): • Physical – maps elements onto processing and communication nodes (a deployment view) • The “plus one” is a a set of key use cases that serve to validate that the structures are not in conflict with each other and together describe a system meeting its requirements.