plz, check the diagram at http://www.mycgiserver.com/~dronski
this is considered to be more a high-level diagram, than a design one. does such model communicate the idea? i'd like to here from you concerning exactly how clear the model is. after your reply i'll describe what i really wanted to model and what ideas i wanted to bring to you, all.
best regards,
Andrew
Yes the idea is pretty clear. Your NotificationsManager sends Notifications via Senders.
But I don't understand why a NoticationsManager not just sends Notifications. Why do you want it to send EmailNotifications and SMSNotifications (the same applies to the senders).
I think that you should describe the overall structure (NotificationsManager, Sender, Notification) in one diagram and have class hierarchies (SMSGate implemnts Sender, EMailListServerGate implements Sender, SMSNotification extends Notification, EMailNotification extends Notification) in another.
Søren Bak
I tried to show the association between the NotificationsManager and Notifications. But then arises another problem - I cannot show clearly the association boundary classes. I wouldn't like to incorporate the sending logic into the manager, for e.g., now the SMS provider is implemented as a third-party webservice, but the e-mail senders can be decided between a third-party and home-grown solution (using JavaMail and local SMTP server).
The whole idea is using the double polymorphic hierarchy, so the call to manager would be something like
notificationManger.sendNotification(Notification, Sender);
if you have more ideas how to describe this on a UML diagram, I am open to your input :)
Its a good class diagram but to convey your design properly the best way is to follow the 4 + 1 view design methodology. So you would have to have about 5 views at least to deliver your design. Tese views would include
1)Use Case
2)Sequence
3)COllaboration or class diagram (one of teh two would do)
4)State or COmponent Diagram (Again one of the two would do)
5) Dseployment diagram. (Its good to have it but I personally eould consider it optional at this stage).
Sure, there are other views of this subsystem. Just wanted to have your feedback on this one, for I'm in the processing of learning to apply UML in practice.
I guess, this refined one is better:
http://www.mycgiserver.com/~dronski/Notifications_system2.png
Of course, it's not enough to describe the subsystem in details, other diagrams and comments will do this. I have a question here: is the use of a boundary stereotype ok in this case? According to OMG UML specs, they claim that boundary is the 'proxy to interact with other systems, transforming one representation of input/output to another.'
> [..] the best way is to follow the 4 + 1 view
> design methodology. So you would have to have about
> 5 views at least to deliver your design. [..]
I strongly disagree. The best aproach is to have any number of diagrams that you need to make the intent clear.
If this can be done with one diagram (as with the second diagram posted) thats fine.
In many cases it is not possible to convey everything one wants to describe in one diagram, then it makes sense to think about the other diagrams mentioned in your list.
There is no rule saying 1 or 2 is bad 4+1 is good.
regards
Spieler
> > [..] the best way is to follow the 4 + 1 view
> > design methodology. So you would have to have
> about
> > 5 views at least to deliver your design. [..]
>
> I strongly disagree. The best aproach is to have any
> number of diagrams that you need to make the intent
> clear.
>
> If this can be done with one diagram (as with the
> second diagram posted) thats fine.
>
> In many cases it is not possible to convey everything
> one wants to describe in one diagram, then it makes
> sense to think about the other diagrams mentioned in
> your list.
>
> There is no rule saying 1 or 2 is bad 4+1 is good.
>
> regards
> Spieler
You could do it in one view or in two but then there is a difference between Object Oriented Analysis and design and a good Object Oriented Analysis and design. Thats what the grand masters like martin fowler, Booch, Rumbaugh have been preaching all along. And they not me came up with this idea of 4 + 1 views. refer to
http://www.cs.rug.nl/~ben/Courses/EmbeddedSystems/chapter8.html
This architecture modelling technique has been mentioned in all the major books about UMl, including gang of four and The Unified Modelling Language Users Guide by Booch, Rumbaugh and Jacobson.
Hopefully you would refer to some books or browse a li'l before disagreeing so strongly next time.
> Hopefully you would refer to some books or browse a
> li'l before disagreeing so strongly next time.
I have read various books and web pages including large parts of the specification. And I am well aware of the 4+1 aproach. But I still allow my self to have a opinion of myself. Which is in the current case:
4+1 is a great thing for complex models. But if one view is sufficient and still simple, why bother with another 4 views.
This matches the general aproach most people use to UML (which is also recommended in various books if it makes a difference to you):
- Use what is helpfull in your case ignore the rest until it becomes helpful
What good is it to have 5 view when one is sufficient. I'm pretty sure
the design gurus had more complecated things in mind then the diagram in question when they developed the 4+1 method.
my 0.02Euro
Spieler
