Do you guys review diagrams?

[peter king]

Hi Friend,

I 've design a part of an Applicant management System and this portion deals with candidated and their interviews....

This is kind of like a review of my Model.. so before i publish the class diagram i would like to know weather you are allowed to answers for those types of review?  : )

This is a review that i need you judgement that on doubts that i have on certain class relationships and their multiplcities.. : )

Thanks

[son-of-sargasso]

Without a doubt.

Now all you have to do is explain very carefully what your objectives may be if such a review were to be undertaken.

bruce

[peter king]

hi friend,

thanks for consideration....

please refer to the follwing thread for the details and diagram

http://www.sparxsystems.com/cgi-bin/yabb/YaBB.cgi?num=1258282780

Thanks

[son-of-sargasso]

As I said,  what is the objective?

From the diagram, all the specializations are redundant, given the information on the diagram you only need three classes: candidate, interview and outcome.

b

[peter king]

Hi Friend,

I have serveral types of interviews.....

1. The reason i split the interview class is to provide unqie sets of Outcome..

eg:
In the audition, the criteria that an interview is differencent from Directive interview

Audtion
check for
1. Technical skills
2. Documenting skills
3. Team work spirit

In Directive
1. Management skills
2. HR skills
3. Financial skills

therefore in the interview class i have to include
attributes:
1. Technical skills
2. Documenting skills
3. Team work spirit
4. Management skills
5. HR skills
6. Financial skills

if the interview include 100 things to test becuase of generalization then the class will really long....

that's why i've split interview to several interview classes.

Is this not neccessary?

Thanks

[son-of-sargasso]

Probably.  This is what I mean by "whats your objective?"  We can't read your mind and this information isn't in the diagram.

The word "review" is an English imperative with IMO zero meaning.  We can't comment on a diagram unless the context of the model is known.  ("The diagram is not the model!")

Ask specific questions, as you are starting to do.

From your last post, I can see at least three different answers, the most appropriate of which would depend on the context.  For example, I still can't see any difference between these "skills" attributes.

To me, looking at this in isolation an interview has a type (string) and a collection (0..n) of skill outcomes.  A skill outcome has a type (string) and presumably some sort of mark_out_of_ten (int).  This would suggest that there are three classifiers (Interview, Skill and Outcome), ignoring of course the interviewee side of the model.

bruce

[peter king]

Hi Friend,

My appologies for misunderstanding question, typically review means finding errors... however thanks for clarififcation and fixing the issues that makes the diagram complicated!

Thanks

[Geert Bellekens]

I can't see the diagram in question because it is blocked by our internet filter  , but I think the issue here is something that in general surfaces a lot.
The question here is whether to create a new subclass for each type, or provide a more general class with a type attribute of some kind.

Unfortunately there is no general rule to follow, it all depends on the specific circumstances of your design.

Reasons for making different subclasses include

• The different types have a different behaviour
• The different types are used differently. If you see that you have a lot of operations with an implementation that hase a swith-case statement on the subtype of the class then it might be better to design them as subclasses. This allows you to create overloaded operations that only process one specific subtype of the class.

Reasons for using the a type attribute (or an association to a type class) include

• The nature of the subtypes is dynamic -> you need to be able to create new subtypes at runtime.
• The subtype of the class is only a classification, the behavior of the different subtypes is pretty much the same.
• You expect a lot of different subtypes

Even when some subtypes have a different behavior from others, you might want to choose for the "type attribute" solution.
If this is the case it would probably be best to create a "type" class: like that defines the type of the class (because it has an association to it) and also defines the different aspects of its behavior.

Usually in things like this the behavior of the different subtype can be divided in some categories: a set of types uses behavior "A" where another set uses behavior "B". If this is the case you might want to look at the Strategy pattern on how to achieve this.

But as Bruce already said, there is indeed no way for us the know which of these choices is best for you without knowing the whole context. The only thing we could do is review the diagram on the formal UML rules. Everything else depends on the the context.

Geert