Unified Modeling Language

This page uses modern project management strategies and tools to present the options for strategies and tools during various phases of a web system development project.

Take the Brainbench certification test on the Unified Modeling Language (UML)

Oracle Certified Solution Developer - JDeveloper Skill 2a : Exam #1Z0-513 Object Oriented Analysis and Design with UML

Site Map  
About this site  

Phase 2. Design (Elaboration)

This plan is based on several popular approaches to ameliorate Object Oriented computer systems development:
• Microsoft's Solutions Framework (currently on its way to version 4);
• Rational Unified Process bought by IBM; and
• The ICONIX process proposed by Doug Rosenberg and Kendal Scott in their Applying Use Case Driven Object Modeling with UML", (2001, Addison-Wesley ISBN 0-201-73039-1)

Each phase in the process provides a different perspective for the various roles contributing to the project.

Standard Design Patterns may be used to reuse elements of a system's design.

UML in a Nutshell: A Desktop Quick Reference by Sinan Si Alhir. O'Reilly & Associates, September 1998.

“Unified Modeling Language (UML)” and “Unified Process” in Software Engineering, 2nd Edition. Marciniak, John J., ed. John Wiley, December 2001.

UML Distilled: Applying the Standard Object Modeling Language, 2nd Ed. by Martin Fowler, Kendall Scott (with ICONIX Software Engineering). Addison-Wesley, 1999

The Solutions Design Process Model

A model is a description of a system in a context.

The Muench model is where requirements documents are successively refined as they are converted into design documents, which are also iteratively refined into more glanular (more detailed) specifications.

The MSF descibes how, during the design process, designs become more concrete and detailed.



Audience	Granularity of Requirements	Deliverable	Individual Documents
			Static	Dynamic
End-Users	Business Functional and Non-Functional Requirements	Conceptual Design	Features for stakeholders, Domain Glossary, Deployment Diagrams	Role State Transitions Scenarios through Use Cases in Storyboards using BMPN (Business Process Modeling Notation)
Designers	System Requirements	Logical Design	Logical Database Schema Objects and Services	Robustness Diagrams User Interface Guidelines Activity Diagrams
Developers	Subsystem Requirements	Physical Design	Physical Database Structure (DDL)	Sequence Diagrams Components User Interface User Interface Mockups
Programmers	Unit Requirements	Final Design	Package Diagrams Class Diagrams	Application demo modules Unit Tests

Flow of UML Models Through Stages of Development

Development Stage	Graphical Representations
Use Case Model	Use case, Activity Diagrams
Domain Model	BMPN (Business Process Modeling Notation), Class, State Diagrams
Architectural Design	Robustness, Package, Implementation Diagrams
Detailed Design	Class, Sequence, Package Diagrams
Source Code	Java, C#, C++, XML, DDL

UML (Unified Modeling Language) Graphical Notation Models

OMG's UML 2.1 standard specifies 13 diagrams (up from 8 in UML 1.2). Here is how various authors group the diagrams.

Model Views	Focus	Diagrams
Use Case view	what functionality the system provides to its users. Code generated from this diagram appear in user GUI menus as activity that a user wants to do and which the computer can help.	Use-Case diagrams represents the scope and goals of actors triggering or using use cases within systems. Scenarios are single paths through a use case. — sequences of actions (dyanamic behavior) within autonomous domains. Extension points record the things that can go wrong and provide alternate (extended) scenarios for handling them. "include" and "extend" relationships show decomposition of requirements.
Robustness (Static) view ("rescued" from Jacobson’s Objectory work before UML)	The traceability between what the system does (use cases) to how the system works (sequence diagrams). Done to disambiguate the use cases and identify gaps in the domain model.	Robustness diagrams describe HOW actors use boundary (interface) objects (such as form objects and JSF pages) to communicate with the system. Control objects (controllers) transmit data from boundary objects to persistent entity objects (domain databases or other repositories of data). An improvement. This example is a standard.
Structural (Static) view	what elements are in the system structure.	Class diagrams detail the attributes and operations (methods) in the static (persistent) structural hierarchy of a system. They abstractly describe potential links among objects. Package Diagrams illustrate how model elements are grouped and divided, (how Java package and dependencies between packages are mapped to Java import statements.) Object (Instance) diagrams depict the static structure and data values of a system at a particular (instantaneous) point in time.
Behavioral (Dynamic) view	how elements interact over time (in lifecycles) to provide the functionality of the system.	Two types of Interaction diagrams show how objects interact with each other: Collaboration (Communication) diagrams use numbered arrows to sequence the interaction of messages exchanged between objects. They are used to show how objects in a system interact over multiple use cases. Sequence diagrams allocate behavior to objects. They illustrate when messages (requests and responses) occuring along a vertical timeline (from top to bottom) are activated horizontally among objects (players/roles). Some modeling software, such as Rational Rose, lets you toggle between these two views. The ICONIX methodology eliminates Collaboration diagrams entirely for its redundancy. UML2 added for embedded software Timing Diagrams where time flows from left to right. Additionally: State machine diagrams depict the events / actions causing transitions from initial to intermediate to final states (status). Sample: Java threads Note: Sequence Diagrams cannot be drawn within Visio 2005. Activity diagrams illustrate the behavior of an operation as a set of actions between an initial and final state. “Swimlanes” separates responsibilities among roles. As object-oriented equivalent of flow charts and data-flow diagrams (DFDs), they depict object and control flows between action states. Solid lines between activities illustrate causal relationships. Dashed lines represent producer-consumer relationships. Events are annotated on lines with unadorned words. "(request)" and "(reply)" with parentheses indicate arguments passed between activities. "[Denied]" and "[Approved]" with square brackets indicate conditions. Diamond shapes describe decision branching. A thick dark line illustrates activities performed in parallel. A variant of Activity Diagrams are UML 2.0 Interaction Overview Diagrams to illustrate collaborations among users. Agile modelers begin from a User Interface Flow Diagram (Storyboard)
Implementation view	how the system is realized or implemented (into a jar file).	Component diagrams describe relationships among software components within the implementation environment (such as what <<resides>> in a component Entity). They indicate the choices made at implementation time. UML 2 added ports and interfaces to component diagrams.
Environmental view	the context (run-time configuration) of an implemented system in use.	Deployment diagrams show the configuration of run-time dependencies among artifacts (executables and script files) running on nodes (resources).

Process Models

Process models:

• Value-added Chain Diagram (VACD) diagrams use:
  • 5-sided baseball diamonds to represent objectives
  • "penant flag" shapes to represent processes
  • ovals to represent organizations
  • sharp-cornered solid rectangles to represent roles.
  • sharp-cornered grey rectangles to represent technical terms.

• Event-driven Process Chain (EPC) diagrams describe chronological and business logical dependencies using:
  • 6-sided shapes (which formerly represent manual processes) to represent events.
  • triangles to represent control poins.
  • ovals to represent organizations
  • round-cornered rectangles to represent functions.

UML Graphics Packages

The leading products are:

• MagicDraw from No Magic, Inc. integrates with Openarchitectureware (oAW).
• Enterprise Architect
• Microsoft's Visio, which can be used to reverse engineer code into UML.

  Visio stencil shapes for UML (2.0 and previous versions) plus Visio stencil for SysML from Pavel Hruby.

  Open Source Alternatives to Visio

  UML from a .NET perspective (not in using UML tools but rather in as sketches on whiteboards) at http://www.parlezuml.com

Both textual descriptions and graphical diagrams are necessary to ensure effective communication. So...
• Visual Paradigm
• Telelogic Tau/Developer and Tau/Architect G2 MDA, acquired by IBM in 2007, which does not bode well for the product since
• IBM has Rational Rose, XDE
• Ueli Brawand in Swizerland Sparx Enterprise Architect (EA)
• Together ControlCentre (acquired by Borland in 2003) has a free community edition. Andy Carmichael and Dan Haywood has a book demonstrating how to get the most out of tools such as Together1. good write-up on it

• Compuware's OptimalTrace product creates two-way concurrent conversion between Microsoft Word requirements documents and UML use cases and activity diagrams created in IBM/Rational Rose and Borland's Together.

About the Unified Modeling Language

These Diagrams depict the relationships among model elements and artifacts.

Artifacts are deliverables such as executable files or script files (created with effort).

Model elements include classes, interfaces, components, use cases, and other objects.

An object ("thing") is a concrete instance of an abstract class. Thus, object instances <<originates from>> a Class. Note the use of guillemet (a French word pronounced "Ghee-yu-ay") characters to designate a stereotype.

Stereotypes are qualifiers that narrow the meaning of elements and relationships.

Each instance of an object is an entity with a unique identity, behavior, and a state.

A class is a realization of an <<interface>>. Thus, an interface is a specification of a class.

A class is a classifier of objects. Thus, a classifier is a description of an instance.

Relationships among objects include:

Associations and compositions are considered "adornments" in UML.
• generalizations of concrete examples into an abstract concept, represented by an arrow with a white arrowhead.
• associations represented by an arrow with a black arrowhead.
• compositions
• derivations

  Dependices among Packages

  Collaboration diagrams illustrate UML model elements grouped into packages that contain or reference model elements.

  Two colons separate package names qualifying an element name

  Package::Element

  A dependency between autonomous domains is called a bridge, represented by dashed lines pointing to the domain at a lower level of abstraction (not a flow of control). One domain makes assumptions which are requirements placed on lower domain. With Executable UML, domains are represented as packages with dependencies.

States

A solid round dot represents the initial (starting) state.
A circle around a solid round represents a final (finishing) state.

Events

Visio 2003 allows these events on transitions:
• Call events occur when an element receives a call for an operation.
• Signal events occur when an element receives an explicit signal from another element.
• Change events occur when a designated condition (usually described as a Boolean operation) becomes true.
• Time events occur after a designated period of time or at a specific time or date (such as when someone become designated as Inactive after a period of time).

Actions

Visio 2003 allows these actions to be associated with transitions:
• A create action creates an instance of some classifier (data element).
• A call action is a synchronous or asynchronous action that invokes an operation on an instance.
• A local Invocation is an action that invokes a local operation, that is, an operation on "self." This type of action does not generate a call event.
• A return action results in a value being returned to the caller.
• A send action results in an asynchronous signal being sent. You can specify the signal receivers (via objectSetExpression) or leave them unspecified, in which case they are defined by some external mechanism.
• An Uninterpreted action represents any action that is not explicitly defined in the UML.
• A Terminate action results in the self-destruction of an object.
• A destroy action results in the destruction of an object specified in the action.

Classes


Classes are represented by a box with three parts: class identifier, attributes, and events.

A classifier Role (or simply Role) defines an abstraction of an instance.
A Classifier Role specifies a single usage of its class.
Object instances <<conforms to>> a ClassifierRole.
ClassifierRoles are a <<view of>> a class.

The diagrams are visual representations of Object Constraint Language (OCL) text.
Classifier names are preceded with a colon.
ClassifierRoles names are preceded with a slash.

An Association Role specifies the required properties of a Link used in a Collaboration.

A collaboration has external initiators, active handlers, and passive managed entities.

As with any language, UML is defined by syntax and semantics. Syntax are rules by which language elements (e.g., words) are assembled into expressions (e.g., phrases and clauses). Semantics are rules by which syntactic expressions are assigned meanings.

UML.org unifies the syntax, graphic notations, and semantics from Booch, OMT, Objectory, and other object modeling languages.

The UML also includes:

• example profiles of Business Modeling and Software Development processes.
• CORBAfacility Interface Definition
• XML Metadata Interchange DTD

• Infrastructure
• Superstructure
• OCL (Object Constraint Language)

Zoomable, interrelated Championzone sample UML charts from Microsoft's Visio gallery. You can zoom in and out on these interrelated charts by clicking the “Fit in Window” and scrolling a wheel mouse.

Kendall Scott's UML Dictionary

The UML Forum by Cris Kobryn at Telogic

Ian Moraes' Introduction to the UML

$52 Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process (2nd ed.) by C. Larman (Upper Saddle River, NJ: Prentice Hall PTR (Pearson): 2002)

$45 Design Patterns Explained: A New Perspective on Object-Oriented Design by Alan Shalloway, James R. Trott (Reading, MA: Addison- Wesley (Pearson): 2001)

$45 UML and the Unified Process: Practical Object-Oriented Analysis and Design (Addison-Wesley, Dec, 2001) by Jim Arlow, Ila Neustadt

$25 Instant UML (Wrox Press Inc; 1st edition Dec 1997) by Pierre-Alain Muller

$35 UML Distilled : A Brief Guide to the Standard Object Modeling Language (2nd Edition) (Addison-Wesley: August 25, 1999) by Martin Fowler & Kendall Scott

$35 UML Toolkit (John Wiley & Sons; Book and CD-ROM edition October 14, 1997) by Hans-Erik Eriksson, Magnus Penker

The Unified Modeling Language User Guide by Booch, Rumbaugh, and Jacobson

UML Notation Guide, Version 1.1

$70 Object Models: Strategies, Patterns, and Applications (Prentice Hall: December 1996) by Peter Coad, David North, and Mark Mayfield

$32 Java Design: Building Better Apps and Applets (2nd Edition) (Prentice Hall: January 1999) by Peter Coad and Mark Mayfield

Mechanisms

UML is extended by Stereotypes, tagged values, and constraints:



• Stereotypes specialize metamodel classes.

  The most common artifacts are:

  <<file>>	A physical file in the context of the system developed.
  <<script>>	A script file that can be interpreted by a computer system.
  <<executable>>	A program file that can be executed on a computer system.
  <<library>>	A static or dynamic library file.
  <<source>>	A source file that can be compiled into an executable file.
  <<document>>	A generic file that is not a source file or executable.

• tagged values extend the attributes of the metamodel classes (labels that can be attached to UML elements).

