UML Weekend Crash Course™ - To Parent Directory

28
Friday Evening
the other guy), and leaves assuming he has the truth. How do you feel Outraged, I imagine.
The officer talked to his “client” and captured the facts just like we typically gather our
requirements. So what’s the problem
The problem is that the officer did nothing to verify his facts. He should have asked the
other witnesses for their perspectives. After he does that, he has a bunch of eyewitness
accounts. If he compares the stories, he’ll discover two things. First, some of the information
from different testimonies will agree. He can reasonably assume that those portions of the
account are true. Second, the portions that don’t line up can’t be trusted until he can find
corroborating evidence.
Working with multiple, different views works in the same way. The diagrams each look at
your problem in a different way, like different witnesses. The diagrams will overlap. If they
agree where they overlap, you can relax knowing you’ve probably got it right. If they don’t
agree, then you have some homework to do to reconcile the differences. Now here is the
other great benefit: When they disagree, you’ve pinpointed where you need to invest your
effort. When everything agrees, you know you’re done.
Object-Oriented Principles
Next I want to visit the principles that drive most of the UML modeling. All the UML diagrams
describe some form of object-oriented information. But what does the term object-oriented
mean The term itself sheds some light on the answer. It has something to do with viewing
the things in the world as objects.
So what is an object The simplest definition of an object is pretty much anything you
can talk about. Look around you. Almost without thinking you may begin to recognize
things you see and give them names: book, chair, lamp, room, and so on. An object can be
a physical entity, like the things you see, but an object may also be intangible, for example,
a concept like an illness, attendance, or a job. Even though a job is not something you can
touch, it is something you can describe, discuss, assign, and complete.
(By the way, if you aren’t already familiar with OO concepts, some of the language may
sound a little odd. Be prepared.)
So what do you need to know about an object
Abstraction
A software object is an abstraction, a representation of something in the real world like this
book. An abstraction is a way to describe something where you only include the information
about it that is important to you. When I need to contact my friend Victor, for example, I
don’t need to know everything about him. I just need his phone number or e-mail address.
Thank heaven I don’t also need to know his anatomy, his genealogy, and his music preferences!
All those things are valid, but they don’t help me contact him. Figure 3-5 shows
Victor on the left, hard at work, and an object icon, my abstraction of Victor, on the right.