1. CONTENTS Object-Oriented Modeling Using UML
Introduction to OO & D with UML
Object-Oriented Modeling Using UML
Applying UML in Software Development.

2. Chapter 3: Applying UML in Software Development
Subject/Topic/Focus:
Case Study of a Point of Sale System
Summary:
Use Cases
Class Diagrams
Interaction Diagrams
Design of class Diagram
Implementing a Design

3. Point-of-Sale Terminal
3.1. Case Study: POST
Point-of-Sale Terminal
A point-of-sale terminal (POST) system is a computerized system used to record sales and handle payments.
It is typically used in a retail store.
It includes hardware components, i.e., a computer, a bar code scanner and software to run the system.
The POST application is representative for many information systems and touches upon common problems, developers may encounter.
This case study demonstrates an iterative incremental process, covering the analysis and design phases.
OOA&D with UML

4. 3.2. Overview of the project
During the inception phase the basic requirements of the development process are defined.
Overview statement:
The purpose of this project is to create a POST system to be used in retail sales.
Goal:
The general goal is to increase checkout automation, to support faster, better and cheaper services and business processes.
• Quick checkout for the customer.
• Fast and accurate sales analysis.
• Automatic inventory control.
OOA&D with UML

5. 3.11. Design Class Diagrams Details
During the creation of a collaboration diagram, we record the methods corresponding to the responsibilities assigned to a class in the third section of the class box.
These classes with methods are software classes representing the conceptual classes in the conceptual models.
Then based on these identified software classes, the collaboration diagrams and the original conceptual model, we can create a design class diagram which illustrate the following information:
classes, associations and attributes
methods,
types of attributes
navigability
dependencies
OOA&D with UML

6. 3.11. Design Class Diagrams Details
Based on the above discussion, we have
OOA&D with UML

7. 3.11.1. Add dependency relationships
Apart from the attribute visibility, there are the other three kinds of visibility: parameter visibility, locally declared visibility, and global visibility. For examples:
1. The POST software object receives a returned object of type ProductSpecication from the specifi-cation message it sent to a ProductCatalog. Thus, POST has a short-term locally declared visibility to the ProductSpecication.
2. The Sale receives a ProductSpecication as a parameter in the makeLineItem message; it has parameter visibility to a ProductSpecication.
A non-attribute visibility may be illustrated with a dashed arrowed line indicating a dependency relationship from the source class to the target class.
OOA&D with UML

8. 3.11.1. Add dependency relationships
Design diagram with association and navigability
OOA&D with UML

9. Generalisation
The concepts CashPayment, CreditPayment, and CheckPayment are all very similar. A Sale can be paid by any of these methods of payment. A partial class diagram modeling this is given in following
OOA&D with UML

10. Generalisation
There are the following problems with the model:
1. There are too many distinct association (though they have the same name), one between each payment method and the Sale.
2. The multiplicities in the model do not correctly capture the fact that a Sale is paid by one and only one of the payment methods; and an instance of a Payment of any kind is to pay a Sale instance.
3. If a new kind of payment were introduced, a new association would also have to be added to the model.
4. The model does not explicitly show the similarities of the three concepts of payment methods which probably have a large amount of common structure.
These problems can be overcome by making use of the notion of generalization. Generalization is the activity of identifying commonality among concepts and defining supertype and subtype relationships.
In a generalization-specialization relationship, one class is identified as a ‘general’ class and a number of others as ‘specializations’ of it.
OOA&D with UML

11. 3.11.2. Generalisation 2. 100% Rule attributes associations
1. Is-a-Rule
If we define a class as a set of objects, then subtypes and supertypes are related in terms of set membership:
All members of a subtype set are members of their supertype set:
SubtypeSet  SupertypeSet
This is also termed as the Is-a-Rule for testing a correct subtype:
Subtype is a Supertype
2. 100% Rule
In general, this rule of inheritance from (conformance to) a supertype is the Rule:
100% of the supertype’s definition should be applicable to the subtype. The subtype must conform to 100% of the supertypes’s:
attributes
associations
OOA&D with UML

