UML ( Unified Modeling Langauage)

UML is simply another graphical representation of a common semantic model. UML provides a comprehensive notation for the full lifecycle of object-oriented development.

Advantages:

To represent complete systems (instead of only the software portion) using objectoriented concepts To establish an explicit coupling between concepts and executable code To take into account the scaling factors that are inherent to complex and critical systems To creating a modeling language usable by both humans and machines

UML defines several models for representing systems:

The class model captures the static structure The state model expresses the dynamic behavior of objects. The use case model describes the requirements of the user. The interaction model represents the scenarios and messages flows The implementation model shows the work units The deployment model provides details that pertain to process allocation

UML Diagrams
UML defines nine different types of diagram: 1. 2. 3. 4. 5. 6. 7. 8. 9. Use case diagrams: represent the functions of a system from the user's point of view. Sequence diagrams: are a temporal representation of objects and their interactions. Collaboration diagrams: spatial representation of objects, links, and interactions. Object diagrams :represent objects and their relationships and correspond to simplified collaboration diagrams that do not represent message broadcasts. Class diagrams represent the static structure in terms of classes and relationships Statechart diagrams: represent the behavior of a class in terms of states at run time. Activity diagrams: represent the behavior of an operation as a set of actions Component diagrams: represent the physical components of an application Deployment diagrams: represent the deployment of components on particular pieces of hardware

The different types of diagrams defined by UML

Relationship among various UML Diagrams in OOAD ( Object Oriented Analysis and design) is illustrated in the following diagrams of Business Model, Use Case Diagram , Sequence Diagram , Class Diagram and Code generation..

1. Use Case Diagram:

Use Cases for ATM System:

Use Case Specification:

A flow of events document is created for each use cases Written from an actor point of view Details what the system must provide to the actor when the use cases is executed Typical contents o How the use case starts and ends o Normal flow of events o Alternate flow of events o Exceptional flow of events

2. Activity Diagram:

Used to document complex use case logic. It is not required for simple use case logic.

Symbols:

Use Case to accept credit Card Payment: 1. The customer then enters and submits her card details. 2. The system validates these values and either returns to the customer if there is an error or submits the payment to the Credit Card Service. 3. If the card payment is accepted, then the system notifies the customer of success. If not, then the error is logged, and the customer is notified of the failure (and perhaps directed to handle the payment some other way).

Object Interactions:( Sequence and Collaboration : Complimentary to each other) diagrams.

Interactions between objects are represented by interaction diagrams both sequence and collaboration diagrams. An example of a collaboration diagram is shown below. Objects are drawn as rectangles and the lines between them indicate links a link is an instance of an association. The order of the messages along the links between the objects is indicated by the number at the head of the message: Sequence diagrams show essentially the same information, but concentrate on the time-ordered communication between objects, rather than their relationships. An example of a sequence diagram is shown below. The dashed vertical lines represent the lifeline of the object:

3. Sequence Diagram:

Time ordered message passing:

Withdrawal Transaction Use Case

