Subject: SD Agile Modeling: Making Sense of Modeling Software Development's Agile Modeling Newsletter Nov. 2003 By Scott W. Ambler MAKING SENSE OF MODELING by Scott W. Ambler According to traditional software development theory, we need requirements, analysis, design, program, test and deploy phases. Over time, weíve recognized that the serial approach to development is appropriate only for a small minority of projects in which the requirements are very stable and identifiable from the start -- for the vast majority of projects, an evolutionary (iterative and incremental) approach is more effective. Unfortunately, when it comes to modeling we still havenít discarded this sort of phasist thinking, burdening ourselves with the concepts of requirements gathering, analysis and design. Itís time to rethink this approach. This is necessary for several reasons. First, many modeling artifacts -- use cases, data models, business rules and UML class diagrams -- can be used for all three purposes. This confuses many IT professionals and often results in creation of separate, additional models to maintain several views when only one is needed. Second, this sort of thinking has infected the way that we describe development. For example, the Unified Process (UP) includes a Requirements discipline as well as an Analysis and Design discipline. Many traditionalists making the switch to the UP tend to slip back into their phasist mentality because these discipline names make it easy to confuse new approaches with their old familiar ones. Third, software development has become more complex since these phases were first put forth, and theyíre now too high-level to fairly reflect the complexities that weíre dealing with. We need something more precise and accurate. Donít get me wrong -- it still makes sense to consider these three issues: Youíll always want to ask what your stakeholders want (requirements), explore the details of the requirements (analysis), and determine how youíre going to fulfill those requirements (design). However, it makes sense to consider these issues within the scope of eight focused modeling categories: 1. Usage modeling helps you to identify the way people work with your system. It crosses the boundary of traditional requirements and analysis, and arguably even design, because it explores what users will do with the system as well as the way the system will support that usage (for example, by considering user interface and deployment decisions). Potential usage model artifacts include essential use cases, features, system use cases, UML 2 use-case diagrams and user stories. 2. Process modeling is similar to usage modeling in that it explores the way people work with the system, taking into account the flow of the activities being performed. However, process modeling techniques often explore the flow of artifacts, including but not limited to information, as well as logic flow. Potential process models include data flow diagrams (DFDs), flow charts and UML 2 activity diagrams. 3. User interface (UI) modeling: Every single system that Iíve ever built includes a UI, and because Iím more effective modeling something before I build it, Iím very motivated to find modeling and development techniques that allow me to do so. UI techniques include essential UI prototyping (often created with paper), screen sketches, traditional prototyping, and/or user interface flow modeling (storyboarding). 4. Supplementary modeling addresses the fact that thereís more to identifying what stakeholders need than usage, UI or conceptual modeling. Supplementary models include business rules, constraints, glossaries and technical requirements. 5. Conceptual domain modeling helps you identify the entities, their responsibilities and their relationships within your problem domain. Potential models include class responsibility collaborator (CRC) models, logical data models (LDMs), object role model (ORM) diagrams, robustness diagrams and UML 2 class models. 6. Architectural modeling should focus on the high-level design of a system or an enterprise, as the case may be. Although virtually any model can be used for architectural modeling, I prefer models that can be used to explore the general landscape of your efforts. This includes change cases, free-form diagrams, network diagrams, UML 2 component diagrams, UML 2 deployment diagrams and UML 2 package diagrams. 7. Dynamic design modeling helps you to explore the behavioral aspects of an object system. The UML defines a large collection of diagrams for this purpose, including communication/collaboration diagrams, composite structure diagrams, interaction-overview diagrams, sequence diagrams, state machine diagrams and timing diagrams. 8. Structural design modeling helps you do exactly what the name implies: explore the detailed structure of your software. Because youíll work with both object and relational technologies to build systems, youíll need modeling techniques to explore both environments. These techniques include UML 2 class diagrams, UML 2 object diagrams and physical-data models (PDMs). Having laid down the law, I want to offer a few caveats: --Even though I listed several artifacts in each category, you donít need to create every one. --You donít need to create a model for each category, although you should at least consider the issues that each category addresses. --Modeling is iterative, not serial. --Effective developers understand a wide range of models. The techniques listed in this newsletter are described in detail at http://click.sd.email-publisher.com/maabyWjaa2dFYa9GYQSb/ . --Many other modeling artifacts are available to you; the ones listed above are simply the most common. So how do these categories change the development landscape? First, I believe that they make the complexity of modern software development more explicit. They focus on the high-level issues that you should consider modeling, instead of modeling phases, and as a result, provide better guidance to developers. Second, they provide insight into the types of models that you should create, providing better guidance for your modeling efforts. This column was modified from the forthcoming book The Object Primer 3rd Edition: Agile Model Driven Development with UML 2. The Agile Modeling Newsletter is a monthly newsletter brought to you by CMP Media LLC, publisher of Software Development magazine. Copyright 2003 CMP Media LLC