Teach Yourself UML in 24 Hours 3rd phần 6 ppt

In the same way we used packages inFigure 14.7 to show the layers of modeling in the world of letter writing, wecan use packages to model the foundations of the UML—what the OMG refers t

Moving On

In earlier editions of this book, I said very little about M3, the metametamodellayer With the changes that UML 2.0 has brought and the proliferation of UMLmodeling tools, however, I felt it wise to explore the metametamodel layer.Although it’s not a layer you’ll encounter in your day-to-day modeling activities, Ithink you’ll understand UML a little better if you’re at least familiar with thefoundational concepts in this layer Knowing these concepts might also help youget conversant with a UML modeling tool, once you start using one

So take a deep breath, and let’s journey to M3

To Boldly Go

Are you a science fiction fan? A devotee of Star Trek, perhaps? Have you ever

won-dered how the bizarre inhabitants and exotic life forms from far-off planets all

manage to speak perfect English to the crew of the Enterprise? (And, weirdly, to

each other?)

Sometimes, sci-fi writers just ignore the language problem and have all their

characters speak English regardless of their worlds of origin The creators of Star

Trek, however, confronted this problem and came up with the Universal

Translator, a device that somehow matches up the brain waves of the speaker

with the brain waves of the listener to create a matrix of information The matrix

enables the device to quickly turn words, phrases, and idioms from one language

into words, phrases, and idioms from the other In that way, everybody in the

galaxy can talk to everyone else

Why this brief excursion into the linguistics of the final frontier? If you substitute

“applications on widely varying information processing systems” for “bizarre

inhabitants from far-off planets,” and “seamless communication” for “perfect

English,” you’ll pretty much understand one of the early challenges that confronted

the Object Management Group (Starfleet Command?): Back in the early 1990s,

OMG’s Prime Directive was to come up with something like a Universal

Translator The goal was to have objects based on different systems (which were

potentially from different vendors) communicate smoothly and seamlessly with

one another

Bear with the Star Trek analogy for a moment If you can imagine the Universal

Translator as a real-life device, its architecture and infrastructure are analogous

to CORBA—OMG’s platform for enabling applications to work together over

net-works Think back to that matrix of information that the Translator creates The

specification for what’s supposed to be in that information matrix is analogous to

another OMG solution—the Meta-Object Facility (MOF) MOF is OMG’s way of

specifying and managing information that resides on CORBA

So I’ve taken you from Star Trek to CORBA to MOF What does this

conglomer-ation of sci-fi and acronyms have to do with the UML? Just this: The MOF is the

foundation of UML 2.0’s underlying structure

What does that mean, exactly?

Well, OMG uses the Meta-Object Facility for purposes other than specifying the

nature of CORBA-related information MOF is also OMG’s template for creating

modeling languages like UML

Modeling languages like UML? Yes, just as humans have numerous languages for

communicating ideas, UML is not the only possible language for creating models

It’s become our standard, but other modeling languages are possible In theory,

you could learn what MOF is all about and use its concepts as the basis for ing a different modeling language.

creat-This would be something like taking the specifications of the information matrixfrom the Universal Translator and using them as the basis for creating new lan-guages for humans and other life forms to use

Packaging the Infrastructure of UML

Let’s talk about M3 more formally In the same way we used packages inFigure 14.7 to show the layers of modeling in the world of letter writing, wecan use packages to model the foundations of the UML—what the OMG refers

to as the UML’s infrastructure.

What’s in those packages? Class diagrams written in MOF These diagrams tute specifications (And this is why the MOF is at the foundation of the UML.) Atsome point, you might be wondering about MOF, so let me explain

consti-It all begins (in M3) with a package called the Infrastructure Library AsFigure 14.8 shows, the Infrastructure Library owns two packages, Coreand

Profiles Think of the Corepackage as a repository of concepts for creatingmetamodels like UML The Profilespackage is a repository of concepts for cus-tomizing metamodels Coreholds the concepts that define UML, and Profiles

holds the concepts that allow you to create variations of UML (and other models) for particular domains

Library owns the

Coreand Profiles

Paint and Canvas.” You might then read this book, create your own unique style

of painting, and publish your techniques for painting in that style People could

then apply these techniques to create paintings in your particular style

In the “Profiles” section of the library, one title might be “The Human Anatomy

for Painters.” After reading this book, you would be able to add particular

