Modeling the Architecture

1. Modeling the Architecture • Every software system has an architecture (a set of principal design decisions) that may be captured by models. • Architectural “modeling” is the act of reifying (concretizing) and documenting the design decisions. • Architectural modeling notation is the language used for capturing the design decisions. ------ and ------ • Architectural model is: • the artifact that captures all the design decisions, via modeling with some notations, that comprise a system’s architecture.

2. Architectural Modeling • Some “Key” decisions in modeling: • Which design decisions and concepts should be modeled? • Which ones are important & importance is based on what criteria? • To what level of depth and detail should the decisions be modeled? • Should the more important or the more complex or the larger design decisions be modeled with deeper levels? • To what level of rigor and formality should the decisions be modeled? • Which notation should we use and how formal a notation should we use? Remember that this should also includes a “cost-benefit “ tradeoff decision.

3. Some Modeling Related Concepts to Consider • Stakeholder-Driven Modeling • Basic architectural entities (concepts) • Elements of architectural styles • Static and dynamic aspects • Functional and non-functional aspects

4. Stakeholder-Driven Modeling • It is clear that not every design decision is viewed with same level of concern. It depends on the stakeholders of the project and may also vary from project to project. Thus modeling should be stakeholder driven using a process (set of steps) such as: • Identify (by stakeholders) the relevant aspects of the software to model • Categorize the aspects in terms of importance (based on some criteria stated by stakeholders) • Identify the goals of modeling for each aspect (quality analysis, ease of use, reduction of complexity, communications, etc.) • Select modeling notation (s) --- based on importance & “goal” of modeling (e.g. UI - modeling language for “ease of use”) • Create the model • Use the model in a manner consistent with the modeling goals

5. Basic Architectural Entities (concepts) • In architectural modeling, we need to include the following main entities: • Components • Describe the basic functional building blocks and what functionality and data are encapsulated in each component. • Connectors • Describe those basic building blocks that facilitate the interaction among the functional components • Interfaces • Describes the points where the components and connectors interact with the external world such as users, other systems, or other connectors. • Configurations • Describes the relations and associations among components and connectors. • Rationale • Describes the reasons behind the design decisions and what purpose various entities serve. Modeling these entities require some language , and we may have to use different ones to best represent different entities. For example configurationmay be best expressed with a graph, but rationale may require using natural language.

6. Elements of Architectural Styles • Architectural style is a design decision that is 1) applicable to a given context, 2) constrain the design decisions to that context , and 3)elicit beneficial properties from that resulting system. Thus architectural style should be included in modeling because: • Clarifies about what is allowed and what is not • Makes it easier to distinguish design decisions • Reduces potential future architectural drift and erosion • Helps guide evolution of architecture • Captures cross-cutting (general) concerns (e.g. performance, security, etc.) • “Style” model includes (some constraints): • Specific elements (of components, connectors, and interfaces); these may be facilitated by a modeling template • “Types” of components, connectors, and interfaces that satisfy certain system constraint • Interaction constraints among the elements, such as in client-server interaction using a prescribed protocol • Behavioral constraints, including concurrency, on the elements using some state transition diagram to depict a complete system

7. Static and Dynamic Aspects • Static aspect of a system addresses those characteristics of the system that does not change over time such as (a) the number of components and connectors and their structural topology or (b) what a component is functionally responsible for • Dynamic aspect of a system addresses the characteristics of the system that change over time. • It addresses the behavioral (execution) aspects of the system and thus is more difficult to model. (e.g. real-time trigger and process) • It also addresses how the overall system (state) itself changes over time.

8. Functional and Non-functional Aspects • Functional aspects of a system captures what services or functionalities are provided by the system. [comes pretty naturally from stakeholder requirements] • Non-functional aspects of a systems describes what properties the system must have and how the functionalities are delivered (e.g. performance, security, reliability, etc.) [not easily transformed from requirements] *Note that sometimes a functional component is developed to satisfy a non-functional aspect. (e.g. accessing the system needs to be secure --- leading to a functional aspect of checking for user id and password or putting access control on tables in database.)

9. Potential “Problems”of Architectural Models • An architecture is a set of principal design decisions made about the system; thus in a sense it is an abstraction of the system. Thus, in capturing or modeling the architecture, we need to be cognizant of potential problems: • Ambiguity • Accuracy (correctness) • Precision(exactness)

