introduction to umland ood

7/31/2019 Introduction to UMLand OOD

1/48

Introduction to OO using UMLnotation

By

Arun Nair


2/48

Agenda

Introduction

4+1 View

Use Case Diagrams Class Diagrams

Association Types

Sequence Diagrams

Object Oriented Design Principles


3/48

Introduction

UML provides system architects workingon object analysis and design with one

consistent language for specifying,visualizing, constructing, and documentingthe artifacts of software systems.


4/48

4+1 View

Logical ViewMain Functionality,End-Users Point of View, The

Problem

Development ViewSystem specification,

Decomposition

Physical ViewProduct Topology,

Deployment Diagram

Use Case View

Process View

System Functionality,Performance, Scalability


5/48

Logical View

The structural view of the system. Thisgives an idea of what a given system is

made up of. Documents the view from designers and

architects perspective.

Class diagrams and object diagrams formthe design view of the system.


6/48

Process View

The dynamic behavior of a system.

Diagrams such as the state diagram,activity diagram, sequence diagram, andcollaboration diagram are used in this

view.


7/48

Development View

Shows the static organization of softwareof a given system.


8/48

Physical View

Shows the mapping(s) of the softwareonto the hardware and reflects its

distributed aspect. Deployment diagrams that compose this

view illustrate the physical nodes anddevices that make up the application, aswell as the connections that exist betweenthem.


9/48

Use Case View

Ties the other four views to give aconcrete description of the system.

This view documents the system from thecustomers perspective.

Diagrams most common in this view are

the use case diagrams and, less common,activity diagrams.


10/48

Represents a coherent set of functionalityprovided by a system, a subsystem, or a class

as manifested by sequences of messagesexchanged among the system and one or moreoutside interactors (called actors) together withactions performed by the system (subsystem,

class). Fulfilled by a set of interactions modeled as a

sequence diagram.

Use Case

Source: UML Specification 1.4.2


11/48

Use Case Diagrams

Shows a set of actors and use cases, andtheir relationships.

Represent functionality of a system(subsystem or a class) as manifested toexternal interactors with the system or theclassifier

Enables to structure the entire applicationaround the core processes that it mustsupport.


12/48

Sample Use Case Diagram


13/48

Semantics - Actor

A coherent set of roles that users of a system can playwhen interacting with a system.

Examples: Workflow Developer, Business Analyst, Rulesubsystem etc.


14/48

Semantics - Association

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


15/48

Semantics - Generalization

The generalizations from use case Make CashPayment and Make Check Payment to use caseMake Payment indicate that both Make CashPayment and Make Check Payment arespecializations of Make Payment.


16/48

Semantics -

Indicates that an instance of the source usecase will also contain the behavior as specified

by the target use case.


17/48

Semantics -

Indicates that an instance of the source usecase may augment the behavior specified by the

target use case.


18/48

Class Diagrams

Illustrates a set of classes, and theirrelationships detailing a particular aspectof a system.

This diagram is likely the most commonone used in modeling.


19/48

Sample Class Diagram


20/48

Class Stereotypes - Entity

Entity

a class that is passive; i.e., its objects do notinitiate interactions on their own. mayparticipate in many different use caserealizations and usually outlives any singleinteraction. Depicted as shown below:

Note: Not to be confused with DesignIT Entity classes.


21/48

Class Stereotypes - Control

Control

a class, whose objects control interactionsbetween collections of objects. Usually hasbehavior specific for one use case and doesnot outlive the use case realizations in whichit participates. Depicted as shown below:


22/48

Class Stereotypes - Boundary

Boundary

a class, that models some system boundary,typically a user interface screen. It is used inthe conceptual phase to capture usersinteracting with the system at a screen levelDepicted as shown below:


23/48

Association

Represents structural relationships between objects ofdifferent classes, information that must be preserved forsome duration and not simply procedural dependency.

Represents the ability of one class instance to send amessage to an instance of another class.

Implies the two classes must have member variables,that is accessible during their lifetimes, that allows eachto reference the other.


24/48

Aggregation

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


25/48

Aggregation contd.

It is a special form of Association with theconnotation of 'whole/part' relationship.

Indicates that the lifetimes of the partsare dependent on the lifetime of the whole.

the only semantic difference between anassociation and an aggregation (in UML) is

that the lifetimes of the two participants arejoined; and that the Whole dictates the lifetimeof the Part.


26/48

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 tohttp://groups.google.co.in/group/comp.object/browse_thread/thread/1b0beac467633569/cbd295019f550a35?hl=en&lnk=st&q=UML+aggregation+navigation#cbd295019f550a35for a detailed discussion on this.


27/48

Composition

A stronger form of aggregation, used to indicateownership of the whole over its parts. The partcan belong to only one composite aggregation ata time. If the composite is deleted, all of its partsare deleted with it.


28/48

Association -.NET Example

publicclass Order

{

privateclass OrderItem{ }List orderItems;

protectedAddress shippingAddress;

privateclass OrderStatus

{

public bool isShipped;

public bool isPaid;

}protectedOrderStatus status;


29/48

Dependency

A relationship type that signifies that a single or a set ofmodel elements requires other model elements for theirspecification or implementation.

It has many derivatives such as Realization, Instantiation

and Usage. Usually are named and adorned with multiplicity

information.


30/48

Dependency .NET Example

publicclass OrderFactory{public Order Create(){

returnnew Order();}

}


31/48

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.


32/48

Abstract Class

Class designed to be used only as a parent fromwhich sub-classes may be derived but which isnot itself suitable for instantiation.

Paymentis an abstract class that contains allcommon attributes and behavior that all itsmultiple derived classes share.


33/48

Generalization vs. Association

Generalization is a relation betweenclasses (implemented as Inheritance).

Associations represent relations on sets of

class instances designated by theassociated classes.

Generalization is nota kind of association.

They Never have multiplicities. Never have role names

Never have names.


34/48

Interface

Specification of behavior (or contract) thatimplementers agree to meet.

Interfaces cannot be instantiated.


35/48

Sequence Diagrams

Semantically equivalent to a collaborationdiagram.

It is a type of interaction diagram thatdescribes time ordering of messages sentbetween objects.


36/48

Sample Sequence Diagram


37/48

Message

A messagereflects the communication mechanism betweentwo objects in a sequence diagram.


38/48

Self Message

A self-messagereflects a new process or method invokedwithin the calling lifeline's operation.


39/48

Asynchronous Message


40/48

Lifecycle of an Element


41/48

UML and .NET

UML does not provide any explicit notationfor Events and Delegates.

Events are depicted as messages passedbetween objects.

Delegates are actually implemented asclasses and can be depicted as such.

Threads correspond to asynchronousmessages in UML.

Obj t O i t d P i i l


42/48

Object Oriented Principles

Law of Demeter

An object A can request a service (call amethod) of an object instance B, but object

A cannot reach through object B to

access yet another object to request itsservices.



43/48


Single Responsibility Principle

A class should have only oneresponsibility.

All services provided by the class should benarrowly aligned with that responsibility.

A responsibility is a reason to changeand aclass should have only one reason to change.

Si l R ibilit P i i l


44/48

Single Responsibility Principle

Example

Class with multipleresponsibilities

Class split to conform toSingle Responsibility Principle



45/48


Open Closed Principle

Software entities (classes, modules, functions,etc.) should be open for extension but closed formodification.

Open for extensionmeans the ability to make theclass/module behave in new and different ways asrequirements change.

Closed for Modificationmeans the existing source

code is inviolate. Encourages use of abstraction and polymorphism.

See Strategy Patternfor an example.



46/48


Liskov Substitution Principle

Subtypes must be substitutable for theirbase types.

Wherever a method accepts a base type,it must accept the base types derivedclass.


47/48

Object Oriented PrinciplesViolation ofLiskov 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 FileSourceif (_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();

}}

}

O O


48/48

Object Oriented PrinciplesLiskov Substitution Principle Applied

publicclass BusinessProcess {private readonly IDataSource _source;

public BusinessProcess(IDataSource source) {_source = source;

}

publicvoidProcess(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);

}}