1. Modeling the Architecture
Every software system has an architecture (a set of principal design decisions) that may be captured by models.
Architectural “modeling” is the act of reifying (concretizing) and documenting the design decisions.
Architectural modeling notation is the language used for capturing the design decisions.
and
Architectural model is:
the artifact that captures all the design decisions, via modeling with some notations, that comprise a system’s architecture.

2. Architectural Modeling
Some “Key” decisions in modeling:
Which design decisions and concepts should be modeled?
Which ones are important & importance is based on what criteria?
To what level of depth and detail should the decisions be modeled?
Should the more important or the more complex or the larger design decisions be modeled with deeper levels?
To what level of rigor and formality should the decisions be modeled?
Which notation should we use and how formal a notation should we use?
Remember that this should also includes a “cost-benefit “ tradeoff decision.

3. Some Modeling Related Concepts to Consider
Stakeholder-Driven Modeling
Basic architectural entities (concepts)
Elements of architectural styles
Static and dynamic aspects
Functional and non-functional aspects

4. Stakeholder-Driven Modeling
It is clear that not every design decision is viewed with same level of concern. It depends on the stakeholders of the project and may also vary from project to project.
Thus modeling should be stakeholder driven using a process (set of steps) such as:
Identify (by stakeholders) the relevant aspects of the software to model
Categorize the aspects in terms of importance (based on some criteria stated by stakeholders)
Identify the goals of modeling for each aspect (quality analysis, ease of use, reduction of complexity, communications, etc.)
Select modeling notation (s) --- based on importance & “goal” of modeling (e.g. UI - modeling language for “ease of use”)
Create the model
Use the model in a manner consistent with the modeling goals

5. Basic Architectural Entities (concepts)
In architectural modeling, we need to include the following main entities:
Components
Describe the basic functional building blocks and what functionality and data are encapsulated in each component.
Connectors
Describe those basic building blocks that facilitate the interaction among the functional components
Interfaces
Describes the points where the components and connectors interact with the external world such as users, other systems, or other connectors.
Configurations
Describes the relations and associations among components and connectors.
Rationale
Describes the reasons behind the design decisions and what purpose various entities serve.
Modeling these entities require some language , and we may have to use different
ones to best represent different entities. For example configuration may be best
expressed with a graph, but rationale may require using natural language.

6. Elements of Architectural Styles
Architectural style is a design decision that is 1) applicable to a given context, 2) constrain the design decisions to that context , and 3)elicit beneficial properties from that resulting system. Thus architectural style should be included in modeling because:
Clarifies about what is allowed and what is not
Makes it easier to distinguish design decisions
Reduces potential future architectural drift and erosion
Helps guide evolution of architecture
Captures cross-cutting (general) concerns (e.g. performance, security, etc.)
“Style” model includes (some constraints):
Specific elements (of components, connectors, and interfaces); these may be facilitated by a modeling template
“Types” of components, connectors, and interfaces that satisfy certain system constraint
Interaction constraints among the elements, such as in client-server interaction using a prescribed protocol
Behavioral constraints, including concurrency, on the elements using some state transition diagram to depict a complete system

7. Static and Dynamic Aspects
Static aspect of a system addresses those characteristics of the system that does not change over time such as (a) the number of components and connectors and their structural topology or (b) what a component is functionally responsible for
Dynamic aspect of a system addresses the characteristics of the system that change over time.
It addresses the behavioral (execution) aspects of the system and thus is more difficult to model. (e.g. real-time trigger and process)
It also addresses how the overall system (state) itself changes over time.

8. Functional and Non-functional Aspects
Functional aspects of a system captures what services or functionalities are provided by the system. [comes pretty naturally from stakeholder requirements]
Non-functional aspects of a systems describes what properties the system must have and how the functionalities are delivered (e.g. performance, security, reliability, etc.) [not easily transformed from requirements]
*Note that sometimes a functional component is developed to satisfy a
non-functional aspect. (e.g. accessing the system needs to be secure --- leading to a functional aspect of checking for user id and password or putting access control on tables in database.)

9. Potential “Problems” of Architectural Models
An architecture is a set of principal design decisions made about the system; thus in a sense it is an abstraction of the system. Thus, in capturing or modeling the architecture, we need to be cognizant of potential problems:
Ambiguity
Accuracy (correctness)
Precision (exactness)

10. Ambiguity
Since architecture only captures the “principal” design decisions it may not be i) complete or ii) deep enough, causing the architecture model to be ambiguous.
A model is ambiguous if it is open to more than one interpretation.
An architectural model that admits multiple interpretations will lead to ambiguity and potential errors in design.
1.This problem is often addressed through design inspections, and clarifications
should be provided in the design rationale section in a cost effective manner.
2. Beware that some architectural modeling notation (language) admits ambiguity.

11. Accuracy and Precision
The architectural model should be, but may not be, accurate and precise since it is an abstraction of the sytem.
A model is accurate if it is correct (conforms to fact) or deviates from “correctness” in a limited manner
A model is precise if it is detailed, specific and exact
Note that we can be wrong and be very detailed and exact (precise). Thus between accuracy and precision, one should strive for accuracy before precision.
e.g. Conversion rate between US. Dollar to Japanese yen on 3/5/2015:
$1 = yen (accurate and precise)
$1 = 98 yen (accurate but imprecise)
$1 = 365 yen (inaccurate and imprecise)
$1 = yen (inaccurate but precise)
Assuming that 98.45
is the conversion rate

12. Modeling Complexity: Multiple Views & Mixed Content
No single approach can capture all aspects of an architecture; thus different aspects of architecture (functional, nonfunctional, structural, physical, etc.) may need to be modeled using different approaches or perspective.
An architectural view is a set of design decisions related by some common concern
An architectural viewpoint is the perspective from which a view is taken
A view is an instance of a viewpoint of a system, where a viewpoint is associated with one common concern. Examples of viewpoints are:
Logical viewpoint : system entities and their relationships
Physical viewpoint: hardware entities and their relationship to system
Deployment viewpoint: logical entities mapped to physical entities
Behavioral viewpoint: system states and processing characteristics
Concurrency or parallelism viewpoint: concurrency and threading control

13. Comparing to Kruchten’s 4 + 1 ?
Krutchen authors
Logical logical
Process behavioral; concurrency
Physical physical; deployment
Development
and Scenarios

14. Views and Viewpoint
Architectural Views and Viewpoints provide advantages such as:
Limit the presentation to a cognitively manageable subset of the architecture (the old decompose/separation of concern/modularity idea)
brings related concepts together (old cohesion idea)
Tailors to the needs of specific stakeholders
Displays the information at various levels of abstraction within the viewpoint
Views and viewpoints which contain the same information must be consistent. Potential inconsistencies include:
Two views or viewpoints directly contradict each other
Two refinements of the same view or viewpoint contradict each other
The static versus the dynamic aspects of the view or viewpoint contradict each other
Functional versus non-functional aspects of views do not meet the same needs or contradict each other.
Dynamic aspects of two views contradict each other.

15. Modeling Techniques and Languages (Notations)
There are many different ways to model and many different notations to use to capture the model, ranging from natural language to the highly popular UML for OO design.
In evaluating modeling technique and language one should consider the following points:
Scope and purpose of the technique/language
Basic elements or concepts that are modeled
Styles of architecture that are supported or not supported
Extent of static and dynamic aspects of the architecture supported
Support for changes and reflecting dynamic changes of the architecture
How well is non-functional aspects supported, assuming functional aspects are supported
How much support is there in checking for ambiguity and accuracy
How detailed can the system architecture be modeled to suffice precision
What viewpoints are supported
How much view and viewpoint consistency is checked
There probably is not a one modeling technique/notation that can satisfy all these

16. Wide Spectrum of Architectural/Design Modeling Languages
General:
Natural language (e.g. English)
Boxes and Lines (e.g. Power Point , vision tools)
OO based and most popular today:
Unified Modeling Language (UML) which includes 13 different diagrams:
Class diagram,
component diagram,
composite structure diagram,
deployment diagram,
object diagram,
package diagram;
activity diagram,
state transition diagram,
use case diagram;
communication diagram,
interaction diagram,
sequence diagram,
timing diagram-a specific kind of interaction diagram.

17. Architectural Description Languages
Some Architectural Description Language (ADL) which modeled components, connectors, interfaces, and configurations:
Darwin: for distributed or interconnected architecture modeling (Imperial College)
Rapide: a language framework that contains a type language, arch def. language, specification constraint language, and concurrent programming language used to support large distributed systems (Stanford U.)
Wright: component interface language that allows for interface checking (CMU)
Koala: models consumer electronic domain-specific designs (Philips electronics)
Weaves: a language for modeling concurrent, communicating components called “tool fragments” (Aeorspace Corporation)
AADL: models real-time, embedded system for avionic, automotive, and other industries; outgrowth of Honewell’s MetaH (Honeywell, SEI-CMU, US Army)
Acme: An extensible modeling language that allows modeling extensions to its 7 baseline constructs of components, connectors, ports, roles, attachments, systems, and representations. Extensibility is provided via properties which are decorations applied to one of the seven basic constructs (CMU and USC)
ADML: XML based architecture description language whose syntax is derived from Acme
xADL: also an XML based language where extensions are introduced as first class entities, not just as extensions to the basic constructs

