1. Architectural Modeling
Software Architecture

2. 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

3. 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

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, and
With how much rigor or formality
Decisions 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 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

6. Stakeholder-Driven Modeling

7. 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

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 Style
Static and Dynamic Aspects
Functional 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 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

11. 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.

12. 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

13. 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

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 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

15. 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.

16. 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..

17. 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

18. 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

19. 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

20. 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

21. 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

22. 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

23. 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

24. 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

25. 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

26. 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

27. 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.

28. 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.

29. 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

30. 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

31. 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.

32. 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

33. 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

34. 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

35. 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

36. 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

37. 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?

38. 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?

39. 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?

40. 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

41. 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

42. 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

43. 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

44. 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

45. 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

46. 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

47. 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.

48. 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

49. 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

50. 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

51. 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

52. 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

53. 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

54. 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

55. 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