Unified Modeling (Part I)
Overview of UML & Modeling
Elizabeth Bigelow
Carnegie Mellon University
Today’s Lecture
Modeling
Software Architecture
Introducing UML
Software Development Life Cycle
Modeling
Why model?
Kinds of models
Why is it important?
Principles of Modeling
Object-Oriented Modeling
Why Model?
To communicate the desired structure and
behavior of a system
To visualize and control the architecture
To better understand a system and manage risk
To reason about alternatives
Kinds of Models
Iconic (example: model airplane)
Analogic (example: electrical network
modeling the flow of liquid through pipes;
some properties, some structure)
Analytic (example: set of differential equations
claiming to describe how prices change)
What is a model?
A simplification of reality (abstraction)-not the truth, the whole truth and
nothing but the truth…
At the same time, we choose to make
certain parts rigorous
Why is Modeling Important?
We cannot visualize a system in its
entirety--limits to the human ability to
understand complexity
Principles of Modeling
Choice of model has profound influence on how
a problem is attacked and how solution is
shaped
Every model may be expressed at different
levels of precision
The best models are connected to reality
No single model is sufficient
The hard part
Many models of the same thing are
nearly independent (at least in
preparation)
The hard part: fitting them all together
Object Oriented Modeling
The primary strength of object oriented
modeling is helping to pull the various models
together
Traditional methods algorithmically based--tend
to be brittle, hard to change
Does not mean that implementation must be
object oriented, or even in an object oriented
language
Software Architecture
Shaw & Garlan:
Software Architecture is the system level
organization of components (units of code) and
connectors (method invocation, RPC,
network protocols, etc.)
Another definition is that software architecture
is the highest level of system organization in
which one can discern or impose order.
Architectural Decisions





Organization of a software system
Selection of structural elements and their interfaces
by which the system is composed
Behavior (collaboration among elements)
Composition into progressively larger subsystems
Architectural style (patterns, pipe-filter, functional
decomposition, object-oriented, main line
procedure call, event system)
Modeling a System’s Architecture
Design View
Implementation
View
Use Case
View
Process View
Deployment
View
Design View




Classes, interfaces collaborations
Services that should be provided to end
users
Static aspects captured in class diagrams
and object diagrams
Dynamic aspects are captured in
interaction diagrams, statecharts, and
activity diagrams
Process View
Threads and processes that form a
system’s concurrency and
synchronization mechanisms
Addresses performance, scalability and
throughput of the system (focus on
active classes)
Implementation View
Components and files used to assemble
and realize the physical system
Diagrams: component diagrams (static)
and interaction diagrams, statechart
diagrams and activity diagrams
Deployment View
Hardware topology on which the system
executes
Distribution, deliver and installation of the parts
that make up the physical system
Deployment diagrams (static) and interaction,
statechart, and activity diagrams (dynamic)
Use Case View
Use cases describe the system as seen
by its end users, analysts and testers
Static aspects are captured in use case
diagrams and dynamic are captured in
interaction diagrams, statechart
diagrams and activity diagrams
UML Conceptual Model



Building blocks--things, relationships and
diagrams
Rules on how the blocks may be put
together (names, scope, visibility, integrity,
execution)
Common mechanisms (specifications,
adornments, common divisions, extensibility
mechanisms)
Classes and Objects
A class is a set of objects that share the
same attributes, relationships and
semantics.
An object is an instance of a class--an
entity with a well defined boundary and
identity that encapsulates state and
behavior
Key Abstractions





Structural Things (class, interface)
Behavioral Things (dynamic, interactionmessages, state machines)
Grouping Things (packages)
Annotational Things (comments,
constraints)
Relationships (dependency, association,
generalization, realization
Diagrams
Class diagrams
Object diagram
Use case diagram
Sequence diagram
Collaboration diagram
Statechart diagram
Activity diagram
Component diagram
Deployment diagram
Examples
Pilot
Wright Flyer
Take Off ()
Land ()
Turn()
1
2
Wing
1
1
1 Flies * Name
Weight
Increase Throttle()
Brake ()
1
Decrease Throttle()
2
Canard
Rudder
Engine
High Level Statechart for Wright Flyer
Taking
Off
Idle
(Parked)
Flying
Landing
Starts
Engine
Orville
Flexes Wing
<<extends>>
Wilbur
Releases
Catapult
Says Start Engine
Wright Flyer
USE CASE DIAGRAM
Booch, Rumbaugh and
Jacobson
Inception

Business Modeling & Requirements
Elaboration

Analysis, Design, Implementation, Test
Construction

Analysis, Design, Implementation, Test
Transition

Implementation, Test, Deployment
Next Time
Basic Structural Modeling