6 reasons to prefer a «use» Dependency to «instantiate» and «create».

Less is more in UML models.

My guest blog on May 20^th 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.  

// Milan Kratochvil consultant, Kiseldalen.com and teacher in IT architecture at Informator.

Main author: UML Xtra Light: How to Specify Your SW Requirements and

Growing Modular: Mass Customization of Complex Products, Services and Software .

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.