Architectural Standards

Objectives

Concepts
What are standards?
Why use standards?
And why not? (drawbacks)
Deciding when to adopt

Objectives

Concepts
What are standards?
Why use standards?
And why not? (drawbacks)
Deciding when to adopt

What are standards?

Definition: a standard is a form of agreement between

De jure and de facto standards

Some standards are controlled by a

De jure and de facto standards (cont’d)

Some standards emerge through widespread

Examples of de jure and de facto

De jure standards
UML (managed by

Gray-area Standards

HTML
Officially standardized by W3C, indicating de jure
Flavors and browser-specific extensions

Another spectrum

Standards (whether de jure or de facto) can be:
Open
Allow public

Open vs. closed standards

Another spectrum with a gray area
Some standards bodies

Why use standards?

Standards are an excellent way to create and exploit

Why use standards? (cont’d)

To ensure interoperability between products developed by different

Drawbacks of standards

Limits your agility
Remember that doing ‘good’ architecture-based development means

Overspecification vs. underspecification

A perennial tension in standards use and development
Overspecification
A standard

Two different kinds of underspecification

Two compromises often made in negotiation when

When to adopt a standard?

Early adoption
Benefits
Improved ability to influence the standard
Get

When to adopt a standard? (cont’d)

Early adoption
Drawbacks
Risk of failure
Standard may not

When to adopt a standard? (cont’d)

Late adoption
Benefits
Maturity of standard
Better support
Drawbacks
Inability to

Objectives

Concepts
What are standards?
Why use standards?
And why not? (drawbacks)
Deciding when to adopt

IEEE 1471

Recommended practice for architecture description
Often mandated for use in government

IEEE 1471 (cont’d)

Very high level
Purposefully light on specification
Does not advocate any

Department of Defense Architecture Framework

DoDAF, evolved from C4ISR
Has some other international

DoDAF (cont’d)

Some vocabulary inconsistency with our terms (and IEEE 1471 among

DoDAF (cont’d)

Three views (in our terms: viewpoint sets)
Operational View (OV)
“Identifies what

DoDAF (cont’d)

Three views (in our terms: viewpoint sets) – continued
Technical Standards

DoDAF Examples

OV-1 “High-Level Operational Concept Graphic”

Software Architecture: Foundations, Theory, and Practice; Richard

DoDAF Examples (cont’d)

OV-4 “Organizational Relationships”

Software Architecture: Foundations, Theory, and Practice; Richard N.

DoDAF Examples (cont’d)

SV-1 “Systems Interface Description”

Note implied correspondence with OV-1 entities

Software Architecture: Foundations,

DoDAF Examples (cont’d)

SV-3 “Systems-Systems Matrix”

One of several “N2” views in DoDAF

Software Architecture: Foundations,

DoDAF Examples (cont’d)

TV-1 “Technical Standards Profile ”

Software Architecture: Foundations, Theory, and Practice; Richard

DoDAF Takeaways

Extremely comprehensive standard advocating capture of many views
Takes a high-level

The Open Group Architecture Framework

TOGAF – an “enterprise architecture” framework
Focuses beyond

TOGAF Part 1: ADM

An iterative process for architecture-centric development
Each step in

TOGAF Part 2: Enterprise Continuum

Taxonomizes different kinds of architectures and the

TOGAF Part 3: TOGAF Resource Base

A collection of useful information and

TOGAF Takeaways

Large size and broad scope looks at systems development from

RM-ODP

Another standard for viewpoints, similar to DoDAF but more limited in

RM-ODP

Another standard for viewpoints, similar to DoDAF but more limited in

RM-ODP

Another standard for viewpoints, similar to DoDAF but more limited in

UML

As a standard, primarily prescribes a syntax
Some semantics with purposeful ambiguity
Encourages

UML Takeaways

Provide a common syntactic framework to express many common types

SysML

An extended version of UML
Developed by a large consortium of organizations

SysML Diagrams

SysML Requirement Diagram

Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor,

SysML Diagrams

SysML Parametric Diagram

Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor,

Standard UML Tools

E.g., Rational Rose, ArgoUML, Microsoft Visio
These are de facto

ArgoUML – a UML tool

Screenshot from the Argo/UML Website and Documentation

Telelogic System Architect

Formerly Popkin System Architect; popular among architects
Supports 50+ different

Rational Unified Process

Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor,

Model-Driven Architecture

Also known as MDA
Core idea: specify your architecture in detailed

Overall Takeaways

Standards confer many benefits
Network effects, reusable engineering knowledge, interoperability, common

Some More on UML

UML combines several visual specification techniques
use case diagrams,

UML Class Diagrams

Class diagram describes
Types of objects in the system
Static relationships

Example Class Diagram

Order

dateReceived
isPrepaid
number: String
price: Money

dispatch()
close()

Product Order

quantity: Int
price: Money
isSatisfied: Bool

1

1..*

Ordered
Product

Constraint
for order class

Product

1..*

1

Corporate
Customer

contactName
creditRating
creditLimit

remind()
billForMonth(Int)

Customer

name
address

creditRating():String

Personal
Customer
creditCardNumber

indicates
generalization

1

1..*

Employee

0..1

1..*

Sales
Rep

{creditRating()=“poor”}

indicates

Sequence Diagrams

A sequence diagram shows a particular sequence of messages exchanged

Example Sequence Diagram

:ProductOrder

:StockItem

check()

:Order

*prepare()

[check=“true”]

remove()

:OrderEntryWindow

prepare()

:ReorderItem

:DeliveryItem

needsToReorder()

<>

[check=“true”]
<>

[needsToReorder=“true”]

Collaboration Diagrams

Collaboration diagrams show a particular sequence of messages exchanged

Example Collaboration Diagram

:ProductOrder

:StockItem

:Order

:OrderEntryWindow

:ReorderItem

:DeliveryItem

1:prepare()

1.1:*prepare()

1.1.1:check()
1.1.2:[check==true]remove()

1.1.2.1:needsToReorder()

1.1.2.2:new

1.1.3:[check==true]new

message

object

link

sequence number

Sequence numbers are used
to show the time

State Diagrams

State diagrams are used to show possible states a single

State Diagrams

Hierarchical grouping of states
composite states are formed by grouping

Superstates

Checking

do/checkItem

/ getFirstItem

getNextItem
[not all items checked]

Dispatching

do/initiate
Delivery

Waiting

Cancelled

Delivered

itemsReceived
[some items not in stock]

[all items

Concurrent States

Checking

Dispatching

Waiting

Authorizing

Authorized

Delivered

Cancelled

Rejected

[payment not OK]

cancelled

this transition
can only be taken
after both concurrent
states

Activity Diagrams

Activity diagrams show the flow among activities and actions associated

Receive Order

Check Order
Item

Dispatch
Order

Authorize Payment

Cancel Order

Add Remainder
to Stock

[succeeded]

[failed]

Assign to Order

ReceiveSupply

Choose Outstanding Order

UML Diagrams

Functionality, requirements
use case diagrams
Architecture, modularization, decomposition
class diagrams (class structure)
component diagrams,

How do they all fit together?

Requirements analysis and specification
use-cases, use-case diagrams,

Object Constraint Language

Object Constraint Language (OCL) is part of UML
OCL was

Object Constraint Language (OCL)

OCL provides a way to develop more precise

OCL Constraints

OCL constraints are declarative
They specify what must be true not

An Example

Loyalty programs are used by companies to offer their customers

LoyaltyProgram

enroll(c:Customer)

Service

condition: Boolean
pointsEarned: Integer
pointsBurned: Integer
description: String

0..*

deliveredServices

Membership

LoyaltyAccount

points: Integer

earn(i: Integer)
burn(i: Integer)
isEmpty(): Boolean

Customer

name: String
title:String
isMale: Boolean
dateOfBirth:

Types and Instances

OCL types are divided into following groups
Predefined types
Basic types:

Operations on Boolean Type

Boolean operators that result in boolean values
a or

Operations on Integer and Real Types

Operation on Real and Integer with

Operations on String Type

Operations on String type with result type Boolean
s1

Model Types

Model types are classes, subclasses, association classes, interfaces, etc. defined

OCL expressions and constraints

Each OCL expression has a result
the value that

Invariants

Using OCL we can specify class invariants such as
Customer
age >= 18
As

Invariants

We can also write invariants on attributes of associated classes
Examples:
Membership
card.owner =

Writing Pre and Postconditions

One can specify the pre and postcondition of