In data-intensive systems, modeling the (structure of) the data is an important concern. Until the 1970s, data modeling techniques very much mixed up implementation concerns with concerns arising from the logical structure of the universe of discourse (UoD). For example, the book catalog would be modeled as a 'table' containing 'tuples' ('records') with alphanumeric fields containing the title and author and numeric fields containing the publication year and number of pages.

Entity—relationship modeling (ERM), as pioneered by Chen, is directed at modeling the logical, semantic structure of the UoD, rather than its realization in some database system. Entity—relationship models are depicted in entity—relationship diagrams (ERDs). There are many variants of ERM, which differ in their graphical notations and extensions to Chen's original approach. The basic ingredients of ERM are given in Table 10.1.

An entity is a 'thing' that can be uniquely identified. Entities are usually depicted in an ERD as rectangles. Example entities are:

Entities have properties known as attributes. For example, some library employee may have the name 'Jones'. Here, 'Jones' is the value of the attribute called 'name'. Attributes are usually depicted as circles or ellipses.

Both entities and attribute values have a type. As modelers, we tend to view a type as a set of properties shared by its instances. As implementors, we tend to view a type as a set of values with a number of associated operations. For the attribute 'number of books on loan', the set of values could be 0..10 with operations such as increment and decrement. For the entity type 'book copy', candidate operations would be 'borrow', 'return', and so on.

Entities are linked through relationships. For example, the relationship 'borrow' involves the entities 'book copy' and 'library member'. Most often, a relationship is binary, i.e. it links two entities. A relationship is denoted by a diamond linked to the entities involved.

Entity—relationship models impose restrictions on the cardinality of relationships. In its simplest form, the relationships are 1—1, 1—N, or N—M. The relationship 'borrow' is 1—N: a copy of a book can be borrowed by one member only, while a member may have borrowed more than one book copy. In an ERD, these cardinality constraints are often indicated by small adornments of the arrows linking the entities.

An example entity—relationship diagram is given in Figure 10.1. Cardinality constraints have been indicated by explicitly indicating the set of possibilities. Thus, this ERD states that a book copy can be borrowed by at most one member, and a member may borrow up to ten book copies.

An entity—relationship model can be obtained using any of the elicitation techniques discussed in Chapter 9. In particular, form analysis and analysis of natural language descriptions are often used. Since ERMs tell only part of the story, additional techniques have to be employed to model other aspects. Many structured analysis techniques, for example, incorporate ERM to model the data aspect.

Figure 10.1. An entity—relationship diagram

Entity—relationship modeling is a natural outgrowth of database modeling. Originally, ERM was intended to model the logical structure of data, rather than the logical structure of the UoD. In heuristics on how to obtain a 'good' entity—relationship model, these roots are still visible. For example, some of these heuristics resemble normalization constraints from database theory. This may explain why some do not commend entity—relationship modeling as a requirements specification technique (see, e.g., (Davis, 1993)).

Present-day ERM has a lot in common with object-oriented analysis techniques. For example, subtype—supertype relations between entity types are included in many ERM-techniques. Conversely, the class diagram of UML (see Section 10.3.1) includes many elements from ERM.

At any one point in time, our library system is in one of a (vast) number of possible states. The state of the library can be expressed in terms of:

Any action occurring in the library, be it the return of a book or the appointment of a new employee, transforms the current state s into a new state s′.

Requirements specification techniques which model a system in terms of states and transitions between states are called state-based modeling techniques. A simple yet powerful formalism for specifying states and state transitions is the finite state machine (FSM). An FSM consists of a finite number of states and a set of transitions from one state to another that occur on input signals from a finite set of possible stimuli. The initial state is a specially designated state from which the machine starts. Usually, one or more states are designated as final states. Pictorially, FSMs are represented as state transition diagrams (STDs). In a state transition diagram, states are represented as bubbles, with a label identifying the state, and transitions are indicated as labeled arcs from one state to another, where the label denotes the stimulus which triggers the transition. Figure 10.2 gives an FSM depicting the possible states of a book copy and the transitions between those states. The final state is the one labeled 'written off'. Any of the others could be designated as the initial state.

