Unified Modeling Language (UML) definition: A diagram that shows a collection of declarative (static) model elements, such as classes, types, and their contents and relationships.
Class Diagrams Tutorial
DB Visual Architect - A tool can draw class diagram and generate database.
The progression from class diagram (which describes specifications) to something more immediately applicable by developers (an implementation view) seems dificult. Does anyone have any advice or sources of advice for making this transition?
Possibly because the process abstraction you describe is backward. See for example, Evo Fusion, which is a reasonably good and clear example of one way of doing it. In the diagram in the Evo Fusion topic, the "Inheritance Graphs" are what we call class diagrams. There are many other discussions of this (see Good OOPBooks) and the creation of class hierarchies is both itterative and subject to refactoring over the lifetime of the software cycle. You never "start" with class diagrams. Category Frameworks is a good place to start if a solid foundation of classes is really what you need...-- Steven Black
The progression I'm speaking of is from class design to implementation. In Evo Fusion it would be from Inheritance Graphs to Program. My thinking was that the class diagrams would be produced from specifications and may not represent the best/most practical class design for implementation. In UML Distilled, Martin Fowler defines three perspectives of class diagrams: Conceptual, Specification and Implementation. He recommends creating class diagrams from the Specification perspective and reading his book caused me to wonder if creating them from the Implementation perspective after initially creating them from the Specification perspective would be helpful. Have I clarified my question? -- Jim Icenhower
The key is to make activities concurrent and iterative, which is advocated by all the major methodologies such as the Rational Unified Process, Extreme Programming, Evo Fusion, (all of them). In other words, you start with selecting a basic architecture, then think of implementation details, which leads to a refinement of the architecture, leading to more evolution of the implementation (maybe scrapping some of it) and so on. By the time you have a good general idea of your classes, you can start final construction, which will uncover details that lead to refinements in the class design, and so on. These are all concurrent and iterative activities.
The notion of BigDesignUpFront (a link on the Wiki Wiki Web), where you design everything in excruciating detail before implementation, is dying rapidly.-- Steven Black
Category UML Category Exam 70-155 Hot Topic
( Topic last updated: 2005.03.07 10:56:05 PM )