UML Object relationships

  • Thread starter Thread starter dkode
  • Start date Start date
D

dkode

Guest
Simple question I believe,

I am using Visio to create UML diagrams of my use cases/static structure diagrams

Now, when i create two objects and then create a relationship between them, what exactly does this accomplish when i generate vb.net code from the uml diagram.

It places a private variable into the class that has the 1 end of the relationship like so:

Private End1 As ArrayList()

I'm not sure what this accomplishes or if creating relationships in Visio is just so you can see how objects relate to each other?

Thanks
 
wyrd said:
Not entirely accurate, but basically, yes. People use UML to design software, which is the process that happens before you actually code anything.[/url]
Click to expand...

UML applications can actually create code (strucutres and links) based on design. I havent used it much (uni course quickly), and that was in Java. I could never actually make it do anything like I wanted. It was easier to code my hand :).
 
In Visio at least, it really depends on what type of relationship you create between them and it's definitely not for visual purposes only. You'll probably find yourself creating Composition and Generalization relationships most often. Composition is when you want one class to be composed of another (ie. contain a variable of that type inside it) while Generalization is another way to say inheritance.

As far as being easier to code by hand, I couldn't imagine that being true for any reasonably complex piece of software. We document our design in Visio, then do a one-time code generation after the initial design phase which gives us well-commented stubs for all classes. It makes it really easy to point a developer to a commented stubbed out class to implement.
 
Ok,

So let me see if I got this straight,

In a UML diagram I have 3 business entities:

Project
Employee
RevenueGoal

I created 3 Collections classes to hold collections of the entities.

Is it correct to create a composition between the 3 classes above and their 3 associated collections classes?

Right now I created compositions,

the * side being on the Project, Employee and RevenueGoal classes and the 1 side being on the ProjectCollection, EmployeeCollection and RevenueGoalCollection

Am i treating the Compositions correct?

I already inherited the business entities from a BusinessObjects base class, so I don't want to inherit them from the collections classes right?

Also, one more thing:
What significance does adding name ends to the composition? the wrox book i bought said to just delete the names?

thank you
 
In that case it sounds like you'd want to inherit from CollectionBase and override Item, Add, Remove, etc. to accept your business entities. Unfortunately Visio's support for working with framework classes is poor so you'll have to work to get the generated code correct with this. When the code is generated the name becomes the variable name inside the composite class.
 
Ok,

just one more question and I promise i'll go away :)

I am making member variables for each field in the tables. I.E.:

m_ProjectID
m_ProjectName
m_Client
m_Location

and then i would make read/get properties to expose each of these to my presentation layer correct?

also,

should i create member variables/properties for data this is linked into another table?

for instance. the project table has a link to the Employee table.

Each Project is linked to one employee.

What i did right now is I will have the Project Business Object create a new Employee object in the variable m_objEmployee and then expose it with a property to access the associated employee.

I think i have figured that part out....

But how do i pass off other tables that I did not create a Business object for. I.E: Status Table, holds StatusID and Status that links to the Project table. Do i need to create a seperate business object for each of my database tables? this doesnt sound right.

if not, then how do I expose the Status table to be bound to a drop-down in my presentation layer.
 
If you've decided to go the Business entity route, then you should probably remain consistent. With ADO.NET, I'm frankly seeing little need for true business objects and instead using pseudo-typed DataTables as containers. We're using a BusinessRules layer that provides validation on saves and such. We basically went with a Duwamish-like architecture.
 
Not a "true" typed as in backed by a schema, but custom datasets that are typed through custom buildtable routines called in the constructor - Duwamish-like. It's been a while since we made the decision but it was something about the regular typed-datasets declaring columns or something as friends so they're unavailable outside of that particular assembly. Since we're defining our datasets as the common data structures between tiers in their own assembly, that didn't work so well.
 
Back
Top