classification of uml diagrams. behavioral and structural perspectives of unified modeling language...
TRANSCRIPT
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 diagramSequence diagramCollaboration diagramState chart diagramActivity 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 casesDefine 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 DiagramA 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 itFor each actor, consider the behavior that each expects
or requires the system to provideName 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 SystemIdentify 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
maintenanceOrganize actors that are similar to one another in a
generalization / specialization hierarchyPopulate 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 ActorsOrganizing Use Cases
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.
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.
<<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
<<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.
Extension PointsDetails 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
Extension point: conditions <<extend>>
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 caseAn 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
No Yes
No Yes
No Yes
[ Source: Robert Maksimchuk & Eric Naiburg: UML for Mere Mortals, Addison-Wesley, 2005. ]
The nature of the «include» relationship
extending the primary Use Case
The Nature of the Generalization Relationship
Simple Use Case ExampleOnline Bookshop Use Case Diagram
Simple Use Case ExampleBuy Goods
Example: Login Use Case?
AddUser
SetDevicePrefsLandlord
«include»
«include»
LoginLandlord
AddUser
SetDevicePrefs
Login
BAD: GOOD:
Another ExerciseI 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 casesSimplifying assumptions:
One movie showing at a timeMovie time is same every day, only one time, same
priceOnly manager can change/add movieCustomer can only buy tickets
Who or what are the actors?What are the use cases (goals of actors)?
Use case diagramfor Movie Ticket Machine
Why are there three Actors?Why three use cases for Customer?Which use cases look easy to write
Use cases for ManagerUse case: Set titleActors: Manager, Machine1. Manager requests a change of movie
title2. Machine asks manager for new
movie title3. Manager enters movie titleUse case: Set priceActors: Manager, Machine1. Manager requests a change of ticket
price2. Machine asks manager for new price
for movie title3. Manager enters ticket priceAlternatives: Invalid priceIf manager enters price below $1 or
greater than $103a. Machine asks manager to reenter
price
Use case: Set seatsActors: Manager, Machine1. Manager requests a change in number of seats2. Machine asks manager for number of seats in theatre3. Manager enters number of seatsAlternatives: Invalid number of seatsIf manager enters number less than 20 or greater than 9993a. Machine asks manager to reenter number of seats
Use cases for CustomerUse case: Buy ticketsActors: Customer, Machine1. Customer requests tickets2. Machine tells customer to put balance due in money slot3. Customer enters money in money slot4. Machine updates customer balance5. Customer requests tickets6. Machine prints tickets7. Machine updates number of seatsAlternative: Insufficient seatsAt step 1, if number of tickets requested is less than available seats, 1a. Display message and end use caseAlternative: Insufficient fundsAt step 5, if money entered < total cost,• 5a. Display insufficient amount entered • 5b. Go to step 3
Behavioral Diagram II Sequence Diagram
Interaction DiagramsOne 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 diagramsSequence 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 diagramTo 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.
Case StudyMSG Foundation Information
System
The Initial Functional Model: MSG Foundationl 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
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
Eighth Iteration of the Use-Case DiagramThe 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
Estimate Funds Available for Week Use Case
Description of use case
Estimate Funds Available for Week 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 • This class models the estimated return on investments for the week
– Estimated Funds Report Class • This class models the printing of the report
Estimate Funds Available for Week Use Case
Scenario (one possible instance of the use case)
Estimate Funds Available for Week Use Case
Sequence diagram equivalent to the collaboration diagram (of the realization of the scenario of the use case)
Manage an Asset Use Case
• Use case
Manage an Asset Use Case
One scenario of the use case
Manage an Asset Use CaseSequence diagram equivalent to the collaboration diagram (of the realization of the scenario of the use case)
Manage an Asset Use Case
• A different scenario of the use case
Manage an Asset Use CaseBoundary class User Interface Class appears in
all the realizations– The same screen will be used for all commands of
the information system
Update Annual Operating Expenses Use Case
Equivalent sequence diagram
Produce a Report Use Case
Produce a Report Use Case
Descriptionof use case
Produce a Report Use Case
One scenario of the use case
Produce a Report Use Case (cont’d)
• Sequence diagram
Produce a Report Use Case (cont’d)
• Sequence diagram for second scenario