Class Diagrams Examples

Here we provide some examples of class diagrams and object diagrams:

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.

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.

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.

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

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 Patient’s 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 physician’s 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.

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.

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.

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.

                     

 

This document describes UML 2.5 and is based on OMG™ Unified Modeling Language™ (OMG UML®) 2.5 specification [UML 2.5 Specification].

All UML diagrams were created in Microsoft Visio 2007, 2010 using UML 2.2 stencils. You can send your comments and suggestions to web master at webmaster@uml-diagrams.org.

 

Copyright © 2010-2013 uml-diagrams.org. All rights reserved.