7/31/2019 Introduction to UMLand OOD
1/48
Introduction to OO using UMLnotation
By
Arun Nair
7/31/2019 Introduction to UMLand OOD
2/48
Agenda
Introduction
4+1 View
Use Case Diagrams Class Diagrams
Association Types
Sequence Diagrams
Object Oriented Design Principles
7/31/2019 Introduction to UMLand OOD
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.
7/31/2019 Introduction to UMLand OOD
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
7/31/2019 Introduction to UMLand OOD
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.
7/31/2019 Introduction to UMLand OOD
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/31/2019 Introduction to UMLand OOD
7/48
Development View
Shows the static organization of softwareof a given system.
7/31/2019 Introduction to UMLand OOD
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.
7/31/2019 Introduction to UMLand OOD
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.
7/31/2019 Introduction to UMLand OOD
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
7/31/2019 Introduction to UMLand OOD
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.
7/31/2019 Introduction to UMLand OOD
12/48
Sample Use Case Diagram
7/31/2019 Introduction to UMLand OOD
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.
7/31/2019 Introduction to UMLand OOD
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.
7/31/2019 Introduction to UMLand OOD
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.
7/31/2019 Introduction to UMLand OOD
16/48
Semantics -
Indicates that an instance of the source usecase will also contain the behavior as specified
by the target use case.
7/31/2019 Introduction to UMLand OOD
17/48
Semantics -
Indicates that an instance of the source usecase may augment the behavior specified by the
target use case.
7/31/2019 Introduction to UMLand OOD
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.
7/31/2019 Introduction to UMLand OOD
19/48
Sample Class Diagram
7/31/2019 Introduction to UMLand OOD
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.
7/31/2019 Introduction to UMLand OOD
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:
7/31/2019 Introduction to UMLand OOD
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:
7/31/2019 Introduction to UMLand OOD
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.
7/31/2019 Introduction to UMLand OOD
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).
7/31/2019 Introduction to UMLand OOD
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.
7/31/2019 Introduction to UMLand OOD
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.
7/31/2019 Introduction to UMLand OOD
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.
7/31/2019 Introduction to UMLand OOD
28/48
Association -.NET Example
publicclass Order
{
privateclass OrderItem{ }List orderItems;
protectedAddress shippingAddress;
privateclass OrderStatus
{
public bool isShipped;
public bool isPaid;
}protectedOrderStatus status;
7/31/2019 Introduction to UMLand OOD
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.
7/31/2019 Introduction to UMLand OOD
30/48
Dependency .NET Example
publicclass OrderFactory{public Order Create(){
returnnew Order();}
}
7/31/2019 Introduction to UMLand OOD
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.
7/31/2019 Introduction to UMLand OOD
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.
7/31/2019 Introduction to UMLand OOD
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.
7/31/2019 Introduction to UMLand OOD
34/48
Interface
Specification of behavior (or contract) thatimplementers agree to meet.
Interfaces cannot be instantiated.
7/31/2019 Introduction to UMLand OOD
35/48
Sequence Diagrams
Semantically equivalent to a collaborationdiagram.
It is a type of interaction diagram thatdescribes time ordering of messages sentbetween objects.
7/31/2019 Introduction to UMLand OOD
36/48
Sample Sequence Diagram
7/31/2019 Introduction to UMLand OOD
37/48
Message
A messagereflects the communication mechanism betweentwo objects in a sequence diagram.
7/31/2019 Introduction to UMLand OOD
38/48
Self Message
A self-messagereflects a new process or method invokedwithin the calling lifeline's operation.
7/31/2019 Introduction to UMLand OOD
39/48
Asynchronous Message
7/31/2019 Introduction to UMLand OOD
40/48
Lifecycle of an Element
7/31/2019 Introduction to UMLand OOD
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
7/31/2019 Introduction to UMLand OOD
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.
Obj t O i t d P i i l
7/31/2019 Introduction to UMLand OOD
43/48
Object Oriented Principles
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
7/31/2019 Introduction to UMLand OOD
44/48
Single Responsibility Principle
Example
Class with multipleresponsibilities
Class split to conform toSingle Responsibility Principle
Obj t O i t d P i i l
7/31/2019 Introduction to UMLand OOD
45/48
Object Oriented Principles
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.
Object Oriented Principles
7/31/2019 Introduction to UMLand OOD
46/48
Object Oriented Principles
Liskov Substitution Principle
Subtypes must be substitutable for theirbase types.
Wherever a method accepts a base type,it must accept the base types derivedclass.
7/31/2019 Introduction to UMLand OOD
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
7/31/2019 Introduction to UMLand OOD
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);
}}
Top Related