Introduction to OO using UML notation

By

Arun Nair

Agenda
Introduction 4+1 View Use Case Diagrams Class Diagrams Association Types Sequence Diagrams Object Oriented Design Principles

Introduction
UML provides system architects working on object analysis and design with one consistent language for specifying, visualizing, constructing, and documenting the artifacts of software systems.

4+1 View
Logical View
Main Functionality, EndUsers Point of View, The Problem

Development View
System specification, Decomposition

Use Case View

Process View
System Functionality, Performance, Scalability

Physical View
Product Topology, Deployment Diagram

Logical View
The structural view of the system. This gives an idea of what a given system is made up of. Documents the view from designers and architects perspective. Class diagrams and object diagrams form the design view of the system.

Process View
The dynamic behavior of a system. Diagrams such as the state diagram, activity diagram, sequence diagram, and collaboration diagram are used in this view.

Development View
Shows the static organization of software of a given system.

Physical View
Shows the mapping(s) of the software onto the hardware and reflects its distributed aspect. Deployment diagrams that compose this view illustrate the physical nodes and devices that make up the application, as well as the connections that exist between them.

Use Case View

Ties the other four views to give a concrete description of the system. This view documents the system from the customers perspective. Diagrams most common in this view are the use case diagrams and, less common, activity diagrams.

Use Case
Represents a coherent set of functionality provided by a system, a subsystem, or a class as manifested by sequences of messages exchanged among the system and one or more outside interactors (called actors) together with actions performed by the system (subsystem, class). Fulfilled by a set of interactions modeled as a sequence diagram.
Source: UML Specification 1.4.2

Use Case Diagrams

Shows a set of actors and use cases, and their relationships. Represent functionality of a system (subsystem or a class) as manifested to external interactors with the system or the classifier Enables to structure the entire application around the core processes that it must support.

Sample Use Case Diagram

Semantics - Actor

A coherent set of roles that users of a system can play when interacting with a system. Examples: Workflow Developer, Business Analyst, Rule subsystem etc.

Semantics - Association

The participation of an actor in a use case, i.e. instances of the actor and instances of the use case communicate with each other.

Semantics - Generalization

The generalizations from use case Make Cash Payment and Make Check Payment to use case Make Payment indicate that both Make Cash Payment and Make Check Payment are specializations of Make Payment.

Semantics - <<include>>

Indicates that an instance of the source use case will also contain the behavior as specified by the target use case.

Semantics - <<extend>>

Indicates that an instance of the source use case may augment the behavior specified by the target use case.

Class Diagrams
Illustrates a set of classes, and their relationships detailing a particular aspect of a system. This diagram is likely the most common one used in modeling.

Sample Class Diagram

Class Stereotypes - Entity

Entity
a class that is passive; i.e., its objects do not initiate interactions on their own. may participate in many different use case realizations and usually outlives any single interaction. Depicted as shown below:

Note: Not to be confused with DesignIT Entity classes.

Class Stereotypes - Control

Control
a class, whose objects control interactions between collections of objects. Usually has behavior specific for one use case and does not outlive the use case realizations in which it participates. Depicted as shown below:

Class Stereotypes - Boundary

Boundary
a class, that models some system boundary, typically a user interface screen. It is used in the conceptual phase to capture users interacting with the system at a screen level Depicted as shown below:

Association

Represents structural relationships between objects of different classes, information that must be preserved for some duration and not simply procedural dependency. Represents the ability of one class instance to send a message to an instance of another class. Implies the two classes must have member variables, that is accessible during their lifetimes, that allows each to reference the other.

Aggregation

A type of association that shows that an element contains or is composed of other elements. Used in Class models to show how more complex elements (aggregates) are built from a collection of simpler elements (component parts; eg. a car from wheels, tires, motor and so on).

Aggregation contd.
It is a special form of Association with the connotation of 'whole/part' relationship. Indicates that the lifetimes of the parts are dependent on the lifetime of the whole.
the only semantic difference between an association and an aggregation (in UML) is that the lifetimes of the two participants are joined; and that the Whole dictates the lifetime of the Part.

