0% found this document useful (0 votes)
5 views

Software Engineering Lab8

The document outlines the requirements modeling for a software engineering lab, focusing on use case diagrams and the relationships between actors such as Professors, Assistants, and Research Associates. It explains the inheritance of use cases and actors, as well as the correct associations necessary for executing various tasks within a university's student office system. Key use cases include managing student data, creating courses, and issuing certificates, with a focus on generalization to streamline the modeling process.

Uploaded by

cikif83366
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
5 views

Software Engineering Lab8

The document outlines the requirements modeling for a software engineering lab, focusing on use case diagrams and the relationships between actors such as Professors, Assistants, and Research Associates. It explains the inheritance of use cases and actors, as well as the correct associations necessary for executing various tasks within a university's student office system. Key use cases include managing student data, creating courses, and issuing certificates, with a focus on generalization to streamline the modeling process.

Uploaded by

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

KARABUK UNIVERSITY

Computer Engineering Department

CPE 310 Software Engineering


Lab#8
Requirements Modeling
Scenario-based methods: User Case Diagrams-III

Hasan Kivrak
Let the use case diagram speak
● Professor and Assistant inherit from the
actor Research Associate
○ every professor and every assistant is a research
associate.

○ every research associate can execute the use


case Query student data.

● Only professors can create a new course


(use case Create course);
● Tasks can only be published by assistants
(use case Publish task).
● To execute the use case Issue certificate
○ an actor Professor and Assistant is required
Example with and without generalization (between actors)
both actors must participate in each of them inherits the association. Then each
the use case actor participates in the use case individually
Incorrect associations
● If a use case is
associated with two
To resolve this
actors, it means that
problem, we can
both are necessary for its
execution. introduce a new
Research Associate
● The actors Assistant and actor from which
Professor are involved in the two actors
the execution of the use
Assistant and
case Issue information,
Professor inherit
which is not the
intention.
Example of generalization of use cases
● Generalization allows us to group the
common features of the two use cases

● The use case Announce event passes on its


properties and behavior to the use cases
Announce lecture and Announce talk.

○ As a result of an «include» relationship,


both use cases must execute the
behavior of the use case Assign
lecturer.

○ This means that we do not have to


model both the «include» relationship
and the association with the professor
twice.
Examples of relationships in a use case diagram
The use case H inherits from the use case C. As use case C is executed
by the actor L, an actor L must also be involved in the execution of H.
The actors N and M inherit from L. Therefore, both use cases C and H
can also be executed by an actor M or N.

The use case J inherits from the use case B. As a result of the
inheritance relationship, an actor O is involved in the execution of use
case J. However, an association with O is also modeled for J directly.
The consequence of this is that two actors in the role O are involved in
the execution of J. Note that these two actors can coincide.

The use case F inherits from the use case G. As a result of the
inheritance relationship, an actor N is involved in the execution of use
case F. For F, an association with the actor L is also modeled directly.
Therefore, an actor N and, due to the inheritance relationship of the
actors L, N, and M, either an actor L or an actor M or an additional
actor N is involved in the execution of F. If two actors N are involved,
they may coincide.

The use case I extends the use case F. As use case F inherits from use
case G and as I extends use case G, this relationship is passed on to F.
If G and I were in an «include» relationship, this relationship would
also be passed on to F in the same way

The use case J extends the use case H. This is as a result of the
inheritance relationships from B to J and from C to H.
Information system of student office of a university
● Modeling administrative activities of student ● Two types of employees in the student office:
office.
○ with the administration of student data
● Student office manage students data. (service employee, or ServEmp)

○ register for studies ○ fulfill the remaining tasks (administration


employee, or AdminEmp)
○ enroll, and withdraw students from
studies. ○ all employees (ServEmp and AdminEmp)
can issue information.
○ receive their certificates
● Administration employees
■ the certificates are printed out by an
○ issue certificates
employee.
○ create courses.
● Lecturers send grading information to the
student office. ■ when creating courses, they can
reserve lecture halls.
Identifying actors
● Lecturer

● Employees of the types

○ ServEmp and AdminEmp


Identifying use cases
● As the Register, Enroll, and Withdraw have
the association to ServEmp in common
○ introduce the use case Manage student data and
use cases Register, Enroll, and Withdraw inherit
from

● Lecturers can execute the use case Send


certificate.
● We have
○ Issue information,
○ Reserve lecture hall,
○ Create course, where Reserve lecture
hall extends the use case Create
course
Identifying associations
● The relationship between a use
case and an actor is referred to
as an association.
● To keep use case diagrams as
compact as possible
○ generalization is supported
for both actors and use
cases, which allows the
extraction of common
properties.
Notation elements for
the use case diagram

You might also like