UML an overview

Introduction
What is UML?
Is a language. It is not simply a notation for drawing diagrams, but a complete language for capturing knowledge(semantics) about a subject and expressing knowledge(syntax) regarding the subject for the purpose of communication. Applies to modeling and systems. Modeling involves a focus on understanding a subject (system) and capturing and being able to communicated in this knowledge. It is the result of unifying the information systems and technology industrys best engineering practices (principals, techniques, methods and tools).

Unified Modeling Language (UML)

used for both database and software modeling version 1.1 was adopted in November 1997 by the Object Management Group (OMG) as a standard language for object-oriented analysis and design Initially based on a combination of the Booch, OMT (Object Modeling Technique) and OOSE (Object-Oriented Software Engineering) methods, UML was refined and extended by a consortium of several companies, and is undergoing minor revisions by the OMG Revision Task Force.
Ivar Jacobson is known as the father of Use Cases.

Refernces http://www.inconcept.com/JCM/April1998/halpin.html

The UML process

There are four kinds of things in the UML. 1. Structural Things. 2. Behavioral Things.

3. Grouping Things.
4. Annotational Things.

Things in UML
Structural Things 1. Class 2. Interface 3. Collaboration 4. Use Case 5. Active Class 6. Components 7. Nodes Behavioral Things 1. Interaction 2. State Mechanism Grouping Things 1. Packages Annotational Things 1. Notes

Diagrams in UML A Diagram is the graphical presentation of a set of elements, most often rendered as a connected graph of things and relationships. UML includes 9 such diagrams. 1. Class Diagram.

2. Object Diagram.
3. Use Case Diagram. 4. Sequence Diagram. 5. Collaboration Diagram. 6. State Chart Diagram. 7. Activity Diagram. 8. Component Diagram

9. Deployment Diagram.

Class Diagrams Class Diagrams describe the static structure of a system, or how it is structured rather than how it behaves. Provide a conceptual model of the system in terms of entities and their relationships Used for requirement capture, end-user interaction Detailed class diagrams are used for developers

Class representation

Each class is represented by a rectangle subdivided into three compartments

Name Attributes Operations

Modifiers are used to indicate visibility of attributes and operations. + is used to denote Public visibility (everyone) # is used to denote Protected visibility (friends and

derived) - is used to denote Private visibility (no one)

By default, attributes are hidden and operations are visible.

An example of Class
Name Attributes

Account_Name - Customer_Name - Balance +addFunds( ) +withDraw( ) +transfer( )

Operations

Relationships

There are two kinds of Relationships

Generalization (parent-child relationship) Association (student enrolls in course)

Associations can be further classified as

Aggregation Composition

Relationships: Generalization
Supertype
Example:

Customer

Regular Customer

Loyalty Customer

Subtype1

Subtype2
or:

Customer

- Generalization expresses a parent/child relationship among related classes. - Used for abstracting details in several layers
Regular Customer Loyalty Customer

Relationships: Composition
Whole Class Class W Composition: expresses a relationship among instances of related classes. It is a specific kind of Whole-Part relationship. It expresses a relationship where an instance of the Whole-class has the responsibility to create and initialize instances of each Part-class. Class P1 Class P2 It may also be used to express a relationship where instances of the Part-classes have privileged access or visibility to certain attributes and/or behaviors defined by the Whole-class. Composition should also be used to express relationship where instances of the Whole-class have exclusive access to and control of instances of the Part-classes. Automobile Composition should be used to express a relationship where the behavior of Part instances is undefined without being related to an instance of the Whole. And, conversely, the behavior of the Whole is ill-defined or incomplete if one or more of the Part instances are undefined.

Part Classes

Example

Engine

Transmission

Relationships: Aggregation
Container Class Class C AGGREGATION Aggregation: expresses a relationship among instances of related classes. It is a specific kind of ContainerContainee relationship. Class E2 It expresses a relationship where an instance of the Container-class has the responsibility to hold and maintain instances of each Containee-class that have been created outside the auspices of the Container-class. Aggregation should be used to express a more informal relationship than composition expresses. That is, it is an appropriate relationship where the Container and its Containees can be manipulated independently. Aggregation is appropriate when Container and Containees have no special access privileges to each other.

Class E1

Containee Classes

Example

Bag

Apples

Milk

[From Dr.David A. Workman]

Class Diagram
Name Attributes
Order
-dateReceived -number :String -price : Money +dispatch() +close()

Multiplicity: mandatory

class
1
Customer
-name -address
+creditRating() : String()

*
Association

Operations

{if Order.customer.creditRating is "poor", then Order.price must be higher }

Generalization

Corporate Customer

Personal Customer
-creditCard#

Constraint Multiplicity: Many value (inside braces{}}

-contactName -creditRating -creditLimit +remind() +billForMonth(Integer)

Multiplicity: optional

0..1

*
Employee

*
OrderLine
-quantity: Integer -price: Money -isSatisfied: Boolean

Product

Object Diagrams Object Diagrams describe the static structure of a system at a particular time. Whereas a class model describes all possible situations, an object model describes a particular situation. Object diagrams contain the following elements: Objects, which represent particular entities. These are instances of classes. Links, which represent particular relationships between objects. These are instances of associations.

Object Diagram
o1:Order
dateReceived = 01.11.11 number : A00121 price : 20500.00

C1:Customer
name = Ram address = Behala

CC:Corporate Customer

PC:Personal Customer
creditCard = 002210234501

contactName= Vicky creditRating = 2.0 creditLimit = 200000

E1: Employee OrderLine

Quantity = 400 price = 30450 isSatisfied = True

P: Product

Use Case Diagram

Used for describing a set of user scenarios Mainly used for capturing user requirements Work like a contract between end user and software developers

Use Case Diagram (core components)

Actors: A role that a user plays with respect to the system,including

human users and other systems. e.g.,inanimate physical objects (e.g. robot); an external system that needs some information from the current system.

Use case: A set of scenarios that describing an interaction between a user

and a system, including alternatives.

System boundary: rectangle diagram representing the boundary between

the actors and the system.

Use Case Diagram(core relationship)

Association: communication between an actor and a use case; Represented by a solid line.

Generalization: relationship between one general use case and a special use case (used for defining special alternatives) Represented by a line with a triangular arrow head toward the parent use case.

Use Case Diagram(core relationship)

Include: a dotted line labeled <<include>> beginning at base

use case and ending with an arrows pointing to the include use case. The include relationship occurs when a chunk of behavior is similar across more than one use case. Use include in stead of copying the description of that behavior.
<<include>>

Extend: a dotted line labeled <<extend>> with an arrow toward the base case. The extending use case may add behavior to the base use case. The base class declares extension points.
<<extend>>

Use Case Diagrams

Boundary Actor
Library System

Use Case

Borrow

Employee

Client

Order Title

Fine Remittance

Supervisor

A generalized description of how a system will be used. Provides an overview of the intended functionality of the system

Use Case Diagrams(cont.)

Sequence Diagrams Sequence Diagrams describe interactions among classes. These interactions are modeled as exchange of messages. These diagrams focus on classes and the messages they exchange to accomplish some desired behavior. Sequence diagrams are a type of interaction diagrams. Sequence diagrams contain the following elements: Class roles, which represent roles that objects may play within the interaction. Lifelines, which represent the existence of an object over a period of time. Activations, which represent the time during which an object is performing an operation. Messages, which represent communication between objects.

Sequence Diagram(make a phone call)

Caller
Picks up Dial tone

Phone

Recipient

Dial
Ring notification Ring

Picks up
Hello

Sequence Diagram

Collaboration diagrams
start 6: remove reservation 3 : [not available] reserve title

User
6 : borrow title 2: title data 1: look up 5: title available

Reservations

4 : title returned Catalog 5 : hold title

Shows the relationship between objects and the order of messages passed between them. between them. The objects are listed as rectangles and arrows indicate the messages being passed The numbers next to the messages are called sequence numbers. They show the sequence of the messages as they are passed between the objects. convey the same information as sequence diagrams, but focus on object roles instead of the time sequence.

Statechart Diagrams Statechart (or state) diagrams describe the states and responses of a class. Statechart diagrams describe the behavior of a class in response to external stimuli. These diagrams contain the following elements: States, which represent the situations during the life of an object in which it satisfies some condition, performs some activity, or waits for some occurrence. Transitions, which represent relationships between the different states of an object.

State Chart Diagram

Activity Diagrams Activity diagrams describe the activities of a class. These diagrams are similar to statechart diagrams and use similar conventions, but activity diagrams describe the behavior of a class in response to internal processing rather than external events as in statechart diagram. Swimlanes, which represent responsibilities of one or more objects for actions within an overall activity; that is, they divide the activity states into groups and assign these groups to objects that must perform the activities. Action States, which represent atomic, or noninterruptible, actions of entities or steps in the execution of an algorithm. Action flows, which represent relationships between the different action states of an entity.

Activity Diagrams (Cont...) Object flows, which represent the utilization of objects by action states and the influence of action states on objects.

Activity Diagram

Component Diagrams Component diagrams describe the organization of and dependencies among software implementation components. These diagrams contain components, which represent distributable physical units, including source code, object code, and executable code.

Component Diagram
policy.dll

[for withdrawal of cash]

Bank Server.exe customer.dll Branch Bank.dll

Branch Bank.exe ATM.exe

33

Deployment Diagrams Deployment diagrams describe the configuration of processing resource elements and the mapping of software implementation components onto them. These diagrams contain components and nodes, which represent processing or computational resources, including computers, printers, etc.

Deployment diagram
Branch Bank_ Bank.exe Ethernet Ethernet

ATM_ machine ATM.exe

Bank_ server BankServer.exe

35

Advantages of UML
UML is effective for modeling large, complex software systems It is simple to learn for most developers, but provides advanced features for expert analysts, designers and architects It can specify systems in an implementation-independent manner 10-20% of the constructs are used 80-90% of the time Structural modeling specifies a skeleton that can be refined and extended with additional structure and behavior Use case modeling specifies the functional requirements of system in an object-oriented manner

Thank You !!
Comments and questions