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 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, reduction of complexity, communications, etc.) • Select modeling notation (s) • Create the model • Use the model in a manner consistent with the modeling goals

5. Basic Architectural Entities (concepts) for Models • 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 configuration may be best expressed with a graph, but rationale may require using natural language.

6. Elements of Architectural Styles in Models • 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 such as performance • 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 of Models • Static aspect of a system addresses those characteristics of the system that does not change over time such as the number of components and connectors and their structural topology • Dynamic aspect of a system addresses the characteristics of the system that change over time. • It addresses the behavioral aspects of the system and thus is more difficult to model. • It also addresses how the system itself changes over time.

8. Functional and Non-functional Aspects of Models • Functional aspects of a system captures what services or functionalities are provided by the system. • 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.) 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.)

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 • Precision

10. Ambiguity • Since architecture only captures the “principal” design decisions ---- it may not be complete or deep enough. Thus an architecture model may 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 ssytem. • A model is accurate if it is correct (conforms to fact) or deviates from correctness in a limited manner • A model is precise if it is detailed, specific and exact • We can be wrong and be very detailed and exact. Thus between accuracy and precision, one should strive for accuracy. e.g. Conversion rate between US. Dollar to Japanese yen on 6/5/2009: $1 = 98.45 yen (accurate and precise) $1 = 98 yen (accurate but imprecise) $1 = 360 yen (inaccurate and imprecise) $1 = 360.78 yen (inaccurate but precise)

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, etc.) may need to be modeled using different approaches or perspective. • An architectural view is a set of design decisions related by a common concern • An architectural viewpoint is the perspective from which a view is taken • A view is an instance of a a viewpoint of a system, where a viewpoint is associated with one 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. Views and Viewpoint • Architectural Views and Viewpoints provide advantages such as: • Limit the presentation to a cognitively manageable subset of the architecture • brings related concepts together • Tailors to the needs of specific stakeholders • Displays the information at various levels of abstraction • Views and viewpoints which contain the same information must be consistent. Potential inconsistencies include: • Two views or viewpoints directly contradict each other • Two refinements of the same view or viewpoint contradict each other • The static versus the dynamic aspects of the view or viewpoint contradict each other • Functional versus non-functional aspects of views do not meet the same needs or contradict each other. • Dynamic aspects of two views contradict each other.

14. Modeling Techniques and Languages • 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

15. 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.

16. 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

17. Acme (An 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.

18. 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 representaiton 3 Primary Types

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

20. 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}