Home/ Questions/Q 7554071
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-30T11:14:15+00:00

I need to know, how to represent the sub modules of a module. For

  • 0

I need to know, how to represent the sub modules of a module.

For example i am having a module called X. This module X is actually made up of three sub modules called x1, x2 and x3. User can choose any of this sub module from the available options. That means this module does not exits with out this 3 sub modules. My doubt is that while drawing the use case diagram how can i represent this sub modules? I have to use “include” or “extend” for this sub modules from the main module?

Another doubt is that when i am drawing the use case diagram of x1. How can I represent a main work called “view location” and an optional work called “change map view”

Kindly explain the answer.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    First

    Use-Cases simply describe “what a user can do with your system”.

    This simple definion sometimes confuse many people:

    When we ask what can user do with your System, they tell the
    options-menus on early protype GUI.

    In your problem, I think you also talk about “GUI”. As I understand you have a GUI prototype,
    In which User choose “X Module” option, then you show user “X1,X1,X3” suboptions actions…

    Use Cases “does not interested in” your GUI details. It try to capture the real “motivation”…

    To make it clear: Suppose that you are designing that classic ATM Machine for a Bank.

    What a user wanted to make with an ATM? Suppose that he wanted to Pay his bills from ATM…

    Simple Use Case Digram For this:

    enter image description here

    But how he will pay his/her bills? This is captured by use case descriptions[ not diagram, use case text]…
    And suppose that our client say that User can pay those kind of bills: his/her CellPhone Bill, his/her Electricity Bill, may be His/her tax. And you capture that each of these payings have different characteristics.

    And you start writing your use case description in [ System do this, Actor do this] form

    Use Case : Pay Bill
    ……………….

    Main Scenario:

    1. System show ATM operations
    2. User chose PayBill Options

    3. System show those Pay Bill Operations

      A) Pay CellPhone Bill

      B) Pay Electricity Bill

      C)…

    4. User Select an options

    5. If User Select Pay Cell Phone Bill Then

      5.a) System ask for CellPhone Number..

      ……..
      …….

      5.n) System ask for if user want recipt

      5.n+1) User want a receipt

      5.n+2) System give a receipt
      …..

      …..

    6. If User Select Pay Electricity Bill Then
      …..
      …

    7. If User Selects X Options Then
      ….
      ….

    As a general rule do not make dirty your use case diagram with lots of
    “extends” or “include”, “generalize”

    So as a result: We can not know if “change map view” or “view location” is a real use case [ which we should show in diagram] or just a step in a use case senario. Those are depends on your context…

    As a practical advice you can apply Craig Larman 3 tests in order to find if those are real use cases:

    • Boss Test: Think like a “Boss”. And tell the actor[think actor as your employee] “change view”. Does this satisfy you as “Boss”. Or it is meanigless. For example “PayBill” for ATM pass boss test but “choose paying options ” does not.
    • Size Test: A real use case, has some size[scenarious] not a single step
    • A use case is complete: As a result of use case the user should got a real benefit.

    Finally,

    Use Cases are mainly texts:[Scenarious] Not Diagrams. Diagrams just
    give an overview of functional requirements. But just overview not
    details

    • 0