UML Modelling and design class diagrams (For business logic?) [RESOLVED]

Hi all

I was hoping some of you could share your insight with uml diagrams.

I have a question regarding UML modelling, specifically with Design Class Diagrams.

I am in the process of modelling a system, and i need to know which classes i need to make design class diagrams for.

I have base classes such as "Customer" that stores the actual information like "First Name" etc. I also have business logic classes that hold the business logic relating to the customer component... e.g. search methods for finding customers etc.

Do i make "Design Class Diagrams" for the Business logic classes as well? and if so, what do i put down as attributes?

Quote:

---

Originally posted by Rockhopper
Hi all

I was hoping some of you could share your insight with uml diagrams.

I have a question regarding UML modelling, specifically with Design Class Diagrams.

I am in the process of modelling a system, and i need to know which classes i need to make design class diagrams for.

I have base classes such as "Customer" that stores the actual information like "First Name" etc. I also have business logic classes that hold the business logic relating to the customer component... e.g. search methods for finding customers etc.

Do i make "Design Class Diagrams" for the Business logic classes as well? and if so, what do i put down as attributes?

---

Class diagram should be as detailed as possible. So if you include as many as neccessary to describe the system. I tend to design all Classes and use "Generate Code" feature to generate the base classes.

Yes you would put business logic in the Class Diagram too. Depending on what they are they might be Methos or even a seperate class.

In your case

Code:

---

Class : Customer
Attributes :
        Name
        Address :
        Phone :
        etc....
Methos : Search():
              Edit():
                Delete():
                Add():

---

Hope this helps

Danial

Thanks for your reply...

I realise that business logic must reside within the design class, yet in my customer class for example, i am merely storing attributes. I then have a seperate class that holds all the methods that use the customer class... so essentially the customer class is just a storage container with properties to get and set the attributes of the class.

I'm not sure if this is the best way to go about object orientation, but it is essential to seperate the business logic into its own layer.

My question i suppose is this: Do i make a seperate design class diagram(DCD) for the business logic class that will essentially contain only Methods and no attributes, and then a seperate DCD for the customer class that will contain attributes and a constructor(as its only method really)?


Thak you for your time, i appreciate it.

Quote:

---

Originally posted by Rockhopper


Do i make "Design Class Diagrams" for the Business logic classes as well? and if so, what do i put down as attributes?

---

nothing. If classes are stateless (the business logic ones) then they don't have attributes- only methods

personally i wouldn't include classes that belong outside the immediate layer - mark them as 'object' if unknown and add a little note that points the reader to an associated diagram somewhere.

UML is part of iterative design process - you'll never get it right in the first take, you need to keep revisiting diagrams over and over as your project evolves (at least that's what you tell your boss ;) )

powdir

Quote:

---

personally i wouldn't include classes that belong outside the immediate layer

---

Thank you for your insight... it has cleared a bit up. The only thing of concern to me is that most of my base classes (cCustomer, cDepartment, cStaff etc.) hold only attributes, as well as only one method (the constructor that fills the attributes).

All the logic that operates on these classes is held in the business layer (blCustomerSupport etc)

Do i not make Design Class Diagrams for the business logic classes? Or do i make them with just the methods?

thanks again:wave:

Quote:

---

Originally posted by Rockhopper


Or do i make them with just the methods?

---

yes...just methods. Business layer classes typically have no attributes

Cheers

Thanks hey:thumb:

Hi guys,

Quote:

---

e.g. search methods for finding customers etc.

---

From what Rockhopper is saying, it does not seem that his "Business Objects" are business objects at all. All methods pertaining to Loading, Saving, Creating (initializing) and searching are Data Service objects. Each business object can have its own corresponding data service object, or you can use a generic object for your components. These data service objects should be stateless and, in addition to being used for the above mentioned functions, should be used for large data manipulation.

Quote:

---

Do i make "Design Class Diagrams" for the Business logic classes as well?

---

I think Rockhopper should make a separate class diagram for these objects and they should be part of the data services component and not the business rules component. Rockhopper should also include UML diagrams to show the interaction between the Business Objects and their corresponding Data Services objects.

Quote:

---

the constructor that fills the attributes

---

Also, the constructor that initializes the Business Objects (BO) should be declared as friend. Only top level objects (in the BO relationship hierarchy) could possibly have public constructors. Child BO's should ALWAYS be loaded from property/function of its parent, and they should always be created and initialized by the parent.

Quote:

---

i am merely storing attributes.

---

Dont worry about this... There are many, many cases where your objects will just be attributes. I have produced some small systems where the BO's only have attributes. In cases such as these, 3 tiered design is often a HUGE overkill! You could easily get away with databound forms using ADO and a connection direct to the database. In fact, you should be thinking of M$ Access in this case. You need to constantly weigh up application complexity/potential for growth/time/money(most important)

Quote:

---

essential to seperate the business logic into its own layer

---

Question this! Think very carefully, cause it might not actually be necessary... Time is money. Dont try and anticipate some large app if it is small scale. Get it out! And get it stable!

hey shunt... see ur a local (Kenilworth)

Thanks for the post.

The system we're building is quite complex... so we have seperated it into the data layer, business logic layer and presentation layer.

The project is part of the 3rd yr I.S. course at UCT... so it all has to be right.
On the up side: We got the second highest mark fo rour URS, (second by 1 annoying %), so all the advice from the forum has been great.

keep it up guys :thumb:

Check your vbforums personal messages...
Contact me... Want to ask some questions on the course youre doing...
I might need some UCT student contractors if you guys are up for it...