10. Ambiguity • Since architecture only captures the “principal” design decisions ------- it may not be i) complete or ii) deep enough, causing thearchitecture model to be ambiguous. • A model is ambiguous if it is open to more than one interpretation. • An architectural model that admits multiple interpretations will lead to ambiguity and potential errors in design. 1.This problem is often addressed through design inspections, and clarifications should be provided in the design rationale section in a cost effective manner. 2. Beware that some architectural modeling notation (language) admits ambiguity.

11. Accuracy and Precision • The architectural model should be, but may not be, accurate and precise since it is an abstraction of the sytem. • A model is accurateif it is correct (conforms to fact) or deviates from “correctness” in a limited manner • A model is preciseif it is detailed, specific and exact • Note that we can be wrong and be very detailed and exact (precise). Thus between accuracy and precision, one should strive for accuracy before precision. e.g. Conversion rate between US. Dollar to Japanese yen on 3/5/2015: $1 = 98.45 yen (accurate and precise) $1 = 98 yen (accurate but imprecise) $1 = 365 yen (inaccurate and imprecise) $1 = 365.78 yen (inaccurate but precise) Assuming that 98.45 is the conversion rate

12. Modeling Complexity: Multiple Views& Mixed Content • No single approach can capture all aspects of an architecture; thus different aspects of architecture (functional, nonfunctional, structural, physical, etc.) may need to be modeled using different approaches or perspective. • An architectural view is a set of design decisions related by some common concern • An architectural viewpoint is the perspective from which a view is taken • A view is an instance of a viewpoint of a system, where a viewpoint is associated with one common concern. Examples of viewpoints are: • Logical viewpoint : system entities and their relationships • Physical viewpoint: hardware entities and their relationship to system • Deployment viewpoint: logical entities mapped to physical entities • Behavioral viewpoint: system states and processing characteristics • Concurrency or parallelism viewpoint: concurrency and threading control

13. Comparing to Kruchten’s 4 + 1 ? Krutchenauthors Logical ------ logical Process ------ behavioral; concurrency Physical ------ physical; deployment Development and Scenarios

14. Views and Viewpoint • Architectural Views and Viewpoints provide advantages such as: • Limit the presentation to a cognitively manageable subsetof the architecture (the old decompose/separation of concern/modularity idea) • brings related concepts together (old cohesion idea) • Tailors to the needs of specific stakeholders • Displays the information at various levels of abstraction within the viewpoint • Views and viewpoints which contain the same information must be consistent. Potential inconsistencies include: • Two views or viewpoints directly contradicteach other • Two refinementsof the same view or viewpoint contradict each other • The static versus the dynamic aspectsof the view or viewpoint contradict each other • Functional versus non-functional aspectsof views do not meet the same needs or contradict each other. • Dynamic aspectsof two views contradict each other.

15. Modeling Techniques and Languages (Notations) • There are many different ways to model and many different notations to use to capture the model, ranging from natural language to the highly popular UML for OO design. • In evaluating modeling technique and language one should consider the following points: • Scope and purpose of the technique/language • Basic elements or concepts that are modeled • Styles of architecture that are supported or not supported • Extent of static and dynamic aspects of the architecture supported • Support for changes and reflecting dynamic changes of the architecture • How well is non-functional aspects supported, assuming functional aspects are supported • How much support is there in checking for ambiguity and accuracy • How detailed can the system architecture be modeled to suffice precision • What viewpoints are supported • How much view and viewpoint consistency is checked There probably is not a one modeling technique/notation that can satisfy all these

16. Wide Spectrum of Architectural/Design Modeling Languages • General: • Natural language (e.g. English) • Boxes and Lines (e.g. Power Point , vision tools) • OO based and most popular today: • Unified Modeling Language (UML) which includes 13 different diagrams: • Class diagram, • component diagram, • composite structure diagram, • deployment diagram, • object diagram, • package diagram; • activity diagram, • state transition diagram, • use case diagram; • communication diagram, • interaction diagram, • sequence diagram, • timing diagram-a specific kind of interaction diagram.

17. Architectural Description Languages • Some Architectural Description Language (ADL) which modeled components, connectors, interfaces, and configurations: • Darwin: for distributed or interconnected architecture modeling (Imperial College) • Rapide: a language framework that contains a type language, arch def. language, specification constraint language, and concurrent programming language used to support large distributed systems (Stanford U.) • Wright: component interface language that allows for interface checking (CMU) • Koala: models consumer electronic domain-specific designs (Philips electronics) • Weaves: a language for modeling concurrent, communicating components called “tool fragments” (Aeorspace Corporation) • AADL: models real-time, embedded system for avionic, automotive, and other industries; outgrowth of Honewell’s MetaH (Honeywell, SEI-CMU, US Army) • Acme: An extensible modeling language that allows modeling extensions to its 7 baseline constructs of components, connectors, ports, roles, attachments, systems, and representations. Extensibility is provided via properties which are decorations applied to one of the seven basic constructs (CMU and USC) • ADML: XML based architecture description language whose syntax is derived from Acme • xADL: also an XML based language where extensions are introduced as first class entities, not just as extensions to the basic constructs

