Using Object-Oriented Techniques to Model Various Software in Java
Scenario 1: You are designing software to help stockbrokers manage to contact their clients regularly about their accounts, keeping track of their preferences and any events in the news or the stock market that they want assurance or opportunities for. Use our Object-Oriented techniques to help model this software.
Scenario 1 solution
Scenario 2: You are designing software to help police schedule shifts and allow the shift supervisor to quickly assess coverage for the needed workforce levels and skill mix. Use our Object-Oriented techniques to help model this software.
Scenario 2 solution
Scenario 3: You are designing software to help a shopkeeper proactively manage the vendors who they interact with on a regular basis, their addresses, phone numbers, and representatives, and keep notes on their interaction dates and responsiveness. Use our Object-Oriented techniques to model this software.
Scenario 3 solution
When you've finished, discuss the following questions:
What did you find difficult or easy?
What strategies helped?
A Discussion of The Challenges Met and Helpful Strategies
For this homework, there was difficulty in making decisions.
The first decision that was confusing was whether to include a noun as an entity in the diagram or not. For example, Scenario 1 mentions stockbrokers, Scenario 2 mentioned shift supervisors, and in Scenario 3 it mentioned shopkeepers. I had to study carefully the context of whether their data are included in the domain diagram. I finally came to terms that they shouldn’t be part of the domain diagram because they are the users of the system. The only data that needs to be on the domain diagram are those that the user operates on.
The second decision that was confusing was whether to use association, aggregation, or composition on showing the relationship between two entities. After doing due diligence, I came to understand which relationship is appropriate to be used. An association is used if two entities are related where one entity uses another entity. Aggregation and composition are used if an entity is made up of or composed of other entities. Aggregation and composition are confusing but the rule is that aggregation is used if the child entity can still exist without the parent entity. On the other hand, the composition is used when a child entity cannot exist without the parent entity.
The third decision that was confusing was whether to make data an entity or an attribute. This is evident in Scenario 3. It makes sense to make address, phone number, and representatives as a separate entities. However, it also makes sense that they can be an attribute of a vendor. There were no details that is given for the address, phone number, and representative thus the decision to make them as attributes instead makes more sense. The interaction log is clearly an entity and not an attribute because additional details were given such as notes, dates, and responsiveness which can be attributed to the interaction log entity.
The following strategy helped make the diagram:
Focus on the objects and their properties. Keep users out of the diagram not unless specified.
Do due diligence on the right use of the relationship between entities as not to produce a confusing meaning of the diagram.
Decide carefully whether data is an entity or an attribute. To play it safe, make them as an attribute if not many details are given. However, we can expand them as an entity if in case more details are given to the requirements.
The diagram would’ve been explained better if more details are put to it such as the attributes but domain models do not show such details.