Register your product to gain access to bonus material or receive a coupon.
Java Design: Objects, UML, and Process
- By Kirk Knoernschild
- Published Dec 18, 2001
Book
- Sorry, this book is no longer in print.
Description
- Copyright 2002
- Edition: 1st
- Book
- ISBN-10: 0-201-75044-9
- ISBN-13: 978-0-201-75044-7
Software designers, developers, and architects are constantly confronted with the same confounding problem: how to design software that is both flexible and resilient amid change. To accomplish this tall task, practitioners must utilize the best available technologies to the fullest.
Java™ Design relies on a combination of best practices and best-of-breed technologies to create a clear and concise guide to building high-quality, lasting software designs. In particular, the author provides unique insight into using the Unified Modeling Language (UML) to develop Java applications.
The first half of the book focuses on the software process and how UML, Java technology, and object-oriented programming can be used effectively. The advantages of each technology are enumerated, highlighting common principles. Also included are in-depth discussions of design patterns, the Unified Process, and Extreme Programming.
The second half of the book describes how these complementary technologies can be used together as a system of checks and balances to ensure successful creation of high-quality software. You'll also find details on modeling strategies, a phased approach to adopting each of the technologies outlined, and the design of subsystems.
Key topics include:
- Object-oriented principles and patterns
- UML and the role of modeling
- UML and the software process, including best practices and lifecycle development
- Modeling strategies and requirements
- Behavioral modeling
- Architectural modeling
- Designing subsystems
- Refactoring
Armed with a fresh perception of current design tools, this book will give you a deeper understanding of how to design cleaner Java applications using UML. Learn how you can expand your developer's toolkit using existing technologies in new ways--and create better software.
0201750449B11262001
Sample Content
Downloadable Sample Chapter
Click below for Sample Chapter related to this title:
knoernschildch01.pdf
knoernschildch02.pdf
Table of Contents
Preface.
Introduction.
1. OO Principles and Patterns.
Introduction.
Principles, Patterns, and the OO Paradigm.
Class Principles.
Open Closed Principle (OCP).
Liskov Substitution Principle (LSP).
Dependency Inversion Principle (DIP).
Interface Segregation Principle.
Composite Reuse Principle (CRP).
Principle of Least Knowledge (PLK).
Package Principles.
Package Dependency.
Release Reuse Equivalency Principle (REP).
Common Closure Principle (CCP).
Common Reuse Principle (CRP).
Acyclic Dependencies Principle (ADP).
Stable Dependencies Principle (SDP).
Stable Abstractions Principle (SAP).
Patterns.
Strategy.
Visitor.
Layers.
Conclusion.
2. Introduction to the UML.
Introduction.
UML Defined.
Origin.
Role of Modeling.
The Challenge.
Complexity of Architecture.
The Remedy.
Benefits.
Conclusion.
3. Fundamental UML.
Introduction.
Models and Views.
Fundamental Elements.
Diagrams.
Views.
Core Diagrams.
Behavioral Diagrams.
Structural Diagrams.
Fundamental Elements.
Structural Elements.
Java Independent Entities.
Java Dependent Entities.
Diagram Introduction.
Sequence Diagram.
Class Diagram.
Package Diagram.
Conclusion.
4. UML and Software Process.
Introduction.
Process Defined.
Best Practices.
Behavioral Driven.
Architecture Centric.
Iterative.
Refactoring.
Visual Modeling.
Simple Prototypes.
Development Lifecycle and UML.
Requirements.
Analysis & Design.
Construction.
Test.
Deployment.
The Full Lifecycle.
Conclusion.
5. Modeling Strategies.
Introduction.
Integration Goals.
Development Approach.
Tool Approach.
Integration Factors.
Development Culture.
Software Process.
Object Oriented Experience.
Technological.
Modeling Strategies.
Integration Strategy.
Conclusion.
6. Requirements Modeling.
Introduction.
Notation.
Actor.
Use Case.
Relationships.
Use Case Diagram.
Stereotypes.
Requirements Modeling.
Problem Statement.
Use Case Diagrams.
Use Case Specifications.
Additional Elements.
Conclusion.
7. Problem Analysis.
Introduction.
Notation.
Class.
Association.
Package.
Dependency.
Stereotype.
Collaboration.
Realization.
Identifying Initial Concepts.
Software Specification.
Boundary.
Entity.
Control.
Establishing Architecture.
Allocating Classes.
Conclusion.
8. Behavioral Modeling.
Introduction.
Notation.
Object.
Message.
Sequence Diagrams.
Collaboration Diagrams.
Use Case Realizations.
Responsibility Allocation.
Decentralized versus Centralized Flow of Control.
Controllers as Mediators.
Managing Collections.
Accessor and Mutator Methods.
Additional Diagrams.
Simple Prototypes.
Model Structure.
Conclusion.
9. Structural Modeling.
Introduction.
Notation.
Class Diagram.
Structural Elements.
Relationships.
Coupling and Cohesion.
Useful Class Diagrams.
Package Diagrams.
Interface Diagram.
Implementation Diagrams.
View of Participating Classes (VOPC).
Identifying Structure.
Complex Structure.
Factories.
Collections.
Structural Notes.
Model Structure.
View of Participating Classes.
Conclusion.
10. Architectural Modeling.
Introduction.
Defining Architecture.
Establishing Architecture.
Architectural Mechanisms.
Layers.
Observing.
Model-View-Controller.
Partitions.
Views of Architecture.
Frameworks and Class Libraries.
Frameworks.
Class Libraries.
Component Architectures.
Components Defined.
Components and UML.
Component Sample.
Conclusion.
11. Designing Subsystems.
Introduction.
Defining Subsystems.
Subsystem Dependencies.
Subsystems in Java.
Subsystem Specification.
Subsystem Identification.
Subsystem Development.
Subsystems as Frameworks.
Conclusion.
Bibliography.
Index. 0201750449T09042001
Preface
This book emphasizes the utilization of Java, the Unified Modeling Language (UML), object-orientation, and software process as a cohesive whole. This book will help you
- Understand how to apply proven object-oriented design principles and patterns to develop resilient, robust, and extensible software systems using the Java programming language
- Gain insight into how to adopt and take advantage of the most useful aspects of the UML on a Java development project, while ignoring those less often used
- Do the preceding within the context of a well-defined, repeatable, and predictable software development process, ensuring that the software artifacts that are created are used
This book documents my experiences developing enterprisewide software applications. It contains input from literally hundreds of developers I've instructed and worked with throughout my years of teaching and applying these concepts. It answers these developers' most frequently asked questions in a format that I've found to be understandable by those developers. The approach taken in presenting these answers is one of clear and concise directions, followed by elaborating how various technologies can be used together to realize resilient results. I hope that the information in this book can save you both time and energy in your development efforts.
Intended AudienceThis book discusses how the UML can be used during an implementation stage of the software development lifecycle. With its emphasis on object orientation, problem solving, and communication, this book will give developers a deeper understanding of how to design cleaner Java applications. Much of the discussion is focused on refactoring or cleaning up the design of existing code. Using these concepts, developers can become more efficient in discovering more resilient solutions sooner.
Designers and architects can benefit by gaining a deeper understanding of how the UML can be used to create a system of checks and balances when establishing architectural restrictions and designing subsystems. These individuals will gain insight into how our models serve as the mechanism to validate our systems' architectures. The numerous principles and guidelines discussed also will help contribute to more resilient systems, as well as serve as a measuring stick of our existing object-oriented designs.
Project managers, IT managers, and project sponsors can benefit by obtaining a deeper understanding of the importance of these key technologies. No longer will we view each of these technologies as separate entities, but we'll see them as a set of complementary tools that can be used together to contribute to a lower-risk development effort.
FeedbackI'm always interested in obtaining feedback from individuals reading this book. Feel free to e-mail me the information you found most useful. But more importantly, I'm interested in hearing how you feel this book could be improved. Such feedback can ensure future readers obtain the knowledge needed to enhance their software development efforts. I'll post additional information on this book at www.kirkk.com/JOUP.html.
Kirk Knoernschildjoup@kirkk.comwww.kirkk.com
0201750449P11272001
Index
- (minus sign), 61, 132
+ (plus sign), 132
# (pound sign), 61, 132
AAbstract classes, 9, 10, 11-12. See also Classes
Abstract coupling, 13, 175, 183. See also Coupling
Abstract Windowing Toolkit (AWT), 67, 69, 70
Accessor methods, 160-162
Activities. See also Activity diagrams
separation of, 136
use of the term, 75
Activity diagrams. See also Activities
basic description of, 56
specifying use case behavior with, 126-127
Actors
basic description of, 59, 83, 117
boundary classes and, 138
notation for, 116-117
requirements modeling and, 116-117
three types of, 117
Acyclic dependencies, 27-29, 176
Adoption strategy, xxi
ADP (Acyclic Dependencies Principle), 27-29, 36, 176, 236
Aggregation, 64
Algorithms, 7, 20, 33-34
Alternate flows, use of the term, 85, 127, 128
Analysis
design versus, 86
problem, 131-144
robustness, 138
stage, 86-90
Ancestor, use of the term, 119
Annotations, 66
Applying Enterprise JavaBeans: Component-Based Development for the J2EE Platform, 257
Architectural modeling. See also Architecture
basic description of, 201-228
class libraries and, 217, 224-225
establishing architecture for, 202-203
frameworks and, 217-219
mechanisms for, 204-211
MVC (Model-View-Controller) pattern and, 208-209
Observer pattern and, 207-208
partitions and, 209-211
Architecture. See also Architectural modeling
-centric software processes, 77
complexity of, 45, 203
component, 225-227
document, 86-87
establishing, 142-143, 202-203
4+1 View Model of, 52-53
mechanisms, 204-211
paradox, 4, 5
use of the term, 201-202
views of, 211-217
Artifacts, use of the term, 75
Association(s)
basic description of, 63, 132-133
bidirectional, 173
relationships, 173
unidirectional, 173
Attributes
accessor methods and, 161-172
definition of, 132
structural modeling and, 181, 183, 184
supressing, 181
AWT (Abstract Windowing Toolkit), 67, 69, 70
BBase classes, 10, 11-12
Behavioral diagrams, 55-56, 59. See also Behavioral modeling
Behavioral modeling. See also Behavioral diagrams
accessor methods and, 160-162
basic description of, 135-137, 145-170
collaboration diagrams and, 149-150
managing collections and, 160
Mediator pattern and, 157-160
mutator methods and, 160-162
notation, 146-150
object references and, 164-165
prototypes and, 166-168
responsibility allocation and, 151-168
Behavioral requirements, 76-77
Best practices, xxi, 75-80, 99
Booch, Grady, 42
Boundary classes, 138-139, 140, 141, 153-154
allocation of, 143
entity classes and, separating, 163-164
Brooks, Frederick, 45, 79
Bubble sort, 7
Business rule validation, 217
CCCP (Common Closure Principle), 26-27, 211, 234
CGI (Common Gateway Interface), 253
Challenges, associated with software development, 42-43
Change, probability of, evaluating, 203
Class(es). See also Classes (listed by name)
abstract, 9, 10, 11-12
allocating, 143-144
base, 10, 11-12
basic description of, 6, 61-62
boundary, 138-139, 140, 141, 143, 153-154, 163-164
closing, for modification, 8-11
cohesion of, 26
control, 140-141, 143, 153-154, 159, 160
controller, 155, 208
derived, code listing for, 261-263
entity, 140, 143, 163-164
libraries, 217, 224-225
names, 146
opening, for extension, 8-11
principles, 26-28
proxy, 230-231
software specification and, 137-141
sub-, 158, 184, 186-187
substitution of, 11-12
use of the term, 132
Class diagrams
aggregation and, 64
basic description of, 57, 70, 87
composition and, 64-65
error-handling, 222-223
implementation, 178
interfaces and, 62
interface, 177
package, 176
packages and, 62
realization and, 65
structural modeling and, 172, 175-179
VOPC (View of Participating Classes), 179
Classes (listed by name). See also Classes
Account class, 9, 10
AccountType class, 9-11, 17, 19-21, 33
AdministrativeReportController class, 141, 144
ArrayList class, 193, 194
BankSystem class, 139, 144, 152-153, 156, 180-181, 236-237
BankSystemClient class, 238
BankSystemFactory class, 238-239
BankTransaction class, 144, 152, 156-157, 180-181
Checking class, 9, 10, 17, 21
Class class, 10, 12
Client class, 23, 175, 234
ConcreteColleague class, 158
Course class, 173
DynamicClass class, 34-36
Employee class, 144, 152-153, 155-165, 180-191, 205, 208, 218
EmployeeCollection class, 160, 193-196, 218
EmployeeReportController class, 141, 144
EmployeeType class, 189, 191, 193, 197, 218
EmployeeTypeFactory class, 191, 193
errorClient class, 222
ErrorFactory class, 222
ErrorHandler class, 221
EventExample class, 69, 70
Exception class, 12
Factory class, 234-235, 236
FullTime class, 173
HRAdministrator class, 144
HRRepresentative class, 144
InterestCalculator class, 18, 19, 20, 21, 33
LoginController class, 141, 144
LoginForm class, 139, 144, 153, 163, 164, 165
MainForm class, 139, 144, 153, 165
MaintainPreferencesController class, 141, 144
MaintainTimeCardController class, 141, 144, 164-168, 192
Mediator class, 157-160
Model class, 208
MoneyMarket class, 9, 18, 19, 20
newErrorHandler class, 222
Observer class, 207-208
PartTime class, 173
Paycheck class, 144, 152, 155-157, 159, 163, 180-181
PayrollController class, 152-157, 159-160, 180-181, 189-194, 197, 205-208
PayrollDatabase class, 144, 164, 165
P
Introduction
The convergence of a suite of technologies into a cohesive whole represents a significant advantage over the same technologies standing independently. Java, object orientation, the Unified Modeling Language (UML), and software process are prominent technologies that contribute significantly to the success of software development efforts. Yet used independently, their true power may not be realized. Each of these four unique, yet complementary, technologies has a distinct form and can be studied and applied independently. However, when used together as a set of supporting technologies, we increase the likelihood of developing higher-quality, on-time, and on-budget software that meets our business needs.
Our goal is to discuss the concepts that enable developers to use the UML, objects, and software process to solve complex problems encountered during design and implementation of enterprisewide Java development. We must ensure we realize the maximum benefit of each of these powerful technologies by assembling and applying the best practices as a cohesive whole. In addition, we must ignore, or at least use more judiciously, those aspects that lack significant and immediate value. Mechanisms that enable us to prove our systems are resilient, extensible, and maintainable are sorely needed.
Unfortunately, the complexity of a single technology can be overwhelming. Regardless, we must utilize a combination of complementary technologies that ensures that the software we build is more robust. Hence, our goal throughout this book is to emphasize convergence--the convergence of Java, object orientation, the UML, and software process, and to describe how each can be used as part of a cohesive whole.
The Power of ConvergenceThroughout my travels as a corporate developer, professional instructor, consultant, and mentor, I've found that software developers everywhere consistently struggle with the same fundamental challenges. In essence, these challenges are centered on software design. Whether accommodating scope creep, managing a constant evolution in requirements when developing a new system, or attempting to add new features into an existing system, the architectural mechanisms utilized in each of the situations are vital in determining the success or failure of the software development effort. Systems that support change will grow with the businesses they support; those that don't inevitably will crumble beneath their own weight, eventually resulting in a new development effort.
On a theoretical front, when considering a software system with an ultimately flexible architecture, the possibilities are endless. Simply plugging new components into the system could easily accommodate changing requirements and scope creep. Older rules no longer supported could be dealt with by removing those components from the system. This Promised Land currently exists only in theory; pragmatically speaking, it is almost impossible to achieve, but that isn't to say that we shouldn't strive to achieve it. By putting forth the effort, we're assured of making it one step closer.
Taking this next step is not easy. It involves changes throughout the entire software development lifecycle. By utilizing today's best-of-breed technologies, methodologies, and principles, we can create the set of complementary tools to take our efforts to this next level. Using these complementary tools creates a development effort with an implicit system of checks and balances. These help ensure that our systems will, in fact, be more flexible and resilient to change.
In The Timeless Way of Building, Christopher Alexander discusses an aesthetically pleasing feeling associated with architecture called "The Quality Without a Name" [ALEXANDER79]. He describes various aspects of a garden, a storefront, or a room that create a feeling of warmth. The cause of this feeling can't be attributed to any singular aspect of the surroundings but is the result of how each atomic element works together to create this quality. This description can be applied to software architecture as well. In my discussions with students and clients, I often ask if they've had similar feelings when developing software. Most developers can remember when they've felt proud of their work. They see that the system is flexible, performs well, and is bug free. They have achieved "Quality Without a Name" in software development.
What This Book IsWith this book, we intend to provide solid insight into using the UML and object orientation to develop Java applications within the context of a well-defined software process. We concentrate on the most frequently used aspects of the UML, highlighting best practices of software process as we progress. Because this book is centered around the full lifecycle, various guidelines are presented that can help ensure adherence to the best practices of solid design.
It is highly unlikely that any organization can successfully adopt a technology overnight. With the rampant emergence of recent technologies such as Java, including Java 2 Enterprise Edition (J2EE), the UML, object orientation, and various software processes, an adoption strategy is critical to success. We discuss practices that can help ensure that a successful integration takes place.
Once integrated, however, proven practices must be adhered to. The object-oriented structure of our system, and the manner in which it is implemented, will contribute significantly to the success of our software. We also discuss many of the important decisions that development teams make when architecting object-oriented software.
In general, the intent is to emphasize the more significant elements of these technologies, while ignoring the elements that are less often employed. As such, this book serves as a guide through many of the most common and most significant decisions made on all software development efforts.Our approach to discussion is pragmatic. Discussions of theory take place only in situations where such discussion is warranted and where it can provide deeper insight.
What This Book Is NotThis book is not an exhaustive resource on UML syntax. Spending valuable time understanding the use of technologies in only a small percentage of application development is purely academic. Therefore, UML syntax is discussed only where it is warranted.
This book is not an in-depth study of all of the UML diagrams. We focus on those diagrams that are used most often in the development lifecycle and those that contribute most to application development. These diagrams often are incorporated into a development environment that is adopting the UML for the first time.
This book is not a comprehensive Java resource. A general understanding of Java syntax is assumed. While all examples use Java, and some of our discussions are specific to Java, an understanding of another object-oriented language most likely will suffice for those developers without an in-depth understanding of Java.
This book doesn't present a formal software development process. Instead, we glean best practices from a suite of proven software development processes. As such, while our discussion constantly considers process, we're not interested in a particular software development process, but instead those practices embodied within software processes that focus on success.
High-Level Book OrganizationThis book can be conceptually broken into two parts. The first four chapters present the UML, object-orientation, and software process as independent entities. This helps clarify the purpose and the value of each of the powerful technologies in an independent fashion. The remaining chapters emphasize convergence in a practical and example-laden manner. Our discussions in the latter chapters emphasize applying the concepts discussed in the first four chapters.
How to R