Difference between revisions of "GS Packages Standard"
From BRL-CAD
(New page: ---- =Notes on Packages= *Packages are simply a graphical grouping of functionality. *They combine multiple Actors and Use Cases that...) |
|||
| (2 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
| + | {{DesignDocument}} | ||
| + | |||
---- | ---- | ||
=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. | ||
| Line 10: | Line 12: | ||
Example:<br /> | Example:<br /> | ||
| − | + | [[Image:Restaurant-UML-UC.png]] | |
<br /> | <br /> | ||
!!Replace graphic with GS example!! | !!Replace graphic with GS example!! | ||
| + | <br /> | ||
| + | *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 | ||
| + | |||
| + | <br /> | ||
| + | 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! | ||
Latest revision as of 12:00, 28 May 2008
|
This page contains the design document for an enhancement or feature. The design should be considered a work in progress and may not represent the final design. As this is a collaborative design, contributions and participation from other developers and users is encouraged. Use the discussion page for providing comments and suggestions. |
Notes on Packages[edit]
- 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!
