[Skip Navigation] [ CSUSB ] / [CNS] / [CSE] / [R J Botting] / [CS375] [Search ]
Session: [01] [02] [03] [04] [05] [06] [07] [08] [09] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20]
[Text Version] 06x.html Wed Jan 25 13:05:26 PST 2012

# Exercises for class 06

1. List the artifacts that are developed during inception and indicate their degree of completeness.
2. What three goals are normally tackled during elaboration?
3. What artifacts are started during elaboration?
4. What is a domain model?
5. Here are the two basic symbols used in a simple domain model, what do they mean?

6. Give 2 examples of the kinds of things that do not appear in a domain model.
7. What is the relation between domain models and design class diagrams.
8. List half-a-dozen types of conceptual classes.
9. What is a description class and why are they useful?
10. When should you show an association in a domain model?
11. What is a multiplicity? Give 4 examples.
12. Here is a text version of some multiplicities: Section(*)-----(1)Teacher(*)-----(1)Department. Explain what they are saying.
13. List half-a-dozen categories of association.

## Practice domain modeling.

### CSUSB Inventory Control

Suppose that you have to develop the CSUSB Inventory program for Facilities Services. This software tracks all the equipment and furniture on campus. It enables us to find where things have gone to. Each thing is in one place and places can have any number of things. CSUSB Inventory is used when we move, instal, replace, repair, and remove things from service. It helps us find things and put them in the right place. Places include classrooms and stores.

List the nouns in the above.

Draw a domain model.

. . . . . . . . . ( end of section CSUSB Inventory Control) <<Contents | End>>

### Depot Stock Control Software

#### Instructions

1. Draw a domain model to fit the following description in the space at the bottom of this sheet.

Hint: use a pencil and an eraser. Or a black/white board with chalk. Draw incomplete boxes.

#### Vision -- Depot Stock Control Software

Software runs in a depot that ships stocks requested by orders. It helps the depot manager manage stock levels and outstanding orders.

#### Use Case UC1 Manager reviews unfulfilled orders

The manager at a depot logs in and sees a list of the sales orders that his depot has not yet fulfilled.

#### Exercise 1

Your diagram should show the following information (and not much else!).
##### Classes
1. Depot, Product, Stock, Customer, Sales Order, Sales Item
##### Associations
2. A Depot holds Stocks.
3. Products are stocked as Stocks.
4. A Depot has Customers.
5. A Customer can have Sales Orders.
6. A Sales Order has Sales Items.
7. A Stock can be ordered as a Sales Item
##### Multiplicities
8. Each Stock has precisely one Product and is held at one Depot.
9. Each Customer is served by only one depot.
10. Each Sales Item is on one Sales Order and is for one Stock.

. . . . . . . . . ( end of section Exercise 1) <<Contents | End>>

#### Answer 1 -- With no association names

[ 06xans.png ]

#### Exercise 2

See this [ 07x1.png ] and add these
##### Attributes
3. Sales order: dateOrdered, dueDate,
4. Sales Item: price and quantity,
5. Product: description and units.

#### Answer 2 -- Domain Model with attributes

[ 07x1ans.gif ]

. . . . . . . . . ( end of section Exercise 2) <<Contents | End>>

. . . . . . . . . ( end of section Depot Stock Control Software) <<Contents | End>>

. . . . . . . . . ( end of section Exercises for class 06) <<Contents | End>>

# Standard Definitions

1. Artifact::="Anything that is created in the course of a project".
2. artifact::=see above.
3. DCD::diagram="Design Class Diagram", shows the classes that will be implemented in code.
4. Deliverables::="A packet of artifacts that must be prepared by a deadline for review or distribution".
5. Glossary::= See http://cse.csusb.edu/dick/cs375/uml.glossary.html.
6. GoF::="Gang of Four", [ patterns.html#GoF ]
7. GRASP::patterns="General Responsibility Assignment Software Patterns", a set of guidelines for designing objects and classes. They take a single event that the system must handle and determine a good class to carry it out. See [ patterns.html#GRASP -- General Responsibility Assignment Software Patterns ]

9. KISS::Folk_law="Keep It Simple, Stupid", in agile processes this means never drawing a diagram or preparing a document that doesn't provide value to the clients and stakeholders. In all processes it means never designing or coding what is not needed, see YAGNI.

10. OO::shorthand="Object-Oriented".

11. OOAD::="Object-Oriented Analysis and Design", See chapter 1 in text.
12. patterns::="Documented families of problems and matching solutions", see Patterns.
13. Patterns::= See http://cse.csusb.edu/dick/cs375/patterns.html.

14. Process::="How to develop software".

15. RJB::=The author of this document, RJB="Richard J Botting, Comp Sci and Engineering School, CSUSB".
16. RUP::Process="Rational UP", a proprietary version of UP.

17. SSD::="System Sequence Diagrams", see chapter 10 and [ 02DiceGameSSD.gif ] (example).

18. TBA::="To Be Announced".

19. UML::="Unified Modeling Language". [ Unified_Modeling_Language ]

20. UP::="Unified Process", an iterative, risk-driven, and evolutionary way to develop OO software.

21. YAGNI::XP="You Ain't Gonna Need It", an XP slogan that stops you planning and coding for things that are not yet needed. As a rule the future is not predictable enough to program a feature until the stakeholders actually need now. In this class it also means "It won't be on the final or in quizzes".

22. XP::="Extreme Programming", the ultimate iterative, code-centric, user-involved process.