[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [epf-dev] Refactoring of Visual Modeling packages
|
Chris, that's what I thought.
I'll create the uc_modeling package
under the requirements package and refactor the related elements to there.
Cheers,
Ricardo Balduino
Senior Software Engineer
IBM | RUP Team | EPF Committer
www.ibm.com
www.eclipse.org/epf
"Chris Sibbald"
<Chris.Sibbald@xxxxxxxxxxxxx>
Sent by: epf-dev-bounces@xxxxxxxxxxx
06/20/2006 12:00 PM
|
Please respond to
Eclipse Process Framework Project Developers List <epf-dev@xxxxxxxxxxx> |
|
|
To
| "Eclipse Process Framework Project
Developers List" <epf-dev@xxxxxxxxxxx>
|
|
cc
| External Chris Sibbald <csibbald@xxxxxxxx>
|
|
Subject
| RE: [epf-dev] Refactoring of Visual
Modeling packages |
|
Hi Folks,
Ricardo is correct. At the
June 12 RM content review we discussed moving the method elements related
to Use Cases (Guideline, Concept, Checklist) to a separate sub-package.
The method elements related to Use Cases and Actors would remain
in the base requirements package. We did not discuss making OpenUP/Basic
agnostic of requirements technique at that meeting.
I vote for a package named uc_modeling
within the scope of the requirements package.
My $0.02
Cheers,
Chris
From: epf-dev-bounces@xxxxxxxxxxx
[mailto:epf-dev-bounces@xxxxxxxxxxx] On Behalf Of Ricardo Balduino
Sent: Tuesday, June 20, 2006 1:51 PM
To: Eclipse Process Framework Project Developers List
Subject: RE: [epf-dev] Refactoring of Visual Modeling packages
Hi all,
I haven't necessarily brought up the discussion on making OpenUP/Basic
agnostic of requirements technique - at least not now - meaning that we
would refactor how use cases are used throughout the method. Though that's
important, it would demand a broader discussion on what is then the generic
requirement type that would be used as input/output of tasks when use cases
are suppressed. Is that something we want to discuss an incorporate in
our tight schedule for release 1 or should we postpone the discussion for
release 2?.
My point here was about use case modeling (use-case diagrams, namely).
Only the use-case model artifact and related guidance/tasks would be refactored
to this package (not the use case spec nor the actor - these would still
be at the high level package for now, until we refactor things out as mentioned
in the paragraph above).
Scott referred the various types of modeling considered by Agile Modeling
(AM), where use cases fit under Usage Modeling. I wonder if a broader discussion
on how to add Agile Modeling on top of OpenUP/Basic would help to clarify
this. Scott is that something you would like to drive? :-)
This discussion is important, because the way AM defines this seems to
be different than what I stated above: for AM, use-case specs, actors,
use-case diagrams and such would be under this notion of Usage Modeling,
not only use-case diagrams - the visual modeling part of use-case approach
- as I was considering.
>From the responses I got so far (thank you, by the way) it seems the preferred
approach is to keep separate sub-packages under each main package. The
question is whether to generically call these packages visual_modeling
or be more specific, like uc_modeling (under requirements).
Any more thoughts?
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
"Brian Lyons"
<blyons@xxxxxxxxxxxxx>
Sent by: epf-dev-bounces@xxxxxxxxxxx
06/20/2006 06:41 AM
|
Please respond to
Eclipse Process Framework Project Developers List <epf-dev@xxxxxxxxxxx> |
|
|
To
| "Eclipse Process Framework
Project Developers List" <epf-dev@xxxxxxxxxxx>
|
|
cc
|
|
|
Subject
| RE: [epf-dev] Refactoring of Visual
Modeling packages |
|
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
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev
--------------------------------------------------------------------------------
Telelogic Lifecycle Solutions:
Helping You Define, Design & Deliver Advanced Systems & Software
Learn More at www.telelogic.com
Chris Sibbald
Vice President, Standards and Technology
Telelogic North America Inc.
255 Albert Street, Suite 600
Ottawa
Ontario K1P 6A9
Canada
Phone: +1 (613) 266 5061
Fax: +1 (613) 482 4538
Mobile phone: +1 (613) 266 5061
Chris.Sibbald@xxxxxxxxxxxxx
http://www.telelogic.com
Telelogic - Requirements-Driven Innovation!
-------------------------------------------------------------
The information contained
in this e-mail, including any attachment or enclosure, is intended only
for the person or entity to which it is addressed and may contain confidential
material. Any unauthorized use, review, retransmissions, dissemination,
copying or other use of this information by persons or entities other than
the intended recipient is prohibited. _______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev
