Order Now  +1 678 648 4277 

Object-Oriented Techniques Homework Help in Java

This assignment needs the student to use object-oriented techniques to model various software for different scenarios as shown. We offered Object-Oriented Techniques Homework Help in java on the assignment through one of our competent Java Assignment Help programmers. The programmer also explains the strategies that helped him achieve the goals.

object oriented techniques homework help
Table Of Contents
  • Using Object-Oriented Techniques to Model Various Software in Java

Using Object-Oriented Techniques to Model Various Software in Java

Scenario 1: You are a designing software to help stockbrokers manage contacting 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
Object-Oriented Techniques
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 assignment there was difficulty on making decisions.
The first decision that was confusing was whether to include a noun as an entity into the diagram or not. For example, in Scenario 1 it mentions stock brokers, for Scenario 2 it mentioned shift supervisors, and in Scenario 3 it mentioned shopkeepers. I had to study carefully the context 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 operate 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. An aggregation and composition are used if an entity is made up 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, composition is used when a child entity cannot exist without the parent entity.
The third decision that was confusing was whether to make a data an entity or an attribute. This is evident on Scenario 3. It makes sense to make address, phone number, and representatives as separate entity. 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 attributes for the interaction log entity.
The following strategy helped made the diagram:
 Focus on the objects and the properties. Keep users out of the diagram not unless specified.
 Do due diligence on the right use of relationship between entities as not to produce a confusing meaning of the diagram.
 Decide carefully whether a data is an entity or an attribute. To play it safe, make them as an attribute if not much 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.