« Back

Software Modeling & Design: UML, Use Cases, Patterns & Software Architectures

Comet: Yet Another Small-m Methodology

by Fernando Berzal

Myriads of books on conventional notations, "Big-M" methodologies, agile methods, maturity models, and improvement frameworks make it easy to find high-browed discussions of software development alternatives that tend to forget the essentials that help newcomers be productive in an industrial setting. In this sense, Hassan Gomaa's attempt to "address the specific needs of designing software architectures" is worthwhile on its own. His book goes beyond what you can find in standard software engineering textbooks, and its proposed methodology and focus on case studies make it suitable for lab courses.

That said, the methodology has some minor pitfalls that users should address with care if they choose to adopt Software Modeling & Design as a textbook for a hands-on software engineering course.

The Comet Method

The Collaborative Object Modeling and Architectural Design Method — Comet, for short—proposed in Software Modeling & Design advocates a streamlined process for large-scale software system design, specifically — in the author's term — a "use case-based software life cycle."

The Comet method makes extensive use of the standard UML 2 notation. It starts by modeling both functional and nonfunctional requirements by means of relevant actors and system use cases. Gomaa adopts a traditional top-down (almost structured) approach to specifying use cases, rather than the more flexible essential use case approach commonly employed by user interface designers, as clearly explained in classics such as Constantine and Lockwood's Software for Use: A Practical Guide to the Models and Methods of Usage-Centered Design (Addison-Wesley, 1999).

Two differentiated modeling phases follow the initial requirements modeling:

  • analysis modeling is performed on the problem domain, and
  • design modeling is completed from the perspective of the solution domain.

The analysis modeling phase decomposes the problem to understand it better, identifies domain classes, and realizes use cases through objects. What Gomaa calls analysis modeling is no more than domain-driven design (for example, see E. Evans, Domain-Driven Design: Tackling the Complexity in the Heart of Software, Addison-Wesley, 2004). It's hardly "object-oriented analysis," although this abuse of terminology is common in many object-oriented design textbooks. Obviously, there is always some intellectual analysis in any design activity but, in fact, I've never found anything "object-oriented" around use cases nor have I found any "analysis" in class-level design — at least, as the term is commonly used in software engineering.

Comet's design modeling phase addresses the key solution-domain issues in architectural or high-level design. To acquaint readers with the most common solutions to complex software systems design, Gomaa reviews half a dozen kinds of software architectures, from client-server and service-oriented architectures (SOA) to software product lines. His discussion of architectural design patterns includes specific communication patterns—synchronous/asynchronous, brokers, transactions, and so on—and addresses many design considerations that naturally arise when using them.

A Pragmatic Perspective

Apart from describing the proposed Comet design method, the book introduces the most common software life-cycle models, different (and complementary) software architecture views, and many other useful design concepts. The examples are easy-to-understand, although some might say they're too idealized or even simplistic.

The Comet design method makes extensive use of static and dynamic object-oriented models in UML notation. This is probably the weakest part of the book. First, it contains some inaccuracies; for example, its "unary associations" are, in fact, binary — recursive associations, according to the UML standard. Furthermore, the book deviates somewhat from conventional UML diagram usage by employing interaction diagrams (that is, UML 2 communication and sequence diagrams) almost as data-flow diagrams in order to defer design decisions to a later design phase. This might mislead some readers and even annoy object-oriented purists.

If you want a more in-depth treatment of object-oriented design using UML, as well as detailed design heuristics and guidelines ("structuring criteria," according to Gomaa's singular terminology), I would suggest Craig Larman's landmark book instead, Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd ed., Prentice-Hall PTR, 2005)

Breadth rather than depth

Although Gomaa didn't intend the book to replace standard software engineering textbooks, he has put a great deal of effort into making it as self-contained as possible. He covers a wide range of issues that are fundamental to the proper design of working systems—from the use of nested and long-lived transactions in actual software systems to the logical design of relational databases (that is, how to derive a set of tables or relations from a conceptual model that's specified as a UML class diagram. Unfortunately, trying to take on too much takes its toll. Most topics are only cursorily examined, hiding the complexity of their proper use in practice. The excessive use of forward references in the text doesn't help either.

The book is still a nice complement to more conventional software engineering volumes. Gomaa provides some suggestions for teaching different kinds of courses based on his book. Its tutorial style and its four detailed case studies make it particularly suitable for advanced undergraduate lab-based courses involving student projects. Each case study addresses a particular architectural style: a client/server banking system, an online shopping SOA, a distributed component-based emergency monitoring system, and a real-time vehicle system.

Apart from their use as starting points for student projects, the lavishly illustrated case studies can also help students analyze common design decisions and gain an understanding of how all the different pieces fit together in industrial software development projects.

Fernando Berzal is a researcher at the Information and Communications Technologies Research Center (CITIC) and an associate professor at the Department of Computer Science and Artificial Intelligence, both at the University of Granada (Spain). He's a member of the IEEE Computer Society and a senior member of the ACM. Contact him at berzal@acm.org.

More Reviews