I'm taking a class that includes a high-level review of UML. For a small assignment, we need to develop a Class Diagram based on a "Morphological Box" (see JPG posted at:
http://img682.imageshack.u
I'm not expecting a solution here.... I'm simply asking if someone could get me some pointers for gettting started.
Here's what the solution should include:
- Super class
- Sub class
- Example of possible instances
Again, could someone give me an example (pseudo code would be ok) so that I have a solild starting point?
Thanks,
EEH
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.
Here is part of the Feature class hierarchy.
Feature class hierarchy
Mark,
I worked on my solution and just noticed your 2nd reply with the example. I will have to modify my diagram a bit given that "AngledNailRemovalFeature"
Besides that change that I'll have to make, could you pls review my current approach and let me know if anything else may be wrong?
Also, based on my naming convention, do the 2 suggested (by you) instances correctly apply? Or do I need to rename them?
Thanks,
EEH
ClassDiagram
Mark,
pls see my question above. In previous post, the attached must have been shrunk by EE. Given that's tough to read, pls refer to a better image resolution at:
http://img12.imageshack.us
Thanks,
EEH
In your diagram, you need to separate out the types. A Feature is not a type of Hammer. You have good attributes in Hammer, but they are wrong type - Feature should be features (plural, since there can be multiple) and of type List; Length should be length (since attribute and not class) and of type HandleLength (capitalized since class).
You need to show containment relationship (diamond end of line) between Hammer and other classes, not specialization (subclassing).
Mark,
again, I truly appreciate your help on this diagram.
I've posted an updated (not fully completed) version at:
http://img198.imageshack.u
A few follow-up questions:
1. I use Visio 2003. For "features", I did not see a drop-down choice for type=List. What object/property contains that?
2. I've applied lower cases to all 4 attributes.
-- length = HandleLength
-- do all of the classes have to have an associated attribute? E.g. weight=HeadWeight, material=HandleMaterial, etc.
3. Do I need to break out "NailRemovalFeature" with another subclass such as "AngledNailRemovalFeature"
4. Containment relationship. Right now, I've drawn a containment relationship between Hammer and NailRemovalFeature. All other 4 classes have simple lines. Given that I need the "cardinality" relationships (1:1 or 1:0), I'd have five "1s" next to the diamond. Is it recommended to simply draw the number values (next to subclasses) in a textbox?
Wow, plenty of questions... I hope you don't mind providing me more insights on this topic. 8)
Thousand thanks,
EEH
1- List is an abstraction of other classes. See if they have any Collection type classes (may have names such as list, map, hash, arraylist, ...). If only Array, you can use that (tho not technically the same)
2- all attributes must be of some type - like HandleMaterial, but could be simple object class too, such as String, int, ...
3- Angled could be handled via attribute setting, but that's a design choice.
4- The cardinalities can be different - each line is separate relationship. So, Feature may be 1..* (one or more); Weight would be 1; ...
Mark,
wow... I thought this was a rather straight-forward process. I'm not fully tracking you.
Besides above mentioned processes, I could think of another scenario such as:
1. Hammer
1.1 Head
1.1.1 NailRemoval
1.1.2 StrikingElement
1.1.3 HeadWeight
1.2 Handle
1.2.1 HandleLength
1.2.2. HandleMaterial
I've attached the Visio file. Would you mind providing me one complete parent, child, grandchild relationship in the Visio file? [Note: changed .vsd to .txt in order to upload it]
Thanks,
EEH
see attachments
i am going to be gone for awhile - good luck w/finishing this and please award my points
thx, M
Picture of hierarchy
Business Accounts
Answer for Membership
by: marklorenzPosted on 2009-11-05 at 10:22:59ID: 25752305
You'd want to start by examining the concepts in the domain, in this case (looking at the diagram) you'd want Feature, Weight, Length, and Material. And you'd then have types of Features (i.e. subclasses like NailRemovalFeature, ...), types of Material, ...
The instances would be as shown in the diagram:
- anAngledNailRemovalFeature
- anEightInchHandleLength
- ...
HTH, Mark