ADF Module Specifications?

[Campbell Darren]

Hi,

I'd like to move away from writing throwaway technical specs for ADF development and start writing reusable module specs instead. Anyone doing this already that might like to suggest an approach? Ideally, I'd like to use some form of automated documentation tool to give us a head start, but I have no idea if such a thing even exists for ADF.

Current thinking is to consider a whole application as one module and the individual jspxs as sub-components in a similar way to how we might think of one Oracle Form having many canvases. In this case, we'd probably want to list the EOs, VOs, methods (showing parameters, logic etc), UI Design & page flow etc.

I'm from a PL/SQL background btw, so I don't instinctively think of UML etc, but I am open to it if you think it's appropriate.

Thanks.

Regards,

Darren

Darren Campbell

Regards,

Darren

Darren Campbell
Systems Designer (QMT)
2 Central Quay
89 Hydepark Street  Glasgow  G3 8BW

tel: +441415344069
Follow us on Twitter @ACCANews
www.accaglobal.com


Accountants for business – creating sustainable value
www.accaglobal.com/accountants_business

_______________________________________________
ACCA may monitor and read all e-mails as it is presumed that they are sent or received in connection with the business of ACCA or for business use only. ACCA also monitors e-mails for security reasons to ensure that no unauthorised disclosure of ACCAs confidential information is passed via the e-mail system.
This e-mail and any attachments are confidential. It is intended for the recipient only. If you are not the intended recipient, any use, disclosure, distribution, printing or copying of this e-mail is unauthorised. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and delete the e-mail from your computer.
The contents of any attachment to this e-mail may contain software viruses, which could damage your own computer system. While ACCA has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should carry out your own virus checks before opening the attachment

[Chris Muir]

Hi Darren

Having done this in the past for ADF 11g and an eye to architecture (see
this presentation:
http://download.oracle.com/otn_hosted_doc/jdeveloper/11gdemos/AngelsInTheArchitecture/AngelsInTheArchitecture.html)

....I suggest your documentation break-up follows the architecture path
you choose to follow for your application development.

Given that you're coming from a Forms background, can I highlight the
fact that your thinking in specifications and designs needs to be around
Bounded Task Flows (BTF), not JSPXs. Yes, JSPXs, the layout and
functionality they provide is important, but from an architecture and
design point of view you'll find that working at the BTF level is much
more productive and suits the service oriented development approach of ADF.

In returning to the question of design specs, certainly you'll need an
overall application doc that looks at your architecture + granularity of
your BTFs + how they all fit together.

And then following the "services" nature of BTFs & ADF, and a
deriviation of one of the sum-of-the-part patterns from the previous
presentation, I suggest you'll have a design/specs for each BTF
workspace, be that a fine grained BTF architecture or a wide grained
cylinder pattern.

As such no UML required, just a documentation plan based around your ADF
architecture. (Does anyone use UML anyway these days?, no no, don't
answer that, there's sure to be someone who still thinks Grady Booch is
an IT deity ;-)

Regards,

CM.

> Follow us on Twitter _@ACCANews_ <http://www.twitter.com/accanews>
> ___www.accaglobal.com___ <http://www.accaglobal.com>__
>
>
> *Accountants for business � creating sustainable value
> **_www.accaglobal.com/accountants_business_*
> <http://www.accaglobal.com/accountants_business>**

>
>
> _______________________________________________
> ACCA may monitor and read all e-mails as it is presumed that they are
> sent or received in connection with the business of ACCA or for business
> use only. ACCA also monitors e-mails for security reasons to ensure that
> no unauthorised disclosure of ACCAs confidential information is passed
> via the e-mail system.
> This e-mail and any attachments are confidential. It is intended for the
> recipient only. If you are not the intended recipient, any use,
> disclosure, distribution, printing or copying of this e-mail is
> unauthorised. If you have received this e-mail in error, please
> immediately notify the sender by replying to this e-mail and delete the
> e-mail from your computer.
> The contents of any attachment to this e-mail may contain software
> viruses, which could damage your own computer system. While ACCA has
> taken every reasonable precaution to minimise this risk, we cannot
> accept liability for any damage which you sustain as a result of
> software viruses. You should carry out your own virus checks before
> opening the attachment
>

> --
> 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
>
> All content to the ADF EMG lies under the Creative Commons Attribution
> 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/). Any
> content sourced must be attributed back to the ADF EMG with a link to
> the Google Group (http://groups.google.com/group/adf-methodology).

[Chad Thompson]

On Nov 8, 2012, at 8:07 PM, Chris Muir <chris...@gmail.com> wrote:

Given that you're coming from a Forms background, can I highlight the fact that your thinking in specifications and designs needs to be around Bounded Task Flows (BTF), not JSPXs.  Yes, JSPXs, the layout and functionality they provide is important, but from an architecture and design point of view you'll find that working at the BTF level is much more productive and suits the service oriented development approach of ADF.

.. and as an addition, you'll find (possibly) that many of your use cases might be able to take advantage of partial page refreshes - so the concept of designing around "screens" can get a little hairy.  Focus on what the app "does" in BTF design, not "what it looks like".

In returning to the question of design specs, certainly you'll need an overall application doc that looks at your architecture + granularity of your BTFs + how they all fit together.

And then following the "services" nature of BTFs & ADF, and a deriviation of one of the sum-of-the-part patterns from the previous presentation, I suggest you'll have a design/specs for each BTF workspace, be that a fine grained BTF architecture or a wide grained cylinder pattern.

As such no UML required, just a documentation plan based around your ADF architecture. (Does anyone use UML anyway these days?, no no, don't answer that, there's sure to be someone who still thinks Grady Booch is an IT deity ;-)

… what!?!?  Don't forget Jacobsen and Rumbaugh!!  :-)

The one UML practice I still try to bring over to ADF app design is the use of Activity diagrams in the "what an app does".  (People used to call them "flowcharts", but "Activity Diagram" sounds better.  (And given ADF - or even modern java web app - architectures, it's actually kind of rare to do a big Sequence/Object/State design like we did with servlet/jsp apps.)

- Chad

-- 
Chad Thompson 
chad_t...@mac.com

[Campbell Darren]

Thanks very much Chris, and Chad.

Regards,

Darren

Darren Campbell
Systems Designer (QMT)
2 Central Quay
89 Hydepark Street Glasgow G3 8BW

tel: +441415344069

Follow us on Twitter @ACCANews
www.accaglobal.com

Accountants for business - creating sustainable value
www.accaglobal.com/accountants_business

-----Original Message-----
From: adf-met...@googlegroups.com
[mailto:adf-met...@googlegroups.com] On Behalf Of Chris Muir
Sent: 09 November 2012 02:07
To: adf-met...@googlegroups.com
Subject: Re: [ADF EMG] ADF Module Specifications?

Hi Darren

Having done this in the past for ADF 11g and an eye to architecture (see
this presentation:
http://download.oracle.com/otn_hosted_doc/jdeveloper/11gdemos/AngelsInTh
eArchitecture/AngelsInTheArchitecture.html)

....I suggest your documentation break-up follows the architecture path
you choose to follow for your application development.

Given that you're coming from a Forms background, can I highlight the
fact that your thinking in specifications and designs needs to be around
Bounded Task Flows (BTF), not JSPXs. Yes, JSPXs, the layout and
functionality they provide is important, but from an architecture and
design point of view you'll find that working at the BTF level is much
more productive and suits the service oriented development approach of
ADF.

In returning to the question of design specs, certainly you'll need an
overall application doc that looks at your architecture + granularity of
your BTFs + how they all fit together.

And then following the "services" nature of BTFs & ADF, and a
deriviation of one of the sum-of-the-part patterns from the previous
presentation, I suggest you'll have a design/specs for each BTF
workspace, be that a fine grained BTF architecture or a wide grained
cylinder pattern.

As such no UML required, just a documentation plan based around your ADF
architecture. (Does anyone use UML anyway these days?, no no, don't
answer that, there's sure to be someone who still thinks Grady Booch is
an IT deity ;-)

> *Accountants for business - creating sustainable value