Which of the following show the static structure of data and the operations that act on the data?

10.3 Generalization, Specialization, and Inheritance

We showed a large generalization earlier which is presented in Fig. 10.28. The hollow arrowhead points from a specific to a more general type. Hence, generalization is the name for moving up and specialization for moving down. Generalization/Specialization can be used between Classes and also between Use Cases.

We might read the top relationships of this diagram as:

A Structure Diagramis a Diagram

or

A Structure Diagram is a kind of (or sort of) Diagram

or

A Structure Diagram is a specialization of a Diagram

or

A Diagram is a generalization of Structure Diagram and Behavior Diagram

or

Structure Diagrams and Behavior Diagrams are children of Diagram

or

A Diagram is a parent of Structure Diagram and Behavior Diagram

The specialization relationship allows a subclass (the bottom end) to substitute for the superclass (the end with the arrowhead). For substitution to work, all the features of the superclass (e.g., attributes, operations, constraints, signals, receptions, and association) that are available on the superclass must also be available on the subclass.

We normally draw the generalization triangle pointing up and have all the subclasses sharing the same triangle in a tree-like shape. However, you can have each subclass use its own triangle, and the direction can be in any orientation, subject to considerations on readability.

In Fig. 10.29, we show an example of how inheritance works. The features of the superclass Borrowable Material (title, callNo, and borrow()) are available on all the subclasses. In Audio CD and Book, the two attributes (title and callNo) are repeated. UML recommends using the caret (^) to precede inherited features to distinguish them from features that are native to the class. We do not have to show an inherited feature at all. For example, we did not repeat borrow() on Audio Cd or Book, but it is there.

In earlier versions of UML, there was no (^) notation to indicate inherited features. Modelers often grayed out the feature name to indicate that it was inherited. However, this is not now standard.

On Book, we also added another property, that of author:Person. We show that this feature is also inherited in Juvenile Book by showing ^author:Person. We show that this feature is inherited in Adult Book by showing ^author:Person on the end of the association. As previously discussed, we did not have to show these as the association would be inherited naturally. We also added new attribute and operations on the Book subclasses. Also, note that the role name at the Book end and the Adult Book end is not inherited. These are properties of Person.

When a feature is requested on a subclass, the definition of the feature is retrieved. If it cannot be found in the current subclass, the chain of superclasses above the subclass is examined to find the closest definition. When the closest definition is the found, it is retrieved and used. The UML specification does not explain what happens if the definition is never found as that is an implementation/language concern.

We consider the classes with italic names as abstract. Equivalently, we can use an {abstract} flag before or after the class name. We consider the nonitalic named classes as concrete. A concrete class can have instances (objects) created of the Class, but abstract classes cannot have direct instances.14

We can also flag an operation as abstract, using the same techniques as we used for flagging abstract classes (the italic name for the operation or {abstract} after the operation name). An abstract operation is an operation with a defined argument list, but no implementation defined, that is, the mechanism for performing the operation’s work is not available. If a class has an abstract operation, then the class must also be abstract.

If there are abstract classes, they must be superclasses. As an abstract class cannot have instances, the subclasses must be able to have instances to be useful. If there are abstract operations, the subclasses must eventually resolve the missing methods.

At the very bottom of an inheritance hierarchy, all the classes must be concrete. They must be able to have instances, and all their operations must have a method supplied.

10.3.1 Reflexive Structures Using Generalization

One common modeling idiom that also illustrates the power of combing composition with generalization allows for parsing of structures, see Fig. 10.30. In that figure, we show two types of Structures, Simple, or Compound. A Compound Structure has many Structures as parts, which can be either Simple or Compound. If we make the Structure represent a Mathematical Expressions, we can depict how expressions are built from subexpressions. This pattern could also represent clauses in English Sentences, or Parts in a Mechanical Assembly.

Figure 10.30. Reflexive parsing structure.

We made the Structure class an abstract class (in italics) because all structures must be either a Simple Structure or Compound Structure. No structure can exist that is not resolved to be one of the subclasses. In such circumstances, the Generalization/Specialization is considered “complete” or “covering.” It is common in such circumstances to make the superclass abstract.

10.3.3 Polymorphism

An operation on a superclass will be inherited by its subclasses. Not only will the argument list be inherited, but if any method is supplied (the method is the implementation of the operation), it will also be inherited. If the superclass’s method is missing, the operation is abstract, and methods will need to be supplied for the subclasses to make them concrete. Even if the method is available on the superclass, it can be overridden on the subclasses by simply supplying a method anywhere the default method is not sufficient. When we supply different methods for logically the same operation on different subclasses, we call that polymorphism.