tech-niques to your style that would specialize it for creating paintings of people

The Core

What’s in the Corepackage? The Coreowns four packages: Primitive Types,

Abstractions, Basic, and Constructs, as Figure 14.9 shows I’ll summarize each

one for you

Core

Constructs Abstractions

Primitive Typesare data types that you would use if you were creating a

model-ing language The types in this package are Integer, Boolean, String, and

UnlimitedNatural That last one means any number in the infinite set of natural

numbers, and it specifies that an asterisk (“*”) represents infinity In UML models,

these are the numbers you see in the multiplicities at the ends of associations

between classes (And this is the origin of that asterisk that denotes many.)

Figure 14.10 models these types

A Foundational Question

In looking at Figure 14.10, you might be wondering about MOF That is, if the

Infrastructure Librarydiagrams (which define the foundation concepts) are

writ-ten in MOF, where’s the definition for MOF? And then the definition of that definition

and Well, it all has to stop somewhere, and MOF is where it stops MOF is said to bereflective, meaning that MOF is defined in MOF

In the oil-painting analogy, these primitive types would correspond to properties

of oil paint You’d have to consider these properties in any rules that specify apainting style

AbstractionsThe Abstractionspackage owns 20 packages Each package specifies how to set

up representations of the concepts you learned about in Hours 1–13 The

Elementspackage is the most fundamental of these packages and owns just oneabstract class called, unsurprisingly, Element We’re at the metametamodel level,

so it’s more appropriate to refer to Elementas an abstract metametaclass.Because it generically represents any item in a model, Elementis the superclassfor all the other classes uhmm metametaclasses in the InfrastructureLibrary

Other packages include Relationships, Comments, Multiplicities, and

Classifiers (A classifier is any element that describes structure and

behav-ior Classes, use cases, nodes, and actors are all examples of classifiers in theUML.)

The Basicpackage is a kind of baby-step into modeling Based on classes, it’s a

foundation for developing complex modeling languages If you can imagine the

UML with just classes (along with their attributes and an ability to inherit from

other classes), parameters (for a class’s operations), packages, and the ability to

specify data-types, you’ll get the idea

Constructs

The Constructspackage depends on many of the Abstractionspackages and on

the Basicpackage It combines items from those packages to add detail to

ele-ments like classes, relationships, and data types For example, this package fleshes

out the specifications for how to visualize the attributes and operations in a class

In this package, you’ll also find the kinds of information you can add to an

asso-ciation between classes (like role-names and multiplicities)

Profiles

Let’s double back and examine the Profilespackage This is the one that gives

you the mechanisms for adapting a metamodel for a specific area of knowledge

Each adaptation is a separate profile

Does a profile constitute a new metamodel? No If you were creating a new

meta-model—that is, a new modeling language—you’d begin with the Corepackage

and work from there

Think of a profile as a tweak of an existing metamodel—like adapting the UML

to model the fields of law or education You start with the UML and make some

additions The Profilespackage gives you specifications for what you can add

So what can you add? You’re already familiar with the stereotype as a way of

extending the UML This package specifies the formal mechanisms for creating

stereotypes That is, it owns metametaclasses (classes at the metametamodel

level) called Extensionand Stereotype

To give you an idea of how Extensionand Stereotypework, let’s say you’re

cre-ating a UML profile for modeling the world of electricity You’ll want to have ways

of modeling capacitors, transistors, resistors, power supplies, and other important

electrical components Because these items are hardware, you could create

stereo-types of the node, the UML’s symbol for a piece of hardware

At this level, however, you don’t have that block icon Instead, you have a

metametaclass called Node If you wanted to indicate that you were creating a

stereotype called Capacitor(something that stores electricity), your diagramwould look like Figure 14.11.

So, you might want to also create a ControlKnobstereotype of an interface.When all the stereotypes are complete, they go inside a package icon that repre-sents the profile Figure 14.12 shows your evolving Electricityprofile

profile that adapts

the UML for

modeling the world

of electricity

In practical terms, once these stereotypes are created you now have symbolsavailable in your UML Electricityprofile (that is, in your extended metamodel),which appear in Figure 14.13 (Within the UML, you can use that block icon.)

In even more practical terms, when you use the symbols in a model, their

appear-ance would resemble Figure 14.14

FIGURE 14.13

Symbols available

in the UML as aresult of creatingthe Electricity

profile

«Capacitor»

My Variable Capacitor Capacitance Range: 50pf–500pf

«ControlKnob»

FIGURE 14.14

Using the symbols from the

Electricity

profile

And Now At Last the UML!

Let’s leave M3 and explore M2 Figure 14.15 shows the UML in the context of the

ideas in previous sections—that is, it shows that the Infrastructure Libraryis

the foundation for the UML

The Four Layers AgainIt’s also the case, of course, that the UML is the foundation for the models youcreate We can restate this “foundation” business in terms of classes, metaclasses,and metametaclasses When you create a class in your model, you have created

an instance of a UML class A UML class, in turn, is an instance of a class in the metametamodel Going in the other direction, a runtime instanceresults from code based on your model Figure 14.16 summarizes all this in terms

metameta-of the four layers you’ve seen several times, and shows you some metameta-of the sources inthe metametamodel

Packaging the Superstructure of the UML

Just as package diagrams model the foundation of the UML, package diagrams

also model the elements within the UML—what OMG refers to as the UML’s

superstructure.

Figure 14.17 turns a magnifying glass on the UML package in Figure 14.15 It

shows that the UML superstructure comprises twelve packages

As the names of the packages indicate, this is where you find the formal

specifica-tions for everything you learned in Hours 1–13 As you look at Figure 14.17,

you’ll see a couple of strange-looking arrangements of dependency arrows—

two-headed dependencies and what appears to be cyclic dependency

(CommonBehaviorsdepends on Actions, Actionsdepends on Activities, and

Activitiesdepends on CommonBehaviors) This diagram is set up so that a

dependency arrow between two packages means that at least one element of onepackage depends on at least one element of the other.

Because the package names are obvious indicators of what the packages pertain

to, I’ll just summarize some features of the important ones (Profiles, by theway, is a reuse of the Profilespackage in the Infrastructure Library.)

ClassesJust as you’d expect, Classescontains specifications for classes and their relation-ships You might recall that I mentioned these elements in connection with the

Abstractionsand Constructspackages of Infrastructure Library::Core Infact, Classesreuses the specifications in those packages by merging them into

Kernel, a package that represents the fundamental modeling concepts of theUML

CommonBehaviors

In this package you’ll find the specifications for how objects behave, how nication proceeds among objects, and how to model the passage of time

commu-UseCasesThis package uses information from the Kerneland from CommonBehaviors Itspecifies the diagrams for capturing a system’s functional requirements Here’swhere you find the formal specifications for actors, use cases, inclusion, andextension

CompositeStructures

In addition to the specifications for composite structure diagrams (mentioned inHour 1), this package specifies ports and interfaces It also shows how collabora-tions among classes take place You’ll read more about collaborations in Hour 22

AuxiliaryConstructsI’ll tell you about this package because the name has probably aroused yourcuriosity This one is a grab bag It deals with templates (another Hour 22 topic),techniques for visualizing the flow of information in a system, and symbols forrepresenting models Figure 14.18 shows the icon for a model—a package symbolwith a small triangle For good measure, AuxiliaryConstructsincludes primitivetypes, reusing the information you saw earlier in the Infrastructure Library

Extending the UML

As you can see from the preceding sections, the UML has quite an extensive

struc-ture This structure is the basis of the wide array of modeling techniques you

learned in Hours 1–13

In addition to these techniques, three mechanisms enable you to extend the UML:

stereotypes, constraints, and tagged values

Stereotypes

Appearing inside guillemets, a stereotype is intended to extend a UML element

and thus create something new Back in the section on Profiles, I showed how

stereotyping works within the foundation of the UML Keep in mind that you

don’t have to create a whole new profile in order to use stereotypes

Stereotyping adds great flexibility It enables you to use an existing UML element

as the basis for an element you create—an element that captures some aspect of

your own system or domain in ways that standard UML elements can’t

In addition to stereotypes that you create, the UML comes with an extensive set of

ready-made stereotypes I describe some of them in the subsections that follow

Dependency

A dependency-based stereotype extends a dependency relationship between a

client (the element the dashed arrow starts from) and a supplier (the element the

arrow points to) Let’s look quickly at some stereotyped dependencies

An «import»dependency sits between two packages This stereotype adds the

con-tents of the supplier to the client’s namespace (the aspect of the package that

groups its constituents’ names) In this hour, you’ve already seen «refine»,

another stereotyped dependency between packages

In a «send»dependency, the client sends a signal to the supplier

In an «instantiate»dependency, the client and the supplier are both classes

This stereotype indicates that the client creates instances of the supplier

Design Model

FIGURE 14.18

A package icon forrepresenting amodel

ClassThe «metaclass»is a stereotype you encountered in the section on metamodeling.It’s a class whose instances are also classes (rather than objects) Remember, aclass you create in a UML model is an instance of a metaclass—a class within theUML.

A «type»is a class that specifies a domain of objects along with attributes, tions, and associations The «type»contains no methods (executable algorithmsfor its operations) An object can conform to more than one type

opera-An «implementationClass»is the opposite of a «type» It represents the mentation of a class in a programming language An object may not have morethan one «implementationClass»

imple-A «utility»is a named collection of attributes and operations that aren’t bers of that class It’s a class that has no instances

mem-Within a class, an operation or a method can create an instance or destroy an

instance (Perhaps you’ve seen constructor and destructor methods in Java.) You

indicate these features by «create»and «destroy», respectively

PackageUML has a couple of built-in stereotypes for packages One specifies that a pack-age holds model elements other packages can reuse It’s called «modelLibrary»

A «framework»is a stereotyped package that contains patterns and templates—

UML elements geared toward reusability I’d explain what these constructs are,but Hour 22 deals with them in detail

Graphic StereotypesSometimes you might have to bring a new symbol or two into a UML model inorder to help convey a meaning As long as everyone in your community under-stands and agrees on the meaning of the new symbol, it’s acceptable to use it.Deployment diagrams typically provide the greatest potential for this Clip art ofhardware is usually available and can replace the plain-vanilla cubes youlearned about in Hour 13, “Working with Deployment Diagrams.” When you use

a picture to represent a UML icon, you create a graphic stereotype.

Figure 14.19 shows an example It’s a stylized version of Figure 13.7, a model of

an ARCnet

As you’ve seen, constraints supply conditions and restrictions for UML model

ele-ments You can specify a constraint in any format as long as you write it inside

braces If, for example, a class has velocity as one of its attributes, you could

apply the constraint {velocity cannot exceed the speed of light}

Tagged Values

A tagged value is designed to explicitly define a property It’s also written inside

braces It consists of a tag, which represents the property to be defined, and a

value For example, you might attach {location = nodeName}to a component,

where nodeNamerepresents the node where the component resides

This hour dealt with packages and with the concepts at the base of the UML Theobjective was to give you an in-depth understanding that will enable you toapply the UML in real-world situations that don’t always mirror textbook exercises

We covered these concepts after all the diagrams so that you would understandthe elements of the language before delving into the foundations

One way of understanding the UML is in terms of its four layers: run-timeinstances, model, metamodel, and metametamodel (abbreviated as M0, M1, M2,and M3) The UML models you create reside in the second layer Code resultingfrom a UML model resides in the first When you learn UML concepts, you’re usu-ally operating in the third layer The fourth layer is one that you won’t come intocontact with on a daily basis, but some familiarity with its concepts can help youunderstand the UML and gain facility with modeling tools In fact, vendors whocreate UML modeling tools have to start from this layer

The UML provides three extension mechanisms: stereotypes, constraints, andtagged values Stereotypes create new elements by extending existing ones Somestereotypes are predefined in the UML You can also create your own Anotherkind of stereotype, graphic stereotyping, substitutes pictures for UML icons.Constraints indicate restrictions on model elements A tagged value explicitlystates the value of a property

Now if I had told you all these foundational concepts at the beginning of Hour 1,would they have been comprehensible?

A No, they’re not An object in your model is different from a run-time object.

The object in your model is in layer M1 The run-time object is in M0

Q You mentioned the four layers several times Is that some sort of limit?

Can a metamodel layering ever have more than four layers?

A Yes Theoretically, there’s no limit on the number of possible layers Forexample, if you think of our business letter analogy, our metametamodelwas “correspondence.” A higher-level layer would be “written communica-tion” which would result in metametamodels like “fiction” and “nonfiction”

in addition to “correspondence.” Practically speaking, however, you’ll ably find few areas in life where that level of layering is appropriate

prob-Q A couple of times you mentioned “other metamodels.” Is the

Infrastructure Librarythe foundation of metamodels other than the UML?

A Yes The Infrastructure Libraryis also the foundation of CWM, a guage for modeling data warehouses

lan-Q That brings up another question When do you create a profile and when

do you create a new metamodel?

A Good question Unfortunately, there aren’t any set rules for deciding

Q I understand that MOF is the foundation of UML 2.0 Has the MOF been the basis for every version of the UML?

A No it hasn’t UML 1.x was defined in UML

A OMG wanted to align the UML with other OMG efforts, including futureefforts (like upcoming metamodels) Giving them all a common foundationwas a great way to do this

Q I can see that the UML has a number of rules Who enforces these rules?

A As I mentioned before, the UML Police don’t come around and check yourmodel for correctness A modeling tool, however, gently helps you stick tothe rules

3 Why is it important to be able to extend the UML?

4 What are the UML’s extension mechanisms?

ExerciseFind online pictures or clip art of devices and use them to refine the deploymentdiagrams you saw in Hour 13

HOUR 15

Fitting the UML into a Development Process

What You’ll Learn in This Hour:

Why a development process is important Why older development methodologies are inappropriate for today’s systems The GRAPPLE development process

How to incorporate the UML into the process

Now that you’ve learned about the UML’s diagrams and structure, it’s almost timefor the rubber to meet the road The UML is a wonderful tool, but you don’t use it inisolation It’s intended to fuel software development In this hour, you’re going tolearn about development processes and methodologies as a vehicle for understand-ing the use of the UML in a context

Imagine this situation: Your organization needs a new computer-based system Newhardware and software will result in a competitive advantage, and you want thatadvantage Development has to start, and soon

You’re the one who made the decision to build the new system You’ve put a ment team in place, complete with a project manager, modelers, analysts, program-mers, and system engineers They’re champing at the bit, anxious to get started.You are, in other words, a client What work-products will you expect to see from theteam? How do you want the project manager to report to you? At the end, of course,you’ll want the system up and running Before that, you’ll want indications that theteam understands the problem you’re trying to solve and clearly comprehends yourvision of how to solve it You’ll want a look at their solution-in-progress, and you’llwant an idea of how far along the team is at any point

develop-These are common concerns for any client and for any system development ect that involves an appreciable amount of time, money, and personpower.

proj-Methodologies: Old and New

You won’t want the development team to rush off and start coding After all,what will they code? The development team has to proceed in a structured,methodical way The structure and nature of steps in a development effort are

what I mean by a methodology.

Before they begin programming, the developers have to fully understand theproblem This requires that someone analyze your needs and requirements Afterthat analysis is done, can coding start? No Someone has to turn the analysis into

a design Coders then work from the design to produce code, which, after testingand deployment, becomes a system

The Old WayThis oversimplified look at a sequence of segments of effort might give you theidea that the segments should neatly occur in clearly defined chunks of time, oneright after the other In fact, early development methodologies were structured inthat way Figure 15.1 shows one way of thinking that was highly influential for a

number of years Dubbed the waterfall method, it specifies that analysis, design,

coding, and deployment follow one another like activities in an activity diagram:Only when one is complete can the next one begin

This way of doing things has some ominous overtones For one thing, it

encour-ages compartmentalization of effort If an analyst hands off an analysis to a

designer, who hands off a design to a developer, chances are that the three

team-members will rarely work together and share important insights

Another problem with this method is that it minimizes the impact of

understand-ing gained over the course of a project (Make no mistake: Understandunderstand-ing evolves

during the life of a project—even after an analysis has turned into a design.) If

the process can’t go back and revisit earlier stages, it’s possible that evolving ideas

will not be utilized Trying to shoehorn new insights into a project during

devel-opment is difficult at best Revisiting an analysis and a design—and then

incor-porating an evolved understanding—provides a much better chance of success

A New Way

In contrast to the waterfall method, contemporary software engineering stresses

continuing interplay among the stages of development Analysts and designers,

for example, go back and forth to evolve a solid foundation for the programmers

Programmers, in turn, interact with analysts and designers to share their insights,

modify designs, and strengthen their code

The advantage is that as understanding grows, the team incorporates new ideas

and builds a stronger system The downside (if there is one) is that some people

like closure and want to see intermediate stages come to a discrete end

Sometimes, project managers like to be able to say something to clients like,

“Analysis is complete, and we’re going into design Two or three days of design,

and we’ll begin coding.”

That mentality is fraught with danger Setting up artificial barriers between stages

will ultimately result in a system that doesn’t do exactly what a client wants

The old way fosters another problem: It’s usually the case that adherents of the

waterfall method allot the lion’s share of project time to coding The net effect of

this is to take valuable time away from analysis and design

What a Development Process Must Do

In the early years of computer programming, one person could analyze a

prob-lem, come up with a solution, and write a program In the early years of building

homes (back when the world was flat), one person could build a pretty serviceable

home, too

Today it’s a different story In order to develop the kinds of complex systemstoday’s business world demands, a team approach is necessary Why? Knowledgehas become so specialized that one person can’t know all the facets of a business,understand a problem, design a solution, translate that solution into a program,deploy the executable version onto hardware, and make sure the hardware com-ponents all work together correctly.

The team has to consist of analysts to communicate with the client and stand his or her problem, designers who construct a solution, programmers whocode the solution, and system engineers who deploy the solution A developmentprocess has to take all these roles into account, utilize them properly, and allot theproper amount of time to each stage of the effort The process must also result in anumber of work-products that indicate progress and form a trail of responsibility.Finally, the process must ensure that the stages of the effort aren’t discrete.Instead, feedback must take place among the stages to foster creativity andincrease the ease of building new ideas into the effort Bottom line: It’s easier tomake a change to the blueprint and then make the change to the house, ratherthan change the house while you build the physical structure

under-In arriving at a process, the temptation is to construct a set of stages that result inmassive amounts of paperwork Some commercially available methodologies dothis, leaving project managers to fill out endless forms The paperwork becomes

an end unto itself

One reason for this is the erroneous idea that a one-size-fits-all methodology ispossible Every organization is unique An organization has its own culture, stan-dards, history, and people The development methodology that’s right for a multi-national conglomerate will probably fail in a small business, and vice versa Intrying to shoehorn a methodology to fit an organization, the misconception isthat massive paper trails will somehow help

So here’s the challenge A development process must. Ensure that the development team has a firm understanding of the problemit’s trying to solve

. Allow for a team that consists of an array of roles. Foster communication among the team members who occupy those roles. Allow for feedback across stages of the development effort

. Develop work-products that communicate progress to the client, but nate superfluous paperwork

elimi-Oh, by the way, it would be a good idea if the process produces a finished product

within a short timeframe

Process and Methodology

You’ll notice that I use the words process and methodology interchangeably Although

it’s possible to find some differences between the two, I’d rather not split hairs It’s

been my experience that the word methodology has acquired a bad odor in some

organizations Mixing process into the discussion, I feel, somewhat alleviates the

discomfort

GRAPPLE

To meet the multifaceted challenge of creating a development process, I present

the Guidelines for Rapid APPLication Engineering (GRAPPLE) The ideas within

GRAPPLE aren’t original They’re a distillation of the ideas of a number of others

The Three Amigos created the Rational Unified Process, and prior to that, each

Amigo had his own process The ideas in those processes are similar to GRAPPLE

Steve McConnell’s book, Rapid Development (Microsoft Press, 1996), contains a

number of best practices that pertain to well rapid development

The first word in GRAPPLE’s name, Guidelines, is important: This isn’t a

methodol-ogy written in stone Instead, it’s a set of adaptable, flexible ideas Think of it as a

simplified skeleton of a development process I present it as a vehicle for showing

the UML within a context With a little tweaking here and there, GRAPPLE can

work in a variety of organizations (but maybe not all) It leaves room for a

cre-ative project manager to add his or her own ideas about what will work in a

par-ticular organization and to subtract the built-in steps that won’t

A Little Context

Before I discuss GRAPPLE, here’s a question you might be asking: “Why are you

telling me about this in a book about the UML?”

Here’s the answer: If I don’t tell you about a development process and provide a

context for using the UML, all I’ve done is show you how to draw diagrams The

important thing is to show why and when you’d use each one

In Part II, “A Case Study,” you’ll go through a test case that applies GRAPPLE and

RAD 3 : The Structure of GRAPPLE

GRAPPLE consists of five segments I use segments rather than stages to get away

from the idea that one “stage” has to be complete before the next one starts (I

resisted the temptation to call them pieces “Five easy pieces” was just too cute.) Each segment, in turn, consists of a number of actions Each action produces a

work-product, and each action is the responsibility of a particular player.

In many cases, the project manager can combine the work-products into a reportthat he or she presents to the client The work-products, in effect, serve the samepurpose as a paper trail without bogging down the project in paperwork

To adapt GRAPPLE, a project manager could add actions to each segment.Another possibility is to drill down a level deeper and subdivide each action intosubactions Still another possibility is to reorder the actions within each segment.The needs of an organization will dictate the course to follow

GRAPPLE is intended for object-oriented systems Thus the actions within eachsegment are geared toward producing work-products of an object-oriented nature.The segments are

Before all these segments start, you assume the client has made a business casefor the new system You also assume the members of the development team, par-ticularly analysts, have read as much relevant documentation as possible.Let’s examine each segment more closely, with an eye toward showing the parts

of the UML that fit into each one

Requirements Gathering

If you were to try and assign a relative importance to each segment, this one is a

good candidate for numero uno If you don’t understand what the client wants,

you’ll never build the right system All the use case analysis in the world won’t

help if you don’t understand the essentials of the client’s domain and the problem

he or she wants you to solve

Discover Business Processes

It’s a good idea to begin the development effort by gaining an understanding of

the client’s business processes, specifically the one(s) you’re trying to enhance

with the proposed system To gain this understanding, an analyst typically

views the client or a knowledgeable client-designated person and asks the

inter-viewee to go through the relevant process(es) step-by-step

An important outcome is that the analyst gains a working vocabulary in a subset

of the client’s terminology The analyst uses this vocabulary when interviewing

the client in the next action

The work-product for this action is an activity diagram or a set of activity

dia-grams that captures the steps and decision points in the business process(es)

Perform Domain Analysis

This action is like the example of the conversation with the basketball coach from

Hour 3, “Working with Object-Orientation.” It can take place during the same

session as the preceding action The objective is to gain as solid an understanding

as possible of the client’s domain Note that this action and the preceding one are

about concepts; they’re not about the system you’re going to build The analyst

has to get comfortable in the client’s world, as he or she will ultimately be the

client’s emissary to the development team

The analyst interviews the client with the goal of understanding the major

enti-ties in the client’s domain During the conversation between the client and the

analyst, another team member takes notes (optimally, on a laptop computer

equipped with a word processing package), and an object modeler constructs a

high-level class diagram If you can have more than one team member take

notes, by all means do so

The object modeler listens for nouns and starts by making each noun a class

Ultimately, some nouns will become attributes The object modeler also listens for

verbs, which will become operations of the classes At this point, a

computer-based modeling tool becomes extremely valuable

The work-product is a high-level class diagram and a set of meeting notes.

To Tape or Not to Tape?

Should you tape these interviews or should you just rely on your meeting notes?This is a question that crops up frequently When you tape an interview, the tempta-tion is to not listen as closely or not take notes as rigorously (After all, you canalways listen to the tape later.) If you do decide to tape, my advice is to forget thetape recorder, and take notes as though the recorder weren’t there

Tape recording can be a useful tool when you’re training a new object modeler Anexperienced modeler can compare the new modeler’s diagrams with the taped dis-cussion and check for completeness

Identify Cooperating SystemsSeventeenth-century poet John Donne wrote, “No man is an island, entire ofitself.” If he were writing today, it would have been “No person is a land-masssurrounded entirely by water, entire of him- or herself.” He might also have writ-ten “No system is an island ,” and so on

Donne would have been right on all counts Today’s business systems don’t cally emerge in vacuums They have to work with others Early in the process, thedevelopment team finds out exactly which systems the new system will depend

typi-on and which systems will depend typi-on it A system engineer takes care of thisaction, and produces a deployment diagram as the work-product The diagramshows the systems as nodes, with lines of internode communication, resident com-ponents, and intercomponent dependencies

Discover System RequirementsThis one is extremely important You might have guessed that because it has

requirements in its name In this action, the team goes through its first Joint

Application Development (JAD) session Several more occur throughout the

course of GRAPPLE

A JAD session brings together decision-makers from the client’s organization, tial users, and the members of the development team A facilitator moderates thesession The facilitator’s job is to elicit from the decision-makers and the users whatthey want the system to do At least two team members should be taking notes, andthe object modeler should be refining the class diagram derived earlier

poten-The work-product is a package diagram Each package represents a high-levelarea of system functionality (for example, “Assist with customer service”) Each

By the

Way