• constraints extend the metamodel semantics (logical conditions that can be applied to elements or relationships on a diagram)

notes, dependencies, and type/instance and type/class dichotomies

UML Stereotypes

The default stereotypes within Microsoft Visio 2003 provides are listed below. Its UML Stereotypes dialog does not allow sorting, so here is the list sorted by Base Class:

Stereotype	Base Class
	Action
	ActionSequence
	ActionState
	ActivityModel
	ActivityState
	Actor
	Adornment
	Argument
	Association
	AssociationEnd
association	AssociationEndRole
global	AssociationEndRole
local	AssociationEndRole
self	AssociationEndRole
	AssociationRole
	Attribute
	AttributeLink
create	BehaviorFeature
destroy	BehaviorFeature
	Binding
	CallAction
	CallEvent
	ChangeEvent
delegate	Class
implemtation class	Class
struct	Class
type	Class
union	Class
utility	Class
powertype	Classifier
process	Classifier
stereotype	Classifier
thread	Classifier
	ClassifierInState
	ClassifierRole
	Collaboration
requirement	Comment
document	Component
executable	Component
file	Component
library	Component
table	Component
	CompositeState
invariant	Constraint
postcondition	Constraint
powertype	Constraint
	CreateAction
enumeration	DataType
	DataValue
becomes	Dependency
call	Dependency
copy	Dependency
derived	Dependency
friend	Dependency
import	Dependency
instance	Dependency
powertype	Dependency
send	Dependency
	DestroyAction
	Element
create	Event
destroy	Event
extends	Generalization
inherits	Generalization
private	Generalization
protected	Generalization
subclass	Generalization
subtype	Generalization
uses	Generalization
	Guard
	Instance
	Interface
	Link
association	LinkEnd
global	LinkEnd
local	LinkEnd
self	LinkEnd
	LinkObject
	LinkInvocation
	Message
	MessageInstance
	Method
useCaseModel	Model
	ModelElement
	Namespace
	Node
	Object
	ObjectFlowState
	Operation
facade	Package
framework	Package
stub	Package
system	Package
topLevelPackage	Package
	Parameter
	Partition
	Primitive
	PseudoState
	Reception
deletion	Refinement
	Request
	ReturnAction
	Request
	ReturnAction
	SendAction
	Signal
	SignalEvent
	SimpleState
	State
	StateMachine
	StateVertex
	Stereotype
	StructuralFeature
	SubMachineState
	TaggedValue
	TerminateAction
	TimeEvent
	Trace
	Transition
	UniterpretedAction
	Usage
	UseCase
	UseCaseInstance
	ViewElement

Conceptual Design

Take the analogy of designing a physical building. It starts with the architect's sketches, providing a high-level view of the building for the client. They might contain a site plan, elevations, floor plans, cut away drawings, and other pictures or drawings. This view corresponds to the Conceptual Design for the project.

It all starts with an understanding of what the users really need to do and creating an easily communicated set of models that captures this understanding.

Logical Design

The architect's sketches are followed by architectural plans, showing the building as seen by the architect and contributing staff. This second phase in the architectural process combines the client's view with the architect's view and knowledge, providing detailed drawings in each of many categories for communication with the different contractors and other parties involved in the project.

This analogy corresponds to the MSF view of a Logical Design where we lay out the structure and communication among the individual elements of a system being developed.

Physical Design

Finally, contractors' plans are drawn up for the builder, adding detail to the architect's plans, making adjustments for the physical environment of the site and the technology and materials available to build the building. This view directs all the construction activities and may add greater detail such as shop plans for individual subcontractors.

This analogy corresponds to the Physical Design, where the real world constraints of technology are applied to the logical model including implementation and performance considerations. This is the point at which real resources, costs, and schedule can be estimated.

Final Design

The Final Design is a another name for the completed product released to the users.

The Application Model

Designed to improve development, maintenance, and support, this model provides a three-tiered, services-based approach to designing and developing software applications. The services utilized in this model are scalable, and can be used on a single desktop or on multiple servers worldwide. These models promote principles such as risk-driven scheduling, a fixed-release-date mind-set, versioned releases, visible milestones, and small, peer-based teams. MSF exposes critical risks, important planning assumptions, and key interdependencies required for successfully planning, building, deploying, and managing your company's mission-critical technology infrastructure or business solution.

Rational Process Workbench (RPW) creates “process” web sites from UML process models stored in Process Content Libraries manipulated by Rational Rose (also used to create Activity Diagrams from the models). RPW references the Rational Unified Process.

The Enterprise Architecture Model

Designed to shorten the enterprise architecture planning cycle, this model provides guidelines for building enterprise architecture through versioned releases.