Re: Use cases question

Responding to Santiago...

I am reading "UML 2 for dummmies" (for me :) ). It says when I have collected the use cases and describe it as seen by the actors. After that says I represent the system as a class with use cases as operations.

I assume what the book is referring to in the last sentence is application partitioning. It happens to be convenient to think of a subsystem as a class on steroids because all the same OO principles of encapsulation, cohesion, implementation hiding, etc. apply to subsystems in much the same way that they apply to objects.

I can also see where one could define operations in the subsystem "class" as use cases as a means of organizing the allocation of requirements. However, there are problems with that approach because use cases often apply to multiple subsystems. IOW, often the requirements use case needs to be broken up so that portions of it can be allocated to specific subsystem subject matters.

My problem is the system I am modeling has three subsystems:
-Reader: Reads data.
-Visualizer: Show data on screen.
-Timer: Generates events to Reader and Visualizer subsystems. For exampe: orders to read every minute a refresh visualizer every twenty seconds.

Here exists use cases that user doesn't see (those use cases where Timer is the actor).

This is another problem. Requirements uses cases are "black box" descriptions of what the overall system does. However, that is at a pretty high level of abstraction and it is not uncommon for subsystems to be dedicated to specific computing space paradigms. For example, the user doesn't care if data is stored in an RDB, an OODB, flat files, or clay tablets. But a Data Access subsystem cares a great deal about which particular paradigm is actually used.

So it is not uncommon to expand use cases into a form that is more relevant to the systems engineering partitioning of the application. So one would translate a line like "Save Customer data" in a requirements use case into an entire new use case that explicitly defines the mapping of the data into, say, a Customer table in an RDB. That new use case will deal with notions like Table, Tuple, Field, Schema, Dataset, and Query for saving the data.


I need to represent every subsystem as a class with its use cases as operations? or only one big class representing entery system? I last, then I need to put operations (use cases) that are generated by Timer subsystem??

If your application is even modestly complex you probably want to partition it into subsystems. You will then need to associate requirements with each subsystem. One was to do that is with the technique the author suggested. However, in doing so you may find it necessary to subdivide and/or expand the use cases.

The bottom line is that use cases are a good way to express requirements because they map conveniently to the software via A&D methodologies. Requirements may be generated by the customer or they may be implicit in the computing environment. Either way, if you partition into subsystems it will probably be a good idea to define use cases tailored to each subsystem (e.g., the Actor is another subsystem). Any tailoring or augmentation of the use cases should be done to make it clear what the individual subsystem requirements are.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions  -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH



.

Relevant Pages

  • Re: Actor for Startup Use Case?
    ... I have a subsystem level use case that says what the subsystem ... I'm keeping these requirements high level. ... Who would be the actor for such a use case? ... technically I think it is the person/thing that causes the startup. ...
    (comp.object)
  • How to organize-class/object relationship
    ... implementation of that interface. ... public class CustomerCreator ... // This is a facade to subsystem that handles the group of these ... class CustomerImplOfType3 implements Customer ...
    (comp.lang.java.programmer)
  • How to organize-class/object relationship
    ... implementation of that interface. ... public class CustomerCreator ... // This is a facade to subsystem that handles the group of these ... class CustomerImplOfType3 implements Customer ...
    (comp.object)