Bottom up or top down?

[Chris Muir]

The groups gone quiet again Over 300 members and nothing much to
say! Let's kick off a new discussion.

The typical development method for an ADF app is, create your db
objects, then ADF Business Components, then pages and task flows, a
bottom up approach if you will. With the introduction of JDev 11g and
placeholder data controls, it's possible to take a top down approach,
starting with the pages/flows, then Business Components, then finally
the db object.... well at least it's possible in theory.

Anybody using or has used the top down approach? Any experiences,
successes, failures, issues and/or thoughts you'd like to share with
the group please?

Cheers,

CM

[Aino]

Hi,

 

Interesting approach, although I probably still would promote to start with the the application modules.

 

But in both cases, it's often the case that the DB model already exist; how often can you work in a greenfield situation.

 

 

Ciao

  Aino

--
You received this message because you are subscribed to the ADF Enterprise Methodology Group (http://groups.google.com/group/adf-methodology). To unsubscribe send email to adf-methodolo...@googlegroups.com

To unsubscribe from this group, send email to adf-methodology+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

[Chris Muir]

Hi Aino

Really, why the AMs? Are you thinking transactions should drive the
design/development? Even so, I'd be interested from the AMs where do
you naturally progress from there?

As for greenfield projects, fair point. I guess most development for
myself is a mix of new development in parts reusing old db
infrastructure. Still point stands, anybody given a fully top-down
development a go?

Regards,

CM.

[John Flack]

Strange way of putting it - I've always thought of database to
business objects to pages as top-down, and pages to database as bottom-
up.

Actually, I kind of like working from both ends towards the middle.
What I mean by that, is that I like to design pages on paper, to give
users an idea of what things are going to look like, and which items
of information are going to appear where, and how the flow is going to
work. In so doing, I'll be getting an idea of what the important bits
of data are and how they are related to each other. Then, I'll start
designing the database, or deciding how I'll use an existing database,
and what might need to be added or changed. I'll do E/R diagramming,
and maybe a process flow (use-case to some people), and validate it.
Then I may make changes to the paper page design, and the cycle may
continue a few loops.

Eventually, I'll get back to what I'd call top-down (what you called
bottom-up) and generate ADF BC, and pages. Note that pages are just
on paper until this point, because it is a heck of a lot easier to
build pages from data controls, and you have to have an AM to have
data controls.

On Mar 24, 5:04 am, Chris Muir <chriscm...@gmail.com> wrote:
> Hi Aino
>
> Really, why the AMs?  Are you thinking transactions should drive the
> design/development?  Even so, I'd be interested from the AMs where do
> you naturally progress from there?
>
> As for greenfield projects, fair point.  I guess most development for
> myself is a mix of new development in parts reusing old db
> infrastructure.  Still point stands, anybody given a fully top-down
> development a go?
>
> Regards,
>
> CM.
>

> On 24 March 2010 16:01, Aino <aino.andries...@gmail.com> wrote:
>
> > Hi,
>
> > Interesting approach, although I probably still would promote to start with
> > the the application modules.
>
> > But in both cases, it's often the case that the DB model already exist; how
> > often can you work in a greenfield situation.
>
> > Ciao
> >   Aino
>

[Luc Bors]

I've been playing with placeholder datacontrols in order to get a demo up and running.
That works ok for small demo's. However, correct me if I'm wrong, you cannot create an application module from a place holder datacontrol.

So for real life projects it is not my favorite approach.

If we could have something like that, the take a top down approach, starting with the pages/flows, could make sence.
You would not have to create an "application module like" structure from scratch twice.

Luc

[michel...@gmail.com]

I tested the placeholder approach for a full redesign an existing
application (db model also) but stopped early in the process because i
found it was easier to create/adapt the database schema rather than
use placeholder data definitions. So i'm using an iterative approach
by starting with the database model and application module design that
correspond to the use cases. I'm building the page flows and later the
ui fine design by using the data controls generated for the am. It
works fine.

On 24 mar, 10:04, Chris Muir <chriscm...@gmail.com> wrote:
> Hi Aino
>
> Really, why the AMs?  Are you thinking transactions should drive the
> design/development?  Even so, I'd be interested from the AMs where do
> you naturally progress from there?
>
> As for greenfield projects, fair point.  I guess most development for
> myself is a mix of new development in parts reusing old db
> infrastructure.  Still point stands, anybody given a fully top-down
> development a go?
>
> Regards,
>
> CM.
>

> On 24 March 2010 16:01, Aino <aino.andries...@gmail.com> wrote:
>
>
>
> > Hi,
>
> > Interesting approach, although I probably still would promote to start with
> > the the application modules.
>
> > But in both cases, it's often the case that the DB model already exist; how
> > often can you work in a greenfield situation.
>
> > Ciao
> >   Aino
>

[Jean-Marc Desvaux]

John,

I thought it was only my wife who was putting things the other
way. ;O)
For example when switching TV Channels moving from channel 1 and
pressing the button down to the last one, I see it as moving down the
channels but she sees it as moving up.
Hopefully it is well known that Opposites attract....

We also work from both ends... of course always keeping the model to
an acceptable normal form level. I think going top down strictely
could pose a risk to the data model quality.

Jean-Marc

[John Flack]

Two more points on this issue:
First, pages are meant to get data into and out of the database - they
support the database, the database does not support the pages.
Applications come and go, but data is forever. The database design
must be robust and flexible enough, not just for today's application
design, but also for applications that haven't been conceived yet. I
think that's why I think of starting with the database as top-down.

Second, I'm beginning to experiment with having pages bind to a PL/SQL
API - not a Table API, but an operational API. For instance, maybe I
don't want to update the EMPLOYEE and EMPLOYEE_ADDRESS tables, maybe I
want to ADD_EMPLOYEE, with arguments for the employee first and last
names and an array of addresses. It would map one to one with the
AddEmployee page. Could be done with a stored procedure accessed
through a method in the AM, or with an EO for a view with INSTEAD OF
triggers. Of course, I could go overboard with this, and wind up hand
coding a lot of stuff that I should let the framework do for me.
Understand - this is just an experiment, a vagrant thought, not a
recommendation.

[Jean-Philippe Melanson]

We have been using a UI prototyping approach for a year now on our
project because of the strictness of our GUI interfaces.
This is a way for us to minimize change in the user interface and
prevent time and cost explosion like we have seen in the past.
The prototypes must be approved by stakeholders and they remain still
through development with few minor changes.

I know it may not be agile, but in a project where the GUI is very
important because a commitment on usability is made, I think this is a
good approach and the placeholder data control is a great tool.

But as a developer, I would rather like to start from the database.
The problem I see with our current development process is that the
business domain development is made at the end, and we all know that
in the end we lack time.
I would prefer to have a rock-solid domain model than a fix UI, but
this is from a developer's angle.

I also heard some projects are starting from POJO java objects created
by a UML tool where javadoc is used to inform DBA and developers about
the business domain objects.
I don't know what you guys think about it, but I am personnally
curious about this approach, because sometimes, business rules cannot
be guaranteed only by the database.

Regards

[Liza]

Within Oracle, we generally refer to these overall approaches to
application design and development as UI-first and data-first. The
terms apply equally well to the actual implementation phase, which may
use a different approach from the initial design phase.

Within our Applications development teams, we generally follow a
process that looks a bit like this:

1. UI designers and product managers define the user experience and
functional characteristics of a module. The earlier we are in the
design process, the lower the fidelity of the UI designs. So, when
first roughing out the flows and ideas for what the pages look like, a
designer may start by sketching on a whiteboard or paper. The first
tangible soft copy deliverables are wire frames and navigation flows
drawn in Visio (we have templates and stencils that we've defined that
looks like our Fusion applications, so this really speeds the
process).

While these initial designs will clearly be informed by data
requirements, they're not focused on a data model. Instead, they're
focused on the data that users will interact with -- which as we all
know, may look very different from the physical schema.

2. When the designs completed in step 1 have stabilized, UI designers
create a high fidelity prototype of their module that looks like the
RT, and supports basic interaction and navigation, but no validation
logic, etc.. Additionally, the UI is based on "dummy
data" (essentially an Excel spreadsheet of rows and columns with data
you want to show in the UI) and not on real persistence objects.

Early in the JDeveloper/ADF 11g, the designers used a special
extension they built for Dreamweaver to do these interactive
prototypes. We actually introduced placeholder data controls
specifically for UI prototyping, and in the last year, they've started
doing these prototypes in JDeveloper using ADF Faces components, task
flows, and placeholder data controls. We've also developed special
training specifically targeted towards helping UX professionals -- who
aren't assumed to be developers -- learn how to do this. These
prototypes, which provide a nice tool for usability testing and
internal demos, also help the designers verify that what they have
dreamed up can actually be implemented in the product, and it provides
a platform for communication with the developer who will be
implementing it (best case, the developer can actually use some of the
prototype UI directly without having to recode it).

Now, there are a couple interesting considerations when working with
placeholder data controls. First, in a large team you can create them
for core objects and share them. Second, because they ultimately
yield a data control like any other, you can easily substitute real
data controls if available -- even for UX prototyping. The idea is
that you want to use placeholder data controls when you don't have
your view objects in place yet (you may have the underlying tables,
but the view objects shape the data for the UI so until you know what
that's going to be, you may not have that in place), but if you do
have those view objects, your UI prototypers can use those just as
well. This might also open the door for introducing a bit of business
logic that your UI designer doesn't need to worry about implementing.
Third, they let you build the prototype primarily data-first, which is
generally more efficient than going the other way when physically
creating pages. So, for example, I can drop a Purchase Order Header
placeholder data control on a page, and quickly create a corresponding
form. Now that I have databound controls, I can enhance/augment the
basic layout as needed.

3. Once the functional design is clear, the developers proceed with
their technical design. Among other things, this includes the
necessary data model changes (if any) and corresponding Business
Components definitions.

4. During implementation, we typically work data-first since you don't
need to do "UI design" at this point. You can implement and test your
model independent of the UI -- and of course a model module may be
used by many UIs -- and then start working form the UI. But, as you
can imagine, it's rarely an all or nothing approach. I may build a
page out completely, and then move out to building the UI for a second
page, and then databind it after I get the basic structure in place.

So, from a high-level process perspective, we follow a UI-first
approach: we decide what the user wants to see and do, and then we
figure out how to implement it. From an implementation perspective,
it's flexible based on the task at hand and developer's personal
preference, but data-first is predominant so you can put all the data
controls in place that you need for the UI.

That provides a glimpse into how a very large development organization
with specialized staff approaches this problem. I recently used the
exact same approach with a small team of ~ 4 people working on a much
tighter deadline, although we varied the process as follows. As an
individual developer working alone to do the whole thing, I would use
the same basic approach.

1. UI / functional design (the user always, always comes first :-) ).
2. No UI prototyping phase, so I don't really need placeholder data
controls.
3. Technical design, including data modeling/schema changes and basic
Business Components definitions without any implementation behind them
so I can quickly produce a starting set of data controls.
4. Implementation using the new dynamic UI shell (so I started
building the application UI-first, and when I started work on my first
transaction flow, I created the task flow, generated fragments and
switched to working data-first to create the databound components).

Sorry to be so long-winded. I hope this helps!

Liza Lyons Broadbent

Senior Manager, Application Development Tools User Experience
Oracle

On Mar 25, 3:33 am, "michel.wi...@gmail.com" <michel.wi...@gmail.com>
wrote:

[Rob Nocera]

John,

Maybe a little off-topic, I apologize, but I have seen applications developed years ago in Forms where there was no direct access to any tables only a PL-SQL API layer of stored procedures.  Seemed like overkill to me especially when I was the one responsible for building a java-layer on top of it for other apps. 

I should mention that even there was even a Stored Procedure layer that wasn't allowed access to the tables directly only to the PL-SQL Data API.

It just seems like the more things change, the more they stay the same.

-Rob

[Marcos Ortega]

I think that until  database not pass to object model style , and istill remain in relational model , stored procedures API's will survive;

"re-thinking"  Also maybe in object databases , perhaps procedures API's will came in a more intense way;

 

As a metter of fact;  databases are the easiest way ( and most common way ) to connect throw serveral varieties of plataforms;

we can have java, C# , ruby ... SOA all against one database's procedures API;

      Marcos Ortega
 Analista de Sistemas
  Campo Grande - MS
http://www.santoandrea.com.br

2010/3/25 Rob Nocera <rob.n...@gmail.com>