18. DARWIN • One of the “early” general-purpose ADL focused on: • Components • Interfaces • Configuration (Composition) • Darwin notation allows the modeling of “interconnected components” and primarily provides astructural description

19. Darwin Syntax Example Component DataStore { provide x-values; } Component Calculation { require x-values; provide calc-results; } Component UserInterface{ require x-values; require calc-results; } Component AppSWE6653{ inst UI: UserInterface; C: Calculation; D: DataStore; bind C.x-values - - D.x-values; UI.x-values - - D.x-values; UI.calc-results - - C.calc-results; }

20. Darwin Graphical Representation AppSWE6653 x-values x-values DataStore UserInterface calc-results calc-results x-values Calculation = requires Note: that any component may be further decomposed = provides

21. Acme(another Architecture Description Language - ADL) • Primary Purpose:Provide an interchange format for architectural development tools and environment • Primary goals: • Provide a representational scheme that will permit development of new tools --- for analyzing and visualizingarchitectural structures • Provide foundation for developing new, possibly domain specific ADL • Serve as a vehicle for creating conventions and standards for architectural information • Provide expressive descriptions that are easy for human to read and write.

22. Acme’s Basic Types of Entities • Acme’s 7 basic elements: • Component • Connector • System • Port – interfaces of the components • Roles – interfaces of the connectors • Representations – lower level description of component/connector • Representation Maps – a mapping between more detailed internal representation and an external representation 3 Primary Types

23. Graphical Acme system component component connector c1 c2 representations Re-Map 1 Re-Map 2 role port Representation- maps

24. Acme in text form Systemsimple_one = { componentc1 = { port send-request } componentc2 = { port receive-request} connector call1 = { roles {caller, receiver} } attachments : { c1.send-request to call1.caller; c2.receive-request from call1.receiver}

25. Architecture Analysis & Design Language (AADL) • This design modeling language was initially targeted for the description and analysis of systems for the avionic industry. • It has expanded to facilitate a wide variety of systems; it is not bound to any specific industry. • The “fundamental” element in this language is the Component which has a : • unique name, • set of properties, • interface to other components and • subcomponents

26. AADL Component • Component is identified via its “type” & there are 3 categories of 10 predefined “types” of components • Application software: • Thread • Thread group • Process • Data • Subprogram • Execution platform: • Processor • Memory • Device • Bus • Composite: • System

27. Graphical Representation of AADL Component types memory device process data thread thread group processor bus subprogram Application Software Execution Platform system Composite

28. Simple Example of a Component Process Component features Flows Properties Component Implementation subcomponents - connections call sequence flows modes properties

29. AADL Component Type & Component Implementation Component implementation identifier - Subcomponents - Calls - Connections - Flows - Modes - Properties Componenttype & identifier - Features - Flows - Properties Component Typeis one of the previous 10 types - declares the interfaces & I/O via Features(e.g. ports that are synchronous calls, data queued, etc) - declares specific infotransfer channels via Flow - declares externally observable properties via Properties (e.g. “thread” type may execute periodically, aperiodic event-driven, in background, or with some timing constraint, or with a device, etc.) -Subcomponents, Calls and Connections provide the composition of the Component -Flows specify end-to-end flow across subcomponents -Modes indicate alternative operational flow, alternative configuration, or alternative properties (e.g. normal, backup-recovery, novice/expert, etc.) -Properties specify properties that apply to all instances of this component (e.g. must run on Apple OS)

30. More clauses in AADL Component and Implementation • “Extends” clause may be used in Component and Implementation declarations to inherit characteristics of another, original Component • If used in Implementation declaration, Extends may be used to specify multiple implementation for the same component (e.g. implementation on MS OS, Unix, Apple OS may have different performance, difference security, etc.) • “Refine” clause may be used in Implementation declaration to complete a partially specified implementation (e.g. an implementation template)

31. Additional ADDL features • Packages – allows declaration of groups of components to be organized into separate units with their own names (e.g. search methods) • Property Set – allows a definition of a named group of related sub-properties (e.g. DB security levels) • Annex – allows the declaration of extensions to the core language such as a Fault-Tree model for reliability analysis