12. 3.11.2. Generalisation When to define a subtype
A type partition is a division of a type into disjoint subtypes. When is it useful to show a type partition?
The following are strong motivations to partition a type into subtypes:
1. The subtypes have additional attributes of interest.
2. The subtypes have additional associations of interest.
3. The subtype concept is operated upon, handled, reacted to or manipulated differently than the supertype or other subtypes, in ways that are of interest.
4. The subtype concept represents an animate thing (for example, animal, robot) that behaves differently than the supertype or other subtypes, in ways that are of interest.
In a design class diagram, in addition to adding new features to a subclass, it sometimes happens that a class requires a customized version of a method (operation) that it has inherited from its superclass.
OOA&D with UML

13. Generalisation
The subtypes of payment have additional associations that are of interest.
OOA&D with UML

14. 3.12. Implementing a Design
The notion of the interface of a class and its features
Definition of a class in a programming language
Definition of a method of a class in a programming language.
OOA&D with UML

15. 3.12.1. Notation for Class Interface Details
The interface of a class primarily consists of the declarations of all the methods (or operations) applicable to instances of this class, but it may also include the declaration of other classes, constants, variables
(attributes), and initial values.
The implementation of a class primarily consists of the definitions of all the methods (or the implementation of all the operations) declared
in the interface of the class.
The interface of a class can be in general divided into three parts
Public: A declaration that is accessible to all the clients which are the classes that have attribute visibility to this class.
Protected: A declaration that is accessible only to the class itself, its subclasses, and its friends1.
Private: A declaration that is accessible only to the class itself and its friends.
OOA&D with UML

16. 3.12.2. Mapping a Design to Code
Add reference attributes
A reference attribute is an attribute that refers to another complex object, not to a primitive type such as a String, Number, and so on.
The reference attribute of a class are suggested by the associations and navigability in a design class diagram.
For example, a SalesLineItem has an association to a ProductSpecication, and with navigability to it.
This navigability is needed for sending the message price to the ProductSpecication from the SalesLineItem in the collaboration diagram for total of the Sale.
Sometimes, if a role name for an association is present in a class diagram, we can use it as the basis for the name of the reference attribute during code generation. The Java definition of the class SalesLineItem with a reference attribute prodSpec as following
OOA&D with UML

17. 3.12.2. Mapping a Design to Code
OOA&D with UML

18. 3.12.2. Mapping a Design to Code
In the same way, we can define the Java class for POST.
OOA&D with UML

19. 3.12.3. Defining a method from a collaboration diagram
A collaboration diagram shows the messages that are sent in response to a method invocation. The sequence of these messages translates to a series of statements in a method definition.
For example, consider the collaboration diagram for the enterItem operation given in following
OOA&D with UML

20. 3.12.3. Defining a method from a collaboration diagram
We have to look at the messages sent by POST in response to the message enterItem received by POST.
Message 1: According to the collaboration diagram, in response to the enterItem message, the first statement is to conditionally create a new Sale.
if (isNewSale()) { sale = new Sale(); }
Message 2: The second message sent by the POST is specication to the the ProductCatalog to retrieve a ProductSpecication.
ProductSpecification spec = prodCatalog.specification(upc);
Message 3: The third message sent by POST is the makeLineItem to the Sale:
sale.makeLineItem(spec, qty);
In summary, each sequenced message within a method, as shown on the collaboration diagram, is mapped to a statement in the Java method.
OOA&D with UML

21. 3.12.3. Defining a method from a collaboration diagram
Therefore, the complete enterItem of POST method is given as:
public void enterItem(int upc, int qty) {
if (isNewsale()){sale=new Sale();}
ProductSpecification spec = prodCatalog.specification(upc);
sale.makeLineItem(spec,qty); }
OOA&D with UML

22. 3.12.4. Container/collection classes in code
It is often necessary for an object to maintain visibility to a group of other objects; the need for this is usually evident from the multiplicity value in a class diagram – it may be greater than one. For example, a Sale must maintain visibility to a group of SalesLineItem instances, as shown in following figure
OOA&D with UML

23. 3.12.4. Container/collection classes in code
The choice of a container class is influenced by the requirements; key-based lookup requires the use of a Hashtable, a growing ordered list requires a Vector , and so on.
With these discussions, we can now define the makeLineItem method of the Sale class as shown in figure
OOA&D with UML

24. 3.13. Packages: Organizing Elements
The conceptual model for development cycle two of the POST application is approaching an unwieldy size; it indicates the need to partition the model elements into smaller subsets.
How to partition the conceptual model into packages
To partition the conceptual model into packages, place elements together that:
are in the same subject area–closely related by concept and purpose
are in a generalization-specialization hierarchy together
participate in the same use cases
are strongly associated.
OOA&D with UML

25. 3.13. Packages: Organizing Elements
POST conceptual model packages
This section gives a package organization for the POST application.
OOA&D with UML

26. 3.13. Packages: Organizing Elements
OOA&D with UML

27. 3.13. Packages: Organizing Elements
OOA&D with UML

28. 3.13. Packages: Organizing Elements
OOA&D with UML

29. 3.13. Packages: Organizing Elements
OOA&D with UML

30. 3.13. Packages: Organizing Elements
OOA&D with UML

31. 3.14. Exercises
Use Case (Look up the use case description in the Rational Rose)
Open the Use Case View. Draw Use Case diagram to model the actors and use cases given on figure 1. For each actor and use case add a short textual description. For use cases also attach a text file with a more elaborated description.
Then add the relationships (involved in, uses, extends) to the diagram.
Note: "is involved in" is implemented as "Unidirectional association" (from actor to use case) by the tool <<uses>> and <<extends>> are both implemented as "Generalization" plus a stereotype in the specification
Annotate your diagram by comments that are attached to actors, use cases, and relationships.
OOA&D with UML

32. 3.14. Exercises
Figure 1
OOA&D with UML

33. 3.14. Exercises
Figure 2
(Result)
OOA&D with UML

34. 3.14. Exercises 3.14.1 Classe Diagram
1. Model the diagram shown on this figure 3 with Rational Rose. Use the correct semantic entities for names, attributes, types, operations etc.
Class-Diagrams belong to the Logical View.
Double-Click on a class, attribute, operation, or association (or right mouse button over the selected element and "Open Specification") will bring you to the specification of the class, attribute, ...
In the specification tabs for attributes and operations you may insert a new attribute or operation using the right mouse button.
For types of attributes there is a special column in the attribute specification.
The multiplicity of associations is set by the the tabs "Role A/B Detail" using the field "Cardinality".
You may draw an inheritance relationship between classes or between a class and an existing inheritance relationship (these relationships are then connected together).
Use "Note" for the comment. Use no other notes!
If some elements are not shown in the diagram, check the visibility (select and right mouse button) and rearrange the elements in the diagram.
OOA&D with UML

35. 3.14. Exercises
Figure 3.
OOA&D with UML

36. 3.14. Exercises 3.14.2 Classe Diagram
2. Draw a class diagram for the following Java code:
class Account {
public String PIN;
public String name;
public int balance = 0; }
interface CardUse {
public int read(String PIN);
public void reduceBy(int amount, String PIN); }
class BankCard implements CardUse {
private int usage = 0;
private String owner;
private Bank bank;
public int read(String PIN) {...}
public void reduceBy(int amount, String PIN) {...} }
class Bank {
private Account [] accounts = new Account [10];
private int number = 0;
private Account findAccount(String name, String PIN) {...}
public int getBalance(String PIN, String name) { ... }
public String createAccount(String name, int startAmount) { ... }
public CardUse getBankCard(String name, String PIN) { ... } }
OOA&D with UML

