 |
UML
state machine diagrams,
formerly called state chart diagrams in UML 1, depict the dynamic behavior of an
entity based on its response to events, showing how the entity reacts to various
events depending on the current state that it is in. Create a
UML state machine
diagram to explore the nature of a:
-
Explore
the complex behavior of a class, actor, subsystem, or component.
-
Modeling
real-time systems.
|
|
There are guidelines for:
- General issues
- State
- Substates
- Transitions
and Actions
- Guards
Figure 1. A UML state machine
Diagram for a seminar during enrollment.
- Create A state machine When Behavior Differs Based on State. A Seminar
object is fairly complex, reacting to events such a enrolling a student
differently depending on its current state, as you see depicted in
Figure 1 .
- Place The Initial State In The Top-Left Corner
- Place The Final State In The Bottom-Right Corner
A state is a stage in the behaviour pattern of an entity.
States are represented by the values of the attributes of an entity.
For example, in Figure 1
a seminar is in the Open
For Enrollment state when it has been flagged as open and there are
seats available to be filled.
- State Names Should be Simple but Descriptive
- Question “Black Hole” States. A black hole state is one that has transitions into it but
none out.
- Question “Miracle” States. A miracle state is one that has transitions out of it but
none into it.
Figure 2. The complete lifecycle
of a Seminar.
Figure 3. A top-level state
machine
for Seminar.
- Model Substates For Targeted Complexity. Figure 2 models the entire lifecycle of a
Seminar,
depicting
Figure 1 as a collection of substates of a new
Enrollment
composite state, also called a superstate.
- Aggregate Common Substate Transitions
- Create a Hierarchy of State Machines for Very Complex Entities.
Figure 3 represents the top-level view andFigure 1 depicts a more detailed view.
- Top-Level State Machines Always Have Initial and Final States
A transition is a progression from one state to another and
will be triggered by an event that is either internal or external to the entity
being modeled. For a class,
transitions are typically the result of the invocation of an operation that
causes an important change in state, although it is important to understand that
not all method invocations will result in transitions.
An action is something, in the case of a class it is an operation, that
is invoked by/on the entity being modeled.
- Name Software Actions Using Implementation Language Naming Conventions
- Name Actor Actions Using Prose
- Indicate Entry Actions Only When Applicable For All Entry Transitions
- Indicate Exit Actions Only When Applicable For All Exit Transitions
- Model Recursive Transitions Only When You Want to Exit and Re-Enter the
State
- Name Transition Events in Past Tense
- Place Transition Labels Near The Source State
- Place Transitions Labels Based on Transition Direction. To make it easier to identify which label goes with a
transition, place transition labels according to the following heuristics:
- Above
transition lines going left-to-right
- Below
transition lines going right-to-left
- Right
of transition lines going down
- Left
of transition lines going up
A guard is a condition that must be true in order to
traverse a transition.
- Guards Should Not Overlap. The guards on similar transitions leaving a state must be
consistent with one another. For
example guards such as x <0, x = 0, and x > 0 are consistent whereas guard such
as x <= 0 and x >= 0 are not consistent because they overlap.
- Introduce Junctions to Visually Localize Guards.
In Figure 2 you see that there are two transitions from
Being
Taught as the result of the
student
dropped event, whereas there is only one in
Figure 3 – the transitions are combined into a single one that leads to a junction
point (the filled in circle).
- Guards Need Not Form a Complete Set
- Name Guards Consistently
|
|
|
The Elements of UML 2.0 Style describes a collection
of standards, conventions, and
guidelines
for creating effective
UML diagrams. They are based on sound, proven
software engineering principles that lead to diagrams
that are easier to understand and work with. These
conventions exist as a collection of simple, concise
guidelines that if applied consistently, represent an
important first step in increasing your productivity as
a modeler. This book is oriented towards
intermediate to advanced UML modelers, although there
are numerous examples throughout the book it would not
be a good way to learn the UML (instead, consider
The Object Primer). The book is a brief 188
pages long and is conveniently pocket-sized so it's easy
to carry around. |
 |
|
The Object Primer 3rd Edition: Agile Model Driven
Development with UML 2 is an
important reference book for agile modelers,
describing how to develop 35
types of agile
models including all 13
UML 2 diagrams.
Furthermore, this book describes the techniques
of the
Full Lifecycle Object Oriented Testing
(FLOOT) methodology to give you the fundamental
testing skills which you require to succeed at
agile software development. The book also
shows how to move from your agile models to
source code (Java examples are provided) as well
as how to succeed at implementation techniques
such as
refactoring and
test-driven development
(TDD). The Object Primer also includes a
chapter overviewing the critical database
development techniques (database refactoring,
object/relational mapping,
legacy analysis, and
database access coding) from my award-winning
Agile Database Techniques
book. |
 |
|
Agile Modeling: Effective Practices for Extreme
Programming and the Unified Process is the seminal
book describing how agile software developers approach
modeling and
documentation. It describes principles and
practices which you can tailor into your existing
software process, such as
XP, the
Rational Unified Process (RUP), or the
Agile Unified Process (AUP), to streamline your
modeling and documentation efforts. Modeling and
documentation are important aspects of any software
project, including agile projects, and this book
describes in detail how to
elicit requirements,
architect, and then
design your system in an agile manner. |
|
|
I actively work with clients around the world to
improve their information technology (IT) practices as
both a mentor/coach and trainer. A full description of
what I do, and how to contact me, can be
found here.
|
