Transcript Chapter: Overview - Arizona State University

UML Overview
1
Overview of Modeling
A model is an abstraction of the real world
Modeling is a heavily practiced, proven engineering
technique
 architectural modeling of buildings
 mathematical modeling of systems
Models include important details and omit minor aspects
Why do people model?
2
Why Do We Model?
To help us understand what a system should do, and how it
should do it
To communicate our decisions of what and how
To detect and prevent misunderstandings and
miscommunications
To generate (portions) of the system’s artifacts
To help understand existing systems (reverse engineering)
3
UML (Unified Modeling Language)
The Unified Modeling Language (UML) is a language for specifying,
visualizing, constructing, and documenting the artifacts ofsoftware
systems, as well as business modeling and other non-software systems”
Standard language for modeling software-intensive systems
Can be used to generate code
 UML 2.0 additions focused on formal semantics for transformations
Notation independent of development process
 UML is not a methodology or process
Numerous tools exist which implement UML
 http://www.objectsbydesign.com/tools/umltools_byCompany.html
 Several tools reverse engineer code into UML
4
Why UML?
UML has became the de facto language for describing the
artifacts of software-intensive systems
 Several extensions exist for systems engineering (SysML) and
others (software engineering, business process modeling)
 Can serve as a standard for the definitions of the concepts of
object-orientation (OO)
• But in practice there is no such standard
 Includes recommendations about how to describe systems
UML is a syntactically and semantically complete
language!
 The visual elements are expressed and related in specific ways
(syntax)
• You can have the equivalent of a compiler error - i.e. you can’t just
connect things with a line anywhere you like!
 Even if you can connect them, the type of line matters (semantics)
– if it is dashed or not, uses a hollow or thin arrow, etc.
5
UML Diagrams Support Multiple System Views
Use case view (Use Cases, Activity)
 behavior of the system as seen by the end users
Design view (Class, Object)
 both static and dynamic view of classes and objects; their
relationships and their interaction
Process view (Timing, Interaction, Statechart)
 illustrates concurrency and synchronization issues
Implementation view (Component, Package)
 configuration management issues about assembly and release
of code files
Deployment view (Deployment)
 distribution of parts among hardware elements
6
Categories of UML Diagrams
UML 2.0 has (at least) 18 different diagrams
A few different ways to think about them (in addition to
previous slide):
 Descriptor vs. Instance
• Descriptor diagrams describe the system’s general case, instance
show system snapshot
– Descriptor diagrams - class, use case, deployment, component
– Instance diagrams– object, sequence, static structure, deployment,
component
 Behavior vs. Structure
• Need both behavior and structure to communicate
– Behavior – statechart, interaction, timing, use case
– Structure – class, component, deployment, block (SysML)
– Flow might be another form here – activity, sequence, timing
7