Notes on xUML text, chapters 3, 4, 7, 16, 17, 18
RJLRef: $PH/04s522/XUMLtextNotes040511.doc
We haven't been making much use of XUML so far.
I hope that delving into the guts of COOL-LCP and COOL-GEN
has convinced you that Model-Driven Development (MDD) has
some value. But I don't know if that's possible without
having tried to develop multiple system designs from
scratch (without framework tools) and then with such tools
that (I hope) foster re-use by auto-generation of
application-specific code from general-purpose tools for
defining design models.
I do know that a lot of XUML that is pertinent to MDD we
did not have time to cover this semester. (I tend to grow
into a new textbook gradually.) Before this term is over,
I do want to point to some specific chapters (chapters are
very short in XUML) that are relevant to the multi-user
collaboration problems in DBDE and remote-client-servicing
in bde2java04s and DSG (Distributed Set Game).
Here are my notes, in Chapter order (Some topics are crossreferenced):
Chapter 3 Domains and Bridges (p. 29-39).
Chapter 3.3: (p. 35-38) defines Bridges as a way to model
inter-Domain communication without changing either Domain.
Direct acccess is deprecated so encapsulation (info-hiding)
is not violated; then dependent client Domains do not
constrain server Domains which should remain independent
and free to change their internals(Design for Change :-)
(E.g., the JPsim overview data model handout with four
domains: BDE, SM, plant layout, and active objects. (OP and
TImer might be placed in a separate Service Domain.)
Chapter 4: Use Cases (p. 44-56).
Four levels of use cases. They are named to remind us of
their granularity or degree of detail: sky, kite, sea (or
ground) and mud.
4.3 Activity Diagrams are given short shrift, although
their basis (Petri Nets), is a significant technical
contribution to synchronization among State Machines.
Is this because XUML does not favor Activity Diagrams?]
One example, Fig. 4.8 p. 52, reveals the sequencing
constraints among the four trivial Use Cases in Fig. 4.7.
It shows one pair of two-way fork and join points
for a pair of concurrent sub-processes, Both of these must
complete (join) before the order can be shipped. The state
of these synchronization bars depends on multiple State
machines which together define a multi-component currentstate vector. The system state is a vector, not a scalar,
and Petri Nets must be used to derive properties of the
whole collection of (asynchronous) machines.
4.4 Formalizing Use Cases (p. 53-54) mentions pre- and postconditions. These formalize requirements on actions and
methods at all levels, not just Use Cases. Note 4.4.3: "One
use case's post-condition is often another's precondition."
(e.g. Fig. 4.10 p. 55).
4.5 Scenarios and Testing (p; 54-56) defines a scenario as
an instance of a use case, or the actual execution of a use
case with real data values. I would like to see a
definition of 'test coverage' at the State Model level.
This could motivate tools to measure "What fraction of
state-transitions (and event-generating actions) are
traversed among all collaborating state machines, during
actual execution of an entire set of [regression] test
cases?" I believe the StateMate tool provides such metrics.
Chapter 7 Class Actions (p. 109-123)
An action is defined as "an individual operation that
performs a single task on an element of a model". It gives
a syntax and examples for 'object and attribute' actions
(Fig. 7.1 and 7.2), 'selection expressions' (Fig. 7.3 and
7.4), and iteration (for each) in Fig. 7.5. Selection can
return one object (select any) or a set of objects (select
many).
7.3 Link Actions (p. 114-115) in Figs 7.7 and 7.8 show how
to create and delete associations (fkey pairings, as in
Join Points below), and select one or a set of objects
across association links.
7.4 Link Object Actions extends (or regresses?)
relationship actions to associative entities. (These
objects contain K>=2 fkeys as in genv12 schemas). Such
pairings are both links and objects by construction. Their
create/delete actions hava k>= 2 fkeyu parameters and are
called 'relate' and unrelate'. Selections can reference
associative objects that 'relate' a pair of fkey values.
7.5 Generalization Hierarchies (p. 117-119) defines
'Reclassification' as "the act of moving an object from one
leaf subclass in a gen-spec hierarchy to another".
E.g., Shlaer-Mellor tools reclassify an Active Instance to
a new subclass whenever it changes state. Then a virtual
State Action method in the super-class can be called
polymorphically with an argument whose type is a particular
State subclass. The result is execution of the concrete
Action Routine that overrides the superclass for this
state. [An appropriately specialized semantically
meaningful function name is not available; a state 'name'
and comments on each state node of the STD must suffice to
explain each state's behavior.]
[Some OMG/ADTF group correspondence on this is collected at
www.cs.uml.edu/~lechner/03f522/uml2mdaDynamicSubtypes.]
7.5 also refers to Fig. 6.18 p. 102 as an example of
Compound Generalization (more than one dimension of
specialization). An example of this is the Big/Small and
White/Black dog class hierarchy in my slide show (path
TBD).
7.6 Other Action Languages (p. 119-123) discusses SMALL
(Shlaer-Mellor Action Language of the BridgePoint tool).
This is a data-flow-oriented predecessor to UML1.5 Action
Senamtics, with unix-like pipe notation to sequence subprocesses (within a single, or across multiple, State
Actions?).
Footnote 2, p. 119 is this interesting insight by Peter
Fontana of Pathfinder Solutions: "all chains of operations
end in a write, or a signal generation". [In COOL, one
obvious example of this is a change-state operation (that
should be executed only at the end of an action): it either
updates the state variable directly, as in BDE, or it
generates an event that causes some state transition, as in
LCP.]
[A similar insight was noted by MIT Prof. Marvin Minsky in
his old book on 'neural' network state models: State
machines often have the same state behavior for every
incoming transition. Perhaps this is one reason why the
Moore model gets along pretty well without the Mealy
model's flexibility. (Minsky's notation was one inspiration
for my TRAIL notation for state nodes.)]
7.6 also summarizes a functional language TALL, with
nestable actions whose return values are usable in other
actions, by Balcer, Bock and Epperson (Table 7.18 p. 122).
Chapter 8 Constraints (p. 125-146)
An introduction to Object Constraint Language, adopted in
UML 1.4.
8.4 Association Loops identifies unconstrained (Fig. 8.15),
redundant (derivable) and constrained types of cyclic paths
in a class model or EERD. 8.4.3 Equal-set Constraint (p.
141-143) and 8.4.4 Subset Constraint (p. 143-145) are two
examples which give OCL expressions that specify
constraints that UML class models can't show graphically.
Chapter 16 Model Management (p. 269-274)
This 6-page chapter is about dividing large Domains into
subsystems.
16.2 says draw the class diagram of each subsystem
separately. Include each related but external class as a
box with a class name and <<imported>> notation
(stereotype) but without a property list inside. [His
figures 16.2 and 16.5 do not follow this advice - internal
and external class boxes both have attributes on 16.2 and
both have only class names on 16.5.]
Fig. 16.3 shows a UML 'Package Diagram' with Domain nodes
linked by lines labeled with the inter-Domain association
identifiers (Rx, Ry). This is how Domain Charts in ShlaerMellor: Object Life Cycles would be redrawn in UML. They
are a necessary abstraction of Object Communication (or
Collaboration) diagrams, which show all event type links
among class nodes. When too many classes communicate, a
class-level network diagram is too dense to read.
Chapter 17 Joining Multiple Domains (pp 275-289)
This chapter expands
on the Bridge defined in 3.3.
17.2 defines Anonymous Explicit Bridges (17.2.3 asynchronous
signal events and 17.2.4 synchronous Bridge Operations).
These are distinct types of inter-domain method calls, e.g.
to access an available property or request a task of some
object in another Domain.
BDE uses direct pr_get_* and pr_set_* calls to access
objects (table rows) in other domains. Similarly, LCP uses
XXGetField and XXSetField operations on rows of table type
XX, regardless of its Domain. Do these violate
encapsulation? Yes (partly), if it can only access
attribute names inside other classes; navigation can still
be hidden, e.g. pr_find(tbl,pkey,value). No, if 'Field' is
replaceable by a derived property that could be a
dynamically constructed object, or even a subschema or
Query/View/Transformation (QVT) collection of objects. This
is far above one schema-declared table attribute, for which
genv12 auto-generates access code.
17.3.3 Implicit Bridges with Join-Points p. 286 discusses
structural Join Points. These also occur as JP_HN and HN_ST
associative entities in JPsim's 4-Domain data model (prior
handout). JP_HN joins the BDE GUI domain to JPsim's plant
layout domain; HN_ST joins BDE to LCP's Stat Model domain.
These explicit info-structure dependencies between object
classes and attributes suggest that inter-domain
dependencies may occur between methods via messages
generated during state actions. Exposing these is the main
reason for object interaction diagrams in UML and object
communication diagrams (OCDs) in OLC.
Class-to-instance joins need not be one to one. Fig. 17.11
p. 288) is an order fulfillment example, where one GUI
screen (one instance of the screen class) displays an order
header and multiple line items (many instances from another
Domain).
In BDE, the graph-object is a list of references to all HN,
HL and GC items of one diagram. It defines how to draw a
single canvas drawing window (object instance). Bde2vcpp
(VC++ version of bde) using MSoft's Document Object Model
could open multiple windows in one bde editing process.
Each window displayed a distinct HG-row.
Appendix B: Case Study (p. 313-360)
Appendix B gives all details for the online bookstore
application used throughout the text (and downloadable from
www.executableumlbook.com). The problem requires no
specialized domain expertise, but the detailed text shrink
to practically unreadable size on the diagrams. Its content
is directly translatable into code by the XUML toolset.