... Hi Nuno, Tony, Larry, Hallvard, ... Picking up a few points here: 1. A system may be developed incrementally, but that doesn t mean it has to be releasedMessage 1 of 44 , Jan 24, 2001View SourceAt 06:17 24/04/01 -0400, you wrote:
>Hi Nuno, Tony, Larry, Hallvard, ...
> Nuno J. Nunes wrote:
> > On the light of current XP practice, you either:
> > 1. Don't refactor the UI and end-up with a bad UI.
> > 2. Refactor the UI and end-up loosing a lot of time and effort in the
> > process, thus compromising process velocity.
> As I said in my post to Larry, there might be a third option:
> 3. Create your usage model based on *all* available stories; i.e. your model
> spans many iterations. Use this model to create a UI for a given iteration.
> Thus you have a coherent model for the whole system, and a UI that is
> suitable for a given iteration and beyond.
Picking up a few points here:
1. A system may be developed incrementally, but that doesn't mean it has to be
released every increment. So the customer disatisfaction at UI changes may be
a red herring.
2. Cost of up-front design versus cost of refactoring [of UI in this case] (as
Nuno mentions above) has a very familiar ring to it - namely its parallel with
the arguments of cost of internal up-front [OO] design versus the cost of
incremental refactoring of the [OO] design.
The arguments on this front are (tediously? - well perhaps if you read otug)
[Position 1]: do an overall analysis of requirements, design holistically for
all of these, then develop incrementally based on the design.
[Position 2]: but in this case you do a lot of design work that may be
unnecessary - in an agile project half of those initial requirements will never
be used. No, just design for the current increment and [be "brave" enough :-)]
to refactor later.
[Position 1]: No, the cost of refactoring would just be too high, and it
might'n even get done - and your system will rot.
[Position 2]: That's all well and good, but the moment you show the system to
the users/customers you realise that the requirements as you stated them were
wrong - and all that design work is wasted. Design incrementally.
Examining two extreme positions shows there are pros and cons to both
approaches - so unfortunately it comes down to a judgement call as to where the
balance should be drawn.
Interested in your thoughts.
> p.s. Can I post your reply to the XP list?
> Yahoo! Groups Sponsor
> eLert_ComputersInternet_Software_WhiteGridTime&t=ad>Click Here to Find
> Software Faster
> Your use of Yahoo! Groups is subject to the
> <http://docs.yahoo.com/info/terms/>Yahoo! Terms of Service.
|Voice: +44 (0)20 8579 7900 Fax: +44 (0)20 8579 9200|
|Mobile:+44 (0)777 163 6882 Email: markcc@... |
|Post: 17-19 The Broadway, Ealing, London W5 2NH, UK |
|RATIO: OO Training Tools Consultancy Recruitment |
|Training: C++, Java, EJBs, CBD, UML, OOAD, XP, XML, |
|See ObjectiveView technical journal: www.ratio.co.uk |
on 30/04/01 08:40, Hallvard Trtteberg at firstname.lastname@example.org wrote: Hallvard, ... I m familiar with Paternò s interactors. That approach is very close to theMessage 44 of 44 , Apr 30, 2001View Sourceon 30/04/01 08:40, Hallvard Trtteberg at hal@... wrote:
> The abstraction is close to the "York/Piza" interactors, which in shortI'm familiar with Paternò's interactors. That approach is very close to the
> introduces a basic UI building block called "interactor" which mediates
> information in two directions, user to system and system to user, through
> four "gates". In my notation, the interactor is a rectangular box with
> title, triangular gates and a resource interface. I've introduced functions
> and merged these with gates, to provide domain specific computations.
> Interactors are put together a bit like lego-bricks, by connecting the gates
> and can be nested into a hierarchical graph, similar to a process network. I
> formalise part of this using Statecharts, while the process algebra LOTOS
> has been used by others. If anyone is particularly interested, I can send
> him/her parts of my thesis, where this is discussed in relation to concrete
> interface elements.
model-based tradition, which was popular years ago but failed to gain
widespread support mainly because model-based environments (including
back-to-back automatic generation) never proved to be effective in practice.
I'm not saying this approach is wrong or flawed, it surely is sound from a
theoretical perspective. The main problem is that "pure" model-based
approaches (in the sense that they attempt to fully automate the UID
process) have not proved to be flexible enough for modern UIs. There are
other successful examples of automatic generation techniques, mainly the web
- where UIs described in markup are rendered in different platforms.
However, those successful examples are very limited in terms of the extent
to which they support the UID process.
Times are changing though. Today we're moving away from the stable desktop
paradigm and there is an increasing number of target platforms that differ
substantially in terms of the devices we use to interact, and the related
interaction styles and techniques.
My point is that model-based techniques will inevitably come into play
again. It will be very difficult to deploy software systems over a series of
different platforms (just think of desktop, web, palm, cellular phone, and
interactive TV) without effective model-based techniques. It's not a matter
of whether we like them or not... We just can't cope with the increasing
complexity without model-based approaches.
> I want this to be a practical tool and have experimented with a runtimeSounds interesting... Can you send more info on that UML adaptation? Is the
> system for this. I'm also working on a mapping to UML through stereotypes,
> which I guess you're particularly interested in.
runtime environment available?
> I like to call the UID patters, i.e. both user interface and design. If weI prefer a different distinction:
> omit "design" these may wrongly regarded as software patterns.
Software patterns - all patterns that have to do with software
Design patterns - patterns that have to do with OO design
Analysis patterns - same for OO analysis
UI patterns - patterns that have to do with UIs - interaction patterns,
UID patterns, etc. are different classes of UI patterns.
Nuno Jardim Nunes
University of Madeira - Teaching Assistant
Mathematics Dep. - Computer Science Unit
phone: +351 291 705160 (direct) 705150 (secretary)
fax: +351 291 705199
Address: Campus Universitário da Penteada
9000 - Funchal - Portugal