[PDF] UML Java Programmers The class diagram for this

View - Download UML Java Programmers

Previous PDF

Next PDF

UML for Java

Programmers

Robert Cecil Martin

Object Mentor Inc.

Prentice Hall, Englewood Cliffs, New Jersey 07632

Don't PanicDon't PanicDon't PanicDon't PanicDon'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 Panic Don't Panic Don't Panic Don't Panic Don't PanicDon't PanicDon't PanicDon't PanicDon'tPanicDon'tPanicDon'tPanicDon'tPanic

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.

PrintedintheUnitedStatesofAmerica

10987654321

ISBN 0-13-203837-4

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

PRENTICE-HALLINTERNATIONAL(UK) Limited,London

PRENTICE-HALL OFAUSTRALIAPTY.LIMITED,Sydney

PRENTICE-HALLCANADA,INC.,Toronto

PRENTICE-HALL OFINDIAPRIVATELIMITED,New Delhi

PRENTICE-HALL OFJAPAN,INC.,Tokyo

SIMON&SCHUSTERASIAPTE.LTD.,Singapore

EDITORAPRENTICE-HALL DOBRASIL,LTDA.,Rio de Janeiro

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: unclebob@objectmentor.com

Object Mentor Inc.: info@objectmentor.comwww.objectmentor.com iChapter :

Chapter 1:

Overview of UML for Java Programmers

..................................1 Diagram Types......................................................................................2 Class Diagrams...................................................................................4 Object Diagrams.................................................................................5 Sequence Diagrams............................................................................6 Collaboration Diagrams .....................................................................6 State Diagrams ...................................................................................7

Chapter 2:

Working with Diagrams

Why Model?...........................................................................................9

Why build models of software? .......................................................10 Why should we build comprehensive designs before coding? ........10 Making Effective use of UML............................................................10 Communicating with Others............................................................11 Back end Documentation.................................................................13 What to keep, and What to throw away...........................................14 Iterative Refinement...........................................................................15 Behavior first....................................................................................15 Check the structure...........................................................................17 Envisioning the code........................................................................19 Iterative Refinement.........................................................................20 When and how to draw diagrams......................................................21 When to draw diagrams, and when to stop. .....................................21 CASE Tools......................................................................................22 But what about documentation?.......................................................23 And Javadocs?..................................................................................23

Chapter 3:

Class Diagrams

ii

The Basics............................................................................................25

An Example Class Diagram...............................................................28

The Details...........................................................................................30

Class Stereotypes..............................................................................30 Abstract classes ................................................................................31 Association Stereotypes ...................................................................35 Inner Classes ....................................................................................36 Anonymous Inner Classes................................................................36 Association classes...........................................................................37 Association Qualifiers......................................................................38

Chapter 4:

Sequence Diagrams

The Basics............................................................................................41

Objects, Lifelines, Messages, and other odds and ends...................41 Creation and Destruction..................................................................43 Simple Loops....................................................................................44 Cases and Scenarios.........................................................................44 Advanced Concepts.............................................................................48 Loops and Conditions.......................................................................48 Messages that take time....................................................................49 Asynchronous Messages..................................................................51 Multiple Threads..............................................................................53 Active Objects..................................................................................54 Sending Messages to Interfaces. ......................................................54 iiiChapter :

Chapter 5:

Use Cases

Writing Use Cases...............................................................................57 What is a use case.............................................................................58 The Primary Course .........................................................................58 Alternate Courses.............................................................................59

What else? ........................................................................................59

Use Cases Diagrams............................................................................60 System Boundary Diagram ..............................................................60 Use Case Relationships....................................................................61

Chapter 6:

Principles of OOD

Design Quality.....................................................................................63

Design Smells...................................................................................63 Dependency Management................................................................64 The Single Reponsibility Principle (SRP).........................................64 The Open Closed Principle (OCP)....................................................66 The Liskov Substitution Principle (LSP)..........................................78 The Dependency Inversion Principle (DIP)......................................80 The Interface Segregation Principle..................................................81

