• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

Domain Model First or Use Case

 
Ranch Hand
Posts: 426
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

I am currently trying to catch up on my design because I am not sure if what I have been for sometime is correct.

Oftentimes, I was given requirements but I am not sure which is the best way to start.

Is Domain Modelling the first step to do wherein I create the relationships between the realword objects that I see on the requirements list?

This is where I create an aggregation/composition relationship between the possible objects that I see on the requirements list (e.g A library has many books ).

or

should I focus on the transactions that the user's are doing? This is actually where I derived
my use cases. (e.g AddBookDetails/BorrowBooks/ReturnBooks).

I tend to favor the second approach but from the way that I have been doing it, I end up with a lot of different transactions. In the end each transaction represents one class that I am instantiating.

I have been reading lots of online materials, but I cannot represent my objects the way that they are describing. (e.g. An Inventory contains different products)
In the end, the Inventory class contains methods such as addProduct()/deleteProduct()/updateProduct().

I am not sure but I think there is something wrong on how I perform my modelling approach?

Could you comment on this?
 
Ranch Hand
Posts: 40
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You have many different ways to start a modeling project.
I would recommend for beginners to make it simple because don't forget that in UML what is important is to give a clear vision of the project and always adapt diagrams to the audience. There is no interest developing sophisticated diagrams if the team doesn't know UML. If the team is mainly composed by beginners then just do 2 or 3 different kinds of diagram.

- First crop all requirements on a paper or word document.
- Then define the scope of your application. Just make few simple usecase diagrams
- Finally create the architecture of your application with a class diagram.

You can also use sequence, or usecase diagram at requirement stage but this is not easy if you don't have a mentor
You should decide at the architecture stage to create either code from class diagram once the modeling stage is finished or to use live code and model synchronization.

I would recommend a live code generation in which you create at the same time from UML diagram the skeleton of your application with packages, classes etc....I would not recommend the modeler enter too deep in the business implementation and would suggest just to create UML attributes / methods (with no code generation) inside an existing class and therefore let the implementation team code manually the business implementation. This is not a full live code and model synchronization but let you to create the architecture and therefore control any further project evolution and refactoring if requirements evolve during project implementation.

 
Author
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I don't see how you can necessarily do one step "before" the other. I tend to figure out, loosely, what entities the app needs, and as I work through the requirements I'll add details like fields, methods, and so on. As I add details, I can usually refactor out additional entities to group behavior (methods), but it obviously depends on what I'm doing

The bottom line is that if your approach *works*, it's right--at least for you, and at least for now :)
 
Vlad Varnica
Ranch Hand
Posts: 40
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
David,

I just tried to explain an easy way to model if teams doesn't know UML and don't have time to learn it. This methodology also works for agile project which are using scenarios on white board.
I definitely agree that requirement should be collected at modeling stage but how will a beginner do that if he doesn't know deep UML

I agree there could be better methodologies depending on the project need and this is why UML specialists are getting well paid for and books exist
 
David Newton
Author
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
@Vlad: I was replying to Mark's original message, not yours.
 
Vlad Varnica
Ranch Hand
Posts: 40
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sorry David I am French
 
Bartender
Posts: 2662
19
Netbeans IDE C++ Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Vlad Varnica wrote:Sorry David I am French

Haha. That's no excuse
 
David Newton
Author
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It sounds better if I say "Sorry, I'm American", since we have a worse reputation for being able to listen ;)
 
Mark Reyes
Ranch Hand
Posts: 426
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Vlad and David,

Thanks for giving your insights on this.

But I would like to take this opportunity to get your comments on my way of thinking when it comes to requirements, hope you would be patient enough to read through
Recently, I was given this task.
It's a simple inventory system for machines. This is where user can add/edit/delete/transfer/display machines. (There are other transaction, but I had limited it to these transactions)

My usual way of thinking is to think of the behavior of the system and how user will interact. So I always end up representing them in terms of transactions.
Most of the time I find common methods from these transaction so I follow below class hierarchy.




After doing so, this is where I perform Domain Modelling and assign responsibilities to objects. Oftentimes I end up with below class



I often think that this class performs so many task and I think it violates the idiom in OO theory that a class should only have one responsibility.

Could you comment on this? I definitely think that I could improve something in the way of my OO design.
 
Vlad Varnica
Ranch Hand
Posts: 40
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
We are already at the implementation stage with this class diagram which is fine for me.
I have created the class diagram to visualize it better.
mark_reyes_code_example.png
[Thumbnail for mark_reyes_code_example.png]
 
Mark Reyes
Ranch Hand
Posts: 426
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Vlad,

Thanks for the diagram..

But I am a bit unsure about this class diagram. I am not sure, but I think there is a better way of doing this.
 
Ranch Hand
Posts: 1855
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Mark,

I haven't read the whole thread but only your first enquiry. Since you have your requirements it doesn't matter whether you first draw a use case or the domain model. Both are good and should be part of your design.

Personally I would always start with the domain model based on the given requirements and then continue where necessary with some use case diagrams.
 
When evil is afoot and you don't have any arms you gotta be hip and do the legwork, but always kick some ... tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic