1

Below are three business objects selected from a use case

enter image description here

For any given use case, my understanding is, an actor can be considered a business object, if it falls under below two cases:

  1. if that actor has it's own local state and that state must keep changing from time to time.

Or

  1. if that actor may not have it's own local state but effects the state of another actor through association(composition/aggregation). Example: CoinFlipGame actor affects actors Player & Coin.

To emphasize, I would like to generalize that, any actor to be considered a business object, that actor should fall under above two cases. Further, every business object will be an OOP class(C++/Java/C#).

  1. Do you agree with this approach, in picking a business object, to derive an OOP class?

  2. For a given use case, How to identify business objects where in database can address the requirement?

overexchange
  • 15,768
  • 30
  • 152
  • 347
  • 1
    Every Business Object is an OOP object, but not every OOP Object is a business object. – Romain Hippeau Sep 14 '17 at 20:56
  • @RomainHippeau Query edited, wrt your comment – overexchange Sep 14 '17 at 23:52
  • 1
    You have three objects. 1) Player 2) Coin 3) Game. The choice of a player is an attribute, so are the sides of the coin. The Game object is the glue you need to tie everything together. Items 1 and 2 are your business objects. Item 3 is just an artifact you need for the implementation. In the end what is a business object and what is not is really academic, and depends on your implementation. – Romain Hippeau Sep 15 '17 at 15:04
  • @RomainHippeau I agree with [this](https://stackoverflow.com/questions/46226783/oo-design-how-to-pick-a-business-object-given-a-requirement#comment79420060_46226783). – overexchange Sep 15 '17 at 18:40
  • FWIW: Player is an Actor. Not over-stressing a Business Actor :-/ Of course it will be represented as Business Object. – qwerty_so Sep 15 '17 at 19:16
  • @ThomasKilian for any use case requirement, how to decide, if this business objects also need to be stored in database? In the coin-flip use case, simple c++/java application would suffice, without a database – overexchange Sep 15 '17 at 21:48
  • It depends on your requirements. If it's must not remember anything about the actor you don't need to save his state/data. If you personalize it you will likely save its name and scores. – qwerty_so Sep 15 '17 at 22:03
  • It won't help to down vote all answers. Your question is anyway on the way on being closed as off-topic. – qwerty_so Sep 17 '17 at 17:25
  • FWIW: The guys who wrote that paper you reference in your deleted answer are not using valid UML all over their paper. Referring to that is - how should I say? – qwerty_so Sep 17 '17 at 17:28
  • @ThomasKilian What about [this](https://github.com/shamhub/Java_programming/blob/master/0_OO_Design/Case_study/applied_uml.pdf)? – overexchange Sep 18 '17 at 06:41
  • That's a 404 page. – qwerty_so Sep 18 '17 at 08:06
  • @ThomasKilian My bad. it is [here](https://github.com/shamhub/Java_programming/blob/master/1_OO_Design/Case_study/applied_uml.pdf) – overexchange Sep 18 '17 at 08:10
  • Larman is ok, but it's more about project management than UML. – qwerty_so Sep 18 '17 at 08:16
  • If I compare your original question, the current one seems to be a rather different one. The title of your question is also does not match the text in the question. – qwerty_so Sep 18 '17 at 08:22

4 Answers4

1

Notice that, in general, we have to distinguish between real-world objects (or business objects) and OOP objects (such as JS objects or Java objects). A string may be an OOP object (e.g., in Java), but it's not a business object.

In Java, or, more specifically, in Java EE, an entity is a special Java object that instantiates a Java entity class, which is a Java class that is JPA-annotated as @Entity such that all its instances are automatically saved to persistent storage in a Java EE environment (such as TomEE).

A Java entity is intended to represent a business object. A Java string object cannot be a Java entity.

Any (business or OOP) object has it's own (local) state, and can also acces the state of other objects to which it is linked by means of references (via associations).

The question is: which business object types from a domain model (such as player, prediction, option, coin, coin game) have to be included as OOP classes in an OO design model? We can also say that the design model is derived from the domain model, which is obtained from the requirements.

Both domain models and design models can be made in the form of UML class models (visualized as class diagrams), see also this SO answer. A domain model describes a real-world domain, while an OO design model defines OOP classes to be implemented with a specific OOP language (like Java).

The selection of classes from the domain model to be included in the design model depends on the information requirements of your app development project. You have to identify what is the relevant information to be captured with your model (and the resulting Java classes).

If the purpose of your app is to record and display information about your coin flipping games, then I would include the following classes in a design model:

  • Player( id, name)
  • Game( id, date-time, bettingPlayer, opponent, bet, outcome)

Here, bettingPlayer and opponent would be reference properties, which represent corresponding associations between Gameand Player.

Making such a design from a domain model requires some experience in identifying the relevant information items. Transforming a business domain model into a platform-independent system design model involves both simplification and elaboration.

The domain model is simplified by

  1. abstracting away from elements that only have business meaning but no informational/computational meaning for the system to be built;
  2. compressing certain parts of the model to get a more efficient design (a business domain model is more concerned with conceptual explicitness while a system design model is more concerned with efficiency)

The domain model is elaborated by adding details, which are essential for the design (such as standard identifiers, data types, etc.).

Here is a (not quite up-to-date) tutorial that may provide some help.

And here is a diagram illustrating the model-based development process: enter image description here

Gerd Wagner
  • 5,481
  • 1
  • 22
  • 41
-1

Generally I would say yes to your question, although you could provide a more specific or detailed example in order to answer less generally.

Ale Zalazar
  • 1,875
  • 1
  • 11
  • 14
-1

I generally disagree, that OO modeling has something to do with the state of the object, although this might be a controversial subject, so your mileage may vary depending on who you ask.

You may start out with collecting the "things" that your requirements talk about, like Coin, Player, etc. in your case. Those are good candidates to be objects in your application.

The next step however should not be listing the variables those things might have, what information they should hold, or in what relation they are in. This would be data modeling, not object-oriented modeling.

In object-oriented modeling, the next step is to list responsibilities, and assign them to the object "candidates" from above. A good tool to use here are CRC Cards.

Identifying the "data" (state) the objects need should be completely an implementation detail, and should be part of the modeling at most in very coarse grained manner, ideally not at all.

Object candidates that receive no responsibilities will not be part of the application. Note also, that we are not modeling the real world in the sense that objects have state and behavior like in the real world. We are modeling the requirements, not more, not less. In the real world, dice can't really roll themselves, however in a software they might.

A word of warning: A lot of contemporary frameworks and libraries won't really let you work this way, most notably anything that requires you to create Java Beans will probably not be happy with your OO code. Obviously if you have to work with such libraries you might have to compromise you design.

Robert Bräutigam
  • 7,514
  • 1
  • 20
  • 38
  • My understanding is, any candidate to be part of OO design model should have follow those two cases given in query. Because, I create a class instance for either of those two case. Otherwise I donot need to create an instance of a class – overexchange Sep 15 '17 at 15:05
  • OO modeling is both about state/information stucture (with UML class diagrams) and behavior (with UML state charts and UML activity diagrams). You seem to ignore the fact that the core concept of OOP are classes, which are modeled with class diagrams, defining both properties (state structure) and methods (behavior). OOP classes/objects are closely related to data structures such as SQL tables as shown by ORM technologies. – Gerd Wagner Sep 15 '17 at 15:08
  • 1
    I strongly disagree that Objects have anything to do with relational databases, tables, ORM, or any data structures. The core concept of object-oriented design is to model behavior through active agents called objects. That UML can model properties is irrelevant, in fact, UML itself is pretty irrelevant and not required in any way for OOD or OOP. – Robert Bräutigam Sep 15 '17 at 16:04
  • @RobertBräutigam My point is, if any *actor* follows those two cases(given in query), for any given domain model, then corresponding *class* should exist in OO design model. Adding behavior to a class is the later activity which is relatively easy. – overexchange Sep 15 '17 at 17:55
  • @RobertBräutigam Sure, someone who was a baby or toddler in the 1990's when OOP and UML have been developed (by thousands of smart programming and modeling experts), may in his juvenile boldness think that "UML itself is pretty irrelevant". – Gerd Wagner Sep 17 '17 at 19:58
-1

I think that putting Business Objects in a separate classification is very artificial. To me as an IT person String and Person are objects of the same quality. But talking to non-IT people they'd clearly say that String is artificial and Person is concrete - just because Person is a term of their day to day world. But Person is an abstraction like everything. All terms we use are abstractions. Even John Doe living next to me is an abstraction since this conglomerate of molecules is a projection which is named John Doe. Watching closely, those molecules are exchanged completely over the years and the 30 year old person has nothing in common with the 10 year old.

OMG - it's getting philosophical. That's also why I voted to close this question as primarily opinion based.

qwerty_so
  • 35,448
  • 8
  • 62
  • 86
  • As I have pointed out in my answer, it's not true that "`String` and `Person` are objects of the same quality". In Java EE, `Person` can be made a Java entity while `String` cannot. – Gerd Wagner Sep 15 '17 at 14:46
  • @GerdWagner I have no idea of that Java stuff and was talking on a more formal and not a language oriented level. – qwerty_so Sep 15 '17 at 15:11
  • But also on a more general/logical/formal level, a string is not really an object with an object ID and a state. Rather it's a data value. It just happens to be implemented as an instance of a `String` reference type in OOP languages. Such reference types happen to be implemented as classes, like real object types. – Gerd Wagner Sep 15 '17 at 15:24
  • @GerdWagner Now you're drifting off. State and ID are independent of any object. BTW.: each object has an implicit ID which programmatically is expressed by its address. – qwerty_so Sep 15 '17 at 16:42
  • @ThomasKilian I think my query is related to design phase of any java/C++ implemented based project. Why is this leading to philosophical aspect? Query edited – overexchange Sep 15 '17 at 18:06
  • It seems like you're building up your mind to get the 42-question. Like @RomainHippeau commented, any object is based in the OOP domain. And some are attributed with "Business" which is a purely artificial classification. Though there's some common sense which is which, the position where the border is drawn is basically opinion based. – qwerty_so Sep 15 '17 at 18:16