unified modeling language user guide section 1—getting started
TRANSCRIPT
Unified Modeling LanguageUser Guide
Section 1—Getting Started
Paper
• Konsep Object dan Class
• Intro UML
• Enrollkey: pbotik-h
• Minngu depan – Review intro UML– Object oriented modeling
Sung Kim CS6359 Slide 2
Sung Kim CS6359 Slide 3
Overview• Why we model
– Importance– Principles– Object-oriented modeling
• Introducing UML– UML Overview– Conceptual model of UML– Architecture– Software development life-cycle
Sung Kim CS6359 Slide 4
What is a model?
• A model is a simplification of reality.
• A set of blueprints of a system.
• Semantically closed abstraction of the system.
• A model is an abstraction of something for the purpose of understanding it before building it.
Sung Kim CS6359 Slide 5
Why We Model
• Communicate a desired structure and behavior of a software system.
• Visualize and control a system’s architecture.• Assist in understanding a system under
development.• Expose opportunities for simplification and
reuse.• Manage risk.• Document decisions.
Sung Kim CS6359 Slide 6
Importance of Modeling
• Proven and accepted engineering technique; divide-and-conquer.
• We build models of complex systems because we cannot comprehend such a system in its entirety.
• Desire to build the right software right.
Sung Kim CS6359 Slide 7
Principles of Modeling
1. The choice of what models to create has a profound influence on how a problem is attacked and how a solution is shaped.
2. Every model may be expressed at different levels of precision.
3. The best models are connected to reality.4. No single model is sufficient. Every
nontrivial system is best approached through a small set of nearly independent models.
Sung Kim CS6359 Slide 8
Modeling Comparison
• Functional– Algorithmic perspective– Building blocks of functions or procedures– Yields brittle systems
• Object-Oriented– Building blocks of classes or objects.– Drawn from the vocabulary of the problem
space.
Sung Kim CS6359 Slide 9
Object vs. Class
• Object– Thing drawn from the problem domain or
solution space.– Instantiation of class.– Has identity, state, and behavior.
• Class– Description of a set of common objects.
Sung Kim CS6359 Slide 10
Introducing UML
• Used to visualize, specify, construct, and document
• …appropriate for modeling systems ranging from enterprise information systems to distributed Web-based applications and even to hard real time embedded systems.
• Process independent.
Sung Kim CS6359 Slide 11
UML is a Language
• Vocabulary and rules for communication.
• Focus on conceptual and physical representations of a system.
• A language for software blueprints.
• Not a process.
Sung Kim CS6359 Slide 12
A UML Compatible Process
• Use case driven
• Architecture-centric
• Iterative
• Incremental
Sung Kim CS6359 Slide 13
UML is for Visualizing
• An explicit model facilitates communication.
• UML is a graphical language.
• UML symbols are based on well-defined semantics.
Sung Kim CS6359 Slide 14
UML is for Specifying
• Specifying means building models that are:– Precise– Unambiguous– Complete
• UML addresses the specification of all important analysis, design, and implementation decisions.
Sung Kim CS6359 Slide 15
UML is for Constructing
• Models are related to OO programming languages.
• Round-trip engineering– Forward engineering—direct mapping of a
UML model into code.– Reverse engineering—reconstruction of a
UML model from an implementation.– Requires tool and human intervention to
avoid information loss.
Sung Kim CS6359 Slide 16
UML is for Documenting
• Architecture
• Requirements
• Tests
• Activities– Project planning– Release management
Sung Kim CS6359 Slide 17
Conceptual Model of UML
• Three basic building blocks of UML– Things—abstractions that are first class
citizens in a model.– Relationships—tie things together.– Diagrams—group interesting collections of
things.
Sung Kim CS6359 Slide 18
Things
• Structural—nouns of UML models.
• Behavioral—dynamic parts of UML models.
• Grouping—organizational parts of UML models.
• Annotational—explanatory parts of UML models.
Sung Kim CS6359 Slide 19
• Nouns of UML models.
• Conceptual or physical elements.
• Seven Kinds
Structural Things
– Classes– Interfaces– Collaborations– Use cases
– Active classes– Components– Nodes
Sung Kim CS6359 Slide 20
Classes
• Description of a set of objects that share the same attributes, operations, relationships, and semantics.
• Implement one or more interfaces.
Windoworiginsize
open()close()
nameattributes
operations
Sung Kim CS6359 Slide 21
Interfaces
• Collection of operations that specify a service of a class or component.
• Describes the externally visible behavior.
<<interface>>
IWindow
open()close()
name
operations
IWindow
Sung Kim CS6359 Slide 22
Collaborations
• Defines an interaction.
• Society of roles and other elements.
• Provide cooperative behavior.
• Structural and behavioral dimensions.
Chain ofresponsibility
Sung Kim CS6359 Slide 23
Use Cases
• Description of a sequence of actions that produce an observable result for a specific actor.
• Provides a structure for behavioral things.
• Realized by a collaboration.
Place order
Sung Kim CS6359 Slide 24
Active Classes
• Special class whose objects own one or more processes or threads.
• Can initiate control activity.
Event Manager
suspend()flush()
nameattributes
operations
heavyborder
Sung Kim CS6359 Slide 25
Components
• Physical and replaceable part.
• Conforms to a set of interfaces.
• Physical packaging of logical components.
Sung Kim CS6359 Slide 26
Node
• Physical element that exists at run time.
• Represents a computational resource.
• Generally has memory and processing power.
Node
Sung Kim CS6359 Slide 27
Variations on Structural Things
• Actors
• Signals
• Utilities
• Processes and Threads
• Applications
• Documents
• etc.
Sung Kim CS6359 Slide 28
• Verbs of UML models.• Dynamic parts of UML models.• Usually connected to structural elements.• Two kinds
– Interactions—behavior that comprises a set of messages exchanged among a set of objects.
– State Machines—specifies the sequences of states an object or interaction goes through in response to events.
Behavioral Things
display
Idle
Sung Kim CS6359 Slide 29
Grouping Things• Organizational parts of UML.
• Purely conceptual; only exists at development time.
• One kind– Package—general-purpose mechanism for
organizing elements.
Business rules
Sung Kim CS6359 Slide 30
Annotational Things• Explanatory parts of UML.
• Comments regarding other UML elements.
• Information best expressed as text.
• One kind– Note—symbol for rendering constraints or
comments attached to an element.
Return copy of self
Sung Kim CS6359 Slide 31
Relationships in UML
• Dependency
• Association
• Generalization
• Realization
Sung Kim CS6359 Slide 32
Relationships• Dependency—semantic relationship
between two things in which a change to one thing may affect the semantics of the other.
• Association—structural relationship that describes a set of links; a link being a connection among objects.
0..1 *
employer employee
Sung Kim CS6359 Slide 33
Relationships (cont’d)
• Generalization—specialization relationship in which child objects are substitutable for the parent.
• Realization—semantic relationship between classifiers, wherein one classifier specifies a contract that the other guarantees to carry out.
Sung Kim CS6359 Slide 34
Diagrams
• Graphical representation of a set of elements.• Rendered as a connected graph
– Vertices are things.– Arcs are behaviors.
• Projection into a system form a specific perspective.
• Five most common views built from nine diagram types.
Sung Kim CS6359 Slide 35
Common Diagram Types
• Class• Object• Use case• Sequence• Collaboration
• Statechart• Activity• Component• Deployment
Sung Kim CS6359 Slide 36
Rules of UML• Well formed models—semantically self-
consistent and in harmony with all its related models.
• Semantic rules for:– Names—what you can call things.– Scope—context that gives meaning to a name.– Visibility—how names can be seen and used.– Integrity—how things properly and consistently
relate to one another.– Execution—what it means to run or simulate a
dynamic model.
Sung Kim CS6359 Slide 37
Models in Development
• Elided—certain elements are hidden for simplicity.
• Incomplete—certain elements may be missing.
• Inconsistent—no guarantee of integrity.
UML encourages the most important aspects such that models become well-formed over time.
Sung Kim CS6359 Slide 38
Common Mechanisms in UML
• Specifications—textual statement of the syntax and semantics of a building block.
• Adornments—other details attached to UML elements.
• Common divisions—dichotomy representation of elements (i.e. Class vs. Object)
Sung Kim CS6359 Slide 39
Common Mechanisms (cont’d)
• Extensibility mechanisms– Stereotypes—extends vocabulary.– Tagged values—extends properties of
UML building blocks.– Constraints—extend the semantics of UML
building blocks.
Sung Kim CS6359 Slide 40
Architecture
• Set of significant decisions regarding:– Organization of a software system.– Selection of structural elements and
interfaces from which a system is composed.
– Behavior or collaboration of elements.– Composition of structural and behavioral
elements.– Architectural style guiding the system.
Sung Kim CS6359 Slide 41
Architecture Views
Deployment ViewProcess View
Design ViewImplementation
View
Use Case View
vocabularyfunctionality
performancescalability
throughput
behavior
system assemblyconfiguration mgmt.
system topologydistributiondeliveryinstallation
Sung Kim CS6359 Slide 42
Use Case View
• Encompasses the behavior as seen by users, analysts and testers.
• Specifies forces that shape the architecture.• Static aspects captured in use case
diagrams.• Dynamic aspects captured in interaction
diagrams, statechart diagrams, and activity diagrams.
Sung Kim CS6359 Slide 43
Design View
• Encompasses classes, interfaces, and collaborations that define the vocabulary of a system.
• Supports functional requirements of the system.
• Static aspects captured in class diagrams and object diagrams.
• Dynamic aspects captured in interaction diagrams, statechart diagrams, and activity diagrams.
Sung Kim CS6359 Slide 44
Process View
• Encompasses the threads and processes defining concurrency and synchronization mechanisms.
• Addresses performance, scalability, and throughput.
• Static and dynamic aspects captured as in design view; emphasis placed on active classes.
Sung Kim CS6359 Slide 45
Implementation View
• Encompasses components and files used to assemble and release a physical system.
• Addresses configuration management.• Static aspects captured in component
diagrams.• Dynamic aspects captured in interaction
diagrams, statechart diagrams, and activity diagrams.
Sung Kim CS6359 Slide 46
Deployment View
• Encompasses the nodes that form the system hardware topology.
• Addresses distribution, delivery, and installation.
• Static aspects captured in deployment diagrams.
• Dynamic aspects captured in interaction diagrams, statechart diagrams, and activity diagrams.
Sung Kim CS6359 Slide 47
Software Process
• Use case driven—use cases are primary artifact for defining behavior of the system.
• Architecture-centric—the system’s architecture is primary artifact for conceptualizing, constructing, managing, and evolving the system.
• Iterative and incremental—managing streams of executable releases with increasing parts of the architecture included.
Sung Kim CS6359 Slide 48
Phases
• Span of time between two major milestones.• Primary phases
– Inception—seed idea is brought up to point of being a viable project.
– Elaboration—product vision and architecture are defined.
– Construction—brought from architectural baseline to point of deployment into user community.
– Transition—turned over to the user community.
Sung Kim CS6359 Slide 49
Summary• Modeling.
• UML introduction.
• Building blocks of UML.
• Rules of UML.
• Common UML mechanisms.
• Architectural views.
• Software lifecycle.