Difference between revisions of "GS Packages Standard"
From BRL-CAD
(→Notes on Packages) |
(→Notes on Packages) |
||
| Line 2: | Line 2: | ||
=Notes on Packages= | =Notes on Packages= | ||
*Packages are simply a graphical grouping of functionality. | *Packages are simply a graphical grouping of functionality. | ||
| − | *They combine multiple [[ | + | *They combine multiple [[GS Actors Standard|Actors]] and [[GS Use-Cases Standard|Use Cases]] that have some comonalities. |
*Packages can also be called Systems or Subsystems. | *Packages can also be called Systems or Subsystems. | ||
*Packages do not have to define internal associations between different Use Cases. | *Packages do not have to define internal associations between different Use Cases. | ||
Revision as of 07:57, 28 May 2008
Notes on Packages
- Packages are simply a graphical grouping of functionality.
- They combine multiple Actors and Use Cases that have some comonalities.
- Packages can also be called Systems or Subsystems.
- Packages do not have to define internal associations between different Use Cases.
Example:
!!Replace graphic with GS example!!
- The actors in this diagram are:
- WaitStaff
- Patron
- Cashier
- Chef
- The combined Use Cases for all the actors are:
- Order Food
- Serve Food
- Eat Food
- Drink Wine
- Pay For Food
Now, depending on how the developer was intending on implementing this in code, one could easily say that sense all the actors 'is a' Person, then they all need to 'Eat Food.' If this food is only the food served at this resteraunt, then perhaps all the actors do not have to 'Eat Food.'
A simple Diagram like this has already helped to identify ambiguity in a design!
