Rational Rose深度解析：UML建模与Rose工具实战

需积分: 9 110 浏览量更新于2024-07-18 收藏 7.59MB PDF 举报

"《Mastering UML with Rational Rose 2002》是一本详细介绍统一建模语言（UML）及其在Rational Rose工具中的应用的专业书籍。该书共分为两章，第一章深入浅出地介绍了UML的基础概念和原则，包括面向对象编程的基本特性如封装、继承和多态性，以及视觉建模的重要性。章节中详细探讨了UML的各种图示类型，如业务用例图、用例图、活动图、顺序图、协作图、类图、状态图、组件图和部署图，这些都是软件开发过程中用于描述系统结构和行为的关键图形表示。第二章则重点介绍Rational Rose这款工具，涵盖了如何使用Rose进行模型创建、导航和管理。内容包括Rose的简介，用户界面的不同部分，以及如何在四个主要视图（用例视图、逻辑视图、组件视图和部署视图）之间切换。书中还讲解了模型的创建、保存、导出导入、发布到网络以及与控制单元的工作，同时还涉及到模型集成器的使用、注释管理、包操作，以及如何添加文件、URL和自定义字体颜色等细节。通过阅读这本书，读者不仅可以掌握UML语言的核心原理，还能学会如何有效地利用Rational Rose这个工具进行软件开发项目的可视化设计和管理，这对于软件工程师和架构师来说是非常实用的参考资料。"

Chapter 1: Introduction to UML

The pace of business is getting faster and faster, with a greater need to compete and sustain a market. In this

age of e−commerce, e−business, e−tailing, and other e's, "traditional" system development just doesn't cut it

anymore. Systems now must be developed in "Internet time." Also, this faster pace has increased the need for

flexible systems. Before, a user could send a request to the data−processing center and wait two years for a

change. Now a user sends a request for change to the IT department and demands it in two weeks! Six−week

development cycles, demanding managers, demanding users, and even the concept of XP (extreme

programming) drive this point: System changes must happen fast!

This is where the Unified Modeling Language (UML) enters the picture. UML is the industry−standard

modeling notation for object−oriented systems, and is the premiere platform for rapid application

development. In this chapter, we describe how UML came into being, introduce the concepts of

object−oriented programming, and show you how to use UML to structure your applications.

•

Learning about the object−oriented paradigm and visual modeling

•

Exploring types of graphical notation

•

Looking at types of UML diagrams

•

Developing software using visual modeling

Introduction to the Object−Oriented Paradigm

Structured programming was the mainstream in the earlier days of software engineering. Programmers began

developing standard blocks of code to perform operations like printing, and then copied and pasted that code

into every application they wrote. While this reduced the development time for new applications, it was

difficult if a change was needed in that block of code, because the developer had to make the change

everywhere that code had been copied. Structured programming presented some challenges for which

object−oriented programming was designed to solve.

With object−oriented programming, developers create blocks of code, called objects. These objects are then

used by the various applications. Should one of the objects require modification, a developer needs to make

the change only once. Companies are rushing out to adopt this technology and integrate it into their existing

applications. In fact, most applications being developed today are object−oriented. Some languages, such as

Java, require an object−oriented structure. But what does it mean?

The object−oriented paradigm is a different way of viewing applications. With the object−oriented approach,

you divide an application into many small chunks, or objects, that are fairly independent of one another. You

can then build the application by piecing all of these objects together. Think of it as building a castle out of

blocks. The first step is to make or buy some basic objects, the different types of blocks. Once you have these

building blocks, you can put them together to make your castle. Once you build or buy some basic objects in

the computer world, you can simply put them together to create new applications.

In the world of structured programming, to create a form with a list box, for example, you would need to write

voluminous code: the code to create the form itself, the code to create and populate the list box, and the code

to create an OK button that will accept the value in the list box. With object−oriented programming, on the

other hand, you simply need to use three (typically prebuilt) objects: a form, a list box, and an OK button. The

exercise of coding used to be along the lines of "create from scratch, but copy whatever you can find from old

programs to save some time." The newer paradigm is "put together a bunch of objects, and then just focus on

what's unique to this particular application."

One of the primary advantages of the object−oriented paradigm is the ability to build components once and

then use them over and over again. Just as you can reuse a toy building block in a castle or a house, you can

reuse a basic piece of object−oriented design and code in an accounting system, an inventory system, or an

order−processing system.

So, how is this object−oriented paradigm different from the traditional approach to development?

Traditionally, the approach to development has been to concern ourselves with the information that the system

will maintain. With this approach, we ask the users what information they will need, design databases to hold

the information, provide screens to input the information, and print reports to display the information. In other

words, we focus on the information and pay less attention to what is done with the information or the behavior

of the system. This approach is called data−centric and has been used to create thousands of systems over the

years.

Data−centric modeling is great for database design and capturing information, but taking this approach when

designing business applications presents some problems. One major challenge is that the requirements for the

system will change over time. A system that is data−centric can handle a change to the database very easily,

but a change to the business rules or to the behavior of the system is not so easy to implement.

The object−oriented paradigm has been developed in response to this problem. With the object−oriented

approach, we focus on both information and behavior. Accordingly, we now can develop systems that are

resilient and flexible to changes in information and/or behavior.

The benefit of flexibility can be realized only by designing an object−oriented system well. This requires

knowledge of some principles of object orientation: encapsulation, inheritance, and polymorphism.

Encapsulation

In object−oriented systems, we combine a piece of information with the specific behavior that acts upon that

information. Then we package these into an object. This is referred to as encapsulation. Another way to look

at encapsulation is that we divide the application into small parts of related functionality. For example, we

have information relating to a bank account, such as the account number, balance, customer name, address,

account type, interest rate, and opening date. We also have behavior for a bank account: open, close, deposit,

withdraw, change type, change customer, and change address. We encapsulate this information and behavior

together into an account object. As a result, any changes to the banking system regarding accounts can simply

be implemented in the account object. It works like a one−stop shop for all account information and behavior.

Another benefit of encapsulation is that it limits the effects of changes to the system. Think of a system as a

body of water and the requirement change as a big rock. You drop the rock into the water

and—SPLASH!—big waves are created in all directions. They travel throughout the lake, bounce off the

shore, reverberate, and collide with other waves. In fact, some of the water may even splash over the shore

and out of the lake. In other words, the rock hitting the water caused a huge ripple effect. But if we

encapsulate our lake by dividing it into smaller bodies of water with barriers between them, then the

requirement change hits the system—SPLASH! As before, waves are created in all directions. But the waves

Chapter 1: Introduction to UML

can only go as far as one of the barriers, and then they stop. So, by encapsulating the lake, we have limited the

ripple effect of dropping the rock in, as shown in Figure 1.1.

Figure 1.1: Encapsulation: Lake model

Let's apply this idea of encapsulation to the banking system. Recently, the bank management decided that if

the customer has a credit account at the bank, the credit account could be used as an overdraft for their

checking account. In a nonencapsulated system, we begin with a shotgun approach to impact analysis.

Basically, we do not know where all of the uses of withdraw functionality are in the system, so we have to

look everywhere. When we find it, we have to make some changes to incorporate this new requirement. If

we're really good, we probably found about 80 percent of the uses of withdraw within the system. With an

encapsulated system, we do not need to use the shotgun approach to analysis. We look at a model of our

system and simply find where the withdrawal behavior was encapsulated. After locating the functionality in

the account, we make our requirement change once, only in that object, and our task is complete! As you can

see in Figure 1.2, only the Account class needs to change.

A concept similar to encapsulation is information hiding. Information hiding is the ability to hide the murky

details of an object from the outside world. To an object, the outside world means anything outside of itself,

even though that outside world includes the rest of the system. Information hiding provides the same benefit

as encapsulation: flexibility. We will explore this concept more in Chapter 6, "Classes and Packages."

Figure 1.2: Encapsulation: Banking model

Inheritance

Inheritance is the second of the fundamental object−oriented concepts. No, it has nothing to do with the

million dollars you're leaving for little Johnny. It has more to do with the nose you got from your father or

mother. In object−oriented systems, inheritance is a mechanism that lets you create new objects based on old

ones: The child object inherits the qualities of a parent object.

Chapter 1: Introduction to UML

You can see examples of inheritance in the natural world. There are hundreds of different types of mammals:

dogs, cats, humans, whales, and so on. Each of these has certain characteristics that are unique and certain

characteristics that are common to the whole group, such as having hair, being warm−blooded, and nurturing

their young. In object−oriented terms, there is a mammal object that holds the common characteristics. This

