1. CIS 764 Database Systems Engineering
L11.2: Class and Sequence models
Pets and homework examples.
(Late posting)
(These examples were presented in class
using transparencies.)
Fall 2007

2. CIS 764 Database Systems Engineering
Following are some remaining issues with class models.
An example model is in the next slide.
It is not readable on the slide, but you can save it and zoom in.
The list of issues follow (with evaluation of the example in parentheses).
Fall 2007

3. CIS 764 Database Systems Engineering
Fall 2007

4. CIS 764 Database Systems Engineering
Class model notes:
* no need to show getters,setters for attributes (good)
(these are understood).
* key methods should be shown (good)
and often there is not room for parameters,
so the class signatures (methods and parameters)
might be listed in an associated text document. (missing)
Fall 2007

5. CIS 764 Database Systems Engineering
* the “createEntity(…) method
should not be in the Entity class; [#]
e.g. Order should not contain “createOrder(…) (error)
Instead, the create method must be in either
(i) the parent class (if there is one)
(ii) an associated session bean
(which Oracle calls a Façade class).
In either case, the class with “create” should show
composition (the solid diamond) (missing)
* it would help to annotate classes as either
<entity> or <session>
[#] Note: You could put the createEntity in the Entity class
and write your own sql or calls to the entity manager,
but that would not make sense to others maintaining your code,
and it would not use “container managed persistence”.
Fall 2007

6. CIS 764 Database Systems Engineering
* whenever possible, keep a top-down and left-right
ordering of parent to sub-entity classes.
e.g. the InventoryManager session class (missing)
should be above the InventoryItem class.
Note: I have observed MSE projects tend to use just a few
(even a single manager/session) class for several entity collections.
That is not so pretty, but reasonable and efficient for small models.
Fall 2007

7. CIS 764 Database Systems Engineering
Following is another example for comparison.
Again, you might zoom the view of the image.
Fall 2007

8. CIS 764 Database Systems Engineering
Fall 2007

9. CIS 764 Database Systems Engineering
The next step in the Pets design was to build some sequence models.
Suggested operations were:
user login
user purchase a pet (the primary use case).
In class, some hints were given
and then several models were reviewed.
Later, the following were given as examples.
See comments after the diagram.
Fall 2007

10. CIS 764 Database Systems Engineering
Fall 2007

11. CIS 764 Database Systems Engineering
Sequence models:
* the actor on the left is external to the middleware
(it is not one of the model classes).
Show a name different from the model classes.
Some tools will not draw the human icon;
in that case, label the box as <actor> .
* the human communicates with some GUI instance.
It is not necessary to show the actual GUI objects,
as that should be clear from the page flow.
* the human can only input / receive scalar values
(submitted via forms or controls);
the GUI may read/write files to the user environment.
* the GUI usually first communicates with some session/façade object.
Fall 2007

12. CIS 764 Database Systems Engineering
* If there is only a single instance of a class,
then it is not required to give an instance name.
* If multiple instances are involve (as Customer),
then the instance name should be shown.
* An instance is a row in the backing table;
it cannot be used unless either:
(i) it was identified on a prior sequence diagram
(ii) there is a get( ) operation on the parent class
(iii) there is a create( ) operation by the parent class
Fall 2007

13. CIS 764 Database Systems Engineering
* Each message is shown as a method (with parameters)
entering at the top of an activation record rectangle
(usually from the left).
* An activation record rectangle for a model object cannot
terminate until each message sent from the rectangle is completed.
The exceptions to this rule are:
(i) GUI components
(ii) separate, asynchronous threads.
* Each method shown (entering the top of an activation record)
must match the method name the class as shown in the class
model (or separate signature design for the class).
Note: This can only be checked by comparing the sequence
with the class model.
Fall 2007

14. CIS 764 Database Systems Engineering
Following two sequences are for the ejb3 assigment
previously given.
Fall 2007

15. CIS 764 Database Systems Engineering
Fall 2007

16. CIS 764 Database Systems Engineering
Fall 2007

17. CIS 764 Database Systems Engineering
Next step (for off-campus):
Build sequence model for customer to select and order a pet.
Assume there are only a few pets;
names of pet types are all shown on the browse/order page.
Fall 2007

18. CIS 764 Database Systems Engineering
Further issue:
In general, a class model does not uniquely define the
model behavior.
Multiple sequence model help to do that.
In addition, assertions help to give meaning to the model.
(That is the focus of the 771 course
on software specification and verification.)
The following briefly show some assertions.
However, assertions are mostly left for the 771 course.
Fall 2007

19. CIS 764 Database Systems Engineering
Assertions:
(i) invariants:
whenever there are multiple paths to a class in the class model,
some clarifying invariant should be given.
For example, for the first class model, for the two paths
SysManager -> InventoryItem -> Pet
and SysManager -> Order -> Pet
the clarifying assertion might be:
for each distinct Order O1,O2 : O1.Pet =/= O2.Pet
for each Order O: O.Pet in InventoryItem.Pet
Note: the last invariant exposes the missing “status” field.
Fall 2007

20. CIS 764 Database Systems Engineering
Assertions:
(i) pre/post (or in/out) assertions for each method.
e.g Order.addPet( p: Pet)
pre: p.available
post: p in Order.Pet and not p.available
or Order.addPet( pName: String)
pre: exist p in Pet : p.available
post: p in Order.Pet and not p.available.
Fall 2007

21. CIS 764 Database Systems Engineering
end.
Fall 2007