UML Sequence Diagrams

During the requirements analysis phase, the system can be treated as a single "black box", which means that we can look at the system's behavior (what it does) without explaining how it does it. Read this section to see an example of a simplified trace diagram that shows only system input events. This is called a system sequence diagram.

4. Adding Associations in a Conceptual Model

A conceptual model with totally independent concepts only is obviously useless, as objects in different classes must be related to each other so that they can interact and collaborate with each other to carry out processes. In UML, an association is a relationship between two classes that specifies how instances of the classes can be linked together to work together. 

In the same sense that instances of a class are objects, instances of an association are links between objects of the two classes – this is what we meant that objects in the same class "share the same relationships". 

With respect to an association between classes, an important information is about how many objects of one class (say "A") can be associated with one object of another (say "B")n , at a particular moment in time. We use multiplicity to represent this information. An example in Figure 3.9 shows the multiplicity expressions and their meanings.


Figure 3.9: An Example on Multiplicity Use


Some high priority associations useful to include in a conceptual model are: 

  • A is a physical or logical part of B. 
  • A is physically or logically contained in/on B. 
  • A is recorded in B.

From the list of concepts identified, one can start thinking on the possible associations concepts have to each other. This can accelerate the creation of a conceptual diagram. In this way relevant associations will not be forgotten. Figure 3.10 shows possible aggregation relationships of concepts in a POST system.


Figure 3.10: Aggregation Association in POST Application as an example, a conceptual model, or sometimes known as a class diagram for a POST system domain is as shown in Figure 3.11. This has also considered concepts' association: inheritance, aggregation and composition as discussed earlier.


Figure. 3.11: A Conceptual/Class model for the POST System (concepts, associations and Attributes)


Add Attributes in a Conceptual Model Instances of a concept may have some properties. For examples, a Sale can have a date and time; a Payment can have amount, a Furniture can have a size, a Module can have a code, title, and number of credits, a Student has a name, registration number and age, etc. 

An attribute of a class is the abstraction of a single characteristic or a property of entities that have been abstracted as objects of the class. At any given moment of time, the attribute of an individual object in the class is a logical data value representing the corresponding property of the object, and called the value of attribute for the object at that time. One object has exactly one value for each attribute at any given time. Therefore, the value for an attribute of an object may change over time. For examples,

  • time and date are attributes of class Sale, and an instance of Sale can be a sale at 13.30 on 1/10/1998. 
  • code, title, and credit are three attributes of class Module, and an instance of Module can have a code MC 206, title: Software Engineering and System Development, and credit: 20. 
  • name and age are attributes of Student, an individual student can have the name John Smith, and age 19.

Something to note in attributes: 

(a) The attributes in a conceptual model should be simple and clear without ambiguity. Examples of simple attributes are Date, Number, PhoneNumber, Name, Description, Code, Title etc 

(b) In object-oriented approach no foreign keys. Attributes are not be used to relate concepts in the conceptual model, but to store some information about the objects themselves. Liu, (2001) state that the most common violation of this principle is to add a kind of foreign key attribute, as is typically done in relational database designs, in order to associate two types. For example, the currentPOSTNumber attribute in the Cashier type in Figure 3.12 is undesirable because its purpose is to relate the Cashier to a POST object. The better way to express that a Cashier uses a POST is with an association, not with a foreign key attribute Once again 

Relate types with an association, not with an attribute


Figure 3.12: Do not use attributes as foreign keys