Classification of UML Diagrams

Classification of UML Diagrams

Behavioral and Structural Perspectives of Unified Modeling Language UML
Any software system can have two aspects, static and dynamic. So a model is considered as complete when both the aspects are covered fully.

Structural Diagrams The structural diagrams represent the static aspect of the system. These static aspects represent those parts of a diagram which forms the main structure and therefore stable. Class Diagrams, Object Diagrams, Package Diagrams, Component Diagrams Deployment Diagrams

Behavioral Diagrams Behavioral diagrams basically capture the dynamic aspect of a system. Dynamic aspect can be described as the changing/moving parts of a system. Use case diagram Sequence diagram Collaboration diagram State chart diagram Activity diagram

Behavioral Diagram I Use case diagram

Use case Diagrams Use cases help with some of the most difficult aspects of a development process: model sequences of actions that are carried out by the system and that provide an observable result to someone or something outside the system; provide the basis for determining the interfaces to the system; model alternative scenarios for specific use cases that may result in different sequences of actions;

Use Case Diagrams Use case diagrams are a set of use cases, actors and their relationships. They represent the use case view of a system. A use case represents a particular functionality of a system. Use case diagram is used to describe the relationships among the functionalities and their internal/external controllers. These controllers are known as actors.

Use cases Define a piece of behavior of an “entity” without revealing the internal structure of the entity. The specification of sequences of actions, including variant sequences and error sequences, that a system or a class can perform by interacting with an external entity. Graphically, a use case is only given by

Actors Actor represents a coherent set of roles that users of use cases play when interacting with these use cases An actor represents a role that a human, a hardware device, or even another system plays with a system

Associations between Actors and Use Cases
Denote 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. Are the only relationships between actors and use cases. May have adornments (such as multiplicity and names).

Use Case Diagram A use case diagram is a diagram that shows a set of use cases and actors and their relationship. Use case diagrams commonly contain Use cases, Actors, Dependency, Generalization, and Association relationships Use case diagrams are applied to model the static use case view of a system by modeling the context of a system and by modeling the requirements of a system

Communication between Actors and Use Cases
One actor may communicate with several use cases of an entity, i.e. the actor may request several services of the entity. One use case communicates with one or several actors when providing its service. Two use cases specifying the same entity cannot communicate with each other since each of them individually describes a complete usage of the entity.

Modeling the Requirements of a System
Establish the context of the system by identifying the actors that surround it For each actor, consider the behavior that each expects or requires the system to provide Name these common behaviors as use cases Factor common behavior into new use cases that are used by others Factor variant behavior into new use cases that extend more main line flows Model these use cases, actors, and their relationships in a use case diagram

Modeling the Requirements of a System

Identifying Use Cases Identify potential services by answering the following questions from the point of view of each actor: What is the actor trying to accomplish? What does the actor need to be able to do? What are the main tasks of the actor? What information does the actor require from the system? What information does the actor provide to the system?

Modeling the Context of a System
Identify the actors that surround the system by considering which groups require help from the system to perform their tasks; are needed to execute the system’s functions; interact with external hardware or other software systems; perform secondary functions for administration and maintenance Organize actors that are similar to one another in a generalization / specialization hierarchy Populate a use case diagram with these actors and specify the paths of communication from each actor to the system’s use cases

Modeling the Context of a System

Modeling the Behavior of an Element

EXAMPLE

Organizing Use cases Generalization between Actors
by adding <<include>>, <<extend>> and generalization relationships between use cases. by grouping them into packages to define functional blocks of higher level. Generalization between Use Cases

<<include>> relationships between use cases
An include relationship between use cases means that the base use case explicitly incorporates the behavior of another use case at a location specified in the base.

<<include>> relationships between use cases
The behavior of the include use case is common to two or more use cases The result of the behavior that the include use case specifies is important to the base use case An include relationship points from the CheckorderStatus use case to the Login use case to indicate that the CheckOrderStatus use case always includes the behaviors in the Login use case.

<<extend>> relationships between use cases
The extend relationship contains a condition and references a sequence of extension points in the target use case. The condition must be satisfied if the extension is to take place, and the references to the extension points define the locations in the base use case where the additions are to be made.

