Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

1z0-865 Entities Diagram

 
Sergio Figueras
Ranch Hand
Posts: 56
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi folks!

It's me again. The guy without experience in UML modeling. :P :P

I've chosen to separate my classes diagrams according with each tier, so now, I'm developing my entities diagram and I've some questions:

1. Should I reference agreggation / composition in both ways? Because there're some of my classes that are composed (see the attached model please).
2. Can I add an interface into my hierarchy? I've made that because there's a dumb division in my domain model (Precious, Semiprecious), but I wanna threat all of them as gems.
3. Do I need to add security entities (user, for example)? In my usecases there's the need to each user be authenticated in a login (and there's no reference to external authentication systems). So, what should I do about that?
4. Do I need to represent Multiplicity in each node?
Anything that you guys wanna tip me about my entities diagram is very welcome!

Best,

Sergio.

Classes.png
[Thumbnail for Classes.png]
 
K. Tsang
Bartender
Posts: 3585
16
Android Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The composition/ aggregation shouldn't be both ways. Composition is different from aggregation such that for composition when the parent object is destroyed, the dependent objects also destroyed. Aggregation is the opposite, the dependent object does not die.

Class A has (through composition) Class B = when A dies, B dies


Multiplicity should be present for those entities matching those in the domain model given in the assignment.


The User class is out of place. Shouldn't Buyer and Supplier extend User?
 
Heliton Rodrigues Aranha Filho
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Pretty much what K Tsang said.

I'd add that you might want to use only simple association, and don't delve into the details. As I said in a previous post, with UML modelling in this exam less is more. Don't overdo it unless you're absolutely certain of what you're doing, or you'll get penalised. Remember the best design principle of all: KISS.

I also agree that the user should be a generic class (abstract or not, depends on your architecture), extended by your domain classes. That's how I did mine.

You can add the interface to generalize domain ideas (in my case I used abstract classes), but try not to over do it, specially "inside" the domain diagram provided in the assignment. Try to keep that core as pure as you can, as it seems some people here have lost points for messing too much with it. That also goes for the multiplicity.

I basically kept the core domain diagram intact, and built around it, adding abstractions, associations and dependencies. The only multiplicities I used were the ones already in the domain diagram; I chose to play it safe as, again, this is not a professional project, this is just for Oracle and it's what they want and they will be very strictly and technically grading you. So you'll end up doing things you normally wouldn't do just to please them. Think of them as a very annoying and picky customer that you just want to get the project done and move on to better things.

Cheers!
 
Heliton Rodrigues Aranha Filho
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
One last point, I wouldn't go into that much detail in the class diagram, showing ALL the attributes and operations. In mine I only showed the attributes that were modified in the use cases and were important business-wise, and the operations that were accessed in the sequence diagrams. Otherwise I thought it'd bee too much for the person correcting the exam to double check and it might put him off or something. Just kept it simple so it's easier to, in a glance, understand everything that's going on.
 
Heliton Rodrigues Aranha Filho
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As a last thought, if you haven't already, consider following Cade's examples. They're what Oracle wants.
 
K. Tsang
Bartender
Posts: 3585
16
Android Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Keeping the class diagram simple and conform to the domain model is one thing. Many people in this forum anyway say that the objects in the sequence diagram should be also in the class diagram.

Another crack is that the components/ objects in the component diagram should be in the class diagram too given the use cases use such objects. Yet some people think this will make class diagram unmanageable.
 
Sergio Figueras
Ranch Hand
Posts: 56
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
K. Tsang wrote:The composition/ aggregation shouldn't be both ways. Composition is different from aggregation such that for composition when the parent object is destroyed, the dependent objects also destroyed. Aggregation is the opposite, the dependent object does not die.

Class A has (through composition) Class B = when A dies, B dies


Multiplicity should be present for those entities matching those in the domain model given in the assignment.


The User class is out of place. Shouldn't Buyer and Supplier extend User?


Hi K. Tsang, thanks for your reply.

I've made change in composition and aggregation.

The only kind of user mentioned in my assignment is a purchasing agent, that is a guy which approve buy or selling orders. The sell / buy orders are created automatically by the system. For that reason, it seems to me, that "user" entity should manage only purchasing agents, not suppliers or buyers, because in fact, they're not users. Did you understand my explanation? :P

The Buyers or Suppliers doesn't make any login into the system, in fact, they're only people which orders are addressed. Does it make sense for you?
 
Sergio Figueras
Ranch Hand
Posts: 56
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Heliton Rodrigues Aranha Filho wrote:As a last thought, if you haven't already, consider following Cade's examples. They're what Oracle wants.


Thank you for all your tips, Heliton! I'm so grateful!

Another point: do you think that should I separate diagrams by layers, as I'm doing? Separate diagrams for domain / persistence, logic, etc, in different diagrams?

