Class Diagram with aggregation and generalization

views:

278

answers:

+1 Q:

Class Diagram with aggregation and generalization

I am working on a university project and i have the following problem i can not figure out.

I have a class Called Employee from this i generalize two classes Contractor employee and Permanent Employee.

Now i have a team that is made by both types of Employee so i am planning to use aggregation.

Do i have to connect the team class to the two subclasses or to the employee class?

Thanks

+2 A:

Hmm interesting question... If your Team class only refers to Employee, you'd be able to expand in the future to other types of Employees (TeamLeads, Managers, etc...). If you bind your Team class to Contractor and PermanentEmployee, you are effectively saying that a Team can have Contractors, Perm.Employees, and nothing else! But maybe that's what you want...

FrustratedWithFormsDesigner 2010-02-08 21:51:18

Hmm side question: Would it be possible (in Java) to have a GenericTeam which can be passed serveral parameterizations eg.Team<Contractor,PermanentEmployee,StudentSlave> ?

er4z0r 2010-02-08 21:54:50

@er4z0r: Sure, you could use Generics do determine what kind of employees will be in the team, but as far as I know you can not have a variable number of generic types passed to the class. So you could have `class Team<E1 extends Employee, E2 extends Employee, E3 extends Employee>{...}` (syntax may not be 100% correct but you get the idea yeah?) but that would mean your Team class could have at most 3 different kinds of employees.

FrustratedWithFormsDesigner 2010-02-08 22:01:59

Thanks. The variable number of generic types, was the key point. If that is not possible it would probably be better to have an interface/abstract class Team<V> and leave all the constraint-checking (e.g. can only contain Contractor and PermanentEmployee but not StudentSlave) to the implementing class.

er4z0r 2010-02-09 07:54:24

+5 A:

To the employee class. The team class will have a list of Employees; it won't care it they're actually ContractorEmployees, PermanentEmployees, or FooEmployees.

JacobM 2010-02-08 21:51:34

But what if a team is made by only one Manager and any number (any type) of employees? does the relationship remain the same? and what if the contractor has to be connected to a particular qualification(class)

GigaPr 2010-02-08 22:02:55

@user183089: If you want restrictions on certain types of employees, those have to be indicated separately.

FrustratedWithFormsDesigner 2010-02-08 22:05:06

I mean i connect the Team Class to employee but do i have to connect the qualification to the contractor of again to employee?

GigaPr 2010-02-08 22:07:40

There's not much point in having a generalized parent class in this case if you can't use it for polymorphism.If your team will have a link to a manager and a link to a group of employees, then sure, these will be two links, one specifically to the Manager (one-to-one) and one to Employee(one-to-many).Further restrictions probably don't belong in a class diagram -- remember that the class is supposed to be the generalized template used for all cases. Things such as "this particular team should only have Permanent Employees" aren't class attributes.

JacobM 2010-02-08 22:08:52

Of course, you could also specialize the Team class and make a PermanentEmployeeTeam class that ONLY has a relation to PermanentEmployee (instead of Employee). That PermanentEmployeeTeam class should probably extend the Employee team class.

FrustratedWithFormsDesigner 2010-02-08 22:22:02

To what @JacobM has said, I would add that although it may seem obvious that teams have one and only one manager, reality can have other ideas. Even those setting the requirements may have discounted the edge cases (that one time a team had two managers, or that one team that had no manager for a week...), unaware that edge cases too minor to worry about in the real world can cause major headaches if not accounted for in software. So don't add constraints to a design without getting business value back, like cheaper implementation.

Wayne Conrad 2010-02-08 22:26:32

Take a look here: Composition Associations

In UML 2, aggregation would be shown with an open diamond.

Rubens Farias 2010-02-08 21:53:12

Don't use aggregation between Team and Employees or their subtypes. The Team class has a attribute 'Members' which is a collection of Employees. This way the Team can have any combination of Employee subtypes including any other subtypes added later.

Kelly French 2010-02-08 22:35:19

I think you are only partially correct Kelly. If you said "Don't use aggregation between Team AND SUBTYPES of Employee" I would totally agree. But what is the problem about an Aggregation between Team and Employee. What you describe (collection of Employees) is IMHO just the implementation of an Aggregation relationship in the model.

er4z0r 2010-02-09 08:01:46

@er4z0r: It really depends on how loose the association is between the class doing the aggregation and the class being aggregated. A rolodex is nothing more than a collection of contacts, a team can be much more than a collection of employees. Also, when there is a chance of a many-to-many relationship (Teams made up of many employees, employees belonging to many teams) it's much easier to avoid the many-to-many problem by including the collection class in the model, hence a Members class.

Kelly French 2010-02-09 14:17:39

ansaurus

tags:

views:

answers:

Class Diagram with aggregation and generalization

related questions