But I can't see why UML should legally be used to describe completely Non-Software things like bread, dough, flour. Any thought?Thomas, this is a really good question.
[size=13]Thought you'd get a kick out of this one!
My Aunt died this past January. CitiBank billed her for February and March for their monthly service charge on her credit card, and then added late fees and interest on the monthly charge...the balance had been $0.00... now was somewhere around $60.00)
I placed the following phone call to CitiBank:
Me: "I am calling to tell you that she died in January."
CitiBank:
"The account was never closed and the late fees and charges still apply."
Me: "Maybe, you should turn it over to collections..."
CitiBank: "Since it is 2 months past due, it already has been."
Me: "So, what will they do when they find out she is dead?"
CitiBank: "Either report her account to the frauds division, or report her to the credit bureau...maybe both!"
Me: "Do you think God will be mad at her?"
CitiBank:"...excuse me .?"
Me: "Did you just get what I was telling you.... the part about her being dead?"
CitiBank: "Sir, you'll have to speak to my supervisor!"
(Supervisor gets on the phone)
Me: ''I'm calling to tell you, she died in January."
CitiBank: "The account was never closed and the late fees and charges still apply."
Me: "You mean you want to collect from her estate?"
CitiBank: ".....(stammer)"
CitiBank: "Are you her lawyer?"
Me: "No, I'm her great nephew." (Lawyer info given... )
CitiBank: "Could you fax us a certificate of death?"
Me: "Sure." ( Fax number is given ) ( After they get the fax. )
CitiBank: "Our system just isn't setup for death..."
Me: "Oh..."
CitiBank: "I don't know what more I can do to help..."
Me: "Well... if you figure it out, great! If not, you could just keep billing her...I suppose...don't really think she will care...."
CitiBank: "Well...the late fees and charges do still apply."
Me: "'Would you like her new billing address?"
CitiBank: "That might help."
Me: " ( Odessa Memorial Cemetery #### Hwy 129 and plot number given. )
CitiBank: "Sir, that's a cemetery!"
Me: "What do you do with dead people on your planet?!!"[/size]
[size=13][SNIP][/size]bruce,
P,J,
I'm having trouble with the original precepts in "Collections, Containers, Composites & Nests" - I have tried out the precepts on a Cricket Club mebership model and cant reconcile that example against all the precepts. My point? Don't get stuck in using one example to investigate the abstractions.
bruce
these things are a moving target...but is it consistently moving? ;D
When I got into work this morning, I found this in my inbox...
I case my rest... ;D
I guess the requirement "Citibank customers are not allowed to die" was not written down in the section specification. Another case of a wrong model...Thomas,
[size=13][SNIP][/size]What is the purpose of an Information System? Jean Raymond Abrail (who started me on this modelling lark 30 years ago) had a simple view:
3) It is extremely difficult and very expensive to use a model that does not express the real-world accurately. In this context I mean both a UML model and a Management Information System (MIS). If clients are to get value from their MIS, the MIS must be a model of the business and react to its inputs in the same way the business reacts to its inputs. Otherwise, use of the MIS, as a decision support system, would yield bad management decisions.[size=13][SNIP][/size]
4) I involve clients in the modeling process as much as I can, for it makes them think formally about their domain. They don't often get a chance to do this in their work-a-day activities.I used to say: "Automating a business that makes sense is actually relatively easy. Automating one that doesn't make sense is impossible. Now which one are you?" ;D
[size=13][SNIP][/size]
I guess the requirement "Citibank customers are not allowed to die" was not written down in the section specification....It surely was a wrong model, but the interesting question is how did this come about?My guess is that it was written down, then deleted by the Marketing Department...bad press and all that.. ;D PS: How do you guys make the [snip] thing appear?
The point is: I model the world first, then the industry, then the enterprise, then the processes.I follow a similar approach, but I model the company's Charter (explains how the company is like others of its type), then Mission (explains how they are different from the others), then Goals (strategic steps to executing the Mission), then Organizational Structure (how they divide their labor in to distinct tasks, and achieve coordination among them), then Policy (their guidelines for making decisions), then Procedures (ways of achieving results or making decisions), then Rules (which are substitutions for thinking). Environment is analyzed in parallel with these as it provides: needed resources, cultural influences, regulatory control, and product markets. Problems & Opportunities are analyzed in terms of Actuals & Should bes, the variances between them, the forces creating the variances, and who cares enough about them to sponsor & participate in a project to do something about them. A dose of additional stakeholders and their inputs and I'm ready to start my design. The new/enhanced MIS then becomes a tool for removing the variance in the problem/opportunity model.
How do you guys make the [snip] thing appear?
I follow a similar approach ...
I rarely tell a client I'm developing a UML model; ...
Sorry...This thread hit one of my hot buttons and got me to pontificating a bit :-[
Quote this and you'll see???
As regards the dead account holder, in terms of the model, perhaps the missing detail was "reasons for closing account (#27) - death of account holder / action - reconcile account credit balance with estate as of date of death, cancel any charges accruing after date of death."With respect, young mike, I believe you are hoist by your own petard... ;)
... since as far as the system goes, you should just be modelling the lifecycle of the account, not (ahem) the lifecycle of the account-holder.
Well, it's just an event (with all due respect to the deceased ...)Yes, but it's not a disembodied event (pun intended) ;D
[SNIP]The event is the fact of the account holder's death. How do you manage the other accounts without the account holder and their death? [SNIP]Perhaps we have joint ownership or a transfer of the account's ownership? ;D
Perhaps we have joint ownership or a transfer of the account's ownership? ;DThat doesn't alter the fact that all the accounts for which this person is an account holder are candidates for closure. They have to be examined and a decision reached.
I suggest the model was missing an Inheritance feature? :-/
Well I agree with Mike and Paolo... It is the responsibility of the Account object to deal with a death of account holder event; it is the responsibility of the Account Holder object to pass death of account holder events on to each Account object; and it is the responsibility of the Requirements Analyst to remember to put the possibility of such events in the spec in the first place!I'm actually saying more than that... I'm saying it is the responsibility of the Person object to notify the Account Holder object that it died. Because this person is also an Employee of the bank, person has to notify employee also. Oh, and by the way, the person also had a housing loan... And was the employee elected director on the board...
...it is the responsibility of the Person object to notify the Account Holder object that it died...
I'm saying it is the responsibility of the Person object to notify the Account Holder object that it died....Dead people talking to the living? ??? My world doesn't work that way. In such situations, the death notifications always came by way of direct observation (I killed it, I saw it happen, etc.) or from 3rd parties (Stewards, executors, friends, etc.). I think it might be the same for the death of a network connection object as a result of a loss of communication. I suggest that the dead are not always able to speak.
The world works the way the enterprise sees it - NOT!
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).Apparently not. ;D 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.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.
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...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.
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.
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 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 :o 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.
When an account holder ceases to exist, any accounts held solely by them must be closed.
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?
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.Kevin,
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.
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. :)
I'm not surprised that many programmers use the UML Icons like another green plastic stencil set.Ah... (Nostalgically) those beautiful (German) Green Plastic Stencil sets... There MUST be a UML one!