[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[epf-dev] Re: Review and Strategy for Design, visual and non-visual
|
Adding my comments to Scott's.
Bruce MacIsaac
Manager - RUP/OpenUP Content
bmacisaa@xxxxxxxxxx
phone: (408)863-8718
"Scott W. Ambler"
<swa@xxxxxxxxxxxx>
07/17/2006 02:26 PM
|
To
| "Brian Lyons" <blyons@xxxxxxxxxxxxx>
|
cc
| "Eclipse Process Framework Project
Developers List" <epf-dev@xxxxxxxxxxx>, "Frank DuPont"
<fdupont@xxxxxxxxxxxxx>, "DeShazo, Jeanne" <jdeshazo@xxxxxxxxxxxxx>,
"Bob Houston" <rkh@xxxxxxxxxx>, bernie.clark@xxxxxxxxxxxxxxxxxxxxxxx,
apereira@xxxxxxxxxxx, "Scott W. Ambler" <swa@xxxxxxxxxxxx>,
Bruce Macisaac/Cupertino/IBM@IBMUS, Jim Ruehlin/Irvine/IBM@IBMUS
|
Subject
| Re: Review and Strategy for Design,
visual and non-visual |
|
Howdy. Comments below. In addition, I've
also attached an updated
version of the document with change tracking turned on. The doc also
has
some embedded comments.
- Scott
On Sun, July 16, 2006 3:57 pm, Brian Lyons said:
> <snip>
>
>
> Some things to keep in mind are: visual modeling with respect to the
> design is separated out,
I'm not so sure that this is a good idea.
> user-interface design is also separated out,
Bad idea.
> and Refactoring is currently just a Concept and a Guideline referenced
> here and there.
I think it's a step, if not a task.
> Each of these aspects is fodder for the strategy part
> of this feedback elicitation.
>
>
>
> My goal is to get some feedback on this design content before we move
> into the visual and UI stuff (Jim Ruehlin and Scott Ambler have also
> been providing good content for this package). In addition to
reviewing
> the actual content, please feel free to remark on the strategy that
will
> be followed moving ahead (described below).
>
>
>
> Mixing in Visual Modeling
>
> Based on the original donation of content from IBM, additional steps
> were added to this task in the package for visual modeling. Those
steps
> are bold in context below.
>
> 1) Understand requirement details
>
> 2) Identify logical classes to provide behavior
We also need some sort of "Identify tables/columns to store data"
or
something along those lines. Shouldn't forget the db stuff.
Same thing can be said of "Identify screens/fields to interact with"
I would pretty much assume that the people following OpenUP are building
business software that has a UI, implements some form of business logic
using OO technology, and stores information in a database somewhere. If
this is a reasonable assumption, then our design process needs to reflect
this.
BM: While we need
to support this, I think we also want to be able to support someone who
is building an embedded system.
In general, we are looking
for a scaleable solution. The approaches I can think of for supporting
variation on technology are:
A - have a general task
that makes sense in all cases, and have guidelines to express the technology
specifics; or
B- have separate tasks
for UI design, database design, application class design (perhaps that
extend a more general abstract task); or
Could have a main task
for designing something that pulls together all the pieces, and allow for
specialized tasks to do more specialized work in a technology area.
I have a preference for
B, because I think that specialists in these areas will not want to see
content belonging to another specialty area.
For Sept, perhaps our
only real tasks are a general "component design" task that deals
with 3GL language type development, and doesn't include UI or DB specialty
tasks, these are added by separate
plug-ins or packages.
>
> 3) Identify design elements
This might be to generic, considering step 2 and my suggestions above.
>
> 4) Design Components
What about services? Or classes? Or screens? Or....
>
> 5) Determine how elements collaborate to realize
the scenario
>
> 6) Create Use-Cases Realizations
This says almost nothing to the average practitioner. We need to
be more
specific.
>
> 7) Refine design decisions
Why wouldn't the previous steps design each aspect to the appropriate
level for the situation? If that's the case, I'm not sure that we
need
this.
>
> 8) Design internals (for large or complex elements)
Same as above. The details captured here are good, but perhaps should
be
moved to the guideline(s).
>
> 9) Communicate the design
Very good idea.
>
> Having covered a range of design concepts in the existing steps, I
am
> tempted to drop these three steps and just add one step before
> "Communicate the design". Possibly just something
like "Model the
> Design"
>
>
>
> At this moment, there is Guidance in the visual_modeling sub-package
for
> Design Components and Use-Case Realizations. In the Architecture
> package, there is a Concept on Visual Modeling.
What about non-visual modeling? Seems to me that use cases are a
fairly
important thing for us, yet they're non-visual.
> I am planning to add an
> overall Guideline on Designing Visually that will give some detail
to
> how visual modeling applies to each of the steps of the Design Solution
> task.
www.agilemodeling.com/style might be of interest. ;-)
>
>
> UI as its own task with both design and implementation elements
That could be. If so, then the DB stuff is likely in the same boat
and
"Design the Solution" is more along the lines of "Design
the Object Stuff"
>
> Based on the original donation of content, there is a separate task
> called "Prototype the User Interface". That task involves
producing a
> design and implementation of the user interface.
Prototyping can also be a requirements activity -- I prototype to explore
the UI needs of the stakeholders.
>
>
>
> How do people feel about the user interface being excluded from Design
> the Solution? How do people feel about the design and implementation
> being put in one task? Should the UI be treated like visual
modeling
> (i.e. an aspect that can be folded into existing tasks and work products
> with its own guidelines and in its own easily excludable package)?
If the UI stuff is it's own task then it provides easier hooks for people
to produce UI-related plug ins.
>
>
>
> Refactoring as Guidance or a Task
>
> The original donated content had a Concept and a Guideline for
> Refactoring. It has been suggested that Refactoring warrants
an
> explicit task.
The reason why I think it's a task is that this is the type of things
agilists would expect to see in an agile process. It was so important
to
the XP folks that it was one of 12 original XP practices. Refactoring
is
pretty much a given within the object programming community and is now
being adopted within the data community (I can recommend a really good
book on the subject, BTW) and within the UI community. It wouldn't
surprise me to find out that the technical documentation folks are talking
about "documentation refactoring" as well.
Refactoring is more of a coding technique than a modeling technique IMHO.
It's typically done after the fact to improve the existing stuff, not
before the fact. So, I'd argue that it likely doesn't belong as a
step in
the various design tasks because there's a lack of temporal cohesion
(there's your $10 term of the day, BTW) between design modeling stuff and
refactoring stuff. "Stuff" is your $0.10 term of the day.
>
>
>
> How do people feel about having a task for Refactoring? Or should
it be
> a step (amongst already too many steps) in the Design Solution task?
Or
> should it just stay as a Concept plus a Guideline?
Just having it as a concept/guideline doesn't do it justice, IMHO.
BM: For me its a
question of timing. We need to express when you do refactoring. If
we can do that well with a task, then that's fine with me.
- Scott
Practice Leader Agile Development, IBM Rational
http://www.ambysoft.com/scottAmbler.html
Refactoring Databases (
http://www.ambysoft.com/books/refactoringDatabases.html ) is now
available.
Attachment:
Review of Design Content 2006 07 17 Ambler.doc
Description: Binary data