37. 3.14. Exercises 3.14.2 Classe Diagram (Continue)
Initial values may be given in the attribute specification.
Check the visibility! It is represented by different icons in Rational Rose.
An interface is modeled by a class with a stereotype "interface" (set "Show Sterotype" for the class). Its implementation is a special inheritance relationship.
Attributes in Java may become associations in UML (e.g., BankCard.bank, Bank.accounts).
The use of a class in an operation signature (e.g., Bank.getBankCard) introduces a dependency relationship (e.g., Bank is dependent on CardUse).
3. Implement the class diagram of exercise 1 above using Java.
OOA&D with UML

38. 3.14. Exercises 3.14.3 Interaction Diagrams
Model the sequence diagram shown on this following figure with Rational Rose.
OOA&D with UML

39. 3.14. Exercises 3.14.3 Interaction Diagrams (Continue)
2. Model the collaboration diagram shown on this following figure with Rational Rose. Describe (textually) the situation shown in the diagram.
OOA&D with UML

40. 3.14. Exercises 3.14.3 Interaction Diagrams (Continue)
Draw an interaction (sequence) diagram that captures the following scenario. Use the actors, classes and methods shown in this following figure.
“Packets (i.e., their descriptions) are created by a clerk. Packets know where (to which location) they are sent. The clerk asks the transport coordinator for a transport for that packet. The transport coordinator looks for a transport that does visit the target location of the packet. If he does not find such a transport, he creates a new transport and schedules it for that location. He loads the packet onto that transport.”
OOA&D with UML

41. 3.14. Exercises 3.14.4 State Diagrams
Model the state diagram of class OrderDelivery shown on this following figure with Rational Rose.
OOA&D with UML

42. 3.14. Exercises 3.14.4 State Diagrams (Continue)
Given the following behavior description of the class Transport, draw a state diagram capturing the behavior of Transport. Use states, events, nesting & concurrency, conditions, sending of messages. Use the methods (i.e., messages and events) shown on this following figure.
“A transport is responsible for transporting packets from one location to another. Each transport has a maximum capacity of packets he can transport. The number of actually loaded packets may not be greater than this capacity. So packets may only loaded if the capacity has not been reached. In parallel to the loading of packets a transport is scheduled for a target location. The target location may be changed (re-scheduled) until the transport starts its journey. The transport may start its journey only if it has been scheduled. The loading stops when the transport starts its journey. When the transport reaches its target location, the unloading begins. All packets that are addressed to this location are delivered to a local dispatcher. Then the transport waits again for loading and scheduling.”
OOA&D with UML

43. 3.14. Exercises 3.14.5 Package Diagrams
Model the following Java packages and classes using UML (classes, packages, dependencies).
package application.utilities;
public class DatabaseManager { ... }
public class MailManager { ... }  
package application.database;
import application.utilities.DatabaseManager;
public class Customer { ... }
public class Product { ... }  
package application.workflows;
import application.utilities.MailManager;
import application.database.*;
public class Order { ... }  
package application.gui;
import application.workflows*;
public class MainWindow { ... }
public class OrderWindow { ... }
OOA&D with UML

44. 3.14. Exercises 3.14.5 Package Diagrams (Continue)
2. Implement the UML package and class structure shown on the following figure in Java. Define the correct directory structure for your class files. Insert import statements in the class files so that the dependency relationships are correct. Compile your (empty) classes to show that your solution is correct.
OOA&D with UML

45. 3.14. Exercises The School System provides the following functions:
Develop a School System
The School System provides the following functions:
Create course by teacher
Enroll course for student
Cancel course by teacher
Register for user
Modify the personal information
View the Course information (number of students enrolled and teacher information of the course)
Required Software:
DB Visual ARCHITECT 3.0 Java or Professional Edition (
Sun J2SE 1.4 JDK or above (
MySQL Server 4.1 or above (
OOA&D with UML