Examine Fig. 10.31. In the figure, the Figure Manager class is managing an ordered set of Geometric Figures. One of the operations that the Figure Manager can perform is to sum the areas of all the Figures on a diagram (getDiagramArea()). To accomplish this task, it will loop through all the Geometric Figures in the figure ordered set. Each time it gets a new Geometric Figure from the set, it will call the getArea() operation. The Figure Manager will not need to know that a Circle’s area uses π and that a Square’s does not. Each class knows how to perform its own operations. The Figure Manager could just process in a tight loop, all the figures without looking at them or determining their type. If we added a new subtype of Geometric Figure, for example, a Rhombus, neither Geometric Figure nor Figure Manager would have any changes.

Figure 10.31. Polymorphism example.

If we looked at the code of FigureManager.getDiagramArea(), we would see something like:

totalArea = 0

loop over GeometricFigures in ordered set of Figure:GeometricFigures

  get next GeometricFigure

  totalArea = totalArea = GeometricFigure.getArea()

  endLoop

return totalArea

Polymorphism is a big advantage for object-oriented development, as changes do not propagate, and testing the type of an object is often not needed. It incorporates information hiding, i.e., the details of the getArea() operation are not exposed outside of the Circle or Square.

Points to Remember

•

In Generalization, we have a superclass (or parent class) that holds some features common to the subclasses (or child classes).

•

In Specialization, we have subclasses that inherit any attribute, association, operation, method, constraint, and reception that are defined on the superclass.

•

Generalization and Specialization are two aspects of the same relationship seen from different perspectives.

•

Features (including association ends/roles) at the lower level that are inherited from a higher level can be elided or preceded with a ^ to show explicitly that the feature is inherited.

•

When you ask a subclass to perform an operation, it searches up the inheritance tree for the closest supplied method for that operation.

•

We can declare Classes as abstract, possibly because we defined some features incompletely.

•

An abstract operation on a class automatically makes the class abstract.

•

Abstract classes cannot be instantiated directly because such an instance would be incomplete.

•

A concrete subclass can substitute for the superclass as all its features are defined.

•

Abstract classes support encapsulation and information hiding. A user of the abstract class need not know what actual subclass is being substituted.

•

Polymorphism describes having the same operation appear on different subclasses with different methods.

•

Using Polymorphism also for dynamic determination of the correct method based on the subclass, eliminating the maintenance effort when new subclasses are created.

•

Objects know how to perform their class’s methods.

1.3 Unified Modeling Language (UML)

Some developers believe that UML is a methodology, maybe because of the “M” in the acronym. However, that is not true: UML means Unified Modeling Language, and it is therefore a language that can be used to describe things.

Knowing a language does not necessarily imply the ability to produce useful artifacts. For example, English is a language, but someone who knows how to speak English does not necessarily know how to write good poetry or how to make good speeches. Besides the language syntax, there are knowledge and techniques of best practices that greatly help poets and speakers to place the elements of the language in an order and structure that is adequate to produce the expected results.

The UML language has been under development since James Rumbaugh and Grady Booch joined forces at Rational Software and started to unify their already well-known diagrammatic notations and processes. Later, Ivar Jacobson joined the group and added his use cases and other notations to the unified language that was under development.

UML is constantly being revised and currently has the following three families of diagrams:

Structure diagrams: Includes package, class, objects, composite structure, component, profile, and deployment diagrams. They are used to define what must be implemented in the system in terms of components. They are useful to specify the part of the system architecture that is time independent.

Behavior diagrams: Includes use case, activity, and state machine diagrams. They emphasize what must happen in the system or business process. They are used to describe the functionality of the system.

Interaction diagrams: Includes communication, sequence, timing, and interaction overview diagrams. These are a subset of behavior diagrams and describe the control flow between different components of the system.

Not every diagram must be used during the development of a system. Only those that represent useful information for the project are recommended. This book emphasizes the use of the activity, machine state, use case, sequence, communication, and class diagrams for modeling information systems. However, other diagrams can be useful depending on the features of the system being modeled. For more information on the different UML diagrams, the book by Miles and Hamilton (2006) may be consulted.

9.11 Sleep mode

As with Chapter 6 we embed Sleep mode, when time appears to be suspended, in a chapter on timing. The Sleep mode of the 16F87XA follows exactly the principles of the Sleep mode of the 16F84A, described in Section 6.6 of Chapter 6. A possible limitation of the 16F84A Sleep mode was the limited range of wake-up opportunities. A significant example of this is the lack of a periodic timed wake-up. (Although the WDT seems to offer this, its frequency of operation is imprecise and the range of overflow periods not particularly wide.)

The 16F87XA in contrast offers a wide range of wake-up opportunities, including a number from peripherals. The interrupt structure diagram of Figure 7.10 suggests that all peripherals can cause a wake-up from Sleep. In practice, of course, some of these stop functioning as they depend on the clock oscillator, which is turned off during Sleep. An interesting case now is Timer 1, which can run with its own oscillator. This can be left running while in Sleep, with a periodic wake-up derived from its overflow interrupt. Peripheral wake-up opportunities are available from the following:

Timer 1, when operating in asynchronous mode.

The CCP Capture mode interrupt.

The special event trigger, with Timer 1 operating in asynchronous mode with the external clock.

The synchronous serial port.

The USART (Addressable Universal Synchronous Asynchronous Receiver Transmitter) port.

The ADC, when running with a RC clock oscillator.

EEPROM write complete.

The comparator output change.

The parallel slave port read or write (for the 16F874A or ’877A).

12.2 Answer 5.2: Subsystem Identification

The Roadrunner Traffic Light Control System is a fairly small system, so the system architecture diagram is straightforward. I used a UML structure diagram to represent the system architecture. Note the use of stereotypes «System» and «Subsystem» to mark the architectural elements. This is completely optional but I find it useful to clarify the usage of elements in the model. Note that none of the elements shown in Figure 12.5 are “primitive” – they are all composites containing a possibly rich set of internal parts.

The ports between the Roadrunner subsystems are not (yet) typed by interfaces, but the links among the elements are straightforward. One can certainly imagine these connections are required for system operation and with a little thought one could definitely define a set of services provided and required across these ports. The definition of these interfaces is dealt with in an exercise later in this chapter.

Notice the set of subsystems for the traffic light control system in Figure 12.5. There is a different subsystem for the primary vehicle light assembly (P_VehicleLightAssembly) than for the secondary road (S_VehicleLightAssembly). The two subsystems are, at this point, expected to be identical in their structure and behavior but play different roles; that is, both of these instances are typed by the same class: VehicleLightAssembly. The architecture in this case is shown as objects.

The same architecture could be shown with a class diagram instead. However, the explicit connections cannot be shown in ports in class diagrams (the end points must be objects not classes). It is not unreasonable to avoid the use of ports and use class diagrams instead, but it is a different style. Although we won’t develop this view further, Figure 12.6 shows what it would look like.

The Coyote Unmanned Aerial Vehicle (CUAV) is about two orders of magnitude larger in scope that the traffic light control system. For this reason, the architecture is depicted on a set of diagrams rather than a single diagram. The first of these, Figure 12.7, shows the interconnected systems comprising the CUAV conglomerate. We can see that there are three kinds of systems identified – the CMPS ground systems (for mission planning and operations control), the Coyote (the air vehicle itself), and the various payloads. There are four different payloads shown – missiles, forward-looking infrared (FLIR), optical video, and synthetic aperture radar (SAR). Each of these is stereotyped «System» and they will be decomposed into separate subsystem diagrams. While it is possible to put all this information in a single diagram, it makes that diagram far more difficult to comprehend.

Figure 12.7 is an object diagram, allowing the links to connect the systems at their ports. In this case, the first cut interfaces are shown as well, although not the details of those interfaces. Between the two major systems – the CMPS and the Coyote – there are two ports: a high-speed link for video, radar, and FLIR data, and a low-speed connection for commands and low-frequency data. This latter link is expected to be encrypted. The CMPS also has a port to which unspecified devices can connect to get logs, reports, videos, and other configuration and operational data.

The ports between the Coyote and its (potential) payloads are organized so that the Coyote provides services to configure and command the payload while requiring services that provide data and results from other services. For the sensor payloads, two different interfaces are required from the payload – data services and other services. Also note that all the connected port pairs are port conjugates; that is, what one offers, its pair requires and vice versa. This arrangement is typical.

The systems defined within the CUAV project must be decomposed into their primary subsystems as well. This is done in the following set of diagrams. Figure 12.8 shows the subsystem architecture of the ground station. Note that the Ground Datalink subsystem and the Data Storage subsystem are singletons (i.e., have a single instance) within the ground station, but there are up to four manned stations, and each of these has two stations within them – one for controlling a UAV and one for mission operations, such as receiving and processing the reconnaissance data or targeting and launching missiles. The association among the manned stations allows them to be slaved together into a single station for low-vigilance monitoring.

The guidelines used to link together the subsystems are simple. If one subsystem requires services or data from another, a link is emplaced between them. All links (at the subsystem level) employ ports as a means to help ensure strong encapsulation. Although interfaces on the ports aren’t shown for the internal CPMS links in Figure 12.8, they must exist to specify the services and data passed among the subsystems.

Figure 12.9 shows the vehicle itself. It is organized into a set of subsystems as well. The subsystems are summarized in Table 12.1.

Table 12.1. CUAV Subsystem Summary.

The payloads are not broken down into their subsystems here. One reason is that it is likely that a single team will be developing each of the payloads, so it is less crucial to do that decomposition early. Secondly, the payloads are clearly less complex that either the ground station or the vehicle.

One thing to note about the system-to-subsystem decomposition performed in this answer – the subsystems themselves are multidisciplinary. That is, each subsystem contains software, electronic, mechanical, and possibly chemical engineering aspects. That decomposition is discussed in a later problem in this chapter.

