Today I am preparing to teach a UML course at Emageon in Milwaukee, WI. I have presented this course several times for different clients in the past and have refined it each time. The central theme in my training is a "use case driven" process coupled with visual modeling. These two concepts are cornerstones to the USDP.
UML, therefore, is a visual expression and expansion of the use case model. The use case model is a reflection of the system requirements, and the UML model expands upon this model. It is beneficial to achieve both behavioral and structural views of the use case model using UML. Structural views manifest themselves as class diagrams, component diagrams, and collaboration diagrams, while behavioral views are manifested by activity diagrams, sequence diagrams, and state machines. Additionally, it is helpful to have a good mix of these diagram types -- each one is intended to address a specific viewpoint or level of detail.
Structural models address the "static" view of things. For example, class diagrams express the structure of classes, their associations with other classes, and their inheritance hierarchy. Behavioral models address the dynamic interaction of things in the system. For example, a sequence diagram emphasizes the messages between objects in a scenario, especially the sequence of those messages. It is very important to address both the structure and the behavior of objects in a system.
Another useful view is the State Machine, which is primarily used to express the complex behavior exhibited by a class, especially when the class exhibits different behavior depending on its state.
I have found that the most useful progression of UML modeling is as follows:
1) Begin with the use case model.
2) Expand the use case model using Activity diagrams.
3) Identify the "things" in the system. These are most evident by looking for nouns in the use cases and activity model. These are classes, modeled (of course) by a Class diagram.
4) Examine the simple behaviors of each class and how each class collaborates with other classes. Document these behaviors as operations on each class (in the Class diagram) and as collaborations (in the Collaboration diagram).
5) Document each scenario in which message sequence is critical by using a Sequence diagram.
6) In cases where objects exhibit complex, state-dependent behavior, use a State Machine.
For completed systems, use the Component and Deployment diagrams to depict the physical implementation and relationships among nodes.
Wednesday, October 24, 2007
Thursday, October 11, 2007
It occurs to me that some folks know about the Unified Software Development Process (USDP) and how it can ensure quality results. They may even act as process evangelists, helping IT shops implement process changes and USDP development techniques.
It also seems to me that some of them don't really believe in it. Maybe they understand the benefits from an academic perspective, but having never actually lived in a "process pure" environment, they see software development processes as intrusive and weighty.
The truth is, software development is chaotic by nature. The questions of "how do we begin", "how do we know when we are done", "what are our deliverables", and "what is quality" seem basic. However, it is surprising how often development projects are undertaken without understanding what these things mean. Even when process evangelists are involved from the beginning, when the team fails to follow the process systematically the project will begin to degrade toward chaos.
A good development process does not have to be heavy. The most important features (use case driven development, visual modeling, and iterative development) can be tailored to the project and the project team.
Following a USDP can lend order to the chaos. It provides focus to the development effort. Everyone on the team has a common mental picture of what must be done, how it should be done, what is being produced, how the components relate to each other, and how to know when they are done and done correctly. Even when things start to degrade, as they often do when schedules and budgets get tight, a good development process is self-healing. It provides the disciplines needed to regroup and re-focus the team, mitigate risks, resolve unforeseen issues, and establish corrective measures.
Actually putting the USDP into practice is the key to understanding its benefits. Once you have been on a development team whose focus is USDP, you will never want to do things the "old way" again.
It also seems to me that some of them don't really believe in it. Maybe they understand the benefits from an academic perspective, but having never actually lived in a "process pure" environment, they see software development processes as intrusive and weighty.
The truth is, software development is chaotic by nature. The questions of "how do we begin", "how do we know when we are done", "what are our deliverables", and "what is quality" seem basic. However, it is surprising how often development projects are undertaken without understanding what these things mean. Even when process evangelists are involved from the beginning, when the team fails to follow the process systematically the project will begin to degrade toward chaos.
A good development process does not have to be heavy. The most important features (use case driven development, visual modeling, and iterative development) can be tailored to the project and the project team.
Following a USDP can lend order to the chaos. It provides focus to the development effort. Everyone on the team has a common mental picture of what must be done, how it should be done, what is being produced, how the components relate to each other, and how to know when they are done and done correctly. Even when things start to degrade, as they often do when schedules and budgets get tight, a good development process is self-healing. It provides the disciplines needed to regroup and re-focus the team, mitigate risks, resolve unforeseen issues, and establish corrective measures.
Actually putting the USDP into practice is the key to understanding its benefits. Once you have been on a development team whose focus is USDP, you will never want to do things the "old way" again.
Subscribe to:
Posts (Atom)
