Should Modelling Document Analysis?

Question

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:

1. Describe the use-cases to be fulfilled; with scenarios describing the actor's input and the system's response
2. Describe the interactions to be fulfilled; this component/package/domain must have interface X and it must support a conversation like...
3. 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?

Answer 1

I think that Martin Fowler's posts about UML modes - UML as Sketch, UML as Notes, UML As Blueprint, and UML as Programming Language will be helpful to you. I also think that Scott Ambler's work on Agile Modeling, specifically his writings on Model Storming and Just Barely Good Enough Models and Documents, are also very relevant.

I disagree with your statement that "UML encourages specifics". UML isn't a process. There are process that are UML-centric. The Rational Unified Process, for example, is often taught in conjunction with the various IBM Rational tools (which include things like Rational Rose or Rational Enterprise Architect for model-driven development, forward engineering, and reverse engineering). But UML is, first and foremost, a language. That means that each construct (each diagram type) has a specific set of rules that govern the symbols and meaning behind those symbols to enable everyone to have a common understanding.

It seems like you're trying to include too much detail early on. UML is a language. Just because the language has, for example, constructs in a class diagram to represent not only relationships between classes, but public, private, and protected member variables and methods in a class, you don't need to use all of these language constructs all the time.

I think that your overall process flow is good. It seems to generally work for you. I think there are two changes that you need to look at to be more effective, though.

I would recommend looking at things other than UML, though. For use cases, I'm guessing you have something more than a use case diagram. You probably capture use stories or use cases in a tabular format. In fact, in UML Distilled, Martin Fowler even discourages the use of UML use case diagrams in favor or textual or tabular methods of capturing use cases since they are far more useful and valuable. Scott Ambler provides a number of modeling artifacts that may be useful to show different aspects of the system.

You should also consider design as an iterative process. The fact that your models that you use for requirements analysis either need to get revised and refined or thrown later is normal. Your design begins at the same time as your requirements development - you should be thinking about the context of your system (think UML state machine diagrams, component diagrams, deployment diagrams, interaction overview diagrams). As your requirements become more clear, you can add more detail. However, you can't have a fully accurate diagram until you have code, and that diagram is only accurate as long as the code doesn't change.

Recently, I've begun to advocate for code as design. Agile Modeling advocates for a single source of information. Ideally, that source should be the code (and tests). However, in a complex system, it is difficult to just read the code and tests and understand the interactions between components and how the system fits into even larger systems. In these cases, you want any visual design models (UML or some other notation) to be generated from the code, ideally automatically, but hand-created is OK in some cases.

Answer 2

Building on the answer from Thomas Owens...

I encourage you to consider the difference between "Model-Driven" (goal is to directly generate the product from the model) and "Model-Based" (goal is to create "single version of the truth" for the human stakeholders)

I happen to work primarily in SysML (a profile on top of UML) and am firmly in the "model-based" camp. If you are in this camp, the only things that you need in your diagrams are things that specifically help a certain set of stakeholders understand how the system works. For example, you can put a ton of stuff in a class diagram, but doing so is rarely helpful for your human stakeholders.

Likewise, you have to think carefully about your goals for sequence diagrams. You really have to decide which side you are on (Model-based vs model-driven) before you start trying to make the diagram. Last Fall at QA&Test 2015, I had a great discussion with a young Dutch engineer who was working on models in testing. As she put it: "If the diagram is clear and helpful for the humans, it does not have enough information for the computer to execute. If you add enough information so that the computer can execute it, the diagram becomes incomprehensible for the humans."

Hope this helps,