Class Diagrams Examples
Purpose: Illustrate Abstract Factory design pattern.
Summary: Abstract Factory is creational software design pattern. This pattern provides interfaces for creating families of related or dependent objects without specifying their concrete classes.
Purpose: Describe domain area for an Integrated Library System (ILS), also known as a Library Management System (LMS) - Library, Catalog, Book, Patron, Account.
Summary: Library Domain Model describes main classes and relationships which could be used during analysis phase to better understand domain area for ILS or LMS.
Purpose: Show some domain model for online shopping - Customer, Account, Shopping Cart, Product, Order, Payment.
Summary: Example of a UML class diagram representing online shopping domain. Each customer could have some web user identity. Web user could be in one of several states and could be linked to a shopping cart.
Summary: This example shows several subtypes of Bank Account using UML generalization sets. Bank accounts could be grouped into UML generalization sets based on different criteria. Example diagram shows bank accounts topology with two orthogonal dimensions and with corresponding power types Liability Type and Account Type.
Summary: This example shows several subtypes of Health Insurance Policy using UML generalization sets. One generalization set is Coverage Type - Job Based Coverage, Self Coverage, and Benefits Coverage, and another set is based on Insurance Plan - HMO, POS, PPO, FFS.
Summary: A domain model for the Hospital Management System is represented by several class diagrams.
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.
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 or an attending physician.
Purpose: Represent domain model ("model of the real world") for Digital Imaging and Communications in Medicine (DICOM) - Patient, Visit, Facility, Imaging Service Request, Scheduled Procedure Step, Modality Performed Procedure Step.
Summary: UML diagram example represents DICOM extended domain, abstract description of the real world objects used in the Modality-IS Interface. Modality is a piece of medical imaging equipment, e.g. computed tomography (CT) or ultrasound (US).
Purpose: The purpose of the domain diagram is to show major "things" used during software licensing and protection process using Sentinel HASP, and relationships between those things.
Summary: When software vendor purchases a Sentinel HASP LDK, the vendor is provided with a unique batch code and corresponding vendor key. Each protected software product has some features and is associated with a batch code. An entitlement can contain one or more products and is associated with the customer who placed the order. The customer could be either an individual customer or a company.
Purpose: An example of implementation level UML class diagram to illustrate usage of Android Camera API (Android 3.1 Platform, API Level 12).
Summary: CameraDemo class extends Android's Activity class. An Activity is a single, focused thing that a 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.
Purpose: Show implementation details of several HASP classes realizing the HASP Java Native Interface Proxy component.
Summary: The HASP Aladdin package includes 4 classes. These classses are implementation of the HASP Java Native Interface Proxy component you can find on the Sentinel HASP licensing component diagram.
Purpose: An example of UML object diagram which shows some runtime objects involved into login process for a web user.
Summary: An instance of Login Controller class is associated with instances of User Manager, Cookie Manager, and Logger. Login Controller, User Manager, and Hibernate User DAO (Data Access Object) share a single instance of Logger.
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.
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.
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.