(r2) DefiningDalStandards < IVOA

IVOA Web>IvoaDAL>DefiningDalStandards (revision 2) (raw view)~~EditAttach~~

---++ Notes on Defining a DAL Standard

Under construction.

<!--
When embarking upon the definition of something as profound and all-encompassing as a  network application standard, due consideration must be given to all aspects of the problem it seeks to address. It is particularly important to have a context within which the standard is defined and evolved. This page proposes such a context.

---+++ The Problem

Or should that be opportunity? Either way, it must be defined and bounded if the standard is to have any hope of emerging fully formed and within a reasonable time frame. It is OK if the standard evolves over time, but the basic requirements for each evolution must be set.
The time honoured way of defining the problem is to produce a Statement of Requirements. The modern way to do this is through the production of a series of Use Cases that fully encapsulate the scenario being addressed and the mechanisms used to address it. Defining the requirements must also be done within the context of the architecture of the infrastructure itself.

---+++ Architecture

<img src="%ATTACHURLPATH%/serviceDiagram.png" alt="serviceDiagram.png"  width="548" height="386"  />

---+++ Defining Use Cases

The subject of much thought and the production of many books, a basic agreement as to what constitutes a Use Case must be reached. Use Cases themselves need to be organised into groups and priorities from which the requirements for a given revision of the Standard can be agreed. This is the Use Case Suite. The primary goal of writing use cases is to specify the system to be built. No single use case specifies the entire requirements of the system. Each use case merely explains one particular interaction.
<br>
I am using [[http://readyset.tigris.org/][this]] site for some of these definitions. Other noteworthy sites can be found [[http://www.readysetpro.com/][here]] and [[http://alistair.cockburn.us/index.php/Structuring_use_cases_with_goals][here]]. I suggest the following definitions meets our needs nicely:

   * [[http://readyset.tigris.org/nonav/templates/use-cases.html#UC-00][Use Case]]: A use case bridges the gap between user needs and system functionality by directly stating the user intention and system response for each step in a particular interaction. Each use case should show a straightforward example of the user succeeding at a goal. The steps in a use case are almost always a linear sequence.
   * [[http://readyset.tigris.org/nonav/templates/use-case-suite.html][Use Case Suite]]: An organized suite of use cases is needed to fully specify the software requirements. A Use Case Suite is effectively table of contents for the individual use cases. 

---+++ Satisfying Use Cases

When formulating solutions to Use Cases, it is vital that the key elements of the system are considered, namely, Client, Payload, Protocol and Service (see Architecture). Each must be used correctly and not overloaded with features that rightly belong in other areas. Whilst we may compromise over where certain functionality is implemented, we should only do so where there is a clear and compelling need so to do, not because it provides a short term gain. To do so is to invite deep rooted problems that will be hard or impossible to solve at a later date.

-->

<br/>
<!--
      * Set ALLOWTOPICRENAME = %MAINWEB%.TWikiAdminGroup
-->

Topic revision: r2 - 2007-09-20 - KeithNoddle

IVOA

Log in or Register

IVOA.net
Wiki Home
WebChanges
WebTopicList
WebStatistics

Twiki Meta & Help
IVOA
Know
Main
Sandbox
TWiki

TWiki intro
TWiki tutorial
User registration
Notify me

Working Groups

Interest Groups

Time Domain

Committees

Stds&Procs

www.ivoa.net
Documents
Events
Members
XML Schema