Decision Framework, J. Duggan Research Note 11 September 2003 Evaluating OOA&D Functionality Criteria Looking at nine criteria will help you evaluate the functionality of object-oriented analysis and design tools. In Gartner's OOA&D tool selection best practices, functionality comprises nearly one-quarter of the decision. Core Topic Application Development: Architecture and Design for Application Development Key Issues What techniques and tools best translate user needs into IT requirements? How will best practices in metadata and information management, and modeling techniques and tools enable SODA and promote enterprise understanding of technical implementations? Although criteria to help evaluate the functions and features of an object-oriented analysis and design (OOA&D) tool are crucial to its successful selection, other considerations frequently have a greater influence on which technology is ultimately purchased. In "Object-Oriented Analysis and Design Tool Selection Criteria," we describe the best practices for identifying, organizing and weighting OOA&D selection criteria. These categories of criteria are functionality, vendor viability, vision, cost, and service and support. Here, we explore the nine functionality criteria (which make up 24 percent of the total decision) in more detail. Integration With the Business Modeler Business requirement analysis, which is driven through a combination of textual requirements and visual models, is a major factor in the successful use of objects in design. Use-case analysis, written requirements or XP stories, and test cases all work well for small-project elements; however, they need to be supplemented by a context or index in larger, more-complex projects. Business process modeling tools provide good higherlevel views to supplement OOA&D. Ideally, a business model and an IT model would be different views of the same information and could be populated without duplicate input that is, the transition from one to the other would be transparent. More-commonly implemented is the ability to move business models into a use-case representation, which is marginally useful if the use cases cannot then be linked to other diagrams, as in the original object-modeling technique methodology. Because of the more-complex notations and less-familiar terminology, direct business modeling in Unified Modeling Language (UML) activity diagrams has not been as productive when business end users are involved. Gartner Reproduction of this publication in any form without prior written permission is forbidden. The information contained herein has been obtained from sources believed to be reliable. Gartner disclaims all warranties as to the accuracy, completeness or adequacy of such information. Gartner shall have no liability for errors, omissions or inadequacies in the information contained herein or for interpretations thereof. The reader assumes sole responsibility for the selection of these materials to achieve its intended results. The opinions expressed herein are subject to change without notice.
Criteria: Look for modeling in common business terms that can be mapped to one or more UML diagrams. Shared repositories or metadata bridges can be used to implement this integration. Enablement of Physical Database Design Designers using object-oriented modeling tend to deal primarily with logical design and still make heavy use of database design tools. The mapping from logical to physical database design can occupy 40 percent or more of project design efforts. Most tools have bridges to import established database schema and generate an "ideal" physical design based on the object-oriented model. Assisted mapping from logical to physical design (object to relational mapping) is a significant step toward broadening the deployment of these tools, especially for those early on the learning curve. The real requirement for mapping tools is that they go beyond the ability to create an "ideal" design for the new persistent data to include an ability to iterate with or map transformations into established databases. Criteria: Closely review functionality provided to map persistent data through an iterative design process involving database schema and objects. Good database design functionality and database object generation capabilities are assets. Synchronization With an Integrated Development Environment Real-time synchronization of a model with the code within an integrated development environment (IDE) is replacing batchoriented round-trip engineering (batch transforming model to code and then back to model to maintain synchronization) as the preferred mode of operation. Both techniques are bidirectional, but real-time synchronization creates a quick round trip via tight integration with the IDE. This is often the best way to work when the project is focused on rapid application development (AD) and programmer and analyst roles are intertwined. Batch-oriented round-trip techniques become appropriate when project scope has increased to a point at which business analysts, modelers and architects are in charge of the model within a formal methodology. Less-frequent and very selective mode updates then become critical. In fact, updates are usually made only once or twice during an iteration (one reason to keep iterations short). Evaluations need to keep both approaches in mind when assigning metrics. In a practical sense, weak integration with an IDE will lead to less use of round-trip engineering and bias the tool toward use by the analysts and designers. Less-robust round-trip engineering or 11 September 2003 2
lack of pattern support implies that coding standards will need to be introduced to minimize code rework on each cycle. Robust, interactive synchronization improves the utility of models for rapid application development projects and for a variety of "agile" design approaches. The interactive approach can lead to a secondary role for the models, leaving them as documentation of the result of "code first" approaches, unless a design discipline is incorporated into the development process. Strong integration is often achieved by including some level of IDE function and modeler function in the same tool, and modeler function in an IDE is growing more rapidly than the use of stand-alone modelers. Criteria: To maintain long-term utility for the models, a primary evaluation metric will be the ability to keep the model in synch with the written code. Synchronization With Other Tools The exchange of design information with requirements, project management, testing and other tools outside the IDE must be evaluated. For example, requirements, models and test scripts can be linked and many changes automated in all views at once. If the OOA&D tool is part of a suite of development products, the ability to reflect changes made elsewhere and to enable changes made in the tool to propagate into the suite should be examined. Evaluations should weigh the commonality of metadata and functional integration highly and the common look and feel moderately. Criteria: If the goal is to develop models for long-term use, a primary evaluation metric will be the ability to keep the model in synch with the written code. Analysis and Design Assists and Tailoring Patterns, frameworks and pre-built libraries of analytical models and designs have become common in OOA&D tools. Nearly 60 percent of the design phase will be devoted to elaborating these to a working design. In addition, tools should now support tailoring of generated headers and class structures. As development styles shift to service-oriented architecture (SOA), a consistent use of patterns and the like will be important to success, improving the commonality of approach and shaping the nature of components for quicker payback. Criteria: Look for the ability to tailor the generation of scaffolding and repetitive code structures. Other desirable features include the incorporation of pattern libraries, templates, design fragments 11 September 2003 3
or other techniques that will enable effective leveraging and reuse of design artifacts. Consider the likelihood of nextgeneration models and designs being delivered by third parties in the tool that is selected. Support for Orchestration, Assembly and Component-Based Development In addition to methodology support (listed separately), products need to represent and facilitate the collections of objects into larger structures. This capability is evolving in the way it is treated in UML, as well as in the facilities and guides available. The object is to provide consistency in service and component description, facilitating communication among designers and improved understanding and reuse of higher-level structures, such as components or services. Criteria: Evaluations should focus on facilities for defining and managing services and components, as well as for the suitability of those techniques to enterprises' overall development plans and processes. Emerging functionality is expected to guide programmers in allocating functionality across structures, to grade the "merit" of a structuring alternative or to otherwise guide the characterization or sharing of components. Methodology Support The UML remains the diagramming notation standard for OOA&D tools. Users should separately assess a project methodology and the tools' ability to support or to be tailored to a variety of detail design methodologies, such as The Unified Process, Catalysis, Dynamic Systems Development Methodology, XP and Agile. Tools can assist in the implementation of methodology in many ways. Some tools incorporate online documentation, contextual help or even integration with workflow to assist in adhering to the method. Another issue for larger projects is whether supports exist or could be created in more-comprehensive processmanagement tools. Criteria: Look for plug-in mechanisms and other implementations of the ability to adjust or tailor to a variety of methods and to local method simplifications or elaborations. Life Cycle Support The ability to track changes and coordinate the efforts of many contributors of models across phases of the development life cycle will be important for large-scale projects. Ultimately, this 11 September 2003 4
requires a repository function for impact analysis and fine-grain versioning. Tools currently provide a variety of locking mechanisms, ranging from simple interfaces with external products through internal file locking (check-in/check-out). The most-advanced tools juggle object-level locking with finegrain versioning and fall short of full repository function. Advanced team support will include parsers for importing established designs and programs, repository services (such as versioning, model subsetting and security), robust reporting and integration with workflow tools. In some cases, integration with a software change management facility provides file-oriented services in lieu of an integrated object repository. Coordination of changes with third-party component libraries is another life cycle support issue. Criteria: Enterprises seeking to keep models and code in synch will need to ensure that both forms are included in change management processes and versioned is such a way as to preserve the traceability of design to code. Use of other metadata repositories will require that they be integrated into the life cycle support. Administration and Team Support The techniques of OOA&D were developed in the context of small, iterative projects. Enterprises seeking to implement broad project development methodologies will need to add project management, resource planning and estimation, using the UMLbased tools to manage iterations within this broader project context. Furthermore, larger teams will require administration features, such as security (by role, value and other attributes), model subsetting and management across multiple sites and projects, and sophisticated activity and status reporting facilities. Criteria: Match the administrative features of the tools to the needs of your project scale. Look for extensions or interfaces to related facilities or built-in functions to support project geographic and internal scope. Acronym Key AD application development IDE integrated development environment OOA&D object-oriented analysis and design SODA service-oriented development of applications SOA service-oriented architecture UML Unified Modeling Language Bottom Line: To select a "balanced" object-oriented analysis and design tool, evaluators should follow a proven set of tool selection best practices, such as Gartner's Refined Hierarchical Analysis methodology. Functionality is only one aspect of the decision. The criteria, all of which are supplemental to the basic Unified Modeling Language diagrammer implementation, will determine success in terms of the functionality of OOA&D tools. To achieve sustained success, match internal team support and integration needs and supplement the offerings with manual processes and project management. 11 September 2003 5