3.2.5.3 Internal block diagram

If BDDs are the SysML equivalent of the UML’s Class diagram, then the IBD is the SysML equivalent of the UML’s Structure Diagram. The IBD is really a usage of a BDD where the purpose is to show the internal part structure of a block. I say that it is a usage of a type rather than a type of diagram because I can show internal parts on a BDD as well, if desired. However, it is a common enough usage that it was reified as a type of structural diagram in the SysML.

Figure 3.10 shows the elements in the previous figure as an IBD. I added some flows on the diagram (electricity and commands) to illustrate something often done by system engineers.

Note that the names on the parts are in an instance-name:block-type format. This way we can see the names of the instances as well as their type. If desired, we can also show other features and properties such as their nested parts, as I did in the case of the WiperController.

We couldn’t show the relations between the ports in Figure 3.9 because the connector relation is not a relation between blocks (which are types) but really relations between block instances or parts. We’ll talk a bit more about different ways to connect blocks and parts later in this chapter.

The IBD is a crucial view because systems engineers structure systems as layers of whole-part decompositions, and this is the intent of this diagram.

2.1.1 Rhapsody Object Model Diagrams

The OMDs are used to specify the structure and the static relationships of the classes and objects in a software system. Rhapsody's OMDs serve, to some extent, the same purpose as the UML's composite structure diagrams, class diagrams and object diagrams. The top-level object in an OMD is usually a composite class that represents the root class of the system and which is also considered as the system container. The IBM Rational Rhapsody code generator directly translates the elements and relationships modeled in an OMD into source code in a specified high-level language (e.g., C, C++, C#, Java, or Ada). Fig. 1A shows a system AB that is composed of two communicating objects: itsA and itsB. Object itsA is of class A that has an integer attribute x that is initialized to 0 and a protocol of a set of three messages: e1, e2, and e3. Similarly, object itsB is of class B that has an integer attribute y that is initialized to 5 and a protocol of three messages: e4, e5, and e6. Message e1 has an integer argument e1Arg1 and message e5 has an integer argument e5Arg1. The behavior of each object is modeled by the Rhapsody Statecharts shown in Figs. 1B and C, respectively.

2.3.1 Identify System Actors

Identifying system actors is shown in Table 2.6.

Table 2.6. Summary: Identify system actors.

Systems consist of several units that work more or less autonomously and, together, form the entire system as a network of communicating units. Since the single system is, in turn, part of a larger system, we speak of an embedded system. Note that for my definition of embedding it doesn't really matter whether the single system is a simple 8-bit processor or a complex aggregate, such as an automobile, for example. The underlying aspects that have to be taken into consideration in the system development are the same.

I've used the word “system” several times in the last short paragraph above. You may not have noticed it. But I still haven't even mentioned what I mean by a system. This is one of these trivial terms that are used all the time but hardly ever defined or examined. The term “system” is relative and varies with the onlooker's standpoint. For a software developer it means a software application that may have a few hardware artifacts. For a hardware developer it means the exact opposite. A systems engineer or customer usually has a rather holistic view. I myself take the view based on the INCOSE definition of a system [45].

A system is an artifact created by humans and consisting of system blocks that, together, pursue a goal. A block can be software, hardware, an individual, or any other unit.

The system under development interacts with individuals and other systems. Its boundary is an important piece of information: What belongs to my system and what's outside of it? This question can be answered in an early project phase—at least in part. We already know who will interact with the system. That's the nature of the matter: I'll hardly have an idea or even a concept for a system unless I know who will operate it.

It is basically clear to all project participants what belongs to the system and what doesn't. However, these views can blur directly at the system boundary. What clearly belongs to a system for some parties could be seen as external interaction partners by others.

The system context diagram shows the system's environment and thus the system boundary. It is not a predefined diagram of SysML or UML, but a variant of block diagrams.9 In the center of the diagram is the system under development. It is a block with the stereotype «system». This clearly distinguishes this block from other system blocks yet to be identified. All currently known interaction partners are denoted all around the system and associations are used to connect them.

The system's interaction partners, i.e., elements outside of it, are called actors. An actor is not a concrete system or a concrete individual, but a role, e.g., “operator” instead of “Miss Gabi Goldfish” or “temperature sensor” instead of “XY sensor article number 4711.”

The model element actor is too general for our purposes. We need a rough categorization of actors and distinguish, e.g., between user, external system, mechanical system, environmental effect, actuator, and sensor. This differentiation helps us better understand the system and makes it easier to describe its services later on. For example, a user has clearly different requirements than a sensor. The categories are represented by different actor symbols.

A user is a human actor. When a human emerges as a direct interaction partner with the system we need to provide a user interface within the system, e.g., the GUI10 of a software application, or the HMI11 of a technical system, such as a dashboard.

A user can and should be asked directly about their requirements to the system. The success of our project depends on their acceptance. Unfortunately, it is not always possible to ask our future users directly. In this case, we try to find a suitable substitute, e.g., somebody in product management or marketing.

We use the standard symbol for actors—the stick man—to represent users (Figure 2.12).

An external system is a system that interacts directly with the system to be modeled. In its role as an interaction partner, the external system is seen merely as a black box. This external system can be the system under development in another project, and our system would then assume the role of an external system from their point of view.

An external system is denoted as a box (Figure 2.13).

A user system is a type of external system that serves as a medium for a user to interact with our system. Typical user systems are keyboard, display, and dashboards.

Whether we model the keyboard as an interaction partner or the user directly as an actor depends on the project. It can be useful for technical systems to describe user systems as interaction partners, since they could be more important than the users behind them from our system's perspective.

Similar to an external system a user system is denoted as a box, but additionally with a user symbol (Figure 2.14).

We can additionally model the individual who operates the user system. For formal reasons, you cannot draw a solid line (association) between a user and a user system, i.e., between two actors. The relationship between any two actors is represented by means of an information flow.

A boundary system is a special external system that provides an interface to another external system. For example, this can be a sender that enables contacting another system. It is comparable to a user system, except that a boundary system is a mediator for another system rather than for a human.

A boundary system is only used if it has a special modeling significance. Otherwise, the external system is a direct actor.

Similar to an external system, a boundary system is denoted as a box with an additional fish symbol (Figure 2.15). The fish symbol is also known as a boundary symbol in software class modeling.

Several factors from the environment influence the system without directly interacting with it. This includes environmental effects such as temperature, precipitation, or oxygen. Only relevant environment effects are of course considered. We don't generally have to model the fact that most systems won't survive umpteen degrees Celsius or total flooding. An environmental effect is denoted as a box with a sun symbol (Figure 2.16).

An actuator is a special external system that serves our system in influencing its environment. In contrast, a sensor is a special external system that accepts information from the environment and passes it on to the system.

Similar to an external system, an actuator is denoted as a box with an additional cogwheel symbol, while a sensor is denoted with an additional symbolic dial gauge (Figure 2.17).

Actuators and sensors are special categories for technical systems. Other categories can be introduced as needed by the project. For example, the sender and receiver categories with their respective symbols are more suitable than actuators and senders in a communication environment.

A mechanical system is a special external system that has only mechanical aspects from our system's view. In particular, it does not include calculation resources, and no data is exchanged, but there may be an exchange of forces, for example.

Similar to an external system, a mechanical system is denoted as a box with an additional tool symbol (Figure 2.18).

You should be careful not to define too many categories, though. Here too, less is more. Think carefully about the goals you want to achieve with a new category before you introduce it. Will it make the diagrams easier to understand and improve the communication? Will it help winning more information or focus on an important fact? How would you model the actors if you were NOT to introduce a new category?

The system context diagram may make a trivial impression. In practice, however, searching for actors can lead to difficult discussions. For example, we modeled the actor customer as a user of our system. Would you have chosen the same actor? Or perhaps opted rather for the card reader? Or the customer card? (Figure 2.19).

The customer is just the one who holds the card in front of the card reader, and the card reader is just the mediator between the customer card and the on-board computer control.

And what about the processors in the card reader, or the cable between the card reader and the on-board computer, or …; are they all actors?

There can be good reasons to model each of the solutions mentioned above. You can surely imagine the kind of workshops where all these are discussed. There is no single recipe for finding the best solution. So every workshop participant would be right. Selecting an actor or the system boundary is a pure project decision.

What interaction partner do you want to focus on? And which blocks really belong to your system or project? Information about other potential actors won't necessarily be lost. If this is the information you think is important, then you should document it, e.g., in a comment.

Figure 2.20 shows you a different way. The relationship marked as flow between the actors car service employee and car management system represents an information flow. The car service employee transmits a status request to the car management system. Notice that you are outside the system under development. Your modeling focus is within the system boundaries. So don't invest too much work into modeling relationships between actors.

If you do have a bigger modeling need between actors it might be a good idea to move the system boundary further outward. The actors would then become part of the system and fall within the modeling focus.

But let's go back to our selection of actors in Figure 2.19. We decided to use customer which means, e.g., that card reader and keyboard are part of the system. In terms of systems engineering, we take a holistic view of the system. This allows us to then derive requirements for the card reader, which is to be purchased from a third party, or evaluate other conceivable access systems, such as a cell phone (see Section 2.8.1). Altogether, we now have the system context model fully worked out, as shown in Figure 2.21.

When searching for actors we normally run into elements that are not outside but inside our system. Now, what do we do with this information? We cannot model these elements as actors, since actors are outside the system by definition.

Of course, we won't discard this information for the only reason that it is not needed in this work step; instead, we add it. Model an element found as a so-called block and use the composite relationship to connect it with the entire system (Figure 2.22). Blocks are a concept of the SysML language. We will be looking at blocks more closely in Section 4.5.

PROJECT DIARY

Project Time 5942

We managed to excellently use the system context diagram in a workshop with the domain experts. Though not all of the participating domain experts came from the engineering field none of them had trouble understanding and commenting the diagram. That's very beneficial for our project, since we can coordinate the models directly with the principal, who will now be jointly responsible.

In contrast, there were fierce discussions about the planned navigation system. Though they considered it a very good service, they feared, on the other hand, that customers may feel they are being watched, because SpeedyCar would be technically able to determine the current position of a car at any given time. We will consider it secondary for the time being until there will be a final decision either for or against the navigation system.

4.6 Diagrams

UML has 14 kinds of diagrams, divided into two convenient and conceptual groups: Structure and behavior. Each of the boxes in the tree-like Fig. 4.8 represents a diagram type in UML. As it is one of the first UML diagrams that you may have seen, we need to go over the meaning of the notation. Each box represents a class, that is, a type, a type of diagram. The concepts (Generalization and Specialization) were already introduced in Chapter 2, What is UML?. A hollow arrow points up from specific diagram types to a more general diagram type. This arrow is called a generalization when you follow the arrow going up and specialization when you look toward the tail going down. Following a tree metaphor, the generalization arrow points to more central branches, and the box labeled diagram is the trunk of the tree. When you go down to the tail of the arrow, you are going down to smaller branches and pointing to the leaves at the lowest level.

When you travel up the tree, you can think of this best by reading it something like “A Class Diagram is a kind of Structure Diagram, which is a kind of Diagram.” Similarly, “A Sequence Diagram is a kind of Interaction Diagram, which is a kind of Behavior Diagram, which is a kind of Diagram.” Some people reading this prefer to use the words “sort of” or “type of” to “kind of.”

We introduced the topics of Generalization and Specialization earlier in Chapter 2, What is UML?. They play an important role in UML modeling.

When you travel down the tree toward the leaves, you find that there are multiple kinds of some of the diagrams. Fig. 4.8 shows that there are seven kinds of structure diagram. (Make sure you can see how this works.)

The boxes with their names in normal (roman) font are concrete classes. Going left-to-right in Fig. 4.8, they are Profile, Class, Composite Structure, Component, Deployment, Object, Package, Activity, Use Case, State Machines, Sequence Communication, Interaction Overview, and Timing Diagrams. A concrete class is a class that may have individual instances—In this case; they may have diagrams of their specified type. A concrete class is a set that may contain individual elements. There are 14 concrete classes in the figure matching the 14 diagram types in UML 2.5.

The boxes with their names in italic font are abstract classes. (You should be able to find abstract classes in the figure.) These are branches that only split off into other branches, while not having any leaves themselves; that is, they are classes that can only contain other classes.

Don’t worry if this sounds a bit confusing. We will cover the abstract–concrete distinction in more detail in the later chapters.

Points to Remember

UML has 14 kinds of diagrams.

There are two categories of UML diagrams: Structure and Behavior.

A hollow arrow (generalization) points from the specific to the more general.

Specialization (the other direction of a generalization) points to a special kind of the general.

Abstract classes cannot have any individual elements, only other classes.

Concrete classes may have individual elements.

4.6.3 General Diagram Features

In UML, there are some common diagram capabilities and features that are conveniently discussed here.

4.6.3.1 Views

A UML diagram is just a view into the model. A model element, such as a class, need not appear on any diagram. We have previously shown this relationship, but now we redraw it as a metamodel diagram in Fig. 4.9.

Figure 4.9. The relationship between model and diagram elements.

So not only may there be model elements that have no diagram elements, and therefore appear on no diagrams, but some model elements may appear on multiple diagrams, and can appear multiple times on the same diagram. Moreover, because they are views, they do not have to appear with the same amount of detail at each appearance. The underlying model element will be a cumulative union of all the matching diagram elements from all the diagrams. If you add detail to a matching diagram element, even if that detail appears on only one diagram, it becomes part of the underlying model element, and that detail is capable of being summoned up on each diagram that can display that detail.

The tools will allow you to delete detail from the diagram or from the model. Of course, if you delete the detail from the model, you will be updating all diagrams containing that element automatically to remain consistent with the underlying model element. So be careful, if you perform a delete on a diagram, you explicitly select the scope: Either diagram-element scope or model-element scope.

4.6.3.2 Diagram Frame and Header

Often in UML, we surround a UML diagram by a boundary box called a frame. For some diagram types, the frame has semantic meaning. In these diagram types, diagram elements may be placed on the frame or across the frame boundary for different meanings. In these diagram types, using the frame may be necessary to indicate some specific feature. However, except for this purpose, eliminating the frame is generally at the modeler’s option.

Without the frame, the diagram often does not feel complete. In the OCUP 2 exams, as we often omit the frame because of space reasons, we usually refer to the remainder as a diagram fragment. Of course, everything relevant to answering the question is still in the diagram fragment.

When the diagram frame appears, we are required to have a diagram header, which serves as the name for the diagram. Based on the UML Specification of Annex A, the diagram header is contained in a name tag, a rectangle with a cutoff corner (the lower right corner) forming an irregular pentagon (Fig. 4.10).

Figure 4.10. A UML diagram with <heading> and <contents area>.

UML 2.5 Specification Fig. A.1.

The format for the <heading>, given in BNF, is the following.

[<kind>]<name>[<parameters>]

<kind> ::= ‘activity’ | ‘act’ | ‘class’ | ‘component’ | ‘cmp’ | ‘deployment’ | ‘dep’ | ‘interaction’ | ‘sd’ | ‘package’ | ‘pkg’ | ‘state machine’ | ‘stm’ | ‘use case’ | ‘uc’

This syntax in BNF is subject to many rules; the example above has the following rules:

1.

The angle brackets, “<>”, indicate a field that the user can supply the contents.

2.

Fields surrounded by square brackets, “[ ]”, indicate that the field is optional.

3.

The “::=” is an assignment statement defining a field by lower level fields for substitution.

4.

Fields separated by vertical bars “|” are alternatives.

5.

Terms surrounded by quotes are literals, and must be supplied as is. In the example, the literals are all bold face.

Therefore, the <kind> field is optional, but if used, it may be any one of the 15 listed possibilities. The <name> field is required, and the <parameters> field is optional.

The boundary box of the diagram represents the owning or containing model element. The heading of a diagram represents the <kind>, <name>, and <parameters> of the namespace enclosing or the model element owning or containing the element in the diagram’s <contents area>. In the OCUP 2 Foundation exam, the <parameters> field will not be tested.

Many tools and users get confused and believe the bold <kind> field indicates the Diagram Kind. Thus, a diagram containing use cases and actors would be given the <kind> of uc based on this misconception. Unfortunately, this is wrong. Usually, a set of use cases would be kept in a package, so the correct <kind> field would be pkg. This approach is different from SysML, where the <kind> field indicates the kind of diagram.

The majority of structure diagrams and use case diagrams would have <kind> field of pkg. Because behavior diagrams work a bit differently, the <kind> of owning or containing model element tends to match the diagram type. There is still the confusion that interaction diagrams (sequence diagram, timing diagram, interaction overview diagrams, and communication diagrams) all use the <kind> field of sd.

We’ll show examples of the basic format for a diagram header starting in Section 4.6.3.4, Namespace.

4.6.3.3 Diagram Kind

The Diagram Kind is still a useful concept, even if it is different from the <kind> field in the diagram header. If you know the kind of diagram, then you know what types of elements would be likely to appear on the diagram. This controls the editing palette that the tools will offer up for editing. If the majority of elements on a diagram are packages, then it is a package diagram. If the majority of elements on a diagram are classes, it is a class diagram. If the majority of elements are objects (instance specifications), then it is an object diagram. If there seems hard to decide, we generally go with the most inclusive, so we prefer to call a diagram a class diagram to calling it an object diagram if we can’t decide.

It is always possible to put an object on a class diagram or a class on an object diagram and possible to put both objects and classes on a package diagram. As classes and objects can be stored in a package, all these diagrams are likely to have a <kind> field of pkg.

4.6.3.4 Namespace

What makes the given <kind> values the possible values? These are all namespaces in UML that are capable of holding other elements. A namespace is a software development concept. It is a set of unique names that identify entities. A namespace does not allow duplicate names. If a name appears more than once, it must refer to the same thing.

A package is a namespace. The symbol for a package is rectangle body with a tab in the upper left, which usually contains the name of the package, see Fig. 4.11. The elements inside the package cannot have clashing names. A class is also a namespace. It has a set of attributes (see the class symbol, Book, inside the figure), each with a name, and no duplicate names are allowed for the attributes.

Figure 4.11. A package with a class and an object.

A package is primarily an organization feature for a UML model. Consider it similar to a folder or directory in an operating system. These are also namespaces. The operating system will not allow you to have two files with identical names within the same directory/folder. A package will not allow two elements (of the same type) with the same name inside the package. If an element appears twice in a package, they are just representations of the same thing.

Modelers create packages for their namespace features, but they primarily create them for the same reasons developers create directories. They help to organize the project. They serve as configuration management structures. They can be used to assign work to teams, schedules, and limit the chance the modelers step on each other’s work.

The above package could be converted into a diagram. In Fig. 4.12, we depict a class diagram (because the diagram depicts classes and objects) showing the contents of the package MyPackage. The <kind> field is pkg and the <name> field is MyPackage.

Figure 4.12. A class diagram showing the contents of a package.

4.6.3.5 Comments

UML allows the modeler to add comments to a diagram or diagram fragment. The symbol for a comment, sometimes called a note-symbol, is a rectangle with a bent upper-right corner. The comment may be connected to the elements being annotated with a dashed line (not an arrow). In previous versions of UML instead of an arrowhead, there was a small circle. Now in UML 2.5, there is neither an arrowhead nor a circle (Fig. 4.13).

Figure 4.13. Class diagram with comment.

4.6.3.6 Constraints

A constraint is a rule that prohibits some potential values for a field. In UML, constraints can be added to many places on a diagram. One common way is to place the constraint inside a comment symbol. To identify it is a constraint the text of the constraint is surrounded by curly braces, {}.

The BNF for a constraint is as follows:

<constraint> ::= ‘{’ [ <name> ‘:’ ] <boolean-expression> ‘}’

where <name> is the optional name of the Constraint.

If the <name> field appears it is followed by the colon ‘:’.

<boolean-expression> is the textual form for the Constraint. It is required to have either a true of false value when evaluated.

The whole expression is surrounded by curly braces ‘{}’.

The language for the constraint can be in the OCL, or in a programming-like syntax, or in mathematical-like syntax, or in natural language. We usually try to make it a true-false, Boolean expression, but if a natural language is used, it may be difficult to force it into that form.

In Fig. 4.14, we depict a constraint, using an unnamed Boolean expression. The constraint is on the length of the ISBN string, based on the publishing year of the book. As with a comment, we connect the constraint to all the elements that are involved. Here, we connect the constraint to year and to ISBN because the constraint uses both those fields.

Figure 4.14. Class diagram with constraint.

Points to Remember

•

An element can appear on as many diagrams as needed, including no diagrams, and multiple times on the same diagram.

•

The underlying model element is consistent with the union of the details of all its appearances.

•

Deleting a diagram element or any of its features only changes the underlying model element if specifically requested.

•

UML diagrams can be enclosed in a frame with a header.

•

The header is placed inside a pentagonal tab in the upper left.

•

The header has an optional <kind> field indicating the kind of the containing namespace.

•

The header also contains the <name> of the containing namespace.

•

A namespace is a structure that enforces unique names on its contents.

•

The most common namespace for structural diagrams (and use case diagrams) is the package (pkg).

•

A package is an organizing namespace that has an upper-left named tab.

•

Interaction diagrams use a <kind> of sd.

•

The Diagram Kind is based on the diagram contents; the <kind> in the diagram header is the type of owning namespace.

•

Diagrams can have comments and constraints which use a note shape with a folded down upper-right corner.

•

Comments connect to the annotated elements and constraints connect to their constrained elements by a dashed line with no adornments.

2.4.2.2 Design

Design covers modeling of the things in the solution world that you have chosen, the approaches you are going to take, the decisions you have made, based on your understanding of the analysis products. Taking the analysis products as input, Design covers the modeling of the additional things that you have chosen to be part of the solution, the approaches you are going to take, the patterns you are going to repeat, and the decisions you have made, all to meet the users’ needs and system requirements.

conceptualization: Covers the high-level design approaches to how the system will work, including the major systems and subsystems that will need to be made. Often the major principles of architecture are also covered. As the conceptualization effort reveals the basic solution approaches, conceptualization is often used to produce a better estimate of the cost and schedule for the project. In this type of model, all of the UML diagrams may be used, though the detail is light, to convey the approach without getting lost in the weeds.

architecture: Covers the modeling necessary to convey the organization and associated principles of the new system. The UML models will need to cover the structure, behavior, and other views of the system. Specialty views are common, for example, a Security View would encompass the set of UML diagrams that cover how the system’s security will work. Other views may need to be constructed, such as how the system will be installed, upgraded, turned off, disposed of, upgraded, maintained, or replenished. These views are usually tailored to a particular community of interest.

Architecture models can include all of the diagrams in UML, but may only show the information supporting the current view. Architecture models need to support reasoning about the structure and behavior of the system, so that changes, when made, will be consistent with the overall architecture. Patterns specifying the how the elements interact with each other, such client-server, peer-to-peer, or layers, would be captured as part of the architecture model, so that reviewers will know the approaches being taken, and the later implementer can use the pattern when needed.

Detailed Design: Covers the remaining details necessary to specify the solution, following the architectural decisions made previously. The target of the models made during detailed design are the developers themselves so that the diagrams can be considerably more detailed. They typically include composite structure diagrams, communication, component, and deployment diagrams to an extent not done earlier.

Points to Remember

Design modeling captures what the new system will have and how it will work.

Conceptualization captures high-level design decisions on how the system will be made.

Architecture captures the general arrangement of how the system’s structure and behavior will work. It will show patterns of structure and behavior that will be repeated throughout. Architecture views will often be tailored to specific interested communities.

Detailed Design capture the entire planned solution.