UML入门实践指南：类图、顺序图和开发过程

UML

需积分: 22 47 浏览量更新于2024-07-27 收藏 1.71MB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

UML Distilled UML（Unified Modeling Language）是一种标准化的建模语言，用于描述软件系统的结构、行为和组织。它提供了一种通用的语言和符号集，用于描述软件系统的各个方面，从需求分析到系统设计和实现。 **Derived Properties** Derived Properties 是一种特殊类型的属性，它可以根据其他值计算而来。这种属性通常是通过其他值计算而来的，而不是存储在数据库中的固定值。例如，在一个订单系统中，订单的总金额可以根据订单中的商品价格和数量计算而来，而不是存储在数据库中的固定值。在 UML 中，Derived Properties 通常用斜线（/）标记，以区别于存储的值。这种标记方式可以帮助人们区分计算值和存储值，并提醒人们注意约束关系。 **Interfaces and Abstract Classes** Interfaces 和 Abstract Classes 是 UML 中的两种重要概念。Interfaces 定义了一组方法的签名，而不提供方法的实现。Abstract Classes 则提供了一些基本的方法实现，但需要子类来继承和实现。 Interfaces 通常用于定义一组方法的签名，以便其他类可以实现这些方法。Abstract Classes 则用于提供一些基本的方法实现，以便子类可以继承和扩展。 **UML Diagrams** UML 提供了多种类型的图表，包括类图、序列图、状态图、活动图、用例图等。这些图表可以用于描述软件系统的不同方面，从需求分析到系统设计和实现。在本书中，我们将介绍 UML 的基本概念和应用，包括类图、序列图、状态图等。我们还将讨论 UML 在软件开发过程中的应用，包括需求分析、系统设计、实现和测试等。 **Why Bother with the UML?** UML 提供了一种通用的语言和符号集，用于描述软件系统的各个方面。它可以帮助人们更好地理解和交流软件系统的设计和实现。UML 也可以帮助人们识别和解决软件系统中的问题，例如性能问题、可扩展性问题等。 **Structure of the Book** 本书共分为 118 页，包括前言、序言、 Preface、 Acknowledgments 等。书中还包括多个章节，包括介绍 UML 的基本概念、类图、序列图、状态图等。 **Changes for the Third Edition** 本书的第三版进行了多方面的更新和改进，包括更新了 UML 的最新标准、添加了新的内容、改进了书中的例子等。 **Acknowledgments** 我们感谢所有参与本书编写和编辑的人员，感谢他们的辛勤工作和贡献。

资源详情

资源推荐

16/118

In contrast, UML as blueprint is about completeness. In forward engineering, the idea is that

blueprints are developed by a designer whose job is to build a detailed design for a programmer to

code up. That design should be sufficiently complete in that all design decisions are laid out, and the

programmer should be able to follow it as a pretty straightforward activity that requires little

thought. The designer may be the same person as the programmer, but usually the designer is a

more senior developer who designs for a team of programmers. The inspiration for this approach is

other forms of engineering in which professional engineers create engineering drawings that are

handed over to construction companies to build.

Blueprinting may be used for all details, or a designer may draw blueprints to a particular area. A

common approach is for a designer to develop blueprint-level models as far as interfaces of

subsystems but then let developers work out the details of implementing those details.

In reverse engineering, blueprints aim to convey detailed information about the code either in paper

documents or as an interactive graphical browser. The blueprints can show every detail about a

class in a graphical form that's easier for developers to understand.

Blueprints require much more sophisticated tools than sketches do in order to handle the details

required for the task. Specialized CASE (computer-aided software engineering) tools fall into this

category, although the term CASE has become a dirty word, and vendors try to avoid it now.

Forward-engineering tools support diagram drawing and back it up with a repository to hold the

information. Reverse-engineering tools read source code and interpret from it into the repository

and generate diagrams. Tools that can do both forward and reverse engineering like this are

referred to as round-trip tools.

Some tools use the source code itself as the repository and use diagrams as a graphic viewport on

the code. These tools tie much more closely into programming and often integrate directly with

programming editors. I like to think of these as tripless tools.

The line between blueprints and sketches is somewhat blurry, but the distinction, I think, rests on

the fact that sketches are deliberately incomplete, highlighting important information, while

blueprints intend to be comprehensive, often with the aim of reducing programming to a simple and

fairly mechanical activity. In a sound bite, I'd say that sketches are explorative, while blueprints are

definitive.

As you do more and more in the UML and the programming gets increasingly mechanical, it

becomes obvious that the programming should be automated. Indeed, many CASE tools do some

form of code generation, which automates building a significant part of a system. Eventually,

