Advanced UML Structural Modeling

The Unified Modeling Language (UML) is a general-purpose, developmental, modeling language in the field of software engineering that is intended to provide a standard way to visualize the design of a system.

The creation of UML was originally motivated by the desire to standardize the disparate notational systems and approaches to software design. It was developed at Rational Software in 1994–1995, with further development led by them through 1996.

In 1997, UML was adopted as a standard by the Object Management Group (OMG), and has been managed by this organization ever since. In 2005, UML was also published by the International Organization for Standardization (ISO) as an approved ISO standard. Since then the standard has been periodically revised to cover the latest revision of UML. In software engineering, most practitioners do not use UML, but instead produce informal hand drawn diagrams; these diagrams, however, often include elements from UML.

Advanced Structural Modeling

• A relationship is a connection among things. In object-oriented modeling, the four most important relationships are dependencies, generalizations, associations, and realizations.
• Graphically, a relationship is rendered as a path, with different kinds of lines used to distinguish the different relationships.

Dependency

• A dependency is a using relationship, specifying that a change in the specification of one thing may affect another thing that uses it, but not necessarily the reverse. Graphically, a dependency is rendered as a dashed line
• A plain, unadorned dependency relationship is sufficient for most of the using relationships you’ll encounter. However, if you want to specify a shade of meaning, the UML defines a number of stereotypes that may be applied to dependency relationships.
• There are 17 such stereotypes, all of which can be organized into six groups.
• First, there are eight stereotypes that apply to dependency relationships among classes and objects in class diagrams.

1. bind: Specifies that the source instantiates the target template using the given actual parameters
2. derive: Specifies that the source may be computed from the target
3. friend: Specifies that the source is given special visibility into the target
4. instanceOf: Specifies that the source object is an instance of the target classifier
5. instantiate: Specifies that the source creates instances of the target
6. powertype: Specifies that the target is a powertype of the source; a powertype is a classifier whose objects are all the children of a given parent
7. refine: Specifies that the source is at a finer degree of abstraction than the target
8. use: Specifies that the semantics of the source element depends on the semantics of the public part of the target

bind: bind includes a list of actual arguments that map to the formal arguments of the template.

derive: When you want to model the relationship between two attributes or two associations, one of which is concrete and the other is conceptual.

friend: When you want to model relationships such as found with C++ friend classes.

instanceOf: When you want to model the relationship between a class and an object in the same diagram, or between a class and its metaclass.

instantiate: when you want to specify which element creates objects of another.

powertype: when you want to model classes that cover other classes, such as you’ll find when modeling databases

refine: when you want to model classes that are essentially the same but at different levels of abstraction.

use: when you want to explicitly mark a dependency as a using relationship

* There are two stereotypes that apply to dependency relationships among packages.

1. access: Specifies that the source package is granted the right to reference the elements of the target package
2. import: A kind of access that specifies that the public contents of the target package enter the flat namespace of the source, as if they had been declared in the source

* Two stereotypes apply to dependency relationships among use cases:

1. extend: Specifies that the target use case extends the behavior of the source
2. include: Specifies that the source use case explicitly incorporates the behavior of another use case at a location specified by the source

* There are three stereotypes when modeling interactions among objects.

1. become: Specifies that the target is the same object as the source but at a later point in time and with possibly different values, state, or roles
2. call: Specifies that the source operation invokes the target operation
3. copy: Specifies that the target object is an exact, but independent, copy of the source

* We’ll use become and copy when you want to show the role, state, or attribute value of one object at different points in time or space

* You’ll use call when you want to model the calling dependencies among operations.

* One stereotype you’ll encounter in the context of state machines is

1. send: Specifies that the source operation sends the target event

* We’ll use send when you want to model an operation dispatching a given event to a target object.

* The send dependency in effect lets you tie independent state machines together.

Finally, one stereotype that you’ll encounter in the context of organizing the elements of your system into subsystems and models is

1. trace: Specifies that the target is an historical ancestor of the source

* We’ll use trace when you want to model the relationships among elements in different models