Does the time clock have the enterprise business
features that color modeling was created to deal with?


--- David J Anderson <netherby_uk@...> wrote:

> Gee! They must be using PSP/TSP. The time clocks are
> a key feature
> in PSP. We've had to develop one internally at
> Microsoft.
>
> Anyway, Clark is suggesting it as an application we
> might want to
> consider. Should I create a vote, based on the
> various suggestions?
>
> David
>
> --- In colormodeling@yahoogroups.com, "Clarke Ching"
> <lists@c...>
> wrote:
> >
> > Howabout this for a toy project.
> >
> >   _____
> >
> > From: scrumdevelopment@yahoogroups.com
> > [mailto:scrumdevelopment@yahoogroups.com] On
> Behalf Of
> acockburn@a...
> > Sent: 15 June 2005 15:39
> > To: scrumdevelopment@yahoogroups.com
> > Subject: [scrumdevelopment] Easy to use
> time-keeping tool
> >
> >
> > Where I am working, one person asked me if there
> wasn't available
> some sort
> > of really easy to use time-keeping tool he could
> keep open on his
> > workstation ---
> >
> > --- He was thinking of something like a chess
> clock with a running
> number
> > and a big Continue button and a big Pause button
> ---
> >
> > This way, when he gets interrupted for a visitor
> or a phone call
> or a
> > meeting, he can hit Pause then later hit continue.
> What he's
> after, is not
> > only to show how much time he spent on each
> assignment, but also
> show (by
> > subtraction) how much time he's spending handling
> interrrupts.
> >
> > Presumably he could run several of them for when
> he's working on
> several
> > different project numbers...
> >
> > ... Anyway, he asked if I knew of any such things,
> he was pretty
> sure
> > someone in the agile world would have written one
> by now ...
> >
> > Anyone seen such a type of thing?
> >
> > Alistair
> >
> >
> >
> >
> >
> > To Post a message, send it to:
> scrumdevelopment@e...
> > To Unsubscribe, send a blank message to:
> > scrumdevelopment-unsubscribe@e...
> >
> >
> >
> >   _____
> >
> > Yahoo! Groups Links
> >
> >
> > * To visit your group on the web, go to:
> > http://groups.yahoo.com/group/scrumdevelopment/
> >
> >
> > * To unsubscribe from this group, send an email
> to:
> > scrumdevelopment-unsubscribe@yahoogroups.com
> >
>
<mailto:scrumdevelopment-unsubscribe@yahoogroups.com?
> subject=Unsubscribe>
> >
> >
> > * Your use of Yahoo! Groups is subject to the
> Yahoo! Terms of
> Service
> > <http://docs.yahoo.com/info/terms/> .
>
>
>


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

Let's do payroll first and come back to this. I also liked the timer
example - just because it is different.

--- In colormodeling@yahoogroups.com, Dean Schulze
<dean_w_schulze@y...> wrote:
>
> How about a simple calendar/scheduler project similar
> to the calendat in Microsoft Exchange?  You can
> schedule resources (i.e. meetings in a room, use of a
> projector) with various people.
>
> It has moment-intervals, people, things, descriptions.
>  Roles would probably fit in but I can't think of
> where off-hand.
>

Good to have you on-board Craig.

For the wider audience, your example of marriage would use a Groom a
yellow <<role>> coupled to Bride a yellow <<role>> through Marriage
a pink <<moment-interval>> in this case specifically an interval of
time with a start and end date.

Would anyone like to suggest the obvious previous <<Moment-
Interval>> class and potential subsequent <<Moment-Interval>> class
that would give us a sequence of pinks per the Domain Neutral
Component model? ;-)

