UML and the unified process : practical object-oriented analysis and design / Jim Arlow and Ila Neustadt.

By:

Arlow, Jim, 1960-

Contributor(s):

Neustadt, Ila

Material type: Text

TextSeries: The Addison-Wesley object technology seriesPublication details: Boston : Addison-Wesley, 2002.Description: xvii, 395 p. : ill. ; 24 cmISBN:

0201770601 (pbk. : alk. paper)

Subject(s):

DDC classification:

005.262 ARL

Holdings
Item type	Current library	Call number	Status	Date due	Barcode
Standard Loan	Moylish Library Main Collection	005.262 ARL (Browse shelf(Opens below))	Available		39002000351586

Enhanced descriptions from Syndetics:

A practical guide to the essentials of both UML (Unified Modelling Language) and the Unified Process, aimed at the Objected Oriented (OO) designer or analyst. It provides a quick, focused tour through the early stages of the OO software development process -analysis and design. The text introduces and explains the need-to-know concepts and key elements of both UML and the Unified Process. It seeks to get the reader up to speed on successful techniques that can be immediately applied and used - the emphasis is on information that is useful from the point of view of the OO analyst and designer, and that can be applied straight away.

Includes bibliographical references (p. [381]) and index.

Table of contents provided by Syndetics

Acknowledgments (p. vi)
Preface (p. xv)
Part 1 Introducing UML and UP (p. 1)
1 What is UML? (p. 3)
1.1 Chapter roadmap (p. 3)
1.2 What is UML? (p. 5)
1.3 The birth of UML (p. 5)
1.4 Why "unified"? (p. 7)
1.5 Objects and UML (p. 7)
1.6 UML structure (p. 8)
1.7 UML building blocks (p. 8)
1.8 UML common mechanisms (p. 12)
1.9 Architecture (p. 18)
1.10 What we have learned (p. 20)
2 What is the Unified Process? (p. 22)
2.1 Chapter roadmap (p. 22)
2.2 What is UP? (p. 23)
2.3 The birth of UP (p. 24)
2.4 UP and the Rational Unified Process (p. 27)
2.5 Instantiating UP for your project (p. 28)
2.6 UP axioms (p. 29)
2.7 UP is an iterative and incremental process (p. 29)
2.8 UP structure (p. 31)
2.9 UP phases (p. 33)
2.10 What we have learned (p. 38)
Part 2 Requirements (p. 41)
3 The requirements workflow (p. 43)
3.1 Chapter roadmap (p. 43)
3.2 The requirements workflow (p. 45)
3.3 Software requirements--metamodel (p. 46)
3.4 Requirements workflow detail (p. 47)
3.5 The importance of requirements (p. 49)
3.6 Defining requirements (p. 49)
3.7 What we have learned (p. 53)
4 Use case modeling (p. 55)
4.1 Chapter roadmap (p. 55)
4.2 Use case modeling (p. 57)
4.3 UP activity: find actors and use cases (p. 57)
4.4 UP activity: detail a use case (p. 63)
4.5 Complex use cases (p. 71)
4.6 When to apply use case modeling (p. 74)
4.7 What we have learned (p. 75)
5 Advanced use case modeling (p. 78)
5.1 Chapter roadmap (p. 78)
5.2 Actor generalization (p. 79)
5.3 Use case generalization (p. 81)
5.4 [double left angle bracket]include[double right angle bracket] (p. 84)
5.5 [double left angle bracket]extend[double right angle bracket] (p. 86)
5.6 When to use advanced features (p. 90)
5.7 What we have learned (p. 91)
Part 3 Analysis (p. 95)
6 The analysis workflow (p. 97)
6.1 Chapter roadmap (p. 97)
6.2 The analysis workflow (p. 98)
6.3 Analysis model--rules of thumb (p. 100)
6.4 What we have learned (p. 102)
7 Classes and objects (p. 103)
7.1 Chapter roadmap (p. 103)
7.2 What are objects? (p. 104)
7.3 UML object notation (p. 108)
7.4 What are classes? (p. 110)
7.5 UML class notation (p. 114)
7.6 Scope (p. 120)
7.7 Object construction and destruction (p. 122)
7.8 What we have learned (p. 124)
8 Finding analysis classes (p. 127)
8.1 Chapter roadmap (p. 127)
8.2 UP activity: analyze a use case (p. 129)
8.3 What are analysis classes? (p. 129)
8.4 Finding classes (p. 134)
8.5 Creating a first cut analysis model (p. 138)
8.6 What we have learned (p. 139)
9 Relationships (p. 142)
9.1 Chapter roadmap (p. 142)
9.2 What is a relationship? (p. 144)
9.3 What is a link? (p. 144)
9.4 What is an association? (p. 147)
9.5 What is a dependency? (p. 160)
9.6 What we have learned (p. 166)
10 Inheritance and polymorphism (p. 170)
10.1 Chapter roadmap (p. 170)
10.2 Generalization (p. 171)
10.3 Class inheritance (p. 173)
10.4 Polymorphism (p. 176)
10.5 What we have learned (p. 180)
11 Analysis packages (p. 182)
11.1 Chapter roadmap (p. 182)
11.2 What is a package? (p. 182)
11.3 Package dependencies (p. 185)
11.4 Transitivity (p. 186)
11.5 Nested packages (p. 187)
11.6 Package generalization (p. 189)
11.7 Package stereotypes (p. 190)
11.8 Architectural analysis (p. 191)
11.9 What we have learned (p. 194)
12 Use case realization (p. 197)
12.1 Chapter roadmap (p. 197)
12.2 UP activity: analyze a use case (p. 199)
12.3 What are use case realizations? (p. 199)
12.4 Use case realization--elements (p. 200)
12.5 Interaction diagrams (p. 201)
12.6 Collaborations and interactions (p. 202)
12.7 Collaboration diagrams (p. 202)
12.8 Sequence diagrams (p. 220)
12.9 What we have learned (p. 227)
13 Activity diagrams (p. 231)
13.1 Chapter roadmap (p. 231)
13.2 What are activity diagrams? (p. 232)
13.3 Action states (p. 233)
13.4 Subactivity states (p. 234)
13.5 Transitions (p. 235)
13.6 Decisions (p. 236)
13.7 Forks and joins (p. 237)
13.8 Swimlanes (p. 238)
13.9 Object flows (p. 239)
13.10 Signals (p. 240)
13.11 What we have learned (p. 242)
Part 4 Design (p. 245)
14 The design workflow (p. 247)
14.1 Chapter roadmap (p. 247)
14.2 The design workflow (p. 249)
14.3 Design artefacts--metamodel (p. 250)
14.4 Design workflow detail (p. 253)
14.5 Artefacts (p. 254)
14.6 What we have learned (p. 255)
15 Design classes (p. 257)
15.1 Chapter roadmap (p. 257)
15.2 What are design classes? (p. 259)
15.3 Anatomy of a design class (p. 260)
15.4 Well-formed design classes (p. 261)
15.5 Inheritance (p. 264)
15.6 Templates (p. 268)
15.7 Nested classes (p. 270)
15.8 What we have learned (p. 271)
16 Refining analysis relationships (p. 274)
16.1 Chapter roadmap (p. 274)
16.2 Design relationships (p. 276)
16.3 Aggregation and composition (p. 276)
16.4 Aggregation semantics (p. 277)
16.5 Composition semantics (p. 280)
16.6 How to refine analysis relationships (p. 282)
16.7 One-to-one associations (p. 283)
16.8 Many-to-one associations (p. 283)
16.9 One-to-many associations (p. 284)
16.10 Collections (p. 284)
16.11 Reified relationships (p. 288)
16.12 What we have learned (p. 291)
17 Interfaces and subsystems (p. 296)
17.1 Chapter roadmap (p. 296)
17.2 What is an interface? (p. 297)
17.3 Interfaces and component-based development (p. 300)
17.4 Finding interfaces (p. 303)
17.5 Designing with interfaces (p. 303)
17.6 What are subsystems? (p. 304)
17.7 Advantages and disadvantages of interfaces (p. 309)
17.8 What we have learned (p. 310)
18 Use case realization--design (p. 313)
18.1 Chapter roadmap (p. 313)
18.2 Use case realization--design (p. 314)
18.3 Interaction diagrams--design (p. 314)
18.4 Subsystem interactions (p. 316)
18.5 What we have learned (p. 318)
19 Basic statecharts (p. 319)
19.1 Chapter roadmap (p. 319)
19.2 Statechart diagrams (p. 320)
19.3 State machines and classes (p. 321)
19.4 Basic statechart syntax (p. 322)
19.5 States (p. 322)
19.6 Transitions (p. 324)
19.7 Events (p. 325)
19.8 What we have learned (p. 328)
20 Advanced statecharts (p. 331)
20.1 Chapter roadmap (p. 331)
20.2 Composite states (p. 333)
20.3 Sequential composite states (p. 333)
20.4 Concurrent composite states (p. 335)
20.5 Submachine communication (p. 338)
20.6 History (p. 341)
20.7 Submachine state (p. 343)
20.8 What we have learned (p. 345)
Part 5 Implementation (p. 347)
21 The implementation workflow (p. 349)
21.1 Chapter roadmap (p. 349)
21.2 The implementation workflow (p. 350)
21.3 Model trace relationships (p. 351)
21.4 Implementation workflow detail (p. 352)
21.5 Artefacts (p. 353)
21.6 What we have learned (p. 353)
22 Components (p. 355)
22.1 Chapter roadmap (p. 355)
22.2 What is a component? (p. 356)
22.3 Simple Java example (p. 357)
22.4 Enterprise JavaBean example (p. 360)
22.5 What we have learned (p. 363)
23 Deployment (p. 364)
23.1 Chapter roadmap (p. 364)
23.2 The deployment diagram (p. 365)
23.3 Deployment diagram syntax (p. 366)
23.4 Enterprise JavaBean example (p. 368)
23.5 What we have learned (p. 370)
Appendix 1 Example use case model (p. 373)
Appendix 2 XML and use cases (p. 379)
Bibliography (p. 381)
Index (p. 383)

Excerpt provided by Syndetics

This book provides an accurate, concise and practical guide to the processes and techniques of object oriented analysis and design using the Unified Modelling Language (UML) and the Unified Process (UP). The reader will learn to apply the relevant activities defined by the Unified Process, and learn how to use the UML to create effective and valuable OO models. As such, one could reasonably view this book as a presentation of the UDSP from the point of view of the OO analyst/designer. UML and UP are still, by themselves, not enough. There are OO modelling techniques and processes that the modeller needs to have at his or her fingertips that are not described in the UP, and we'll try to present these where appropriate and show how they fit into the UP framework in a structured manner. We attempt to be as accurate and rigorous in our use of UML as possible. This is important as many UML presentations are constrained by the limited features offered by specific CASE tools and so give a distorted and incomplete perspective on the rich and powerful UML syntax and semantics. We believe that creating a good OO model is a matter of both creativity and craftsmanship. A key aspect of craftsmanship is precision and this summarises our approach to UML modelling. This book is biased towards the beginning of the software development lifecycle -- towards OO requirements engineering and analysis. This is because these are exactly the areas where the OO analyst/designer can add most value. As we will see, most projects that fail do so due to a failure in requirements or analysis, and so that it is the beginning of the software development lifecycle that is of paramount importance for success. OO requirements engineering and analysis tends to be of strategic importance, whilst OO design is in some sense more tactical in nature. As well, OO design is always predicated on a technical infrastructure and, as such, is hard to teach without the reader having some knowledge of the particular technical infrastructure chosen. Although OO design may be harder to teach than OO analysis, it is often easier to do! This is because many OO analyst/designers come from a programming background, and are used to working at the lower level of abstraction required by design. Abstraction is the primary skill of the accomplished OO analyst/designer, and by focussing on requirements and analysis in this book, we aim to try to inculcate or enhance this skill in the reader. Finally, we'd like to point out that there are no easy shortcuts to OO analysis/design nirvana. A book like this can certainly help. But one really only becomes good at OO analysis and design through direct experience and practical application. Some of us seem to naturally have an innate ability to work at high levels of abstraction, and therefore make good OO analysts. Others of us have the sort of attention to detail and craftsmanship to make excellent OO designers. However, for the rest of us, these are skills that can be learned. We hope that this book will help the reader in this learning process! 0201770601P08132001 Excerpted from UML and the Unified Process: Practical Object-Oriented Analysis and Design by Ila Neustadt, Jim Arlow All rights reserved by the original copyright owners. Excerpts are provided for display purposes only and may not be reproduced, reprinted or distributed without the written permission of the publisher.

Author notes provided by Syndetics

Jim Arlow is a London-based independent consultant and trainer with over 10 years' experience designing & programming OO systems. He regularly devises & teaches courses (including OO A&D, Java Servlets & Server Pages, RMI, EJBs & JDBC to IT professionals) and speaks at conferences internationally.Ila Neustadt has worked in IT for British Airways for over 17 years, on a wide range of projects including work in the strategy department developing architecture training and acting as programme head for the graduate Business Analyst scheme.