2 DefinitionEvery 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
3 Modeling 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
4 Stakeholder-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
5 Stakeholder-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
7 Stakeholder-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
8 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
9 What do We Model? Basic Architectural Concepts/elements Elements of the Architectural StyleStatic and Dynamic AspectsFunctional and Non-functional Aspects
10 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 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
12 Basic 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
13 2. 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
14 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 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
15 2. 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.
16 3. 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..
17 3. 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
18 3. 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
19 3. 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
20 4. 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
21 Functional 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
22 Non-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
23 Important 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
24 AmbiguityAmbiguityA 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
25 Ambiguity 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
26 Accuracy 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
28 Complex 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.
29 Views 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
30 ViewpointsViewpoint 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
31 Viewpoints 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.
32 ViewpointsMultiple 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
33 Importance 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
34 Consistency 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
35 InconsistencyIf 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
36 InconsistencyRefinement 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
37 Evaluating 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?
38 Evaluating 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?
39 Evaluating 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?
40 Specific 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
41 Modeling Approaches Generic Technique Natural language PowerPoint-style modelingUML, the Unified Modeling LanguageEarly architecture description languagesDarwinRapideWrightDomain- and style-specific languagesKoalaWeavesAADLExtensible architecture description languagesAcmeADMLxADL
42 Generic 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
43 Natural 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
44 Natural 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
45 Natural 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
46 Informal 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
48 Related 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
49 Informal 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
50 Informal 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
51 Unified 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
52 UML 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
53 UML 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
54 Early 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
55 Languages 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