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