UML; Integration of Object-oriented Analysis & Design Methodologies. June, 1998
- written by Jim Dempsey, Kevin D. Shim, Garry Woo & Elisa Talamantes
TABLE OF CONTENTS
INTRODUCTION *
Rumbaugh *
The Booch Method *
JACOBSON’S USE CASES *
What is a use-case? *
Graphical notation of use case model to describe scenarios *
Two structuring mechanisms *
Summary *
Integrating these approaches provides a complete picture *
OO CASE TOOLS *
CONCLUSION *
UML present and future *
APPENDIX A *
The market for object modeling tools is currently a niche market, even though it is one that grew 40% over the past year to $127.4 million. In addition, for the most part, object-oriented (OO) projects are still seen primarily in the technical, real-time community such as aerospace and telecommunications, or in high-profile, leading-edge businesses willing to invest in high-end client/server development tools. All this is about to change. The Internet is bringing objects to the forefront, and with it, a change in the perception that most developers have about the technology. Rational Software Corp. has recruited 3 object theorists ?Grady Booch, Jim Rumbaugh, and Ivar Jacobson ?who have literally written the book on object modeling. These "3 amigos" have prepared a proposal to the Object Management Group (OMG) to certify their combined work, called the Unified Modeling Language. The proposal is in response to an OMG request for technology that calls for a standard language and meta model that will allow different modeling tools to interoperate.
The UML is nonproprietary and open to all. It addresses the needs of user and scientific communities, as established by experience with the underlying methods on which it is based. Many methodologists, organizations, and tool vendors have committed to use it. Since the UML builds upon similar semantics and notation from Booch, OMT, OOSE, and other leading methods and has incorporated input from the UML partners and feedback from the general public, widespread adoption of the UML should be straightforward.
There are two aspects of "unified" that the UML achieves: First, it effectively ends many of the differences, often inconsequential, between the modeling languages of previous methods. Secondly, and perhaps more importantly, it unifies the perspectives among many different kinds of systems (business versus software), development phases (requirements analysis, design, and implementation), and internal concepts.
In the face of increasingly complex systems, visualization and modeling become essential. In the meantime, as the strategic value of software increases for many companies, the industry looked for techniques to automate the production of software and looked for techniques to improve quality and reduce cost and time-to-market. These techniques include component technology, visual programming, patterns, and frameworks. The industry also sought techniques to manage the complexity of systems as they increase in scope and scale. In particular, they recognized the need to solve recurring architectural problems, such as physical distribution, concurrency, replication, security, load balancing, and fault tolerance. Complexity will vary by application domain and process phase. One of the key motivations in the minds of the UML developers was to create a set of semantics and notation that adequately addresses all scales of architectural complexity, across all domains.
Meanwhile, as the number of O-O methods texts proliferated, analysts were able to sort the various methodologies into groups, with each group addressing a piece of the overall puzzle. Analysts adopted the terms data-centered (Rumbaugh, Martin/Odell, Shlaer/Mellor), scenario-based (Jacobson, OBA), and structural (Booch) as categories for the different kinds of methods. Analysts recognized balance between user driven and object driven methods. Each method has its strengths. Rumbaugh has a strong method for producing domain object models, Jacobson has a strong method for producing user driven, solution space models, and Booch has a strong method for producing detailed OOD models.
Each method also has weaknesses. While Rumbaugh has a strong method for modeling the problem domain, OMT models can be simplistic for the solution space. Jacobson de-emphasizes domain modeling, and while he covers a fairly wide range of the lifecycle, he does not treat detailed OOD to the same level as Booch, who focuses almost entirely on design, not on analysis.
Notations will change but the key concepts will remain the same. Here are some issues that must be understood during analysis and design, and the techniques we'll use to document this understanding:
?What are the users of the system doing? (Jacobson Use Cases, prototypes)
?What are the objects in the real world and the associations between them? (Rumbaugh Class Diagrams, prototypes)
?What objects are needed for each use case? (Jacobson Robustness Analysis)
?How do the objects within a use case collaborate with each other? (Jacobson Interaction Diagrams, Booch Object Diagrams)
?How will we implement real-time control? (Pick your favorite state diagramming notation)
?How are we really going to build this system? (Booch Class Models, Module Architecture Diagrams)
James Rumbaugh created a popular Object Modeling Technique, which is an analysis and design method. He is one of the leading object-oriented methodologists, and is author of the best selling book: Object-Oriented Modeling and Design. James Rumbaugh has a B.S. in physics from MIT, a M.S. in astronomy from Caltech, and a Ph.D. in computer science from MIT. Being the chief developer of OMT, it is a powerful way to design object-oriented systems, and gives the developer a diverse way in doing so. It describes object-oriented as a way to organize software as a collection of discrete objects that incorporates both behavior and data structure. OMT contains three models. The first, called the Object Model, gives the developer an easy way to distinguish what are all the objects in a system by describing the static structure of objects in a system and their relationships. The second model, called the Dynamic Model, describes how to specify all the behaviors and control aspects of the system. State diagrams show the dynamic part of an object, and then Event Flow Diagrams are drawn to show the states, transitions, and events. Finally, the Functional Model explores what the process descriptions are such as the producer/consumer relationship. It describes the computations within a system. This section will give a overview of some important concepts, and then elaborate on the three models.
Some of the major concepts to understand the OO design process are:
OMT divides Analysis and Design into three parts:
The three views are now presented in more detail:
Objects and class methods need to be specified as well as associations need to be supported. This is done in the object model. The relationships or associations between an object and a class can be described in two ways: qualification (relates two objects to a qualifier) and aggregation (whole/part relationship). The inheritance of a class and it’s superclass can be thought of in an analogy of a payroll example. An employee (superclass) has a name and a salary associated with it. The salary_employees (subclass) and the hourly_employees (another subclass) inherit the name and the salary attributes. Also the hourly_employee can use other attributes from another superclass such as managers. This is called multiple inheritance. A metaclass is when a class is treated like an object, and is helpful when many attributes are common to an entire class of objects. OMT also allows the addition of constraints, which are important in real-world concepts for security and other political issues. The object model consists of EER models which are objects diagram, like the one below:
State Diagrams are part of the Dynamic Model, and every class with relevant behaviors needs a diagram associated with it. Of course, the state diagrams contain states, events, and transactions, which is a change in the state caused by an event. Concepts of the state diagrams include:
Inheritance can also take part in the state diagrams. For example, states can break down into sub-states and the transitions are inherited. The same concept can be applied to events. An example or a dynamic model would look like this:
The Functional Model deals with computations in a system, and describes how the output values are derived from the inputs placed into the system. Data Flow Diagrams (DFD’s) aid in the Functional Model with the following concepts:
Control flows can be added to describe some decision functions but must be taken from the Dynamic Model. An example of a functional model on a GUI would look like this:
?#060;/p>
To sum up the relationships between the modeling techniques:
"The object model shows the structure of actors, data stores and flows in the functional model, the dynamic model shows the sequence in which processes are performed and the functional model shows supplier-client relationships among classes" http://wwwis.cs.utwente.n1-8080/dmrg/OODDC. An overall diagram to show all the characteristics of the OMT model is:
According to Rumbaugh, Object Oriented approach forces the developer to think more carefully about what an Object is and does. The costs savings will not be seen in reduced development time, but in the future reuse of the classes and designs which will reduce errors and maintenance.
It’s framework and mechanic Based on the book Object-Oriented Modeling and Design With Applications by Grady Booch 1991.
The Booch method is a widely used OO-method that covers the analysis- and design phases of an OO-system. Though it has big set of different symbols and diagrams which you never use all, only when you are ready to generate code, you add some design symbols. This is where Booch is strong: you can really document your OO-code.
Booch’s work changed the original thinking and application of object technology. The method was instrument in developing two major concepts: an iterative model of s/w development and the
importance of software architecture. Using this method, Booch developed Ada-language reusable components and the Booch C++ source-code component, which helped to popularize s/w reuse and make it economically feasible. Booch methods and ideas are being used to develop some of the most complex and demanding s/w systems, ranging from air-ttrafic-control system to commercial aircraft avionics to financial trading systems to telecommunication switching networks to defense systems.
What’s inside this method is the development of the following diagrams:
The Models of OO-Analysis & Design
Support multiple, interrelated views of a system under development.
The Booch-method defines different models to describe your system. The logical model (problem domain) is represented in the class- and object structure. In the class- diagram you construct the architecture, the static model. The object-diagram shows how the classes interact with each other, it captures some moments in the life of the system and helps you so to describe the dynamic behavior.
The module and process architecture describes the physical allocation of the classes to modules and processes.
(Table omitted)
Dynamic Model
Static Model
Logical Model
Physical Model
The process of OO Development
Booch support the iterative and incremental development of a system.
Macro Process
Micro process
Analysis: aim to specify and define the system to be built. This model should tell us what the system would do.
The Booch method has a rich notation to show every aspect of a design, but gives only fuzzy rules on finding your classes. Experiences with real-life project showed, that you couldn’t start by drawing clouds (or rectangles?. Booch people often use the Use-case driven approach for the first steps in a project. In the unification of Booch and OMT this approach will be part of the method.
Specify the requirements, use-case model
We describe the functionality of our system in use-cases. Use-cases are an outline view of our system that tells us what this system will do. In the basic use-case model actors (user of system) and use-cases (system functions) are the only occurrences.
Many peoples use the resulting use-case model:
Design: based on the found classes and the functionality of the application expressed in object interaction diagrams, we develop the application architecture.
In the design we introduce support-class that helps us implement the required functionality. To be able to design the system, we have to understand our tools (CASE-tool, compiler/programming environment and class library). OO programs cannot be seriously developed without a class library. You will always find the same, basic class in every system. Class libraries are great, because they help you to reduce the time you need to develop the application, but the learning effort for complex frameworks is immense.
Use Case captures system requirements
There are two fundamental questions in software engineering. How do you know you are building the software right? The existing object-oriented design methods address this question. Then how do you know you are building the right software? The notion of "Use Case" was introduced by Ivar Jacobson to address this question.
The idea behind use-cases is not startling. Many people have used the general approach for a long time. However Jacobson pushed this idea to the center of the stage and created a set of well-defined use cases. The "use" in use cases was clearly intended to be from the view of a "user of the system" by Jacobson. Use case technique represents a system in terms of what happen when it is executed (William, 1997). "Use case" doesn’t analyze systems by looking at the way databases or applications interact, but as business processes performed by real people. It looks at the systems from the outside, not the internal details of how you design it. Use case snapshots of one aspect of system make communication with users easier in developing good software. The sum of all use cases is the external picture of the system, explaining what the system will do.
Our models of the software should not only define what the system should do but also be user understandable. So the customer or user can criticize our understanding of the system and involved well in the system development. The best candidate for such a model is the use case, which allows the software engineers and the customers to understand well what the system should do.
Think of an example at an appropriate level of abstraction: an ordering system. A user sits down to do a single unit of work such as add an order, update an order or delete an order. Each such unit is a use case. To be precisely, each of them is use case instance. Another example is the ATM cashier system: deposit money, withdraw money and transfer between accounts by bank customer are the use cases. Use cases represent the behavior of the system.
The use case model consists of "actor" and "use case". An actor is everything that needs to interact with the system under construction. Actors represent the users of the system and hence are outside the system. Actors help software engineers to delimit the system and get a clear picture of what it is supposed to do. The behavior of the system is represented by use cases, and use cases are developed according to the actor’s needs. This ensures that the system will turn out to be what the users expected.
The term "use case" means a use case type. The execution of a use case is an instance of the use case. The instance of use case can be described by scenario descriptions (such as add order or delete order). In order to make a use case understandable, it is important to carefully select the use case types that can offer those instances. So when we say that we identify and describe a use case, we really mean that we identify and describe the use case type.
An actor can be a human user, external hardware, or another system. The difference between an actor and a user of the system is that an actor represents a particular type of user (with a specific role to play to the system) rather than a real physical user. A single physical user can also have several roles, and hence act as different actors. Several different physical users can play the same role in relation to the system, then they are instances of the same actor. Therefore the actor is the class concept which can has instances. For example, bank customer can have instances of private customer and corporate customer.
Actors communicate with the system by sending and receiving messages. To fully understand the role of an actor, we must know which use cases the actor is involved in. An actor instance communicates with a use case instance offered by the system.
Graphical notation of use case model to describe scenarios
Actors are drawn as stick figures, and use cases are drawn as ellipses.
Table omitted.
There are two important structuring mechanisms in use case: use generalization (Douglass, 1997) and extension (http://www2.awl.com).
(1) We may find behavior that is common to several use cases. For example, the use cases "Withdraw Money", "Deposit Money", and "Transfer Between Accounts" in the ATM cashier system involve the movement of money between monetary holders. To avoid describing the same flow of events several times, we can define a common behavior in an abstract use case "Monetary Transfer". This allows behavior used by several concrete use cases to be pulled out into a separate use case which is reused (or inherited) by the original use cases.
Concrete use case uses
Table omitted.
?#060;/p>
Abstract use case
An abstract use case will never be instantiated by itself. A concrete use case is initiated by an actor. When a concrete use case is initiated, an instance of the abstract use case is created.
(2) We can extend one use case to another. An extension behavior is something added into the original description of a use case type. Extension is often used to show exception behavior or special cases, which would otherwise bloat the amount of use cases in the model. For example: a bank customer withdrawing money may cause an account overdraft. This is handled by a use case Overdraft Management that extends the use case Withdraw Money.
Use cases provide an external view of the system. The art is to identify the user’s goals, not the system functions. Use case diagrams provide a way of describing the external view of the systems. In this way it resembles the context diagram of traditional approaches. In this representation the outside world is represented as actors. Actors are roles played by various people, or other computer systems. The emphasis on roles is important: one person may play many roles, and a role may have many people playing it. Use cases are then typical interactions that the actor has with the system.
A good collection of use cases is central to understanding what your users want. It gives feedback to the users about where the software is going. Use case could be used throughout the development part of the software life-cycle, e.g., during analysis, design, and testing, because it is a valuable technique for capturing and communicating high-level requirements.
?#060;/p>
Integrating these approaches provides a complete picture
Of the three methodologists, Booch and Rumbaugh can both be described as more object-centered, in that their approaches are focused on figuring out what the objects of a system are, how they are related, and how they collaborate with each other, while Jacobson is more user-centered in that everything in his approach is derived from usage scenarios. We need more of a balance between the user driven and object driven approaches. By following Jacobson's lifecycle model, we can produce designs that are traceable across requirements, analysis, design, code, and test.
There is a simple, clear,step-by-step approach to the design from the requirement model. All of the design directly traces back to the user requirements.
Usage scenarios become test scenarios. Notations will change but the key concepts will remain the same. It is essential, however, to include prototyping in the lifecycle because none of the three really feature prototyping in their approaches. Both the Rumbaugh and Jacobson?s high-level models provide
good avenues for getting started: Rumbaugh domain models into Booch class models, and Jacobson robustness analysis and integration diagrams into Booch object diagrams.
?#060;/p>
CASE is an acronym for Computer Aided Software Engineering, although in some literature it is also called Computer Assisted (or Automated) Systems Engineering. A formal definition of CASE was written by B. Terry & D. Logee in the Software Engineering Notes of April 1990 as " Individual Tools to aid the software developer or project manager during one or more phases of software development." See "Terminology for Software Engineering and Computer-aided Software Engineering" by B. Terry & D. Logee. In layman’s terms, CASE is a tool which aids a software engineer to maintain and develop software.
The basic idea behind OO CASE tools is to support each phase of the object oriented software development cycle with a set of labor saving tools and structured development methodologies. In many cases CASE tools are used along with third and fourth generation languages. In some cases they replace the languages by allowing the software developer to create high-level program specifications from which program code can be generated directly. AT the very least a CASE tool should take the developer through the four stages of software development:
The two general approaches to object oriented development are what could be called the "translation" method, represented by the Shlaer-Mellor methodology, and the "iterative" or "elaborative" method, represented by Grady Booch and James Rumbaugh. Rumbaugh's method is known as object modeling technique (OMT). (Computer Design, October 1995) Currently there is an effort to merge the Bootch and OMT methodologies into a single unified methodology. Once that happens an organizations major choice will be made based on its development process.
Some of the potential benefits of CASE are:
The commercial availability of CASE tools is on the increase. Most of the CASE tools on the market today carry out single functions, some provide limited integration through one-way data communications or file transfers. Few tools can be classified as integrated tools which would involve using the same data in different ways to perform various analytical functions.
The evaluation and selection of a CASE tool is not a simple task. The needs of the organization and the problems the tool is intended to address must be transformed in to a selection criterion on which the selection of a CASE tool must be based.
?#060;/p>
Why UML model: Motivation to define the UML
Developing a model for an industrial-strength software system prior to its construction or renovation is as essential as having a blueprint for large building. Good models are essential for communication among project teams and to assure architectural soundness. As the complexity of systems increase, so does the importance of good modeling techniques. There are many additional factors of a project’s success, but having a rigorous modeling language standard is one essential factor. A modeling language must include:
?Model elements ?fundamental modeling concepts and semantics
?Notation ?visual rendering of model elements
?Guidelines ?idioms of usage within the trade
The UML is a well-defined and widely accepted response to that need. It is the visual modeling language of choice for building object-oriented and component-based systems. Prior to the UML, there was no clearly leading modeling language. Users had to choose from among many similar modeling languages with minor difference in overall expressive power. Most of the modeling languages shared a set of commonly accepted concepts that are expressed slightly differently in different languages. This lack of agreement discouraged new users from entering the OO market and from doing OO modeling, without greatly expanding the power of modeling. Users longed for the industry to adopt one, or a very few, broadly supported modeling languages suitable for general-purpose usage. They wanted a (lingua franca) for modeling.
It is important to the entire OO industry to encourage broadly based tools and vendors, as well as niche products that cater to the needs of specialized groups. The perpetual cost of using and supporting many modeling languages motivated many companies producing or using OO technology to endorse and support the development of the UML. While the UML does not guarantee project success, it does improve many things. For example, it significantly lowers the perpetual cost of training and retooling when changing between projects or organizations. It provides the opportunity for new integration between tools, processes, and domains. But most importantly, it enables developers to focus on delivering business value and provides them a paradigm to accomplish this.
Many organizations have already endorsed the UML as their organization’s standard, since it is based on the modeling languages of leading OO methods. The UML is ready for widespread use. These documents are suitable as the primary source for authors writing books and training materials, as well as developers implementing visual modeling tools. Additional collateral, such as articles, training courses, examples, and books, will soon make the UML very approachable for a wide audience.
The real measure of the UML’s success is its use on successful projects and the increasing demand for supporting tools, books, training, and mentoring. Although the UML defines a precise language, it is not a barrier to future improvements in modeling concepts. People have addressed many leading-edge techniques, but expect additional techniques to influence future versions of the UML. Many advanced techniques can be defined using UML as a base. The UML can be extended without redefining the UML core.
The UML, in its current form, is expected to be the basis for many tools, including those for visual modeling, simulation, and development environments. Component-based development is an approach worth mentioning. It is synergistic with traditional object-oriented techniques. While reuse based on components is becoming increasingly widespread, this does not mean that component-based techniques will replace object-oriented techniques. There are only subtle differences between the semantics of components and classes. As interesting tool integration is developed, implementation standards based on the UML will become increasingly available. The UML has integrated many disparate ideas, so this integration will accelerate the use of OO.
?#060;/p>
?#060;/p>
REFERENCE
Baer, T. (1997). Object standards: Is peace breaking out? [ABI/Inform]. Software Magazine, 17(5), 32-33. UTA library ABI/Inform: Accession Number: 01416549.
Bowen, T. S. (1997). Database Designer for Oracle8 enters testing. [ABI/Inform]. Inforworld, 19(45), 19. UTA library ABI/Inform: Accession Number: 01532625.
Corporate and Professional Publishing Group (1998). Use Case. http://www2.awl.com/cseng/titles/0-201-89542-0/useCase.html.
Csn Inc. (1996). Rumbaugh/OMT. http://www.csn.net/infopage/rumba.html.
Douglass, B. P.(1997). Designing real-time system with the Unified Modeling Language. Electronic Design. V.45.
ICONIX Software Engineering, Inc. (1997). Object Modeler Product Description.
http://www.iconixsw.com/Spec_Sheets/ObjectModeler.html.
Patrizio, A. (1997). Object tool for NT. [ABI/Inform]. Informationweek. (636), 130. UTA library ABI/Inform: Accession Number: 01468551.
Ratioanl software corporation (1998). UML Summary.
http://www.rational.com/uml/html/summary/summary3.html.
Sigs corp. (1998). Booch Method. http://www.sigs.com/publications/docs/road/9603/road9603.c.booch.html
Taft, D. K. (1997). Rational, supporters push object standard. Computer Reseller News, (725), 107-108. UTA library ABI/Inform: Accession Number: 01394678.
William, Tom: Standard graphical notation proposed for object-oriented development. Electronic Design. V.45, Jan. 20 1997.
?#060;/p>
?#060;/p>
?#060;/p>
Copy rights, November 13, 1998. Kevin D. Shim