At the end of this chapter, you should be familiar with concepts and usage of
Static characteristics of a system. Use of UML static diagrams such as class, object and package diagrams.
Events and States in a system and their role in depicting dynamic behaviour.
Use UML diagram to design the system using OOPS concepts.
While modelling an object, we are interested in two aspects. The first is the structure. When we say structure, we mean it is defined at compile time. We can also call this a static characteristic. For example, when we define a class, it includes attributes, behaviour in terms of attributes, links and associations, and some complex structures such as class within a class definition. We use class diagrams, object diagrams and package diagrams to describe the static characteristics of a system model.
Objects are instances of classes. Classes have attributes and behaviour. We are aware that instances are created at run-time, and these objects have a specific lifetime. They also undergo changes based on messages received during an object's lifetime. Methods or functions, as they are otherwise called, are responsible for an object's behaviour. Attributes hold values that can be changed during the lifetime of an object.
State of an object is defined as current values held by the attributes of an object. It is the result of behavioural changes of an object till that particular instance.
In this chapter, we would concentrate on static and dynamic modelling of object. Firstly we provide over view of UML, a language used for describing the behaviour of objects. We have used class diagrams, object diagrams, package diagrams to describe the static characteristics of a system modelling. We will also introduce dynamic modelling through study of collaboration diagrams, sequence diagrams, activity diagrams, and state transition diagrams etc.
Objects are dynamic entities. They are created at run-time as per the need of the program when the program is under execution. We say an object is instantiated. Constructor does this job of instantiation and also allocates initial values to the attributes of an instance of a class. Objects have attributes and behaviour. An object can communicate with other objects by passing messages. An object passes information about its state to others through get and set functions that are defined in a class. Get functions that return a value of attributes are also called assessors. Set functions that allow attributes to be modified are also called mutators.
Objects in Java use references to uniquely identify the instance of an object, whereas C++ uses pointers and references.
Once the object completes the role assigned to it, it has to be deleted from the memory so that the freed memory can be dynamically allocated to other objects. This is done through garbage collector in Java. Garbage collector is a program initiated by the Java run-time system to remove objects that are no longer required. In C++, programmers can explicitly remove an object through the use of delete function.
The Unified Modelling Language (UML), is used as a graphical tool in object-oriented analysis and design (OOAD) methodology to model a software-based system under development.
When do we resort to modelling?
What do we look in a modelling system?
The UML, founded by a consortium of industries such as Hewlett-Packard (HP), International Business Machines (IBM), Oracle, etc., under the aegis of a controlling group called Object Management Group (OMG), satisfies all the aforementioned criteria and is indeed an industry standard for software development. The UML can be effectively used to conceptualise, modify, construct and deliver an object-oriented software system, including full-fledged documentation.
The term “Unified” in UML implies that UML unifies the theories of three leading scientists at a software company called Rational Software, Grady Booch (Booch methodology), James Rumbaugh (object-modelling technique [OMT]) and Ivar Jacobson (use cases and objectory), into a rational unified process (RUP). Later, RUP was merged with development methodologies such as Booch methodology, OMT and object-oriented software engineering (OOSE).
The UML is a graphical representation of a system under development. In addition, it also contains documentation such as use cases that are used for developing the system. The UML has two different views as described below:
The UML Version 2.2 has 14 diagrams, seven static diagrams and seven behavioural diagrams. Behavioural diagrams include four interaction diagrams.
Structure means the essential things that must be present so that the system can function as per specification. For example, the backbone and jaw are essential in human body to maintain the erect posture and to chew the food. Structure diagrams, as they depict the elements that are present in the system, represent the architecture of the system as shown below:
Behavioural diagrams depict the functionality of the system. The different types of behaviour diagrams are shown:
The classification adopted by UML is shown in Figure 4.1. Class, object and package diagrams depict the structure and static characteristics. Use case diagrams, interaction diagrams, state diagrams and activity diagrams, on the other hand, depict behavioural modelling. In Chapter 2, we have dealt in detail with structure. In the following sections, we discuss dynamic behaviour.
We want to produce a system that the user wants. Once the system is produced, users interact with it to produce the desired result. So we need some description on how to go about it. Use cases typically provide such description. Use cases describe what the system does from the point of view of an external user. They provide a sequence of steps describing the interaction between the system and the user. This sequence of steps is called a scenario.
For example, for an automated library information system in a college, a scenario could be as follows (Fig. 4.2): A student browses online the catalogue of books available in the library and selects the accession number of the book he or she wishes to borrow from the library. The issue subsection of the automated system checks the entitlement of the student and confirms the issue of the book to the student. The system issues an authorization slip to the issue gate by email. The student carries the book to the issue gate, where the in-charge affixes the authorization slip on the inside-cover page.
Figure 4.2 Use cases in an issue section of a library system
A second scenario can be that authorization fails because the student has exceeded the limit of borrowing.
A third scenario could be that a student has failed the identification checks.
There are three scenarios described for borrowing a book from the library; but the goal of the student in all three scenarios is the same, i.e. borrowing a book. So, we can now say that a use case is a collection of different scenarios but with a common goal.
In a use case, we call users as actors. An actor can be a human being, a device, or a software module. For example, banking software system manager, customer, smoke sensor and software agent working in the background are all actors. A use case can have several actors and conversely one actor can use several use cases. An actor is shown as a stick and a use case as an oval. The UML has a use case diagram that shows how use cases are related to each other.
As a second example consider the case of a student enrolling for a third semester course.
The actors and use cases involved in this example are shown in Figure 4.3.
Use cases explain functional requirements of a system under study. Each use case is required to be described in detail before implementing. A scenario explaining the step-by-step procedure of how the user gets what he or she wants out of a system is given below:
Gautam enrols for third semester course. A step-by-step procedure in shown below:
Each use case will have a primary actor that calls on the use case to deliver the functionality expected. A use case can have another use case defined inside. Each step in a use case is an interaction between the actor and the system. In addition, each use case can have preconditions, a guaranteed result, and also a trigger that sets the use case into action.
In any real-world problem, we have users and their wants and needs. Accordingly, we define objects and their interactions, i.e. we decide architecture. Users’ world is called Domain.
We have users of the system and use cases. We have classes in the software we are developing. Classes are a reflection of the real-world client (users) and what they want (use cases). Based on clients and their real-world interactions, we define interaction between objects and classes as links and associations to deliver functionality. This arrangement is termed as architecture.
We can define architecture as a depiction of objects and their attributes together with the operations these objects perform to meet user specifications or needs.
The clients and their interactions exist in the real world. Class is a conceptual model that maps real-world problems to software. The users’ world is called domain.
We will show the users domain and our architecture as a collection of square boxes that contain names of the objects (Fig. 4.4). We will also show their links and associations by drawing interconnecting lines. As we have studied in Chapter 2, we can also amplify by specifying role names and multiplicities. In Example 4.2, we consider domain and architecture of a college.
Figure 4.4 Domain and architecture diagram for a college
The square boxes you see are called entities. For a complex project, attributes of each entity is maintained in a table. This table is called a data dictionary. Before the advent of the objectoriented programming paradigm, these diagrams were also called entity-relation diagrams.
In order to get an insight into which object does what, it is advisable to list out the sequence of steps for the entire process. Let us revisit the overall sequence of operations for the registration process we have discussed in Example 4.1, with amplification shown to registration process as shown below:
3.1 Add a course.
3.2 Delete the course already added (update).
Then for each step in this sequence of steps, we can prepare a sequence diagram or a communication diagram and/or timing diagram. What each object does is an important issue for the user. UML provides sequence diagram and communication diagrams to solve this issue. Timing diagram is a variation of the sequence diagram that specifies against time base.
Users are represented by stick figure. Each object is represented by a square box (object representation). A vertical line is drawn from each object to represent the activity base line. Arrows emanating from each vertical line show the object sending a message or calling a function belonging to some other object.
In Figure 4.5, we show the sequence diagram. The actor understudy is a third-year student. The course coordinator would like to drop or delete Gautam's name from section K. The sequence of activities is as follows:
Figure 4.5 Sequence diagram for deleting a name from registration process
Earlier, communication diagrams were known as collaboration diagrams. These are essentially the same as sequence diagrams except in the case of communication diagrams. The time of occurence of messager, called time ordering, is shown explicitly by numbering the messages as shown in Figure 4.6. Each message in a collaboration diagram has a sequence number. The top-level message is numbered 1. Messages at the same level (sent during the same call) have the same decimal prefix but different suffixes of 1, 2, etc., according to when they occur.
The key elements of a communication diagram are
In order to read the collaboration diagram, simply start at the message numbered as 1 and follow numbers. In Figure 4.6, we have used a simple numbering scheme. However, UML uses a nested numbering system such as
Simple numbering scheme: 1, 2, 3, 4, …
Nested UML numbering: 1, 1.1, 1.1.1, 1.1.2, …
Collaboration diagrams convey the same information as sequence diagrams; but they focus on object roles instead of the times that messages are sent.
Class diagrams are static in nature and depict the links and associations between classes. They cannot be used to depict the behaviour of objects during objects’ lifetime.
Objects have behaviour and state. The state of an object is defined by current values of attributes. We have further learnt that access specifiers like getters and setters can change the values of attributes. We can say that some events trigger the process of changing the values of attributes and thereby change the state of an object.
Note that a state diagram describes behaviour of class objects. Therefore, all objects share a single state diagram. But the path object follows in the state diagram is specific to an instance of the object.
The state chart notation has been developed in computer science as part of theory of automatic machines called the automata theory. This science has been adopted by UML to depict the way in which an object changes. Each change in behaviour is modelled as a change in state.
A state diagram represents events and states. When an event occurs, transition to the next state depends on current state and event. The state diagram shows these changes in states and allows changes that cause the change of state. As an example let us see how a student enrols in a college. The state diagram is shown in Figure 4.7.
Figure 4.7b Student undergoing UG/PG courses
In a state diagram, observe that start and stop are shown as black blobs. Each state is shown as a rectangle with rounded corners. Change in state means that the object has changed its behaviour. For example, a student when he or she undergoes the undergraduate (UG) course, i.e., first- to fourth-year courses, and qualifies, then he or she becomes a UG. A student can enrol either for UG course or directly for an integrated postgraduate (PG) course. Each arrow represents a change.
We can add a lot of additional information on the state chart diagram:
We are now ready to define a dynamic model as a collection of all state diagrams that interact with each other with interacting events.
In online banking, there are the following distinct states:
From each state, transactions emerge. Transactions are shown as arrows going from one state to another state. Events that trigger transition from one state to another are shown next to the arrows. In Figure 4.8, in our system we have two self-transitions that occur when the user enters invalid username or password. Till user does not enter tab key or enter key the cursor remains and dot is displayed to maintain secrecy of data being entered.
Figure 4.8 State diagram for Internet banking
The Internet banking system obtains user id and Internet password and validates them. If they are found to be correct, user can enter transaction details. The system, as a double safety measure, asks for user id and transaction password. These entries are also subjected to validation. If they are found to be correct, final state is reached wherein user can attend to his or her transaction or it is rejected.
The start and stop are shown as black circles and are dummy states. Each state can have an action. The object performs the action, and as a result of this action the object can change its state.
States perform activities. It can be a single activity or a sequence of activities. The notation used is “Do X1”. If a state has “Do X1” mentioned in rectangular box, it means that on entry it will do activity X1.
On the other hand, an action signifies immediate operation. Operations are indicated with a “/”. For example, we have shown / Display Dot as operation in the Internet banking example in Figure 4.8.
Action can also be used to generate other events. For example, from an idle state, by right clicking the mouse button, we can generate a help menu. On release, the help menu can be removed. The state diagram is shown in Figure 4.9.
Figure 4.9 Example of internal actions
We have learnt that states perform activities. Activities can be broken down into subactivities. Now, if each subactivity represents a state, we can say state is a collection of substates and we can call the structure as a nested state diagram.
As an example, consider the cool-drink vending machine installed at your campus. The main activities involved in obtaining a cool drink from the machine are as follows:
The vending machine model is presented in Figure 4.10. The main states shown are as follows:
The state diagram contains an activity called dispense item and an event called select cool drink. We will expand and show these two through nested state diagrams. Figures 4.11a and 4.11b show nested state diagrams.
Figure 4.11a Expanded state diagram for the event select item
Figure 4.11b Expanded state diagram for dispense item
For selecting an item from an available list of cool drinks, user has to enter the identification number for the cool drink selected. He or she will have the option of cancelling the entry and re-entering the number. On pressing ENTER, the item gets selected and is registered for dispensing.
A state chart diagram tells us about an object undergoing a process. An activity diagram shows the flow of activities in a single process. It shows the way in which each activity is dependent on other activities. Therefore, we can define activity as a diagram showing the flow of activities and their interdependence on one another.
For explaining the concept of activity diagram, we choose the same example of interbank money transfer through the Internet as in Example 4.3.
The classes involved in the case of interbank money transfer through the Internet are user, client computer system and bank. The activities concerning each class are shown as rounded rectangles in a separate column called swim lane. The salient features of an activity diagram are as follows:
Example 4.4: Activity diagram for online Internet banking
In money transfer using online banking, the activities involved are shown below:
The activity diagram in Figure 4.12 is self-explanatory and follows the list of activities described above. There are two lanes, one for bank server and another for client machine.
White diamond is used to indicate branching, and guard expressions are enclosed in [].
A thick line is used to indicate fork, i.e., to initiate more than one activity such as debit account as well as transfer amount. Same symbol is used for join activity also.
You are familiar with files and folders. In order to organize your work, you open folders and within folders you store files. Package is like a folder. We can store all our classes in this folder called package directly. If the number of classes is very large, then classes can be grouped into components and components into packages (Fig. 4.13).
Components contain classes. They provide pluggable interfaces to users. We will use plug and socket concept to denote an interface. For example, in Figure 4.14, Application module provides interface to students’ module.
Figure 4.14 Notation for components
If we code the classes in components, then these coded classes are called artefacts. Artefacts is the name given by UML to files. There can be several file types. For example, source code, library file called .h file in C++ notation, executable file. Figure 4.15 makes the concept clear. Here, we show a source called Student.cpp and a library called Student.h and corresponding object modules with extension .obj. The standard artefacts used are the following: <<executable>>, <<document>>, <<file>>, <<library>>, <<script>> and <<source>>.
Figure 4.15 Components (artefacts) in a project
In Figure 4.16, we show how packages are interconnected with dependencies. Dotted arrows show dependencies of a package on other packages.
Deployment diagrams depict the physical configuration of software and hardware. We are aware that in object-oriented technology, class diagrams depict the structure of the application and interactions among them through various relationships such as inheritance.
We are further aware that class contains member functions that contain all the code modules required to achieve functionality.
A component is defined as code module. An application such as online shopping contains several components. An application will have a user interface.
Hardware is a collection of nodes. Components reside on the nodes.
Remote nodes are interconnected using networking hardware such as transmission control protocol (TCP)/Internet protocol (IP).
Thus, there is a need to group all the above in a single diagram, which is called a component and deployment diagram, which is shown in Figure 4.17.
Figure 4.17 Component and deployment diagram for online
18.224.59.192