There has always been a controversy between modeling and coding. All from the point where models are to be turned into code automatically, through the state where models are written and then forgotten after coding has started, to the point where one generates models from the code.
To me, code and model is representations of the same thing – the problem to be solved, or the solution to the problem. And when the solution matches the problem, which sometimes happens, all is well.
So the artifacts one make in a model IMHO it should be possible to map to code. I do believe that should be a strong guideline for which artifacts one uses in a model. If that holds, one can always reverse engineer a model from code, at least to a certain degree.
In order to make the picture more complete when one uses Use Cases for specifications is to add navigation diagrams to the suite. The term is coined by Manassis I think, and it shows how the different GUI pages are navigated. This takes form of a set of classes (one for each GUI page or independent part of a page) which depends on each other, where the dependency is named based on how you access the dependency. Ex.: “Button: Create New”. Although they say a use case diagram should be independent of the realization in form of GUI’s, I normally take a more pragmatic viewpoint, and connects these things together. One is to make a software program after all – not a theoretical thesis. I often connects a use case with a graphical page, or in some cases a page may encompass multiple use cases. Anyway, by using tracing from the use cases to the GUI pages, those relationships are taken care of, and a relationship matrix can show which use cases and which GUI’s are not connected, thus revealing missing specifications.
So, the use cases links to user interfaces (or messages for a message based system). Since the logic for the use case is not to be engraved into the user interface it has to be the Controller (or presenter or service component) that orchestrates the use case steps, hopefully most of it delegated down to the domain model. See Controller pattern within the GRASP patterns (Craig Larman).
Very often one uses the Use Case as the main work item for realizing a certain set of functionality, which encompass code on several layers, from the GUI layer, the controller layer, and on the domain layer, possibly also on the database layer. This duality, the use case both representing the code for the logic of the use case, and representing the whole work package for that behavior, is something I believe one just should accept, and not try to mitigate. It really poses no big problems, and mitigation of this would probably only cause over-complexity in the work item tracking or model.
Team System 2010 introduces the Layer Model, which can be used to enforce a more strict layering model in an application, making sure code is not placed inadvertently at the wrong layer, or crossing layer boundaries inappropriately. When one starts to take layering more seriously one also needs to be clear on which artifacts relates to which code-layer. The navigation diagram classes maps to GUI pages or GUI control classes. The Use cases maps to Controller classes. The domain model classes maps firstly to business class domain classes in code, and then, through some O/R mapping into a database model. Having a layering model, together with the necessary model elements, it should be possible to maintain a consistent relationship between model and code. One can then use whatever view one chooses and finds most convenient, and be sure that code and model is in sync. If the model then represents the specifications, the problem to be solved and the solution is also kept in sync.
