Difference: DefiningDalStandards (1 vs. 2)

Revision 22007-09-20 - KeithNoddle

 
META TOPICPARENT name="IvoaDAL"

Notes on Defining a DAL Standard

Added:
>
>
Under construction.

 
<--  
-->

META FILEATTACHMENT attr="h" comment="" date="1190217259" name="serviceDiagram.png" path="serviceDiagram.png" size="16823" user="KeithNoddle" version="1.1"

Revision 12007-09-19 - KeithNoddle

 
META TOPICPARENT name="IvoaDAL"

Notes on Defining a DAL Standard

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

serviceDiagram.png

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.
I am using this site for some of these definitions. Other noteworthy sites can be found here and here. I suggest the following definitions meets our needs nicely:

  • 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.
  • 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.


<--  
-->

META FILEATTACHMENT attr="h" comment="" date="1190217259" name="serviceDiagram.png" path="serviceDiagram.png" size="16823" user="KeithNoddle" version="1.1"
 
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback