AM’s principle multiple models tells you that you have many modeling artifacts at your disposal – change cases, user stories, business rules, UML activity diagrams, UML class diagrams, data models, and business rules – to name a few. Figure 1-1 shows that you have a wide range of modeling options open to you, a box represents an artifact that you may choose to create during a software project. Lines indicate major “iteration” relationships between the artifacts (more on this in a bit). An interesting observation is that you have far more than just the diagrams of the UML at your disposal, and when you consider the number of non-UML models depicted in Figure 1-1 you quickly realize that the UML very likely isn’t yet sufficient for business application development. By the way, Figure 1-1 isn’t complete itself – it doesn’t include robustness diagrams, XP’s user stories, or structure charts – so please don’t assume that these are the only models at your disposal.
Naturally, with a wide range of models at your disposal you will want to follow AM’s practice of apply the right artifact(s) to be successful. For example, you wouldn’t develop a use case model to describe your database schema, nor would you develop an data model to describe your user interface design.
Agile modelers will iterate to another artifact whenever they become stuck working on their current model. This immediately gets the modeler moving again, improving their short-term productivity. Hopefully the change of perspective will provide insight into whatever it was that got them stuck in the first place because it gives them an opportunity to go at the same problem from another direction. But what model to iterate to? That’s where the lines of Figure 1-1 come in, they provide a good indication what other artifact you should consider jumping to. For example, if you’re working on an component diagram and find you’re not making progress consider working on your deployment model to explore how you will distribute the software components across your hardware, working on a design class model to understand the inner workings of one or more components, or a collaboration diagram to explore how the components will interoperate.
An interesting result of this practice is that you often find you are more productive following the AM practice create several models simultaneously than you are by focusing on the creation of a single artifact. Because each type of model has its strengths and weaknesses no single model is sufficient for your modeling needs. For example, when you are exploring requirements you may need to develop some essential use cases, some essential UI prototypes, and some business rules. By working on these artifacts simultaneously you can quickly evolve your understanding of the requirements for your system, by working them one at a time you can only evolve your understanding of a single aspect of the requirements. The implication is that you should question the viability of modeling sessions that focus on a single artifact, such as a use-case model, a class model, or a data model. The RUP certainly doesn’t prevent such an approach, but the near-serial flow in the activity diagrams presented for each major modeligactivity doesn’t communicate this concept well.
Agile Modeling’s principles of iterate to another artifact and create several models simultaneously can be tough ones for experienced modelers to adopt. Traditional modeling techniques often promoted a single artifact approach, such as use-case modeling or user-interface prototyping sessions, and often even modelers that focused, for example data modelers. These concepts were great in theory, focusing on a single artifact at a time should have allowed the modelers to get it right quickly, but unfortunately practice shows this not to be the case. A good way to ease into these practices is instead of use-case modeling sessions instead run requirements modeling sessions where you work on use cases, Class Responsibility Collaborator (CRC) cards, business rules, and user interface prototypes simultaneously. Similarly, hold analysis sessions where you are use case modeling, sequence diagramming, user interface prototyping, and class modeling may make sense, and design sessions where you are class modeling, statchart modeling, data modeling, component modeling, user interface prototyping, and hopefully even developing business code. Once you are comfortable with these practices the next step is to then merge your modeling efforts in with your implementation efforts, applying multiple artifacts including all your potential models, source code, and test cases as needed – truly iterative development.
本站仅提供存储服务，所有内容均由用户发布，如发现有害或侵权内容，请
点击举报。