Aggregation contd.
Does not indicate a particular kind of implementation or navigation direction. Does not imply that the part is created at the same time that the whole is created.
Note: Refer to http://groups.google.co.in/group/comp.object/browse_thread/thread/1b0beac4676 33569/cbd295019f550a35?hl=en&lnk=st&q=UML+aggregation+navigation#cbd29 5019f550a35 for a detailed discussion on this.

Composition

A stronger form of aggregation, used to indicate ownership of the whole over its parts. The part can belong to only one composite aggregation at a time. If the composite is deleted, all of its parts are deleted with it.

Association -.NET Example

public class Order { private class OrderItem { } List<OrderItem> orderItems; protected Address shippingAddress; private class OrderStatus { public bool isShipped; public bool isPaid; } protected OrderStatus status;

Dependency

A relationship type that signifies that a single or a set of model elements requires other model elements for their specification or implementation. It has many derivatives such as Realization, Instantiation and Usage. Usually are named and adorned with multiplicity information.

Dependency .NET Example

public class OrderFactory { public Order Create() { return new Order(); } }

Generalization

Relation that holds between one model element (the parent) and another (the child) when the child is a special type of the parent. In UML, Generalization is used to model inheritance.

Abstract Class

Class designed to be used only as a parent from which sub-classes may be derived but which is not itself suitable for instantiation. Payment is an abstract class that contains all common attributes and behavior that all its multiple derived classes share.

Generalization vs. Association

Generalization is a relation between classes (implemented as Inheritance). Associations represent relations on sets of class instances designated by the associated classes. Generalization is not a kind of association. They
Never have multiplicities. Never have role names Never have names.

Interface

Specification of behavior (or contract) that implementers agree to meet. Interfaces cannot be instantiated.

Sequence Diagrams
Semantically equivalent to a collaboration diagram. It is a type of interaction diagram that describes time ordering of messages sent between objects.

Sample Sequence Diagram

Message

A message reflects the communication mechanism between two objects in a sequence diagram.

Self Message

A self-message reflects a new process or method invoked within the calling lifeline's operation.

Asynchronous Message

Lifecycle of an Element

UML and .NET

UML does not provide any explicit notation for Events and Delegates.
Events are depicted as messages passed between objects. Delegates are actually implemented as classes and can be depicted as such.

Threads correspond to asynchronous messages in UML.

Object Oriented Principles Law of Demeter

An object A can request a service (call a method) of an object instance B, but object A cannot reach through object B to access yet another object to request its services.

Object Oriented Principles Single Responsibility Principle

A class should have only one responsibility.
All services provided by the class should be narrowly aligned with that responsibility. A responsibility is a reason to change and a class should have only one reason to change.

Single Responsibility Principle Example

Class with multiple responsibilities

Class split to conform to Single Responsibility Principle

Object Oriented Principles Open Closed Principle

Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification.
Open for extension means the ability to make the class/module behave in new and different ways as requirements change. Closed for Modification means the existing source code is inviolate. Encourages use of abstraction and polymorphism. See Strategy Pattern for an example.

Object Oriented Principles Liskov Substitution Principle

Subtypes must be substitutable for their base types. Wherever a method accepts a base type, it must accept the base types derived class.

Object Oriented Principles

Violation of Liskov Substitution Principle
public class BusinessProcess { private IDataSource _source; public BusinessProcess(IDataSource source) { _source = source; } public void Process() { long theKey = 112; // Special code if we're using a FileSource if (_source is FileSource) { ((FileSource)_source).LoadFile(); } try { Entity entity = _source.FindEntity(theKey); } catch (System.Data.DataException) { // Special exception handling for the DatabaseSource, // This is an example of "Downcasting" ((DatabaseSource)_source).CleanUpTheConnection(); } } }

Object Oriented Principles

Liskov Substitution Principle Applied
public class BusinessProcess { private readonly IDataSource _source; public BusinessProcess(IDataSource source) { _source = source; } public void Process(Message message) { // the first part of the Process() method // There is NO code specific to any implementation of // IDataSource here Entity entity = _source.FindEntity(message.Key); } }