object is the parent of the child objects cat, dog, human, whale, etc. The dog object inherits the characteristics

of the mammal object, and has some additional dog characteristics of its own, such as running in circles and

slobbering. The object−oriented paradigm has borrowed this idea of inheritance from the natural world, as

shown in Figure 1.3, so we can apply the same concept to our systems.

Figure 1.3: Inheritance: Natural model

One of the major benefits of inheritance is ease of maintenance. When something changes that affects all

mammals, only the parent object needs to change—the child objects will automatically inherit the changes. If

mammals were suddenly to become cold−blooded, only the mammal object would need to change. The cat,

dog, human, whale, and other child objects would automatically inherit the new, cold−blooded characteristic

of mammals.

In an object−oriented system, an example of inheritance might be in the windows. Say we have a large system

with 125 windows. One day, a customer requests a disclaimer message on all of the windows. In a system

without inheritance, we now have the rather tedious task of going into each one of the 125 windows and

making the change. If our system were object−oriented, we would have inherited all of the windows from a

common parent. Now, all we need to do is go into the parent and make the change once. All of the windows

will automatically inherit the change, as shown in Figure 1.4.

Figure 1.4: Inheritance: Window model

In a banking system, we might use inheritance for the different types of accounts we have. Our hypothetical

bank has four different types of accounts: checking, savings, credit card, and certificates of deposit. These

different types of accounts have some similarities. Each one has an account number, interest rate, and owner.

So, we can create a parent object called account to hold the common characteristics of all the accounts. The

child objects can have their own unique characteristics in addition to the inherited ones. The credit account,

for example, will also have a credit limit and minimum payment amount. The certificate of deposit will also

have a maturity date. Changes to the parent will affect all children, but the children are free to adapt without

Chapter 1: Introduction to UML

disturbing each other or their parents.

Polymorphism

The third principle of object orientation is polymorphism. The dictionary defines it as the occurrence of

different forms, stages, or types. Polymorphism means having many forms or implementations of a particular

functionality. As with inheritance, polymorphism can be seen in the natural world. Given the command, or

function, of "Speak!" a human may reply, "How do you do?" The dog may reply "Woof!" The cat may reply

"Meow!" but will probably just ignore you.

In terms of an object−oriented system, this means that we can have many implementations of a particular

functionality. For example, we might be building a graphic drawing system. When the user wants to draw

something, be it a line, circle, or rectangle, the system issues a draw command. The system is comprised of

many types of shapes, each of which contains the behavior to draw itself. So, when the user wants to draw a

circle, the circle object's draw command is invoked. By using polymorphism, the system figures out as it is

running which type of shape is being drawn. Without polymorphism, the code for the draw function might

look like this:

Function Shape.drawMe()

{

SWITCH Shape.Type

Case "Circle"

Shape.drawCircle();

Case "Rectangle"

Shape.drawRectangle();

Case "Line"

Shape.drawLine();

END SWITCH

}

With polymorphism, the code for draw would just call a drawMe() function for the object being drawn, as in

this example:

Function draw()

{

Shape.drawMe();

}

Each shape (circle, line, rectangle, etc.) would then have a drawMe() function to draw the particular shape.

One of the benefits of polymorphism, as with the other principles of object orientation, is ease of maintenance.

What happens, for example, when the application now needs to draw a triangle? In the nonpolymorphic case,

a new drawTriangle() function has to be added to the shape object. Also, the drawMe() function of the shape

object has to be changed to accommodate the new type of shape. With polymorphism, we create a new

triangle object with a drawMe() function to draw itself. The draw() function that initiates the drawing

operation does not have to change at all.

What Is Visual Modeling?

If you were building a new addition to your house, you probably wouldn't start by just buying a bunch of

wood and nailing it together until it looks about right. Similarly, you'd be more than a little concerned if the

Chapter 1: Introduction to UML

剩余713页未读，继续阅读

qq_1144521901

粉丝: 168
资源: 9

Rational Rose深度解析：UML建模与Rose工具实战

mastering uml with rational rose 2002

UML和Rational Rose

UML with Rational Rose入门到精通

SYBEX - Mastering UML with Rational Rose

mastering opencv with practical projects源码

mastering ui development with unity

mastering gui programming with python

mastering concurrency programming with java 8

mastering go 2 pdf

mastering docker 4 pdf

最新资源