RE: [epf-dev] Re: What do we do for an analysis model

["steve" <steve@xxxxxxxxxxxxxxxxx>]

It just happens that last night Eric Evans gave a terrific presentation to
our Agile user group (Agile Vancouver www.agilevancouver.ca) on this very
topic. This is just after I wrote my e-mail yesterday that in my experience
I have not done a lot of domain modeling :-) However, that does not mean I
do NOT do any domain modeling (how is that for a double negative). 

I absolutely agree, not all requirements can be expressed with use cases. We
have usually developed "informal" models - usually on white boards - to
understand the nature of the problem domain, and to develop a common
vocabulary and then use that vocabulary to drive the architecture. The lines
between analysis and architectural design are often blurred here. One mantra
I learned a long time ago is "the shape of the solution should match the
shape of the problem" 

Bottom line, I believe domain modeling is a necessary discipline and must be
included in the BUP, however we need to discover what we consider minimal.
Eric has done a lot to make domain modeling fashionable in this feature
driven world. He has a book out "Domain-Driven Design: Tackling Complexity
in the Heart of Software" This may be a good guide to assisting us in
creating a minimal/light approach to domain modeling in the BUP. 

Best regards,
Steve



-----Original Message-----
From: epf-dev-bounces@xxxxxxxxxxx [mailto:epf-dev-bounces@xxxxxxxxxxx] On
Behalf Of Ana Valente Pereira
Sent: Tuesday, February 14, 2006 11:47 AM
To: Eclipse Process Framework Project Developers List
Subject: Re: [epf-dev] Re: What do we do for an analysis model

I don´t think that a domain model can be considered a "big upfront 
design"... and from my experience I can tell that it helps to understand 
the use case model... and even for some of our customers it is easy to 
say that "one person can have more that one car"... than writing the use 
cases for the car management system... not all the requirements can be 
expressed in the form of use cases... I see a domain model as a product 
from business modeling instead of analysis

we have been working with a basic "home made" version of the unified 
process in the last years and what has worked for us is clear 
requirements (domain model&glossary + use case specifications) and a 
solid architecture, that provides guidelines for the developers... most 
of the time the use cases are so clear that the developers skip "formal 
analysis and design" and spend more time on unit testing instead... the 
only analysis that we don´t give up is the user interface analysis 
(navigation map, prototype etc) .. but I dont see that in the BUP as 
well ... even in a minimal process I think that it should be considered...

regards

Ana

WSA Consulting Inc wrote:

