- Shopping Bag ( 0 items )
UML 2 represents a significant update to the UML specification, from providing more robust mechanisms for modeling workflow and actions to making the modeling language more executable. Now in its second edition, this bestselling book provides you with all the tools you'll need for effective modeling with UML 2. The authors get you up to speed by presenting an overview of UML and its main features. You'll then learn how to apply UML to produce effective diagrams as you progress through more advanced topics such as use-case diagrams, classes and their relationships, dynamic diagrams, system architecture, and extending UML. The authors take you through the process of modeling with UML so that you can successfully deliver a software product or information management system.
With the help of numerous examples and an extensive case study, this book teaches you how to:
* Organize, describe, assess, test, and realize use cases
* Gain substantial information about a system by using classes
* Utilize activity diagrams, state machines, and interaction diagrams to handle common issues
* Extend UML features for specific environment or domains
* Use UML as part of a Model Driven Architecture initiative
* Apply an effective process for using UML
The CD-ROM contains all of the UML models and Java?TM code for a complete application, Java?TM 2 Platform, Standard Edition, Version 1.4.1, and links to the Web sites for vendors of UML 2 tools.
What is the UML? In short, the Unified Modeling Language (UML) provides industry standard mechanisms for visualizing, specifying, constructing, and documenting software systems. However, such a static definition does not convey the tremendous growth of UML and the exciting opportunities of recent advances in the language. UML organizes thought with a dynamic set of features that support continuous evolution. This evolution has seen UML through a number of minor new releases (versions 1.0, 1.1, 1.2, 1.3, and 1.4, referenced as UML 1.x) into a major release (2) designed to extend UML's growth into new areas. The latest UML specification now spans hundreds of pages, with links to other specifications bringing the total into the thousands. The long answer to the question "What is the UML?" is found in the specifications that define the current edition of UML. However, those specifications, freely available for download, do not provide a practical overview of the key features of UML. This book seeks to address this need. This chapter provides some general background on software modeling, the historical roots of UML, and the basic goals of UML 2.
UML provides a language for describing system interactions, supported by a cohesive set of definitions managed by an official group, the Object Management Group (OMG). In this, UML at firstresembles a software product more than a language; software versions improve "bugs" in the specification and add new "features" just like UML. However, like a language, UML has evolved dialects beyond the reach of official standards for such needs as data modeling, business modeling, and real-time development. The designers of UML intentionally gave UML the power for such evolution; UML has extension mechanisms that allow for creative new approaches. The implementation of UML, and especially UML 2, allows flexible language evolution that can keep up with the pace of change in software development. UML seeks to define concepts, to establish notation for communicating those concepts, and to enforce the related grammatical rules for constructing software models, allowing for automated tool support. The goal is to have the flexibility to apply to all software development while providing coherent enough definitions for automation. UML 1.x made a giant step toward this goal, and UML 2 furthers this effort. Put another way, UML provides a set of tools for all those involved in using information technology. This set of tools involves a rich set of graphical elements, including notation for classes, components, nodes, activities, ports, workflow, use cases, objects, states, and the relationships between all these elements.
Just as a dictionary does not explain how to write a book, UML itself offers no process for developing software. Just as a toolbox does not tell you how to use a hammer, UML does not recommend how to use the notation it provides in a model. Using UML to enhance project success requires skill, talent, and creativity. This book explains how to use the UML toolkit to improve software systems. So, this book not only discusses the specific elements of the UML specification, but also shows how to use these to model within a process to develop good software.
The Purpose of Modeling
A model represents highly creative work. There is no final solution and no correct answer that is checked at the end of the work. The model's designers, through iterative work, ensure that their models achieve the goals and the requirements of the project under construction. But a model is not final; it is typically changed and updated throughout a project to reflect new insights and the experiences of the designers. During the modeling, the best solutions are often achieved by allowing a high degree of brainstorming, during which different solutions and views are modeled and tested. By discussing different possibilities, the designers reach a deeper understanding of the system, and can finally create models of the systems that achieve the goals and requirements of the system and its users.
Communicating a model in a clear way to the many people involved in a software project represents a core feature of UML. The term modeling can lead to confusion, because it also applies to a number of different levels. Modeling shows not only the detailed specifications of software elements, but also high level analysis, providing mechanisms to link the different layers of abstraction. A model can reduce complexity by decomposing a system into easy-to-understand elements. In software engineering, modeling starts with a description of a problem, an analysis, and then moves to the proposition of a solution to solve the problem, a design, along with an implementation and a deployment.
Models have driven engineering disciplines for centuries. One assumes the ancient Egyptians worked up a model before starting on a pyramid. Any building project includes plans and drawings that describe the building. This model also provides essential instructions to the workers implementing the design. For a model, the object under development may be a house, a machine, a new department within a company, a software program, or a series of programs. Diagrams specify how you want the finished product to look and to act. Plans for implementation, including estimation of cost and resource allocation, are made based on the information contained in the model. A poor model makes accurate estimation and planning impossible.
During the work of preparing a model, the model's designers must investigate the needs, preferences, structure, and design for the finished product. These needs and preferences, called requirements, include areas such as functionality, appearance, performance, and reliability. The designers create a model to communicate the different aspects of the product. Good designers will take advantage of the tools offered by UML to improve their design and get feedback from their clients. In order to allow this feedback loop between those who need the software, those who design the software, those who build the software, and those who deploy the software, a model is often broken down into a number of views, each of which describes a specific aspect of the product under construction.
A model not only represents a system or organization, promotes understanding, and enables simulation, but it is also a basic unit of development. It specifies a part of the function, structure, and the behavior of a system. A model is not directly observable by its designer or its user, but can be expressed in terms of diagrammatic notation, text, or a combination of both.
Many models for software engineering are displayed using a graphical language expressed by shapes, symbols, icons, and arrows, and supported by labels. In fact, models are usually described in a visual language, which means that most of the information in the models is expressed by graphical symbols and connections. The old saying that "a picture speaks a thousand words" is also relevant in modeling. Using visual descriptions helps communicate complex relationships; it also makes the practical modeling work easier.
NOTE Note everything is suitable for a visual description, some information in models is best expressed in ordinary text.
In short, usable models are:
* Accurate. They must precisely and correctly describe the system they are representing.
* Understandable. They must be as simple as possible, but too simple to accurately fulfill their purpose, and must be easy to communicate.
* Consistent. Different views must not express things that are in conflict with each other.
* Modifiable. They must be easy to change and update.
Software Development, Methods, and Models
Many software projects fail. They can fail in many ways.
* Excessive cost
* Late delivery
* Absolute failure to meet the requirements and needs of customers
Some projects fail in terms of budget, schedule, and functionality, the three major factors to track in managing a software project. Such total failures appear far too often in software development. Effective modeling and sound management practices can help avoid such failures.
Technical advances, such as object-oriented programming, visual programming, and advanced development environments, have helped to increase productivity of coding, but have not solved these problems. Such technical advances have improved efficiency at the lowest level of system development, the programming level, not at the level of the analysis, design, or implementation.
One of the main problems with today's software development is that many projects start programming too soon and concentrate too much effort on writing code. Many managers lack an understanding of the software development process and become anxious when their programming team is not producing code. Programmers also tend to feel more secure when they're programming rather than when they are building abstract models of the system they are to create. In many cases, fundamental industry practices created many of these problems by measuring the performance of a programmer by lines of code rather than by solutions.
The use of modeling in software development is the difference between mature software engineering and hacking up code for a temporary solution. Systems are becoming much larger, integrating many different hardware and software components and machines, and distributed over complex architectures and platforms. The need to integrate extremely complex systems in distributed environments requires that systems be designed carefully, not coded haphazardly.
Before UML, many approaches, called methods, were developed that attempted to inject engineering principles into the craft of software engineering. The most worthwhile engineering techniques are those that can be described both quantitatively and qualitatively, and used consistently and predictably. The method must achieve better results than using no method, must be able to be applied to many different problems, and must be able to be taught to others relatively easily.
The multitude of different methods, each with its own unique notation and tools, left many developers confused and unable to collaborate. The lack of a well-established notation upon which creators of many methods and tools could agree made it more difficult to learn how to use a good method. Furthermore, most of the early object-oriented methods were immature and best suited for small systems with limited functionality. They did not have the capability to scale up to the large systems that are now common. Indirectly, modeling can encourage a designer or software architect to adopt a more disciplined development process. Directly, models serve as a repository of knowledge.
The trends of the software industry still point to the need for creating models of the systems we intend to build. Visual programming is a technique by which programs are constructed by visually manipulating and connecting symbols; so it is that modeling and programming are highly integrated. Systems are becoming larger and are distributed over many computers through client/server architectures (with the Internet as the ultimate client/server architecture). The need to integrate complex systems in distributed environments requires that systems have some common models. Business engineering, where the business processes of a company are modeled and improved, requires computer systems that support these processes to implement the business models. Building models of systems before implementing them is becoming as normal and accepted in the software engineering community as it is in other engineering disciplines.
UML has helped improve modeling, making software engineering more mature as a discipline. Now, those who want to work as a software architect must know UML. The Java architecture exam, for example, assumes a knowledge of UML. Such progress, in a little over 60 months since initial adoption, represents a remarkable achievement. It is worth knowing how UML evolved, to understand the core elements of the language. Basically, three prominent methodologists in the information systems and technology industry-Grady Booch, James Rumbaugh, and Ivar Jacobson-cooperated in developing UML. UMLcombined the most effective diagramming practices applied by software developers over the past four decades. This combination put an end to competing styles that had clashed in the so-called "method wars."
The Method Wars
Antecedents of object-oriented (OO) modeling languages first appeared in the mid-1970s, and continued during the 1980s as programmers and project managers tried different approaches to analysis and design. Object orientation was initially spawned by the programming language Simula, but it didn't become popular until the late 1980s with the advent of programming languages such as C++ and Smalltalk. When object-oriented programming became a success, the need for methods to support software development followed. More than 50 methods and modeling languages appeared by 1994, and a growing problem became finding a single language to fulfill the needs of many different people and projects.
In the mid-1990s, the modeling languages started to incorporate the best features of previous languages, and few languages gained prominence over the field. These included OOSE (Object-Oriented Software Engineering), OMT-2 (Object Modeling Technique), and Booch'93. OOSE established the use of use cases, making it suited to business engineering and analysis. OMT-2 was strongly oriented toward analysis, and proved to be better at modeling data-intensive information systems. Booch'93 focused on the design and construction phases of projects, and proved especially applicable to engineering applications. Some prominent methods from this era and their contributions are listed as follows:
* Coad/Yourdon. This method, also known as OOA/OOD, was one of the first methods used for object-oriented analysis and design. It was simple and easy to learn, and worked well for introducing novices to the concepts and terminology of object-oriented technology. However, the notation and method could not scale to handle anything but very limited systems. It was not heavily used.
* Booch. Booch defined the notion that a system is analyzed as a number of views, where each view is described by a number of model diagrams. The method also contained a process by which the system was analyzed from both a macro- and microdevelopment view, and was based on a highly incremental and iterative process.
Excerpted from UML 2 Toolkit by Hans-Erik Eriksson Magnus Penker Brian Lyons David Fado Excerpted by permission.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
About the OMG.
2003 OMG Press Advisory Board.
Preface for the Second Edition.
About the Authors.
Chapter 1: What Is UML?
Chapter 2: An Overview of UML.
Chapter 3: Use-Case Modeling.
Chapter 4: Classes, Objects, and Their Relationships.
Chapter 5: Dynamic Modeling.
Chapter 6: Advanced Dynamic Modeling Illustrated by Real-Time Systems.
Chapter 7: Representing Architecture.
Chapter 8: Extending UML.
Chapter 9: Model Driven Architecture.
Chapter 10: A Process for Using UML.
Chapter 11: Case Study.
Appendix A: Visual Glossary.
Appendix B: Glossary.
Appendix C: References.
Appendix D: What’s on the CD-ROM?
End-User License Agreement.
GNU General Public License.
Posted October 21, 2003
As a professional software architect, I've seen UML covered by the good, bad and ugly. This book is the best I've read. Using clean writing, useful examples, and clear language, the authors express all you need to know about UML. I will be giving this book to every member of my my development team!Was this review helpful? Yes NoThank you for your feedback. Report this reviewThank you, this review has been flagged.