18. DARWIN
One of the “early” general-purpose ADL focused on:
Components
Interfaces
Configuration (Composition)
Darwin notation allows the modeling of “interconnected components” and primarily provides a structural description

19. Darwin Syntax Example Component DataStore { provide x-values; }
Component Calculation {
require x-values;
provide calc-results;
Component UserInterface{
require calc-results;
Component AppSWE6653{
inst
UI: UserInterface;
C: Calculation;
D: DataStore;
bind
C.x-values - - D.x-values;
UI.x-values - - D.x-values;
UI.calc-results - - C.calc-results;

20. Darwin Graphical Representation
AppSWE6653
x-values
x-values
DataStore
UserInterface
calc-results
calc-results
x-values
Calculation
= requires
Note: that any component may be further decomposed
= provides

21. Acme (another Architecture Description Language - ADL)
Primary Purpose: Provide an interchange format for architectural development tools and environment
Primary goals:
Provide a representational scheme that will permit development of new tools --- for analyzing and visualizing architectural structures
Provide foundation for developing new, possibly domain specific ADL
Serve as a vehicle for creating conventions and standards for architectural information
Provide expressive descriptions that are easy for human to read and write.

22. Acme’s Basic Types of Entities
Acme’s 7 basic elements:
Component
Connector
System
Port – interfaces of the components
Roles – interfaces of the connectors
Representations – lower level description of component/connector
Representation Maps – a mapping between more detailed internal representation and an external representation
3 Primary Types

23. Graphical Acme system component component connector representations
Re-Map 1
Re-Map 2
role
port
Representation- maps

24. Acme in text form System simple_one = {
component c1 = { port send-request }
component c2 = { port receive-request}
connector call1 = { roles {caller, receiver} }
attachments : { c1.send-request to call1.caller;
c2.receive-request from call1.receiver}

25. Architecture Analysis & Design Language (AADL)
This design modeling language was initially targeted for the description and analysis of systems for the avionic industry.
It has expanded to facilitate a wide variety of systems; it is not bound to any specific industry.
The “fundamental” element in this language is the Component which has a :
unique name,
set of properties,
interface to other components and
subcomponents

26. AADL Component
Component is identified via its “type” & there are 3 categories of 10 predefined “types” of components
Application software:
Thread
Thread group
Process
Data
Subprogram
Execution platform:
Processor
Memory
Device
Bus
Composite:
System

27. Graphical Representation of AADL Component types
device
memory
process
data
thread
thread
group
processor
bus
subprogram
Application Software
Execution Platform
system
Composite

28. Simple Example of a Component
Process Component
features
Flows
Properties
Component Implementation
subcomponents -
connections
call sequence
flows
modes
properties

29. AADL Component Type & Component Implementation
Component implementation identifier
- Subcomponents
- Calls
- Connections
- Flows
- Modes
- Properties
Component type & identifier
- Features
- Flows
- Properties
Component Type is one of the previous 10 types
- declares the interfaces & I/O via Features (e.g. ports that are synchronous calls, data queued, etc)
- declares specific info transfer channels via Flow
- declares externally observable properties via Properties (e.g. “thread” type may execute periodically, aperiodic event-driven, in background, or with some timing constraint, or with a device, etc.)
-Subcomponents, Calls and Connections provide
the composition of the Component
-Flows specify end-to-end flow across subcomponents
-Modes indicate alternative operational flow, alternative
configuration, or alternative properties (e.g. normal,
backup-recovery, novice/expert, etc.)
-Properties specify properties that apply to all instances
of this component (e.g. must run on Apple OS)

30. More clauses in AADL Component and Implementation
“Extends” clause may be used in Component and Implementation declarations to inherit characteristics of another, original Component
If used in Implementation declaration, Extends may be used to specify multiple implementation for the same component (e.g. implementation on MS OS, Unix, Apple OS may have different performance, difference security, etc.)
“Refine” clause may be used in Implementation declaration to complete a partially specified implementation (e.g. an implementation template)

31. Additional ADDL features
Packages – allows declaration of groups of components to be organized into separate units with their own names (e.g. search methods)
Property Set – allows a definition of a named group of related sub-properties (e.g. DB security levels)
Annex – allows the declaration of extensions to the core language such as a Fault-Tree model for reliability analysis