Integrating Architecture Description Languages with a Standard Design Method

1
Integrating Architecture Description Languages
with a Standard Design Method
jrobbins_at_ics.uci.eduneno_at_ics.uci.eduredmiles_at_ics
.uci.edudsr_at_ics.uci.edu
Jason E. RobbinsNenad MedvidovicDavid F.
RedmilesDavid S. Rosenblum Information and
Computer Science Dept. University of California,
Irvine
2
Overview

• Introduction, Motivation
• UML Background, Brief Tutorial
• UML Constructs
• A Simplified UML Meta-model
• UML Extension Mechanisms
• Extending UML to Model C2 Architectures
• Extending UML to Model Wright Architectures
• Discussion Core Models and Extensions
• References and URLs see www.ics.uci.edu/pub/arch
  /uml

3
Introduction

• Software architecture focuses on high-level
  models of software systems
• Formalists Analysis is the main purpose of a
  modelADLs C2, Wright, Rapide, Darwin, Aesop,
  etc.
• Practitioners Communication is the main
  purposeBooch, OMT, OOSE, ROOM, Fusion, etc.
• We try to get the best of both worldsUse a
  practical, mainstream notation (UML) but extend
  it to get the benefits of an ADL
• We add semantic constraints on the UML
  meta-model to make it match ADL semantics

4
BackgroundUML The Unified Modeling Language

• UML unifies
• Popular OO design notations Booch, OMT, OOSE
• Many views of the system object model, state
  models, use cases, deployment model, etc.
• Notations used for analysis, design, and
  implementation
• UML is well defined
• UML Meta-model defines what is in a UML model
• Object Constraint Language specifies system
  constraints
• UML stereotypes allow the notation to be extended

5
Motivation Why use UML?

• Fairly complete set of models that work together
• Better than current OO design notations
• Reduces training costs, eases communication
• The software industry is in an skills/employment
  crisis
• Evolving into industry standard, market leader
• OMG standard scheduled for late 1998
• Rational, Microsoft, IBM, ObjectTime, HP, Oracle,
  MCI Systemhouse, Unisys, IntelliCorp, I-Logix,
• Dozens of tools support UML notation now, more
  semantic support expected next year

6
Motivation Why use it for research?

• Reduces barriers to technology transfer
• Easier to explain value added over status quo
• Sets an example of what industry values, and what
  they can accept
• Leverages existing skills, training
• Extensive tool support from multiple sources
• Allows for incremental adoption use a little at
  a time
• Formalism is behind the scenes
• Visually more self-explanatory than Booch or OMT
• Catch a wave make our research exciting by
  linking it with exciting, growing, current things

7
UML Constructs Objects

• UML defines constructs for Classes, Attributes,
  Operations, Associations between classes, Class
  Inheritance

0..
stereotype Class1
optional stereotype Name of Class
Association Name
attr2 int
attr1 data_type init
oper1 (arg_list) result_type
Class3
Class2
self.class1.attr2-gtexists( a a mod 2 0 )
8
UML Constructs State Machines

• UML defines constructs for (Hierarchical) States,
  Transitions, Events, Guards, Actions
• Based on Statemate

event(args) condition /action
Super State Name
stereotype State Name
stereotype State Name
9
UML Constructs Collaboration

• UML defines constructs for illustrating
  interactions between instances that occur as part
  of a use case
• Example instances
• Example messages

1 setScreenColors(256)
myWindow
WindowManager
1.1 repaint()
Window
1.2 repaint()
w2
10
UML Constructs Sequences

• UML defines constructs for illustrating
  interactions between instances that occur as part
  of a use case

myWindow
WindowManager
Window
setScreenColors(256)
repaint()
repaint()
11
UML Constructs Components

• UML defines constructs for software components
• Basically defines Makefile-style dependencies

12
UML Constructs Deployment

• UML defines constructs for software components
• Not very well developed

Host Name
Host Name
13
UML Constructs Use Cases

• Informally enumerate expected classes of users
  and usage scenarios (i.e., use cases)
• Show dependency and inheritance among use cases
• Useful as an input to formal requirements

stereotype Use Case
stereotype Use Case
stereotype Use Case
stereotype Use Case
14
UML Constructs Constraints

• Any UML model element can have constraints
  applied to it
• Some constraints are predefined, e.g., or,
  disjoint
• Others can be written in constraint languages,
  e.g., OCL
• Many examples are discussed below
• The Object Constraint Language (OCL) is described
  below

15
UML Constructs Other

• Packages group elements and define name spaces
• Dependencies indicate that if head element
  changes, tail element may need revision
• Notes attach comments to any element

stereotype State Name
Package contents
16
UML Example
(self.robot-gtsize) / (self.worker-gtsize) lt 0.1
0..
Company
Course
1..4
1..
1..
Worker
Trainee
0..
Robot
Person Employee
17
Practitioners View of UML

• What you have seen up to this point is probably
  the type of description most developers will use
  when learning UML
• Examples of notation with explanations in English
• However, UML is defined more formally with a
  meta-model and constraints

18
Four Levels of Modeling

• 1 User Objects in the Running System
• Run-time instances
• Checking of design constraints on running system
• 2 Model of System Under Design
• Instances of UML constructs
• Specify design constraints on running system
• Checking of UML language syntax and semantic
  constraints
• 3 Meta-model
• Abstract syntax of UML constructs defined
• Constraints on use of constructs in Model
• 4 Meta-metamodel
• Data interchange formats between modeling tools
• E.g., CDIF or MOF

19
Stereotype Person

• Stereotype Person for instances of meta-class
  Class
• 1 If a person is in any composite relationship,
  it must be the composite (not one of the parts)
• self.oclType.role.forAll ( myRole
  myRole.association.role-gtexists ( anyRole
  anyRole.aggregation composite) implies
  myRole.aggregation composite)
• This defines a new kind of class that is like a
  regular class, but avoids a certain kind of
  design errors

20
Simplified UML Meta-model
0..
Role
1..
Class
Feature
2.. ordered
0..
Interface
Association
Operation
Attribute
0..
0.. ordered
Parameter
21
UML Extension Mechanisms

• UML predefines a set of flexible constructs
• Tagged values can be applied to any construct
• Constraints can be applied to any construct
• Stereotype are groups of tagged values and
  constraints that can be named and applied to any
  construct
• Stereotypes are the main extension mechanism
• They add semantics w/out changing UML language
• They can be just names, with meaning for humans

22
Object Constraint Language (OCL)

• Useful for
• Constraints on classes, associations
• pre-, post- conditions
• Based on first order predicate logic
• And, or, not, forall, exists
• Set union, intersection, difference, size, etc.
• Strongly typed
• Adds a navigation language to move around
  object models and access attributes
• Every expression is evaluated in the context of
  some construct
• UML compliant tools must check OCL syntax

23
UML Metrics

• 100 Meta-classes
• 70 Attributes on those meta-classes
• 190 Associations between meta-classes
• 180 Constraints on all of that
• Graphical Notation Guide, 142 pagesSemantic
  Reference, 162 pagesOCL reference, 32 pages
• Several books in print, many more on the way

24
Making a New Design Notation

• Imagine you are designing a new language to model
  some aspect of a design/architecture
• Identify modeling requirements
• Invent constructs to model objects of concern
• Define a precise meaning for each construct
• Usually a minimum set of constructs is best
• Test your language to see if it meets stated
  needs
• Document what you have done, e.g. users manual
• Implement tools to support your language
• This assumes a one-shot process with no reuse

25
UML as a Domain Asset for a Design Notation
Product Family

• Product families pay off
• Investigate domain requirements, gain experience
• Invest in a reusable domain model and supporting
  assets
• Only state commonalties in the domain model
• Leave the specifics for the products in the
  family
• UMLs meta-model as reusable asset
• not perfect, but usable and useful, based on
  experience
• UML provides a set of broadly defined constructs
  that might not be defined as precisely as we
  would like
• We can instantiate UML to make a new design
  notation with more specific semantics
• Still backward compatible with standard UML
  tools

26
UML as a Domain Asset for a Design Notation
Product Family

• I feel that ACME and UML are basically on the
  same track, but differ in style and scope
• Meta-model classes ACME 7, UML 100
• Constraint languages ACME uses Armani and more,
  UML uses OCL and more
• We might prefer to use and teach Scheme, but
  industry went for more for Common Lisp

27
BackgroundC2 A Software Architecture Style

• C2 is a style for building systems with complex
  user interfaces
• Architectures consist of components and
  connectors
• Architecture is layered
• Connectors broadcast messages up or down one
  layer
• Request messages only go up Notifications only
  go down
• Components connect to one connector above and one
  below
• For more detail see C2 paper in TSE, June 1996

28
C2 Example
Database Component
Admin IU
User IU
Window System
29
Extending UML to C2C2 Operations

• C2 operations are modeled as stereotyped UML
  operations
• C2 operations are tagged as notifications or
  requests
• C2 messages do not have return values
• Stereotype C2Operation for instances of
  meta-class Operation1 c2MsgType enum
  notification, request 2 not
  self.oclType.parameter-gtexists( p p.kind
  return )

30
Extending UML to C2C2 Components

• C2 components are modeled as stereotyped UML
  classes
• C2 components have exactly two interfaces, one
  labeled top and one labeled bottom
• Request messages can only be sent through the top
  interface, notifications through the bottom
  interface
• C2 components contain four predefined internal
  parts

31
Extending UML to C2C2 Connectors

• C2 connectors are modeled as stereotyped UML
  classes
• A connectors interface is determined by what it
  is connected to, rather than being declared
• There are only three kinds of associations
  allowed between C2 components and C2 connectors
• C2AttachOverComp connector above component
• C2AttachUnderComp connector below component
• C2AttachConnConn connector to connector

32
Extending UML to C2C2 Architectures

• C2 Architectures are modeled as stereotyped UML
  SystemModels
• C2 architectures can only contain elements with
  C2 stereotypes
• The number of attachments each component has is
  limited to one above and one below
• Each component must attach to something
• Let comps self.oclType.elements-gtselect(e
• e.stereotype C2Component),
• comps.role.association-gtsize gt 0

33
C2 Example in UML
C2AttachUnderComp
C2Connector Connector_One
C2AttachOverComp
C2AttachOverComp
34
DiscussionModeling C2 Architectures in UML

• Modeling our style was fairly straightforward
• UML provides a good set of broadly defined
  meta-classes that can be constrained to mean what
  we wanted to say
• Many C2 concepts are similar to those of OO
  design
• Some concepts are very different
• We can represent similar concepts in UML and
  treat others as annotations
• Similar concepts might be checked by UML/OCL
  tools
• C2 specific concepts may still need special tools

35
Extending UML to Wright

• Wright describes system topology and behavior of
  components and connectors with CSP
• Topology can be constrained as done in the C2
  extension
• CSP processes are like UML objects with state
  machines inside, in fact we can define a mapping
  from CSP constructs to state machine constructs
• CSP communication can be mapped to UML messages

36
DiscussionCore Models and Extensions

• We propose using a core model (UML) with a core
  process and adding ADL extensions as needed
• Places emphasis on day-to-day development
  needsLeverages standard notations, tools, and
  skills
• Architecture questions can be answered as they
  arise
• Adds practicality to ADLs, analysis possibilities
  to UML
• Conflicts between extensions can arise, must be
  managed

Core Model (UML)
ADL specific extensions
37
DiscussionCore Models and Extensions

• Analysis is a key goal for architecture
• Where does architecture fit in process?
• Cant always answer questions before they arise
• Dont just stick architecture early in the
  waterfall
• Use architecture to identify/resolve risks
  throughout

Architecture
ADL
ADL
UML
ADL