¡Descarga UML para Java y más Ejercicios en PDF de Ingeniería Infórmatica solo en Docsity!
UML
for
Java
Programmers
Robert Cecil Martin
Object Mentor Inc.
Prentice Hall, Englewood Cliffs, New Jersey 07632 Don’t Panic Do n’t Panic Do n’t Panic Do n’t Panic Don ’t Panic Don ’t Panic Don ’t Panic Don ’t Panic Don’t Panic Don’t Panic Don’t Panic Don’t Panic Don’t Panic Don’t Panic Don’t Panic Don’t Panic Don’t Pan ic Don’t Pan ic Don’t Pan ic Don’t Panic Don’t Panic Don’t Panic Do n’t Panic Do n’t Panic Do n’t Panic Do n’t Panic Don ’t Panic Don ’t Panic Don ’t Panic
The author and publisher of this book have used their best efforts in preparing this book. These efforts include the development, research, and testing of the theories and pro- grams to determine their effectiveness. The author and publisher shall not be liable in any event for incidental or consequential damages in connection with, or arising out of, the furnishing, performance, or use of these programs.
All rights reserved. No part of this book may be reproduced, in any form or by any means, without permission in writing from the publisher.
Printed in the United States of America
10 9 8 7 6 5 4 3 2 1
ISBN 0-13-203837-
Publisher: Alan Apt Production Editor: Cover Designer: Copy Editor:
© 2002 by Prentice-Hall, Inc. A Simon & Schuster Company
Martin, Robert Cecil. The Principles, Practices, & Patterns of Agile Software Development /Robert Cecil Martin. p. cm. “An Alan R. Apt Book.” Includes index. ISBNxxxxxxxxx
This book is dedicated to my grandchildren:
XXX: the son of Micah and Angelique.
Alexis: the daughter of Angela and Matt.
It has been said that grandchildren are the desert of life.
If that’s so, what am I supposed to do with all the many
main courses I’m not done with yet?
Source Code and Contact Information:
Much of the source code presented in this book can be obtained from the Object Mentor Inc. web site. www.objectmentor.com/UMLFJP
Robert C. Martin: [email protected]
Object Mentor Inc.: [email protected] www.objectmentor.com
iii Chapter :
- Overview of UML for Java Programmers .................................. Chapter 1:
- Diagram Types ......................................................................................
- Class Diagrams...................................................................................
- Object Diagrams.................................................................................
- Sequence Diagrams ............................................................................
- Collaboration Diagrams .....................................................................
- State Diagrams ...................................................................................
- Conclusion ..............................................................................................
- Bibliography ..........................................................................................
- Working with Diagrams .................................................................... Chapter 2:
- Why Model? ...........................................................................................
- Why build models of software? .......................................................
- Why should we build comprehensive designs before coding? ........
- Making Effective use of UML ............................................................
- Communicating with Others. ...........................................................
- Back end Documentation .................................................................
- What to keep, and What to throw away. ..........................................
- Iterative Refinement ...........................................................................
- Behavior first....................................................................................
- Check the structure...........................................................................
- Envisioning the code. .......................................................................
- Iterative Refinement .........................................................................
- Minimalism ..........................................................................................
- When and how to draw diagrams. .....................................................
- When to draw diagrams, and when to stop. .....................................
- CASE Tools......................................................................................
- But what about documentation?.......................................................
- And Javadocs?..................................................................................
- Conclusion ............................................................................................
- Class Diagrams ................................................................................... Chapter 3:
- The Basics ............................................................................................ ii
- Classes ..............................................................................................
- Association .......................................................................................
- Multiplicity.......................................................................................
- Inheritance ........................................................................................
- An Example Class Diagram ...............................................................
- The Details ...........................................................................................
- Class Stereotypes..............................................................................
- Abstract classes ................................................................................
- Properties..........................................................................................
- Aggregation......................................................................................
- Composition .....................................................................................
- Multiplicity.......................................................................................
- Association Stereotypes ...................................................................
- Inner Classes ....................................................................................
- Anonymous Inner Classes................................................................
- Association classes...........................................................................
- Association Qualifiers ......................................................................
- Conclusion ............................................................................................
- Bibliography ........................................................................................
- Sequence Diagrams ........................................................................... Chapter 4:
- The Basics ............................................................................................
- Objects, Lifelines, Messages, and other odds and ends. ..................
- Creation and Destruction..................................................................
- Simple Loops....................................................................................
- Cases and Scenarios .........................................................................
- Advanced Concepts .............................................................................
- Loops and Conditions.......................................................................
- Messages that take time....................................................................
- Asynchronous Messages. .................................................................
- Multiple Threads ..............................................................................
- Active Objects ..................................................................................
- Sending Messages to Interfaces. ......................................................
- Conclusion ............................................................................................
- Use Cases ............................................................................................... Chapter 5:
- Writing Use Cases ...............................................................................
- What is a use case.............................................................................
- The Primary Course .........................................................................
- Alternate Courses .............................................................................
- What else? ........................................................................................
- Use Cases Diagrams ............................................................................
- System Boundary Diagram ..............................................................
- Use Case Relationships ....................................................................
- Conclusion ............................................................................................
- Principles of OOD .............................................................................. Chapter 6:
- Design Quality .....................................................................................
- Design Smells...................................................................................
- Dependency Management ................................................................
- The Single Reponsibility Principle (SRP) .........................................
- The Open Closed Principle (OCP) ....................................................
- The Liskov Substitution Principle (LSP) ..........................................
- The Dependency Inversion Principle (DIP) ......................................
- The Interface Segregation Principle ..................................................
- Conclusion ............................................................................................
- Bibliography ........................................................................................
- The Practices: dX ............................................................................... Chapter 7:
- Iterative Development .........................................................................
- The Initial Exploration .....................................................................
- Estimating the features .....................................................................
- Spikes ...............................................................................................
- Planning ...............................................................................................
- Planning Releases.............................................................................
- Planning Iterations............................................................................
- The midpoint. ...................................................................................
- Velocity Feedback............................................................................ iv
- Organizing the Iterations into Management Phases ........................
- What’s in an Iteration? .......................................................................
- Developing in Pairs ..........................................................................
- Acceptance Tests..............................................................................
- Unit Tests .........................................................................................
- Refactoring .......................................................................................
- Open Office ......................................................................................
- Continuous Integration.....................................................................
- Conclusion ............................................................................................
- Bibliography ........................................................................................
- Packages ................................................................................................ Chapter 8:
- Java Packages ......................................................................................
- Packages ...........................................................................................
- Dependencies ...................................................................................
- Binary Components -- .jar files. .........................................................
- Principles of Package Design .............................................................
- The Release/Reuse Equivalency Principle (REP) ............................
- The Common Closure Principle (CCP)............................................
- The Common Reuse Principle (CRP) ..............................................
- The Acyclic Dependencies Principle (ADP)....................................
- The Stable Dependencies Principle (SDP).......................................
- The Stable Abstractions Principle (SAP) .......................................
- Conclusion ..........................................................................................
- Object Diagrams .............................................................................. Chapter 9:
- A Snapshot in Time. ..........................................................................
- Active Objects ....................................................................................
- Conclusion ..........................................................................................
- State Diagrams .................................................................................. Chapter 10:
- The Basics .......................................................................................... v Chapter :
- Special Events ................................................................................
- Super States ....................................................................................
- Initial and Final Pseudo States .......................................................
- Using FSM Diagrams ........................................................................
- SMC ...............................................................................................
- ICE: A Case Study .........................................................................
- Conclusion ..........................................................................................
- Heuristics and Coffee ..................................................................... Chapter 11:
- The Mark IV Special Coffee Maker ................................................
- A Challenge....................................................................................
- A Common, but Hideous, Coffee Maker Solution.........................
- MissingMethods. ............................................................................
- Vapor Classes.................................................................................
- Imaginary Abstraction....................................................................
- God Classes ....................................................................................
- A Coffee Maker Solution ..................................................................
- Crossed Wires ................................................................................
- The Coffee Maker User Interface...................................................
- Use Case 1: User pushes brew button. ...........................................
- Use Case 2: Containment Vessel not Ready. .................................
- Use Case 3: Brewing Complete. ....................................................
- Use Case 4: Coffee all gone. ..........................................................
- Implementing the Abstract Model..................................................
- Use Case 1. User pushes Brew Button (Mark IV) .........................
- Implementing the isReady() functions. ..........................................
- Implementing the start() functions. ................................................
- How does M4UserInterface.checkButton get called? ....................
- Completing the Coffee Maker........................................................
- The Benefits of this design.............................................................
- How did I really come up with this design?...................................
- SMC Remote Service: Case Study ............................................. Chapter 12:
- Caveat Emptor................................................................................ vi
- Unit Tests. ......................................................................................
- The SMCRemote System. .................................................................
- SMCRemoteClient ............................................................................
- SMCRemoteClient Command Line ...............................................
- SMCRemote Communication Protocols ........................................
- SMCRemoteClient .........................................................................
- The Loggers....................................................................................
- The Remote Sessions. ....................................................................
- RemoteSessionBase .......................................................................
- The Remote Registrar.....................................................................
- The Remote Compiler ....................................................................
- FileCarrier ......................................................................................
- SMCRemoteClient Conclusion ......................................................
- SMCRemoteServer ...........................................................................
- SocketService .................................................................................
- SMCRemoteService .......................................................................
- SMCRemoteServer.........................................................................
- ServerSession .................................................................................
- Three Level FSM ...........................................................................
- UserRepository...............................................................................
- OReillyEmailSender.......................................................................
- PasswordGenerator.........................................................................
- Conclusion. .........................................................................................
- Tests for SMCRemoteClient .......................................................
- Tests for SocketService .....................................................................
- Tests for SMCRemoteServer ..................................................
- Other Tests .........................................................................................
- ServerController (SMC Generated) ...............................................
- Bibliography ......................................................................................
Diagram Types 2
biological species, belong to the animal kingdom. Thus, the diagram is subject to interpre- tation.
However, the same diagram at the Specification or Implementation level has a much more precise meaning:
public class Animal {} public class Dog extends Animal {} This source code defines Animal and Dog as classes connected by an inheritance relationship. Whereas the Conceptual model says nothing at all about computers, data pro- cessing, or programs, the Specification model describes part of a program.
It is unfortunate that the diagrams themselves don’t communicate what level they are drawn at. Failure to recognize the level of a diagram is the source of significant miscom- munication between programmers and analysts. A Conceptual level diagram does not define source code, nor should it. A Specification level diagram that descibes the solution to a problem does not have to look anything like the Conceptual level diagram that describes that problem.
All the rest of the diagrams in this book will be at the Specification / Implementation level, and will be accompanied by corresponding source code where feasible. We have seen our last Conceptual level diagram.
Diagram Types
Below is a very quick tour of the primary diagrams used in UML. Once you read through it, you will be able to read and write most of the UML diagrams you will usually need. What remains, and what subsquent chapters address, are the details and formalisms that you will need to become proficient in UML.
UML has three main kinds of diagrams. Static diagrams describe the unchanging log- ical structure of software elements by depicting classes, objects, and data structures; and the relationships that exist between them. Dynamic diagrams show how software entities change during execution by depicting the flow of execution, or the way entities change
Figure 1- A Dog is an Animal
Animal
Dog
3 Chapter : Overview of UML for Java Programmers
state. Physical diagrams show the unchanging physical structure of software entities by depicting physical entities such as source files, libraries, binary files, data files, etc., and the relationships that exist between them.
Consider the code in Listing 1-1. This program implements a map based upon a sim- ple binary tree algorithm. Familiarize yourself with the code before you consider the dia- grams that follow.
Listing 1- TreeMap.java public class TreeMap { TreeMapNode topNode = null; public void add(Comparable key, Object value) { if (topNode == null) topNode = new TreeMapNode(key, value); else topNode.add(key, value); } public Object get(Comparable key) { return topNode == null? null : topNode.find(key); } } class TreeMapNode { private final static int LESS = 0; private final static int GREATER = 1; private Comparable itsKey; private Object itsValue; private TreeMapNode nodes[] = new TreeMapNode[2]; public TreeMapNode(Comparable key, Object value) { itsKey = key; itsValue = value; } public Object find(Comparable key) { if (key.compareTo(itsKey) == 0) return itsValue; return findSubNodeForKey(selectSubNode(key), key); } private int selectSubNode(Comparable key) { return (key.compareTo(itsKey) < 0)? LESS : GREATER; } private Object findSubNodeForKey(int node, Comparable key) { return nodes[node] == null? null : nodes[node].find(key); } public void add(Comparable key, Object value) { if (key.compareTo(itsKey) == 0) itsValue = value; else addSubNode(selectSubNode(key), key, value); }
5 Chapter : Overview of UML for Java Programmers
upon, the other.
- The name on an association maps to the name of the variable that holds the refer- ence.
- A number next to an arrowhead typically shows the number of instances held by the relationship. If that number is greater than one then some kind of container, usually an array, is implied.
- Class icons can have more than one compartment. The top compartment always holds the name of the class. The other compartments describe functions and vari- ables.
- The «interface» notation means that Comparable is an interface.
- Most of the notations shown are optional. Look carefully at this diagram and relate it to the code in Listing 1-1. Notice how the association relationships correspond to instance variables. For example, the association from TreeMap to TreeMapNode is named topNode and corresponds to the topNode variable within TreeMap.
Object Diagrams
Figure 1-3 is an Object Diagram. It shows a set of objects and relationships at a par- ticular moment in the execution of the system. You can view it as a snapshot of memory.
Figure 1- TreeMap Object Diagram
:TreeMap
:TreeMapNode
:TreeMapNode
:TreeMapNode
:TreeMapNode
:TreeMapNode
:TreeMapNode
:TreeMapNode
nodes[LESS] nodes[GREATER]
nodes[LESS] (^) nodes[GREATER] nodes[LESS] nodes[GREATER]
topNode
Diagram Types 6
In this diagram the rectangle icons represent objects. You can tell that they are objects because their names are underlined. The the name after the colon is the name of the class that the object belongs to. Note that the lower compartment of each object shows the value of that object’s itsKey variable.
The relationships between the objects are called link s , and are derived from the asso- ciations in Figure 1-3. Note that the links are named for the two array cells in the nodes array.
Sequence Diagrams
Figure 1-4 is a Sequence Diagram. It describes how the TreeMap.add method is imple- mented.
The stick figure represents an unknown caller. This caller invokes the add method on a TreeMap object. If the topNode variable is null, then TreeMap responds by creating a new TreeMapNode and assigning it to topNode. Otherwise the TreeMap sends the add message to topNode.
The boolean expressions inside square brackets are called guards. They show which path is taken. The message arrow that terminates on the TreeMapNode icon represents construction. The little arrows with circles are called data tokens. In this case they depict the construction arguments. The skinny rectangle below TreeMap is called an activation. It depicts how much time the add method executes.
Collaboration Diagrams
The diagram in Figure 1-5 is a Collaboration Diagram depicting the case of TreeMap.add where treeNode is not null. Collaboration diagrams contain the same information that sequence diagrams contain. However whereas sequence diagrams make the order of the messages clear, collaboration diagrams make the relationships between the objects clear.
Figure 1- TreeMap.add
:TreeMap
add(key, value) topNode: TreeMapNode
value key
[topNode == null] add(key, value) [topNode != null]
Conclusion 8
We can translate Figure 1-6 to english as follows:
- If we are in the Locked state, and we get a coin event, then we transition to the Unlocked state and we invoke the Unlock function.
- If we are in the Unlocked state and we get a pass event then we transition to the Locked state and we invoke the Lock function.
- If we are in the Unlocked state and we get a coin event, then we stay in the Unlocked state and we call the Thankyou function.
- If we are in the Locked state and we get a pass event then we stay in the Locked state and we call the Alarm function. Diagrams like this are extremely useful for figuring out the way a system behaves. They give us the opportunity to explore what the system should do in unexpected cases, like when a user drops a coin, and then drops another coin for no good reason.
Conclusion
The diagrams shown in this chapter are enough for most purposes. Most programmers could live without any more knowledge of UML that what is shown here.
Bibliography
[Fowler00]: UML Distilled , 2d. ed. Martin Fowler, Addison Wesley, 199?
9
________________________
________________________
Working with Diagrams
“Before we explore the details of UML, it would be wise to talk about when and why we use it. Much harm has been done to software projects through the misuse and overuse of UML.
Why Model?
Why do engineers build models? Why do aerospace engineers build models of aircraft? Why do structural engineers build models of bridges? What purposes do these models serve?
These engineers build models to find out if their designs will work. Aerospace engi- neers build models of aircraft and then put them into wind tunnels to see if they will fly. Structural engineers build models of bridges to see if they will stand. Architects build models of buildings to see if their clients will like the way they look. Models are built to find out if something will work.
This implies that models must be testable. It does no good to build a model if there are no criteria you can apply to that model in order to test it. If you can’t evaluate the model, the model has no value.
Why don’t aerospace engineers just build the plane and try to fly it? Why don’t struc- tural engineers just build the bridge and then see if it stands? Because airplanes and bridges are a lot more expensive than the models. We investigate designs with models when the models are much cheaper than the real thing we are building.
