I´ve tested a little bit with the Whitehorse "modeler". I´ve some questions:
- Do you provide only 2 diagrams (infrastructure and class diagram) ? I think it´s necessary to have a use case diagram, activity diagrams, sequence diagrams and class diagrams as minimum set (see UML for more details).
- The class diagram is like the UML class diagram but with less functionality - e.g. in Whitehorse I have only the directed association and the generalisation. What´s about the rest ? (Aggragation,composition, ...) Will these features come in the final ?
- If I add an abstract element (method, ...) the designer generates e.g. a method body -> that´s a bug.
- I cannot see abstract, virtual, ... in the class diagram - I have to read the tooltip.
- If I use the association to connect two classes the designer automatically generates a property. How can I have an association without a property - if I need the class1 to use the class2 (initiate).
- will there an interface between Whitehorse and UML XMI ?
- most of the UML tools has the feature that you can "draw" the model and get the code for that - and vice versa. In whitehorse (for now) I cannot drag and drop a new class into the "class diagram" - why ? Is that a feature for the final Version ?
Summary: A real UML tool (like rational xde) has about 20 diagram types. Everything is possible. Whitehorse is very "primitive".
How can I develop GOOD software if I start with the infrastructure or the class diagram -> that is not possible (see some OO guys like R.Martin, ...). Infrastructure is a (implementation) detail. The class diagram is also very detailed and not a good starting
point for OOD/OOA.
What´s your way ?
How can Whitehorse "survive" if it is only a smaller UML.
Very Important: You know that UML is not only the class diagram, yes ?!
Whitehorse is not UML, but rahter a DSL (domain-specific language) tool, which makes it much more suitable for actual software design. You should read
this post, and other posts at
Keith Short's blog.
"We’d recommend precisely defined DSLs and DSL-based tools for
Precise abstractions from which code is generated
Precise abstractions that map to variabilities in frameworks and components
Precise mappings between DSLs
Conceptual drawings that have precisely specifiable mappings to other DSLs or to code artifacts"
This is also possible with the UML tools. So why do I need a worth "class diagram" in whitehorse ?
Having experienced first hand the mismatch between UML and programming languages, first by mapping UML to Java for a standard UML profile, and then by mapping UML to C# for a UML based modeling tool, I'm not convinced that these things can be done well
with UML tools.
Have you tried modeling C# properties using UML? How about events? Did you find the results satisfying?
Have you tried putting a UML class diagram that talks aobut attributes and operations instead of fields and methods in front of a code oriented C# developer? What response did you get?
Someone has actually noticed there is a H U G E gap between system modelling tools such as UML and the finished coded article.
Adding to UML is almost like 'un-controlled' growth, some could say a wart! I'm not impressed with what I have seen so far and I count myself as abit of a veteran of system design for many years, the silver bullet is allot closer but still for my mind along
UML diagrams for me for are the bare-bones and gives you the first pass in the thinking of how an applications structure could possibly fit together.
For me in actual reality a good percent of detail doesn't get stored out until you are coding the applications. I have found the prototypes do far more me in helping to design an application than UML. Also old techniques such as P/Code (now I'm showing my age)
really did help in establishing a good program simply by allowing the developer a valuable pass at the eventual program at a lower level of detail.
Obviously such primitive techniques are all well and good but the challenges of modern day computing such as OO design and SOA need applications to look increasing at the bigger picture as well as up close and personal.
What we need is a design standard that will allow us to design and build application in an iterative fasion at many different design 'resolutions', from the 'big picture' to 'fly wing' detail that simply inter-locks.
... and finally it's got to be a standard that we can all hum.
Hmmm, something to ask Santa for ... oh and world peace.
Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.