--- In colormodeling@yahoogroups.com, Craeg Strong <cstrong@a...>
wrote:
> Hello:
>
> In the projects I have worked on, I usually end up needing to
reify
> relationships.
> Following this approach, you would have a Customer relationship
that
> exists between two roles.
> You can then decide whether the roles are both simply PartyRoles,
or you
> could have two different kinds of
> Customer relationships, namely BusinessCustomer and
IndividualCustomer.
>
> Even better, the standard complaint about Java's lack of support
for
> method return covariance is fixed in Tiger.
> Now you can have a method like getToRole() [assuming a directed
> relationship has a to- role and a from- role]
> that returns a PartyRole for the base Customer relationship but
returns
> an OrgRole for a BusinessCustomer relationship.  At last!
>
> The relationship pattern is pretty robust, the most obvious/basic
> example being marriage between the roles
> of bride and and groom.  Note that the start and end date of the
> marriage are properties of the marriage relationship,
> not properties of the roles nor the parties filling the roles.
>
> My background...
> I read the original color modeling book, but by that point I had
already
> been "tainted" :-) by reading
> Martin Fowler's "Analysis Patterns" and Len Silverston's "Data
Model
> Resource Book."
> Since that time, I have been expanding on these patterns and
modeling in
> color, although not strictly
> adhering to Coad's color scheme.  I am interested in seeing where
the
> confluence of these good ideas can lead us.
>
> Regards,
>
> --Craeg Strong
>
> David J Anderson wrote:
>
> > Wow! This is an advanced topic - can we pick an easier one
before we
> > scare people away.
> >
> > The history of the superclasses revolves around Peter's move,
with
> > his collaborators Jill Nicola and Mark Mayfield to develop
pluggable
> > enterprise components that could be "wire wrapped". The super
> > classes and their associations are design to abstract away the
hard
> > interface knowledge that normally exists between a green
<<Person-
> > Place-Thing>> (or <<PPT>>) and its yellow <<role>> delegates.
> >
> > Steve Palmer wrote a good Coad Letter on this and I covered it
in my
> > Borcon paper [see, agilemanagement.net home page for the list of
> > these articles]
> >
> > Using a PartyRole superclass is for advanced decoupling. It
might be
> > easier if you simply did away with it. Simply couple the specific
> > <<role>> classes to your Person or Organization green classes.
> >
> > The purpose of the superclass or interface is to allow a green to
> > hold a collection of yellows that are bound at runtime - not
compile
> > time. The rules determining whether a green can hold a yellow
> > association are described in a blue description class attached to
> > the green. When a yellow role wants to bind to a green then the
> > green has to ask its blue description for permission to play that
> > role.
> >
> > I doubt if you really need this runtime bound flexibility - at
least
> > at this stage. On balance I'd say it is adding risk and
complexity
> > to your architecture and project and you aren't going to need
it ;-)
> > Yes, we do YAGNI in color modeling too. So simplify but record
where
> > you simplified and what the benefits might be of adding back the
> > complexity for the future.
> >
> > David
> >
> > --- In colormodeling@yahoogroups.com, David Carter
> > <d.david.carter@g...> wrote:
> > > In JMCU ("The Coloring Book"), Coad introduces us to the Party
&
> > > PartyRole components. Party role specializes into PersonRole,
> > OrgRole,
> > > and also into various roles that can be played by either a
Person
> > or
> > > an Organization, such as Customer.
> > >
> > > In my current project, we are applying this pattern, but
struggling
> > > with how we should model our Customer classes. In the domain,
we
> > have
> > > concepts of "Customer" (really an individual customer) and
> > > "BusinessCustomer".
> > >
> > > Approach 1:
> > > - Customer derives from PersonRole
> > > - BusinessCustomer derives from OrgRole
> > > - pros: follows the pattern in the book, BusinessCustomer can
use
> > the
> > > OrganizationalUnit construct via relationship inherited via
OrgRole
> > > - cons: no common BaseCustomer class for behavior/data shared
by
> > > Customer & Business Customer
> > >
> > > Approach 2:
> > > - BaseCustomer derives from PartyRole
> > > - both Customer & Business Customer derive from BaseCustomer
> > > - pros: BaseCustomer provides behavior/data common to all
customers
> > > - cons: doesn't make use of the PersonRole/OrgRole distinction
in
> > the pattern
> > >
> > > I think to make this decision, I need a better understanding
of the
> > > purpose of the PersonRole/OrgRole dichotomy. It is not well-
> > detailed
> > > in the book. There are no listed properties or methods on
either of
> > > these classes, other than the optional OrgRole association to
> > > OrganizationalUnit.
> > >
> > > I assume the primary purpose of the PersonRole is as a marker,
for
> > use
> > > in validation rules along the lines of "if
> > > (partyRole.isInstanceOf(PersonRole))", to verify that the given
> > > PartyRole subclass instance can take part in a particular
> > > relationship.
> > >
> > > Any advice on what to consider in making this decision? Or
does it
> > not
> > > warrant the degree of agonizing we're going through right now?
> > Perhaps
> > > we should be more agile, pick one approach that appears to work
> > now,
> > > and be prepared to refactor later if we find it doesn't work
for
> > us?
> > >
> > > --
> > > David Carter
> > > david@c...
> >
> >
> >
> > -----------------------------------------------------------------
-------
> > *Yahoo! Groups Links*
> >
> >     * To visit your group on the web, go to:
> >       http://groups.yahoo.com/group/colormodeling/
> >
> >     * To unsubscribe from this group, send an email to:
> >       colormodeling-unsubscribe@yahoogroups.com
> >       <mailto:colormodeling-unsubscribe@yahoogroups.com?
subject=Unsubscribe>
> >
> >     * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
> >       Service <http://docs.yahoo.com/info/terms/>.
> >
> >

Let's be very agile and just start with a vision statement.

Payroll.com is a new startup which will offer outsource payroll
services to small and medium size business in the USA. It will hold
the HR records for its clients and arrange for paychecks or bank
transfer according to the employers' agreements with their employees.

It will provide an online web based portal for both employees to
access their payroll details and for employers representatives to
upload payroll and employee information e.g. new hires, promotions,
pay rises, bonus payments etc.

The system will also provide the functionality for reporting the end
of year taxes such as the W2 Form.

Now let's model this domain. And then move on to define an FDD project
which will release a working increment every three months.

Would someone like to suggest where we start?


--- In colormodeling@yahoogroups.com, Steven Gordon <sagordon@a...>
wrote:
> Payroll sounds perfect.
>
> Do we assume that we all have the same application in mind, or
should we start with a designated customer or from a written set of
high level requirements?

How about a simple calendar/scheduler project similar
to the calendat in Microsoft Exchange?  You can
schedule resources (i.e. meetings in a room, use of a
projector) with various people.

It has moment-intervals, people, things, descriptions.
  Roles would probably fit in but I can't think of
where off-hand.


--- David J Anderson <netherby_uk@...> wrote:

