UML_Tutorial.rar_uml_umltutorial_使用UML资源-CSDN文库

共1个文件

pdf：1个

版权申诉

使用uml

5 浏览量 2022-09-20 14:27:04 上传评论收藏 691KB RAR 举报

资源推荐

资源详情

资源评论

收起资源包目录

UML_Tutorial.rar （1个子文件）

UML Tutorial.pdf 749KB

Contacts: Ian Graham or Alan Wills +44-161-225 3240; clive@trireme.com

UML – a tutorial

UML – a tutorial.....................................................................................................1

1 The history of object-oriented analysis and design methods.............................2

2 Software engineering ......................................................................................7

2.1 Responsibility-driven versus data-driven approaches ..............................12

2.2 Translational versus elaborational approaches........................................13

3 Object-oriented analysis and design using UML............................................13

3.1 Types and classes ....................................................................................13

3.1 Object structures.....................................................................................18

3.2 Using use cases to discover types............................................................28

3.3 Invariants and rulesets............................................................................35

3.4 Invariants and encapsulation ..................................................................43

3.5 State models...........................................................................................45

3.6 Moving to component design..................................................................48

3.8 The design process .................................................................................55

3.9 Documenting models..............................................................................57

3.10 Real-time extensions.............................................................................58

4 Identifying objects.........................................................................................60

4.2 Task analysis...........................................................................................65

4.3 Kelly grids...............................................................................................68

5 CASE tools...................................................................................................71

6 Patterns, architecture and decoupled design ..................................................73

6.1 Design patterns for decoupling ................................................................87

7 Designing components..................................................................................97

7.1 Components for flexibility....................................................................100

7.2 Large-scale connectors .........................................................................101

7.3 Mapping the business model to the implementation..............................103

8 Notation summary.......................................................................................105

8.1 Object modelling symbols.....................................................................105

8.2 Action (use case) modelling symbols........................................................110

8.3 Sequence and collaboration diagram symbols..........................................110

8.4 State modelling symbols...........................................................................112

8.5 Action or activity diagram symbols ..........................................................114

8.6 Implementation and component modelling symbols .................................115

8.7 Collaborations and patterns......................................................................116

8.8 Real-time notation: ports and connectors..................................................116

9 Further reading...........................................................................................117

10 Exercises...................................................................................................118

UML is the international standard notation for object-oriented analysis and design.

It is defined by the Object Management Group (www.omg.org

) and is currently at

Contacts: Ian Graham or Alan Wills +44-161-225 3240; clive@trireme.com

release 1.4 with 2.0 expected next year. UML provides several notations which are

described in detail in Ian Graham's Object-Oriented Methods (Addison-Wesley,

2001); Chapters 1, 6 and 7 give a detailed coverage of object-oriented analysis and

design using UML and Catalysis. This tutorial is based on it.

UML is a sound basis for object-oriented methods including those that apply to

component based development. One such method is Catalysis which is described

elsewhere on this site. To buy the book click here

This tutorial focuses both on the widely used UML notation and upon the

principles of modelling. Our treatment is particularly based on Catalysis (D’Souza

and Wills, 1999) and SOMA (Graham, 1995). The focus is on best practice and we

suggest a set of requirements for a practical analysis and design technique.

We introduce and explain the Unified Modelling Language (UML). UML is a

standardized notation for object-oriented analysis and design. However, a method is

more than a notation. To be an analysis or design method it must include

guidelines for using the notation and methodological principles. To be a complete

software engineering method it must also include procedures for dealing with

matters outside the scope of mere software development: business and requirements

modelling, development process, project management, metrics, traceability

techniques and reuse management. In this tutorial we focus on the notational and

analysis and design aspects.

1 The history of object-oriented analysis and design methods

The development of computer science as a whole proceeded from an initial concern

with programming alone, through increasing interest in design, to concern with

analysis methods only latterly. Reflecting this perhaps, interest in object-orientation

also began, historically, with language developments. It was only in the 1980s that

object-oriented design methods emerged. Object-oriented analysis methods

emerged during the 1990s.

Apart from a few fairly obscure AI applications, up until the 1980s object-

orientation was largely associated with the development of graphical user interfaces

(GUIs) and few other applications became widely known. Up to this period not a

word had been mentioned about analysis or design for object-oriented systems. In

the 1980s Grady Booch published a paper on how to design for Ada but gave it the

prophetic title: Object-Oriented Design. Booch was able to extend his ideas to a

genuinely object-oriented design method by 1991 in his book with the same title,

revised in 1993 (Booch, 1994) [sic].

With the 1990s came both increased pressures on business and the availability

of cheaper and much more powerful computers. This led to a ripening of the field

and to a range of applications beyond GUIs and AI. Distributed, open computing

became both possible and important and object technology was the basis of much

Contacts: Ian Graham or Alan Wills +44-161-225 3240; clive@trireme.com

development, especially with the appearance of n-tier client-server systems and the

web, although relational databases played and continue to play an important rôle.

The new applications and better hardware meant that mainstream organizations

adopted object-oriented programming and now wanted proper attention paid to

object-oriented design and (next) analysis. Concern shifted from design to analysis

from the start of the 1990s. An object-oriented approach to requirements

engineering had to wait even longer.

The first book with the title Object-Oriented Systems Analysis was produced by

Shlaer and Mellor in 1988. Like Booch‘s original paper it did not present a

genuinely object-oriented method, but concentrated entirely on the exposition of

extended entity-relationship models, based on an essentially relational view of the

problem and ignoring the behavioural aspects of objects. Shlaer and Mellor

published a second volume in 1992 that argued that behaviour should be modelled

using conventional state-transition diagrams and laid the basis of a genuinely OO,

albeit data-driven, approach that was to remain influential through its idea of

‘translational’ modelling, which we will discuss. In the meanwhile, Peter Coad had

incorporated behavioural ideas into a simple but object-oriented method (Coad and

Yourdon, 1990; 1991). Coad’s method was immediately popular because of its

simplicity and Booch’s because of its direct and comprehensive support for the

features of C++, the most popular object-oriented programming language of the

period in the commercial world. This was followed by an explosion of interest in

and publication on object-oriented analysis and design. Apart from those already

mentioned, among the most significant were OMT (Rumbaugh et al., 1991),

Martin-Odell (1992), OOSE (Jacobson et al., 1992) and RDD (Wirfs-Brock et al.,

1990). OMT was another data-driven method rooted as it was in relational database

design, but it quickly became the dominant approach precisely because what most

programmers were forced to do at that time was to write C++ programs that talked

to relational databases.

OMT (Rumbaugh et al., 1991) copied Coad’s approach of adding operations to

entity-type descriptions to make class models but used a different notation from all

the previous methods. Not only was OMT thoroughly data-driven but it separated

processes from data by using data flow diagrams separately from the class diagrams.

However, it emphasized what Coad had only hinted at and Shlaer and Mellor were

yet to publish: the use of state-transition diagrams to describe the life cycles of

instances. It also made a few remarks about the micro development process and

offered very useful advice on how to connect object-oriented programs with

relational databases. Just as Booch had become popular with C++ programmers

because of its ability to model the semantic constructs of that language precisely, so

OMT became popular with developers for whom C++ and a relational database

were the primary tools.

Two of OMT’s chief creators, Blaha and Premerlani (1998), confirm this with

the words: ‘The OMT object model is essentially an extended Entity-Relationship

approach’ (p.10). They go on to say, in their presentation of the second-generation

Contacts: Ian Graham or Alan Wills +44-161-225 3240; clive@trireme.com

version of OMT, that the ‘UML authors are addressing programming applications;

we are addressing database applications’. Writing in the preface to the same

volume, Rumbaugh even makes a virtue out of the relational character of OMT. We

feel that a stricter adherence to object-oriented principles and to a responsibility-

driven approach is a necessity if the full benefits of the object-oriented metaphor are

to be obtained in the context of a fully object-oriented tool-set.

In parallel with the rise of the extended entity-relationship and data-driven

methods, Wirfs-Brock and her colleagues were developing a set of responsibility-

driven design (RDD) techniques out of experience gained more in the world of

Smalltalk than that of the relational database. The most important contributions of

RDD were the extension of the idea of using so-called CRC cards for design and,

later, the introduction of the idea of stereotypes. CRC cards showed Classes with

their Responsibilities and Collaborations with other objects as a starting point for

design. These could then be shuffled and responsibilities reallocated in design

workshops. The idea had originated from the work of Beck and Cunningham at

Tektronix, where the cards were implemented using a hypertext system. Moving to

physical pieces of cardboard enhanced the technique by allowing designers to

anthropomorphize their classes and even consider acting out their life cycles.

Objectory was a proprietary method that had been around much longer than

most object-oriented methods. It originated in the Swedish telecommunications

industry and emerged in its object-oriented guise when Jacobson et al. (1992)

published part of it (OOSE) in book form. The major contribution of this method

was the idea that analysis should start with use cases rather than with a class model.

The classes were then to be derived from the use cases. The technique marked an

important step forward in object-oriented analysis and has been widely adopted,

although it is possible to make some fairly severe criticisms of it. Objectory was the

first OO method to include a bona fide, although partial, development process.

OBA (Object Behaviour Analysis) originated from Smalltalk-dominated work

at ParcPlace and also included a process model that was never fully published

although some information was made available (Goldberg and Rubin, 1995; Rubin

and Goldberg, 1992). One interesting feature of OBA was the use of stereotypical

scripts in place of use cases.

Coming from the Eiffel tradition, Waldén and Nerson’s (1995) BON (Business

Object Notation) emphasized seamlessness and hinted at a proto-process. However,

this approach (and indeed its very seamlessness) depended on the adoption of Eiffel

as a specification language throughout the process. It made important contributions

to the rigour of object-oriented analysis as did Cook and Daniels’ (1994) Syntropy.

BON improves rigour using the Eiffel idea of class invariants while Syntropy does

this and further emphasizes state machines.

MOSES (Henderson-Sellers and Edwards, 1994) was the first OO method to

include a full-blown development process, a metrics suite and an approach to reuse

management. SOMA (Graham, 1995), which appeared in its mature form roughly

contemporaneously with MOSES and was influenced by it, also included all these

Contacts: Ian Graham or Alan Wills +44-161-225 3240; clive@trireme.com

features, as well as attempting to fuse the best aspects of all the methods published

to date and go beyond them; especially in the areas of requirements engineering,

process, agent-based systems and rigour.

In 1994 there were over 72 methods or fragments of methods. The OO

community soon realized that this situation was untenable if the technology was to

be used commercially on any significant scale They also realized that most of the

methods overlapped considerably. Therefore, various initiatives were launched

aimed at merging and standardizing methods.

Thus far, to the eyes of the developer there appeared a veritable soup of object-

oriented analysis and design methods and notations. It was an obvious development

to try to introduce some kind of unification and the Fusion method (Coleman et al.,

1994; Malan et al., 1996) represents one of the first attempts to combine good

techniques from other published methods, although some commentators have

viewed the collection of techniques as poorly integrated. There is a process

associated with Fusion although published descriptions of it appear incomplete

compared to the proprietary versions sold by Hewlett-Packard. The modern object-

oriented developer had to find a way to pick out the noodles from this rich soup of

techniques. Because of this and because there were many similarities between

methods it began to be felt by most methodologists that some sort of convergence

was in order

The OPEN Consortium was an informal group of about 30 methodologists,

with no common commercial affiliation, that wanted to see greater method

integration but felt strongly that methods should include a complete process, should

be in the public domain, should not be tied to particular tools and should focus

strongly on scientific integrity as well as pragmatic issues. The founding members

of OPEN were Brian Henderson-Sellers and myself who began to integrate the

MOSES and SOMA process models. The result was published as Graham et al.

(1997b). They were soon joined by Don Firesmith who started work on an

integrated notation (OML) with the aim of exhibiting a more pure object-oriented

character than the OMT-influenced UML and one that would be easier to learn and

remember (Firesmith et al., 1997).

Jim Rumbaugh left GE to join Grady Booch at Rational Inc. These two merged

their notations into what became the first version of UML (Booch et al., 1999).

Later they were joined by Ivar Jacobson who added elements of his Objectory

notation and began the development of the Rational Unified Process (RUP). UML

was submitted to the OMG for standardization and many other methodologists

contributed ideas, although the CASE tool vendors have generally resisted both

innovations that would cause them to rewrite their tools and simplifications that

would make their tools less useful. The OPEN consortium proposed the

semantically richer OML which was largely ignored despite many good ideas,

probably largely due to its over-complicatedness (Firesmith at al., 1997). Real-time

elements were added based on the ROOM method (Selic et al., 1994) and a formal

constraint language, OCL, heavily influenced by Syntropy (Cook and Daniels,

评论收藏

内容反馈

版权申诉

局外狗

粉丝: 78
资源: 1万+

UML_Tutorial.rar_uml _uml tutorial_使用UML

最新资源

UML_Tutorial.rar_uml _uml tutorial_使用UML

uml_tutorial

Uml Tutorial

UML Tutorial.pdf

UML Tutorial (English)

UML.rar_uml

uml_tutorial.zip_idea U

CMSIS_RTOS_Tutorial.pdf

WORKFLOW_TUTORIAL_610_EN.pdf

EclipseCon2005_Tutorial28.pdf

UML Tutorial

UML建模语言设计指导

uml tutorial

RationalRose2003_tutorial教程

UML class diagram tutorial

uml tutorial全英文版

UML进阶.rar_uml

UML.rar_UML设计_uml

UML.rar_uml案例

UML.rar_UML 需求_uml

UML.rar_UML 实例_UML建模_uml _uml 例

最新资源