Last week I posted a partial diagram for the Parks and Rec scenario. Here is a more complete one, though there are still some minor changes and additions that can be made.
Some Notes
Still missing from the diagram is a class to manage the check ins and check outs of equipment.
I made Person abstract. That means that you can never instantiate (use) Person directly. You can only use its children. Person has two children, Employee and client that inherit from it.
Client, Inventory and Park all implement the Interface I_Manage which gives them Add, Edit, and Remove methods. Implementing an interface is similar to Inheritance. You not only get the methods in the interface, you must implement them.
There are two Composition relations. Remember Composition represents a whole/part relationship where if the whole is destroyed the parts are also destroyed. Item is a part of Inventory. If the inventory is removed we will say all the items go with it. Fine is a part of Client. If the client is removed the fines go with him or her.
We have one Aggregate relationship. Employees are a part of a Park. But if the Park is removed, we will not remove all employees.
There is an Association relationship between Park and Inventory. Park calls a method in Inventory to get the Items for its park.
In Park I noted two constructors because they are not the default constructors. Also note that most of Park's methods are private, meaning they can only be called from within the class itself.
"Is a" versus "has a" Relationships
One way to look at relationships between classes is to determine if a relationship is an "is a" of a "has a" type of relationship. For instance Client is a type of person, Employee is a type of person also. Inventory has a collection of Item. Park has a collection of Employees. Client has a collection of fines.
Most relationships can be resolved into one of these two relations.
No comments:
Post a Comment