Prev: looking for a predicate hierarchy
Next: double-entry bookkeeping unneeded?
From: H. S. Lahman on 19 Dec 2006 12:03
Responding to Federica...

> Hi all,
> I have to draw a class diagram about an airline company.
>
> The business Domain model of the company is the following:
>
> [Itinerary] 1 -----------1..* [Segments] 1 --------1 [Flight] 1
> ----------1 [Airplane]
>
> Where:
> Itinerary: a list of flight segments
> Segment: a single take off and landing
> Flight: holds flight (date,time) information
> Airplane: holds airplane information.
>
> My main concern is how to represent the relation between Segments and
> Flights ?
> Since they have a 1:1 relation it seems to me that Segment holds
> ABSTRACT
> information (price, length of the flight) and Flight holds CONCRETE
> information
> (Date/ time airplane used).
> *** How should I model this in a class diagram ? ****

First, relationships have nothing to do with the specific semantics of
the classes they relate. The relationship simply defines the overall
structure of how individual members of each class set may be logically
related. That basic structure is defined in three ways:

Multiplicity. Given a member (object) of one set, how many objects of
the other set can that member be related to at any moment in time?

Conditionality. Given a member of one set, must it /always/ be related
to at least one member of the other set or can it be related to none?

Role. A relationship role defines the specific logical nature of any
collaborations. While it is not implemented per se, it exists to help
the developer keep track of Why a relationship exists at all.

In addition, in UML relationships are subdivided for specialized
purposes like generalization and composition. Those subdivisions place
additional semantics and constraints on the relationship.

A generalization seems to be about property sets but that is
superficial. The generalization itself only defines subset membership
for members of the root superclass. The fact that class sets happen to
be defined in terms of properties /enables/ rules like inheritance for
resolving properties of members, but the generalization itself simply
defines subset membership for root objects. IOW, it is a Venn Diagram
in tree form.

Second, the notions of abstract vs. concrete only apply to
generalizations. In a generalization a superclass must define What
properties must be implemented for each member but it is not required to
implement those properties. Only members of specific leaf subclasses
must always have implementations. If an implementation is not provided
in a superclass, the relevant property is abstract for that superclass.
If an implementation is provided, then the property is concrete for
all members of that set, which includes members of all descending subsets.

What you have described does not seem to be a generalization so the
notions of abstract vs. concrete are not relevant. IOW, the
relationship between [Segment] and [Flight] is a simple association and
you have already correctly represented (i.e., multiplicity and
conditionality) the model.

> A last question, should I show in the Segment Class the instance filed
> "Flight flight" (which holds an instance of the class Flight) ?

I am not sure what you are asking here. I suspect, though, it is
related to the difference between implementation, instantiation, and
navigation of relationships at the 3GL level.

There are three ways to implement a relationship: invoking a FIND search
on the class set; passing an object reference as a method argument; and
embedding a reference to another object in an object. The first way is
the typical RDB way relationships are implemented and it is rarely seen
in OO applications for performance reasons. Passing an object reference
creates a temporary relationship (over the scope of the called method).
But that is avoided whenever possible because it increases coupling
substantially. So the most common implementation is through referential
attributes. (Handling * relationships usually requires collection
classes at the 3GL level, which is why multiplicity is important.)

Relationships are instantiated by actually providing a specific object
reference for the implementation dynamically at run-time. So one
assigns a specific object reference to a referential attribute to
instantiate that implementation. (Referential integrity determines
whether and when a reference must be available, which is why
conditionality is important.)

Relationships are navigated when messages are sent between objects
during collaborations. To send a message one needs the address of the
recipient and one gets that address from the instantiated relationship
implementation.

The main point here is that OOA/D relationships are implemented at the
3GL level. Since there are multiple ways to do that one would be
usurping the prerogatives of OOP to specify exactly how the
relationships should be implemented in the OOA/D. IOW, all you define
at the Class Model level is that the relationship exists and what its
controlling characteristics -- multiplicity and conditionality -- are.
(One also defines instantiation and navigation of relationships at the
OOA/D level, but that is done abstractly in dynamic descriptions like
Statechart through abstract action language.)


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl(a)pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info(a)pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH



From: Doug Pardee on 19 Dec 2006 13:29
This sounds like you're doing a homework problem rather than modeling
an actual business, so my response will be oriented toward that.

Federica wrote:
> My main concern is how to represent the relation between Segments and Flights ?
> Since they have a 1:1 relation

Why do they have a 1:1 relationship? Whenever there is a 1:1
relationship, the two parts could easily be combined into one.

I would think that a segment can only happen on one flight, but a
flight could have multiple segments. If I board Flight 123 from Los
Angeles to New York via Chicago, that is one flight but with two
segments: LA to Chicago, and Chicago to NY. If I board that flight from
LA to Chicago, it is the same flight but my itinerary only has one
segment on the flight in that case.

Similarly, I wonder about the 1:1 relationship between Flight and
Airplane. The same airplane might be used on more than one flight.
Maybe I boarded Flight 123 from LA to Chicago, then the flight number
changed to 246 for the Chicago to NY segment even though it was the
same plane.

In Real Life, it is much more complicated than that. Due to
code-sharing, the same segment can be have different flight numbers
from different airlines. The same airplane will certainly be used on a
number of different flights (if nothing else, the return path almost
always has a different flight number). And each segment will have
multiple itineraries, unless you're only allowing one passenger at a
time!

In Real Life, those aren't nearly enough classes to properly model an
airline booking system. Those are all entity classes; the model is
completely missing its event, description, and role classes. The
absence of the event classes would become glaringly obvious when you
tried to model the many-to-many relationships that exist In Real Life.

From: Federica on 20 Dec 2006 03:31
Thanks a lot for your answers!

>The main point here is that OOA/D relationships are implemented at the
>3GL level. Since there are multiple ways to do that one would be
>usurping the prerogatives of OOP to specify exactly how the
>relationships should be implemented in the OOA/D. IOW, all you define
>at the Class Model level is that the relationship exists and what its
>controlling characteristics -- multiplicity and conditionality -- are.
>(One also defines instantiation and navigation of relationships at the
>OOA/D level, but that is done abstractly in dynamic descriptions like
>Statechart through abstract action language.)

If I understand correctly what you say, it's not necessary to show in
the class Diagram the
instance field which holds a reference to the other object
(for example the field "flight" in the Segment class). I'll rather
focus on the characteristics of the relationship.

> This sounds like you're doing a homework problem rather than modeling
> an actual business, so my response will be oriented toward that.

Yes, sorry I forgot to mention, it's a "work" for the University not
for a real business.
I have a simulated interview with a business analyst who gave me this
business model.

> I would think that a segment can only happen on one flight, but a
> flight could have multiple segments. If I board Flight 123 from Los
> Angeles to New York via Chicago, that is one flight but with two
> segments: LA to Chicago, and Chicago to NY. If I board that flight from
> LA to Chicago, it is the same flight but my itinerary only has one
> segment on the flight in that case.

I totally agree with you. This Business Model is really weird. I have
spent weeks searching for an answer on Ariline web sites and all I have
found is that Segment and Flight are just synonyms in the Airline
Industry for the majority of people.

I have inquired at the University to find some clues and I have been
told I have two choices:

1) Implement the BDM as it is. (somehow!)
2) If I plan to change the multiplicity of relations I should explain
exaclty what's the reason for it.

At first I have chosen to follow the indications of the BDM and just
"split" the flight information between Flight and Segment....but as
time passes I think this is really non-sense

In my opinion, the challenge for the student here is to face a problem
(BDM inconsistent) and see how he/she solve this problem.

May I ask you, if you had to model these relationship, what track would
you choose (1 or 2) ?
Thanks a lot in advance......

From: Pillo on 20 Dec 2006 18:27
Ciao,
to me

| Itinerary | 1 ---------* | SEGMENT | *--------- 1 | Airplane |


Flight is
1 -- * to Segment
* --- * to Airplane

because
- the flight can gather many takeoffs and landings i.e. Flight AZ102 is
from Rome to Berlin but it will fly on january 1, january 2, ecc.
- the flight AZ102 is actually performed by different airplanes and
vice versa

 | 
Pages: 1
Prev: looking for a predicate hierarchy
Next: double-entry bookkeeping unneeded?