I just got my assignment and took a first look at it.
In another discussion to part 2 somebody in this forum gave the advice 'don't change the domain model unless you have really good reasons'
In my assisgnment domain model I have an order and 3 different products or items which can by added to the order. Order and Items have an 1-n relationship.
My question is: I would add an OrderDetail or ListItem in between the Order and the Items. From my experience in real live projects, I know this is a very useful construct.
This way I only store an foreign key of the item and fields like amount on the orderDetail. Order and OrderDetail would have an 1-n relationship, OrderDetail and Item and 1-1.
Do you think this is legal to expand the domain model to better fit the requests.
thanks, I think so too.
maybe I have to extend/change the DomainModel even more.
There are another 3 objects that would really fit for inheritence (which is promoted in any JEE5 documentation).
not to use inheritence here, just because i don't wan't to change the BDM, can not be the best solution.
The domain model like it is, looks to me like a business DOM, not a technical DOM.
I always had to alter BDMs (because business analysts don't know/care about lineItems and inheritence)...to better serve the realisation
as long as the BDM is not changed in it's intention or meaning
what about the sequence diagrams:
Is it necessary to exhibit the whole UI interaction in a given use-case?
an easy example:
User -> JSF (press some button e.g.)
JSF -> FacesContext (setXXX).
a lot of stuff, before I finally come to the business tier.
useful information. this makes the sequence diagrams a bit smaller;-)
so the first element to the right of the User-object should be a UI Element (not specified to JSP/JSF) and next element would be the SessionBean (or Facade if I use one)?
I guess the backing bean can not be omitted, since 1) it's in the class and component diagram and 2) it acts as a facade to the Session Bean, correct?
that would be : User - UI - BackingBean - EJB
ok, I keep it straight like the examples of the study guide from humprey sheil. means less to draw;-)
what about alternatives flows or loops in a sequence diagrams, are these necessary? no example in the book got one,
but I think it's conceivable.
for example a customer put's an item in a cart, systems checks availability and put's in in the cart ( not mentioned in the description, but: if there is no availability, the item
will not added to the cart)
in case of success the cart will be displayed, in the other case (even it's not specified) something like displaying an information page 'sorry not enough stock'.
so this could mean in the sequence diagram to exibit the alternativ flow.
I think loops are too detailed for the sequence diagrams as long they won't be between different components.
(e.g. validating the order before payment could mean iterating over all details and check something or calculate total)
Hi Wolfgang. I'm no expert so don't go by my words completely :-). I haven't got my results yet, besides. :-)
In my case, my seq diagrams showed only the main flows. Class diag showed only main classes.
Let's see if that is enough or will I need to do a resubmitting :-)
ok, I omited alternative flows in the sequence diagrams. In one case I drawed the alternativ in a refrenced additional diagram. since I think this one is essential.
what about interfaces in the class diagram?
in the study guide from humprey sheil no interfaces are exhibited in the class or component diagram.
should interfaces be included? or is it not necessary e.g. for local interfaces to session beans, if I describe somewhere else, I invoke all methods
through the session beans local interface?
I too had many of the questions that you asked (so thanks!). I also go by humprey sheil example. In that example, instead of OrderItem having a 1-1 with product, he had an OrderItem which would be extended by all the available products - this is another way - though I also preferred your way - are we not supposed to favor composition over inheritance?
For sequence diagrams, I think if it is absolutely necessary we should show the alternates...ideally I would love to show all the alternates...but, someone said giving too much information may lead to more mistakes and to less marks! - so, I am not sure...
I think local interfaces to session beans are not needed to be shown - as we already qualify a session bean with a sterotype - or you can think of using the lollipop to keep your diagrams precise...
I already introduced a abstract super class for my products, I stayed with my order detail solution, I hope it's ok.
I justified the decision also with the fact JPA will anyway create this table (since we have a n-m relation).
Finally my JPA model looks quite different as the BDM on the first look. BDM has 7 tables, I have 11 entities.
but the representation of my entity model on the database looks very much like the BDM, since the
only real change I made is the order-detail. the 3 abstract jpa's will not appear as tables with TABLE_PER_CLASS.
I inserted a extra diagramm to illustrate this.
what concerns the alternative flows in the sequence diagrams: I omited most. I included the guards but I have no alternative blocks.
I use Jude-UML, it doesn't even have these feature.
I have one alternative block, which is really important as a reference in a extra diagram.
anyways one sequence diagram scores 4 points, so I spent more time to the class and component diagram the last time, since each will mark 40 points.