Working Effectively with Legacy Code (2004) ISBN 0131177052Bunkhouse Review "To me, legacy code is simply code without (automated) tests." So you've realized that refactoring is useful and essential - however it requires that you have unit tests for the system that you are working on (unless you like working without a safety net). Michael Feathers describes how to approach this problem. Sample code is in Java and C++. Great companion to Refactoring.
Domain Driven Design -- Tackling Complexity in the Heart of Software (2003) ISBN 0321125215web page Your application has finally gotten complex enough to invest the effort into a Domain Model. Do changes to your application always seem to run orthogonal to your current object model? To solve these problems you will have to sit down with your domain experts and formulate a ubiquitous language that forms the base for your new domain object model and will be used for communication among the team and the clients. Then you can move on and create the requisite Entities, Value Objects, Services and Repositories which your software solution will be based on. Eric Evans presents the ideas and concepts that are necessary to create an effective domain model and how to maintain it even in the face of less than perfect collaborating systems. Applying DDD gives a more hands on view (if you don't mind a .NET implementation). The minibook Domain Driven Design Quickly is offered by InfoQ.
You use it without being aware that you're using it
You hear about it, read up on it, and tinker a bit
You learn more and start using it explicitly, if naïvely
You get the fire and evangelize (optional)
You learn more and apply it "less naïvely" and more implicitly
Time passes and you see flaws
You question the concept (often because you misapplied it)
You either forget about it or add knowledge and experience (Repeat steps 5--9 as necessary)
You use it without being aware that you're using it
From: A Head Start on Domain-Driven Design Patterns Design patterns make communication more effective. Using design pattern monikers prevents getting bogged down in the discussion of minutiae, provided all parties are equally versed in the design patterns referenced.
We allow inner complexity of language because it enables us to shift that complexity away from the individual utterance.
(p. xlv, The Ruby Way, 2eISBN 0672328844).
If you are using UML as a sketch then most simple UML tools will do. If you want to generate code from UML - well, you may want to reconsider. It is probably going to take longer than to simply code the thing. All of the excruciating detail that you have to supply will only serve to obfuscate your essential design.
Model-Driven Development: One Curmudgeon's View - Why won't the general purpose language be graphical? It was simply faster to write code: Computers don't do big picture.
If you are trying to reverse engineer a blueprint from existing code then be prepared to toss the generated artifact after you have developed an initial understanding of the system. It will usually take intervention from a human being to re-organize and re-interpret the diagrams, to strip away the trivial to only leave the essential, in order to attain any degree of clarity. Usually simpler is better. For example the built-in UML capability of Visio Studio Professional 2002 bogs you down with pointless micro-management of the entire model. With Pavel Hruby's "Visio Stencil and Templates" you can simply focus on what needs to be communicated.
UML for Java™ ProgrammersChapter 5: Use Cases :
Use Cases Diagrams Of all the diagrams in UML, use case diagrams are the most confusing, and the least useful. With the exception of the System Boundary Diagram, which I’ll describe in a minute, I recommend that you avoid them entirely. ... Use Case Relationships Use case relationships fall into the category of things that “seemed like a good idea at the
time”. I suggest that you actively ignore them. They’ll add no value to your use cases, or to your understanding of the system, and they will be the source of many never ending debates about whether or not to use «extends» or «generalization».
Not Object Relational Mapping but Object Role Modeling. In fact the Object in ORM has little to do with the Object from object-orientation. ORM consists of a 7 step Conceptual Schema Design Procedure (CSDP) which leads to a logical model that can then be algorithmically transformed into a design described by an entity relationship or UML diagram. The CSDP hasn't really caught on. However Joe Celko made an interesting observation in his book Data & Databases: Concepts in PracticeISBN 1558604324 p.23:
The main proponent of ORM is Terry Halpin, and I recommend getting his book for details of the method. What I do not recommend is using the diagrams in his method. In addition to diagrams, his method includes the use of simplified English sentences to express relationships. These formal sentences can then be processed and used to generate schemas in a mechanical way. Most of the sentences are structured as subject-verb-object, but the important thing is that the objects are assigned are role in the sentence. For example, the fact that "Joe Celko wrote Data and Databases for Morgan Kaufman Publishers" can be amended to read 'AUTHOR: Joe Celko wrote BOOK: 'Data and Databases' for PUBLISHER: Morgan Kaufman," which gives us a higher level, more abstract sentence...with the implication that there are many authors, books and publishers involved. Broadly speaking, objects and entities become the subjects and objects of the sentences, relationships become verbs, and the constraints become prepositional phrases.
In essence the first step of the CSDP can be used as a valuable method during the initial stages of data design even if you don't go with the full-blown CSDP. This step is described in the sample chapter of Halpin's book. Also users tend to be more comfortable with these word based designs - they don't require them to learn yet another notation (Technical diagrams (ORM, ER, UML) don't make much sense to non-technical domain experts).