> Hi Guys:
>
> This opens a useful area of discussion, and also may help us develop 
> the principles what is definitely “in” and what is optional. Most of 
> my experience is with projects with less than 50 staff members and 
> more often less than 10. We rarely did extensive domain modeling 
> because we believed it was not necessary and what modeling we 
> performed was usually limited to UML diagrams on white boards. I agree 
> with Ricardo here, for the process-still-known-as-BUP domain modeling 
> should be kept to a minimum, with the goal of simply creating a common 
> project vocabulary.
>
> I’m restating the obvious, but the process must be minimal such that a 
> small team (say less than 5 people) or even an individual would 
> enthusiastically embrace it. Plugins should then enable the process to 
> scale with the size and complexity of the project. The exciting 
> opportunity this opens for us is the addition of plugin modules that 
> extend this minimal description. The utility is not so much that 
> additional activities and artifacts these plugin models introduce, but 
> the criteria for when to add a plugin to the basic process – in other 
> words the criteria for growing the process. For example, what risks 
> does a specific domain modeling plugin mitigate and therefore when is 
> it appropriate to add domain modeling to the minimal process? The 
> answers to this question will make this EPF and BUP truly useful to 
> its adopters. This is what motivated me to join this project in the 
> first place, looking at how to scale UP rather than trying to tailor down
>
> That’s my 2 cents worth anyways.
>
> Best regards,
>
> Steve Adolph
>
> Consultant
>
> WSA Consulting Inc
>
> Vancouver Canada
>
> P +1 604 696 0460
>
> F +1 604 696 0470
>
> ------------------------------------------------------------------------
>
> *From:* epf-dev-bounces@xxxxxxxxxxx 
> [mailto:epf-dev-bounces@xxxxxxxxxxx] *On Behalf Of *Ricardo Balduino
> *Sent:* Friday, February 10, 2006 2:54 PM
> *To:* epf-dev@xxxxxxxxxxx
> *Subject:* [epf-dev] Re: What do we do for an analysis model
>
>
> Hi Chris,
>
> You definitely have a good point here, and that is the type of 
> feedback we expect to hear from the community about the proposed work. 
> Now the challenge is to get consensus on what would be a good release 
> 1.0 for BUP which can provide a minimal -- still complete -- process.
>
> That being said, I understand your concern about this "big jump", 
> where it seems analysis activities are missing. In fact, when 
> proposing BUP we considered that in small projects these analysis 
> activities are "transparent" and kind of absorbed by tasks performed 
> by the architect and developer roles. At some extent, the architect 
> does some high level analysis (finding key abstractions, understanding 
> architectural constraints, etc). The developer also has to do some 
> analysis for his/her use case/scenario, finding the classes that are 
> part of that use-case realization. That seemed to bring a more 
> straightforward approach to analysis and design. Comments on this will 
> be appreciated.
>
> Regarding a domain model: one of the intents for BUP is certainly not 
> to be so model-centric or advocate big up-front design. Actually, we 
> may think of design being captured using different approaches, like 
> UML diagrams (even in a whiteboard), CRC cards, etc. These are 
> variants for what we hope to see plug-ins extending BUP. Up-front 
> design thinking should be allowed, but not a premise. If one wants to 
> follow a "design as you go" approach, it should also be allowed to do. 
> I'd just be a bit cautious when adding different levels of 
> abstractions for models and diagrams, in order to avoid having people 
> thinking we are imposing a heavy way of doing design in BUP. If, in 
> your opinion, there's a lack of information that a nice glossary could 
> suppress, than we have to think about it.
>
> Again, we want a minimal, yet complete process :-)
>
> Comments from the others will be appreciated.
>
> Regards,
>
> Ricardo Balduino
> Senior Software Engineer
>
> IBM | RUP Team | EPF Committer
> Phone: 1 (408) 863-5019 (TL: 560-5019)
>
> www.ibm.com
> www.eclipse.org/epf
>
> Ricardo Balduino
> Senior Software Engineer
>
> IBM | RUP Team | EPF Committer
> Phone: 1 (408) 863-5019 (TL: 560-5019)
>
> www.ibm.com
> www.eclipse.org/epf
>
>
> *epf-dev-request@xxxxxxxxxxx*
> Sent by: epf-dev-bounces@xxxxxxxxxxx
>
> 02/10/2006 09:00 AM
>
> Please respond to
> epf-dev
>
> 	
>
> To
>
> 	
>
> epf-dev@xxxxxxxxxxx
>
> cc
>
> 	
>
> Subject
>
> 	
>
> epf-dev Digest, Vol 2, Issue 3
>
> 	
>
>
>
> Message: 1
> Date: Fri, 10 Feb 2006 17:17:23 +1100
> From: ChrisDoyle@xxxxxxxxxxxxxx
> Subject: [epf-dev] What do we do for an analysis model
> To: epf-dev@xxxxxxxxxxx
> Message-ID:
> <OF2BA98BB8.058BB295-ONCA257111.002218B3-CA257111.00228D45@xxxxxxxxxxxxxx>
>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi All,
>
> I would like to ask a question regarding the analysis discipline in BUP.
>>From what I can see from the available documents, there is a significant
> jump from the use-case model to the use-case realisation. In RUP and 
> other
> processes there are a number of tasks and work products based around
> domain analysis (analysis model).
>>From my own experience on small to medium size projects, a critical part
> of any project has been domain analysis. Output from domain analysis is a
> domain model but looking at the BUP documents there appears to be neither
> glossary (which can provide some of the detail) nor a domain object 
> model.
>
> So my question is should the analysis model be left out of BUP and
> mentioned as a "consideration" which can be included by other 
> plug-ins? No
> doubt you considered this and I would be interested in hearing your
> thoughts. NB the BUP method content may already have guidance on this
> subject so I'm looking forward to seeing the BUP plugin as a download (is
> it available yet?).
> Chris Doyle
> Solution Specialist
> Synergy Plus Pty Ltd
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: 
>
http://eclipse.org/pipermail/epf-dev/attachments/20060210/0a8566a0/attachmen
t.html
>
> ------------------------------
>
> _______________________________________________
> epf-dev mailing list
> epf-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/epf-dev
>
>
> End of epf-dev Digest, Vol 2, Issue 3
> *************************************
>
>------------------------------------------------------------------------
>
>_______________________________________________
>epf-dev mailing list
>epf-dev@xxxxxxxxxxx
>https://dev.eclipse.org/mailman/listinfo/epf-dev
>  
>
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev