CHAPTER 6 - MODELING ANH AU

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

MODELING CONCEPTS

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 Benefits of having certain models in certain forms/notations Costs of creating and maintaining these models Architects must balance:

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 STAKEHOLDER – DRIVEN MODELING (CONT.) Architecture-centric software development Modeling

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)

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

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 aspects involve 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 vs changes to the models themselves) A model of dynamic aspect of a system – describes system changes as it executes A dynamic models - changes itself

FUNCTIONAL AND NON-FUNCTIONAL ASPECTS Functional aspects – what a system does “The system prints medical records” Generally more concrete, easier to model WHAT’S THE DIFFERENCE, YOU ASK? Non-functional aspects – how a system performs its functions “The system prints medical records quickly and confidentially.” Qualitative and subjective

AMBIGUITY, ACCURACY, AND PRECISION

AMBIGUITY 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! 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

ACCURACY AND PRECISION EXAMPLE

COMPLEX MODELING MIXED CONTENT AND MULTIPLE VIEWS

VIEWS AND VIEWPOINTS Think of it this way: A viewpoint 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

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

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

SPECIFIC MODELING TECHNIQUES

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

EARLY ARCHITECTURE DESCRIPTION LANGUAGES DARWIN 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 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 “First generation” ADLs WRIGHT Focused on checking component interactions through their interfaces. Takeaway: Steep learning curve Analysis capabilities are powerful but limited

EDUARDO! YOUR TURN… PLEASE