CS206 System Analysis & Design Note 15 By ChangYu 1 Lecture Note 15 Unified Modeling Language (UML)...

CS206 System Analysis & Design Note 15 By ChangYu

1

Lecture Note 15Unified Modeling Language (UML)

Use Case Diagram and Sequence Diagram

Systems Analysis and Design

Kendall & Kendall

Sixth Edition

Part V: Software Engineering and Implementation


2

Major Topics

• Use Case Diagram• Use Case Diagram Syntax• The steps for creating a Use Case Diagram• Sequence Diagram• Sequence Diagram Syntax• The steps for creating a Sequence Diagram


3

Object Modeling and UML

• Systems analysts use the UML to describe object-oriented systems.

• The UML uses a set of symbols to represent graphically the various components and relationships within a system.

• UML is mainly used to support object-oriented system analysis and to develop object models.

• The core of UML is formed by four techniques Use case Diagrams, Sequence Diagrams, Class Diagrams, and StateChart Diagrams.

• In this notes, we will introduce how to draw Use Case diagram and Sequence diagram.


4

Use Case Diagram• Use cases are the primary drivers for all the UML

diagramming techniques. A use case diagram illustrates the main functions of a system and the different kinds of users that interact with it.

• The Use Case diagram includes:

Actors: which are people or things that derive value from the system, and Use Cases: that represent the functionality of the system.Associations: Draw lines toconnect use cases and actors together.System boundary: which represents

the system.


5

• A use case may represent several paths that a user can take while interacting with the system.

• Drawn early on in the SDLC, when SA is gathering and defining requirements for the system.

• The actors and use cases are separated by a system boundary and connected by lines representing associations.• At time, actors are specialized versions of more general actors. Similarly, use cases can extend or include other use cases.


6

Five Steps Processes for Building Use Case Diagram

1. Identify Use Case: The analyst identifies the use cases and creates accompanying documentation, the use case report, to describe each function in detail.

2. Draws the system boundary: Place a box on the use case diagram to represent the system. place the system’s name on the top of the box.

3. Adds the use cases to the diagram: Place use cases inside the system boundary corresponding to the number of functions that the system must perform.

4. Identifies the actors: A person or another system that interacts with and derives value from the system.

5. Add Associations: Draw lines to connect use cases and actors together.


7

Example: This figure shows a use case diagram for a Doctor’s Office Appointment System.Patients, doctors, and management personnel will use the appointment system to make appointments, record

availability, and produce schedule information.


8

Symbols for Use Case Diagram

Actor

Symbol Meaning

Is a person or system that derives benefit from and is external to the system.

Use CaseRepresents a major piece of system functionality.

System Boundary

Represents the scope of the system.System Name

Name


9

Use Case Relationships


10

Actor• An actor is labeled stick figures.• Similar to an external entity found in DFDs.• A person or another system that interacts with and

derives value from the system.• It is not a specific user but a role that a user can play

while interacting with the system.• An actor requests the system to perform a function or

process.• Example : A data-entry clerk (or a nurse entering

patient information) would not be considered an actor because he or she would fall within the scope of the system itself.


11

• Sometimes an actor plays a specialized role of a more general type of actor.

• Then, a specialized actor (new patient) is placed on the model, shown using a line with a hollow triangle at the end of the more general superclass of actor (patient).

• The specialized actor will inherit the behavior of the superclass and extend (延伸 ) it in some way.


12

Example1: A new patient interacts with the system in a way that is somewhat different than for a general patient.


13

List Product

Order Product

Accept Payment

Sales System

Calculate Commission

Purchaser

Customer Salesman

Example2: This figure shows a use case diagram for Sales System. The specialized actors (customer and salesman ) will inherit the behavior of the more general superclass of actor (Purchaser).


14

Use Case• A use case, depicted by an oval in the UML, is a

major process performed by the system that benefits an actor in some way.

• It is labeled using a descriptive verb-noun phase.• Use case represents a major piece of system

functionality.• It describes a sequence of actions that the system

performs to achieve an observable result of value to an actor.

• One use case will sometimes use the functionality or extend or include the functionality of another use case on the diagram, and these are shown with “include” or “extend” associations.


15

Include relationship:• The includes relationships describes the situation in

which a use case contains behaviour that is common to more than one use case.

• In other words, the common use case is included in the other use cases.

• It can be used to separate out a sequence of behavior that us used in many use cases.

• It should not be used to create a hierarchical functional decomposition of the system.

• A dotted arrow points to the common use case indicates the includes relationship.


16

Example1: An example would be a use common Pay Student Fees that is included in Enroll in Course and Arrange Housing, because the both cases students must pay their fees.


17

Renew the books

Return the books

Borrow the books

Library System

Student

Check borrower’s Status

<<include>>

<<include>>

<<include>>

