UML与Java面向对象设计指南

4星 · 超过85%的资源需积分: 25 146 浏览量更新于2024-08-01 收藏 5.18MB PDF 举报

"Object Oriented Design with UML and Java" 是一本由Kenneth Barclay和John Savage合著的书籍，专注于面向对象设计与UML及Java编程的结合应用。该书以PDF格式提供，共320页，用英文撰写，属于面向对象、UML和JAVA开发领域的教材。此书由Butterworth-Heinemann出版社出版，ISBN号为0750660988。在面向对象设计领域，这本书深入探讨了如何利用统一建模语言（UML）来系统地设计和规划软件项目。UML是一种标准的建模语言，它为软件开发提供了图形化的表示方法，包括类图、序列图、状态图等，帮助开发者理解和表达复杂系统的结构和行为。书中可能涵盖了以下知识点： 1. **面向对象原则**：讲解封装、继承、多态等面向对象编程的基本概念，以及它们在实际设计中的应用。 2. **类与对象**：解释如何通过定义类来抽象现实世界中的实体，并创建和操作对象。 3. **UML基础**：介绍UML的各个图表，如用例图、类图、序列图、协作图和状态图，以及如何使用这些图表进行系统建模。 4. **设计模式**：可能讨论了一些常见的设计模式，如工厂模式、单例模式、观察者模式等，以及它们在Java编程中的实现。 5. **包与模块化**：探讨如何使用包来组织代码，以及模块化的优点和最佳实践。 6. **接口与抽象类**：解释接口和抽象类在Java中的角色，以及它们如何促进代码的可扩展性和重用性。 7. **Java编程基础**：涵盖Java语言的关键特性，如异常处理、IO流、多线程、集合框架等。 8. **测试与调试**：可能介绍了单元测试、集成测试的重要性，以及如何使用JUnit等工具进行测试。 9. **实例分析**：通过实际的案例研究，展示如何将UML与Java结合起来进行完整的系统设计和开发。 10. **最佳实践**：提供面向对象设计和Java编程的建议，以及在实际项目中应遵循的最佳实践。这本书对于希望提升面向对象设计技能，尤其是结合UML和Java的开发者来说，是一份宝贵的学习资料。它不仅理论丰富，还可能包含大量实例和练习，以帮助读者更好地理解和应用所学知识。通过阅读和实践，读者可以学习到如何用更系统化的方法来规划和构建软件项目。

Object Technology

This book is concerned with Object-Oriented Design, the Uniﬁed Modelling Language

(UML) and the Java Programming Language. It seeks to demonstrate that a Java appli-

cation, no matter how small, can beneﬁt from some design during its construction.

Various aspects of that design are captured and documented with the UML.

In this book we are primarily concerned with the middle ground between object-

oriented design and implementation. Many textbooks exist that are solely concerned

with the Java programming language (see the bibliography). These books give little or no

explicit consideration to the question of design. A much smaller number of analysis and

design books have been published. They often say little on the matter of realizing their

designs. Here, we seek to offer a bridge between the two.

The beneﬁt from this approach is that there is a signiﬁcant shift of emphasis away

from detailed programming issues on to the higher ground of analysing the meaning

and accuracy of the design. Further, as mappings from the design to the implementation

language are established, we recognize emerging and repeated patterns and conse-

quently much of the programming activity often collapses into a coding chore.

This introductory chapter offers a roadmap into the remainder of the book. Here, we

present the essence of object-oriented computing, and provide the necessary introduc-

tory background. We examine the fundamentals of object-oriented computing includ-

ing modelling, analysis, design and implementation. The concepts are framed around

everyday illustrations in which we concentrate on introducing the vocabulary of object-

oriented systems.

Computer technology has developed extremely quickly since its inception. Today,

computer-based systems impact on much of our lives in many spheres including bank-

ing, medical, ﬂight reservation, educational and military applications. They are distin-

guished by having large amounts of software at their core. The capabilities of these

systems are derived from the complex computer programs that control them.

Although we better understand the process of developing computer software, we fre-

quently deliver it late and over budget. Often the software fails to do what the user

requires and is difﬁcult to maintain and modify. These remarks have always applied to

the computer software industry, and while we have improved the technologies to sup-

port the development process, they have not fully matched the size and complexity of

contemporary systems. Object technology is considered the best to deliver on these

challenges, offering us the means to improve application development, reliability and

scalability.

1.1 Background

During the 1990s object technology entered the mainstream computing landscape. The

two primary fronts were in programming languages and in the introduction of object-

oriented methods. The development of object-oriented methods was the subject of

much research by both organizations and individuals. Notable leaders include Grady