Figure 10.2 models only a tiny part of the library system. It does not describe the complete state of the system in any one bubble, nor does it depict all possible state transitions. Modeling a system in one, large, monolithic STD is not to be recommended. Such a structure soon becomes unwieldy and difficult to understand. Though we could model the system in a series of FSMs, we would still have the problem of how to integrate them into one model.

A possible way out is to allow for a hierarchical decomposition of FSMs. This is the essence of a notation known as statecharts. In statecharts, groups of states can be viewed as a single entity at one level, to be refined at the next level of abstraction. In UML, FSMs are modeled as state machine diagrams (Section 10.3.2).

Figure 10.2. A state transition diagram

The data flow design method originated in the early 1970s with Yourdon and Constantine. In its simplest form, data flow design is but a functional decomposition with respect to the flow of data. A component (module) is a black box which transforms some input stream into some output stream. The main notation used is that of data flow diagrams (DFDs).

Four types of data entity are distinguished in a data flow diagram:

Data flow diagrams result from a top-down decomposition process. The diagram at the highest level has one process only, denoting 'the system'. This top-level diagram is then further decomposed. For our library example, this could lead to the data flow diagram of Figure 10.3. A client request is first analyzed in a process labeled 'preliminary processing'. As a result, one of 'borrow title' or 'return title' is activated. Both these processes update a data store labeled 'catalog administration'. Client requests are logged in a data store 'log file'. This data store is used to produce management reports.

The design method mostly used in conjunction with data flow diagrams is discussed in Section 12.2.2. There, we also give more example data flow diagrams.

CRC stands for Class—Responsibility—Collaborators. A CRC card is simply a 4″×6″ or 5″×7″ index card with three fields labeled Class, Responsibility and Collaborators. CRC cards were developed in response to a need to document collaborative design decisions. CRC cards are especially helpful in the early phases of software development, to help identify components, discuss design issues in multi-disciplinary teams, and specify components informally. CRC cards may be termed a low-tech tool, as opposed to the high-tech tools we commonly use. Yet they are highly useful. They are also fun to work with in our all-too-serious business meetings.

CRC cards are not only used in collaborative design sessions. Within the design pattern community, for instance, they are used to document the elements that participate in a pattern.

Figure 10.3. Data flow diagram for library automation

The word 'class' in CRC is a historical relic. CRC cards can be used to describe any design element. We will stick to the original terminology, however. The class name appears in the upper-left corner of the card. A bulleted list of responsibilities appears under the class name and a list of collaborators appears on the right part of the card. Figure 10.4 gives an example of a CRC card for a Reservations component in our library system.

The main responsibilities of this component are to keep an up-to-date list of reservations and to handle reservations on a FIFO basis. Its collaborators are the Catalog and User session components. The types of interaction with these components are shown in Figure 10.13.

Class diagrams depict the static structure of a system. A class diagram is a graph in which the nodes are objects (classes) and the edges are relationships between objects. By decorating the edges, many kinds of relationship can be modeled. These relationships fall into two groups: generalizations and associations.

The most common example of a generalization class diagram depicts the subclass—superclass hierarchy. Figure 10.5 is an example of such a class diagram. The classes are denoted by rectangles that have three compartments. These compartments contain, from top to bottom:

UML allows for quite some variety in its notation. We may for instance depict a class as a rectangle with one compartment only, just giving the name of the class. Adding slightly more detail, we may depict a class as a rectangle having two compartments, where the second one characterizes the responsibilities of that class, i.e., what it is supposed to do, as kind of an inline comment. Figure 10.6 gives the three-compartment representation in which a number of analysis-level details have been added. We may even extend the notation further and add implementation-level details, such as whether attributes and operations are public or private. We may think of these different representations as different views of the same model element. We may envision tool support that allows the user to switch from one representation to another, suppressing or adding detail as the need arises.

Figure 10.6. UML class diagram: generalization

The hollow triangle in Figure 10.6 indicates that the structure is a specialization—generalization structure. Generalization is shown as a solid path from the more specific element (such as Book) to the more general element (Publication), with a large hollow triangle at the end of the path. A group of generalization paths may be shown as a tree with a shared segment, as in Figure 10.6.

The attributes of a class denote properties of that class. For example, publisher is a property of Publication. Next to attributes, UML has another way of denoting properties of a class, viz. associations. A UML association is depicted as a solid line connecting two classes. This line may be adorned with a variety of glyphs and textual information to provide further specifics of the relationship. A simple association between a library and its clients is depicted in Figure 10.7a. The (optional) name of the association is printed near the path. The solid triangle indicates the direction in which the verb is to be read. Note that associations are bi-directional: a client is a member of a library and a library has members. Further adornments can be added to indicate properties of the association. In Figure 10.7a we have added multiplicity information: a client can be a member of one or more libraries, while a library may have zero or more clients.

Figure 10.7. UML class diagram: (a) association, (b) association as attribute, (c) association class, (d) association class as a full class

Strictly speaking, there is no difference between an attribute and an association. In Figure 10.7b, we have depicted Client as an attribute of Library. Usually, simple properties such as numbers and dates are modeled as attributes, while more significant concepts are modeled as associations.

An association such as Member-of also has class properties. For example, this association has attributes, e.g.MemberId, and operations, such as BecomeMember and CeaseToBeMember. Alternatively, we may say that class Membershiphas association properties. In UML, this model element is termed an association class. It can be depicted as a class symbol attached by a dashed line to an association path, as in Figure 10.7c. We may even promote an association class to a full class, as in Figure 10.7d. Notice that the multiplicities have moved. A membership (of a client) can be to one or more libraries, whereas the membership (of the library) relates to zero or more clients.

The part-of relationship is called aggregation or composition in UML. In an aggregation, objects can be part of more than one other object. For example, if our library maintains lists of required reading for certain courses, then a given book may be a part of more than one required reading list. Aggregation is denoted by an open diamond as an association role adornment. Composition is a strong notion of aggregation, in which the part object may belong to only one whole object. With composition, the parts are expected to live and die with the whole. If a table is composed of four legs and a tabletop, the table owns these parts. They cannot be part of another table at the same time. Composition is denoted by a solid filled diamond as an association role adornment, as in Figure 10.8a, which shows a Book with parts title, author, and isbn. A book has one title and one ISBN, so these parts have multiplicity 1. We assume here that a book may have up to three authors, so that part has multiplicity of 1..3. At the whole end of composition, the multiplicity is either 1 or 0..1. This part-of relationship is a relationship between a class and the classes of its attributes. An alternative notation for this part-of relation therefore consists of the top two compartments of the diagram for a class, as in Figure 10.8b.

Next to generalization and association, there are many other ways in which elements of a class diagram may depend on each other. For example, one class may call operations from another class, create instances of another class, and so on. Such dependencies are depicted with a dashed arrow, labeled with the type of dependency. If all dependencies are included in a class diagram, it soon becomes very cluttered. So it is wise to include only important dependencies. Many types of dependency need not be modeled by hand, but can be derived from the source code, and tools exist to do so.

Figure 10.8. UML class diagram: composition as (a) association role adornment and (b) a simple class diagram

An abstract class is a class that cannot be instantiated directly. Only its (concrete) clients can. Abstract classes typically occur in hierarchies of data types. For instance, we may have an abstract class List, with subclasses such as LinkedList and ArrayList. The abstract class List may have abstract operations, such as get, that can only be made concrete at the subclass level. At the level of List, we then merely state that each of its subclasses will provide an implementation of get. In our library example, we could have designated Publication as an abstract class. Abstract classes are indicated by printing their name in italics.

