Uml Presentation - Rabobank

UML • What is UML ? • UML is a language for Documenting • Building Blocks of the UML

What Is UML “The Unified Modeling Language(UML) is a graphical language for visualizing, specifying, constructing, and documenting the artifacts of a Software-intensive system.The UML offers a standard way to write a system blueprints, including conceptual things like business process and system function as well as concrete things such as programming language statements, database schemas, and reusable software components”

UML is a language for Documenting A healthy S/W organization produces all sorts of artifacts in addition to raw executable code. These artifacts include • • • • • • • •

Requirements Architecture Design Source code Project plans Tests Prototypes Releases

Building Blocks of the UML The vocabulary of the UML encompass three kinds of building blocks

• Things • Relationships • Diagrams

Things in the UML Things in the real world are represented as objects, in the same way that things in the constructed world are. There are four kinds of things in UML:

• • • •

Structural things Behavioral things Grouping things Annotation things

Structural things Structural things are the nouns of UML models. These are mostly static parts of a model, representing elements that are either conceptual or physical. In all , there are 7 kinds of structural things.

• • • • • • •

Classes Interfaces Collaborations Use Cases Active Classes Components Nodes

Behavioral Things Behavioral things are the dynamic parts of UML models. These are the verbs of an model, representing behavior over time and space. In all there are two primary kinds of behavioral things.

• Interaction • State machine

Grouping Things Grouping things are the organizational parts of UML models. These are the boxes into which a model can be decomposed. In all there is one primary kind of grouping thing, namely, Packages

Annotational Things Annotational things are the explanatory parts of UML models. These are the comments you may apply to describe.

Inheritance 1. Class B extends Class A

2. “is - a” , “type-of” relationship 3. Relation is shown by hollow arrow head 4.Class A is Generalized form of Class B 5.Class B is Specialized form of Class A

Realization 1.

Class A implements interface B

2.

Class realizes interface B

3.

Relationship is shown by dotted line and hollow arrow head pointing a interface

Association 1.

Class A is associated with Class B

2. It is classified into Aggregation and Composition

Unidirectional

Relationship is shown by continuous line

Bidirectional

Associations 1. 2. 3.

Association can have name and you can use that name to describe the nature of relationship When a class participates in an association, it has a specific role which it can play in the relationship. You can show roles in diagram.

Multiplicity

The above relationship can be read as following : For each instance of course offering , there can be either 0 or 1 Professors or instructors For each instance of Professor , many course offerings may be taught. Multiplicity should always be read from 1 to many .

Dependency 1. 2. 3. 4. 5.

Class A depends on Class B. Relationship is shown by dotted line and a arrow head. Any change to independent thing will affect the dependent thing. Any change is specification of class B may affect class A which uses it but not viceversa. This relationship can be shown between packages.

(source)

(target)

Aggregation 1. Type of Association 2. Represents a whole part relationship. It’s a “has-a ” relationship. 3. Relationship is represented by a hollow diamond and continous line 4. Diamond is towards whole part 5. A has B as a part of it. 6. A exists even if B is deleted 7. Loose bonding 8.

For example : Assembly – Parts : Aircraft - Engine

Composition 1. 2. 3. 4. 5. 6. 7. 8.

Type of association Represents a whole part relationship.It’s a “has-a” relationship. Relationship is represented by shaded diamond and a continuous line Diamond is towards whole part A consists of B. A gets deleted when B is deleted. It’s a on-delete cascade Tight bonding. For example : Library : Books -- Whole : Parts

Overriding 1. 2.

If we show a method in Parent class as well as Derived class. It implies that Overriding is depicted in the class diagram.

If the method is not shown in derived class then it implies that derived class has that method from parent class

Rose diagram of a Class 1. 2. 3. 4. 5. 6. 7. 8.

The diagram shows a class Operation. Variable name is of String datatype with access specifier as Private. Method3() has a return type as Long with access specifier as Private. Private is shown in Rational Rose as a lock symbol. Variable age is of Long datatype with access specifier as Protected. Method2() has a return type as Double with access specifier as Protected. Variable status is of Boolean datatype with access specifier as Public. Method1() has a return type as Boolean with access specifier as Public.

In UML + Public - Private # Protected

Rose Facility On suppressing the attributes class looks like the following

On suppressing operations and attributes class looks like the following

UML Notations Package Name

Component

Note Textual content

Analysis Entity Class

Analysis Boundary Class

Analysis Control Class

UseCase

Action

Actor

OOA Object Oriented Analysis 1. 2. 3. 4. 5. 6.

This is problem phase Ask question WHAT ????? WHAT is it that the system should do ? WHAT will be the classes ? WHAT will the classes do ? ( functionality aspect ) WHAT will be relationships between classes ?

OOD Object Oriented Design 1. 2. 3. 4. 5. 6.

This is solution phase Ask question HOW ????? HOW will classes handle responsibility ? HOW will the classes communicate with each other ? HOW will I define attributes and methods ? HOW will be the implementation ?

Structural View

1. 2.

This has Object and class diagrams . Static in nature

Implementation View

1.

This has Component diagram.

Environment View

1.

This has Deployment diagram.

Behavioral View

1. 2. 3. 4. 5.

Sequence Diagram Collaboration Diagram State Chart Diagram. Activity Diagram. All of the above represent Dynamic behavior.

Use Case Analysis 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.

Emphasize on finding external behavior of system. Determine all possible users and actors. Determine interaction between actors and services. Describe each use case in terms of scenario. Determine relationships if any , between Use Cases. Use Case implies Functionality. Direction of arrow in Use Case diagram shows initiation of data flow. Don’t consider Acknowledgments , Exception in Use Case diagram . Exception is data driven. Generally humans have unidirectional use case. Actors can be shown with inheritance. Actors are roles to be shown.

Use Case Relationships 1. 2. 3. 3.a 3.b 4. 5. 6.

Relationship shown is extend between Buy Merchandise and Browse use case. EXTENDS implies optional relationship. Any of the following situation will occur. User will login and browse the online shopping site and leave. User will login , browse and Buy Merchandise. So we can interpret this as Buy only after browsing . Browse but don’t buy. Use this when you think its ADD-ON to existing functionality.

Use Case Relationships 1. 2. 3. 4.

Relationship shown here is include. INCLUDE implies compulsory. Customer Order use case sends data to Delivery centre regarding details of order. Customer Order use case must have knowledge of Payment Details use case.

Relationships shown in Use Case diagram Some other relationships which can be shown in Use case diagram.

Indicates bidirectional relationship

One user extending other user

Sequence Diagrams 1. 2. 3. 4. 5.

6. 7. 8.

Interaction Diagrams

They show a set of objects and messages sent and received by those objects. The objects are named or anonymous instances of classes. Distinguishing features of these diagrams are object lifeline and focus of control. Object lifeline : It shows existence of a object over a period of time. It’s a vertical dashed line. Focus of Control : It’s a tall , thin , rectangle that shows period of time during which object is performing an action , either directly or through subordinate procedure. The top of rectangle is aligned with start of procedure and bottom with completion. You can show recursion , self operation . This diagram is with respect to time. Models dynamic aspect of systems.

Collaboration Diagrams 1. 2. 3. 4. 5. 6. 7. 8.

Interaction Diagrams

They show the interaction between objects. You can render the links that connect the objects and adorn these links with messages that objects send and receive. Special features of these diagrams are path and sequence number. Path : Indicates how one object is linked to another. Sequence number : To indicate the order of message flow. [ 1 is the first message . 1.1 is the first nested message in message 1 . Similarly for 1.2 ] Iteration can be shown by interaction expression [ I := 1…n ] To model a condition , prefix sequence number by say [ x > 0 ] Models dynamic aspect of systems.

Activity Diagrams 1. 2.

Used for modeling dynamic aspect of system. Shows the flow from activity to activity . Activities result in some action which can result in a change in state of system. 3. Initial state of activity is shown by solid ball and stop state by solid ball in a circle. 4. Similar to flowchart you can include a branch which specifies alternate paths based on some condition. 5. Fork represents the splitting of a single flow of control into 2 or more concurrent flows of control. Below the fork we show activities in parallel. 6. We can show sequential or concurrent flows. 7. Join represents synchronization of two or more concurrent flows. It can have two or more incoming transitions and once outgoing transition. Above the join activities can go on in parallel. 8. Forking and Joining is shown by Synchronization bar and its shown by a thick horizontal line. 9. Number of flows that leave a fork should match number of flows that enter a join. 10. You can partition activity diagrams into groups. Each group is called swim lane as groups can be divided vertically. Each swim lane has a unique name.

State Chart Diagrams 1. 2. 3. 4. 5. 6. 7.

For modeling dynamic aspects of system. Used for modeling lifetime of object. Models flow of control from event to event. It contains Simple and composite states. Stable state of an object is the one in which the object may live for a period of time. Events that trigger a transition from state to state and actions that occur on each state change can be depicted. In reaction to event or a state change , object may respond by dispatching an action.

Component Diagrams 1. 2. 3. 4. 5. 5.1 5.2 5.3 5.4 6.

It shows the organization dependencies among a set of components. Deployment components : these are necessary and sufficient to form an executable system such as (DLL’s , Exe’s). Work product components: these are residue of development process , such as code files , data files from which deployment components are created. Execution components: these are created as a consequence of an executing system , such as COM+ object , which is instantiated from DLL. Stereo Types for components : executable : component that may be executed library : static or dynamic object library table : database table file : document containing source code or data . Main purpose of of using components is to model the deployment components.

Deployment diagrams 1. 2. 3. 4. 5.

They are used to model physical aspects of a system. Models static deployment view of system. Topology of hardware. Useful in communication between project’s hardware engineers and software engineers. Dependency and Association relationships can be shown. Typically we show servers , local network , console etc. in this diagram.

Run Payroll Brief Description The Use case describes how the payroll is run every Friday and the last working day of the month. Flow of Events The use case begin when it’s time to run the payroll. The Payroll is run automatically every Friday and the last working day of the month. 1.The System retrieves all employees who should be paid on the current date. 2.The system calculates the pay using entered timecards, purchase order, employee information(e.g. salary, benefits, etc.) and all legal deduction. 3.If the payment delivery method is mail or pick-up, the system prints a paycheck. 4.If the payment delivery method is direct deposit, the system creates a bank transaction and sends it to the Bank System for Processing. 5.The use case ends when all employees receiving pay for the desired date have been processed.

Use Case Diagram

Class Diagram

Sequence Diagram

Collaboration Diagram

Deployment Diagram

State Diagram