OOAD - UML Approach of Analysis

---

The Unified Modelling Language (UML) is a graphical language for OOAD that gives a standard way to write a software system’s blueprint. It helps to visualize, specify, construct and document the artifacts of an object oriented system. It is used to depict the structures and the relationships in a complex system.

Brief History

It was developed in 1990s as an amalgamation of several techniques, prominently OOAD technique by Grady Booch, OMT (Object Modelling Technique) by James Rumbaugh and OOSE (Object Oriented Software Engineering) by Ivar Jacobson. UML attempted to standardize semantic models, syntactic notations and diagrams of object oriented analysis and design.

Systems and Models in UML

System : A set of elements which are organized to achieve certain objectives form a system. Systems are often divided into subsystems and described by a set of models.

Model : Model is a simplified, complete and consistent abstraction of a system, created for better understanding of the system.

View : A view is a projection of a system’s model from a specific perspective.

Conceptual Model of UML

The Conceptual Model of UML encompasses three major elements:

• Basic Building Blocks
• Rules
• Common Mechanisms

Basic Building Blocks

The three building blocks of UML are:

• Things
• Relationships
• Diagrams

(a) Things

There are four kinds of things in UML, namely:

• Structural Things : These are the nouns of the UML models representing the static elements that may be either physical or conceptual. The structural things are class, interface, collaboration, use case, active class, components and nodes.

• Behavioural Things : These are the verbs of the UML models representing the dynamic behaviour over time and space. The two types of behavioural things are interaction and state machine.

• Grouping Things : They comprise the organizational parts of the UML models. There is only one kind of grouping thing, namely package.

• Annotational Things: These are the explanations in the UML models representing the comments applied to describe, illuminate or remark about elements.

(b) Relationships

Relationships are the connection between things. The four types of relationships that can be represented in UML are:

• Dependency : This is a semantic relationship between two things such that a change in one thing brings a change in the other. The former is the independent thing while the latter is the dependent thing.

• Association : This is a structural relationship that represents a group of links having common structure and common behaviour. (Refer Section 2.7)

• Generalization : This represents a generalization/specialization relationship in which subclasses inherit structure and behaviour from super classes. (Refer Section 2.6)

• Realization : This is a semantic relationship between two or more classifiers such that one classifier lays down a contract that the other classifiers ensure to abide by or perform.

(c) Diagrams

A diagram is a graphical representation of a system. It comprises of a group of elements generally in the form of a graph. UML includes nine diagrams in all, namely:

• Class Diagram
• Object Diagram
• Use Case Diagram
• Sequence Diagram
• Collaboration Diagram
• State Chart Diagram
• Activity Diagram
• Component Diagram
• Deployment Diagram

Rules

UML has a number of rules so that the models are semantically self-consistent and related to other models in the system harmoniously. UML has semantic rules for the following:

• Names
• Scope
• Visibility
• Integrity
• Execution

Common Mechanisms

UML has four common mechanisms:

• Specifications
• Adornments
• Common Divisions
• Extensibility Mechanisms

Specifications

In UML, behind each graphical notation, there is a textual statement denoting the syntax and semantics. These are the specifications. The specifications provide a semantic backplane that contains all parts of a system and the relationship among the different paths.

Adornments

Each element in UML has unique graphical notation. Besides, there are notations to represent the important aspects of the element like name, scope, visibility etc.

Common Divisions

Object oriented systems can be divided in many ways. The two common ways of division are:

• Division of classes and objects : A class is an abstraction of a group of similar objects. An object is the concrete instance that has actual existence in the system.

• Division of Interface and Implementation : An interface defines the rules for interaction. Implementation is the concrete realization of the rules defined in interface.

Extensibility Mechanisms

UML is an open-ended language, meaning that it is possible to extend the capabilities of the language in a controlled manner to suit the requirements of the system. The extensibility mechanisms are:

• Stereotypes : It extends the vocabulary of the UML, through which new building blocks can be created out of existing ones.

• Tagged Values : It extends the properties of UML building blocks.

• Constraints : It extends the semantics of UML building blocks.

UML Notations

UML defines specific notations for each of the building blocks.

Class

A class is represented by a rectangle having three sections:

• the top section containing name of the class
• the middle section containing class attributes
• the bottom section representing operations of the class

The visibility of the attributes and operations can be represented in the following ways:

• Public : A public member is visible from anywhere in the system. In class diagram it is prefixed by the symbol ‘+’.

• Private : A private member is visible only from within the class. It cannot be accessed from outside the class. A private member is prefixed by the symbol ‘−’.

• Protected : A protected member is visible from within the class and from the subclasses inherited from this class, but not from outside. It is prefixed by the symbol ‘#’.