An interface is a class all of whose features are abstract. It has no implementation. Interfaces are a useful means of splitting the set of properties of a class into subsets, in case other classes only need access to subsets of those properties. For instance, class Publication may have properties that are accessible to customers of the library, as well as properties that are for internal use only, such as its price, who authorized acquisition, and so on. We may then define two interfaces to Publication that are made available to other classes in the system. Publicationthen provides different interfaces to different client classes, who in turn require the interface. Interfaces are marked with the keyword ≪interface≫, as in Figure 10.9. Interfaces are often used to increase the robustness of a model, by restricting access to only the properties really needed.

A major class of services provided by an object relates to the object's life cycle: an object instance is created, updated zero or more times, and finally destroyed. State transition diagrams, which depict the possible states of an object and the transitions between those states, are a good help in modeling this life cycle.

Figure 10.9. UML class diagram: interface

Usually, the finite state machine model and its associated state transition diagram (see Section 10.1.2) are extended in several ways when used in modeling the behavior of objects over time:

Many modeling methods, including UML, depict the sequence of states that an object goes through in a variant of the statechart. Statecharts are extended finite state machines (i.e. they have local variables) in which output actions may be associated with both transitions and states and in which states can be arranged hierarchically. In UML, this type of diagram is called a state machine diagram. As with class diagrams, UML has a rich notation for state machine diagrams. We will illustrate the major ingredients through a few examples (see also Figures 10.10 and 10.11).

A state is some condition in the life of an object. It is shown as a rectangle with rounded corners. An initial (pseudo) state is shown as a small filled circle. This initial state is a mere notational device; an object can not be in such a state. It indicates the transition to the first 'real' state. A final (pseudo) state is shown as a circle surrounding a small filled circle. This final state is also a notational device. A transition is shown as a solid arrow from one state to another. When a change of state occurs, that transition is said to 'fire'. A transition has a label that comes in three parts. The general form is trigger-signature [guard]/activity. All three parts are optional. The trigger-signature denotes the event which triggers the transaction, such as the borrowing of a book. The event may be guarded by a Boolean expression. For example, the transition from state is-member to cleaning-up in Figure 10.10 is guarded by the expression 'N = 0': it can only occur if the number of books on loan is zero. When an event occurs, only one transition can be taken. So if multiple transitions occur with the same event, the guards must be mutually exclusive. The transition label may include a procedural expression after the symbol '/'. This procedural expression is executed when the transition fires.

Figure 10.11. UML state machine diagram: object Book, (a) global view and (b) expanded view

Figure 10.11 gives an example of nested states. Figure 10.11a gives a global view of the life cycle of an object Book: a book is ordered, stays alive for a while, and is eventually either disposed of or archived. In Figure 10.11b, state alive is expanded to show its finer structure. In this example, the state is refined into mutually exclusive disjoint substates: a book is either available or borrowed.^[9] The transition from state ordered to state alive is drawn to the boundary of state alive. This is equivalent to a transition to the initial state within the graphics region of alive. The transition from the nested state available to states disposed and archived is made directly. To indicate this transition from a suppressed internal state of alive to disposed and archived in Figure 10.11a, the transitions are not drawn from the boundary of alive, but from a so-called stub, shown as a small vertical line drawn inside its boundary.

Objects communicate by sending messages. To carry out a certain task, a particular sequence of messages may have to be exchanged between two or more objects. The time ordering in which this sequence of messages has to occur may be depicted in a sequence diagram. A sequence diagram is one type of interaction diagram. A second type of interaction diagram is the communication diagram, discussed in Section 10.3.4. In the telecommunications domain, sequence diagrams are known as message sequence charts; they provide a standard notation for designing and specifying protocols. The sequence diagram is also used in the design pattern community, to graphically depict the interaction between two or more objects participating in a design pattern.

In a sequence diagram, the horizontal dimension shows the various objects that participate in the interaction. An object is shown as a vertical dashed line, its 'lifeline'. The period in which the object is active (within the particular sequence of messages depicted) is shown as a thin rectangle. If the distinction between active and inactive is not important, the entire lifeline may be shown as an activation, as in Figure 10.12. The ordering in which the objects are shown carries no meaning.

