Scribd
Upload
52 views15 pages

Use Case Diagram: Behavioral Modeling

1. The document describes a use case diagram modeling technique for representing actors, use cases and their relationships in a system. 2. It explains that a use case diagram visually depicts use cases as ellipses and actors as stick figures that interact with the use cases. 3. Common relationships shown include generalization, inclusion and association between use cases and actors.

Uploaded by

Pallavi Bharti
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
52 views15 pages

Use Case Diagram: Behavioral Modeling

1. The document describes a use case diagram modeling technique for representing actors, use cases and their relationships in a system. 2. It explains that a use case diagram visually depicts use cases as ellipses and actors as stick figures that interact with the use cases. 3. Common relationships shown include generalization, inclusion and association between use cases and actors.

Uploaded by

Pallavi Bharti
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 15

Behavioral Modeling:

Use Case Diagram


Use Cases and Actors:
1. Use Cases: A use case is a description of a set of sequences of actions,
including variants, that a system performs to yield an observable result of value
to an actor. Graphically, a use case is rendered as an ellipse.
• Actor: An actor represents a coherent set of roles that users
of use cases play when interacting with these use cases.
• Typically, an actor represents a role that a human, a hardware
device, or even another system plays with a system.
Use Cases and Flow of Events
• A use case describes what a system (or a subsystem, class, or interface)
does but it does not specify how it does it.
• You can specify the behavior of a use case by describing a flow of events in
text clearly enough for an outsider to understand it easily. When you write
this flow of events, you should include how and when the use case starts
and ends, when the use case interacts with the actors and what objects
are exchanged, and the basic flow and alternative flows of the behavior.
• you might describe the use case ValidateUser in the following way:
• Main flow of events:
• Exceptional flow of events:
• Exceptional flow of events:
• Exceptional flow of events:
Use Cases and Collaborations
• you can explicitly specify the realization of a
use case by a collaboration
Organizing Use Cases
• You can organize use cases by grouping them in packages in
the same manner in which you can organize classes.
• You can also organize use cases by specifying generalization,
include, and extend relationships among them.
• 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.
Use Case Diagrams
• Use case diagrams are one of the five diagrams in the UML for
modeling the dynamic aspects of systems Each one shows a
set of use cases and actors and their relationships.
• Terms and Concepts: A use case diagram is a diagram
that shows a set of use cases and actors and their
relationships.
• Common Properties: A use case diagram is just a special kind
of diagram and shares the same common properties as do all
other diagrams, a name and graphical contents that are a
projection into a model.
• Contents: Use case diagrams commonly contain
· Use cases
· Actors
· Dependency, generalization, and association relationships
Common Modeling Techniques
• i) Modeling the Context of a System
ii) Modeling the Requirements of a System
• Problem Statement :
• Assign the task to develop a new student registration system. The college
would like a new client-server system to replace its much older system
developed around mainframe technology. The new system will allow
students to register for courses and view report cards from personal
computers attached to the campus LAN as well as over the Internet.
Professors will be able to access the system to sign up to teach courses as
well as record grades.
• Due to a decrease in federal funding, the college cannot afford to replace
the entire system at once. The college will keep the existing course catalog
database where all course information is maintained. The legacy system
performance is rather poor, so the new system must ensure that access to
the data on the legacy system occurs in a timely manner. The new system
will access course information from the legacy database but will not
update it. The registrar’s office will continue to maintain course
information through another system.
• At the beginning of each semester, students may request a course
catalogue containing a list of course offerings for the semester.
Information about each course, such as professor, department, and
prerequisites, will be included to help students make informed decisions.
• The new system will allow students to select four course offerings for the
coming semester. In addition, each student will indicate two alternative choices
in case the student cannot be assigned to a primary selection. Course offerings
will have a maximum of ten students and a minimum of three students. A
course offering with fewer than three students will be cancelled. For each
semester, there is a period of time that students can change their schedule.
Students must be able to access the system during this time to add or drop
courses. Once the registration process is completed for a student, the
registration system sends information to the billing system so the student can
be billed for the semester. If a course fills up during the actual registration
process, the student must be notified of the change before submitting the
schedule for processing.
• At the end of the semester, the student will be able to access the system to
view an electronic report card. Since student grades are sensitive information,
the system must employ extra security measures to prevent unauthorized
access.
• Professors must be able to access the on-line system to indicate which courses
they will be teaching. They will also need to see which students signed up for
their course offerings. In addition, the professors will be able to record the
grades for the students in each class.

You might also like