I use UML
I, like most (I think), use UML as my main diagramming toolset. UML is clear and useful for representing OOP and has sufficiently diverse diagrams that there is something for whatever area you are modelling; whether it be class trees, component relationships, or specific interactions between classes.
This means, I have only one model
UML is clearly designed to represent the implemented domain.
Class and object diagrams are rather explicit; they include methods and properties which can rarely be defined with any certainty until you are deciding specific implementation details. Similarly behavioural diagrams feature expicit interactions between objects (messages sent, the order sent, etc.).
However, the early analytical models are rarely so explicit. For context, I approach my early analysis as follows:
- Describe the use-cases to be fulfilled; with scenarios describing the actor's input and the system's response
- Describe the interactions to be fulfilled; this component/package/domain must have interface X and it must support a conversation like...
- Describe processes fulfilled by the domain; this domain must do X and this is the workflow
From here I have a clear set of requirements and begin to analyse the problem domain itself; defining objects/classes, their associations, the kind of information they hold, and the types of operations they support. Lastly I progress to the detailed design which provides all of the implementation-level classes, concretes the exact methods and properties of the classes defined in the problem domain, etc.
I use UML from start to finish, but I end up with only the model defined by the design part of the process. Anything created during the analysis ends up getting revised and refined and tweaked and prodded until it is the same as the implemented design. That is to say, I have only an implementation model, not an analytical model.
There is only one model because...
In short, UML encourages specifics. When I am creating my analytical model, the classes I create have methods with parameters etc. When I move onto implementation, these change and it seems absurd to leave two models that directly conflict with each other.
UML encourages me to write implementation details during analysis because the same diagrams, and therefore language, are used during both activities.
Is this desirable?
Should I adopt a less verbose modelling tool for the analysis so that it does not end up being subsumed within the implementation model?
Or, is it good to have only one model?