Architectural Modeling Software Architecture

Definition Every software system has an architecture either good or not good Capturing and recorded design decisions is modeling Definition: Architectural Model: An architectural model is an artifact that captures some or all of the design decisions that comprise a system’s architecture Architectural modeling: Architectural modeling is the reflection and documentation of those design decisions Models help us to communicate, visualize, evaluate & evolve an architecture

Modeling Notations How we model is strongly influenced by the notations we choose: An architectural modeling notation is a language or means of capturing design decisions Notations can be rich and ambiguous like natural language or can be semantically narrow and highly formal e.g. Rapid Broad variety of modeling notations are covered in this chapter

Stakeholder-Driven Modeling Architects and other stakeholders must make critical decisions: What architectural decisions and concepts should be modeled, At what level of detail, and With how much rigor or formality Decisions should be based on costs and benefits

Stakeholder-Driven Modeling The benefits of creating and maintaining an architectural model must be balanced with the cost of doing so Choice of model and level of details has to be decided Most important or critical aspects of the system should be model in greatest detail with highest degree of formality/rigor

Stakeholder-Driven Modeling

Stakeholder-Driven Modeling Basic activities behind stakeholder driven modeling: Identify relevant aspects of the software to model Roughly categorize them in terms of importance Identify the goals of modeling for each aspect (communication, bugs finding, quality analysis and so on) Select modeling notation that will model the selected aspects at appropriate levels of depth to achieve the modeling goals Create the models Use the models in a manner consistent with modeling goals

These steps are in chronological order but they can be executed in iterative manner From outside it can never be clear what are important aspects of the system, what are goals of modeling, whether these goals are achievable using available notations, technology , time and money. Estimations has to be reevaluated

What do We Model? Basic Architectural Concepts/elements Elements of the Architectural Style Static and Dynamic Aspects Functional and Non-functional Aspects

1. Basic Architectural Concepts Some elements are common and important in every architecture when architectural design is considered. These elements are: Components: Architectural building blocks that encapsulate a subset of system’s functionality and data Connectors: Architectural building blocks that effect & regulate interactions among components Interface: Points at which components and connectors interact with the outside world. i.e. with other components and connectors Configuration: Combination of connectors and components. Represented via graphs where nodes – components & connectors and edges - interconnectivity Rationale: Information that explains why particular architectural decisions were made & purpose of various elements

Basic Architectural Concepts Basic architectural elements Components Connectors Interfaces Configurations Rationale – reasoning behind decisions Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

Basic Architectural Concepts These concepts forms starting point for architectural modeling Notations: box and arrows to represent components, connectors and interface Rationale has to be more expressive as it includes information. Rationale is usually model using natural language Basic modeling wont work for complex systems. These models must be extended and annotated with other concepts: what are nature of type of element? linking components and connectors means what etc… For small systems like word processor, components are static and less in numbers hence easy to describe each one For larger system like www, it is difficult to enumerate all the components. There are too many and constantly coming and going. For such system it is more reasonable to model only part of system or architectural style that governs the architecture

2. Elements of the Architectural Style Arch. Style is collection of design decision in a particular domain, specific to a particular system Modeling arch. Style is very helpful in many ways It reduces confusion about what is and is not allowed in architecture Reduces drift and erosion Help to guide evolution of arch. Reusable from project to project Design decision in architectural style is more abstract or general than in architecture

2. Elements of the Architectural Style Specific elements: style may prescribe that particular component ,connector or interface be included or used in specific situation. Template or base model creation can support this in modeling Component connector and interface style: specific kinds of elements may be permitted, required or prohibited in the architecture. These elements can be of different semantics. We can model these elements

2. Elements of the Architectural Style Interaction constraints: constraints may exist on interaction between components and connectors Temporal constraint (calling component must call init() first before any other function) Topological constraint (only client layer components can invoke server layer components) Interaction protocol like https can be specified Can be model using first order logic, temporal logic etc Behavioral constraints: constraints on behavior of elements can be model. FSM. Concurrency constraint: which elements support concurrency, have access to shared memory etc is specified in style which can be model.

3. Static and Dynamic Aspects Static aspects do not change. They do not involve system’s behavior while it is executing Dynamic aspects of the system involves system’s runtime behavior Static aspects are easier to model. They do not involve changes over time. Static aspects include components/connectors, topology, assignment of components or connectors to processing elements or host, n/w configuration etc..

3. Static and Dynamic Aspects Dynamic aspects of the system deal with how a system behaves or changes over time Dynamic aspects are harder to model Behavioral model, interaction model or data flow model contains dynamic aspect of the system. behavior, mode of interaction and data flow may change over time

3. Static and Dynamic Aspects Static/dynamic distinction is not a clear line Some aspects like structure of system are stable, but under some conditions like system failure they may change. Models include both static and dynamic aspects of the system are employed for such cases where base topology allow limited set of changes that may occur during execution

3. Static and Dynamic Aspects Static model captures properties of the system Static models can be in read only form Dynamic models refers to how the system(internal state) changes in as it executes Dynamic models changes itself Dynamic models has to be in machine readable and writable form

4. Functional and Non-functional Aspects Functional aspects relate to WHAT system does Non-functional aspects relates to HOW system performs its function Example: Functional: system prints medical record Non-Functional: quickly and confidentially

Functional Aspects Functional aspects are more concrete and hence easier to model Can be modeled rigorously and formally Services provided by different components or connectors Behavior of the system Functional models can be static or dynamic in nature Most modeling notation focus on capturing functional aspects of the system

Non-Functional Aspects Modeling non functional aspect is not as perfect as functional aspects Many times Functional aspects are designed to achieve non functional properties of the system It is more informal Similar to rationale, non functional aspects are difficult to model They have to be more expressive and free from notations Natural language type notations are used for modeling non-functional aspects

Important Characteristics of Models Architectures are abstraction of the system Most important aspects of the system will be well defined by architectures Architectures are not complete implementation of system Notations used to capture architecture do not have to be completely unambiguous, accurate and precise Three key cancers of architectural model are: Ambiguity , precision and accuracy

Ambiguity Ambiguity A model is ambiguous if it is open to more than one interpretation Conflicting interpretation of model results in misunderstanding, errors, bugs It is generally desirable to avoid ambiguity in the system Incompleteness is a primary reason for ambiguity in models Unspecified aspects results into different assumption of stakeholders

Ambiguity Architectures are incomplete Impossible to completely eliminate ambiguity It will increase cost Architects decides that architecture is ‘complete enough’ Ambiguous aspects are better to be specified using rationale

Accuracy and 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 detailed, sharply exact or delimited

Accuracy vs. Precision Inaccurate and imprecise: incoherent or contradictory assertions Accurate but imprecise: ambiguous or shallow assertions Accurate and precise: detailed assertions that are correct Inaccurate but precise: detailed assertions that are wrong Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

Complex Modeling Architectural models are complex artifacts Models captures all design decisions that are important to variety of stakeholders Different aspects of the same concept are captured simultaneously e.g. components behavior, interconnection and version history are captured separately about every component Too much information available to deal with Architects prefer to work with parts of architecture Various parts of the architecture will be modeled using different approaches like non functional aspects using natural languages, behavior using state charts, structure using component connector graph etc.

Views and Viewpoints Capturing everything in one model will make that model complex, confusing and too big Different aspects are captured in different models these subsets are called as views Views captures different concerns about the same concept These concerns or criteria about with which a view is taken viewpoint View: a view is a set of design decisions related by a common concern or set of concerns Viewpoint: a viewpoint defines the perspective from which a view is taken

Viewpoints Viewpoint is a filter to the information and view is what you see about the system through that filter Viewpoint is different angles with which system can be seen Viewpoints are means to capture different information of same concerns

Viewpoints Viewpoints that are commonly used: Logical Viewpoints Capture the logical (often software) entities in a system and how they are interconnected. Physical Viewpoints Capture the physical (often hardware) entities in a system and how they are interconnected. Deployment Viewpoints Capture how logical entities are mapped onto physical entities. Concurrency Viewpoints Capture how concurrency and threading will be managed in a system. Behavioral Viewpoints Capture the expected behavior of (parts of) a system.

Viewpoints Multiple views can be taken from the same viewpoint for the same system with different details Example: different deployment views taken for same system where one view shows only top level components where another view shows top level components as well as subcomponents and additional internal structure

Importance of Views and Viewpoints They provide a way to limit presented information to a cognitively manageable subset of architecture They display related concepts simultaneously They can be tailored to the needs of specific stakeholders They can be used to display the same data at various levels of abstraction

Consistency Among Views Same or related information is presented in more than one view Whenever duplication is present, consistency issue comes forward How to say the views are consistent? Definition of consistency in terms of views: Views are consistent if the design decision that they contain are compatible with each other

Inconsistency If there is no inconsistency that means views are consistent Inconsistency appears when two views assert design decisions that both at a time can not be true Inconsistency can arise in different ways Direct inconsistency: when two views assert opposite or contradictory design decisions Example: system runs on two hosts, system runs on three hosts This can be detected by automatic mechanism

Inconsistency Refinement inconsistency: when two views of the same system at different level of detail assert contradictory propositions Static aspects verses dynamic aspects: static view and dynamic view contradictory with each other. Somewhat harder to detect automatically Dynamic aspects: contradiction between two dynamic views. Extremely difficult to detect automatically Functional vs. non functional aspects: non functional property proposed by non functional vies is not achieved by functional view. Example: non functional view says system is robust but functionally system has only one server and no provision for system failure. Most difficult to detect

Evaluating Modeling Approaches Q. What are the dimensions that can be used for modeling techniques? Scope and purpose What is intended to model, what is not! What techniques help you to model what does not. Basic elements What are the basic elements that are modeled? How are they modeled? Style To what extent does the approach help you model elements of the underlying architectural style? Is the technique bound to one particular style or family of styles?

Evaluating Modeling Approaches (cont’d) Static and dynamic aspects What static and dynamic aspects of an architecture does the approach help you model? Dynamic modeling To what extent does the approach support models that change as the system executes? Non-functional aspects To what extent does the approach support (explicit) modeling of non-functional aspects of architecture?

Evaluating Modeling Approaches (cont’d) Ambiguity How does the approach help you to avoid (or embrace) ambiguity? Accuracy How does the approach help you to assess the correctness of models? Precision At what level of detail can various aspects of the architecture be modeled?

Specific Modeling Techniques Architects have huge set of notations to model the different aspects of the system These techniques vary based on many things: what they can model, how precisely they can capture architectural semantics, how good their tool support is Which methods are used and for what purpose largely depends on stakeholders Many approaches are suitable in many domains but its not good to be attached to any one approach

Modeling Approaches Generic Technique Natural language PowerPoint-style modeling UML, the Unified Modeling Language Early architecture description languages Darwin Rapide Wright Domain- and style-specific languages Koala Weaves AADL Extensible architecture description languages Acme ADML xADL

Generic Techniques Generic techniques are often used to describe a software in whole or in part These are flexible but have few semantics Three types under generic techniques are: Natural Language Informal graphical PowerPoint-style modeling UML, the Unified Modeling Language

Natural Language Natural languages are obvious way to document architectural design decisions They are ambiguous, non rigorous and informal in nature Can not be effectively processed by machines Can only be checked and inspected by humans Despite these drawbacks, for modeling some aspects of architecture, natural languages are the best modeling languages e.g. non-functional aspects Easily accessible to stakeholders Can be manipulated with common tools such as word processor Alternative is to use restricted form of it: Avoid Similar terms of same meaning Templates can be created with fill in the blanks places which makes it rigor in nature

Natural Language Evaluation Scope and purpose Capture design decisions with extensive vocabulary Basic elements Any concepts required, no special support for any particular concept Style Can be described by using more general language Static & Dynamic Aspects Both aspect can be modeled Dynamic Models Models must be changed by human No direct tie up to implemented/running system Non-Functional Aspects Expressive vocabulary available

Natural Language Evaluation Ambiguity Plain natural language tends to be ambiguous; statement templates and dictionaries help Accuracy Manual reviews and inspection Precision Can add text to describe any level of detail Viewpoints Any viewpoint (but no specific support for any particular viewpoint) Viewpoint consistency

Informal Graphical Power Point Style Tools like power point OmniGraffale provides ability to create decorative diagrams Supports easier way to create diagrams or charts Diagrams are easier way to express and understand Size limitation (one slide) helps to maintain abstract nature Informal graphical method similar to natural language as it also provide informal unconstrained way of expressing ideas Captures few semantics But lack in rigor required for more concrete models

Informal Graphical Model Example Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

Related Alternatives Some diagram editors (e.g., Microsoft Visio) can be extended with semantics through scripts and other additional programming Generally ends up somewhere in between a custom notation-specific editor and a generic diagram editor Limited by extensibility of the tool PowerPoint Design Editor (Goldman, Balzer) was an interesting project that attempted to integrate semantics into PowerPoint

Informal Graphical Evaluation Scope and purpose Arbitrary diagrams consisting of symbols and text Basic elements Geometric shapes, splines, clip-art, text segments Style In general, no support to a specific style Static & Dynamic Aspects Any aspect can be modeled, but no semantics behind models Dynamic Models Rare, although APIs to manipulate graphics exist Non-Functional Aspects With natural language annotations

Informal Graphical Evaluation Ambiguity Can be reduced through use of rigorous symbolic vocabulary/dictionaries Accuracy Manual reviews and inspection Precision Up to modeler; generally canvas is limited in size (e.g., one ‘slide’) Viewpoints Any viewpoint (but no specific support for any particular viewpoint) Viewpoint consistency

Unified Modeling Language Designed by Booch, Rambaugh and jacobson Most popular notation for writing down software designs UML is a very big language to understand It captures all details in different views Its viewpoint remains focused on design only It is biased towards object oriented languages UML diagram alone can not carry many details Natural language support is taken

UML Evaluation Scope and purpose Diverse array of design decisions in 13 viewpoints Basic elements Multitude – states, classes, objects, composite nodes… Style Through (OCL) constraints OCL-object constraint language Static & Dynamic Aspects Some static diagrams (class, package), some dynamic (state, activity) Dynamic Models Rare; depends on the environment Non-Functional Aspects No direct support; natural-language annotations

UML Evaluation Ambiguity Many symbols are interpreted differently depending on context; profiles reduce ambiguity Accuracy Well-formedness checks, automatic constraint checking, ersatz tool methods, manual Precision Up to modeler; wide flexibility Viewpoints Each diagram type represents a viewpoint; more can be added through overloading/profiles Viewpoint consistency Constraint checking, ersatz tool methods, manual

Early Architecture Description Language Research done in 1990’s decade how to best capture software architecture and the result was ADL Notations were developed specifically for architectural modeling Debate was which notations comes under ADL for capturing architectural design decisions Any language which is able to capture principal design decisions comes under ADL including UML Darwin Rapide Wright

Languages under ADL Darwin General purpose ADL Specify structure of system, composed of components communicating through interface Graphical visualization is associated which depicts Darwin configuration in more accessible but less precise way Rapide: Rapid is ADL designed to specify dynamic aspects of the system It is composed of components that communicate using events Where events are simply result of activity Darwin: Checks components interaction