GeeCON Prague 2014*
The moose likes OO, Patterns, UML and Refactoring and the fly likes Class Diagram -Association & Inheritance Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Class Diagram -Association & Inheritance" Watch "Class Diagram -Association & Inheritance" New topic
Author

Class Diagram -Association & Inheritance

pradeep anandan
Greenhorn

Joined: Jul 02, 2001
Posts: 25
I have a Account type class and Account class
where Account TYpe has differnet types of Accounts eg:Saving and Current
and Account class stores the account info like Account id,account type.
To get account type in account class what type of relationship should i show between 2 classes
1) Association or inheritance. and why
Regards,
Pradeep
Wilfried LAURENT
Ranch Hand

Joined: Jul 13, 2001
Posts: 269
According to Peter Coad:
Choose Inheritance when it satisfy all of the following:
1. A subclass represents "Is a special kind of" and not "is a role of"
2. An object of one class never needs to transmute to another class
3. The derived class extends rather than overrides or nullyfies the responsabilities of its base class
4. A subclass does not extend a utility class
5. For a class in the actual Problem Domain, the subclass specializes a role, a transaction or device.
So make up your mind
W.
Hari babu
Ranch Hand

Joined: Jun 25, 2001
Posts: 208
Hi,
I think it should be aggregation rather than inheritance or association
Hari
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by pradeep anandan:
I have a Account type class and Account class
where Account TYpe has differnet types of Accounts eg:Saving and Current
and Account class stores the account info like Account id,account type.
To get account type in account class what type of relationship should i show between 2 classes
1) Association or inheritance. and why
Regards,
Pradeep

I don't think it's possible to tell without knowing more about the code. Can you show us some (potential) implementation for the classes? How will the classes be used?


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Hari babu:
Hi,
I think it should be aggregation rather than inheritance or association
Hari

Of course aggregation *is* a form of association - and the difference is rather minimal.
The only real semantic difference is that there is no cycle allowed in aggregation.
Vikrama Sanjeeva
Ranch Hand

Joined: Sep 02, 2001
Posts: 756
Hi,
Originally posted by Ilja Preuss:

I don't think it's possible to tell without knowing more about the code. Can you show us some (potential) implementation for the classes? How will the classes be used?

I dont think that answering this question will require some knowledge of implementation.Because making/creating relatiosnship is part of desing.However changes occur when one transforms design into implementation.But still deciding which relationship exist b/w two classes is part of design.


Count the flowers of your garden, NOT the leafs which falls away!
Prepare IBM Exam 340 by joining http://groups.yahoo.com/group/IBM340Exam/
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Vikrama Sanjeeva:
I dont think that answering this question will require some knowledge of implementation.Because making/creating relatiosnship is part of desing.However changes occur when one transforms design into implementation.But still deciding which relationship exist b/w two classes is part of design.

I don't understand your reasoning.
Why would you do a design decision like inheritance vs. association if it doesn't affect the implementation? And if it does, wouldn't it be critical to take the impact on implementation into account? Isn't the whole point of designing to assist implementation?
Hell, I even wouldn't know how to design without "seeing the accompanied code in my head". And I certainly can't stop designing once I started implementing...
Vikrama Sanjeeva
Ranch Hand

Joined: Sep 02, 2001
Posts: 756
Hi,
Originally posted by pradeep anandan:
I have a Account type class and Account class
where Account TYpe has differnet types of Accounts eg:Saving and Current
and Account class stores the account info like Account id,account type.
To get account type in account class what type of relationship should i show between 2 classes
1) Association or inheritance. and why
Regards,
Pradeep

Consider this:
As u told, Account class holds information of Account type.Therefore according to Expert pattern, Account class is responsible for telling account type i.e if i have an operation getAccountType() then it should be placed in Account class.
Now the problem occurs that how Account class will get the information of Account Type?
Here I am assuming that u have made the constructor of Account class like this:
Account(...,AccountType,...)
Considering above code, creation of Account object is dependent on Account Type.Therefore relationship b/w Account and AccountType is of dependency.

Bye,
Viki.
NOTE:This is my perception.May be i am wrong as i am still in learning proccess.
Piyush Daiya
Ranch Hand

Joined: Jun 13, 2002
Posts: 67
Originally posted by pradeep anandan:
I have a Account type class and Account class
where Account TYpe has differnet types of Accounts eg:Saving and Current
and Account class stores the account info like Account id,account type.
To get account type in account class what type of relationship should i show between 2 classes
1) Association or inheritance. and why
Regards,
Pradeep

Well,
As u have mentioned Pradeep, u want account type in account class i.e account type is attribute of account class.Hence the relationship you have to show is association.
Inheritance is type of generalisation relationship.(A Generalisation relationship is relationship among classes where one class shares the structure and/or behaviour of one or more classes).
Since, you havent mentioned anything about sharing structure or anything between Account or AccountType, inheritance is not the relationship between the classes.
Association relationships can be of Aggregation and Composition types.
HTH,
Piyush


"A scientist is not person who gives right answers but a person who asks right questions"
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Oh, ok - if it is a given that Account holds a reference to AccountType, it surely is some form of Association. I understood the original poster to ask wether he should do this, or use inheritance instead - sorry if I got this wrong.
I would still insist in taking the implementation into account when deciding between the two approaches, though...
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Vikrama Sanjeeva:
Account(...,AccountType,...)
Considering above code, creation of Account object is dependent on Account Type.Therefore relationship b/w Account and AccountType is of dependency.

A dependency is a rather weak UML artefact, only telling that if AccountType changes, it will probably affect Account.
An association is much stronger - it's a connection between two classes, through which instances of these classes can send messages to each other.
Vikrama Sanjeeva
Ranch Hand

Joined: Sep 02, 2001
Posts: 756
Hi,

Originally posted by Ilja Preuss:

A dependency is a rather weak UML artefact, only telling that if AccountType changes, it will probably affect Account.
An association is much stronger - it's a connection between two classes, through which instances of these classes can send messages to each other.

Composition is much stronger relationship then association and dependency
I dont think that one should select relationship on the basis of there strongness.Rather the one which logically applies to the given scenario.As design is the logical solution.
Originally posted by Ilja Preuss:

An association is much stronger - it's a connection between two classes, through which instances of these classes can send messages to each other.

I dont think that the method getAccountType is placed in AccountType class and Account class send message to AccountType for asking account type.Rather this information is provided as soon as Account instance is created, possibly via Account's constructor.

Bye,
Viki.
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
What worries me about this so far is that no one seems to have discussed how (if at all) the behaviour of the Account class changes as a result of the AccountType.
It might be something as simple as calling toString on an associated AccountType when generating the name of the Account, or it might be much more complicated (see Strategy pattern, for example).
It might even be that Account doesn't actually need to know about AccountType at all - maybe they would be better aggregated together into another class.
I feel that without at least some discussion of the context of this problem, we are unable to come to any useful conclusion.
Anyone got any more background to this problem ?


Read about me at frankcarver.me ~ Raspberry Alpha Omega ~ Frank's Punchbarrel Blog
Vikrama Sanjeeva
Ranch Hand

Joined: Sep 02, 2001
Posts: 756
Hi,
Originally posted by Frank Carver:
What worries me about this so far is that no one seems to have discussed how (if at all) the behaviour of the Account class changes as a result of the AccountType.

Can u give any example that how Accoun Type changes behaviour of Account class?.

Anyone got any more background to this problem ?

Most of us is familar with Banking process.And i think it's just a general query when one is designing Banking Applications.However, it will be never bad when there is extra information given
Bye,
Viki.
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
Most of us is familar with Banking process.And i think it's just a general query when one is designing Banking Applications
Sure. But to me as a customer, the "account type" of my back accounts is just a text string.
If I were asked to design some sort of software to manage bank accounts, I'd start with the behaviour. Without knowing anything about how the behaviour of a "current" account differs from the behaviour of a "savings" account in this particular case, I can't make much of a decision about how to represent the account type.
So what puzzles me is that this whole thread seems to e trying to make that decision in the absence of the vital information to base it on.
The system may not actually need an "AccountType" class at all. If it is only a name, it can be a String.
Piyush Daiya
Ranch Hand

