• 4.1 Classic Modeling Techniques
  • 4.1.1 Entity-Relationship Modeling
  • 4.1.2 Finite State Machines
  • 4.1.3 Data Flow Diagrams
  • 4.1.4 Class-Responsibility-Collaborators Cards
• 4.2 The Unified Modeling Language
  • 4.2.1 The Use Case diagram
  • 4.2.2 The Class Diagram
  • 4.2.3 The State Machine Diagram
  • 4.2.4 The Sequence Diagram
  • 4.2.5 The Communication Diagram
  • 4.2.6 The Component Diagram

4.1 Classic Modeling Techniques

We discuss four classic modeling techniques that have been around for quite a while:

• Entity-Relationship Modeling (ERM) is a data modeling technique. UML class diagrams are based on ERM.
• Finite State Machines (FSM) are used to model states and state transitions. In the early days, certain types of formal languages, as for instance used in compilers, were modeled as finite state machines. UML state machine diagrams are based on finite state machines.
• Data Flow Diagrams (DFD) model a system as a set of processes and data flows that connect these processes. It is the notation used in data flow design. DFDs resemble the UML sequence diagram.
• CRC (Class-Responsibility-Collaborators) cards are a simple requirements elicitation tool. Much of the information collected on CRC-cards can also be represented in UML communication diagrams.

This techniques can be divided according to notation that use (fig.4.1). The Integration DEFinition (IDEF) is a family of modeling languages in the field of systems and software engineering. IDEF notation cover a wide range of uses, from functional modeling to data, simulation, object-oriented analysis/design and knowledge acquisition. 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. 

During requirements engineering and design, a variety of modeling notations are being applied. Most of these use some sort of box-and-line diagram. The mainstream software systems modeling notations of today stem from UML. 

Many other classic modeling notations exist. Many of these are tied to a certain analysis or design method.

4.1.1 Entity-Relationship Modeling

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 UoD.

