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 http://www.cis.ksu.edu

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 http://www.cis.ksu.edu

CIS 764 Database Systems Engineering Fall 2007 http://www.cis.ksu.edu

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 http://www.cis.ksu.edu

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 http://www.cis.ksu.edu

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 http://www.cis.ksu.edu

CIS 764 Database Systems Engineering Following is another example for comparison. Again, you might zoom the view of the image. Fall 2007 http://www.cis.ksu.edu

CIS 764 Database Systems Engineering Fall 2007 http://www.cis.ksu.edu

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 http://www.cis.ksu.edu

CIS 764 Database Systems Engineering Fall 2007 http://www.cis.ksu.edu

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 http://www.cis.ksu.edu

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 http://www.cis.ksu.edu

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 http://www.cis.ksu.edu

CIS 764 Database Systems Engineering Following two sequences are for the ejb3 assigment previously given. Fall 2007 http://www.cis.ksu.edu

CIS 764 Database Systems Engineering Fall 2007 http://www.cis.ksu.edu

CIS 764 Database Systems Engineering Fall 2007 http://www.cis.ksu.edu

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 http://www.cis.ksu.edu

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 http://www.cis.ksu.edu

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 http://www.cis.ksu.edu

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 http://www.cis.ksu.edu

CIS 764 Database Systems Engineering end. Fall 2007 http://www.cis.ksu.edu