The Unified Modeling Language User Guide SECOND EDITION [Electronic resources] نسخه متنی

Common Modeling Techniques

Modeling Structured Classes

A structured class can be used to model data structures in which the parts have contextual connections that apply only within the class. Ordinary attributes or associations can define composite parts of a class, but the parts cannot be related to each other on a plain class diagram. A class whose internal structure is shown with parts and connectors avoids this problem.

To model a structured class,

• Identify the internal parts of the class and their types.

• Give each part a name that indicates its purpose in the structured class, not its generic type.

• Draw connectors between parts that communicate or have contextual relationships.

• Feel free to use other structured classes as the types of parts, but remember that you can't make connections to parts inside another structured class; connect to its external ports.

Figure 15-6 shows the design of the structured class TicketOrder. This class has four parts and one ordinary attribute, price. The customer is a Person object. The customer may or may not have a priority status, so the priority part is shown with multiplicity 0..1; the connector from customer to priority also has the same multiplicity. There are one or more seats reserved; seat has a multiplicity value. It is unnecessary to show a connector from customer to seats because they are in the same structured class anyway. Notice that Attraction is drawn with a dashed border. This means that the part is a reference to an object that is not owned by the structured class. The reference is created and destroyed with an instance of the TicketOrder class, but instances of

Attraction are independent of the TicketOrder class. The seat part is connected to the attraction reference because the order may include seats for more than one attraction, and each seat reservation must be connected to a specific attraction. We see from the multiplicity on the connector that each Seat reservation is connected to exactly one Attraction object.

Modeling an API

If you are a developer who's assembling a system from component parts, you'll often want to see the application programming interfaces (APIs) that you use to glue these parts together. APIs represent the programmatic seams in your system, which you can model using interfaces and components.

An API is essentially an interface that is realized by one or more components. As a developer, you'll really care only about the interface itself; which component realizes an interface's operations is not relevant as long as

some component realizes it. From a system configuration management perspective, though, these realizations are important because you need to ensure that when you publish an API, there's some realization available that carries out the API's obligations. Fortunately, with the UML, you can model both perspectives.

The operations associated with any semantically rich API will be fairly extensive, so most of the time you won't need to visualize all these operations at once. Instead, you'll tend to keep the operations in the backplane of your models and use interfaces as handles with which you can find these sets of operations. If you want to construct executable systems against these APIs, you will need to add enough detail so that your development tools can compile against the properties of your interfaces. Along with the signatures of each operation, you'll probably also want to include uses cases that explain how to use each interface.

To model an API,

• Identify the seams in your system and model each seam as an interface, collecting the attributes and operations that form this edge.

• Expose only those properties of the interface that are important to visualize in the given context; otherwise, hide these properties, keeping them in the interface's specification for reference, as necessary.

• Model the realization of each API only insofar as it is important to show the configuration of a specific implementation.

Figure 15-7 exposes the APIs of an animation component. You'll see four interfaces that form the API: IApplication, IModels, IRendering, and IScripts. Other components can use one or more of these interfaces as needed.