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
• Architects and other stakeholders must make critical decisions:1. What architectural decisions and concepts
should be modeled,2. At what level of detail, and3. 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:
1. Identify relevant aspects of the software to model2. Roughly categorize them in terms of importance3. Identify the goals of modeling for each aspect
(communication, bugs finding, quality analysis and so on)4. Select modeling notation that will model the selected aspects
at appropriate levels of depth to achieve the modeling goals5. Create the models6. Use the models in a manner consistent with modeling goals
Stakeholder-Driven Modeling
• 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
1. Basic Architectural Concepts/elements2. Elements of the Architectural Style3. Static and Dynamic Aspects4. Functional and Non-functional Aspects
What do We Model?
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 elements– Components– Connectors– Interfaces– Configurations– Rationale – reasoning behind decisions
11Software 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
Basic Architectural Concepts
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
• 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.
2. Elements of the Architectural Style
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..
• 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
3. Static and Dynamic Aspects
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
• 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
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
23
• 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
Ambiguity
Accuracy and Precision
• 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
27
Inaccurate and imprecise:
incoherent or contradictory
assertions
Accurate but imprecise:
ambiguous or shallow
assertions
Inaccurate but precise: detailed
assertions that are wrong
Accurate and precise: detailed
assertions that are correct
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.
• 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
Viewpoints
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
• 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
Consistency Among Views
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?
37
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?
38
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?39
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
41
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
44
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
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 Manual reviews and inspection
Natural Language Evaluation
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
47Software 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
48
49
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
Manual reviews and inspection
Informal Graphical Evaluation
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
52
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
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
UML Evaluation
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 wayRapide:• 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 activityDarwin:• Checks components interaction
Top Related