> The problem with sharing real examples is that they
> are generally the
> intellectual property of the firm that paid for
> them. It's hard or
> impossible to do.
>
> The photos on my website are of real models on a
> real project but I
> deliberately obfuscated the class names on the
> Post-it notes.
>
> Toy project - why not? Go ahead and propose one. We
> can share images
> of models via the files section of the website.
>
> David
>
> --- In colormodeling@yahoogroups.com, "sjalq"
> <sjalq@y...> wrote:
> > I am hoping someone had some examples of color
> models that were
> > actually used in real projects. I think it will
> help greatly to have
> > such real world examples.
> >
> > Also, who would be up to participate in a toy
> project to demonstrate
> > the basics of CM, the DNC and FDD? Something
> simple and fun enough to
> > be motivating.
> >
> > -Schalk Dormehl
>
>
>
>




__________________________________
Discover Yahoo!
Find restaurants, movies, travel and more fun for the weekend. Check it out!
http://discover.yahoo.com/weekend.html

Hello:

In the projects I have worked on, I usually end up needing to reify
relationships.
Following this approach, you would have a Customer relationship that
exists between two roles.
You can then decide whether the roles are both simply PartyRoles, or you
could have two different kinds of
Customer relationships, namely BusinessCustomer and IndividualCustomer.

Even better, the standard complaint about Java's lack of support for
method return covariance is fixed in Tiger.
Now you can have a method like getToRole() [assuming a directed
relationship has a to- role and a from- role]
that returns a PartyRole for the base Customer relationship but returns
an OrgRole for a BusinessCustomer relationship.  At last!

The relationship pattern is pretty robust, the most obvious/basic
example being marriage between the roles
of bride and and groom.  Note that the start and end date of the
marriage are properties of the marriage relationship,
not properties of the roles nor the parties filling the roles.

My background...
I read the original color modeling book, but by that point I had already
been "tainted" :-) by reading
Martin Fowler's "Analysis Patterns" and Len Silverston's "Data Model
Resource Book."
Since that time, I have been expanding on these patterns and modeling in
color, although not strictly
adhering to Coad's color scheme.  I am interested in seeing where the
confluence of these good ideas can lead us.

Regards,

--Craeg Strong

David J Anderson wrote:

> Wow! This is an advanced topic - can we pick an easier one before we
> scare people away.
>
> The history of the superclasses revolves around Peter's move, with
> his collaborators Jill Nicola and Mark Mayfield to develop pluggable
> enterprise components that could be "wire wrapped". The super
> classes and their associations are design to abstract away the hard
> interface knowledge that normally exists between a green <<Person-
> Place-Thing>> (or <<PPT>>) and its yellow <<role>> delegates.
>
> Steve Palmer wrote a good Coad Letter on this and I covered it in my
> Borcon paper [see, agilemanagement.net home page for the list of
> these articles]
>
> Using a PartyRole superclass is for advanced decoupling. It might be
> easier if you simply did away with it. Simply couple the specific
> <<role>> classes to your Person or Organization green classes.
>
> The purpose of the superclass or interface is to allow a green to
> hold a collection of yellows that are bound at runtime - not compile
> time. The rules determining whether a green can hold a yellow
> association are described in a blue description class attached to
> the green. When a yellow role wants to bind to a green then the
> green has to ask its blue description for permission to play that
> role.
>
> I doubt if you really need this runtime bound flexibility - at least
> at this stage. On balance I'd say it is adding risk and complexity
> to your architecture and project and you aren't going to need it ;-)
> Yes, we do YAGNI in color modeling too. So simplify but record where
> you simplified and what the benefits might be of adding back the
> complexity for the future.
>
> David
>
> --- In colormodeling@yahoogroups.com, David Carter
> <d.david.carter@g...> wrote:
> > In JMCU ("The Coloring Book"), Coad introduces us to the Party &
> > PartyRole components. Party role specializes into PersonRole,
> OrgRole,
> > and also into various roles that can be played by either a Person
> or
> > an Organization, such as Customer.
> >
> > In my current project, we are applying this pattern, but struggling
> > with how we should model our Customer classes. In the domain, we
> have
> > concepts of "Customer" (really an individual customer) and
> > "BusinessCustomer".
> >
> > Approach 1:
> > - Customer derives from PersonRole
> > - BusinessCustomer derives from OrgRole
> > - pros: follows the pattern in the book, BusinessCustomer can use
> the
> > OrganizationalUnit construct via relationship inherited via OrgRole
> > - cons: no common BaseCustomer class for behavior/data shared by
> > Customer & Business Customer
> >
> > Approach 2:
> > - BaseCustomer derives from PartyRole
> > - both Customer & Business Customer derive from BaseCustomer
> > - pros: BaseCustomer provides behavior/data common to all customers
> > - cons: doesn't make use of the PersonRole/OrgRole distinction in
> the pattern
> >
> > I think to make this decision, I need a better understanding of the
> > purpose of the PersonRole/OrgRole dichotomy. It is not well-
> detailed
> > in the book. There are no listed properties or methods on either of
> > these classes, other than the optional OrgRole association to
> > OrganizationalUnit.
> >
> > I assume the primary purpose of the PersonRole is as a marker, for
> use
> > in validation rules along the lines of "if
> > (partyRole.isInstanceOf(PersonRole))", to verify that the given
> > PartyRole subclass instance can take part in a particular
> > relationship.
> >
> > Any advice on what to consider in making this decision? Or does it
> not
> > warrant the degree of agonizing we're going through right now?
> Perhaps
> > we should be more agile, pick one approach that appears to work
> now,
> > and be prepared to refactor later if we find it doesn't work for
> us?
> >
> > --
> > David Carter
> > david@c...
>
>
>
> ------------------------------------------------------------------------
> *Yahoo! Groups Links*
>
>     * To visit your group on the web, go to:
>       http://groups.yahoo.com/group/colormodeling/
>
>     * To unsubscribe from this group, send an email to:
>       colormodeling-unsubscribe@yahoogroups.com
>       <mailto:colormodeling-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>
>     * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>.
>
>

