The use of application development tools would be a ****tion of a
communication effort among a group of programmers. The application
development tools would provide useful templates that assist the goal of
uniformity throughout parts of the development system. Generic code can
provide functionality common to many application functions, as in the case
of loop statements, control statements etc. These are built-in constructs
provided by all programming languages, generically.
One of the most valuable benefits of object-oriented development is this
ability to share objects. A correctly built PowerBuilder application uses
the power of inheritace to minimize coding and to maximize efficiency.
Then
sharing objects increases code reliability and interface consistency and
eases the task of code maintenance by reducing or eliminating the need for
duplicate code.
The most im****tant foundation for the application is the requirement list
of
the user or client.
Program Do***entation
Do***entation of the program project is a major trade-off that must be
made
when writing software applications for a system environment. A reference
book An Introduction to Data Structures by John Beidler (Univ. of
Scranton)
publ. Allyn and Bacon, Inc. 1982 pp. 5 "The most sophisticated program can
be almost worthless if it is not do***ented in such a way that others can
read and understand how the program functions. It is im****tant to
remember
that programs must be read by humans as well as by computers. In fact,
the
biggest problems faced in software development is the modification of
programs." .. "A good measure of a well written program is this: A program
by its very existence changes its environment. It can provide new
information which in turn suggests further enhancements to the program.
If
a program can be easily modified so that it can be changed to keep abreast
of its changing environment it is one of the best tests of the quality of
the original design of the program."
"One consideration which programmers must take into account during the
design of the program and implementation is the programmer's personal
resources. These include the human time which it takes to perform the
programming process, in addition to the computer time and the computers
required to encode, debug
and carry out the program. ... Yet speed or program efficiency should not
be
used as excuses for writing programs that cannot be maintained, are
unreadable, or lack do***entation, testing, etc.."
Program Measurement
An im****tant part of simplifying the internal program design is separating
the physical details of how certain things are carried out from the
logical
requirements of what is supposed to be accomplished. Once a program
exists, new questions arise. In particular, how well does a program use
its
resources? What are the program's time and space requirements? Does the
program make efficient use of its resources? Which variables influence
the
program's resources? What effects do these variables have upon the
program
resources?
A space requirement refers to the internal memory and disk drive storage
space that is necessary to use the program. This is a requirement which
is
the sum of the space for the program and the data space. The space
requirements for the program itself are related to a specific computer
system. Normally a program is written to function within a given
hardware/software environment.
A time requirement means the amount of time used by a program. This can
be
thought of in relation to the central processor, the amount of "wall time"
(that is time measured by the clock on your wall), I/O time, etc.
The time and space required by a program depend upon:
- the actual hardware
- the algorithmic structure of the program
- the data processed by the program
With regard to the structure of algorithms, there are four considerations,
the three basic control constructs, and modularization, specifically:
1- sequencing of program steps (control construct)
2- loop control (control construct)
3- conditional code execution (control construct)
4- modularization (modularization)
Sequencing is the sum of the time for the individual steps in the
sequence.
Loop control time depends upon the number of times when the loop must
execute, plus the hardware time involved
Conditonal execution relates to a particular section, or a group of
sections
which will be executed. The execution time amounts to the time of each
sequence plus the hardware time of each sequence. see An Introduction to
Data Structures by John Beidler (Univ. of Scranton) pp. 17.
Time constraints are im****tant where it comes to meeting the internal
schedule of the program execution. In some scenarios a particular step
can
be allowed to time-out and the program execution resumes. Beidler
provides
a notation which can be used to evaluate the time required to determine
the
execution time for a program pp. 19-21. It involves the total of the time
required for sequencing, looping, and sections which are conditional, in
addition to subprograms and conditonal controls (which might include units
of time).
He adds that the data being processed can affect the time and space
requirements of the program. He considers three items:
1- The amount of data
2- The actual values of the data items
3- The organizaton of the data (is it ready for an orderly processor)
Amount of data affects the linear measure of time (how long) in terms of
reading the data.
Actual data values refers to an algorithm which is applied to the data or
the size of the numbers themselves. A multiplication by zero (0) will
take
less time then, 3456 times 233. A complex loop will take longer.
The organization of data suggests how the data will be entered. Tape
drives
are slower devices and take longer etc.
Beidler suggests pp. 22 finding a bound on the program execution time or
the
most im****tant variable of the timing equation. Then focus upon how the
program time changes as that variable gets larger. Using the structure of
the program and assuming that any sequence of instructions is bound by
some
constant K, the timing result is based upon the number of these sequences.
A collection of counting methods can be used to approach the program
timing
issue, by building prototypes that execute commonly used steps and
iterations. The loops can be counted (number of executions) using an
incrementing, counting variable every 100 iterations perhaps Beidler pp.
25.
And for sub loops they set up a MIN and MAX which will be averaged, and
added to the program time in pro****tion to terms of the conditional
execution.
Overall, the program timing depends upon the time of execution required by
any sub programs, plus the requirements for a main program section. Some
****tions of time can be fixed by a standard unit time delay.
Some Logical Structures
This section is from reference book An Introduction to Data Structures by
John Beidler (Univ. of Scranton) Chapter 3 pp. 37. "This chapter
represents
an intuitive description of several of the structures that are studied
(throughout). Actually most of these structures can be represented in
many
ways, and the problem of choosing a structure and its appropriate
representation is really two distinct problems:
1- Selecting the appropriate structures to represent and solve a problem
2- Selecting the appropriate representation of the structure to fit into
the
problem's solution and resources.
The structure of a problem and the structures that lead to an efficient
solution can sometimes defy the clarity needed to understand them. A
structure in a software program or in data, refers to both a real
structure
(in the computer) and the applied structure, how it is used. When asked
to
state the structure of a building, a college, or a cor****ation the issues
are presented from observers points of view. The applied structure, how
it
is used becomes one of access and utilization. see An Introduction to
Data
Structures by John Beidler (Univ. of Scranton) pp.2.
"As essential data structure techniques are attempted, the im****tance of
good programming practices become more apparent. In particular, by
carefully studying the logical requirements of a program, and working out
the logical requirements before generating the code, many potential
difficulties will be bypassed. If more time is spent understanding a
program
and designing the logical requirements of an algorithm, then less time
will
be spent patching and debugging an inapproproate program."
The book An Introduction to Data Structures by John Beidler (Univ. of
Scranton) proceeds to chapter 2 where a discussion about program
measurement is developed. "Basically, given a computer system, a program
has two resources, time and space, whose usage is affected by three
factors - (1) hardware, (2) the algorithm, and (3) the data...
Structured programming assists the programmer with the question on how
well
does a program use its resources?. Which variables influence the
program's
resources. The section considers the effects of the algorithm, and the
data
upon the program's timing. Hardware is considered but I see the hardware
as
being beyond what I can worry about.
There is no complete and exhaustive collection of program measurement
techniques. Program measurement can be difficult and sometimes
impossible.
Basic techniques of measuring a program's time requirement and methods of
recognizing certan recurring timing situations are available. Space
requirements can be described using these techniques as well An
Introduction
to Data Structures by John Beidler (Univ. of Scranton) pp. 15.
Space and Time Measurement
For the most part the preliminary interest would be to use Access data
storage in connection with other Microsoft data sharing applications.
This
type of office automation and data sharing will occur often with the use
of
LAN network technology within an organization. We note below that office
automation is one of the five (5) application types which are used as
broad
categories.
The types of applications are five (5) computer-based application areas
which are (1) expert systems (ES), (2) management information systems
(MIS),
(3) decision sup****t systems (DSS), (4) office automation (OA). Office
automation includes -word processing, video conferencing, email,
electronic
calendaring, facsimile transmision, and desktop publi****ng, etc. (5)
accounting information systems (AIS).
Each of these 5 application areas expert systems, MIS, DSS, OA, and AIS
represents a subsystem within an application which is dedicated to using
information produced among the these components (data integration), and
dedicates those results produced to the higher-level problem solving
application.
Programming may have generally been the only way to access and manipulate
a
database from within another application, but some other programming books
are around for the purposes of comparison and alternatives to the
reference
we use, "Excel VBA Programming" book, authored by Duane Birnbaum. The
practice of database programming is not an original thought from VBA and
Microsoft. It occurs to me that OLE provides data movement between
applications. Data integration is a matter of using data which is
comparable, and is amenable to summing, and/or shared inputs and outputs.
He is suggesting that non-programmed GUI interfaces, that are also
programmed (some language other than VBA) are nothing new. His book is
about VBA and programming, which is how his comparison works. This
statement by Romans must include OLE, a part of the standard Microsoft
GUI.
Romans says, "that database design, and database programing are not
related
in the sense that knowledge of one leads directly to knowledge of the
other,
they are defintely linked, by the simple fact that a power database user
needs to know something about both of these subjects in order to
effectively
create, use, and maintain a database."
A good place to begin work with the development of prototypes would be to
reengineer some of the examples found in database or SQL books. A common
example gven insuch books would be the library catalog of books, or movie
actors and their movies. A good exercise would be to diagram the entities
of these databases, and otherwisse diagram the flow chart of that system
architecture (blueprint). At that point add new items to the diagram
which
are could make useful add-ons to the design model. And then make a
prototype database which uses your new add-on, and test how it works.
Logical vs. Physical Structure
The Database Application GUI
"In fact, it might be said that creating and maintaining a database
application in Microsoft Access is done in three (3) broad steps
-designing
the database, creating the basic graphical interface (i.e, setting up the
tables, queries, forms, and re****ts), and then getting the application to
perform in the desired way." Romans book Preface.
- designing the database
- creating the basic graphical interface (i.e, setting up the tables,
queries, forms, and re****ts)
- getting the application to perform in the desired way
The creation of the database application GUI is fairly straight forward,
since it is mostly a matter of becoming familiar with the relatively easy
to
use Access graphical user interface. A dozen books with thousands of
pages
are devoted to Microsoft Access.
Steven Roman does not discuss forms and re****ts which are used within
Microsoft Access. Neither will he discuss database security or
replication
or client server issues involving multiple users. Roman has been able to
keep the book short by avoiding those three subjects.
- forms and re****ts
- database security
- replication
- client/server issues involving multiple users
"Gary D Man" <captntony@[EMAIL PROTECTED]
> wrote in message
news:mIidnfXdKMYl37rVnZ2dnUVZ_g-dnZ2d@[EMAIL PROTECTED]
> the traits of this problem resemble the deisgn of a method known as a
> hierachical database. That type of a form is used for static
information,
> which comes in levels of authority.
>
> President-
> - Marketing/Chief Technology Offier/Human Resources
> - Assistant 1, Assistant 2
>
>
> - where the dashes separate the levels of authority.
>
> In the case we are considering, the first levels are your modules, or
what
> is known as program space.. That would be a term used by Biedler in his
> book PowerBuilder 4 Adv. Techniques. He considers execution style,
data,
> essential factors (variables) that govern the program section.
>
> You might want to use interger math, or floating point, in two versions
of
> the same module for exemple.
>
> The structures work outr like C language structures or typedefs., in
that
> one structure can include some subtypes. thos would be your sub version
> issues like fixes, or type of program modifier.
>
> Create the problem before solving it. And then don't worry about it.
>
>
> "Logan Shaw" <lshaw-usenet@[EMAIL PROTECTED]
> wrote in message
> news:4823c8cb$0$3386$4c368faf@[EMAIL PROTECTED]
> > James Harris wrote:
> > > Is there any mileage in devising a general application version
> > > numbering scheme and providing sup****t this in a programming
language?
> > > The reason for asking is that it seems useful, in terms of managing
a
> > > computer system composed of many modules, for the components of that
> > > system to have at least
> > >
> > > <user version info>.<feature>.<fix>
> > >
> > > where
> > >
> > > <feature> increments on each /release/ of a new feature set
> > > <fix> resets to 0 or 1 on each feature change and increments on
> > > each released bug-fix
> > >
> > > The user version info would be arbitrary so could include higher
level
> > > version numbers or not as needed. For example, MyApp.2.1.4 would be
a
> > > release of "MyApp.2" feature set 1 and fix version 4.
> > >
> > > Why offer sup****t for this in a programming language? For two
reasons,
> > > 1. it provides intrinsic sup****t for releases of standard (and
> > > possibly other) libraries for the language; 2. it offers this
sup****t
> > > to applications (and system programs) written in the language. These
> > > are only worth doing if the scheme is general enough.
> >
> > IMHO, no scheme is likely to be general enough that having a single
> > scheme is sufficient most of the time. No matter what assumption you
> > make about release cycles (and relation****ps that "always" hold
between
> > one release and another), your assumption will ultimately be violated
> > eventually (and then your model will break).
> >
> > I think what I'm saying is that programming languages are so general
> > (or should be so general) that trying to solve this problem in the
> > programming language seems like a bad idea. Ultimately, it's the
> > environment and cir***stances of an individual application (or
> > "project", whatever term you want to use) that determine the needs
> > for a scheme for naming releases. And hopefully a programming
language
> > is general enough to be used for multiple different types of
applications
> > with different needs! (Well, ignoring domain-specific languages.)
> >
> > To make that a little more concrete, some complications you might
> > see are:
> >
> > 1) Some applications might not choose to define a total ordering
> > of version numbers. It's simpler to comprehend if all
development
> > proceeds along a single line, always marching forward towards the
> > end-state of perfection. But in reality, customer A demands an
> > immediate fix for bug 1 and customer B doesn't care about bug 1
> > but does demand an immediate fix for bug 2. Fixes for bugs 1
> > and 2 go into version N+1, but there is no inherent ordering
> > between bug fix 1 and 2. You can ignore this issue by speaking
> > of only "official" releases, thereby forcing everything into a
> > nice linear sequence of releases, and maybe that's all that you
> > care about. But whether you want to force everything into a
> > single sequence is something that depends on the software.
> > For example, some software is developed without any customers
> > in mind, and in that case, a linear model is easy enough to
> > maintain.
> >
> > 2) The semantics of the actual version number vary between one
> > piece of software and another. In the standard Linux-inspired
> > versioning scheme, versions are a list of numbers, and there is
> > some number in the list which has a special status so that odd
> > numbers mean "unstable" and even numbers mean "stable". For
> > example, in the Linux world, kernel version 2.6.25.2 is
> > (nominally) stable, but version 2.5.x is not. The difference
> > lies in the fact that *second* number is odd. Of course,
> > it would be just as valid for some other project to define
> > 8.x as stable (because 8 is even) and 9.x as unstable (because
> > 9 is odd. To put this a different way, every project has a
> > function mapping version numbers to meanings, and that
> > function tends to be different for different projects.
> > The reason this is significant (to me) is that the ability
> > to manipulate version numbers (other than as opaque strings)
> > rests largely on being able to assign meaning to different ones.
> >
> > Because of all this, if one were to try to "solve" the version
> > numbers problem (and I use quotation marks because I don't know
> > if it is ultimately solvable in the general case), there would
> > be a lot of custom, per-application behavior required. Therefore,
> > it seems like trying to move this into the language is probably
> > a bad idea, unless it is done in a very general manner. And
> > by "general", I mean allowing the individual application to define
> > relations between version numbers ("X is more stable than Y",
> > or "A has more features than B", or even "C is the freeware
> > version of "D"), allowing the rules to change over time, and so on.
> >
> > - Logan
> >
> > P.S.: On the other hand, there can be some value in a language
> > providing direction and forcing 95% of the applications
> > into a certain mold. At least insofar as the applications
> > don't have any strong preference of their own.
>
>
|