Chapter 7:

The Practices: dX

Iterative Development.........................................................................85 The Initial Exploration.....................................................................85 Estimating the features.....................................................................86 Planning Releases.............................................................................87 Planning Iterations............................................................................87 The midpoint....................................................................................88 iv Velocity Feedback............................................................................89 Organizing the Iterations into Management Phases........................89 What's in an Iteration?.......................................................................89 Developing in Pairs..........................................................................90 Acceptance Tests..............................................................................90

Unit Tests .........................................................................................91

Open Office......................................................................................92 Continuous Integration.....................................................................92

Chapter 8:

Packages

Java Packages......................................................................................95

Dependencies ...................................................................................96 Binary Components -- .jar files..........................................................97 Principles of Package Design.............................................................97 The Release/Reuse Equivalency Principle (REP)............................98 The Common Closure Principle (CCP)............................................98 The Common Reuse Principle (CRP) ..............................................99 The Acyclic Dependencies Principle (ADP)....................................99 The Stable Dependencies Principle (SDP).......................................99 The Stable Abstractions Principle (SAP).......................................100

Chapter 9:

Object Diagrams

A Snapshot in Time...........................................................................103

Active Objects....................................................................................105

Chapter 10:

State Diagrams

vChapter :

The Basics..........................................................................................109

Special Events................................................................................110 Super States....................................................................................111 Initial and Final Pseudo States.......................................................113 Using FSM Diagrams........................................................................113

SMC ...............................................................................................114

ICE: A Case Study .........................................................................116

Chapter 11:

Heuristics and Coffee

The Mark IV Special Coffee Maker................................................123 A Challenge....................................................................................126 A Common, but Hideous, Coffee Maker Solution.........................126 Vapor Classes.................................................................................127 Imaginary Abstraction....................................................................128 God Classes....................................................................................129 A Coffee Maker Solution..................................................................129 Crossed Wires ................................................................................130 The Coffee Maker User Interface...................................................131 Use Case 1: User pushes brew button............................................131 Use Case 2: Containment Vessel not Ready..................................132 Use Case 3: Brewing Complete. ....................................................132 Use Case 4: Coffee all gone...........................................................134 Implementing the Abstract Model..................................................134 Use Case 1. User pushes Brew Button (Mark IV) .........................135 Implementing the isReady() functions...........................................136 Implementing the start() functions.................................................137 How does M4UserInterface.checkButton get called?....................138 Completing the Coffee Maker........................................................139 The Benefits of this design.............................................................141 How did I really come up with this design?...................................141

Chapter 12:

SMC Remote Service: Case Study

vi Caveat Emptor................................................................................153 Unit Tests.......................................................................................154 The SMCRemote System..................................................................154 SMCRemoteClient Command Line...............................................155 SMCRemote Communication Protocols........................................155 The Loggers....................................................................................164 The Remote Sessions. ....................................................................165 RemoteSessionBase .......................................................................166 The Remote Registrar.....................................................................169 The Remote Compiler....................................................................171

FileCarrier ......................................................................................176

SMCRemoteClient Conclusion......................................................177 Three Level FSM ...........................................................................192 Tests for SMCRemoteClient.......................................................204 Tests for SocketService.....................................................................211 Tests for SMCRemoteServer..................................................214

Other Tests.........................................................................................224

ServerController (SMC Generated)...............................................227 1 ________________________ 1 ________________________

Overview of UML for Java

Programmers

The Unified Modeling Language (UML) is a graphical notation for drawing diagrams of software concepts. One can use it for drawing diagrams of a problem domain, a proposed software design, or an already completed software implementation. Fowler 1 describes these three different levels asConceptual,Specification,andImplementation.Thisdeals with the last two. SpecificationandImplementationlevel diagrams have a strong connection to source code. Indeed it is the intent for aSpecificationlevel diagram to be turned into source code. Likewise it is the intent for anImplementationlevel diagram to describe existing source code. As such there are rules and semantics that diagrams at these levels must follow. Such diagrams have very little ambiguity, and a great deal of formality. On the other hand, diagrams at theConceptuallevel are not strongly related to source code. Rather they are related tohumanlanguage. They are a shorthand used describe con- cepts and abstractions that exist in the human problem domain. They don't follow strong semantic rules and therefore their meaning can be ambiguous and subject to interpretation. Consider, for example, the following sentence:A dog is an animal. We can create a ConceptualUML diagram that respresents this sentence. (See Figure 1-1.) This diagram depicts two entities namedAnimalandDogconnected bygeneraliza- tionrelationship. AnAnimalis a generalization of aDog.ADogis a special case of an Animal. That's all the diagram means. Nothing more can be inferred from it. We might be asserting that our pet dog, Sparky, is an animal; or we might be asserting that dogs, as a

1. [Fowler00], p??

2Diagram Types

biological species, belong to the animal kingdom. Thus, the diagram is subject to interpre- tation. However, the same diagram at theSpecificationorImplementationlevel has a much more precise meaning: public class Animal {}public class Dog extends Animal {} This source code definesAnimalandDogas classes connected by aninheritance relationship. Whereas theConceptualmodel says nothing at all about computers, data pro- cessing, or programs, theSpecificationmodeldescribes 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. AConceptuallevel diagramdoes not define source code, nor should it. ASpecificationlevel diagram that descibes the solution to a problem does not have to look anything like theConceptuallevel diagram that describes that problem. All the rest of the diagrams in this book will be at theSpecification/Implementation level, and will be accompanied by corresponding source code where feasible. We have seen our lastConceptuallevel 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 changeFigure 1-1

A Dog is an Animal

Animal

Dog

3Chapter : 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-1

TreeMap.java

public class TreeMap {TreeMapNode topNode = null; public void add(Comparable key, Object value) { if (topNode == null)topNode = new TreeMapNode(key, value); elsetopNode.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);}

4Diagram Types

Class Diagrams

TheClass Diagramin Figure 1-2 shows the major classes and relationships in the program. It shows that there is a

TreeMapclass that has public methods namedaddand

get. It shows thatTreeMapholds a reference to aTreeMapNodeinavariablenamed topNode. It shows that eachTreeMapNodeholds a reference to two otherTreeMapNode instances in some kind of container namednodes. And it shows that eachTreeMapNode instance holds references to two other instances in variables nameditsKeyand itsValue.TheitsKeyvariable holds a reference to some instance that implements the Comparableinterface. TheitsValuevariable simply holds a reference to some object. We'll go over the nuances of class diagrams in a subsequent chapter. For now, there are only a few things you need to know. Rectangles represent classes, and arrows represent relationships.

In this diagram all the relationships areassociations. Associations are simpledata relationships in which one object holds a reference to, and invokes methods

private void addSubNode(int node, Comparable key,Object value) {if (nodes[node] == null) nodes[node] = new TreeMapNode(key, value);else nodes[node].add(key, value);}

Figure 1-2

Class Diagram of TreeMapListing 1-1 (Continued)

TreeMap.java

+ add(key, value) +get(key)

TreeMap

+ add(key, value) + find(key)

TreeMapNode

topNode

2 nodes

Comparable"interface»

quotesdbs_dbs10.pdfusesText_16

[PDF] uml diagrams with inheritance

[PDF] uml inheritance java

[PDF] uml questions and answers pdf

[PDF] umr nurse line phone number

[PDF] un allèle muté

[PDF] un anticorps in english

[PDF] un bail traduzione in francese

[PDF] un calendar 2020

[PDF] un cescr general comment 7

[PDF] un climate change report pdf 2018

[PDF] un convention on the law of the sea arctic

[PDF] un demographic report 2019

[PDF] un french ipa

[PDF] un histoire d'amour triste

[PDF] un language exam