Payroll sounds perfect.

Do we assume that we all have the same application in mind, or should we start
with a designated customer or from a written set of high level requirements?

	 -----Original Message-----
	 From: colormodeling@yahoogroups.com on behalf of David J Anderson
	 Sent: Wed 6/15/2005 2:38 PM
	 To: colormodeling@yahoogroups.com
	 Cc:
	 Subject: [colormodeling] Re: Any examples available / Toy project


	 Ah Payroll.com - now you are prompting me to give away all my best
	 interview scenarios ;-)

	 Actually Payroll is a very good one - which is why we use it in
	 interview auditions. We give people a few Features, describe how
	 payroll.com is an outsource payroll company and ask the candidate to
	 model the domain, and design the 3 Features in one hour. They don't
	 need to use FDD or even UML. They can do it any way they like. What
	 I'm looking for is whether they can analyze and design and get their
	 head around the problem. I've hired great data modelers and turned
	 them in to color modelers later.

	 --- In colormodeling@yahoogroups.com, Ron Jeffries
	 <ronjeffries@X...> wrote:
	 > On Wednesday, June 15, 2005, at 3:48:02 PM, David J Anderson wrote:
	 >
	 > > Tell us more or point us at a paper we could read.
	 >
	 > > Dan Vacanti also has a poker game example which he might be
	 willing to
	 > > share as a toy project we could work on.
	 >
	 > The examples on my web site are numerous. Search for "bowling game"
	 > if interested. But I think the problem, which is designed to be
	 > implemented with TDD and discussed, all in a couple of hours, while
	 > rich enough for that purpose, requires too few objects for a useful
	 > experiment with FDD.
	 >
	 > Payroll might be fun. I haven't done that one for five or ten
	 years.
	 >
	 > Ron Jeffries
	 > www.XProgramming.com
	 > My advice is to do it by the book, get good at the practices, then
	 do as
	 > you will. Many people want to skip to step three. How do they know?

Ah Payroll.com - now you are prompting me to give away all my best
interview scenarios ;-)

Actually Payroll is a very good one - which is why we use it in
interview auditions. We give people a few Features, describe how
payroll.com is an outsource payroll company and ask the candidate to
model the domain, and design the 3 Features in one hour. They don't
need to use FDD or even UML. They can do it any way they like. What
I'm looking for is whether they can analyze and design and get their
head around the problem. I've hired great data modelers and turned
them in to color modelers later.

--- In colormodeling@yahoogroups.com, Ron Jeffries
<ronjeffries@X...> wrote:
> On Wednesday, June 15, 2005, at 3:48:02 PM, David J Anderson wrote:
>
> > Tell us more or point us at a paper we could read.
>
> > Dan Vacanti also has a poker game example which he might be
willing to
> > share as a toy project we could work on.
>
> The examples on my web site are numerous. Search for "bowling game"
> if interested. But I think the problem, which is designed to be
> implemented with TDD and discussed, all in a couple of hours, while
> rich enough for that purpose, requires too few objects for a useful
> experiment with FDD.
>
> Payroll might be fun. I haven't done that one for five or ten
years.
>
> Ron Jeffries
> www.XProgramming.com
> My advice is to do it by the book, get good at the practices, then
do as
> you will. Many people want to skip to step three. How do they know?

On Wednesday, June 15, 2005, at 3:48:02 PM, David J Anderson wrote:

> Tell us more or point us at a paper we could read.

> Dan Vacanti also has a poker game example which he might be willing to
> share as a toy project we could work on.

The examples on my web site are numerous. Search for "bowling game"
if interested. But I think the problem, which is designed to be
implemented with TDD and discussed, all in a couple of hours, while
rich enough for that purpose, requires too few objects for a useful
experiment with FDD.

Payroll might be fun. I haven't done that one for five or ten years.

Ron Jeffries
www.XProgramming.com
My advice is to do it by the book, get good at the practices, then do as
you will. Many people want to skip to step three. How do they know?

Clearly the "Party pattern" i.e. a superclass abstract green called
Party that has tangible subclasses such as Person and Organization
is a useful pattern. There is some reusable behavior and attributes
between the two. However, the association with an abstract PartyRole
or role interface is definitely advanced. The idea that you can late
bind roles to be played by, governed by pluggable rules, is not for
the beginnner, or even the general practitioner. I don't think we
fully understand it well enough yet to recommend it for production
systems.

Steve Palmer also has a great Coad Letter on greens and their
associated data classes such as Address, Contact Point and so forth.
This highlights where the Party super class can be useful.

David

--- In colormodeling@yahoogroups.com, David Carter
<d.david.carter@g...> wrote:
> David,
>
> Thanks for the detailed explanation!  Most of this detail is
> definitely left out of JMCU, but your description does ring some
bells
> from having once read Nicola & Mayfield's "Streamlined Object
> Modeling".
>
> I didn't realize this was an advanced question, since Party seems
to
> be one of the most basic patterns that almost any project will
need to
> implement. Maybe that's why we've been struggling so much to wrap
our
> minds around color modeling -- we picked an area we thought was
basic,
> but in reality is very abstract & complex.
>
> -David
>

But Amazon does show 19 available second-hand. . .

-David