specifyShippingInstuctions
Extension Points Details of the point or points in the use case at which the extension takes place can be shown in a extension point in the use case ellipse in the diagram. placeOnlineOrder specifyShippingInstuctions <<extend>> Extension point: conditions For example: The base use case is called placeOnlineOrder that has an extending use case called specifyShippingInstuctions. An extended relationship points from the specifyShippingInstuctions use case to the placeOnlineOrder use case to indicate that the behaviors in the specifyShippingInstuctions use case are optional and only occur in certain circumstances.

Include & Extend Relationships between Use Cases
An include relationship between use cases means that the base use case explicitly incorporates the behavior of another use case at a location specified in the base. An extend relationship between use cases means that the base use case implicitly incorporates the behavior of another use case at a location specified indirectly by the extending use case An extend relationship can be rendered as a dependency, stereotyped as extend. extension points are just labels that may appear in the flow of the base use case

Generalization- Include –Extend relationships between Use Cases

EXAMPLE

Key differences between «include» and «extend» relationships
Is this use case optional? Is the base use case complete without this use case? Is the execution of this use case conditional? Does this use case change the behavior of the base use case? Included use case Extending use case No Yes [ Source: Robert Maksimchuk & Eric Naiburg: UML for Mere Mortals, Addison-Wesley, ]

The nature of the «include» relationship

extending the primary Use Case

The Nature of the Generalization Relationship

Simple Use Case Example Online Bookshop Use Case Diagram

Simple Use Case Example Buy Goods

Example: Login Use Case?
BAD: GOOD: Landlord AddUser SetDevicePrefs Login AddUser SetDevicePrefs Landlord «include» Login

Another Exercise Who or what are the actors?
I am the manager of a theatre. I want to create an automated movie ticket machine. You are analysts who need to describe what the customer wants as a set of use cases Simplifying assumptions: One movie showing at a time Movie time is same every day, only one time, same price Only manager can change/add movie Customer can only buy tickets Who or what are the actors? What are the use cases (goals of actors)?

Use case diagram for Movie Ticket Machine
Why are there three Actors? Why three use cases for Customer? Which use cases look easy to write

Use cases for Manager Use case: Set title Use case: Set seats
Actors: Manager, Machine 1. Manager requests a change of movie title 2. Machine asks manager for new movie title 3. Manager enters movie title Use case: Set price 1. Manager requests a change of ticket price 2. Machine asks manager for new price for movie title 3. Manager enters ticket price Alternatives: Invalid price If manager enters price below $1 or greater than $10 3a. Machine asks manager to reenter price Use case: Set seats Actors: Manager, Machine 1. Manager requests a change in number of seats 2. Machine asks manager for number of seats in theatre 3. Manager enters number of seats Alternatives: Invalid number of seats If manager enters number less than 20 or greater than 999 3a. Machine asks manager to reenter number of seats

Use cases for Customer Use case: Buy tickets Actors: Customer, Machine
1. Customer requests tickets 2. Machine tells customer to put balance due in money slot 3. Customer enters money in money slot 4. Machine updates customer balance 5. Customer requests tickets 6. Machine prints tickets 7. Machine updates number of seats Alternative: Insufficient seats At step 1, if number of tickets requested is less than available seats, 1a. Display message and end use case Alternative: Insufficient funds At step 5, if money entered < total cost, 5a. Display insufficient amount entered 5b. Go to step 3

Behavioral Diagram II Sequence Diagram

Interaction Diagrams One of the subsets of Behavioral diagrams wherein Interaction diagrams graphically depicts the way objects interact with each other to give different behaviors. Interaction diagrams are sub classified into Sequence diagrams and Collaboration diagrams Sequence Diagrams are special type of Interaction Diagram which apart from graphically showing the object interaction specially focuses on the sequence and timing of interaction between the objects. Collaboration Diagrams are special type of Interaction diagrams which apart from graphically showing the object interaction focuses on the spatial distribution of the objects.

