Modeling Architectural Decisions in Software Systems

1. Chapter 6 - Modeling AnhAu

2. Background Architectural model – an artifact that captures some or all of the design decisions that comprise a system’s architecture. Definitions Architectural modeling – making the design decisions into real life and documenting those design decisions

3. Modeling Concepts • What kind of things can be modeled in an architecture? • Which notation (language or means of capturing design decision) should be used? • How can we effectively model this concept?

4. Stakeholder – Driven Modeling • What are the most critical decisions that architects have to make? • Decisions based on costs and benefits! • Architects and other stakeholders must decide: • What architectural decisions and concepts should be modeled • At what level of detail • With how much rigor or formality Costs of creating and maintaining these models Architects must balance: Benefits of having certain models in certain forms/notations Therefore, the choice of what model and what level of detail will be stakeholder driven.

5. Stakeholder – driven modeling (cont.) • Basic steps in Stakeholder-Driven Modeling • (Iterative process) • 1. Identify relevant aspects of the software to model • 2. Roughly categorize them in terms of importance • 3. Identify the goals of modeling for each aspect (bug finding, quality analysis, …) • 4. Select the appropriate modeling notation • 5. Create the models • 6. Use the models in a manner consistent with the goals Architecture-centric software development Modeling

6. Basic Architectural Concepts • Starting Point for architectural modeling • Components – encapsulates a subset of the system’s functionality an/or data, and restricts access to them by an explicitly defined interface • Connectors – effect and regulate interactions among components • Interfaces – the points at which components and connectors interact with the other components and connectors • Configurations – a set of specific associations between the component and connectors of a software system’s architecture • Rationale – reasoning behind architectural decisions; primarily used for communication info and intent among stakeholders At the most basic level, we can simply model the above elements using graphs. (Basic box and arrows)

7. Elements of the Architectural Style • Why it’s useful to model the style that governs how elements have been used : • Reduces the confusion in the architecture • Reduces the architectural drift/erosion • Guides the evolution of the software architecture • Can be reused from project to project • Elements of the architectural style (in a style model) • Inclusion of specific basic elements (e.g., components, connectors, interfaces) : • How? Use a modeling approach that supports templates • Component, connector, and interface types : • How? Many modeling approaches accompanied with a type system but different semantics • Constraints on interactions (temporal, topological, specify particular interaction protocols…): • How? Use modeling approaches that could support logic • Behavioral constraints • How? Use modeling approach that uses either logic or other formal models • Concurrency constraints (concurrent functions and synchronization of access to the shared resources): • How? Use modeling approach that uses formal behavioral models or temporal modeling techniques

8. Static and Dynamic Aspects • Static aspects do not involve the system’s behavior while it is executing • Easier to model since static aspects do not involve changes over time • Ex: component/connector topologies, host and network configs,... • Dynamic aspectsinvolve the system’s runtime behavior • Harder to model since we must deal with how a system behaves over time • Ex: behavioral models, interaction models, or data flow models • Hard to tell sometimes… • Static and dynamic aspects vs static or dynamic models • (Properties of the system being modeled vschanges to the models themselves) • A model of dynamic aspect of a system – describes system changes as it executes • A dynamic models- changes itself Obviously: Supporting dynamic models is a bit harder than supporting static models

9. Functional and Non-Functional Aspects What’s the difference, you ask? Non-functional aspects – howa system performs its functions “The system prints medical records quickly and confidentially.” Qualitative and subjective • Functional aspects – what a system does • “The system prints medical records” • Generally more concrete, easier to model Functional aspects are often developed to go hand-in-hand with non-functional objectives Ex: Non-functional objective: Make paycheck processing component fast Functional model: Describes how component uses caches and local processing to achieve objective

10. Ambiguity, Accuracy, and Precision Architectures are not meant to be complete implementations of a system. But when characterizing architectural models, use these three concepts.

11. Ambiguity Accuracy vs Precision A model is accurate if it is correct, conforms to fact, or deviates from correctness within acceptable limits. A model is precise if it is sharply exact or delimited. Accuracy > Precision • A model is ambiguous • if it is open to more • than one interpretation. • Eliminate me! • Why? • I make models incomplete  • Just kidding. Nice try. It’s impossible to completely eliminate me. It’ll cost too much to try. • Hint: Try to allow aspects to be ambiguous with the consent of appropriate stakeholders. They’ll decide when the architecture is “complete enough.” Document me for later! Notation and modeling approach plays a significant role on the ambiguity, accuracy, and precision of models. Stakeholders should generally choose notations that allow unambiguous, accurate, and precise modeling of the aspects of the system that are most important.

12. Accuracy and precision example http://celebrating200years.noaa.gov/magazine/tct/accuracy_vs_precision.html

13. Complex Modeling Mixed Content and Multiple Views • No single modeling approach will be able to capture all the aspects of an architecture for a project. • Various parts of the architecture may have to be modeled using different approaches.

14. Views and Viewpoints • Think of it this way: • Aviewpoint is a filter for information. • A view is what you see when you look at a system through that filter. • Common Viewpoints: logical, physical, deployment, concurrency, and behavioral • Yes, it is possible to have multiple views from the same viewpoint. • Why We’re Important • limit presented info to a “easier on the eyes” subset of the architecture • display related concepts simultaneously • tailored to stakeholder needs • used to display the same data at various levels of abstraction

15. Consistency among Views • What’s the problem? • Same/related info shows up in two or more views. Is this info consistent? • So when you say consistent… • This means if the views’ design decisions that they each contain are compatible • And an inconsistency? • Occurs when two views assert design decisions that cannot both be simultaneously true • Multiple-view inconsistencies: • Direct, Refinement, Static Aspects vs Dynamic Aspects, Dynamic Aspects, Functional vs Non-Functional Aspects

16. Evaluating Modeling Techniques Rubric for Modeling Techniques Scope and Purpose Basic Elements Style Static and Dynamic Aspects Dynamic Modeling Non-Functional Aspects Ambiguity Accuracy Precision Viewpoints View Consistency

17. Specific Modeling Techniques So many notations and techniques available for modeling different aspects of architectures. Which will the system’s architects and stakeholders choose?

18. Generic Techniques • Flexible but may end up ambiguous • tl;dr For Each • Natural Language • Spoken/written languages such as English • ✓ Best way to capture some aspects of architecture • ✗ Machines can’t process effectively. Need humans. • Informal Graphical PowerPoint-style Modeling • Use software to create decorative diagrams of simple shapes and arrows • ✓ Good for early prototyping, captures ideas at an abstract, conceptual level • ✗ Too simple sometimes, open interpretations of diagrams • Unified Modeling Language (UML) • A graphical notation with different views that are usually textually annotated • ✓ Broad range of diagrams for modeling all kinds of software systems • ✗ Purposefully ambiguous to increase its generality

19. Early Architecture Description Languages “First generation” ADLs Darwin Rapide Specified dynamic properties of systems composed of components that communicated using events. Takeaway: Steep learning curve Addresses dynamic aspects, provides tool support for simulation wright • General purpose ADL that specified the structure of systems composed from components that communicated through explicit interfaces. • Takeaway: • Rigorous, formal ADL • Provides well-defined semantics • Best for structural modeling Focused on checking component interactions through their interfaces. Takeaway: • Steep learning curve • Analysis capabilities are powerful but limited

20. Eduardo! Your turn… please