The vertical dimension denotes the time sequencing of messages. Usually, only the order in which messages are displayed carries meaning. For real-time applications, the time axis may show actual numerical values.

Messages are shown as labeled arcs from one object to another. The vertical arrangement of messages indicates their order. The labels may also contain sequence numbers, which are particularly useful to indicate concurrency. A message may also be labeled with a guard, a Boolean expression that states the condition which must hold for the message to be sent.

Figure 10.12 shows a possible sequence of interactions between a user, a catalog of available books, and an object which handles reservations. The first message comes from an outside, unknown source. This message is called the found message. The user then sends a request to the catalog to look up a certain title. The catalog reacts by sending data about that title to the user. If the title is not available (this is indicated by a Boolean expression, the guard, within square brackets), a request to reserve that title is sent to the object that handles reservations. Some time later, that title will become available again and reservations will be notified. The object reservations will then send a message to the catalog to hold that book and will notify the user that the title is now available. The ordering of those two messages is irrelevant, so they carry the same sequence number. The user may now borrow the title and the corresponding reservation will be removed.

Figure 10.12. UML sequence diagram: reserving a title

Again, UML has a rich notational vocabulary for sequence diagrams. It is possible to distinguish asynchronous message-passing from synchronous message-passing, to indicate iteration, to show the creation and destruction of objects, and so on. The main purpose of the sequence diagram however remains the same: an easy-to-read overview of the passing of messages in a particular interaction sequence.

The communication diagram is another way to show one possible scenario for the interaction between a number of related objects. A communication diagram is a directed graph where the nodes denote entities and the edges denote communication between those entities.

Figure 10.13 shows the same sequence of interactions as the scenario depicted in the sequence diagram in Figure 10.12. Communication diagrams emphasize the objects and their relationships relevant to a particular interaction. To provide more detail about the interaction, relevant attributes may be shown inside the nodes (by adding another compartment, as in a class diagram) and these attributes may also be incorporated in the labels of the edges.

Figure 10.13. UML communication diagram: reserving a title

Sequence diagrams emphasize the ordering of messages and sequence numbers are optional; in a communication diagram, sequence numbers are mandatory since the ordering does not show itself graphically.

When designing larger systems, it may be useful to be able to identify entities larger than a single class. This can be done in a component diagram. In software architecture descriptions, for instance, the component diagram is a good way to depict a module view of a system (see Section 11.3).

In essence, a component diagram is a class diagram with the stereotype <<component>>. In UML 1, the component diagram had a special form. In UML 2, this form is often depicted as a small component icon inside the component, as in Figure 10.14. Other than this icon, the component diagram does not introduce any new notation.

Components contain classes or other components. In Figure 10.14 we have modeled Publication as a component containing two classes, called Searching and Storage. Components are connected by interfaces. Figure 10.14 uses the 'ball-and-socket' notation to depict interfaces. Both this notation and the one used in Figure 10.9 are allowed in both class diagrams and component diagrams.

Figure 10.14. UML component diagram

One possible requirements elicitation technique is scenario-based analysis; see also Chapter 9. A scenario is a story which tells how a specific task instance is executed. Often, different scenarios are variations on the same theme. For instance, one scenario may describe the ordinary borrowing of a book, another one may describe borrowing a book when there are still outstanding fines, and so on. A set of scenarios having the same user goal, in this case borrowing, is called a use case.

A use case can be documented in various ways: as narrative text, formally using pre- and postconditions, for example, or graphically as in a state transition diagram. The use-case diagram provides an overview of a set of use cases. Each use case is shown as an ellipse with the name of the use case. The use cases are enclosed by a rectangle denoting the system boundary. An actor that initiates or participates in a scenario is shown as a stick figure with the name of the actor below. Figure 10.15 shows part of the use-case diagram for our library system. Borrowing a book involves two actors: a client and an employee of the library. Many other use cases will involve those two actors as well. The ordering of a new book needs approval of a supervisor, as does the remittance of a fine.

Figure 10.15. UML use case diagram