Boundary Value Testing

Team. We found a couple of weblogs which discuss different issues in software testing. They are at:

http://writingtestcases.blogspot.com/2013/07/boundary-value-analysis-example.html

and

http://blog.sei.cmu.edu/post.cfm/common-testing-problems-pitfalls-to-prevent-and-mitigate

The first entry discusses boundary value testing. For most of our test cases, we will test three conditions based on the return value from the stencil tag handler. This value can be a null, empty, or arbitrary length alphanumeric string. So our our boundary condition is based on string length: (null, 0-length, and greater than 0); Remember we are not testing the functionality of a complete web application; we are only assuring the quality of the generic controller for creating these type of systems. As a result, the testing will not be as involved.

There are some interesting fact in the second weblog which quantify the cost of software testing failures each year in the United States economy alone.

We will have more for you on Friday. La-La.

Testing Strategy

Team. Our CABOOSE controller has only one primary function, invoking a user-defined method of a given class and replacing a specified string in a text file with the return value from it. This action should be viewed as being atomic. Beyond this, we will be spending most of our time testing the exception handling. The exception handling which we use should be somewhat more detailed. For one, we should probably define exception classes. We should also allow for maintaining process histories with JAVA logging facilities. Plus, we should support the aspectual concerns in each page with #BEFORE# and #AFTER# task handlers. These features might be found in the second revision.

The main approach for ensuring quality which we will use is boundary value testing. The test cases should be available on 03.01.2015.

Enjoy each day's sun and rain. La.-La.

Life-Cycle Document Revisions - Subversion (SVN) - Translating with Lexicon.xml

Team. We have a few outstanding issues remaining before we move on and start our .NET port. First, the life-cycle documents need revising, plus we must produce the test case document. With our other responsibilities, this is between three and four calendar weeks of work. We are estimating completing these documents by the end of March 2015. Initially, our estimates for project completion was 15 March 2015. The current revision of the source should be available by then at the Subversion (SVN) repository on java.net for caboose. It likely will not have full support of the directory.xml translation feature; however, it might if we have time for implementing it. Adding the translation feature will take a pair of calendar weeks at the most. Completing this in parallel with the document revision should be possible. Also, we must start evangelizing the product. Our first efforts at increasing public awareness will likely be at JAVA User Group community meetings starting in April of May 2015. We also are currently using Google AdWords as a part of this effort. We appreciate your interest. Have a Wonderful Day. La-La.

Draft of Detailed Design Document Ready

Team. I could only find a couple of hours for working on this. It still needs a few revisions. Here is the Google Drive link:

https://drive.google.com/file/d/0B101EUHMgepNbzBSSmtpcS1DdTQ/view?usp=sharing

Hopefully, your weekend went well. Happy Coding: Hunt, Peck, Think...La-La.

Working on the Detailed Design

Team. We are working on the detailed design. Each low-level detailed design item will map directly with an high-level architectural design item. Logically, they will be more closely associated with each of the specification items. Their architectural counterpart fixes their location within the high-level design while their respective nearest associated specification item provides a description of the behavior of the system which they realize. This document will likely have the most line items.

Next Week

With eight hours of effort available this weekend, we will hopefully complete the detailed design. As always, our goal is keeping the document short. This should be delivered on Monday. Next week's project is the servlet's test cases which should arrive the following Monday. Also, between now and the 03.01.2015, we must learn how one creates an online mirror for our local Subversion (SVN) source code management repository at java.net. So, we will be skimming the SVN documentation given in yesterday's post.

This places about a week behind our scheduled pace; however, we are not in a rush.

Enjoy your weekend. Use it Wisely. La-La.

Subversion (SVN) Document | Concurrency in Life-Cycle Stages

Team. We have been silent on this weblog for a couple of days and busy with other tasks.  For those of you considering creating a similar project or who would be interested in source code management,

Source Code Management

I have included the following web document:

http://svnbook.red-bean.com/en/1.7/svn-book.pdf

It is a text which covers source management with Subversion (SVN). Some web sources state that creating online mirrors with SVN is much easier than the alternatives.

Concurrent Life-Cycle Processes

Although there are not any formally recognized life-cycle processes which allow for parallelism between the major stages of activity, except for possibly the Rational Unified Process (RUP), completing the high-level design in parallel with the requirements engineering tasks might be advisable. Simply allow for flexibility in your architectural design choices. The first popular model for life-cycles was the Waterfall which was used in the early days of structured development during COBOL's reign. Interestingly enough, it did not allow for the parallelism commonly found in COBOL process flow-charts.