On 6/15/05, Ron Jeffries <ronjeffries@...> wrote:
>  On Wednesday, June 15, 2005, at 2:27:35 PM, David Carter wrote:
>
>  > In JMCU ("The Coloring Book"),
>
>  Out of print, I note. Handy for those of us who want to know about
>  it ...
>

David,

Thanks for the detailed explanation!  Most of this detail is
definitely left out of JMCU, but your description does ring some bells
from having once read Nicola & Mayfield's "Streamlined Object
Modeling".

I didn't realize this was an advanced question, since Party seems to
be one of the most basic patterns that almost any project will need to
implement. Maybe that's why we've been struggling so much to wrap our
minds around color modeling -- we picked an area we thought was basic,
but in reality is very abstract & complex.

-David

On 6/15/05, David J Anderson <netherby_uk@...> wrote:
>  Wow! This is an advanced topic - can we pick an easier one before we
>  scare people away.
>
>  The history of the superclasses revolves around Peter's move, with
>  his collaborators Jill Nicola and Mark Mayfield to develop pluggable
>  enterprise components that could be "wire wrapped". The super
>  classes and their associations are design to abstract away the hard
>  interface knowledge that normally exists between a green <<Person-
>  Place-Thing>> (or <<PPT>>) and its yellow <<role>> delegates.
>
>  Steve Palmer wrote a good Coad Letter on this and I covered it in my
>  Borcon paper [see, agilemanagement.net home page for the list of
>  these articles]
>
>  Using a PartyRole superclass is for advanced decoupling. It might be
>  easier if you simply did away with it. Simply couple the specific
>  <<role>> classes to your Person or Organization green classes.
>
>  The purpose of the superclass or interface is to allow a green to
>  hold a collection of yellows that are bound at runtime - not compile
>  time. The rules determining whether a green can hold a yellow
>  association are described in a blue description class attached to
>  the green. When a yellow role wants to bind to a green then the
>  green has to ask its blue description for permission to play that
>  role.
>
>  I doubt if you really need this runtime bound flexibility - at least
>  at this stage. On balance I'd say it is adding risk and complexity
>  to your architecture and project and you aren't going to need it ;-)
>  Yes, we do YAGNI in color modeling too. So simplify but record where
>  you simplified and what the benefits might be of adding back the
>  complexity for the future.
>
>  David
>
>  --- In colormodeling@yahoogroups.com, David Carter
>
>  <d.david.carter@g...> wrote:
>  > In JMCU ("The Coloring Book"), Coad introduces us to the Party &
>  > PartyRole components. Party role specializes into PersonRole,
>  OrgRole,
>  > and also into various roles that can be played by either a Person
>  or
>  > an Organization, such as Customer.
>  >
>  > In my current project, we are applying this pattern, but struggling
>  > with how we should model our Customer classes. In the domain, we
>  have
>  > concepts of "Customer" (really an individual customer) and
>  > "BusinessCustomer".
>  >
>  > Approach 1:
>  > - Customer derives from PersonRole
>  > - BusinessCustomer derives from OrgRole
>  > - pros: follows the pattern in the book, BusinessCustomer can use
>  the
>  > OrganizationalUnit construct via relationship inherited via OrgRole
>  > - cons: no common BaseCustomer class for behavior/data shared by
>  > Customer & Business Customer
>  >
>  > Approach 2:
>  > - BaseCustomer derives from PartyRole
>  > - both Customer & Business Customer derive from BaseCustomer
>  > - pros: BaseCustomer provides behavior/data common to all customers
>  > - cons: doesn't make use of the PersonRole/OrgRole distinction in
>  the pattern
>  >
>  > I think to make this decision, I need a better understanding of the
>  > purpose of the PersonRole/OrgRole dichotomy. It is not well-
>  detailed
>  > in the book. There are no listed properties or methods on either of
>  > these classes, other than the optional OrgRole association to
>  > OrganizationalUnit.
>  >
>  > I assume the primary purpose of the PersonRole is as a marker, for
>  use
>  > in validation rules along the lines of "if
>  > (partyRole.isInstanceOf(PersonRole))", to verify that the given
>  > PartyRole subclass instance can take part in a particular
>  > relationship.
>  >
>  > Any advice on what to consider in making this decision? Or does it
>  not
>  > warrant the degree of agonizing we're going through right now?
>  Perhaps
>  > we should be more agile, pick one approach that appears to work
>  now,
>  > and be prepared to refactor later if we find it doesn't work for
>  us?
>  >
>  > --
>  > David Carter
>  > david@c...
>
>
>
>  ________________________________
>  Yahoo! Groups Links
>
>
> To visit your group on the web, go to:
> http://groups.yahoo.com/group/colormodeling/
>
> To unsubscribe from this group, send an email to:
> colormodeling-unsubscribe@yahoogroups.com
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.


--
David Carter
david@...

Gee! They must be using PSP/TSP. The time clocks are a key feature
in PSP. We've had to develop one internally at Microsoft.

Anyway, Clark is suggesting it as an application we might want to
consider. Should I create a vote, based on the various suggestions?

David