Booch (Booch 1991) and Jim Rumbaugh (Rumbaugh 1991). The various approaches

promoted by these and others each had some merit but also had the effect of fragment-

ing the industry.

In the mid-1990s Booch and then Rumbaugh, and later Ivor Jacobson, formed the

Rational organization (http://www.Rational.com). The aim was to combine their indi-

vidual approaches and the contributions of others. Their efforts were offered for public

scrutiny, thereby obtaining industry acceptance for a single uniﬁed object-oriented (OO)

notation. It offers a means for capturing and recording the various elements of an

object-oriented analysis and design (OOAD). During the late 1990s Rational published

a number of versions of the UML. Subsequently in 1997 the Object Management Group

(OMG) approved the UML as a vendor-neutral standard.

1.1.1 Modelling

In the same manner that an architect’s blueprint presents design details for a building,

the UML allows software models to be constructed, viewed and manipulated during

analysis and design. Modelling is a proven technique used in a variety of disciplines.

For example, engineering models are used in the design and development of motor cars

(automobile engineering), aeroplanes (aero-engineering) and bridges (civil engineer-

ing). Similarly, meteorologists have developed mathematical models to predict weather

patterns.

Models are central to many human activities. They provide a blueprint for some arte-

fact we wish to manufacture or understand. A blueprint offers a measure of repeatabil-

ity ensuring standardization of the product. This is as equally important to the software

customer as it is to a customer purchasing, say, household goods such as a television or

a washing machine.

Through a model we aim to provide a better understanding of the system under devel-

opment. Models aid our understanding of especially complex systems and help ensure

we have correctly interpreted the system under development. For example, automobile

engineers use models to design new motor cars that meet a number of criteria including

their aerodynamics. The cars can be prototyped in ﬁbreglass and tested in wind tunnels.

A similar argument can be applied to software development whereby a model can be

used to ensure all its requirements are met.

A model also permits us to evaluate our design against criteria such as safety or ﬂexi-

bility. Similarly, UML models permit an application’s design to be evaluated and cri-

tiqued before implementation. Changes are much easier and less expensive to make

when they are made in the early phases of the software lifecycle.

Models help us capture and record our software design decisions as we progress

toward an implementation. This proves to be an important communications vehicle

2 Object-Oriented Design with UML and Java

between the development team members as well as between them and the customer.

Development team members can discuss their designs with the client to ensure they

have fully understood his needs.

Models can be layered and hence provide varying levels of detail. Abstract software

models omit large amounts of ﬁne-grained detail and permit us to gain a high-level

view of the system and its architecture. These views permit us to focus on various parts

of the system without recourse to the details of program code. Repeated reﬁnement of

these models can be used to progress them toward the ﬁnal code.

An architect when designing a building often constructs a number of diagrams that

present it from a variety of perspectives. One view is, of course, the structure of the

building and is vital to the construction company. This same view is also important to

the customer since it reveals the details of the accommodation, its layout and the access

to stairs, elevators, etc. However, electrical (or plumbing) contractors are more inter-

ested in the run of electrical circuits (water supplies and drainage pipes) and their sup-

ply to the building from the utility companies. Hence an architect would construct a

number of blueprints highlighting these various facets.

In a similar manner, the software architect can offer a range of UML diagrams that

view the system from different perspectives. Some give a static view of the application

with the architectural conﬁguration of the objects as the primary focus. Other UML

models emphasize the dynamic behaviour of the objects and their interactions.

1.1.2 UML

The UML deﬁnes a diagrammatic notation for describing the artefacts of an OOAD.

Through the UML we can visualize, specify, construct and document our software appli-

cation. As our software systems become ever larger and ever more complex we need

to manage that complexity and, in a sense, simplify it so we have a better understanding

of it. Often, visualizing the software graphically is more appropriate than struggling to

understand it in program code.

By inspecting our models we can identify deﬁciencies in our designs as well as

opportunities to enhance them. The UML acts as a speciﬁcation language in which we

can precisely and unambiguously capture our design decisions.

Finally, from our UML diagrams we can derive programming language code. This is

referred to as forward engineering — the generation of code from UML models. This

is an approach we advocate through this textbook. The models are at the core of our

designs. The code is an outcome of that modelling activity and is itself a design docu-

ment. The models dictate the code that we ultimately produce.

1.1.3 Analysis and design models

An analysis model used in software development aims to document various facets of

the real world problem that we are modelling. In an object-oriented system develop-

ment this would typically involve identifying the signiﬁcant application objects and the

application processing to be performed.

Chapter 1: Object Technology 3

Development methods that pre-dated object technology often deliberately delineated

between the analysis phase and the design stage. Commonly, they would also use a

linear or waterfall model for the development process in which the design stage only

follows after all the analysis has been completed. Further, these separate analysis

and design stages often resulted in a conﬂict between them, especially where different

models and notations were deployed.

Object-oriented methods are characterized by using the same modelling concepts

throughout the software lifecycle. This way, the solution that emerges during analysis is

carried through into design and ﬁnally to code. Objects identiﬁed during analysis should

also be present in the ﬁnal code. This offers a seamless integration of the stages, not

otherwise found with other approaches. The design models augment the analysis models

with additional detail and, perhaps, introduce further low-level system objects required

in the implementation.

1.1.4 Development process

The UML is a modelling language. It has no notion of a development process, which

must accompany a method. The dictionary deﬁnes a method as a systematic or orderly

procedure. The authors of the UML understood this distinction and deliberately sought

to separate the language used to document a software design from the process used to

develop it. They recognized that processes are inﬂuenced by many considerations such

as the nature of projects and the culture of organizations.

Object-oriented design is usually conducted within an iterative process. This is vital

to ensure that we can revisit earlier decisions when corrections or modiﬁcations are

necessary. This is not unreasonable. After all, initial design decisions may require revi-

sion, especially in new projects or in those that are less well understood by the devel-

opment team. The iterative process continues until the full system is developed.

In common with many object-oriented developers, an iterative process is also accom-

panied by an incremental style of development. Each increment introduces some

additional functionality on to the previous stage. Often, the new increment only adds a

small feature so that we can fully test it and its effect on the existing system and its

architecture.

Each iteration needs to be accompanied by an objective that can be checked.

Otherwise, there is a danger of the process degenerating into undisciplined hacking.

An iterative approach is further enhanced when the customer is closely involved in the

system development. Each new iteration can be presented to the customer to obtain

feedback and to ensure his active participation throughout the project.

1.2 Using the UML

The next chapter presents a detailed discussion of the UML. Here, we simply consolidate

our earlier discussions by considering the more important elements of an object-oriented

software system. This will act as an introduction to the more detailed discussions that

follow.

4 Object-Oriented Design with UML and Java

1.2.1 Objects: combined services and data

An object-oriented system comprises a number of software objects that interact to

achieve the system objective. The software objects usually mimic the real-world objects

of the application domain. The real-world objects may have a physical presence or may

represent some well-understood conceptual entity in the application. For example, in a

university application we might have software objects that represent students. Equally,

we may have software objects representing programmes of study at a university even

though they have no physical existence.

Objects are characterized by having both state and behaviour. The state of an object

is the information an object has about itself. For example, a student object may have a

name, a date of birth and a university matriculation number. Equally, a programme of

study object might have the name of the programme, its duration and the name of the

programme leader. The behaviour of an object describes the actions the object is pre-

pared to engage in. For example, we might ask a programme of study object for its dur-

ation. We might ask a student object for its age. This would involve the student object

performing a calculation based on its date of birth and today’s date.

The behaviour of an object is described by the set of operations it is prepared to per-

form. One object interacts with another by asking it to perform one of its advertised

operations. This interaction is achieved by one object sending a message to another. The

ﬁrst object is known as the sender object and the second object is known as the receiver

or recipient object. The only messages an object can receive belong to the set of oper-

ations it can accept. In the UML, objects and message passing are usually captured by a

sequence diagram as shown in ﬁgure 1.1. Here a university object is shown sending the

message getAge to a student object.

Chapter 1: Object Technology 5

: University

: Student

getAge

Figure 1.1 Message passing in a sequence diagram

When an object receives a message it performs some action. This action is described

by a method. A method is the processes the receiving object follows when servicing the

message. For example, if a university object sends a message to a student object asking

for its name, then the student object simply replies to the sender with one part of its

state, namely, the name. However, if a university object sends a student object the mes-

sage asking for its age, then the method that student object must follow is more elab-

orate. First, it must obtain today’s date. This might be achieved by the student object

剩余416页未读，继续阅读

xiongming1107

粉丝: 2

UML与Java面向对象设计指南

UML for Java Developers: Mastering Object-Oriented Design

"深入理解UML面向对象分析与设计的设计机制

"深入理解 UML 面向对象分析和设计：运行时架构掌握要点

Object Oriented Design with Java and UML.rar

Object Oriented Design with Java, C++ and UML

Practical Object-Oriented Design With UML - McGraw-Hil

Object Oriented Analysis and Design With UML 2.0

Mastering Object-Oriented Analysis and Design with UML

Mastering Object-Oriented Analysis and Design with UML 2.0

Object-Oriented Analysis and Design with UML 双语课件

最新资源