Joined: Jun 13, 2002
Posts: 67
Frank,
I agree with you.More needs to be known about the problem.But,I guess the person is in process of learning OOAD and must have chosen banking example and was asking suggestions.
We all tried to help him with information he provided us.

Piyush
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Vikrama Sanjeeva:
Composition is much stronger relationship then association and dependency

Well, all it adds over aggregation is lifetime responsibility - and in garbage collected languages like Java, this really isn't a very strong distinction. It's much more interesting in C++, for example, where it would include responsibilities like calling a constructor or something similar...

I dont think that one should select relationship on the basis of there strongness.

Sorry, I didn't meant to imply something like that. What I wanted to imply is that the design should be choosen based on the needs of the implementation. And I think Account somehow probably would want to send messages to AccountType.
I dont think that the method getAccountType is placed in AccountType class and Account class send message to AccountType for asking account type.Rather this information is provided as soon as Account instance is created, possibly via Account's constructor.

If we don't want to call methods on AccountType, why would we need an instance of it??? How would Account be dependend on AccountType?
I agree with Frank - we definitely need to know more about the behaviour of Account and the impact of AccountType.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Vikrama Sanjeeva:
And i think it's just a general query when one is designing Banking Applications.

I think the point is that you simply *can't* reasonably design a "general" application, without having detailed insight about the desired behaviour.
Vikrama Sanjeeva
Ranch Hand

Joined: Sep 02, 2001
Posts: 756
Hi,
Originally posted by Ilja Preuss:

I think the point is that you simply *can't* reasonably design a "general" application, without having detailed insight about the desired behaviour.

Well, its all depend upon modeler.I think in IBM 486 Exam no one can give answers b/c there is not much detail is given.Questions are asked in the way pradeep has asked.It's intiuition of modler.In real modeling(i mean other then exam) having good detial of Domain is required.
Bye,
Viki.
[ January 08, 2003: Message edited by: Vikrama Sanjeeva ]
pradeep anandan
Greenhorn

Joined: Jul 02, 2001
Posts: 25
Well it was a great to see so much response..
and I think We are not arriving to a conclusion as there is not enough information provided.
As I am in the learning curve of UML and I was just going through a Banking Application eg to make a UML
design of it.
And there I had a doubt of it.
As in RDBMS we have 2 different tables one for Acccount type and other Account and have a foreign key relationship
will the same is applied in OOPS where The rate of interest differs with the account type
Regards,
Pradeep
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Vikrama Sanjeeva:
Well, its all depend upon modeler.I think in IBM 486 Exam no one can give answers b/c there is not much detail is given.

I would probably think the same, yes.
Questions are asked in the way pradeep has asked.It's intiuition of modler.In real modeling(i mean other then exam) having good detial of Domain is required.

I think there is even more required than detail about the domain. Keep in mind that the *only* job of the design is to foster implementation - and the implementation is much more about the solution than about the problem.
So even if you had enough detail to model the domain (what you probably would call an analysis model), there simply is no mechanic way to get to the design. You *need* to think about the solution (the implementation) to give it a first rough shape (what you probably would call the initial design in this context).
So even if in the domain an Account "HAS AN" AccountType, there is no direct way to tell wether Account should have an association to AccountType, or wether those classes should even exist in the design.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by pradeep anandan:
As in RDBMS we have 2 different tables one for Acccount type and other Account and have a foreign key relationship
will the same is applied in OOPS where The rate of interest differs with the account type

There is no way to tell the appropriate OO solution from this - the tables could be implemented as both inheritance and association, besides a trillion other possible solutions.
If the rate is the only difference between AccountTypes, you probably should use simple fields in the Account class:
Piyush Daiya
Ranch Hand

Joined: Jun 13, 2002
Posts: 67
Originally posted by pradeep anandan:
Well it was a great to see so much response..
and I think We are not arriving to a conclusion as there is not enough information provided.
As I am in the learning curve of UML and I was just going through a Banking Application eg to make a UML
design of it.
And there I had a doubt of it.
As in RDBMS we have 2 different tables one for Acccount type and other Account and have a foreign key relationship
will the same is applied in OOPS where The rate of interest differs with the account type
Regards,
Pradeep

Hi Pradeep,
UML is just a notation/language to represent design or software object model.It is during analysis and design that you decide what relationships exists between two objects.And then after that u show relationship between objects using UML or any other notation.
For learning UML, UML Distilled by Martin Fowler is best book(IMHO).
For doing OOAD, u have to learn to think in terms of objects and not persistent information(like RDMS tables).For this I would suggest book, Applying UML and Patterns:An Introduction to OOAD and Unified Process by Craig Larman,2nd edition.It is very good book and helped me a lot in learning OOAD and UML.
HTH,
Piyush
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Piyush Daiya:
It is during analysis and design that you decide what relationships exists between two objects.

Well, I would rather say that
- *observing* existing relationships between domain concepts is part of analysis, and
- deciding what relationships to build between classes is part of design
And don't get fooled into the thinking that you need to somehow "finish" analyzing before you may start designing or even should have finished your design before you start coding.
Vikrama Sanjeeva
Ranch Hand

Joined: Sep 02, 2001
Posts: 756
Hi,
Originally posted by Ilja Preuss:

And don't get fooled into the thinking that you need to somehow "finish" analyzing before you may start designing or even should have finished your design before you start coding.


Well said Ilja!.This is what UP emphasizes on.A/C to UP, small code should be developed as a protype.This protype does not mean to be useless when starting coding.Rather, this protype is in executable form and must be added in final coding, i.e don't throw this just for testing!.
Bye,
Viki.
Piyush Daiya
Ranch Hand

Joined: Jun 13, 2002
Posts: 67
Yeap Ilja,
You are right.Analysis and Design are to be done iteratively.

Piyush
Guennadiy VANIN
Ranch Hand

Joined: Aug 30, 2001
Posts: 898
Everybody finished? May I?
Originally posted by Ilja Preuss:
Hell, I even wouldn't know how to design without "seeing the accompanied code in my head".

I rather miss a lot. I always thought that architect or programmer-analyst designs, writes in words, defend those descriptions to get financing and after getting money, hire someone to write the corresponding code.
Originally posted by Ilja Preuss:
The only real semantic difference [from asociation] is that there is no cycle allowed in aggregation.

I am getting to this phrase because I see it over and over again. I cannot see how it illustrates any semantics because I even cannot recall any, even single example of, cyclic implementation of association. Does this phrase mean that the only purpose of aggregation is to exclude the potential threat of cycle?! I may give counterexample: any object is simultaneously the whole and the part of itself.
Originally posted by Vikrama Sanjeeva:
I dont think that the method getAccountType is placed in AccountType class and Account class send message to AccountType for asking account type.Rather this information is provided as soon as Account instance is created, possibly via Account's constructor.

Account instance might not be created at all as far as semantically Account is just abstract notion or even an interface to concrete SavingsAccount and CurrentAccount. It is overtypical model example in all UML compliant illustrations.
It is used for illustration of a couple of dozens of patterns. For ex., Change an Object's Class at Run-Time (State Pattern)
http://ootips.org/state-pattern.html,
Originally posted by Frank Carver:
It might even be that Account doesn't actually need to know about AccountType at all - maybe they would be better aggregated together into another class.

What I wanted to write. I am bad in patterns but it seems to me that it is called Visitor Pattern?
Originally posted by Piyush Daiya:
As u have mentioned Pradeep, u want account type in account class i.e account type is attribute of account class.Hence the relationship you have to show is association.
Inheritance is type of generalisation relationship.(A Generalisation relationship is relationship among classes where one class shares the structure and/or behaviour of one or more classes).
Since, you havent mentioned anything about sharing structure or anything between Account or AccountType, inheritance is not the relationship between the classes.
Association relationships can be of Aggregation and Composition types.
HTH,

Originally posted by Ilja Preuss:
Oh, ok – if it is a given that Account holds a reference to AccountType, it

Relationship doesn't mean inevitably association PERIOD
Association doesn't mean Aggregation or Composition PERIOD
Association doesn't mean having necessarily references THREE PERIODS
Fowler, Martin. UML distilled: a brief guide to the standard object modeling language / Martin Fowler with Kendall Scott. - 2nd ed., 2000, Addison Wesley
p.52
Associations represent relationships between instances of classes...
p.54
An association also implies responsibility for updating the relationship. ...
These responsibilities do not apply to data structure, however... I cannot and should not be able to tell whether the Order [Vanin: read "one" instead of "Order"] class contains a pointer to Customer [Vanin: read "another class" instead of "Customer"], or whether the Order class fulfils its responsibility by executing some selection code that asks each Customer whether it refers to given Order.
p.57
"So a parameter reference, or the creation of an object, does not imply an association, you model those with dependencies (see Chapters 6 and 7)"

Originally posted by Ilja Preuss:
Well, all [composition] it adds over aggregation is lifetime responsibility -

I do not agree because association already has life-time responsibility.
Fowler, Martin. UML distilled: a brief guide to the standard object modeling language / Martin Fowler with Kendall Scott. - 2nd ed., 2000, Addison Wesley
p.57
An association represents a permanent link between two objects [Vanin's comment: I would have said between object's populations]. That is, the link exists during the whole lives of the objects, although the instances that are connected may change over time (or, in optional association, be empty). So a parameter reference, or the creation of an object, does not imply an association, you model those with dependencies (see Chapters 6 and 7)"

Originally posted by Ilja Preuss:
And I think Account somehow probably would want to send messages to AccountType.

I couldn't even understood Account as a concrete entity... Account could have been an abstract superclass to concrete classes CurrentAccount and SavingsAccount. But I never use/honor inheritance from political convictions and also because:
Originally posted in
Mark Grand, Patterns in Java: a catalog of reusable design patterns illustrated with UML, Volume 1. - 2nd ed., 1999, John Wiley & Sons
p.56
"Delegation is more general purpose than inheritance. Any extension to a class that can be accomplished by inheritance can also be accomplished by delegation "
"Some inappropriate uses of inheritance are so common that they can be classified as antippaterns. In particular, subclassing utility classes and using inheritance to model roles are common design flaws"


Originally posted by pradeep anandan:
As in RDBMS we have 2 different tables one for Acccount type and other Account and have a foreign key relationship
will the same is applied in OOPS where The rate of interest differs with the account type

To me this phrase is broken both lexically and semantically but I would tell that foreign-key relationship needs in almost cases Association class.
Originally posted by Ilja Preuss:
And don't get fooled into the thinking that you need to somehow "finish" analyzing before you may start designing or even should have finished your design before you start coding.

To me analysis is disintegration of problem domain to atomic elements and notions. Design is synthesis from those bricks. I do not know anyone who builds a building using floors, corners, rooms of the previous building...
Yeap Ilja,
You are right.Analysis and Design are to be done iteratively.
Piyush

I agree. But this doesn't mean using unfinished/incomplete analysis results at each stage!
BTW the literature (books, articles) on OOAD, patterns are full of discussion of, first of all, Account-SavingsAccount, CurrentAccount models, relationships, patterns, antipatterns. I am surprised that these notions happened to be so mysterious /unspecified. You cannot find a single book on patterns, CASE, OOAD without bank accounts model!
But relations may be quiet complex. For ex., there could be a contract that if the CurrentAccount balance drops below certain minimum, then money automatically is back-up-ed from the SavingsAccount (excellent illustration of pre-, post-conditions and invariants).
If the total amount of money (dinheiro, dengi, dollari, euros) disappear/vanishes then accounts change the state to frozen/closed, with quite a different character and behaviour (who may and may not access it, use credit card,
etc).
This is the perfect case of illustration of 2 dozens of patterns.
Since Java doesn't have (?) dynamic types (as well as other mappings to UML notions) then the models and patterns would depend on language orientation, etc.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Guennadiy VANIN:
I rather miss a lot. I always thought that architect or programmer-analyst designs, writes in words, defend those descriptions to get financing and after getting money, hire someone to write the corresponding code.

Well, possibly there are peoply working that way, but I have never seen it in action and can't imagine it working very well. In my experience, for developing a good design you need *much* feedback from the implementation.
I am getting to this phrase because I see it over and over again. I cannot see how it illustrates any semantics because I even cannot recall any, even single example of, cyclic implementation of association.

Imagine a Finite State Machine. An association between states represents an allowed transition. A transition from a state to itself is perfectly valid, as well as other forms of cycles.
Does this phrase mean that the only purpose of aggregation is to exclude the potential threat of cycle?! I may give counterexample: any object is simultaneously the whole and the part of itself.

Depends on your definition of "part of"... (In the mathematical sense, it isn't.)
It's always somewhat risky to use natural language for such technical concepts. "PART OF" (as well as "IS A" etc.) simply isn't strictly defined. I'd rather see them as heuristics, not as definitions.
Relationship doesn't mean inevitably association PERIOD
Association doesn't mean Aggregation or Composition PERIOD
Association doesn't mean having necessarily references THREE PERIODS

You are right, of course. No reason to get loud...
Well, all [composition] it adds over aggregation is lifetime responsibility -
--------------------------------------------------------------------------------

I do not agree because association already has life-time responsibility.

Does it? Could you explain, please?

I would tell that foreign-key relationship needs in almost cases Association class.

Using extra tables for the additional fields of a subclass is a perfectly valid way of modeling inheritance in an RDBMS.
To me analysis is disintegration of problem domain to atomic elements and notions. Design is synthesis from those bricks. I do not know anyone who builds a building using floors, corners, rooms of the previous building...

That is because bricks are much more expensive to rearrange than bits...
You are right.Analysis and Design are to be done iteratively.
Piyush
I agree. But this doesn't mean using unfinished/incomplete analysis results at each stage!

When do you call analysis finished/complete? How do you know you reached that state?

You cannot find a single book on patterns, CASE, OOAD without bank accounts model!

You can! "Agile Software Development - Principles, Patterns and Practices" by Robert C. Martin.
Regards, Ilja
[ January 31, 2003: Message edited by: Ilja Preuss ]
Fintan Conway
Ranch Hand

Joined: Apr 03, 2002
Posts: 141
Originally posted by Ilja Preuss:

I think there is even more required than detail about the domain. Keep in mind that the *only* job of the design is to foster implementation - and the implementation is much more about the solution than about the problem.
So even if you had enough detail to model the domain (what you probably would call an analysis model), there simply is no mechanic way to get to the design. You *need* to think about the solution (the implementation) to give it a first rough shape (what you probably would call the initial design in this context).
So even if in the domain an Account "HAS AN" AccountType, there is no direct way to tell wether Account should have an association to AccountType, or wether those classes should even exist in the design.

In all good texts / discussions on Design Patterns one of the first things emphasised is that a Design Pattern provides a solution
within a particular CONTEXT (sorry for being so loud Ilja )
What I think Ilja and Frank are asking here is "What is the context in which the Account and AccountType classes are used?"
The appropriate way to design these classes will depend on this context, i.e. what is the code trying to use these classes for?
Regards,
Fintan
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Fintan,
couldn't have said it better!
Vikrama Sanjeeva
Ranch Hand

Joined: Sep 02, 2001
Posts: 756
Hi,

Originally posted by Guennadiy VANIN:
Account instance might not be created at all as far as semantically Account is just abstract notion or even an interface to concrete SavingsAccount and CurrentAccount. It is overtypical model example in all UML compliant illustrations.

I agree!
Bye,
Viki.
 
GeeCON Prague 2014
 
subject: Class Diagram -Association & Inheritance