RE: [epf-dev] Refactoring of Visual Modeling packages

["Brian Lyons" <blyons@xxxxxxxxxxxxx>]

hiho,

This is a key distinction.  The usage of use cases vs. some other
requirements technique is a completely different decision than the usage
of visual modeling.

I appreciate that we have the sub-packages.  We just need to think of
the process repository architecture that best serves our need going
forward with more and more optional sub-packages (given the reasonable
premise that WAGNI -- we are gonna need it).

There will be techniques per discipline that could be factored in or
out, especially once the tool and process are adopted by the community
at large.  There also will be families of related techniques that cross
disciplines.  My opinion would be that a consistent organizational
technique that is intuitive and usable for each of the above
circumstances would be to localize the sub-packages to give context to
the process engineer and then deal with cross-discipline things like
visual modeling like it is now: just have identically named sub-packages
in multiple disciplines.

We will also need to find a way to communicate more complex notions on
how these sub-packages fit in.  You might say: here are a set of
explicit requirements techniques and you must pick one to have a
complete process.  You might say: these two techniques are mutually
exclusive.  For the moment, these nuances can just go in the Brief
Description of the sub-package.

So, I suggest that we keep the sub-packages as-is and add a use cases
sub-package within the requirements discipline. 

                                 --------- b
-----Original Message-----
From: epf-dev-bounces@xxxxxxxxxxx [mailto:epf-dev-bounces@xxxxxxxxxxx]
On Behalf Of Scott W. Ambler
Sent: Tuesday, June 20, 2006 8:03 AM
To: Eclipse Process Framework Project Developers List
Subject: Re: [epf-dev] Refactoring of Visual Modeling packages

How about calling the package modeling instead of 
visual_modeling?  Many of the modeling artifacts, such as use cases 
and business rules specifications, are textual in nature not 
visual.  Shouldn't we go for something a bit more generic?

- Scott



At 01:50 PM 6/19/2006, you wrote:

>Hi all,
>
>As part of implementing bug "Refactor Use-Case Model into separate 
>package (https://bugs.eclipse.org/bugs/show_bug.cgi?id=147349), I 
>though of creating a package called visual_modeling (under 
>Requirements package), following the same convention used in 
>Architecture and Development packages.
>
>Another level of refactoring I though could be useful - that I would 
>like to ask your opinion about - is: should we put all these vm 
>packages together in only one package called visual_modeling? This 
>package would be outside of Architecture, Development and RM, but 
>would contribute stuff to each of them. This would offer an 
>all-or-nothing approach, where visual modeling is fully included in 
>a given configuration or not.
>
>Please, let me know what you think. If there aren't strong contrary 
>opinions, I'll proceed with the refactoring.
>
>Thanks,
>
>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 mailing list
>epf-dev@xxxxxxxxxxx
>https://dev.eclipse.org/mailman/listinfo/epf-dev

====================================================
Scott W. Ambler  :-)
Practice Leader Agile Development, IBM Rational
www.ambysoft.com/scottAmbler.html
Every organization gets the process that it deserves.

Refactoring Databases: Evolutionary Database Design 
(www.ambysoft.com/books/refactoringDatabases.html) is now available. 

_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev