UML case fundamental

UML(Unified Modeling Language) CASE Fundamental

Prerequisite:

Participants must have insight in the background of object-oriented techniques, and must have applied these techniques in object-oriented programming.For basic OOP Concept follow my post on Basic OOP Concept.

After completing this tutorial you will be able to:

•  Understand why UML is used?
•  Can work with the commonly used UML elements?
•  Can create simple UML models?

Remember this tutorial doesn’t elaborately describe how to modeling a system from a problem domain rather it will describe how to understand UML of a problem domain.

What is modeling?

Before understanding UML (Unified Modeling Language), we need to understand what does modeling mean? Suppose, you are going to build a new addition to your house, you probably won’t start by just buying a bunch of wood and nailing it together until it looks about right. You’ll want some blueprints to follow so you can plan and structure the addition before you start working.

Modeling does the same thing for us in the software world. They are the blueprints for systems. Like a blueprint; a model also helps you plan a system before you build it. It can help you be sure the design is sound, the requirements have been met, and the system can withstand even a hurricane of requirement changes.

What is UML?

UML is one kind of modeling language for visualizing, specifying, constructing and documenting the artifacts of the system. It allows you to create a blue print of all aspects of the system, before actually physically implementing the system.

Why is it important?

Let's look at this question from the point of view of the construction trade. Architects design buildings. Builders use the designs to create buildings. The more complicated the building, the more critical the communication between architect and builder. Blueprints are the standard graphical language that both architects and builders must learn as part of their trade.

Writing software is not unlike constructing a building. The more complicated the underlying system, the more critical the communication among everyone involved in creating and deploying the software. In the past decade, the UML has emerged as the software blueprint language for analysts, designers, and programmers alike. It is now part of the software trade. The UML gives everyone from business analyst to designer to programmer a common vocabulary to talk about software design.

Types of UML diagram:

UML has nine kinds of modeling diagrams:

•  Use case diagram
•  Class diagrams 
•  Object diagrams 
•  Sequence diagrams 
•  Collaboration diagrams 
•  Statechart diagrams 
•  Activity diagrams 
•  Component diagrams 
•  Deployment diagrams

In our discussion, we only discuss Use case diagram, Class diagrams, Sequence diagram, Collaboration diagram, Activity diagram.

Use case diagram:

Use case diagram consists of some use cases in your system, some of the actors in your system, and the relationships between them. A use case is a high level piece of functionality for a single task or goal that the system will provide. An actor is who or what initiates the events involved in that task. Actors are simply roles that people or objects play.

Use case diagrams are closely connected to scenarios. A scenario is an example of what happens when someone interacts with the system. Here is a scenario for a medical clinic."A patient calls the clinic to make an appointment for a yearly checkup. The receptionist finds the nearest empty time slot in the appointment book and schedules the appointment for that time slot. "

A use case is a summary of scenarios for a single task or goal. An actor is who or what initiates the events involved in that task. Actors are simply roles that people or objects play. The picture below is a Make Appointment use case for the medical clinic. The actor is a Patient. The connection between actor and use case is a communication association (or communication for short).

Use case diagrams describe what a system does from the standpoint of an external observer. The emphasis is on what a system does rather than how.

It is important to notice that Use Case Diagrams are not suited to represent the design, and cannot describe the internals of a system. Use Case Diagrams are meant to facilitate the communication with the future users of the system, and with the customer, and are especially helpful to determine the required features the system is to have. Use Case Diagrams tell, what the system should do but do not — and cannot specify how this is to be achieved.

A use case diagram is a collection of actors, use cases, and their communications. We've put Make Appointment as part of a diagram with four actors and four use cases. Notice that a single use case can have multiple actors.

Use case diagrams fulfill a specific purpose – to document the actors (everything outside the system scope), the use cases (everything inside the system scope), and their relationships. Some things to keep in mind as you are creating use case diagrams.

• Don’t model actor to actor communications. By definition, the actors are outside the scope of the current problem domain. The communication between the actors, therefore, is also outside the scope of what you’re building.    
• Don’t draw an arrow directly between two use cases (except in a uses or extends relationship, which will be described later).
• Every use cases must be initiated by an actor. Again, the exception here is a uses or extends relationship, which will be described later.

Activity diagrams:

An activity diagram is essentially a fancy flowchart. Activity diagrams and state chart diagrams are related. While a state chart diagram focuses attention on an object undergoing a process (or on a process as an object), an activity diagram focuses on the flow of activities involved in a single process. The activity diagram shows the how those activities depend on one another.For our example, we used the following process.

"Withdraw money from a bank account through an ATM."

The three involved classes (people, etc.) of the activity are Customer, ATM, and Bank. The process begins at the black start circle at the top and ends at the concentric white/black stop circles at the bottom. The activities are rounded rectangles.

Sequence diagrams:

Sequence diagrams are used to show the flow of functionality through a use case. Sequence diagrams are interaction diagrams that are ordered by time; you can read the diagrams from top to bottom. Sequence diagrams are used to show the flow of functionality through a use case. 

For example, the Withdraw Money use case has several possible sequences, such as withdrawing money, attempting to withdraw without available funds, attempting to withdraw with the wrong PIN, and several others. The normal scenario of withdrawing $20 (without any problems such as entering the wrong PIN or insufficient funds in the account)

This Sequence diagram shows the flow of processing through the Withdraw Money use case. Any actors involved are shown at the top of the diagram; the customer actor is shown in the above example. The objects that the system needs in order to perform the Withdraw Money use case are also shown at the top of the diagram. Each arrow represents a message passed between actor and object or object and object to perform the needed functionality. One other note about Sequence diagrams—they display objects, not classes. Classes represent types of objects, Objects are specific; instead of just customer, the Sequence diagram shows Joe. The use case starts with the customer inserting his card into the card reader, an object indicated by the rectangle at the top of the diagram. Then, the card reader reads the card number, opens Joe's account object, and initializes the ATM screen. The screen prompts Joe for his PIN. He enters 1234. The screen verifies the PIN with the account object and they match. The screen presents Joe with his options, and he chooses withdraw. The screen then prompts Joe for the amount to withdraw. He chooses $20. Then, the screen withdraws the funds from the account. This initiates a series of processes that the account object performs. First, Joe's account verifies that the account contains at least $20. Then, it deducts the funds from the account. Next, it instructs the cash dispenser to provide $20 in cash. Joe's account also instructs the dispenser to provide a receipt. Lastly, it instructs the card reader to eject the card. This Sequence diagram illustrated the entire flow of processing for the Withdraw Money use case by showing a specific example of Joe withdrawing $20 from his account. Users can look at these diagrams to see the specifics of their business processing. Analysts see the flow of processing in the Sequence diagrams. Developers see objects that need to be developed and operations for those objects.

Collaboration diagram:

Collaboration diagrams show exactly the same information as the Sequence diagrams. However,
Collaboration diagrams show this information in a different way and with a different purpose. The Sequence diagram is given bellow as a Collaboration diagram:

  

In this Collaboration diagram, the objects are represented as rectangles and the actors are stick figures, as before. Whereas the Sequence diagram illustrates the objects and actor interactions over time, the Collaboration diagram shows the objects and actor interactions without reference to time. For example, in this diagram, we see that the card reader instructs Joe's account to open and Joe's account instructs the card reader to eject the card. Also, objects that directly communicate with each other are shown with lines drawn between them. If the ATM screen and cash dispenser directly communicated with one another, a line would be drawn between them. The absence of a line means that no communication occurs directly between those two objects. Collaboration diagrams, therefore, show the same information as Sequence diagrams, but people look at Collaboration diagrams for different reasons. Quality assurance engineers and system architects look at these to see the distribution of processing between objects. Suppose that the Collaboration diagram was shaped like a star, with several objects communicating with a central object. A system architect may conclude that the system is too dependent on the central object and redesign the objects to distribute the processing power more evenly. This type of interaction would have been difficult to see in a Sequence diagram.

Class diagrams:

A Class diagram gives an overview of a system by showing its classes and the relationships among them. Class diagrams are static -- they display what interacts but not what happens when they do interact.The class diagram below models a customer order from a retail catalog. The central class is the Order. Associated with it is the Customer making the purchase and the Payment. A Payment is one of three kinds: Cash, Check, or Credit. The order contains Order Details (line items), each with its associated Item.

UML class notation is a rectangle divided into three parts: class name, attributes, and operations. Names of abstract classes, such as Payment, are in italics. Relationships between classes are the connecting links.Our class diagram has three kinds of relationships.

• Association: A relationship between instances of the two classes. There is an association between two classes if an instance of one class must know about the other in order to perform its work. In a diagram, an association is a link connecting two classes.  
• Aggregation: An association in which one class belongs to a collection. An aggregation has a diamond end pointing to the part containing the whole. In our diagram, Order has a collection of OrderDetails. 
• Generalization: An inheritance link indicating one class is a superclass of the other. A generalization has a triangle pointing to the superclass. Payment is a superclass of Cash, Check, and Credit.   

An association has two ends. An end may have a role name to clarify the nature of the association. For example, an OrderDetail is a line item of each Order.

A navigability arrow on an association shows which direction the association can be traversed or queried. An OrderDetail can be queried about its Item, but not the other way around.The arrow also lets you know who "owns" the association's implementation; in this case, OrderDetail has an Item. Associations with no navigability arrows are bi-directional.

The multiplicity of an association end is the number of possible instances of the class associated with a single instance of the other end. Multiplicities are single numbers or ranges of numbers. In our example, there can be only one Customer for each Order, but a Customer can have any number of Orders.

This table gives the most common multiplicities.

Multiplicities	Meaning
0..1	zero or one instance. The notation n . . m indicates n to m instances.
0..*  or  *	no limit on the number of instances (including none).
1	exactly one instance
1..*	at least one instance

Every class diagram has classes, associations, and multiplicities. Navigability and roles are optional items placed in a diagram to provide clarity.

Thank you for reading.