LOL
,
you probably you lack some phantasy
!
Example:
First iteration of use case analysis:
UseCase "Withdraw Money"
UseCase "Check Account Balance"
Second iteration of analysis: (you realize that both use cases include the identification/authentification stuff)
UseCase "WithDraw Money"
UseCase "Check Account Balance"
UseCase "Enter Identification Credentials" (in germany a 4 digit PIN after you have inserted the credit card into the ATM)
Third iteration of analysis: (you realize that both use cases have basicly the same flow of events)
UseCase "ATM Transaction" { has extensionpoint performTransaction }
UseCase "Withdraw Money" extends "ATM Transaction"
UseCase "Check Account Balance" extends "ATM Transaction"
UseCase "Enter Identification Credentials"
Fourth iteration of analysis: ( your robustness and domain analysis (product-family/product-line analysis) shows you to factor out identification because you want to replace the actually used identification/authentification method with retina scanning thechnique next year)
UseCase "Enter Identification Credentials" renamed to Authentification
UseCase Authentification ( via PIN or retina scan or finger print )
UseCase StartTransaction ( by inserting a credit card or starting the ATM via touching the screen or activating a finger print recognizer or retina scanner)
UseCase "ATM Transaction" { has extensionpoint performTransaction } includes Authentification, StartTransaction
UseCase "Withdraw Money" extends "ATM Transaction/{performTransaction}"
UseCase "Check Account Balance" extends "ATM Transaction/{performTransaction}"
UseCase InsertCard generalizes StartTransaction
UseCase AuthenticateWithPin generalizes Authentification
Well, for simple class room example that is allready far to complicated ...
I asume you are familiar with the standard stereotypes <<control>>, <<boundary>> and <<entity>> as well as with actors.
Add actors as appropriated and start creating classes with the appropriated standard stereotypes.
Insert abstract methods for the extension points ... add inheritance(generalization) relations where ever you encounter an extends relation or generalization between use cases. Add aggregation or associaten(as you like) relations between <<control>> classes where the use cases have an includes relation.
Now: mark the two main use cases with a suitable stereotype, e.g. <<dialog>>.
Suppose you have activity diagrams for you UCs ... I would suggest to seperate the activities between <<input>> and <<system>> activities.
Surprisingly you will realize that you can have 2 menu entries in your main menu (or two buttons): "withdraw money" and "check balance". Its not coincident that I suggested to mark the two connected use cases with <<dialog>> ... furthermore you will likely make two dialog classes, one for each use case. You could hav choosen any other stereotype, like <<menu>> as well to indicate that the two use cases can get triggered from the GUI.
Fianally:
By marking the UCs with suitable stereotypes -- or better a tagged value -- you can trigger your generator to create 4 packages: "application", that holds the code for starting the transaction and the main ATM logic, UseCase StartTransaction and UseCase "ATM Transaction", "check balance" and "withdraw money" I would put both into their own package and finally "authentification".
Basic skelletons for the control and boundary classes, the Customer class as actor and their inheritance and aggregation relations and simple configuration classes which serve as constructors for the components (creating the boundaries and dependent controls and wirering them together) ... that all can begenerated from a simple use case diagram.
As a far more in depth read I suggest "Software Reuse" from Ivar Jacobson and Martin Griss, Asdison Wesley - 1997.
Well, the schema above is how I work with use cases. You likely have to find your own way in utilizing them. Nevertheless you will be able to cathegorize your use cases in several ways. E.g. "system" use cases and "external program" use cases where both are triggered by system intern events and run automatically without GUI or user interaction. Then you probably can describe simple use cases like "edit/cut" and "edit/paste" which certainly have simple representation in the GUI as "menu item" in a "menu". Beyond that you can identify use cases which are triggered by a "menu" but lead to a "dialog". The menu entry and dialog caption are likely the same as the name of the use case. Furhter use cases can be cathegorized as "context menu" actions, "drag&drop" actions and "button" clicks leading to ... creation of command objects or to new dialogs or to calls to methods of <<control>> objects.
The question is primarily on what level and granularity you work with UCs and wether you have one or several reference implementations of frameworks or applications (like using MFC or ATL for GUI construction on side or Swing on the other side, both will have totally different ways of GUI generation).
Best regards,
angel'o'sphere