Example 2: This diagram shows the use case for Library System. The students can borrow the books, renew the books and return the books from the library using Library System.


18

Extent relationship:• The extends relationship describes the situation in

which one use case possesses the behavior that allows the new use case to handle a variation (變化 ) or exception (除外 ) from the basic use case.

• One use case provides additional functionality that may be required in another use case.

• There may be multiple ways of extending a use case, which represent variations in the way that actors interact with the use case.

• A condition can be placed next to the dependency arrow.

• The arrow goes from the extended to the basic use case.


19

Example 1: The extended use case Student Health Insurance extends the basic use case Pay Student Fees.

Basic Use Case

Extended Use Case


20

Example2: This figure is a use case for Car Rental System with an “extend” association relationship and an “include” association relationship.

<<include>>

Pick Up Car

Reserve Car

Car Rental System

Customer

Buy Insurance

<<extend>>

Return Car Generate Bill<<include>>


21

Example3: The doctor’s office system has three basic functions: make appointment, produce schedule information, record availability. Assume every time a patient makes an appointment, he or she is asked to confirm contact information and basic patient information to ensure that the system always contains the must up-to-date information on its patients.


22

Generalization relationship:• Represents a specialized use case to a more generalized one.• It is represented as an unlabeled hollow arrow, with more general

use case being higher than the lower use cases.• Example1: The Make appointment use case has been

specialized to include a use case for an OLD patient and a NEW patient. – The Make Old patient appointment use case inherits the

functionality of the a Make appointment use case and extends its own functionality with the Make payment arrangements use case.

– The Make New patient appointment use case also inherits all of the functionality of generic Make appointment use case and would include any functionality necessary to capture the information needed to insert the new patient into patient database.

– A second specialized actor, Old patient and that patient actor is now simply a generalization of the old and new patient actors.


23

Example1:


24

System Boundary

• When you create a use case diagram, the first step is to identify the system boundary, which is represented by a rectangle.

• The use case are enclosed within a system boundary.

• System Boundary, which is a box that represents the system and clearly delineates what parts of the diagram are external or internal to it.

• The name of the system can appear either inside or on top of the box.


25

Association

• Use cases are connected to actors through associations.

• Show the use cases that the actors interact • A line drawn from an actor to a use case, as

relation with no direction.


26

Creating a Use Case Diagrams

When diagramming a use case, start by asking the users to• List everything the system should do for them. This can be done

using interviews, in a joint application design sessions.

• Write down who is involved with each use case and the responsibilities or services the use case must provide to actors or other system.

• Review the business specifications and identity the actors in the problem domain.

• Identify the high-level events and develop the primary use case that describe those events and how the actors initiate them.

• Review each primary use case to determine the possible variations of flow through the use case.


27

Creating a Use Case Description

• The Use Case Description are needed before creating the use case diagram. The use case describes can be a step-up-step breakdown of interaction between actor and system.

• There is no standardized use case description format. • Often the use cases are documented using a use case

document template predetermined by the organization, which makes the use case easier to read and provides standardized information for each use case in the model.


28

The description may include the three main areas. Some of the areas included are optional and may not be used by all organizations.

1. Use case identifiers and initiators.

2. Steps performed.

3. Conditions, assumptions and questions.

1. Preconditions: the condition of the system before the use case may be performed.

2. Postconditions: the state of the system after the use case has finished.

3. Any assumptions made that would affect the method of the use case.

4. Any outstanding (未解决 ) issues or questions.

5. An optional statement of priority (优先 ) of the use case.

6. An optional statement of risk involved in creating the use case.


29

Use case identifiers and initiators.

Steps performed

Conditions, assumptions and questions.


30

Class WorkThis is a use case example of student enrollment at a

university. • The Add Student use case indicate that students could be added in

person, using Web, using a touch-tone telephone, or other methods. The Add Student use case includes the Verify Identity use case to verify the identity of the student.

• The Purchase Textbook use case extends the Enroll in Class use case, and may part of a system to enroll students in an online course.

• The Change Student Information use case allow student to changes their own personal information. Student could not to change grade, outstanding fees and other information. This use case also includes the Verify Identity use case, and in this situation, it means having the student enter a user ID and password before gaining access to the system.

• View Student Information allows students to view their personal information, as well as courses and grades.


31

Student Enrollment

System


32

Sequence Diagram

• Sequence Diagram illustrates a succession of interactions between classes or object instances over time.

• Sequence Diagrams are often used to illustrate the processing described in use case description.

• In practice, sequence diagrams are derived from use case analysis and are used in system design to derive the interactions, relationships and methods of the objects in the system.

• Sequence Diagrams are used to show the overall pattern of the activities or interactions in a use case.


33

• A dynamic model that shows the explicit sequence of messages that are passed between classes in a defined interaction, and they are very helpful for understanding real-time specifications and for complex scenarios.

