I am working on an online exam management system, which have those main actors:-

  1. Super Admin. Can manage questions/answers under all functional areas.
  2. Functional Admin. Can add questions/answers under his/her functional area only
  3. Applicant. Attend the exam
  4. The system itself. with modules including; Exam creation, Adding Question/Answers,Reports, and so one..
  5. Technical users. who access the system to develop and maintain it

So now i have the following 4 questions about building a sequence diagram for this system:-

  1. Is it OK, if i deal with the system as separate modules? meaning that i will have different objects representing each of the system modules, rather than having the system as one object?

  2. can i have multiple actors under each other?

  3. is it correct to specify the fields that the actors will submit? for example when a admin create a new exam, he/she need to select the questions, give it an activation data, assign it to an applicant,specify the Category, Duration, and so on.. or inside the sequence diagram we only mentioned that action of creating a Exam, without giving further details.

  4. here what i started with any comments?

enter image description here

1 Answer 1


The system is not an actor. Moreover, if we take the UML specifications by the book,external actors should in principle not appear in a sequence diagram since they are external to the system, and the sequence diagrams is about parts belonging to the internals of the system. See this SO question for more details.

The practice of showing actors in sequence diagrams is nevertheless still quite popular. So, if you don't take UML too literally and want to use this representation:

  • You can of course replace a single system lifeline with multiple lifelines. You would then use subsystems and components (modules is not an UML concept).
  • Graphically, nothing prevents to have several lifelines for different objects arranged one under another. But you should avoid this, since it will confuse many readers. Prefer side by side, so that it is clear that it is a different lifeline.
  • Here we come back to my initial remark. The messages between a human actor and a system component are not specified in UML. The semantic is ambiguous. If you use this practice, up to you to make it as clear as possible. What works well is to use plain text rather than real operations and attributes.
  • About your diagram: you don't need a return message if there is no return value and you use a synchronous message (plain arrow head). And a return message (dotted line) should provide a value and not call an operation on the initiator of the exchange (i.e. issue with Get Answer(): if it's a callback, it should be a plain arrow, and ideally, you'd show an overlapping box in the exam).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.