Dr. Dobb's | Making Sense of Modeling

Making Sense of Modeling

According to traditional software development theory, we need requirements, analysis, design, program, test and deploy phases. 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.

May 06, 2004
URL:http://www.drdobbs.com/making-sense-of-modeling/184415822

Software Development's Agile Modeling Newsletter Nov. 2003

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://www.agilemodeling.com/artifacts/ .

--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.

HOT LINKS

The Agile Alliance homepage is the best starting point for anyone interested in learning more about agile software development.
http://www.agilealliance.org.

My article "Agile Model Driven Development (AMDD)" details how to take an AMDD approach on a software development project.
http://www.agilemodeling.com/essays/amdd.htm

Find the Agile Modeling mailing list at
http://www.agilemodeling.com/feedback.htm

Find Agile Modeling training resources at
http://www.agilemodeling.com/training.htm

"Agile Models Distilled: Potential Artifacts for Agile Modeling" provides links to pages overviewing various modeling artifacts such as business rules, use cases, user interface flow diagrams and UML activity diagrams.
http://www.agilemodeling.com/artifacts/

The Enterprise Unified Process (EUP) homepage provides links to leading-edge material describing the Unified Process (UP).
http://www.enterpriseunifiedprocess.info