Project Part III: Sequence and Class Diagram
Requirements
This section outlines the technical requirements for preparing the six Sequence Diagrams and the Class Diagram
for your system.
Use Case Selection Requirement
When selecting the six use cases for sequence diagram development, students must choose the use cases with
the highest priority based on the overall system requirements. Priority should be determined according to factors
such as business importance, system criticality, user impact, and frequency of [Link] low-priority or
optional use cases may result in a loss of points.
1. Sequence Diagram Requirements
You are required to select six use cases from the use case diagram you prepared in Part 2. For each selected
use case, create a separate sequence diagram. Each diagram must include all components listed below.
1.1 Actors
Actors initiating or interacting with the system must be explicitly shown. These may include users or external
systems.
1.2 Classes / Objects
System components involved in carrying out the use case must be represented as lifelines.
Typical examples include:
● Controller classes
● Service classes
● Repository or database interfaces
● External subsystems or APIs
1.3 Message Types
All messages must be modeled according to UML standards. The following message types are required where
appropriate:
● Synchronous Messages : Method calls or interactions where the sender waits for a response.
● Asynchronous Messages : Notifications or trigger signals that do not require an immediate response.
● Return Messages :Return values or outcomes sent back to the caller.
1.4 Combined Fragments
If your use case contains alternative, optional, parallel, or repeated flows, the corresponding UML combined
fragments must be used:
● alt: Alternative flows
● opt: Optional steps
● loop: Repetitive or iterative processing
● par: Concurrent or parallel execution (when applicable)
If your use case includes alternate or optional scenarios, these must be reflected using the appropriate fragment
types. Diagrams omitting required fragments will be considered incomplete.
1.5 Consistency with Fully Dressed Use Cases
Each sequence diagram must be directly derived from the corresponding fully dressed use case. The following
elements must align clearly:
● Trigger :First message in the sequence
● Basic flow : Main message sequence
● Alternative flows : Represented through alt or opt fragments
● Pre/Post conditions : Reflected in the initial and final states of the diagram
2. Class Diagram Requirements
Prepare a Class Diagram representing the overall structural design of your system. The following technical
components must be included.
2.1 Class Names
Each class must be clearly named and represent a meaningful system component.
2.2 Attributes
Attributes must be listed for every class and include appropriate data types.
Examples:
● userId: int
● email: String
● price: double
2.3 Methods
Each class must include its operations, written according to UML notation.
Parentheses are required for all method names.
Examples:
● login()
● calculateTotal()
● validateCredentials()
2.4 Relationships Between Classes
You must correctly represent the relationships among classes using UML-standard notations:
● Association: General class relationships. Multiplicity (e.g., 1..*, 0..1) must be shown.
● Generalization (Inheritance): When a subclass extends a superclass.
● Composition: Whole–part relationships where the part cannot exist independently.
● Aggregation (optional): Whole–part relationships where the part can exist independently.
Use correct arrows, diamonds, and multiplicity indicators.
3. Submission Requirements
You must submit the following documents:
1. Six Sequence Diagrams, each corresponding to a selected use case.
2. One Class Diagram representing the system architecture.
All submissions must be in PDF format.