An abstract class has the class name written in italics.

Example: Let us consider the Circle class introduced in Section 2.1. The attributes of Circle are x-coord, y-coord and radius. The operations are findArea(), findCircumference() and scale(). Let us assume that x-coord and y-coord are private data members, radius is a protected data member and the member functions are public. Figure 6.1 gives the diagrammatic representation of the class.

Object

An object is represented as a rectangle with two sections:

• The top section contains name of the object with the name of the class or package of which it is an instance of. The name takes the following forms:

  • object-name : class-name

  • object-name : class-name :: package-name

  • class-name : in case of anonymous objects

• The bottom section represents the values of the attributes. It takes the form attribute-name = value.

• Sometimes objects are represented using rounded rectangles.

Example : Let us consider an object of the class Circle named as c1. We assume that the center of c1 is at (2, 3) and the radius of c1 is 5. Figure 6.2 shows the object.

Component

A component is a physical and replaceable part of the system that conforms to and provides the realization of a set of interfaces (Rumbaugh et al. in [5]). It represents the physical packaging of elements like classes and interfaces.

Notation : In UML diagrams, a component is represented by a rectangle with tabs as shown in Figure 6.3.

Interface

Interface is a collection of methods of a class or component. It specifies the set of services that may be provided by the class or component.

Notation : Generally, an interface is drawn as a circle together with its name. An interface is almost always attached to the class or component that realizes it. Figure 6.4 gives notation of an interface.

Package

A package is an organized group of elements. A package may contain structural things like classes, components and other packages in it.

Notation : Graphically, a package is represented by a tabbed folder. A package is generally drawn with only its name as in Figure 6.5(a). However it may have additional details about the contents of the package as shown in 6.5(b).

Relationship

The notations for the different types of relationships defined in section 6.1 (i) are as follows:

Usually, elements in a relationship plays specific roles in the relationship. A role name signifies the behaviour of an element participating in a certain context. (Refer Section 2.7 for degree and cardinality ratios)

Example : Figure 6.6 gives examples of different relationships between classes. In Figure 6.6 (a), an association between two classes, Department and Employee is shown, wherein a department may have a number of employees working in it. Worker is the role name. The ‘1’ alongside Department and ‘*’ alongside Employee depict that the cardinality ratio is one–to–many. Figure 6.6 (b) portrays the aggregation relationship, a University is the “whole–of” many Departments. (Refer to section 2.6 for example of generalization)

UML Structural Diagrams

The UML structural diagrams are categorized as follows : class diagram, object diagram, component diagram and deployment diagram.

Class Diagram

A class diagram models the static view of a system. It comprises of the classes, interfaces and collaborations in a system; and the relationships between them.

(a) Class Diagram of a System

Let us consider a simplified Banking System.

A bank has many branches. In each zone, one branch is designated as zonal head office that supervises the other branches in that zone. Each branch can have multiple accounts and loans. An account may be either a savings account or a current account. A customer may open both a savings account and a current account. However, he/she must not have more than one savings account or current account. A customer may also procure loans from the bank.

Figure 6.6 shows the corresponding class diagram

Notes regarding Class Diagram of Simplified Banking System in Figure 6.6

Classes in the system

Bank, Branch, Account, Savings Account, Current Account, Loan and Customer.

Relationships

• A Bank “has–a” number of Branches : composition, one–to–many

• A Branch with role Zonal Head Office supervises other Branches : unary association, one–to-many

• A Branch “has–a” number of accounts : aggregation, one–to–many

• From class Account, two classes have inherited, namely, Savings Account and Current Account.

• A Customer can have one Current Account : association, one–to–one

• A Customer can have one Savings Account : association, one–to–one

• A Branch “has–a” number of Loans : aggregation, one–to–many

• A Customer can take many loans : association, one–to–many

Object Diagram

An object diagram models a group of objects and their links at a point of time. It shows the instances of the things in a class diagram. Object diagram is the static part of an interaction diagram.

Example : Figure 6.7 shows an object diagram of a portion of the class diagram of the Banking System of Figure 6.6.

Component Diagram

Component diagrams show the organization and dependencies among a group of components.

Component diagrams comprise of:

• Components
• Interfaces
• Relationships
• Packages and Subsystems (optional)

(a) Uses of Component Diagrams:

• They are extensively used to construct systems through forward and reverse engineering.

• They are used to model configuration management of source code files while developing a system using an object oriented programming language.

• They are used to represent schemas in modelling databases.

• They also find their usage for modelling behaviours of dynamic systems.

Example

Figure 6.8 shows a component diagram to model a system’s source code, which is developed using C++. It shows four source code files, namely myheader.h, otherheader.h, priority.cpp and other.cpp. Two versions of myheader.h are shown, tracing from the recent version to its ancestor. The file priority.cpp has compilation dependency on other.cpp. The file other.cpp has compilation dependency on otherheader.h.

Deployment Diagram

A deployment diagram focus on the configuration of run time processing nodes and their components that live on them (Rumbaugh et al. in [5]). They are commonly comprised of nodes and dependencies, or associations between the nodes.

(a) Uses of deployment diagrams:

• They are used to model in devices in embedded systems that typically comprise of software intensive collection of hardware.

• They are used to represent the topologies of client/server systems.

• They are used to model fully distributed systems.

Example

Figure 6.9 shows the topology of a computer system that follows client/server architecture. The figure illustrates a node stereotyped as server that comprises of processors. The diagram indicates that four or more servers are deployed to the system. Connected to the server are the client nodes, where each node represents a terminal device like workstation, laptop, scanner or printer. The nodes are represented using icons that clearly depict the real-world equivalent.

UML Behavioural Diagrams

UML behavioural diagrams visualize, specify, construct and document the dynamic aspects of a system (Rumbaugh et al. in [5]). The behavioural diagrams are categorized as follows: use case diagrams, interaction diagrams, state–chart diagrams and activity diagrams.

Use Case Model

(a) Use case

A use case describes the sequence of actions a system performs yielding visible results. It shows the interaction of things outside the system with the system itself. Use cases may be applied to the whole system as well as a part of the system.

(b) Actor

An actor represents the roles that the users of the use cases play. An actor may be a person (e.g. student, customer), a device (e.g. workstation) or another system (e.g. bank, institution).

Figure 6.10 shows the notations of use case and actor. Figure 6.10a shows an actor named Student and a use case Generate Performance Report.

(c) Use case diagrams

Use case diagrams present an outside view of the manner how elements in a system behave and can be used in the context.

Use case diagrams comprise of:

• Use cases
• Actors
• Relationships like dependency, generalization and association

(d) Uses of Use Case Diagram:

• They are used for modelling the context of a system by enclosing all activities of a system within a rectangle and focusing on the actors which lies outside the system and interact with it.

• They are used to model the requirements of a system from the outside point of view.

Example

Let us consider an Automated Trading House System. We assume the following features of the system:

• The trading house has transactions with two types of customers, individual customers and corporate customers.

• Once the customer places an order, it is processed by the sales department and the customer is given the bill.

• The system allows the manager to manage customer accounts and answer any query posted by the customer.

Interaction Diagrams

Interaction diagrams depict interactions of objects and their relationships. They also include the messages passed between them. There are two types of interaction diagrams:

• Sequence Diagrams
• Collaboration Diagrams

(a) Uses of Interaction Diagrams:

• They are used for modelling the flow of control by time ordering using sequence diagrams.

• They are used for modelling the flow of control of organization using collaboration diagrams.

Sequence Diagrams

Sequence diagrams are interaction diagrams that illustrate the ordering of messages according to time.

Notations : These diagrams are in the form of two-dimensional charts. The objects that initiates the interaction are placed on the x–axis. The messages that these objects send and receive are placed along y–axis, in order of increasing time from top to bottom.

Example : A sequence diagram for the Automated Trading House System elaborated in section 6.4 (i) is shown in Figure 6.12.

Collaboration Diagrams

Collaboration diagrams are interaction diagrams that illustrate the structure of the objects that send and receive messages.

Notations : In these diagrams, the objects that participate in the interaction are shown using vertices. The links that connect the objects are used to send and receive messages. The message is shown as a labelled arrow.

Example : Collaboration diagram for Automated Trading House System is illustrated in Figure 6.13.

State–Chart Diagrams

A state–chart diagram shows a state machine that depicts the flow of control of an object from one state to another. A state machine portrays the sequences of states which an object undergoes due to events and their responses to events.

State–Chart Diagrams comprise of:

• States : Simple or Composite
• Transitions between states
• Events causing transitions
• Actions due to the events

(Refer to Chapter 4 for definitions and notations of state, transition, event and action)

Use : To model objects which are reactive in nature.

Example

In the Automated Trading House System (ATHS), let us model Order as an object and trace its sequence.

Figure 6.14 gives the corresponding state–chart diagram.

Activity Diagrams

An activity diagram depicts the flow of activities which are ongoing non-atomic operations in a state machine. Activities result in actions which are atomic operations. (Refer chapter 4 for definitions of activity and action).

Activity diagrams comprise of:

• Activity states and action states
• Transitions
• Objects

(a) Uses of activity diagrams:

• To model workflows as viewed by actors, interacting with the system.
• To model details of operations or computations using flowcharts.

Example

Figure 6.15 shows an activity diagram of a portion of Automated Trading House System