In a comment attached to a diagram here the following question was asked.
Here's a very quick reply.
Green vs. pink is a question that comes up from time to time. There's a few reasons why, but most are to do with over-emphasizing the datetime attribute of a pink.
For example, I'm a Person. I'm a green, right? Well I have a date of birth doesn't that make me pink? Well, no, I'm a Person, I'm a green. What about a building, that's a place. But a building has a date of construction (a moment) and maybe even a date of demolition (thus an interval)... No, a building is a place.
Cases like these are straightforward. If there's still confusion then look at the behavior. A pink moment-interval has that sense of business process associated, is often something we need to track, has a previous and a next, often has a calcTotal, recalcTotal, complete, cancel, and so on. A green does not.
Another case is when it is beyond the boundary or scope of our system (our model). Such as the real world, or something in an external system.
A system that ours integrates with has a time ordered series of pinks in it. It tracks the history. However, in our system we only ever have one of them. A snapshot. To us there is no history or sense of business process or tracking. Hence, in our model it is a green. In the PD of the other system it is a pink.
There are many places in the color modeling book where green classes have dates or intervals on them.
Pink vs. Green
Agree with Jeff - the thing to consider is if the moment-interval is not only 'something that occurs at a moment in time or over an interval of time' but whether this time aspect is 'something that one needs to work with and track for business or legal reasons' (quotes from JMCU book). The context matters.
I have thought about modeling projects and programmes in pink but, in general, pinks do not contain (aggregation/composition in UML) greens, they relate to them (plain old associations in UML). Occurrences in time do not comprise of or hold concrete items. There are considerable MI's that happen around a project, approvals, kick-offs, releases, etc, etc. If we were modeling that wider context it is possible that the green project would become so trivial that it could collapse into a series of pinks or, more likely I think, be little more than named object that links all the related MI's together.
We do often model green containers as containing pinks though - one could have quite a philosophical discussion on that one. Should a feature 'contain' its development milestones? IME it is usually the result of a pragmatic and possibly instinctive collapsing of the more general Party-Role-MI-MIDetail-Role-Thing leg of the DNC. Person (party) as developer (role) doing development (MI) containing milestones (MI-details or subsequent MI's) related to a particular feature in its role as 'something being developed'. However, in this context, we can omit most of this but a broader system might need to include more of it.
Stephen R. Palmer
Micro Focus Principal Consultant
www.step-10.com
Not sold yet :-)
I'm stilling calling a Project pink. (It's even Pink in at least one instance in the "Coloring Book".)
Even by the definition "'something that occurs at a moment in time or over an interval of time' but whether this time aspect is 'something that one needs to work with and track for business or legal reasons'". Certainly tracking a project for business reasons is part of the project management domain, and hopefully won't lead to legal reasons, but sometimes does.
I can buy Aspect and Subject being Green without much convincing -- they're not 'natural' MIs at least. Activity? Seems like a natural MI again to me, and again from the perspective of Project Management as the domain, Activities seem like something we will track for business reasons.
Features. Now that sounds like a fun discussion. For my domain, modeling the FDD Tools domain, certainly Feature is at the heart, and drives a lot of the other tracking. I'm calling it Pink too.
Totally agree with the Jeff's comment that color depends on the the perspective you're modeling from.
Facilitating
That's a dangerous line of thinking. It's not about a class called Project always being pink or always being green. I can contrive a context that would clearly make it pink and I can contrive one that clearly makes it green. Saying there's one model that has it pink is as dangerous as saying I saw a Customer class in a model that had a Region association, therefore Customer in any model always has a Region association.
I'm pretty sure this isn't what you meant, but it's an important distinction in thinking.
Also note that nowhere in my post at the start of this thread did I say Project should be green or pink. I'm simply facilitating some thinking and conversation about this.
Interesting. So what is it about Aspect and Subject that are so clearly green but Activity is not? They have very similar shape. Similar structure and connections. One difference about Activity is its explicit completion date attribute and the simple behavior associated with it; e.g. am I late? However Aspect and Subject have derivable completion dates, and sometimes explicit completion dates. Activity certainly has calcTotal style reporting on it, but then so do Subject and Aspect... (especially Subject - look at the weekly progress summary report). None of Aspect, Subject or Activity have previous or next.
Again, I'm simply facilitating some thinking and conversation about this.
Thanks for facilitating
Re: Green vs. pink
Vernon,
For about 5 years ago I wrote FDDPMA. I did model project and everything under it as pinks. I hope it makes you feel better
However, I see the point that others are making on this thread: it all depends on context. Imagine the two contrived scenarios:
1) We are writing a project management application. The app needs to allocate development resources for features/activities etc. Here pinks may make sense because we need to track when certain activity is planned to start, end, how many developers it needs, if the next activity can start before/after this one etc.
2) We are writing an application that analyzes complexity of projects based on the number of aspects, subject areas, activities etc. The goal of application is to find projects of similar complexity done in the past and predict the outcome of a project as success/failure. In this example all of things we are talking about are green, as we are not interested in tracking the progress of individual projects.
The examples are not perfect, but they may give you an idea why context matters.
I think we're on the same page
It's just that damn precision of language thing
For about 5 years ago I wrote FDDPMA. I did model project and everything under it as pinks. I hope it makes you feel better
I modeled that way too. Which is what brought me to the original question when I saw them all green in the image http://www.featuredrivendevelopment.com/node/792#comment-2088
However, I see the point that others are making on this thread: it all depends on context.
Agreed. So I noted.
Totally agree with the Jeff's comment that color depends on the the perspective you're modeling from.
Thanks, Jeff, for facilitating the discussion. I, for one, have learned something from the discussion, and hopefully others will find it useful too.