Less is more in UML
models.
My
guest blog on May 20th mentioned that
Ivar Jacobson's and Microsoft architect Steve
Cook's article about the “road ahead”, toward a slim UML3 kernel with extension
mechanisms (2010, on Dr Dobbs), makes even more
sense in 2015 than back in 2010.
1.
Standard subtleties
The
new, slimmed UML 2.5 spec (March 2015, by the OMG), table C.1 (included
keywords) lists only «use» and none of «create» or «instantiate»; the text also
states it's an open list. That makes it one of the steps down the Jacobson & Cook road to a much-welcome smaller
kernel with a very simple extension mechanism.
2.
Practical subtleties
The distinction
between a «create» and an «instantiate» Dependency is tiny.
Both
are shades of usage, so that «use» would suffice in most cases: the source uses
the target (for some reason — be instantiation or other).
3.
Interpretation subtleties
I’ve
often wondered whether the slightly higher expressive power was worth the hike
in notation bloat. I used «create» the standard way, for instantiation with full
initialization of attribute values, typically from in-parameters passed through
the constructor operation. By the same token, I used «instantiate» for raw
instantiation (with just zeroes or similar default values instead), but that
didn't make any difference to the many who interpreted «create» and
«instantiate» as synonyms anyway… The 2.0 notation, especially arrow direction,
hardly made things easier to explain:
- Creation: a dashed arrow (…) to the
creation operation.
- Instantiation: a dashed arrow from the
operation performing the instantiation.
4.
Usefulness subtleties
Middleware,
SOA UDDI, auxiliary classes, object-relational mappers such as Hibernate, and
Design Patterns such as Factory, automate and encapsulate more and more of
object loading, instantiation, or creation. That is, mainstream technologies make
it less and less meaningful to model its detail, see diagram 1 (I might imagine
a simple illustration in an architecture document, to explain the architectural
principle and the mechanism once and for all, i.e. once per company or group
of companies, definitely not every time applications incorporate the
mechanism).
In
contrast, I occasionally showed «create» explicitly, back in the early days of
UML, to explain why there were both a «call» Dependency to an
«interface» (operations in the interface are called, «call» being a third
stereotype of «use» ) and along with that one, another Dependency (
«create» ) as a "shortcut" actually bypassing my nice «interface»,
see diagram 2.
That
was pretty common in a simple environment without any automatism: the designer
of the caller ensured "by hand" that there was an implementing object
behind the «interface», to begin with. Which meant, the caller «create»d this
object before the first call.
Some
people argued that two «use» Dependencies (one for the creation, one for the calls)
would be too generic for such cases. So, for the incorrigible «create» fan, remember
the “open list” in the current UML 2.5 standard: no big deal extending the list,
for company-internal purposes (e.g. for code generation).
5.
Separation of concerns
This
is a key idea underlying both the UML and Informator’s courses (T2715 and T2716): avoid a split of focus, don’t
force-fit a whole bunch of areas of concern into a Class Diagram. Sequence
diagrams show creation graphically (ever since UML 1) without a keyword, plus
they do it “in context” of the actual scenarios where it happens. So, where
detail really matters, they’re better and more precise to show creation.
6.
Abstraction
Abstraction
is a vital point in architects’ job description. With the current shift of
focus from detailed design to architecture, the level of abstraction thus shifts
as well: to components or subsystems.
A Dependency
between Components “summarizes” the fact that some Class/es or subcomponent/s
in one Component have relationships to their counterparts in another Component;
at this level of abstraction, it rarely makes sense to show the detail of
loading or creation (unless you're a platform & infrastructure vendor).
Rather, the UML 2.5 “kernel” seems to take mainstream built-in functionality
into account.
UML 2 Professional, OCUP Advanced Level (level 3, of 3)
In addition to consulting, Milan cooperates with Informator since 1996 in modeling, UML, requirements, analysis, architecture and design. He currently teaches courses and workshops on Architecture fundamentals, Modular Product Line Architecture (T1430), agile modeling (T2715, T2716), and formerly also Informator’s full-up Seminar on Use Cases.