The Purposes of Interaction Diagrams
The interactive behavior of the system is visualized . Visualizing interaction is a difficult task. So the solution is to use different types of models to capture the different aspects of the interaction. The purposes of interaction diagram To capture dynamic behavior of a system. To describe the message flow in the system. To describe structural organization of the objects. To describe interaction among objects.

Sequence Diagram A sequence diagram is an interaction diagram.
The diagram deals with some sequences, which are the sequence of messages flowing from one object to another. Interaction among the components of a system is very important from implementation and execution perspective. Sequence diagram is used to visualize the sequence of calls in a system to perform a specific functionality.

Behavioral Diagram III
Collaboration Diagram

Collaboration Diagram
Collaboration diagram is another form of interaction diagram. It represents the structural organization of a system and the messages sent/received. Structural organization consists of objects and links. The purpose of collaboration diagram is similar to sequence diagram. But the specific purpose of collaboration diagram is to visualize the organization of objects and their interaction.

Structural Diagrams Class Diagrams, Object Diagrams, Package Diagrams,
Component Diagrams Deployment Diagrams

Structural Diagram I -II
Class Diagram Object Diagram

Class Diagram Class diagrams are the most common used in UML and most widely used diagrams at the time of system construction. Class diagram consists of classes, interfaces, associations and collaboration. Class diagrams basically represent the object oriented view of a system which is static in nature. Active class is used in a class diagram to represent the concurrency of the system. Class diagram represents the object orientation of a system. it is generally used for development purpose.

Object Diagram Object diagrams can be described as an instance of class diagram. These diagrams are more close to real life scenarios where we implement a system. Object diagrams are a set of objects and their relationships just like class diagrams and also represent the static view of the system. The usage of object diagrams is similar to class diagrams but they are used to build prototype of a system from practical perspective.

Object & Class Design Concepts
Objects represent “things” in real world – Provide understanding of real world – Form basis for a computer solution An Object (object instance) is a single “thing” – for example: an account, an employee A Class (object class) is a collection of objects with the same characteristics – for example: account, employee Attribute – Data value held by object in class – for example: account number, balance

UML notation for objects & classes

Example of classes and objects

Example of class with attributes

Associations Between Classes
Define structural relationships between classes – Depict classes and their relationships on class diagrams Relationships between classes – Associations – Composition / Aggregation – Generalization / Specialization Static Modeling during Analysis System Context Class Diagram – Depict external classes and system boundary Static Modeling of Entity classes – Persistent classes that store data

UML notation for relationship on class diagram

Associations Association is static, structural relationship between classes – for example: Employee works in Department Multiplicity of Associations – Specifies how many instances of one class may relate to a single instance of another class

Multiplicity of Associations
1-to-1 association – Company has President 1-to-many association – Bank manages Account Numerically specified association – Car has 2,4 Door Optional association (0 or 1) – Customer owns Debit Card Optional association (0, 1, or many) – Customer owns Credit Card Many-to-Many association – Course has Student – Student attends Course

Example: one-to-one association

Association : UML Notation
employs Employer class Employer { Employee[ ] employees; } class Employee Employer[ ] employers; Employee is employed by

Example: one-to-many Association

Optional (zero-or-one) Association

Optional (zero,one, or many) Association

Many-to-Many Association

Association Classes Class to model association between two or more classes – Usually for many- to- many associations – Attributes of Association Class For example: Many-to-many association between Project and Employee classes Project has Employee Employee works on project – Association Class - Hours Attribute - Hours Worked

Composition/Aggregation Hierarchy
Whole/Part Relationships – Show parts of more complex class – Composition is stronger relationship than aggregation IS PART OF Relationship – Between part classes and whole (composite or aggregate) class Composition is stronger relationship than aggregation Aggregation is stronger than association

Example:Composition Hierarchy
– Whole and part objects are created, live, die together – Often also has a physical association – Association between instances for example: Composite class - ATM – Part classes ATM customer Keypad Display Car reader Cash Dispencer ReceiptPrinter

Composition: UML Notation and Typical Implementation
Company att: int myFunction() composition Employee emp * * composition class Company { class Employee emp; { } } emp class EmployeeDirectory { class Employee emp; { } } EmployeeDirectory att: int myFunction()

Composition/Aggregation Hierarchy
– Part objects of aggregate object may be created and deleted independently of aggregate object for example: Aggregate class - College – Part classes Admin Office IS PART OF College Department College Research Center IS PART OF College

Example: Aggregation Hierarchy

Aggregation : UML Notation and Typical Implementation
Company att: int myFunction() aggregation Employee emp * * aggregation class EmployeeDirectory { Employee emp; int att; } class Company { Employee emp; int att; } emp EmployeeDirectory att: int myFunction()

Generalization / Specialization Hierarchy
Some classes are similar but not identical – Have some attributes in common, others different Common attributes abstracted into generalized class (superclass) – for example:. Account (Account number, Balance) Different attributes are properties of specialized class (subclass) IS A relationship between subclass and superclass – Savings Account IS A Account

Generalization / Specialization Hierarchy

UML Inheritance … and … Typical Implementation
package MyPackage; abstract class MyAbstractClass class MyDerivedClass extends MyAbstractClass { int att; void myFunction( ReferencedClass r ) { . .. } } MyPackage abstract class MyAbstractClass inheritance MyDerivedClass att: int myFunction() attribute operation

Interfaces UML Notation …… Typical Java Implementation
interface MyAbstractClass class MyClass implements MyInterface { } interface MyInterface myMethod() realization MyClass myMethod()

Dependence : UML Notation … and …Typical Implementation
MyDependentClass att: int myFunction() class MyDependentClass { void myFunction1( MyReferencedClass r ) { . .. } MyReferencedClass myFunction2( … ) void myFunction3( … ) { MyReferencedClass m … } MyReferencedClass dependence (reference to a class) parameter or return type or local variable type

Structural Diagram III
Component Diagram

Component Diagram Component diagrams represent a set of components and their relationships. These components consist of classes, interfaces or collaborations. Component diagrams represent the implementation view of a system. During design phase software artifacts (classes, interfaces ,… ) of a system are arranged in different groups depending upon their relationship. these groups are known as components. Component diagrams are used to visualize the implementation.

Component Diagrams Component diagrams are used in modeling the physical aspects of object-oriented systems. A component diagram shows the organization and dependencies among a set of components. Component diagrams are used to model the static implementation view of a system. Component diagrams are essentially class diagrams that focus on a system’s components. Component diagrams are used for visualizing, specifying, and documenting component-based systems and also for constructing executable systems through forward and reverse engineering.

Structural Diagram IV Deployment Diagram

Deployment Diagrams Shows the configuration of run time processing nodes and the components that live on them. Deployment diagrams are one of the two kinds of diagrams used in modeling the physical aspects of an object-oriented system. used to model the static deployment view of a system (topology of the hardware) A deployment diagram is just a special kind of class diagram, which focuses on a system’s nodes. Deployment diagrams are important for visualizing, specifying, documenting embedded, client/server, distributed systems managing executable systems through forward and reverse engineering.

Common Uses of Component Diagrams
Component diagrams are used in one of four ways To model source code To model executable releases To model physical databases To model adaptable systems

Modeling Source Code Either by forward or reverse engineering, identify the set of source code files of interest and model them as components stereotyped as files. For larger systems, use packages to show groups of source code files. Consider exposing a tagged value indicating such information as the version number of the source code file, its author, and the date it was last changed. Use tools to manage the value of this tag. Model the compilation dependencies among these files using dependencies

Modeling an Embedded System
Identify the devices and nodes that are unique to the system. distinguish processors (contain software components) and devices (at that level of abstraction, don’t directly contain software). Model the relationships among these processors and devices in a deployment diagram. Specify the relationship between the components in system’s implementation view and the nodes in system’s deployment view.

Modeling an Embedded System (the hardware for a simple autonomous robot)

Modeling a Client/Server System
Identify the nodes that represent system’s client and server processors. For example, a special device is modeled , such as credit card readers, badge readers, and display devices other than monitors, because their placement in the system’s hardware topology are likely to be architecturally significant. Provide visual cues for these processors and devices via stereotyping. Model the topology of these nodes in a deployment diagram. Specify the relationship between the components in system’s implementation view and the nodes in system’s deployment view.

Modeling a Client/ Server System the topology of a human resources system.
The system follows a classical client/server architecture

The Difference between Component and Deployment Diagrams
Component diagrams are dependent upon the classes, interfaces ,…..which are part of class/object diagram. The deployment diagram is dependent upon the components which are used to make a component diagrams.

Modeling a Fully Distributed System
Suppose that the system’s devices and processors as for simpler client/server systems are identified If the performance of the system’s network or the impact of changes to the network is important , it is required to model these communication devices in detail that is sufficient to make these assessments. It is required more attention to logical groupings of nodes, which can be specified by using packages. These devices and processors are model by using deployment diagrams.

Modeling a Fully Distributed System

MSG Foundation Information System
Case Study MSG Foundation Information System

The Initial Functional Model: MSG Foundation
Recall the seventh iteration of the use-case diagram

Use Case Manage a Mortgage
One possible extended scenario

Use Case Manage a Mortgage
A second extended scenario

Use Case Estimate Funds Available for Week
One possible scenario

Use Case Produce a Report
One possible scenario

Use Case Produce a Report
Another possible scenario

The Initial Class Diagram: MSG Foundation
The aim of entity modeling step is to extract the entity classes, determine their interrelationships, and find their attributes Usually, the best way to begin this step is to use the two-stage noun extraction method

Noun Extraction: MSG Foundation
Stage 1: Describe the information system in a single paragraph Weekly reports are to be printed showing how much money is available for mortgages. In addition, lists of investments and mortgages must be printed on demand.

Noun Extraction: MSG Foundation
Nouns report and list are not long lived, so they are unlikely to be entity classes (report will surely turn out to be a boundary class) money is an abstract noun This leaves two candidate entity classes Mortgage Class and Investment Class

Noun Extraction: MSG Foundation (contd)
Stage 2: Identify the nouns in this paragraph Weekly reports are to be printed showing how much money is available for mortgages. In addition, lists of investments and mortgages must be printed on demand. The nouns are report, money, mortgage, list, and investment

First Iteration of the Initial Class Diagram

Second Iteration of the Initial Class Diagram
Operations performed on the two entity classes are likely to be very similar Insertions, deletions, and modifications All members of both entity classes have to be printed on demand Mortgage Class and Investment Class should be subclasses of a superclass called Asset Class

Second Iteration of Initial Class Diagram

Back to the Requirements Workflow
The current five use cases include Manage a Mortgage and Manage an Investment These two can now be combined into a single use case, Manage an Asset

Eighth Iteration of the Use-Case Diagram
The new use case is shaded

Initial Class Diagram: MSG Foundation
Finally, we add the attributes of each class to the class diagram For the MSG Foundation case study, the result is shown on the next slide The empty rectangle at the bottom of each box will later be filled with the operations of that class

Second Iteration of Initial Class Diagram (contd)

Estimate Funds Available for Week Use Case

Description of use case

The six classes that enter into this use case are: User Interface Class This class models the user interface Estimate Funds for Week Class This control class models the computation of the estimate of the funds that are available to fund mortgages during that week Mortgage Class This class models the estimated grants and payments for the week Investment Class This class models the estimated return on investments for the week MSG Application Class Estimated Funds Report Class This class models the printing of the report

Scenario (one possible instance of the use case)

Sequence diagram equivalent to the collaboration diagram (of the realization of the scenario of the use case)

Manage an Asset Use Case

One scenario of the use case

Sequence diagram equivalent to the collaboration diagram (of the realization of the scenario of the use case)

A different scenario of the use case

Boundary class User Interface Class appears in all the realizations The same screen will be used for all commands of the information system

Classification of UML Diagrams

Similar presentations

Presentation on theme: "Classification of UML Diagrams"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Classification of UML Diagrams

Similar presentations

Presentation on theme: "Classification of UML Diagrams"— Presentation transcript:

Similar presentations

About project

Feedback