A withdrawal transaction asks the customer to choose a type of account to withdraw from (e.g. checking) from a menu of possible accounts, and to choose a dollar amount from a menu of possible amounts. The system verifies that it has sufficient money on hand to satisfy the request before sending the transaction to the bank. (If not, the customer is informed and asked to enter a different amount.) If the transaction is approved by the bank, the appropriate amount of cash is dispensed by the machine before it issues a receipt. (The dispensing of cash is also recorded in the ATM's log.) A withdrawal transaction can be cancelled by the customer pressing the Cancel key any time prior to choosing the dollar amount.

4. Collaboration Diagram: Relationship among Objects and Messages.

5. Analysis class Diagram: MVC (Model , View and Control) high level Design of the System:

6. Class Diagram:
Class: A Class is represented like this: Class Attribute1 Attribute2 MethodA() MethodB()

The top part showing the class name, the second showing the attributes and the third showing the methods. Object: An object looks very similar to a class, except that its name is underlined:

AnObject
Attribute1 Attribute2 MethodA() MethodB() Relationships: Relationships between classes are generally represented in class diagrams by a line or an arrow joining the two classes. UML can represent the following, different types of object relationships. 3.1 If A depends on B, then this is shown by a dashed arrow between A and B, with the arrowhead pointing at B:

Association: An association between A and B is shown by a line joining the two classes: 1. Bidirectional:

If there is no arrow on the line, the association is taken to be bidirectional. 2. A unidirectional association is indicated like this:

Aggregation: An aggregation relationship is indicated by placing a white diamond at the end of the association next to the aggregate class. If B aggregates A, then A is a part of B, but their lifetimes are independent:

Composition: Composition, on the other hand, is shown by a black diamond on the end of association next to the composite class. If B is composed of A, then B controls the lifetime of A.

Multiplicity: The multiplicity of a relationship is indicated by a number (or *) placed at the end of an association. The following diagram indicates a one-to-one relationship between A and B:

A multiplicity can also be a range of values. Some examples are shown below: 1 One and only one * 0..1 n..m 1..* Any number from 0 to infinity Either 0 or 1 Any number in the range n to m inclusive Any positive integer

Naming an Association To improve the clarity of a class diagram, the association between two objects may be named:

Inheritance

An inheritance (generalization/specialization) relationship is indicated in the UML by an arrow with a triangular arrowhead pointing towards the generalized class. If A is a base class, and B and C are classes derived from A, then this would be represented by the following class diagram:

Multiple Inheritance The next diagram represents the case where class C is derived from classes A and B:

Class Diagram for ATM System:

Package Diagram for Example ATM System

Withdrawal Class: Withdrawal - from: int - amount: Money

+ Withdrawal(atm: ATM, session: Session, card: Card, pin: int) # getSpecificsFromCustomer(): Message throws Cancelled # completeTransaction(): Receipt Visibility of Attribute or Method specified by characters like - (Private), + (Public), # (Protected).

7. State Diagram:
States of objects are represented as rectangles with rounded corners. The transition between difference states is represented as an arrow between states, and a condition of that transition occurring may be added between square braced. This condition is called a guard.

8. Component Diagrams:
Component diagrams describe software components and their relationships within the implementation environment; they indicate the choices made at implementation time. They may be simple files, or libraries loaded dynamically.

In C++, a specification corresponds to a file with a .h suffix, and a body corresponds to a file with the suffix .cpp.

9. Deployment Diagrams
Deployment diagrams show the physical layout of the various hardware components (nodes) that compose a system, as well as the distribution of executable programs on this hardware. Deployment diagrams may show node classes or node instances. As with other types of diagram, the graphical difference between classes and objects is implemented by underlining the object name. The following example shows the deployment diagram of a building access management system:

The diagram describes the nature of the communication links between the various nodes. The server and the PCs are connected via an IPX link; the X-terminals and the server communicate via TCP/IP. The nature of the connections between other nodes is not specified.

Each process named in the deployment diagram executes a main program with the same name as the one described within the component diagram.

Click to go to Home Page

Class Diagrams Examples

Here we provide some examples of class diagrams:

Design Pattern - Abstract Factory Domain Model - Library Domain Model - Online Shopping Domain Model - Hospital Management Domain Model - DICOM Model of the Real World Implementation - Android Camera Implementation Classes Object Diagram - Login Controller

Abstract Factory Design Pattern

Abstract Factory is creational software design pattern. This pattern provides interfaces for creating families of related or dependent objects without specifying their concrete classes. Client software creates a concrete implementation of the abstract factory and then uses the generic interfaces to create the concrete objects that are part of the family of objects. The client does not know or care which concrete objects it gets from each of these concrete factories since it uses only the generic interfaces of their products. Use of this pattern makes it possible to interchange families of concrete classes without changing the code that uses them. It separates details of implementation of a set of objects from their usage.

Class Diagram Example - Abstract Factory Design Pattern

Library Domain Model

Library Domain Model describes main classes and relationships which could be used during analysis phase to better understand domain area for Integrated Library System (ILS), also known as a Library Management System (LMS). Each physical library item - book, tape cassette, CD, DVD, etc. could have its own item number. To support it, the items may be barcoded. The purpose of barcoding is to provide a unique and scannable identifier that links the barcoded physical item to the electronic record in the catalog. Barcode must be physically attached to the item, and barcode number is entered into the corresponding field in the electronic item record. Barcodes on library items could be replaced by RFID tags. The RFID tag can contain item's identifier, title, material type, etc. It is read by an RFID reader, without the need to open a book cover or CD/DVD case to scan it with barcode reader. Library has some rules on what could be borrowed and what is for reference only. Rules are also defined on how many books could be borrowed by patrons and how many could be reserved.

Class Diagram Example - Library Domain Model Library catalog provides access for the library patrons and staff to all sources of information about library items, allows to search by a particular author, on a particular topic, or in a particular format, that the library has. It tells the user where materials meeting their specific needs can be found.

Online Shopping Domain

This diagram is an example of class diagram which shows some domain model for online shopping. Each customer could have some web user identity. Web user could be in several states and could be linked to one shopping cart. Each customer has exactly one account. Account owns shopping cart and orders. Orders are sorted and unique. Each order is linked to none to several payments.

Class diagram example - Online Shopping Domain.

Each order has current order status. Both order and shopping cart have line items linked to specific product.

Hospital Management Domain Model

Domain model for the Hospital Management System is represented by several class diagrams.

Hospital Organization Domain model - Patient, Hospital, Staff - Operations, Administrative, Technical. Ward is a division of a hospital or a suite of rooms shared by patients who need a similar kind of care. In a hospital, there are a number of wards, each of which may be empty or have on it one or more patients. Each ward has a unique name. Diagram below shows it using {id} modifier for ward's name. Wards are differentiated by gender of its patients, i.e. male wards and female wards. A ward can only have patients of the gender admitted to it. Gender is shown as enumeration. Ward and patient have constraint on Gender. Every ward has a fixed capacity, which is the maximum number of patients that can be on it at one time (i.e. the capacity is the number of beds in the ward). Different wards may have different capacities. The doctors in the hospital are organised into teams (also called firms). Each team has a unique name or code (e.g. Orthopaedics or Pediatrics) and is headed by a consultant doctor (in the UK, Republic of Ireland, and parts of the Commonwealth) or attending physician (also known as staff physician) (in the United States). Consultant doctor or attending physician is the senior doctor who has completed all of his or her specialist training, residency and practices medicine in a clinic or hospital, in the specialty learned during residency. She or he can supervise fellows, residents, and medical students. The rest of the team are all junior doctors. Each doctor could be a member of no more than one team.

Hospital wards, teams of doctors, and patients. Each patient is on a single ward and is under the care of a single team of doctors. A patient may be treated by any number of doctors but they must all be in the team that cares for the patient. A doctor can treat any number of patients. The team leader accepts ultimate responsibility, legally and otherwise, for the care of all the patients referred to him/her, even with many of the minuteto-minute decisions being made by subordinates.

Domain model - Patient, Doctors and Treatments

DICOM Model of the Real World

An example of class diagram representing domain model ("model of the real world") for Digital Imaging and Communications in Medicine (DICOM). This diagram is based on E-R model Fig.7-3 of DICOM standard Part 3 - PS 3.3-2009. Diagram represents DICOM extended domain, abstract description of the real world objects used in the Modality-IS Interface. Modality is a piece of imaging equipment, e.g. computed tomography (CT) or ultrasound (US).

A Patient is a human or an animal receiving, or registered to receive, healthcare services, or is the subject of research studies. A Clinical Document is a part of the medical record of a patient. It is a documentation of clinical observations and services provided to the patient. A Service Episode is a collection of events, context in which the treatment or management of an arbitrary subset of a Patients medical conditions occurs. Service episode is entirely arbitrary; it may include a single outpatient visit or a hospitalization, or extend over significant period of time, e.g., the duration of a pregnancy, or an oncology treatment regimen. A service episode may involve one or more Healthcare Organizations (administrative entities that authorize Healthcare Providers to provide services within their legal administrative domain, e.g. hospitals, private physicians offices, multispecialty clinics, nursing homes). Visit is a part of service episode, collection of events that fall under the accountability of a particular Healthcare Organization in a single facility. A visit may be associated with one or more physical locations (e.g. different rooms, departments, or buildings) within the same facility. An Imaging Service Request is a set of one or more Requested Procedures selected from a list of Procedure Types. An Imaging Service Request is submitted by one authorized imaging service requester to one authorized imaging service provider in the context of one Service Episode. An Imaging Service Request may be associated with one or more Visits that occur within the same Service Episode. A modality Scheduled Procedure Step is an arbitrarily defined scheduled unit of service, that is specified by the Procedure Plan for a Requested Procedure. It prescribes Protocol which may be identified by one or more Protocol Codes. A modality Scheduled Procedure Step involves equipment (e.g. imaging equipment, surgical equipment, etc), human resources, supplies, location, and time. A Modality Performed Procedure Step is an arbitrarily defined unit of service that has actually been performed (not just scheduled). It contains references to zero or more Series of Images.

Class Diagram Example - DICOM Domain Model for Modality-IS Interface

Android Camera Implementation Classes

This example is implementation level class diagram which shows some classes using Android Camera API (Android 3.1 Platform, API Level 12). Details of the API could be found at Android hardware Camera class. Example implementation that we follow is described in Using Android Camera API.

CameraDemo extends Android's Activity. An activity is a single, focused thing that the user can do with Android. Activity usually interacts with user, and the Activity class takes care of creating a window in which we can place our user interface. CameraDemo activity will create a Preview object and will hold reference to. Preview holds back reference to the activity as its Context. The Preview object will create a Camera object and return it to the CameraDemo activity. The Camera class is Android hardware class used to get/create objects of the Camera class, set image capture settings, start or stop preview, take pictures, etc. Camera class is not thread-safe, and should be used from a single event thread. This class is a client for the Camera service, which manages the actual camera hardware.

Android Camera demo implementation classes. We will need to register some callback methods to be called by the Camera asynchronously after takePicture method was called and the shutter opened, picture is taken, and when picture data is ready. SurfaceHolder is an interface implemented by objects holding a display surface. It allows us to control the surface size and format, edit the pixels in the surface, monitor changes to the surface, get direct access to the surface object, etc. SurfaceHolder.Callback interface allows to receive information about changes to the surface.

Login Controller Object Diagram

This is an example of object diagram which shows some runtime objects related to web user login process. Class instance loginCtrl of the Login Controller has several slots with structural features of Integer and String types and corresponding value specifications. The instance of Login Controller is also associated with instances of User Manager, Cookie Manager, and Logger. Login Controller, User Manager, and Hibernate User DAO (Data Access Object) share the single instance of Logger.

Login Controller object diagram. User Manager has private attribute defaultURIs which is ordered collection (array) of 5 unique Strings. Instance of the Cookie Manager has two public structural features with specified values. Most links are non navigable backward.