Simplifying UML class diagram for system comprehension

Question

3.00/5 (1 vote)

See more:

Dear all,

I'm currently doing some survey on UML class diagram. The survey is about how to simplify a class diagram by leaving out information that are not important. The motivation behind this survey is to understand a system (after implementation phase) by using reverse engineered class diagram. As we know, reverse engineered class diagrams are typically a detailed representation of the underlying source code, which makes it sometimes hard for the software engineer to understand what the key elements in the software structure are. Hence, we make this survey in order for us to identify what type of class and information that should be left out from the reverse engineered class diagram. You can find the survey at the following URL :

http://presenceclasses.limequery.com/26994/lang-en

Feel free to ask any question or give any comment on this survey. Your cooperation is highly appreciated. Thank you.

-aislimau-

Posted 7-Jun-12 6:15am

Hafeez Osman

Updated 7-Jun-12 23:26pm

v2

Add a Solution

Comments

Sergey Alexandrovich Kryukov 7-Jun-12 13:19pm

Not clear. What kind of product should promote simplification or be a subject of simplification. What is the model role of the person performing simplification. An author of original architecture/design, a person reviewing existing architecture/design or someone preparing presentation of it? The answer depends on that.
--SA

Hafeez Osman 7-Jun-12 13:28pm

The purpose of class diagram simplification is to help the programmer or software developer who want to maintain the system have the brief idea what is the system structure is all about. This survey aims at to come out with a tool that can do simplification of class diagram. The target person for this tools are software developer, software engineer and software architect. :) thank you for asking...

Sergey Alexandrovich Kryukov 7-Jun-12 16:11pm

Still not clear: your question is not about supporting of reasonable simplicity some work artifact, the question is about simplification. The concern is: it means that there should be two version of some artifact: before "simplification" and after, so: how comes that first artifact needs simplification? why it might be not good enough and for what? who created it and who is going to simplify it? the goal of first and second version? You need to describe the use case and workflow, with motivation.

I would assume your question has a valid point, but at this moment it looks pointless. I would recommend you to think at my questions and use "Improve question" above.
--SA

Hafeez Osman 8-Jun-12 5:27am

Thank you SA... I've improve the question... :)

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Stephen Hewison · Accepted Answer · 2012-06-08T11:20:00

When deciding what to include in a class diagram, I think context is the most important thing.

If you have a system which processes payments, perhaps cash, eft and loyalty card, the system should have a reasonable amount of abstraction. I wouldn't draw the entire system in one digram, I would start by documenting the framework. Draw the abstractions and interfaces, the areas which are common to all types of payment.

Next I'd make a list of the relevant user stories. In this instance they would be:

Cash Payment
EFT Payment
Loyalty Card Payment

If the code was already written and I was reverse engineering for documentation I'd actually start with a sequence diagram, by following the code and generating these for each user story. The sequence diagram would then show you which classes, methods and properties are valid for each user story and as such provide you with the important detail in context of the story you're describing.