--- In colormodeling@yahoogroups.com, "Clarke Ching" <lists@c...>
wrote:
>
> Howabout this for a toy project.
>
>   _____
>
> From: scrumdevelopment@yahoogroups.com
> [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of
acockburn@a...
> Sent: 15 June 2005 15:39
> To: scrumdevelopment@yahoogroups.com
> Subject: [scrumdevelopment] Easy to use time-keeping tool
>
>
> Where I am working, one person asked me if there wasn't available
some sort
> of really easy to use time-keeping tool he could keep open on his
> workstation ---
>
> --- He was thinking of something like a chess clock with a running
number
> and a big Continue button and a big Pause button ---
>
> This way, when he gets interrupted for a visitor or a phone call
or a
> meeting, he can hit Pause then later hit continue. What he's
after, is not
> only to show how much time he spent on each assignment, but also
show (by
> subtraction) how much time he's spending handling interrrupts.
>
> Presumably he could run several of them for when he's working on
several
> different project numbers...
>
> ... Anyway, he asked if I knew of any such things, he was pretty
sure
> someone in the agile world would have written one by now ...
>
> Anyone seen such a type of thing?
>
> Alistair
>
>
>
>
>
> To Post a message, send it to:   scrumdevelopment@e...
> To Unsubscribe, send a blank message to:
> scrumdevelopment-unsubscribe@e...
>
>
>
>   _____
>
> Yahoo! Groups Links
>
>
> * To visit your group on the web, go to:
> http://groups.yahoo.com/group/scrumdevelopment/
>
>
> * To unsubscribe from this group, send an email to:
> scrumdevelopment-unsubscribe@yahoogroups.com
> <mailto:scrumdevelopment-unsubscribe@yahoogroups.com?
subject=Unsubscribe>
>
>
> * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
Service
> <http://docs.yahoo.com/info/terms/> .

Wow! This is an advanced topic - can we pick an easier one before we
scare people away.

The history of the superclasses revolves around Peter's move, with
his collaborators Jill Nicola and Mark Mayfield to develop pluggable
enterprise components that could be "wire wrapped". The super
classes and their associations are design to abstract away the hard
interface knowledge that normally exists between a green <<Person-
Place-Thing>> (or <<PPT>>) and its yellow <<role>> delegates.

Steve Palmer wrote a good Coad Letter on this and I covered it in my
Borcon paper [see, agilemanagement.net home page for the list of
these articles]

Using a PartyRole superclass is for advanced decoupling. It might be
easier if you simply did away with it. Simply couple the specific
<<role>> classes to your Person or Organization green classes.

The purpose of the superclass or interface is to allow a green to
hold a collection of yellows that are bound at runtime - not compile
time. The rules determining whether a green can hold a yellow
association are described in a blue description class attached to
the green. When a yellow role wants to bind to a green then the
green has to ask its blue description for permission to play that
role.

I doubt if you really need this runtime bound flexibility - at least
at this stage. On balance I'd say it is adding risk and complexity
to your architecture and project and you aren't going to need it ;-)
Yes, we do YAGNI in color modeling too. So simplify but record where
you simplified and what the benefits might be of adding back the
complexity for the future.

David

--- In colormodeling@yahoogroups.com, David Carter
<d.david.carter@g...> wrote:
> In JMCU ("The Coloring Book"), Coad introduces us to the Party &
> PartyRole components. Party role specializes into PersonRole,
OrgRole,
> and also into various roles that can be played by either a Person
or
> an Organization, such as Customer.
>
> In my current project, we are applying this pattern, but struggling
> with how we should model our Customer classes. In the domain, we
have
> concepts of "Customer" (really an individual customer) and
> "BusinessCustomer".
>
> Approach 1:
> - Customer derives from PersonRole
> - BusinessCustomer derives from OrgRole
> - pros: follows the pattern in the book, BusinessCustomer can use
the
> OrganizationalUnit construct via relationship inherited via OrgRole
> - cons: no common BaseCustomer class for behavior/data shared by
> Customer & Business Customer
>
> Approach 2:
> - BaseCustomer derives from PartyRole
> - both Customer & Business Customer derive from BaseCustomer
> - pros: BaseCustomer provides behavior/data common to all customers
> - cons: doesn't make use of the PersonRole/OrgRole distinction in
the pattern
>
> I think to make this decision, I need a better understanding of the
> purpose of the PersonRole/OrgRole dichotomy. It is not well-
detailed
> in the book. There are no listed properties or methods on either of
> these classes, other than the optional OrgRole association to
> OrganizationalUnit.
>
> I assume the primary purpose of the PersonRole is as a marker, for
use
> in validation rules along the lines of "if
> (partyRole.isInstanceOf(PersonRole))", to verify that the given
> PartyRole subclass instance can take part in a particular
> relationship.
>
> Any advice on what to consider in making this decision? Or does it
not
> warrant the degree of agonizing we're going through right now?
Perhaps
> we should be more agile, pick one approach that appears to work
now,
> and be prepared to refactor later if we find it doesn't work for
us?
>
> --
> David Carter
> david@c...

Tell us more or point us at a paper we could read.

Dan Vacanti also has a poker game example which he might be willing to
share as a toy project we could work on.

--- In colormodeling@yahoogroups.com, Ron Jeffries <ronjeffries@X...>
wrote:
> On Wednesday, June 15, 2005, at 11:56:00 AM, Steven Gordon wrote:
>
> > Would the Bowling Game example of Ron Jeffries be too trivial a
> > toy problem to illustrate color modeling/FDD?  If not, it would
> > certainly provide a comparison to the TDD/XP approach.
>
> I suspect that the one I do all the time is too trivial. We might
> extend it to make it complex enough to require more than an hour to
> do.
>
> Ron Jeffries
> www.XProgramming.com
> Those who attain to any excellence commonly spend life in some single
> pursuit, for excellence is not often gained upon easier terms.
>    -- Samuel Johnson

On Wednesday, June 15, 2005, at 2:27:35 PM, David Carter wrote:

> In JMCU ("The Coloring Book"),

Out of print, I note. Handy for those of us who want to know about
it ...

Ron Jeffries
www.XProgramming.com
Just because XP doesn't talk about how to make fire, should we assume it
requires us to use sticks? -- Richard MacDonald

In JMCU ("The Coloring Book"), Coad introduces us to the Party &
PartyRole components. Party role specializes into PersonRole, OrgRole,
and also into various roles that can be played by either a Person or
an Organization, such as Customer.

In my current project, we are applying this pattern, but struggling
with how we should model our Customer classes. In the domain, we have
concepts of "Customer" (really an individual customer) and
"BusinessCustomer".

Approach 1:
- Customer derives from PersonRole
- BusinessCustomer derives from OrgRole
- pros: follows the pattern in the book, BusinessCustomer can use the
OrganizationalUnit construct via relationship inherited via OrgRole
- cons: no common BaseCustomer class for behavior/data shared by
Customer & Business Customer

Approach 2:
- BaseCustomer derives from PartyRole
- both Customer & Business Customer derive from BaseCustomer
- pros: BaseCustomer provides behavior/data common to all customers
- cons: doesn't make use of the PersonRole/OrgRole distinction in the pattern

I think to make this decision, I need a better understanding of the
purpose of the PersonRole/OrgRole dichotomy. It is not well-detailed
in the book. There are no listed properties or methods on either of
these classes, other than the optional OrgRole association to
OrganizationalUnit.

I assume the primary purpose of the PersonRole is as a marker, for use
in validation rules along the lines of "if
(partyRole.isInstanceOf(PersonRole))", to verify that the given
PartyRole subclass instance can take part in a particular
relationship.

Any advice on what to consider in making this decision? Or does it not
warrant the degree of agonizing we're going through right now? Perhaps
we should be more agile, pick one approach that appears to work now,
and be prepared to refactor later if we find it doesn't work for us?

--
David Carter
david@...

On 6/15/05, David J Anderson <netherby_uk@...> wrote:
>  What's the level of knowledge? Do we need to start at the beginning
>  and explain why color, what are archetypes and how Peter got to where
>  he did between 1992 and 1999?

I am personally the ground-zero type. I've heard about the Coad method
(but don't know much about it) and I've heard about the coloring
approach (but can't never remember which color was for which type).

-Lasse-

On Wednesday, June 15, 2005, at 11:56:00 AM, Steven Gordon wrote:

> Would the Bowling Game example of Ron Jeffries be too trivial a
> toy problem to illustrate color modeling/FDD?  If not, it would
> certainly provide a comparison to the TDD/XP approach.

I suspect that the one I do all the time is too trivial. We might
extend it to make it complex enough to require more than an hour to
do.

Ron Jeffries
www.XProgramming.com
Those who attain to any excellence commonly spend life in some single
pursuit, for excellence is not often gained upon easier terms.
    -- Samuel Johnson

-----Original Message-----
From: colormodeling@yahoogroups.com [mailto:colormodeling@yahoogroups.com]On Behalf Of David J Anderson
Sent: Wednesday, June 15, 2005 10:54 AM
To: colormodeling@yahoogroups.com
Subject: [colormodeling] Where do we start?

Now that we have 33 members in this group, I'd like to gauge where we
start.

What's the level of knowledge? Do we need to start at the beginning
and explain why color, what are archetypes and how Peter got to where
he did between 1992 and 1999?

Or can we start with a working knowledge of archetypes and try
modeling some real problems?

David

On Wednesday, June 15, 2005, at 11:53:47 AM, David J Anderson wrote:

> Now that we have 33 members in this group, I'd like to gauge where we
> start.

> What's the level of knowledge? Do we need to start at the beginning
> and explain why color, what are archetypes and how Peter got to where
> he did between 1992 and 1999?

> Or can we start with a working knowledge of archetypes and try
> modeling some real problems?

Speaking for me, as I often do: it would be wise to assume that I'm
entirely ignorant. I'm happy to read assigned material, though.

Ron Jeffries
www.XProgramming.com
You do ill if you praise, but worse if you censure,
what you do not understand.   --Leonardo da Vinci

I think we'll find differing levels of knowledge & experience, so a
dual approach may be best. Assume that at least some of the audience
is starting from ground zero, but others have more background.

I hope that we'll also be able to entertain specific questions that
people may have from their current projects. I have a couple of
questions I'm struggling with right now, and will be posting soon.

-David

On 6/15/05, Steven Gordon <sagordon@...> wrote:
>  Can we do both - i.e., trying working step by step through a small
> realistic example, using each step to motivate the transfer of the knowledge
> required to understand that step?

Can we do both - i.e., trying working step by step through a small realistic
example, using each step to motivate the transfer of the knowledge required to
understand that step?

	 -----Original Message-----
	 From: colormodeling@yahoogroups.com on behalf of David J Anderson
	 Sent: Wed 6/15/2005 8:53 AM
	 To: colormodeling@yahoogroups.com
	 Cc:
	 Subject: [colormodeling] Where do we start?


	 Now that we have 33 members in this group, I'd like to gauge where we
	 start.

	 What's the level of knowledge? Do we need to start at the beginning
	 and explain why color, what are archetypes and how Peter got to where
	 he did between 1992 and 1999?

	 Or can we start with a working knowledge of archetypes and try
	 modeling some real problems?

	 David

Would the Bowling Game example of Ron Jeffries be too trivial a toy problem to
illustrate color modeling/FDD?  If not, it would certainly provide a comparison
to the TDD/XP approach.

	 -----Original Message-----
	 From: colormodeling@yahoogroups.com on behalf of David J Anderson
	 Sent: Wed 6/15/2005 8:43 AM
	 To: colormodeling@yahoogroups.com
	 Cc:
	 Subject: [colormodeling] Re: Any examples available / Toy project


	 The problem with sharing real examples is that they are generally the
	 intellectual property of the firm that paid for them. It's hard or
	 impossible to do.

	 The photos on my website are of real models on a real project but I
	 deliberately obfuscated the class names on the Post-it notes.

	 Toy project - why not? Go ahead and propose one. We can share images
	 of models via the files section of the website.

	 David

	 --- In colormodeling@yahoogroups.com, "sjalq" <sjalq@y...> wrote:
	 > I am hoping someone had some examples of color models that were
	 > actually used in real projects. I think it will help greatly to have
	 > such real world examples.
	 >
	 > Also, who would be up to participate in a toy project to demonstrate
	 > the basics of CM, the DNC and FDD? Something simple and fun enough to
	 > be motivating.
	 >
	 > -Schalk Dormehl





   _____

	 Yahoo! Groups Links


	 * To visit your group on the web, go to:
		 http://groups.yahoo.com/group/colormodeling/

	 * To unsubscribe from this group, send an email to:
		 colormodeling-unsubscribe@yahoogroups.com
<mailto:colormodeling-unsubscribe@yahoogroups.com?subject=Unsubscribe>

	 * Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> .

Now that we have 33 members in this group, I'd like to gauge where we
start.

What's the level of knowledge? Do we need to start at the beginning
and explain why color, what are archetypes and how Peter got to where
he did between 1992 and 1999?

Or can we start with a working knowledge of archetypes and try
modeling some real problems?

David

The problem with sharing real examples is that they are generally the
intellectual property of the firm that paid for them. It's hard or
impossible to do.

The photos on my website are of real models on a real project but I
deliberately obfuscated the class names on the Post-it notes.

Toy project - why not? Go ahead and propose one. We can share images
of models via the files section of the website.

David

--- In colormodeling@yahoogroups.com, "sjalq" <sjalq@y...> wrote:
> I am hoping someone had some examples of color models that were
> actually used in real projects. I think it will help greatly to have
> such real world examples.
>
> Also, who would be up to participate in a toy project to demonstrate
> the basics of CM, the DNC and FDD? Something simple and fun enough to
> be motivating.
>
> -Schalk Dormehl

I am hoping someone had some examples of color models that were
actually used in real projects. I think it will help greatly to have
such real world examples.

Also, who would be up to participate in a toy project to demonstrate
the basics of CM, the DNC and FDD? Something simple and fun enough to
be motivating.

-Schalk Dormehl

Cross posting frmo Agile Management...

Congratulations! This shows some real courage.

The abstractions shouldn't be too hard. Stephen Palmer has published
some great stuff about this.

Ask people to identify - how you make money? - pinks, who makes the
money? - yellow, what from and where money is made? - green. How you
describe what and where money is made in a catalog type form? - blue.

Think of pinks as transactions. Yellows as who/what is involved in a
specific transaction.

I'm going to repost this over on color modeling too...

David

--- In agilemanagement@yahoogroups.com, David Carter <david@c...> wrote:
> I agree that it is abstract, and takes some time & concentrated effort
> to understand. I don't think just reading the book is enough. You have
> to make the investment to apply it to a real project, with real
> requirements & real deadlines, before you fully understand what it is
> all about. We're still working through our first project with it, and
> it is a struggle to get some of the designers to think in more
> abstract terms & fully understand the power of those abstractions.
>
> -David
>

Welcome to The Coad Method! This group has been overdue. It's amazing
it's taken 6 years to create a group for this discussion.

If your here it is because you value modeling, analysis and
architecture as method of improving productivity and economic returns
from software development.

I get asked often for a list of online resources for color modeling.
Here are the best ones...

The book chapter that started it all, by Peter Coad...

http://www.pcoad.com/download/bookpdfs/jmcuch01.pdf

Stephen Palmer's Coad Letter collection...
http://www.step-10.com/notes/index.html

And some papers from my own site, including one by Daniel Vacanti...

Arguments About Color (by Daniel S. Vacanti)
http://www.agilemanagement.net/Articles/Papers/ArgumentsaboutColor.html

By David J. Anderson...

Advanced Domain Modeling (BorCon 2004)
http://www.agilemanagement.net/Articles/Papers/BorConAdvancedDomainMode
l.html

Coarse-grained Components from a Color Model
http://www.agilemanagement.net/Articles/Papers/CoadLetterCoarse-
grainedC.html

Whole Part Relationships in the DNC
http://www.agilemanagement.net/Articles/Papers/CoadLetterWholePartRelat
i.html

Coloring with Demeter
http://www.agilemanagement.net/Articles/Papers/CoadLetterColoringDemete
r.html

A History of Color Modeling
http://www.agilemanagement.net/Articles/Papers/AHistoryofColorModeling.
html

The Case for Class Ownership
http://www.agilemanagement.net/Articles/Papers/CoadLetterTheCaseforClas
s.html

Architecture Control Board
http://www.agilemanagement.net/Articles/Weblog/ArchitectureControlBoard
.html

Quality Assurance and Over-modeling
http://www.agilemanagement.net/Articles/Weblog/Over-modeling.html

FDD and Legacy Code
http://www.agilemanagement.net/Articles/Weblog/FDDandLegacySystems.html