however, you reach the point at which all the system can be specified in the UML, and you reach

UML as programming language. In this environment, developers draw UML diagrams that are

compiled directly to executable code, and the UML becomes the source code. Obviously, this usage

of UML demands particularly sophisticated tooling. (Also, the notions of forward and reverse

engineering don't make any sense for this mode, as the UML and source code are the same thing.)

Model Driven Arquitecture and Executable UML

When people talk about the UML, they also often talk about Model Driven Architecture

(MDA) [Kleppe et al.]. Essentially, MDA is a standard approach to using the UML as a

programming language; the standard is controlled by the OMG, as is the UML. By

producing a modeling environment that conforms to the MDA, vendors can create models

that can also work with other MDA-compliant environments.

MDA is often talked about in the same breath as the UML because MDA uses the UML as

its basic modeling language. But, of course, you don't have to be using MDA to use the

UML.

MDA divides development work into two main areas. Modelers represent a particular

application by creating a Platform Independent Model (PIM). The PIM is a UML model

that is independent of any particular technology. Tools can then turn a PIM into a

Platform Specific Model (PSM). The PSM is a model of a system targeted to a specific

17/118

execution environment. Further tools then take the PSM and generate code for that

platform. The PSM could be UML but doesn't have to be.

So if you want to build a warehousing system using MDA, you would start by creating a

single PIM of your warehousing system. If you then wanted this warehousing system to

run on J2EE and .NET, you would use some vendor tools to create two PSMs: one for each

platform. Then further tools would generate code for the two platforms.

If the process of going from PIM to PSM to final code is completely automated, we have

the UML as programming language. If any of the steps is manual, we have blueprints.

Steve Mellor has long been active in this kind of work and has recently used the term

Executable UML [Mellor and Balcer]. Executable UML is similar to MDA but uses slightly

different terms. Similarly, you begin with a platform-independent model that is equivalent

to MDA's PIM. However, the next step is to use a Model Compiler to turn that UML model

into a deployable system in a single step; hence, there's no need for the PSM. As the term

compiler suggests, this step is completely automatic.

The model compilers are based on reusable archetypes. An archetype describes how to

take an executable UML model and turn it into a particular programming platform. So for

the warehousing example, you would buy a model compiler and two archetypes (J2EE and

.NET). Run each archetype on your executable UML model, and you have your two

versions of the warehousing system.

Executable UML does not use the full UML standard; many constructs of UML are

considered to be unnecessary and are therefore not used. As a result, Executable UML is

simpler than full UML.

All this sounds good, but how realistic is it? In my view, there are two issues here. First is

the question of the tools: whether they are mature enough to do the job. This is

something that changes over time; certainly,

as I write this, they aren't widely used, and I

haven't seen much of them in action.

A more fundamental issue is the whole notion of the UML as a programming language. In

my view, it's worth using the UML as a programming language only if it results in

something that's significantly more productive than using another programming language.

I'm not convinced that it is, based on various graphical development environments I've

worked with in the past. Even if it is more productive, it still needs to get a cri

tical mass of

users for it to make the mainstream. That's a big hurdle in itself. Like many old

Smalltalkers, I consider Smalltalk to be much more productive than current mainstream

languages. But as Smalltalk is now only a niche language, I don't see many projects using

it. To avoid Smalltalk's fate, the UML has to be luckier, even if it is superior.

One of the interesting questions around the UML as programming language is how to model

behavioral logic. UML 2 offers three ways of behavioral modeling: interaction diagrams, state

diagrams, and activity diagrams. All have their proponents for programming in. If the UML does gain

popularity as a programming language, it will be interesting to see which of these techniques

become successful.

Another way in which people look at the UML is the range between using it for conceptual and for

software modeling. Most people are familiar with the UML used for software modeling. In this

software perspective, the elements of the UML map pretty directly to elements in a software

system. As we shall see, the mapping is by no means prescriptive, but when we use the UML, we

are talking about software elements.

With the conceptual perspective, the UML represents a description of the concepts of a domain of

study. Here, we aren't talking about software elements so much as we are building a vocabulary to

talk about a particular domain.

18/118

There are no hard-and-fast rules about perspective; as it turns out, there's really quite a large range

of usage. Some tools automatically turn source code into the UML diagrams, treating the UML as an

alternative view of the source. That's very much a software perspective. If you use UML diagrams to

try and understand the various meanings of the terms asset pool with a bunch of accountants, you

are in a much more conceptual frame of mind.

In previous editions of this book, I split the software perspective into specification (interface) and

implementation. In practice, I found that it was too hard to draw a precise line between the two, so

I feel that the distinction is no longer worth making a fuss about. However, I'm always inclined to

emphasize interface rather than implementation in my diagrams.

These different ways of using the UML lead to a host of arguments about what UML diagrams mean

and what their relationship is to the rest of the world. In particular, it affects the relationship

between the UML and source code. Some people hold the view that the UML should be used to

create a design that is independent of the programming language that's used for implementation.

Others believe that language-independent design is an oxymoron, with a strong emphasis on the

moron.

Another difference in viewpoints is what the essence of the UML is. In my view, most users of the

UML, particularly sketchers, see the essence of the UML to be the diagrams. However, the creators

of the UML see the diagrams as secondary; the essence of the UML is the meta-model. Diagrams are

simply a presentation of the meta-model. This view also makes sense to blueprinters and UML

programming language users.

So whenever you read anything involving the UML, it's important to understand the point of view of

the author. Only then can you make sense of the often fierce arguments that the UML encourages.

Having said all that, I need to make my biases clear. Almost all the time, my use of the UML is as

sketches. I find the UML sketches useful with forward and reverse engineering and in both

conceptual and software perspectives.

I'm not a fan of detailed forward-engineered blueprints; I believe that it's too difficult to do well and

slows down a development effort. Blueprinting to a level of subsystem interfaces is reasonable, but

even then you should expect to change those interfaces as developers implement the interactions

across the interface. The value of reverse-engineered blueprints is dependent on how the tool

works. If it's used as a dynamic browser, it can be very helpful; if it generates a large document, all

it does is kill trees.

I see the UML as programming language as a nice idea but doubt that it will ever see significant

usage. I'm not convinced that graphical forms are more productive than textual forms for most

programming tasks and that even if they are, it's very difficult for a language to be widely accepted.

As a result of my biases, this book focuses much more on using the UML for sketching. Fortunately,

this makes sense for a brief guide. I can't do justice to the UML in its other modes in a book this

size, but a book this size makes a good introduction to other books that can. So if you're interested

in the UML in its other modes, I'd suggest that you treat this book as an introduction and move on

to other books as you need them. If you're interested only in sketches, this book may well be all you

need.

How We Got to the UML

I'll admit, I'm a history buff. My favorite idea of light reading is a good history book. But I also know

that it's not everybody's idea of fun. I talk about history here because I think that in many ways, it's

hard to understand where the UML is without understanding the history of how it got here.

19/118

In the 1980s, objects began to move away from the research labs and took their first steps toward

the "real" world. Smalltalk stabilized into a platform that people could use, and C++ was born. At

that time, various people started thinking about object-oriented graphical design languages.

The key books about object-oriented graphical modeling languages appeared between 1988 and

1992. Leading figures included Grady Booch [Booch, OOAD]; Peter Coad [Coad, OOA], [Coad,

OOD]; Ivar Jacobson (Objectory) [Jacobson, OOSE]; Jim Odell [Odell]; Jim Rumbaugh (OMT)

[Rumbaugh, insights], [Rumbaugh, OMT]; Sally Shlaer and Steve Mellor [Shlaer and Mellor, data],

[Shlaer and Mellor, states]; and Rebecca Wirfs-Brock (Responsibility Driven Design) [Wirfs-Brock].

Each of those authors was now informally leading a group of practitioners who liked those ideas. All

these methods were very similar, yet they contained a number of often annoying minor differences

among them. The same basic concepts would appear in very different notations, which caused

confusion to my clients.

During that heady time, standardization was as talked about as it was ignored. A team from the

OMG tried to look at standardization but got only an open letter of protest from all the key

methodologists. (This reminds me of an old joke. Question: What is the difference between a

methodologist and a terrorist? Answer: You can negotiate with a terrorist.)

The cataclysmic event that first initiated the UML was when Jim Rumbaugh left GE to join Grady

Booch at Rational (now a part of IBM). The Booch/Rumbaugh alliance was seen from the beginning

as one that could get a critical mass of market share. Grady and Jim proclaimed that "the methods

war is over we won," basically declaring that they were going to achieve standardization "the

Microsoft way." A number of other methodologists suggested forming an Anti-Booch Coalition.

By OOPSLA '95, Grady and Jim had prepared their first public description of their merged method:

version 0.8 of the Unified Method documentation. Even more significant, they announced that

Rational Software had bought Objectory and that therefore, Ivar Jacobson would be joining the

Unified team. Rational held a well-attended party to celebrate the release of the 0.8 draft. (The

highlight of the party was the first public display of Jim Rumbaugh's singing; we all hope it's also the

last.)

The next year saw a more open process emerge. The OMG, which had mostly stood on the sidelines,

now took an active role. Rational had to incorporate Ivar's ideas and also spent time with other

partners. More important, the OMG decided to take a major role.

At this point, it's important to realize why the OMG got involved. Methodologists, like book authors,

like to think that they are important. But I don't think that the screams of book authors would even

be heard by the OMG. What got the OMG involved were the screams of tools vendors, all of which

were frightened that a standard controlled by Rational would give Rational tools an unfair

competitive advantage. As a result, the vendors energized the OMG to do something about it, under

the banner of CASE tool interoperability. This banner was important, as the OMG was all about

interoperability. The idea was to create a UML that would allow CASE tools to freely exchange

models.

Mary Loomis and Jim Odell chaired the initial task force. Odell made it clear that he was prepared to

give up his method to a standard, but he did not want a Rational-imposed standard. In January

1997, various organizations submitted proposals for a methods standard to facilitate the interchange

of models. Rational collaborated with a number of other organizations and released version 1.0 of

the UML documentation as their proposal, the first animal to answer to the name Unified Modeling

Language.

Then followed a short period of arm twisting while the various proposals were merged. The OMG

adopted the resulting 1.1 as an official OMG standard. Some revisions were made later on. Revision

1.2 was entirely cosmetic. Revision 1.3 was more significant. Revision 1.4 added a number of

detailed concepts around components and profiles. Revision 1.5 added action semantics.

When people talk about the UML, they credit mainly Grady Booch, Ivar Jacobson, and Jim

Rumbaugh as its creators. They are generally referred to as the Three Amigos, although wags like to

20/118

drop the first syllable of the second word. Although they are most credited with the UML, I think it

somewhat unfair to give them the dominant credit. The UML notation was first formed in the

Booch/Rumbaugh Unified Method. Since then, much of the work has been led by OMG committees.

During these later stages, Jim Rumbaugh is the only one of the three to have made a heavy

commitment. My view is that it's these members of the UML committee process that deserve the

principal credit for the UML.

Notations and Meta-Models

The UML, in its current state, defines a notation and a meta-model. The notation is the graphical

stuff you see in models; it is the graphical syntax of the modeling language. For instance, class

diagram notation defines how items and concepts, such as class, association, and multiplicity, are

represented.

Of course, this leads to the question of what exactly is meant by an association or multiplicity or

even a class. Common usage suggests some informal definitions, but many people want more rigor

than that.

The idea of rigorous specification and design languages is most prevalent in the field of formal

methods. In such techniques, designs and specifications are represented using some derivative of

predicate calculus. Such definitions are mathematically rigorous and allow no ambiguity. However,

the value of these definitions is by no means universal. Even if you can prove that a program

satisfies a mathematical specification, there is no way to prove that the mathematical specification

meets the real requirements of the system.

Most graphical modeling languages have very little rigor; their notation appeals to intuition rather

than to formal definition. On the whole, this does not seem to have done much harm. These

methods may be informal, but many people still find them useful—and it is usefulness that counts.

However, methodologists are looking for ways to improve the rigor of methods without sacrificing

their usefulness. One way to do this is to define a meta-model: a diagram, usually a class diagram,

that defines the concepts of the language.

Figure 1.1, a small piece of the UML meta-model, shows the relationship among features. (The

extract is there to give you a flavor of what meta-models are like. I'm not even going to try to

explain it.)

Figure 1.1. A small piece of the UML meta-model

剩余117页未读，继续阅读

susan93171

粉丝: 3
资源: 27

UML入门实践指南：类图、顺序图和开发过程

UML精华UML Distilled, 3rd Ed (Martin Fowler - Addison Wesle

UML distilled.pdf

UML Distilled（UML精华）-3rd-（英文版&繁体中文版）

uml distilled中文 pdf

uml distilled 3rd 是什么

软件设计中的抽象能力有哪些参考资料可以提高

__all__ = [ 'deit_tiny_patch16_224', 'deit_small_patch16_224', 'deit_base_patch16_224', 'deit_tiny_distilled_patch16_224', 'deit_small_distilled_patch16_224', 'deit_base_distilled_patch16_224', 'deit_base_patch16_384', 'deit_base_distilled_patch16_384', ]

vit-pytorch 分类

如何关闭reader

怎么再yolov7添加知识蒸馏

vision transformer衍生模型

视觉注意力机制预训练模型

纯数据库设计的参考文献

transformer视觉

数据库参考文献萨师煊

transformer vit

最新资源

all = [ 'deit_tiny_patch16_224', 'deit_small_patch16_224', 'deit_base_patch16_224', 'deit_tiny_distilled_patch16_224', 'deit_small_distilled_patch16_224', 'deit_base_distilled_patch16_224', 'deit_base_patch16_384', 'deit_base_distilled_patch16_384', ]