• Generic (一般的 ) sequence diagram shows all possible scenarios for a use case.

• A set of instance sequence diagrams depicts a single scenario within the use case.

• Each use case scenario which is a single executable path through a use case, may create one sequence diagram.


34

Syntax for Sequence Diagram


35

Elements of a Sequence Diagram

Actor and Object• Actors and objects that participate in the

sequence diagram are placed across the top of the diagram using labeled rectangle.

• The leftmost is the starting object and may an actor, window, dialog box, or other user interface.

• Classes are not required to place in particular order, but it is nice to organize them in some logical way.


36

Lifeline• A dotted line runs vertically below each class to

denote the lifeline of the class instances over time.• Sometimes a class creates a temporary object and

in this case an X is placed at the end of the lifeline at the point the object is destroyed.

• When objects continue to exist in the system after they are used in the sequence diagram, then the lifeline continues to the bottom of the diagram.


37

Focus of Control• A vertical rectangle on the lifeline shows the focus

of control when the object is busy doing things.• This thin rectangle box is to show when the

classed are sending and receiving messages.• It may split into two or more concurrent (同時發生的 )

lifelines to show conditionality, whereby each separate track corresponds to a conditional branch in the message flow.

• It also may merge together at some subsequent point.


38

Message• It is a communication between classes. Horizontal

solid line with arrows show messages or signals that are sent between classes.

• The arrow on the link shows which way the message is being passed, and any argument values for the message are placed in parentheses next to the message’s name.

• The order messages go from the top to the bottom of the page. Therefore, the message located higher on the diagram means the message occur earlier in the sequence.


39

Example: Sequence diagram for Make Appointment


40

• This example illustrates an instance sequence diagram to reflect classes and messages for the scenario “manage appointment”.

• It describes the process by which a patient creates a new appointment, cancels or reschedules an appointment for the doctor’s office appointment system.

• The objects in this example are: APatient, aReceptionist, Patients, UnpaidBills, Appointments and anAppt.

objectName: a name with colon after it represents an object.

:class a colon with a name after it represents a class.

ObjectName::class a name, followed by a colon and another name, represents

an object in a class.

• Patient::List represents that Patients is an instance of the List class that contains individual patient objects.


41

• A dotted line denotes the lifeline of the class instances over time.

• LookUpPatient is a message sent from the object aReceptionist to the object Patients, which is a container for the current patients to determine whether the aPatient object is a current patient.

• There are times that a message is only sent if a condition is met and the condition is placed between a set of [], e, g. [aPatient Exists] LookUpBills(). Conditions are shown on a sequence diagram which models a specific scenario.


42

Six Steps for Creating a Sequence Diagram

1. Set the context.

2. Identify which objects will participate.

3. Set the lifeline for each object.

4. Lay out the messages from the top to bottom of the diagram based on the order in which they are sent.

5. Add the focus of control to each object’s lifeline.

6. Validate the sequence diagram.


Class Work

Apply the concepts at CD Selections Internet Sales System:

Step1: Determine the context of the sequence diagram. We will use a scenario from the place order use case ( show on next page) and list the Normal

flow of Events that contains the scenario which this sequence diagram will need to describe:


44


45

1. Customer submits a search request to the system.2. The System provides the Customer a list of

recommended CDs.3. The Customer chooses one of the CDs to find out

additional information.4. The System provides the Customer with basic

information and reviews on the CD.5. The Customer calls the Maintain Order use case. 6. The Customer iterates over 3 through 5 until

done shopping.7. The Customer executes the Checkout use case.8. The Customer leaves the Web site.


46

Step2: • Identify the objects that participate in the sequence

being modeled. • The objects that will be need to describe this

scenario are instances of the Search Request, CD List, CD, Marking Information, Customer, Review, Artist Information, Sample Clip , Shopping Cart classes. We also have an actor , Customer that interacts with the scenario.

• To complete this step, you should lay out the objects on the sequence diagram by drawing them, from left to right, across the diagram.


47

Step 3:• Set the lifeline for each object.• Draw a vertical dotted line below each of the objects.• Also, an X should be placed at the bottom of the

lifelines for aCDL and aSC since they go away at the end of this process.

Step 4:• Add the messages to the diagram.


48

Step 5:• Add the focus of control to each objects and actor’s

lifeline. This is done by drawing a narrow rectangle box over the top of the lifelines to represent when the object are sending and receiving messages.

Step 6:

Lastly, the CD Selections team validated the diagram by ensuring that the diagram accurately and completely represented the underlying process associated with the Place Order use case.


49

CS206 System Analysis & Design Note 15 By ChangYu 1 Lecture Note 15 Unified Modeling Language (UML)...

Documents

Transcript of CS206 System Analysis & Design Note 15 By ChangYu 1 Lecture Note 15 Unified Modeling Language (UML)...