We appreciate your active readership. La-La.

Five Out of the Seven Life-Cycle Documents and a Few Notes

Team. We have made progress on five of seven of the life-cycle document drafts. The first three which were posted on Google Drive at the end of January have been revised. They had a few spelling and grammatical errors plus word misuses.

There three new links for the Executive Summary, Feature Specification, and Requirements Analysis Document. The old versions of these files are still available at the links given when they were created. Each document is less than 15 minutes of reading.

These documents can be found at the following links:

Executive Summary

https://drive.google.com/file/d/0B101EUHMgepNSWx0M0ZiOTl2SGM/view?usp=sharing

Feature Specification

https://drive.google.com/file/d/0B101EUHMgepNWHBhaGlFSl9XVDg/view?usp=sharing

Requirements Analysis Document

https://drive.google.com/file/d/0B101EUHMgepNekJseExZWG5IMmM/view?usp=sharing

System Requirements Specification

https://drive.google.com/file/d/0B101EUHMgepNNEtRbXpTTjVlSk0/view?usp=sharing

Abstract Architecture Document

https://drive.google.com/file/d/0B101EUHMgepNWnVyQ0xBTi1QT1E/view?usp=sharing

OpenOffice 4.0

These documents have been checked with the OpenOffice 4.0 Spellchecker. For an open-source office productivity product that is reasonably reliable visit:

www.openoffice.org

Multi-dimensional Partitioning of Concerns

