Hi pals,
I wish to build a 3-tier software and I am confused about which designing approach to use. I intend to class diagrams, use-case diagrams and activity diagrams but I am frustrated on the methodology of coupling these diagrams to give the entire software model.
Unfortunately, I don't know where to start and after many consultations of UML 2.0 books, I seem to rush towards a dead-end. Some authors advise to get use cases from software requirements, some contradict this assertion; some books advise getting sequence diagrams from use cases, some say it the other way round.
Sadly, no material exists for modeling 3 tier-models except in a few cases where component diagrams have been applied but I want to limit my modeling to the above-mentioned diagrams.
Can someone please give me a tip on sorting this out? That is tell me which UML class diagrams fit the purpose of modeling a 3-tier model, whereby the static, functional and dynamic behaviour of a software system can be satisfied?
While waiting for a favorable answer,
Many thanks (and the points of course ; ) )
dmxflames*
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Save solutions to your questions, answers you’ve discovered through searching plus helpful articles in your personal knowledgebase for easy future access.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.
Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
hi marklorenz,
thanks for the comment but I still have some questions...
hmm.. should the UML diagrams be applied to all the tiers of the sytem or designated per tier?
That is, should I :
1. design use case diagrams, sequence diagrams, class diagrams and state diagrams per tier
OR
2. design a general use case for the system, general sequence diagram for the system and for each tier; UML class diagrams and state diagrams?
thanks
The use case diagram should be by role - e.g. one for Doctor, one for Nurse, one for Patient
Sequence diagrams should be by use case - e.g. one for Add new patient, one for Schedule new appointment
Class diagrams should be by subsystem - e.g. one for Staff management, one for Scheduling
State diagrams should be by those classes with complex state - e.g. one for Operation (Scheduled, In Progress, Complete)
Be aware - these UML diagrams are mostly used for the model tier, not the UI or the support tiers. The UI can be designed via storyboards (drawings that show their layout and navigation). The DB should be designed via ER diagrams.
HTH, Mark
Business Accounts
Answer for Membership
by: marklorenzPosted on 2008-11-29 at 10:13:31ID: 23060374
There are three primary UML diagrams you need:
(1) Class diagram - to document the static relationships between the concepts (classes) in your system.
(2) Sequence diagram - to document the dynamic, time-ordered method calls to carry out a particular use case.
(3) State diagram - to document the various states an object takes and what causes the transitions. These are used much less then (1) and (2) above.
The general order of things is:
(1) Capture requirements in use cases. Each use case details what must be done to satisfy the requirements from one event (user action, timeout, message from another system, ...).
(2) On a use case by use case basis, start the design process. This involves walking through the use cases, simplest path first, and adding messages to your related sequence diagram. As you do this, you will also add classes and methods (and to a lesser degree data) to the class diagram to satisfy the messaging in the sequence.
You can then continue to move the use case design forward into implementation or go on to another use case (or if your team is large enough, work on both in parallel).
The tiers you mention relate to the Model View Controller (MVC) pattern which is fundamental to any well-designed system. Some systems also break out support layers, such as for persistence.