Best,

Sergio.
 
Heliton Rodrigues Aranha Filho
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sergio Figueras wrote:
Another point: do you think that should I separate diagrams by layers, as I'm doing? Separate diagrams for domain / persistence, logic, etc, in different diagrams?

For the exam I wouldn't and didn't. I followed Cade to the letter. I guess it depends on how big your diagrams are getting. My class diagram had around 30 classes, and I managed to get them in a visible and understandable way onscreen (and it's a 15" widescreen notebook, probably inferior to what they have at Oracle).

I guess it's up to you. Try to heed Cade's and your forum fellow's advices, but in the end, follow your gut. It's your cert and your money and time anyway
 
K. Tsang
Bartender
Posts: 3585
16
Android Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sergio Figueras wrote:
The only kind of user mentioned in my assignment is a purchasing agent, that is a guy which approve buy or selling orders. The sell / buy orders are created automatically by the system. For that reason, it seems to me, that "user" entity should manage only purchasing agents, not suppliers or buyers, because in fact, they're not users. Did you understand my explanation? :P

The Buyers or Suppliers doesn't make any login into the system, in fact, they're only people which orders are addressed. Does it make sense for you?


Yup got that. Then your User class can actually call PurchasingAgent.


Regarding splitting the class diagram, I don't recommend it too. In my class diagram I have about 30 classes too and the business tier classes kinda look cluttered and messy with all those <<use>> arrows everywhere. But no need to split.

Also no need to mention the getters/setters, only attributes for the POJO and entities is sufficient. The classes with operations should adhere to those mentioned in the sequence diagrams (eg public methods). Other notable operations may be mentioned but not a must.
 
Sergio Figueras
Ranch Hand
Posts: 56
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you for all the tips guys!

I`ll put everything on a single diagram, as Cade solution and you folks said.

But, I'm still concerned about my domain model. The attached image show the relationships between classes, but I was thinking in create just an Enum class, in fact, if I do this, I could remove all those classes for a single Enum (because I don't know how you folks can get only 30 classes on your diagrams, just with my domain model and DAOs I'm getting 30 classes).

What do you think about that? Should I substitute this domain classes for a single Enum? (attached image please)
Screen Shot 2015-05-22 at 16.46.27.png
[Thumbnail for Screen Shot 2015-05-22 at 16.46.27.png]
 
Heliton Rodrigues Aranha Filho
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sergio Figueras wrote:What do you think about that? Should I substitute this domain classes for a single Enum? (attached image please)

You do what you gotta do, but I would strongly advise against that. In my opinion (and Cade and others here), the domain classes are sacred. My advice is work around them if you need to improve something, but don't touch them, no matter how messy your diagram gets. Maybe think a little harder about how to better design your diagram, cram things a little more to make them fit, but leave them alone. I suspect you're overdoing the diagram, maybe adding too many abstractions and attributes and operations. As I said before, KISS. Only show attributes and methods that are VERY relevant to the business, specially the ones shown in the sequence diagrams (those really must be there, as public methods). Otherwise just show the boxes and relationships. In real life I can see why you'd think about replacing them, but again, as I've said before, this is not real life nor a real project. This is Oracle's territory, it's what they want, pure and simple. Keep your clever design ideas for your real job and stick to the basics here.
 
K. Tsang
Bartender
Posts: 3585
16
Android Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
When I first did my design I actually did the product stuff (mine is Inventory) as Enum too because of easier maintainence, less code/classes to change bla bla.

BUT just to conform to the domain model, I specify all those classes just like domain model.

Looking at your Gem stuff, it's an interface not a class/entity. So the approach may be a bit different. What methods will be in the Gem interface?

Your Gem stuff is clearly polymorphic.

Oh for interfaces, classes "implements" it hence whatever class implements the Gem interface not composition/aggregation.
 
Sergio Figueras
Ranch Hand
Posts: 56
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi K. Tsang and Heliton,

Thank you for your valuable tips. I'm so glad with your help guys!

After a long (entire day) work, I think that I've the very first version of my class diagram.

In fact, I think that it's still a complex diagram. There's something like 46 classes inside of it, and there are a lot of line across the entire diagram with <<uses>> stereotype. I can't judge if it's ok because I've no experience with UML modeling.

I've made some design decisions like create "Gem" interface inside my business model, otherwise I would have a lot of other stuff in this diagram. But I've preserved the relations between the business model. Also, I've separated my classes into the following sections:

JSF Pages, ManagedBeans, Services (@Stateless), DAOs (@Stateless), entities, and integrations.

Another strange point to me is because my assignment requires a login system, but I don't know if it would be better to use JAAS and how should I model this at my diagram. Anyone of you guys needed to include a login system into your assignment? How was it?

Thank you very much!

Sergio.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic