Sense of UML

[mikewhit]

That's what I was getting at.

There is no need to model the lifecycle of the person - only to respond to such events as the system may receive from the real world: which must of course have been accurately enumerated by the RA.

I just need an abstraction of an account-holder, not a Person.

Well, I can see a distinction :-)

[Kevin Brennan]

It seems to me that there's a little confusion here between the problem domain (the real world which we model) and the solution domain (what is inside the computer).

In the real world, the person dies. But in our solution, is death a terminal state? (Sorry).

As a requirements analyst, I'd have to ask how the system gets informed of the real-world event and what happens next. I'd imagine that the process is distinct from simple account closure. If a person closes their own account, that's their perogative. In this case you need to verify that some other person has the legal authority to close the account, which probably entails some proof of death and stuff that impacts other accounts.

So I'd start with a use case like "Accept Customer Death" and go from there.  Depending on the circumstances accounts might be transferred, closed, etc.

From the analysis perspective, account-holder is an association class between Person and Account, I think, not a class that exists in the absence of those things? But I guess it depends on your domain...

[mikewhit]

Crikey, I seem to have summoned up a Business Analyst !

Thanks !

[jeshaw2]

It seems to me that there's a little confusion here between the problem domain (the real world which we model) and the solution domain (what is inside the computer).

As a business Policy Analyst, I'd have to say that the solution domain is a subset of, and is located within, the problem domain. Business management must first define the solution as policy before a solution procedure can be modeled by their computer enabled MIS. Technology is not a solution, its a tool. MIS is not a solution, its a model just as is the Situation Board on a military aircraft carrier. The solution policy is manifested within an MIS model of a computational procedure which is realized within a computing technology.    Therefor, our Computationally Independent Model (CIM) must model the solution within a business domain.

In the real world, the person dies. But in our solution, is death a terminal state? (Sorry).

Apparently not.  and for good reason too.  However, It would appear that the isDead attribute is missing along with the heDied event and the letsBuryHim event handler.

As a requirements analyst, I'd have to ask how the system gets informed of the real-world event and what happens next.

An excellent question! See reply #3 above by Paolo for a statement of the tacit policy.  Hopefully, the management policy is not properly promulgated which is an easy fix.

I'd imagine that the process is distinct from simple account closure. If a person closes their own account, that's their prerogative. In this case you need to verify that some other person has the legal authority to close the account, which probably entails some proof of death and stuff that impacts other accounts.

So I'd start with a use case like "Accept Customer Death" and go from there.  Depending on the circumstances accounts might be transferred, closed, etc.

This is good stuff!    The need to make these kinds of inferences is why the analyst needs business domain knowledge and experience.  When these skills are not present, essential requirements are often not fully elaborated.

From the analysis perspective, account-holder is an association class between Person and Account, I think, not a class that exists in the absence of those things? But I guess it depends on your domain...

Excellent point Kevin...Look everybody! This is why it is so important to get things named and typed correctly! Perhaps account-holder is a class that is better named BankCustomer.? :-/  And, perhaps BankCustomer is not a model of a person, but of a legal entity having the features of a composite involved in a <<part_Of>> relation with accounts?  And perhaps this confusion underlies the disjointedness of the conversation with CitiBank's Customer Service Representative.

Good show Kevin  

[Kevin Brennan]

As a business Policy Analyst, I'd have to say that the solution domain is a subset of, and is located within, the problem domain. Business management must first define the solution as policy before a solution procedure can be modeled by their computer enabled MIS.

I think what we have here is a difference in terminology, not a substantive disagreement.

Here's what I mean by those words (my definitions are based on Michael Jackson's problem frames).

The real world is, of course what we actually seek to describe. The portion of it that's of interest to us is captured in a problem domain model, which describes what we know about the things in the real world. Here we talk only about things that actually exist in some form.

The goal is to build a software application, the workings of which are captured in a solution domain model. The purpose of this application is to alter the workings of problem domain and thus produce effects in the real world. Those effects are what we call requirements.

Using these terms, policy falls in the solution domain because it seeks to procude effects in the real world. The reason I define it this way has a lot to do with the work I'm currently doing to codify and define the role of the BA--a BA should be asking whether the policy achieves the business goal, not just if the system correctly implements the policy.

[jeshaw2]

The goal is to build a software application, the workings of which are captured in a solution domain model. The purpose of this application is to alter the workings of problem domain and thus produce effects in the real world. Those effects are what we call requirements.  
 
Using these terms, policy falls in the solution domain because it seeks to procude effects in the real world. The reason I define it this way has a lot to do with the work I'm currently doing to codify and define the role of the BA--a BA should be asking whether the policy achieves the business goal, not just if the system correctly implements the policy.

I understand your point and agree that we are very close, but I do have some problem with Jackson's perspectives; [skimming your reference, it appears that] he makes a mistake similar to Jacques Ellule in his treaties on Technology.  I shall read Jackson more deeply...

It is important, at least to me, that we don't misplace the responsibility for effecting change. Technology does not alter behavior (unless perhaps it is a dangerous weapon), it enables changes in behavior (or in the case of a weapon, encourages changes).  The responsibility for effecting a solution in this domain is the domain's management, not the application system nor its manifestation in a list of new/modified Requirements.  I'm sure you understand this, but my students like to read this forum too.

I am uncomfortable with wording that software is the effector of change. New software can be implemented, but without the management force, no change will occur; the old system is just driven underground.  

[Paolo F Cantoni]

I guess Paolo forgot that there is no one-to-one relation between model and real world. Whilst (computer-)objects can be held responsible for being killed/about to being dead, the real world does not offer such a feature For me, I'm not able to find my destructor operation. Except I'll commit suicide and arrange everything in advance. Or maybe my testament should be set up accordingly

Well actually I didn't forget that the model isn't the world.

Above my desk at work I have the following picture by Rene Magritte:
.  Its title is Le trahison des images (the treachery of images).  The text - which is formally part of the picture - says: "This is not a pipe".  I call it The Modeller's Picture.  It's there to remind us all that the model is not reality.

But it should approach reality in the facts it contains and can manage.

The person object needs to be able to hold all the necessary facts about the person it is tracking.  Including their death.  The death of the person and the destruction of the person object are two distinct things.

Paolo

[Paolo F Cantoni]

I think it would be instructive to have some diagrams posted concerning the problem of the dead account holder.  I certainly found the bread modelling instructive for the analysis of meronymy.

If anyone wants to start, I suggest:

Environment:
Each Account has one or more Account Holders
Each Account Holder is a Business Entity (can be sued)
A Business Entity may be a Corporate Entity or An Individual.

Business Rule:
When an account holder ceases to exist, any accounts held solely by them must be inactivated (awaiting executor instruction).  Any accounts held jointly must be flagged for further action.

Paolo

Edit: blue changes as per bruce's comments below...

[sargasso]

When an account holder ceases to exist, any accounts held solely by them must be closed.

In actual fact, under the current Oz regs they cannot do that.

"any accounts held soley by them must be inactivated awaiting instructions from the executor of the will"


bruce

[mikewhit]

There's probably a similar sentence dealing with bankruptcy, where the accounts are similarly inactivated awaiting instructions from the bankruptcy court ... [shudder !]

[Paolo F Cantoni]

There's probably a similar sentence dealing with bankruptcy, where the accounts are similarly inactivated awaiting instructions from the bankruptcy court ... [shudder !]

Of course, but I thought we'd keep it simple first.  Perhaps we could add this rule later and watch the effect on the previously agreed model?

Paolo

[Kevin Brennan]

I believe this confuses the possible lifecycles of a Person and an Organization. As you stated the rule, both can die and require the system to wait for a will to be executed.

In practice Organizations can dissolve, go bankrupt etc. but not die. You need to model their lifecycles and then figure out how the account should respond to state changes in the Account Holder.

[Paolo F Cantoni]

I believe this confuses the possible lifecycles of a Person and an Organization. As you stated the rule, both can die and require the system to wait for a will to be executed.

In practice Organisations can dissolve, go bankrupt etc. but not die. You need to model their lifecycles and then figure out how the account should respond to state changes in the Account Holder.

Kevin,
That's interesting.  I've always modelled that an Organization CAN die.  But your point is well taken.

Also, I think one needs to distinguish between the British/Australian (and possibly other European) Legal view and the and the US Legal view about the status of the Corporate Entity.

It has been put to me that one of the reasons that US companies are so aggressive is that under US Law they have all the accoutrements of an individual except the right to vote.  Thus the directors need not be personally liable.  I believe this is not the case in the other jurisdictions.  The directors in the British system provide the "animus".  Thus when an organisation "dies", there is no "will" since it had no animus to begin with.  

Hence the model (at least in those jurisdictions) can hold that both Individuals and Organisations die, but only Individuals can (optionally) leave a will to be executed.

My 2c

Paolo

[mcoletti]

I rarely tell a client I'm developing a UML model; creates too much anxiety on their part.  I just stand at a White-board as we talk about their domain and make my notes thereon in UML.  With a simple explanation of an element, as I introduce it in my diagram, my diagram becomes an Icon I can use in my documentation that, for them, triggers a remembrance of our conversations and the conclusions arrived at therein.  Gradually, and without knowing it, they learn UML.  

Really interesting thread!

Unfortunately, I am finding anxiety about UML also in developers, with two common side effects:

• usage of "free" formats for diagrams in software documentation;
  
• "free" use of UML icons to create diagrams that are not an expression of UML syntax.

In my view, the importance of UML is in the fact that it is a common "language" (so a set of grammar and syntax rules) that can be used to model different views at different levels.
The responsibility of an "UML evangelist" in an organization, is to communicate the "syntax" of UML as a language (not its icons!) allowing to lower the communication barriers among domain experts, managers, organization analysts, software architects and developers.

Thanks to jeshaw2 for his illuminating "pontification".

Cheers,

Massimo

[jeshaw2]

mcoletti;
Unfortunately, I'm finding too many UML "instructors" that don't understand the grammar either.  UML courses simply describe diagram types and Icons, providing only "see Jane run" examples.  

There are many Advanced UML books that deal with more complicated examples, but they simply say "draw it this way" without really explaining "why this way".

I'm not surprised that many programmers use the UML Icons like another green plastic stencil set.