Modeling

Software Architecture
Lecture 7

Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved.
Software Architecture: Foundations, Theory, and Practice

Objectives
 Concepts
 What is modeling?

 How do we choose what to model?

 What kinds of things do we model?

 How can we characterize models?

 How can we break up and organize models?

 How can we evaluate models and modeling notations?

 Examples
 Concrete examples of many notations used to model software
architectures
 Revisiting Lunar Lander as expressed in different modeling
notations
2
Software Architecture: Foundations, Theory, and Practice

What is Architectural Modeling?

 Recall that we have characterized architecture as the set of
principal design decisions made about a system
 We can define models and modeling in those terms
 An architectural model is an artifact that captures some or all

of the design decisions that comprise a system’s architecture

 Architectural modeling is the reification and documentation of

those design decisions

 How we model is strongly influenced by the notations we choose:
 An architectural modeling notation is a language or means of

capturing design decisions.

3
Software Architecture: Foundations, Theory, and Practice

How do We Choose What to

Model?
 Architects and other stakeholders must make critical
decisions:
1. What architectural decisions and concepts should be
modeled,
2. At what level of detail, and

3. With how much rigor or formality

– These are cost/benefit decisions
 The benefits of creating and maintaining an
architectural model must exceed the cost of doing
so
4
Software Architecture: Foundations, Theory, and Practice

Stakeholder-Driven Modeling

 Stakeholders identify
aspects of the system
they are concerned
about
 Stakeholders decide the
relative importance of
these concerns
 Modeling depth should
roughly mirror the
relative importance of
concerns
From Maier and Rechtin, “The Art of Systems Architecting” (2000)5
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
 Software Architecture: Foundations, Theory, and Practice

What do We Model?

 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.
Software Architecture: Foundations, Theory, and Practice

What do We Model? (cont’d)

 Elements of the architectural style

 Inclusion of specific basic elements (e.g.,
components, connectors, interfaces)
 Component, connector, and interface types

 Constraints on interactions

 Behavioral constraints

 Concurrency constraints

 …

7
Software Architecture: Foundations, Theory, and Practice

What do We Model? (cont’d)

 Static and Dynamic Aspects
 Static aspects of a system do not change as a
system runs
 e.g., topologies, assignment of
components/connectors to hosts, …
 Dynamic aspects do change as a system runs
 e.g., state of individual components or
connectors, state of a data flow through a
system, …

8
Software Architecture: Foundations, Theory, and Practice

What do We Model? (cont’d)

 Functional and non-functional aspects of a system
 Functional
 “The system prints medical records”
 Non-functional
 “The system prints medical records quickly
and confidentially.”
 Architectural models tend to be functional
 It is often important to capture non-functional decisions
 Even if they cannot be automatically or deterministically
interpreted or analyzed

9
Software Architecture: Foundations, Theory, and Practice

Important Characteristics of
Models
 Ambiguity
 A model is ambiguous if it is open to more than one
interpretation
 Accuracy and Precision
 Different, but often conflated concepts

 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 sharply exact or
delimited
10
 Software Architecture: Foundations, Theory, and Practice

Accuracy vs. Precision

Inaccurate and Accurate but

imprecise: imprecise:
incoherent or ambiguous or
contradictory shallow
assertions assertions

Inaccurate but Accurate and

precise: precise:
detailed detailed
assertions that assertions that
are wrong are correct

11

Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice

Views and Viewpoints

 Generally, it is not feasible to capture everything we

want to model in a single model or document
 The model would be too big, complex, and confusing

 So, we create several coordinated models, each

capturing a subset of the design decisions
 Generally, the subset is organized around a particular
concern or other selection criteria
 We call the subset-model a ‘view’ and the concern (or
criteria) a ‘viewpoint’

12
 Software Architecture: Foundations, Theory, and Practice

Views and Viewpoints Example

Deployment view of a 3-tier Deployment view of a

application Lunar Lander system

Both instances of the

deployment viewpoint 13

Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2010 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice

Commonly-Used Viewpoints

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

14
Software Architecture: Foundations, Theory, and Practice

Commonly-Used Viewpoints
(cont’d)
 Concurrency Viewpoints
 Capture how concurrency and threading will be
managed in a system.
 Behavioral Viewpoints
 Capture the expected behavior of (parts of) a
system.

15
Software Architecture: Foundations, Theory, and Practice

Consistency Among Views

 Views can contain overlapping and related design decisions
 There is the possibility that the views can thus become
inconsistent with one another
 Views are consistent if the design decisions they contain are
compatible
 Views are inconsistent if two views assert design
decisions that cannot simultaneously be true
 Inconsistency is usually but not always indicative of problems
 Temporary inconsistencies are a natural part of exploratory
design
 Inconsistencies cannot always be fixed

16
Software Architecture: Foundations, Theory, and Practice

17
Software Architecture: Foundations, Theory, and Practice

18
Software Architecture: Foundations, Theory, and Practice

19
Software Architecture: Foundations, Theory, and Practice

20
Software Architecture: Foundations, Theory, and Practice

21
Software Architecture: Foundations, Theory, and Practice

22