In mid 1970th  Peter Chen developed entity–relationship modeling for database design. Entity-relationship modeling (ERM) 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 (for example, Crow's foot notation, IDEF1X notation, Bachman notation,  Barker–Ellis notation), which differ in their graphical notations and extensions to Chen’s original approach. The basic ingredients of ERM are given in table 4.1.

Term Meaning

Table 4.1  - ERM concepts and their meaning

Entety	distinguichable object of some type
Entety type	type of a set of enteties
Attribute value	partial description of an entety
Attribute	type of a set of attribute values
Relationship	association between two or more entities

An entity is a ‘thing’ that can be uniquely identified. Entities are usually depicted in an ERD as rectangles.

Entities have properties known as attributes. 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.

Entities are linked through relationships. 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.

An example entity-relationship diagram for loan a book in a library is given in figure 4.2. 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 10 book copies.

 

An Entity-relationship modeling can be obtained using any of the elicitation techniques discussed in Unit 3. 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.

An 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.

An 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 includes many elements from ERM.

4.1.2 Finite State Machines

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 (STD). 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. The final state is the one labeled ‘written off’. Any of the others could be designated as the initial state.

Figure 4.3 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.

A state transition diagram models only a tiny part of the modelling system. It does not describe the complete state of the system in any one bubble, nor does it depict all possiblestate transitions. Modeling a system in one, large and 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 these 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 in the state machine diagram.

 

4.1.3 Data Flow Diagrams

The data flow design method originated in the early 1970s with Yourdon and Constantine. In its simplest form, data flow design is 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 (DFD).

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

• External entities are the source or destination of a transaction. These entities are located outside the domain considered in the data flow diagram. External entities are indicated as squares.
• Processes transform data. Processes are denoted by circles.
• Data flows between processes, external entities and data stores. A data flow is indicated by an arrow. Data flows are paths along which data structures travel.
• Data stores lie between two processes. This is indicated by the name of the data store between two parallel lines. Data stores are places where data structures are stored until needed.

Data flow diagrams result from a top-down decomposition process. The process at the highest level has one process only, denoting ‘the system’. Next, this top-level diagram is further decomposed.

The design method mostly used in conjunction with data flow diagrams.

 

4.1.4 Class-Responsibility-Collaborators Cards

A Class-Responsibility-Collaborators (CRC) card is simply a index card with three fields labeled Class, Responsibility and Collaborators (see example in fig.4.5). CRC cards were developed in response to a need to document collaborative design decisions by Kent Beck and Ward Cunningham. CRC cards are especially helpful in the early phases of software development, to help identify components, discuss design issues in multidisciplinary 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.

 

4.2 The Unified Modeling Language

The Unified Modeling Language has its roots in the object-oriented analysis and design methods of the 1980s. Several key players in this field (Grady Booch, John Rumbaugh and Ivar Jacobson) came to work for Rational, and started to unify their methods and notations. This resulted in the first versions of UML. At a later stage, OMG - the Object Management Group, an open consortium of companies - took over. They now control the activities around UML, and adopted it as one of their standards. The current version is known as UML 2.5. UML is by far the most widely used notation for both requirements engineering and design.

Many UML diagrams in turn are based on or derived from earlier types of diagram. This notation evolved from earlier object-oriented analysis and design methods. Concepts used in UML, such as object, attribute, class, relationship, originate in the field of object orientation. The 13 diagrams of UML 2 are listed in figure 4.6. Some diagrams, such as the class diagram and the state machine diagram, have been there since the beginning of object orientation. Others are more recent. For example, the composite structure diagram and the timing diagram were introduced in UML 2. Some of the diagrams give a static view. For instance, a class diagram shows the static structure of a system. Other diagrams give a dynamic, or behavioral view, i.e. they show what happens when the system is executed. For instance, a sequence diagram shows which messages are exchanged between instances of classes.

1.        b. 

 

4.2.1 The Use Case diagram

One possible requirements elicitation technique is scenario-based analysis (see Unit 3). 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 is called a use case (UC). In this case borrowing scenario is 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 4.7 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.

4.2.2 The Class Diagram

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 relationships can be modeled. These relationships fall into two classes: generalizations and associations.

The most common example of a generalization-type class diagram is a diagram depicting the subclass-superclass hierarchy. Figure 4.8 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:

• the name of the class,
• the list of attributes of the class, and
• the list of operations of the class.

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 4.8 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.

The hollow triangle in figure 4.8 indicates that the structure is a generalization/specialization 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 4.8.

The attributes of a class denote properties of that class. E.g., publisher is a property of Publication. Next to attributes, UML has another way of defining properties of a class - 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 4.8a. 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 4.8a it is added multiplicity information: a client can be a member of one or more libraries, while a library may have zero or more clients. Strictly speaking, there is no difference between an attribute and an association. In figure 4.8b, 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 Membership has association properties. In UML, this model element is termed association class. It can be depicted as a class symbol attached by a dashed line to an association path, as in figure 4.8c. We may even promote an association clas to a full class, as in fig.4.8d. 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 relation 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 readings for certain courses, then a given book may be a part of more than one required reading list. Aggregation is denoted with an open filed diamond as 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 4.10a. 

Figure 4.10a 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 4.10b.

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 only include important dependencies. Many types of dependencies need not be modeled by hand, but can be derived from the source code, and tools exist that do so.

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 like LinkedList and ArrayList.

The abstract class List may have abstract operations as well, 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 to split 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 different other classes in the system. Publication then provides different interfaces to different client classes, who in turn require the interface. Interfaces are marked with the keyword interface, as in figure 4.11. Interfaces are often used to increase the robustness of a model, by restricting access to properties really needed.

 

4.2.3 The State Machine Diagram

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.

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

• In the classical finite state machine model, states do not have local variables. All necessary information is coded in the state. This easily leads to unwieldy models. For instance, suppose we want to model an object LibraryMember as follows: a person may become a member of the library, borrow up to 10 books, and cease to be a member of the library. This leads to a finite state machine with states like has-borrowed-0-books, has-borrowed-1-book, has-borrowed-2-books, . . . , has-borrowed-10-books. If the number of books on loan could be modeled as a local variable, the number of states in the model would be reduced from 12 to 2. For this reason, the finite state machine is usually extended by adding local variables to the model. A state in this extended finite state machine then comprises both the explicit state represented by a node in the state transition diagram and the value of the model’s variables. These local variables are not only used to decrease the number of states. State transitions may now also change the values of variables; the variables may be tested to determine the next state and transitions may be guarded by the value of the variables. In figure 4.11, the number of books on loan is kept in the local variable N. This variable is initialized to zero, updated when a book is borrowed or returned, and tested when a person terminates his membership.
• The components being modeled interact with the environment: there are input events and output actions. In all modeling methods that we know of, input events trigger transitions. When a person becomes a member of the library, this triggers the initial transition; when she borrows a book, it triggers a transition from a state, say, has-borrowed-7-books to a state has-borrowed-8-books. If the model has local variables, the latter state transition may result in a change in the value of such a local variable. In figure 4.12, the input events are denoted as strings that label state transitions (like Start and Borrow).

Different modeling methods have different ways to handle output actions. Sometimes, output actions are associated with a transition (this is known as a Mealy machine), sometimes output actions are associated with a state (a Moore machine). In the latter case, the output action is carried out as soon as the state is entered. In a formal sense, Mealy machines and Moore machines have the same expressive power.

Finite state diagrams may become unwieldy. Therefore, one may add some structure, through a hierarchy. Part of the model may be compressed into one state. If we are interested in the details of a state, we may ‘zoom in’ on that state.

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 state machine diagram.

As with class diagrams, UML has a rich notation for state diagrams. We will illustrate the major ingredients through a few examples; see also figures 4.12 and 4.13.

A state is some condition in the life of an object. It is shown as a rectangle with rounded corners. An initial 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 state is shown as a small 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 triggersignature 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 4.12 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 4.13 gives an example of nested states. Figure 4.13a 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 4.13b, 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 ’ . 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 4.132a, 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.

 

4.2.4 The Sequence Diagram

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 on type of interaction diagram. A second type of interaction diagram is the communication diagram. In the telecommunications domain, sequence diagrams are known as Message Sequence Charts and 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 4.14. 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 4.14 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.

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.

 

4.2.5 The Communication Diagram

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 4.15 shows the same sequence of interactions as the scenario depicted in the sequence diagram in figure 4.14. 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 be incorporated in the labels of the edges as well.

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

 

4.2.6 The Component Diagram

When designing large systems, it may be useful to be able to identify entities larger than a single class. Such 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.

In essence, a component diagram is a class diagram with the stereotype <component>. Components contain classes, or other components. In figure 4.16 we have modeled Publication as a component containing two classes, called Searching and Storage. Components are connected by interfaces.

Figure 4.10 uses the so-called ball-and-socket notation to depict interfaces. Both this notation and the one used in figure 4.16 are allowed in both class diagrams and component diagrams