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.

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.

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

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:

1. Identify (by stakeholders) the relevant aspects of the software to model

2. Categorize the aspects in terms of importance (based on some criteria stated by stakeholders)

3. Identify the goals of modeling for each aspect (quality analysis, ease of use, reduction of complexity, communications, etc.)

4. Select modeling notation (s) --- based on importance & “goal” of modeling (e.g. UI - modeling language for “ease of use”)

5. Create the model6. Use the model in a manner consistent with the modeling goals

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 differentones to best represent different entities. For example configuration may be best expressed with a graph, but rationale may require using natural language.

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

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.

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

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)

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 clarificationsshould be provided in the design rationale section in a cost effective manner.

2. Beware that some architectural modeling notation (language) admits ambiguity.

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 = 98.45 yen (accurate and precise) $1 = 98 yen (accurate but imprecise)

$1 = 365 yen (inaccurate and imprecise) $1 = 365.78 yen (inaccurate but precise)

Assuming that 98.45is the conversion rate

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

Comparing to Kruchten’s 4 + 1 ?

Krutchen authors Logical ------ logical Process ------ behavioral; concurrency Physical ------ physical; deployment Development

and Scenarios

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.

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

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:

1. Class diagram, 2. component diagram, 3. composite structure diagram, 4. deployment diagram, 5. object diagram, 6. package diagram; 7. activity diagram, 8. state transition diagram,9. use case diagram; 10. communication diagram,11. interaction diagram, 12. sequence diagram,13. timing diagram-a specific kind of interaction diagram.

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

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

Darwin Syntax Example

Component DataStore { provide x-values; }Component Calculation { require x-values; provide calc-results; }Component UserInterface{ require x-values; 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; }

Darwin Graphical Representation

AppSWE6653

DataStore

Calculation

UserInterface

x-values

calc-resultscalc-results

x-values

x-values

= requires

= provides

Note: that any component may be further decomposed

Acme (another Architecture Description Language - ADL)

• Primary Purpose: Provide an interchange format for architectural development tools and environment

• Primary goals:1. Provide a representational scheme that will permit

development of new tools --- for analyzing and visualizing architectural structures

2. Provide foundation for developing new, possibly domain specific ADL

3. Serve as a vehicle for creating conventions and standards for architectural information

4. Provide expressive descriptions that are easy for human to read and write.

Acme’s Basic Types of Entities

• Acme’s 7 basic elements:1. Component2. Connector3. System4. Port – interfaces of the components5. Roles – interfaces of the connectors6. Representations – lower level description of

component/connector7. Representation Maps – a mapping between more

detailed internal representation and an external representation

3 Primary Types

Graphical Acme

c1 c2

Re-Map 1 Re-Map 2

system

component componentconnector

portrole

representations

Representation- maps

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}

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

AADL Component

• Component is identified via its “type” & there are 3 categories of 10 predefined “types” of components1. Application software:

• Thread • Thread group• Process• Data• Subprogram

2. Execution platform:• Processor• Memory• Device• Bus

3. Composite:• System

Graphical Representation of AADL Component types

data process

threadgroup

thread

subprogram

Application Software

system

Composite

device memory

bus processor

Execution Platform

Simple Example of a Component

Component Implementation subcomponents - connections call sequence flows modes properties

Process Component

features FlowsProperties

AADL Component Type & Component Implementation

Component type & identifier- Features- Flows- Properties

Component implementation identifier- Subcomponents- Calls- Connections- Flows- Modes- 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)

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)

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