Abstract
The first approaches to object-oriented modeling appeared already in the second half of the 1970s, but not much happened for more than a decade so there were still barely more than a handful of modeling languages at the end of the 1980s. It was the early 1990s that witnessed an ever-growing market in competing object-oriented methods so that potential users found it increasingly difficult to identify any single method that suited their needs. This phenomenon came to be known as the “method wars.” Toward the end of 1994, two of the “big” players, Grady Booch and Jim Rumbaugh, decided to join forces by integrating their respective approaches, the Booch method and OMT (object modeling technique). In late 1995, Ivar Jacobson became a member of this team merging in his OOSE method (object-oriented software engineering). The efforts of the “three amigos” aimed at overcoming unnecessary differences between the individual approaches and also improving each of them by creating a common, standardized modeling language that could serve as an industry standard. The result was the release of the Unified Modeling Language (UML), version 0.9, in June 1996. The UML partners, an industry consortium, performed further work on UML. This led to the versions 1.0 and 1.1 being introduced in 1997. The latter was adopted by the OMG (Object Management Group) in the same year. The current version is 2.0 (OMG, 2005, 2006).
TopBackground
UML is a language to support the development of software systems. It features a common framework that provides a set of diagram types covering different aspects of an information system. Here we will focus on the ones we deem to be most important: class diagram, use case diagram, and activity diagram. The first is the principal diagram for the static view on a system. The second is often put forward as the central diagram in communication with the user (see, e.g., Dobing & Parsons, 2000). The latter plays a central role in the information-system (or business-oriented) perspective (see following sections). Elementary concepts of the UML are actor, activity (and state), object, and class.
An actor is a human being or a (computer) system who/which is able to perform activities on his/her/its own. The actor typically represents a group of similar human beings/systems and corresponds to the role the actor performs in the given context. Teacher is an example for such an actor. In UML, actors are shown as stick figures.
An activity refers to a logically connected set of actions that are carried out as a unit in some order. These actions might be executed sequentially, alternatively, concurrently, or in any combination thereof. Grade exam is an example for an activity.
“An object is an abstraction of a set of real-world things such that:
- •
all of the real-world things in the set—the instances—have the same characteristics,
- •
all instances are subject to and conform to the same rules” (Shlaer & Mellor, 1988, p. 14).
The structure (attributes) and behavior (operations) of similar objects are gathered in their common class. The values of the attributes at a certain point in time represent the state of the object. Classes are drawn as rectangles with the object identifier printed in bold face. Additional horizontal compartments can be introduced for the attributes and operations of the class. The object is depicted in the same way with the object identifier underlined (optionally followed by a colon and the respective class identifier). Grade is an example of a class, F: Grade that of an object.
Figure 1 shows how these concepts are related to each other: actors perform activities that involve objects. Each object is an instance of precisely one class. The class diagram shows classes and their relations (called associations). An activity diagram gives a detailed account of the order in which activities are executed. It can also show the relevant states of the involved objects. The use case diagram visualizes use cases (complex activities) and their relation to actors.
Key Terms in this Chapter
Attribute: A property of an object/class. The class Car , for example, can have an attribute Color , its value for the object MyCar: Car might be blue .
Object: An abstraction of a set of real-world things that has state, behavior, and identity. An instance of its class where the values of the attributes determine the state and the operations the behavior.
Operation: A function or transformation that may be applied to or by objects in a class. The class Account , for example, might have the operations Open , Close , PayIn ( Amount ), and Withdraw ( Amount ).
Activity: A logically connected set of actions that are carried out as a unit in some order. It is associated with a state (called action state) in which the system remains while the activity is performed.
Actor: A person or (computer) system that can perform an activity. The actor does not refer to a particular individual but rather to a role (e.g., Teacher ).
State: A certain combination of attribute values of an object.
Class: A template for similar objects defining attributes and operations.