1

So, I have designed a use case for a student online system. The issue is that some of my base cases are subdivided into many included cases. For instance, to generate marksheet as a staff, my included use cases are: select student, select course, select module, select semester

In my class diagram, should i have methods for all of the smaller use cases or just the main one like generateMarksheet?

  • None of _select student, select course, select module, select semester_ are use cases. They are actions. – qwerty_so Jun 06 '20 at 13:06
  • Your question is strange, if I rewrite it it is like *do I have to implement all the system described though the use cases ?*, I think the answer is quite obvious ... if you want to be paid ^^ – bruno Jun 06 '20 at 16:42
  • @bruno i did not get you –  Jun 07 '20 at 13:34
  • @qwerty_so how do you differentiate them? –  Jun 07 '20 at 13:35
  • Basically see Christophe's answer. A use case has to add value to it's primary actor. If that's not the case you don't have a use case but only an action in some activity. – qwerty_so Jun 07 '20 at 13:49

1 Answers1

2

In short

No, that's not how it works.

Some more details

There is no direct mapping in general

Use-cases are about the requirements from a user perspective. So it's about the problems to solve. Typically they represent high level goals for the user such as Manage students or Subscribe to courses.

The classes of your system are about a technical solution that meet these requirements. In general however, there is no direct mapping as you describe: the behavior of the system emerge from the interaction between many classes within the system.

There are some methods to link both worlds

If you want a link between both worlds, you may follow the unified process that was promoted by the founding fathers of UML:

  • You start with your use-cases
  • You create an ECB class model for the analysis, in which you show a control class for every single use case, a boundary class for every association between a use case and an actor, and an entity class for every domain object that you can derive from the narrative.
  • You then think a little more about boundaries and controls, to see if there are some overlaps, or even reuse.
  • Then you think of designing your system. But the level of detail will be much higher. You'll end up mapping your own solution classes to the analysis classes for the purpose of traceability: for every class you can find back the use-case(s) to which it relates. And conversely.

But this approach has lost traction in an agile context. And also because solution design is often heavily influenced by architectural models chosen (such as MVP, MVVM, clean architecture,...) and these have a different logic than ECB (despite some apparent and misleading similarities), so that this analysis step is not adding sufficient value.

Morover, agile methods try to avoid a big up-front analysis that is required for a rigorous ECB approach.

Christophe
  • 68,716
  • 7
  • 72
  • 138