Skip to main content

[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


Back to the top