When you look at the structure of the numbering scheme (stage_letter feature#.requirement#.specification#.architecture#...), you will see that numbers expand in a network-fashion that resembles a tree as a result of iterative refinement. But when we take a step upward in our level of abstraction during the high-level architectural design, you will see a number of repeated architectural design items associated with differing specification items. The network will expand again with the detailed design items.

We are designing a component for a specific architecture. So, we made our architectural design decisions early; they are mentioned in the Executive Summary. This is not always the recommended practice, but it makes development easier. If our product was not for a specific architecture, we would choose a prototypical high-level design before proceeding. This is necessary since the architectural decision is another chicken and egg problem in software engineering. One only can optimize requirements decisions if one knows the high level design for which he is developing.

Subversion (Source Code Repository)

Currently, the source resides in a local repository. That library will be migrating and placed at http://java.net. It might take a couple of weeks. We are working on mirroring the local SVN repository,

https://svn.java.net/svn/caboose~caboose-code

,online. There are three NetBeans Projects in the repository : CABOOSE, JAXWSHello, and JAXRSHello.

Testing CABOOSE

JAXWSHello and JAXRSHello must be deployed and running before one can populate their replacement tiles on the "landing" web-page. Also, a Derby database resource must be created with the name caboose and a single table named CABOOSE with a pair of fields, ID which is an integer and MESSAGE which is a variable length character field. It should contain only one record with an ID of 100 and a MESSAGE of "HIBERNATE Connectivity Established!" The username and password for the resource should be "root" and "root", respectively. Also, one should remove the comments from the directory.xml tile elements for Hibernate, JAX-RS, and JAX-WS connectivity one at a time.

This is all for now. Happy Coding. La-La.

Software Life-Cycle Processes and Operating Systems

Team. This post is based on abstract concepts in software development life-cycle (SDLC) processes and computer operating systems (OS). In yesterday's post, we wrote:

One of the design goals of a popular operating system is expediting the common case of computing. This means that for the normal case, ninety-five percent of the applications it sees, it will perform well and quickly. This is also a wise goal of software engineering processes, accelerating the common case of development. This can be done quite well if one looks for applications in which he might apply the tenets of general-purposeness. These rules are fairly simple. One must balance ease of use and the breadth of the domain. A wider the domain signals a more likely increase in the complexity of the general-purpose engine.

This paragraph combined ideas from operating systems and software engineering. Eventually, the idea arose that developing a standard operating system for life-cycle processes might be beneficial.

A SDLC as a process has many abstract similarities with the more complex processes found in software. It often requires some form of multiprocessing or multithreading of its sub-tasks. Such tasks might be the activities found in requirements engineering, design and analysis, coding, or testing. These individual tasks might require intercommunication for completing their work. They require both memory in the form of documentation and processing in the form of engineer effort. The sub-processes of the SDLC require management. There are a number of traditional management roles in an SDLC, one being project management. The modern operating systems, such as Windows and Linux which we use, supply a pair of needed computing functions. The first allows for administrative control over a computer's hardware. The second allows for an interface between the computer and a user.

An OS for SDLCs would be a mixture of documented business processes and simple software tools. It would be both a set of management paradigms with managerial architectures providing administrative control and a grouping of methods for seamlessly interfacing with the workers and work products of the process. This might be a great paper, thesis, or dissertation topic for a student of software engineering.

Also, combining OS and SDLC concepts is a rather new area of human endeavor versus well-known concepts of general engineering. These principles have been studied since the building of the Great Wall and the Pyramids. It might be the case that someone has built or proposed an OS with a structure and facilities based on engineering concepts and roles. If not, it might be an excellent paper, thesis, or dissertation topic for a computing systems major.

This post is a slight digression from our topic. We hope that you do not mind, and some of the college students reading this weblog find these discussions useful. Many cannot pursue all of the ideas which cross their mind. Others suffer from "creative-blocks" at times especially when dealing with the performance anxieties of college. Remember "computing is for the birds". Hunt. Peck. Think. La-La.

A Short Note Added Later In the Day

We should clarify that we are not implying by our emphasis on hunting, pecking, and thinking that our readership is a flock of "bird brains". This would be an insult in many English speaking countries. Nor are we implying by this post that we are some great geniuses tossing unwanted crumbs at those who cannot intellectually fend for themselves.

A popular religious text states:
   
Consider the ravens: They do not sow or reap, they have no storeroom or barn; yet the Creator feeds them. And how much more valuable you are than birds!

One of its writers also states:

No one should seek their own good, but the good of others.

So, we simply are seeking the good of others when sharing ideas which might be of value for them. Please pardon us if you were offended. A full day of work is allotted for the life-cycle documents this weekend. We will share the results on Monday. Enjoy your weekend. La-La.

A Note on General Purpose Processors

Team.  As you know, our goal is producing a general purpose web-script for the controller portion of layered type-II model-view-controller web applications. The first iteration of this script will be in JAVA and will take the form of a servlet.

There have been some recent discussions in the Communications of the ACM about the fallacy of general-purpose processors. The article discussed forms of central processing units which are commonly found on a computer’s internal circuit boards. The premise of the article was that calling something such as a graphics processor “general-purpose” was misleading. This is because that author had the fixed notion in his mind that anything which is general-purpose and used for computing should work in any computing application. He felt that these should be considered "special-purpose" processors. There is some validity in this argument; however, it is somewhat overly” rule-based”. In other words, the argument is pedantic.

As you know, processors can be in the form of hardware or software. Also, there are many categories of computing problems. Each category represents a set for which one might produce an application that meets the needs of one or more of its problem instances. If one produces an application that meets the needs of all of the problems within a given set, it is a general-purpose processor for that domain.

So, when one discusses general-purposeness, one must consider the universe of discussion. This also is necessary when one discusses any set. Our universe of discussion is controllers that process text-based markup descriptions of interface views. It might seem somewhat narrow; however, it literally contains an infitude of possible application instances.

This approach in computing is very worthwhile. For one, it promotes a very natural form of code reuse. A general-purpose processor driven by configuration files is much like a method with its parameter list. For those of you who are computing students, remember those lessons on computing history that discussed the advantages of using functions in structured programming versus large monolithic programs. Structured programming is often an after-thought and likely rarely mentioned in many current classrooms with the inherent structure in objects. But the evolution from unstructured-ness through structure that resulted in objects and aspects is worth teaching.

One of the design goals of a popular operating system is expediting the common case of computing. This means that for the normal case, ninety-five percent of the applications it sees, it will perform well and quickly. This is also a wise goal of software engineering processes, accelerating the common case of development. This can be done quite well if one looks for applications in which he might apply the tenets of general-purposeness. These rules are fairly simple. One must balance ease of use and the breadth of the domain. A wider the domain signals a more likely increase in the complexity of the general-purpose engine.

There are a number of places within the JEE technologies that one might create one of these processor. For instance, one might be for JAX-RS root resources. an engineer might also consider developing a framework for creating this. Such a template could be used by different organizations for their unique needs.

We hope that this posting length is not overly tedious. We should also add that the ACM is a wonderful organization. Consider joining, www.acm.org. The ACM needs more participation especially from women and under-represented minority groups. Hunt.Peck.Think. Daydream. Create. La-La.

Still Making Progress

Team. We are still making progress. We are somewhat inundated with other responsibilities this week. We will have more life-cycle documents next week. Thanks for your interest. La-La.

More On The Life-Cycle Documents

Team.We are still working on compiling the first draft of the life-cycle documents and desk checking the prototype. We will be posting our work soon. We appreciate your interest. La-La.

For those of you who would like some links for related material, visit this Pinterest board:

https://www.pinterest.com/caboosemvc/java-caboose/

CABOOSE Project Status 02.06.2015

Team. The week we set aside for compiling the first draft of the life-cycle documents has become a couple and might be three. We will supply the test case documents along with those remaining artifacts next week. Based on the planned schedule posted on 01.06.2015, we are slightly behind. The source will be checked and placed in the java.net repository by 03.01.2015. This might be a couple weeks after the first projected deliverable date for the prototype source. The general-purpose controller prototype in JAVA also has support for Hibernate, JAX-WS, and JAX-RS transactions. Basically, it can processing anything which a handler method send it as a String object. Remember our String Theory of Computing. We are ultimately only processing sequences of symbols that we can always interpret as a String regardless of their context or the meaning which we give them. Also, we have not forgotten the potential benefits of using a serial SAX reader for processing our XML files and building our map of view model objects. This will eventually be done instead of using a DOM reader which places the entire file in an intermediate data structure.

We are dusting off our text on .NET (in particular C# since the syntax is so near JAVA). This will be our first port. We will find a repository for the Microsoft-based code in the coming months and be starting our netcaboose.blogspot.com trail. It is not active yet. We are also hoping that we can find a "free" integrated development environment for .NET development that produces runnable object files. But, lets not put our cart before our horse and take everything a step at a time. We appreciate your readership and interest. Enjoy this upcoming weekend. La-La.

More on Build and Fix, Synonyms for Computing, Plus Page Concerns

Build and Fix

Team. As noted in the last weblog posting, engineers build products and, when they do not work as expected, fix them. A common and often criticized metric for coding productivity is the number of lines of instructions (LOC) produced by an engineer in a given period. The primary reason that this is an unreliable measure for production rate is the ease at which it can be inflated. Consider a frugal manager who decides that he will pay his engineers at a rate of a penny per line of code on top of a very modest salary. In fact, he invests a portion of his departmental budget in a line counting program, because he is so certain that this is the best way of motivating his staff's performance. At the end of the first months when drafting the paychecks, he discovered that he owes his college intern over ten billion dollars for a simple controlled-break report which was the students only work assignment. He asks if he can see the source for the program and finds the following method at the top of the intern's program:

void livingLikeAZuckerberg( int x ) {

    if ( false ) x++;
    ...repeated for over a 100 billion pages
    if (false ) x++;

    return;
}

While this an extreme example, it shows why lines of code is a poor measure of performance. Measuring error rate works well. However, the bottom line of software engineering is that it is a business. The bottom line of business is the total cost versus revenue, profit. One product might have thirty errors addressed in the first year of production at a total cost of two hundred and fifty thousand dollars. Another might have fifty errors remedied in the first six months of production requiring seventy-five thousand dollars. So error rate does not fully quantify cost and the goal of any business is reducing cost and increasing income.

Note that being free of errors is synonymous with the notion of producing a working software system which requires very little, if any, fixing. This is a state of high productivity. Since managerial concerns usually center around cost with person-hours being a major cost in engineering, consider measuring the cost of building versus fixing effort as a metric. For enhancements which fall in the grey area between building and fixing, they can be added into both the numerator and denominator of the measure.

It should also be added that using the forethought activities found in more formal and rigorous software life-cycle processes plus documenting are essential techniques for reducing fixing time.

Synonyms for Computing

Computing, although an ancient practice, is a rather new formal discipline in terms of using automated processors. We are still discovering new characteristics of this discipline and inventing terms for describing them. Consider familiar concepts such as the notion of "one"-ness. How many different ways are there for describing it. Let us count a few: first (1), once (2), single (3), unitary (4), and etc. Consider "two" with couple, double, pair, second, twain, twice, and etc. The concepts of "one" and "two" are very commonplace.

But, what about "concern". Of course, computing students would say that concerns are aspects, functions, procedures, modules, methods, subroutines, and the "like". Yet, these are only behavioral concerns. The notion of a concern is much more abstract. It literally means anything which one must consider when building a system. And, the well-partitioning of these "considerations" is quite important when building software.

Certainly, thesaurus.com or an old Roget's thesaurus will provide one with numerous synonyms for the word "concern". However, each one which we utilize when discussing software limits the number available for other topic contexts and can muddle understand. For instance, a modern work on separation of concerns would likely not use the word "aspect" for signifying a "characteristic" of a software system other than a concern which occurs before, during, or after a method.

What's the solution for our limited vocabulary? Seeing that modern languages stem from older forms of other languages, maybe we should simply consider adopting equivalent terms from other modern languages when writing and discussing computing. Based on BabelFish and Google Translate, the following terms are the non-English equivalents of concern in a few of the world languages that are short an memorable:

                  affaire, asunto, sak, sprawa, umur, & vec
 
For readability, we only used translations that are written using English alphabetic characters. Bear with us for a moment while we experiment with using the above terms as synonyms for "concern" in the following paragraph which discusses CABOOSE and its page concerns. The terms have been pluralized using the English custom of adding an "s".

Page Asuntos
 
If it has not already been emphasized, CABOOSE provides a better and simpler mechanism for partitioning of concerns than other open-source model-view-controller systems. Affaire separation is a fundamental in CABOOSE. As has also been said, a concern is not necessarily "behavioral" such as a function, method, or procedure. After designing a markup-based storyboard presentation of a working system. Each dynamic portion of a given web document stencil, page vec, can be directly mapped with a sak handler. The placeholder for the textual representation of this concern with be a stencil replacement variable. If a given page sprawa does not render properly, the portion of code which requires inspection is localized. One is not left tracing the definition and uses of variables throughout a large codebase in search of the lines of code which generated this segment of the page. The directory.xml file provides a listing of all of the page umur and their handlers in the system.

Given that the translation of these terms is "concern", hopefully this increased the read-ability and quality of this paragraph versus the constant repetition of the word "concern". If your mother-tongue was not included in this list of synonyms, please do not be offended.

This should be enough for now. Enjoy this day. La.-La.

Its All Basically "Build and Fix"

Team. When studying software engineering, one learns of the many differing formal life-cycle models. This ranges from prototyping and the evolutionary model to the numerous formal risk assessments of the spiral model. It includes the standard Waterfall model and its notion of a "phase" which one should not confuse with the use of the term "phase" in the Rational Unified Process (RUP). But the crux of the activity is "building" software. If it does not verify, validate, or work as expected in production, one must "fix" it. So all the glorious models in computing envisioned by the greatest minds of this and the past millennium, are ultimately "build" and "fix" models. Yet, young engineering students are told that one should not simply "build and fix" software and that such an approach will only produce the "kludgy"-est of products.

The primary distinction between the "ad-hoc" build and fix approach which we are counseled against and the other processes which we use is the amount of forethought and documentation generated in the process. Creating software is much like writing a term paper for a college course. One can simply sit down at a computer with only a topic and without any research materials, an outline, or thesis statement, and he can start typing. This would likely be a very frustrating approach that would produce a product of less than marginal quality. This is the equivalent of software engineering's "ad-hoc" build and fix model. More formal simple models are the equivalent of writing a structured essay or theme whereas the most rigorous of models parallel creating a "research-grade" professional academic paper.

Also, much like a theme with its thesis statement that must be the last sentence of the introduction, the equivalent of the topic sentence for the summary or conclusion, and sub-divisible into three logical parts which become the topics for its body paragraphs, developing software follows a formulaic pattern. Besides the research which one does for identifying the needed library calls for doing the necessary work in a method, coding any behavioral concern always requires identifying the required inputs, the necessary outputs, and the transformations which produce the output from the input. This is the basis for the ideas on formal "program-correctness" proofs. Using this approach, one can always start with a "Hello World"-type method that simply echoes its input and evolve it from there. Remember, the number theory of computing. One starts with an estimate of the final program, and through the iteration and optimization of that guess one eventually arrives at the desired product. This  approach would be the same as writing the last sentence of the introduction of your theme plus the topic sentence of each body paragraph and the conclusion and then filling in the rest.

Ultimately, all we do is build and fix; however, our primary goal is that we spend more time building and less fixing. Although a fluctuating feature set can require constant "fixing", quality change management can limit such fixes.

Always remember the virtues of hunting, pecking, and thinking. So, build slowly and fix less. Enjoy this day. La-La.