2DefinitionEvery software system has an architecture either good or not goodCapturing and recorded design decisions is modelingDefinition:Architectural Model: An architectural model is an artifact that captures some or all of the design decisions that comprise a system’s architectureArchitectural modeling: Architectural modeling is the reflection and documentation of those design decisionsModels help us to communicate, visualize, evaluate & evolve an architecture
3Modeling NotationsHow we model is strongly influenced by the notations we choose:An architectural modeling notation is a language or means of capturing design decisionsNotations can be rich and ambiguous like natural language or can be semantically narrow and highly formal e.g. RapidBroad variety of modeling notations are covered in this chapter
4Stakeholder-Driven Modeling Architects and other stakeholders must make critical decisions:What architectural decisions and concepts should be modeled,At what level of detail, andWith how much rigor or formalityDecisions should be based on costs and benefits
5Stakeholder-Driven Modeling The benefits of creating and maintaining an architectural model must be balanced with the cost of doing soChoice of model and level of details has to be decidedMost important or critical aspects of the system should be model in greatest detail with highest degree of formality/rigor
7Stakeholder-Driven Modeling Basic activities behind stakeholder driven modeling:Identify relevant aspects of the software to modelRoughly categorize them in terms of importanceIdentify 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 goalsCreate the modelsUse the models in a manner consistent with modeling goals
8These 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
9What do We Model? Basic Architectural Concepts/elements Elements of the Architectural StyleStatic and Dynamic AspectsFunctional and Non-functional Aspects
101. 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 dataConnectors: Architectural building blocks that effect & regulate interactions among componentsInterface: Points at which components and connectors interact with the outside world. i.e. with other components and connectorsConfiguration: Combination of connectors and components. Represented via graphs where nodes – components & connectors and edges - interconnectivityRationale: Information that explains why particular architectural decisions were made & purpose of various elements
12Basic Architectural Concepts These concepts forms starting point for architectural modelingNotations: box and arrows to represent components, connectors and interfaceRationale has to be more expressive as it includes information. Rationale is usually model using natural languageBasic 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 oneFor 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
132. Elements of the Architectural Style Arch. Style is collection of design decision in a particular domain, specific to a particular systemModeling arch. Style is very helpful in many waysIt reduces confusion about what is and is not allowed in architectureReduces drift and erosionHelp to guide evolution of arch.Reusable from project to projectDesign decision in architectural style is more abstract or general than in architecture
142. 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 modelingComponent 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
152. Elements of the Architectural Style Interaction constraints: constraints may exist on interaction between components and connectorsTemporal 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 specifiedCan be model using first order logic, temporal logic etcBehavioral 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.
163. Static and Dynamic Aspects Static aspects do not change. They do not involve system’s behavior while it is executingDynamic aspects of the system involves system’s runtime behaviorStatic 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..
173. Static and Dynamic Aspects Dynamic aspects of the system deal with how a system behaves or changes over timeDynamic aspects are harder to modelBehavioral model, interaction model or data flow model contains dynamic aspect of the system. behavior, mode of interaction and data flow may change over time
183. Static and Dynamic Aspects Static/dynamic distinction is not a clear lineSome 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
193. Static and Dynamic Aspects Static model captures properties of the systemStatic models can be in read only formDynamic models refers to how the system(internal state) changes in as it executesDynamic models changes itselfDynamic models has to be in machine readable and writable form
204. Functional and Non-functional Aspects Functional aspects relate to WHAT system doesNon-functional aspects relates to HOW system performs its functionExample:Functional: system prints medical recordNon-Functional: quickly and confidentially
21Functional AspectsFunctional aspects are more concrete and hence easier to modelCan be modeled rigorously and formallyServices provided by different components or connectorsBehavior of the systemFunctional models can be static or dynamic in natureMost modeling notation focus on capturing functional aspects of the system
22Non-Functional Aspects Modeling non functional aspect is not as perfect as functional aspectsMany times Functional aspects are designed to achieve non functional properties of the systemIt is more informalSimilar to rationale, non functional aspects are difficult to modelThey have to be more expressive and free from notationsNatural language type notations are used for modeling non-functional aspects
23Important Characteristics of Models Architectures are abstraction of the systemMost important aspects of the system will be well defined by architecturesArchitectures are not complete implementation of systemNotations used to capture architecture do not have to be completely unambiguous, accurate and preciseThree key cancers of architectural model are:Ambiguity , precision and accuracy
24AmbiguityAmbiguityA model is ambiguous if it is open to more than one interpretationConflicting interpretation of model results in misunderstanding, errors, bugsIt is generally desirable to avoid ambiguity in the systemIncompleteness is a primary reason for ambiguity in modelsUnspecified aspects results into different assumption of stakeholders
25Ambiguity Architectures are incomplete Impossible to completely eliminate ambiguityIt will increase costArchitects decides that architecture is ‘complete enough’Ambiguous aspects are better to be specified using rationale
26Accuracy and Precision A model is accurate if it is correct, conforms to fact, or deviates from correctness within acceptable limitsA model is precise if it is detailed, sharply exact or delimited
28Complex Modeling Architectural models are complex artifacts Models captures all design decisions that are important to variety of stakeholdersDifferent aspects of the same concept are captured simultaneously e.g. components behavior, interconnection and version history are captured separately about every componentToo much information available to deal withArchitects prefer to work with parts of architectureVarious 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.
29Views and ViewpointsCapturing everything in one model will make that model complex, confusing and too bigDifferent aspects are captured in different models these subsets are called as viewsViews captures different concerns about the same conceptThese concerns or criteria about with which a view is taken viewpointView: a view is a set of design decisions related by a common concern or set of concernsViewpoint: a viewpoint defines the perspective from which a view is taken
30ViewpointsViewpoint is a filter to the information and view is what you see about the system through that filterViewpoint is different angles with which system can be seenViewpoints are means to capture different information of same concerns
31Viewpoints Viewpoints that are commonly used: Logical Viewpoints Capture the logical (often software) entities in a system and how they are interconnected.Physical ViewpointsCapture the physical (often hardware) entities in a system and how they are interconnected.Deployment ViewpointsCapture how logical entities are mapped onto physical entities.Concurrency ViewpointsCapture how concurrency and threading will be managed in a system.Behavioral ViewpointsCapture the expected behavior of (parts of) a system.
32ViewpointsMultiple views can be taken from the same viewpoint for the same system with different detailsExample: 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
33Importance of Views and Viewpoints They provide a way to limit presented information to a cognitively manageable subset of architectureThey display related concepts simultaneouslyThey can be tailored to the needs of specific stakeholdersThey can be used to display the same data at various levels of abstraction
34Consistency Among Views Same or related information is presented in more than one viewWhenever duplication is present, consistency issue comes forwardHow 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
35InconsistencyIf there is no inconsistency that means views are consistentInconsistency appears when two views assert design decisions that both at a time can not be trueInconsistency can arise in different waysDirect inconsistency: when two views assert opposite or contradictory design decisionsExample: system runs on two hosts, system runs on three hostsThis can be detected by automatic mechanism
36InconsistencyRefinement inconsistency: when two views of the same system at different level of detail assert contradictory propositionsStatic aspects verses dynamic aspects: static view and dynamic view contradictory with each other. Somewhat harder to detect automaticallyDynamic aspects: contradiction between two dynamic views. Extremely difficult to detect automaticallyFunctional 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
37Evaluating Modeling Approaches Q. What are the dimensions that can be used for modeling techniques?Scope and purposeWhat is intended to model, what is not! What techniques help you to model what does not.Basic elementsWhat are the basic elements that are modeled? How are they modeled?StyleTo 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?
38Evaluating Modeling Approaches (cont’d) Static and dynamic aspectsWhat static and dynamic aspects of an architecture does the approach help you model?Dynamic modelingTo what extent does the approach support models that change as the system executes?Non-functional aspectsTo what extent does the approach support (explicit) modeling of non-functional aspects of architecture?
39Evaluating Modeling Approaches (cont’d) AmbiguityHow does the approach help you to avoid (or embrace) ambiguity?AccuracyHow does the approach help you to assess the correctness of models?PrecisionAt what level of detail can various aspects of the architecture be modeled?
40Specific Modeling Techniques Architects have huge set of notations to model the different aspects of the systemThese techniques vary based on many things: what they can model, how precisely they can capture architectural semantics, how good their tool support isWhich methods are used and for what purpose largely depends on stakeholdersMany approaches are suitable in many domains but its not good to be attached to any one approach
41Modeling Approaches Generic Technique Natural language PowerPoint-style modelingUML, the Unified Modeling LanguageEarly architecture description languagesDarwinRapideWrightDomain- and style-specific languagesKoalaWeavesAADLExtensible architecture description languagesAcmeADMLxADL
42Generic TechniquesGeneric techniques are often used to describe a software in whole or in partThese are flexible but have few semanticsThree types under generic techniques are:Natural LanguageInformal graphical PowerPoint-style modelingUML, the Unified Modeling Language
43Natural LanguageNatural languages are obvious way to document architectural design decisionsThey are ambiguous, non rigorous and informal in natureCan not be effectively processed by machinesCan only be checked and inspected by humansDespite these drawbacks, for modeling some aspects of architecture, natural languages are the best modeling languages e.g. non-functional aspectsEasily accessible to stakeholdersCan be manipulated with common tools such as word processorAlternative is to use restricted form of it:Avoid Similar terms of same meaningTemplates can be created with fill in the blanks places which makes it rigor in nature
44Natural Language Evaluation Scope and purposeCapture design decisions with extensive vocabularyBasic elementsAny concepts required, no special support for any particular conceptStyleCan be described by using more general languageStatic & Dynamic AspectsBoth aspect can be modeledDynamic ModelsModels must be changed by human No direct tie up to implemented/running systemNon-Functional AspectsExpressive vocabulary available
45Natural Language Evaluation AmbiguityPlain natural language tends to be ambiguous; statement templates and dictionaries helpAccuracyManual reviews and inspectionPrecisionCan add text to describe any level of detailViewpointsAny viewpoint (but no specific support for any particular viewpoint)Viewpoint consistency
46Informal Graphical Power Point Style Tools like power point OmniGraffale provides ability to create decorative diagramsSupports easier way to create diagrams or chartsDiagrams are easier way to express and understandSize limitation (one slide) helps to maintain abstract natureInformal graphical method similar to natural language as it also provide informal unconstrained way of expressing ideasCaptures few semanticsBut lack in rigor required for more concrete models
48Related AlternativesSome diagram editors (e.g., Microsoft Visio) can be extended with semantics through scripts and other additional programmingGenerally ends up somewhere in between a custom notation-specific editor and a generic diagram editorLimited by extensibility of the toolPowerPoint Design Editor (Goldman, Balzer) was an interesting project that attempted to integrate semantics into PowerPoint
49Informal Graphical Evaluation Scope and purposeArbitrary diagrams consisting of symbols and textBasic elementsGeometric shapes, splines, clip-art, text segmentsStyleIn general, no support to a specific styleStatic & Dynamic AspectsAny aspect can be modeled, but no semantics behind modelsDynamic ModelsRare, although APIs to manipulate graphics existNon-Functional AspectsWith natural language annotations
50Informal Graphical Evaluation AmbiguityCan be reduced through use of rigorous symbolic vocabulary/dictionariesAccuracyManual reviews and inspectionPrecisionUp to modeler; generally canvas is limited in size (e.g., one ‘slide’)ViewpointsAny viewpoint (but no specific support for any particular viewpoint)Viewpoint consistency
51Unified Modeling Language Designed by Booch, Rambaugh and jacobsonMost popular notation for writing down software designsUML is a very big language to understandIt captures all details in different viewsIts viewpoint remains focused on design onlyIt is biased towards object oriented languagesUML diagram alone can not carry many detailsNatural language support is taken
52UML Evaluation Scope and purpose Diverse array of design decisions in 13 viewpointsBasic elementsMultitude – states, classes, objects, composite nodes…StyleThrough (OCL) constraints OCL-object constraint languageStatic & Dynamic AspectsSome static diagrams (class, package), some dynamic (state, activity)Dynamic ModelsRare; depends on the environmentNon-Functional AspectsNo direct support; natural-language annotations
53UML Evaluation Ambiguity Many symbols are interpreted differently depending on context; profiles reduce ambiguityAccuracyWell-formedness checks, automatic constraint checking, ersatz tool methods, manualPrecisionUp to modeler; wide flexibilityViewpointsEach diagram type represents a viewpoint; more can be added through overloading/profilesViewpoint consistencyConstraint checking, ersatz tool methods, manual
54Early Architecture Description Language Research done in 1990’s decade how to best capture software architecture and the result was ADLNotations were developed specifically for architectural modelingDebate was which notations comes under ADL for capturing architectural design decisionsAny language which is able to capture principal design decisions comes under ADL including UMLDarwinRapideWright
55Languages under ADL Darwin General purpose ADL Specify structure of system, composed of components communicating through interfaceGraphical visualization is associated which depicts Darwin configuration in more accessible but less precise wayRapide:Rapid is ADL designed to specify dynamic aspects of the systemIt is composed of components that communicate using eventsWhere events are simply result of activityDarwin:Checks components interaction