Use Cases

Last Updated September 8, 1999 - Jack Harich - Go Back

Main Actors

In our continuing efforts to learn from experience, here's yet another look at things from yet another perspective. This manner of going over and over and over a design is what fast evolution is all about.

Here we try to think of each differernt actor. How do they see their universe? What does their "lifestyle" consist of? What do they do every day and minute? What are their conceptual inputs and outputs?

Use Case List

These apply only to the kernel and supporting subsystems like Param and Message. We are excluding Visual Tool details, but not the Visual Tool hook to the kernel. For simplicity we assume the present Param file based subsystem is used. When in doubt we include a Use Case rather than miss it.

No way these are complete. Much of the spec is in the present BA. These Use Cases really need grouping. The groups can be very insightful.

  1. Create new system
  2. File management - Add, Delete, Move, Rename, Copy, etc.
  3. Edit container DK
  4. Edit part DK
  5. Start system
  6. Start container
  7. Close container
  8. Close system
  9. Send message to part in started container
  10. Send message to part in unstarted container
  11. Send message to MessageService in container hierarchy
  12. Send any command to a part, such as Start, Close, Pause, Init
  13. Start a part's lifecycle, with DK option
  14. End a part's lifecydle, with possible "closed" event
  15. Get and apply DK in running part or container, with "dynamic DK" feature. (For containers, do not close and restart if change is to only one part.)
  16. Add part or branch to running system, with rollback
  17. Remove part or branch from running system, with rollback
  18. Replace part or branch in running system, with rollback
  19. Determine Message Chain
  20. Validate part dependencies, system running or not
  21. Let a part manipulate the system directly
  22. Let Visual Tools or other systems "hook" into a system
  23. Notify hooked systems of various kernel events
  24. Handle an exception in kernel or subsystem
  25. Handle an exception in part
  26. Handle errors in DK
  27. Infinite Extensibilty (do separate list)
  28. Deployment of a system
  29. Message name conflict, such as due to part reuse - How to avoid?
  30. Reuse a part
  31. Part external modifications than prevent backwards compatability
  32. Understand a system
  33. Understand a part
  34. Need for designer to know of a "set of messages", similar to interface
  35. Need for MessageRegistry or such for MessageDef reuse
  36. Need for Datatrons, how to "read" their definitions
  37. Design and specify a system, branch or part (before building it)
  38. Test a part
  39. Test a system
  40. Test the kernel

We expect to completely redo this, organizing into groups and key Use Cases, with an "importance ranking". These can be used to validate our architecture. Further detailed Use Case can drive detailed design and the rest of the project.