Paper on Software Life-cycles

Team. Here is a paper on software life-cycles. It was written by the staff or faculty of Carnegie Mellon University which has the best reputation of all software engineering programs in the United States and the oldest formal computer science program. The paper can be found at:

http://resources.sei.cmu.edu/asset_files/curriculummodule/1987_007_001_15491.pdf

We are using an evolutionary model which is simply a meticulous, sophisticated, and thoughtful build and fix approach. This probably the easiest approach when developing a new product. Prototype. Then, iteratively refine. We hope that you enjoy reading this paper. We will start supplying the life-cycle documents on Monday, 02.02.2015. La-La.

Still Writing

Team. We are still working on the life-cycle documents. There is not anything new which we can report.. Have a Great Day. La.-La.

JUGs, the ACM, and IEEE

Team. Consider joining or starting a local JAVA User's Group (JUG). These groups are fun an informative. You learn more about them at https://www.java.net/jugs/java-user-groups. Also, if you have the financial resources consider joining a professional organization such as the the Association for Computing Machinery (ACM), www.acm.org, and the Institute of Electrical and Electronics Engineers (IEEE), www.ieee.org. These are all wonderful ways of being exposed to new ideas in computing. We are still working on the life-cycle documents forCABOOSE. Enjoy your Day. La-La.

Numbering Scheme for Life-cycle Documents

Team. We will be using the following numbering scheme for our life-cycle documents.

Each feature will be numbered : F.1 through F.f.

Each requirement for feature f will be numbered R.f.1 through R.f.r.

Each specification for feature f and requirement r will be numbered S.f.r.1 through S.f.r.s.

Each architectural design element for feature f, requirement r, and specification s will be numbered A.f.r.s.1 through A.f.r.s.a.

Each detailed design element for feature f, requirement r, specification s, architectural design element a, will be numbered D.f.r.s.a.1 through D.f.r.s.a.d.

Each implementation item for feature f, requirement r, specification s, architectural design element a, detailed design element d will be numbered I.f.r.s.a.d.1 through I.f.r.s.a.d.i.

Each test case for feature f and requirement r will be numbered T.f.r.1 through T.f.r.t.

From the notes on multidimensional concern partitioning , posts on 01.07.2015 and 01.20.2015, you can conclude that each number I.f.r.s.a.d.i represents a point in our n-dimensional nominal space. Although a number such as I.0.1.2.3.4.5 is represented by digits, each digit is directly mappable to a "natural language description" of a feature, requirement, specification, architectural or detailed design element, or implementation item.

We have a small prototype whose kernel is less than 500 lines of code, 0.5 KLOC. Mostly likely, the life-cycle documents will be less than a total of twenty pages. The executive summary, the feature list, and the requirements analysis document should be available by next Monday, 02.02.2015. We have revised the deliverable date of 01.30.2015 since the extra weekend provides some "breathing room".

Keep hunting. pecking, and thinking. Smart foragers often find low-hanging fruit. Happy Coding. La-La.

Life-cycle Documents for the First Iteration

Team. Over the next few weeks, we will be compiling the life-cycle documents for the first iteration of the development process after the creation of the prototype. The documents will be placed on-line for your review. They will be composed of an Executive Summary, Feature Statement, Requirements Analysis Document, Requirements Specification Document, Architectural Design Document, Detailed Design Document, and Test Case Document. Reasoning from the prototype will help us structure these documents and ultimately the first revision of CABOOSE. We truly appreciate your participation. The first couple of documents will be placed on-line by 01.30.2015. Remember. Hunt. Peck. Think. Happy Coding. La-La.

A Draft Specification of The CABOOSE Kernel

Team. Algebraic specification works well with abstract data types (ADTs). An ADT and an object are nearly synonymous. Since we have used an object-oriented language for creating our prototype, we will use this form of specification. An algebraic specification of a module has four sections: identification, description, operations, and axioms (rules).

The identification section has three parts: the specification name, its sort (type), and an import list describing any other specifications which it makes use of in its definition. The description section is a natural language description of the sort. The operation section list the method signatures of the accessible behavior of the module. Finally, the axioms section list any rules constraining the results of the module's methods.

Below is a draft specification for the Kernel object which provides content that the general purpose servlet returns.

---<KERNEL>--------------------------------------------------------------------------------------

sort Kernel
imports VIEW_MODEL, java.lang.String, javax.servlet.ServletContext,
javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse

--------------------------------------------------------------------------------------------------

 This is the kernel of the CABOOSE general purpose servlet. Its purpose is handling any
 incoming http request with the help of support classes.

 Implicit Contract Requirements and Guidelines: The CAB contracts with support
 classes that have rendering methods which return String content. These
 methods also must have the signature public String methodName(
 java.util.HashMap<String,String> aMapParameter ) by implicit contract. If
 they do not, the reflection activities which automatically invoke them will
 fail since they cannot find the requested method. Class, method, tile
 replacement, and stencil filename identifiers are all stored in a file called
 directory.xml which contains a mapping between each item.

---------------------------------------------------------------------------------------------------

private String gettingTheResponseStencil(javax.servlet.ServletContext theServletContext, String aStencilFileName) throws Exception

String preparingTheExceptionResponse(javax.servlet.ServletContext theServletContext,javax.servlet.http.HttpServletRequest theHTTPServletRequest,javax.servlet.http.HttpServletResponse theHTTPServletResponse)

String preparingTheSuccessfulResponse(String theViewId, javax.servlet.ServletContext theServletContext,javax.servlet.http.HttpServletRequest theHTTPServletRequest,javax.servlet.http.HttpServletResponse theHTTPServletResponse) throws Exception

private org.w3c.dom.Document gettingTheDirectoryXMLDocument(javax.servlet.ServletContext theServletContext) throws Exception

void populatingTheDirectoryMap(javax.servlet.ServletContext theServletContext) throws Exception

------------------------------------------------------------------------------------------------------

gettingTheResponseStencil(theServletContext,aStencilFileName) <> ( "" | null )

preparingTheExceptionResponse(theServletContext,theHTTPServletRequest,theHTTPServletResponse) <> ( "" | null )

preparingTheSuccesfulResponse(theServletContext,theHTTPServletRequest,theHTTPServletResponse) <> ( "" | null )

populatingTheDirectoryMap(theServletContext) <> ( .size() == 0 | null )

----------------------------------------------------------------------------------------------------------------


 The type (sort) VIEW_MODEL imported in the KERNEL specification is below:

---<VIEW_MODEL>--------------------------------------------------------------------------------------

sort ViewModel
imports java.util.HashMap, java.lang.String

----------------------------------------------------------------------------------------------------------------

 This represents a model of a single view which the controller can return

----------------------------------------------------------------------------------------------------------------

String gettingTheStencilFileName() throws Exception

java.util.HashMap<String, String> gettingTheTileRendererMappings() throws Exception

void settingTheStencilFileName(String aStencilFileName) throws Exception

void settingTheTileRendererMappings(java.util.HashMap<String, String> aSetOfTileRendererMappings) throws Exception


--------------------------------------------------------------------------------------------------------------

gettingTheStencilFileName() <> ( "" | null )

gettingTheTileRendererMappings() <> ( null )

---------------------------------------------------------------------------------------------------------------

We will be reasoning from this specification during the first product life-cycle after 02.15.2015. If you need a brief review of formal specification or an introduction see this chapter by Ian Sommerville:

http://ifs.host.cs.st-andrews.ac.uk/Books/SE9/WebChapters/PDF/Ch_27_Formal_spec.pdf

It was listed earlier in last week's posts.

Enjoy your weekend. La-La.

Free JAVA Textbooks

Team. One never really knows JAVA. First, it is constantly changing. Second, there are over thirty eight hundred objects in the standard edition (JSE) alone. And, each has numerous methods and properties. You could never memorize all of these and have them available for instant recall the way one memorizes addition or multiplication tables in elementary school. Every professional engineer worth his salt uses reference material. Anyone who says that he knows a language and does not need a language reference or programmer's guide is a foolish and ineffectual engineer. Every professional should learn at least one technical text in his discipline well. Beyond that, he should simply know how one navigates and acquires needed information from available resources. Below, a few text are listed which will be useful in mastering JAVA and that are freely available on-line.

This text is printed by Oracle Press and is designed for the beginner. Oracle corporation is the best source for information on JAVA since they are the current corporate custodians of the language.

First chapter of a book by Oracle Corporation
http://www.oracle.com/events/global/en/java-outreach/resources/java-a-beginners-guide-1720064.pdf


This text covers fundamental JAVA concepts and claims that one can learn JAVA by reading one lesson per day for twenty one days.

This text covers simpler JAVA concepts
http://portal.aauj.edu/e_books/teach_your_self_java_in_21_days.pdf


This final text starts simply, but tries addressing some more advanced topics such as multithreading and graphical user interface programming with Swing classes. Each of these are more advanced topics that easily could be treated in an entire book by themselves.

This text covers simple and advanced concepts
http://math.hws.edu/eck/cs124/downloads/javanotes6-linked.pdf

We should have that draft specification for the CABOOSE kernel available in the morning. We have the pleasure of having visitors from a new region of the world:

أهلا وسهلا! نحن سعداء أنك هنا.

Automated translations are often flawed. So, please excuse any errors in this translation which should read: Welcome! We are glad that you are here.  We greatly appreciate your interest in this project.

Enjoy this day. La-La. 

Chickens, Eggs, and the Big Bang make Huevos Rancheros

Team. The art and science of creation has baffled men for eons. We all cannot currently agree on how we wound up in existence. But there are a few abstract things about creation that we all agree on. There is a creative force ( even if that force is only randomness ). This creative force created a prototypical ancestor ( even if this was only a complex molecule which could replicate itself ). This prototypical ancestor produced adapt-able offspring through the guidance of the same force which created it. These abstractions in the creation process are archetypal for the accounts arising from the oral traditions of most cultures. Yet, how does this relate with software engineering?

Within all engineering disciplines, there is the classic problem of the chicken and the egg. Which came first? Pretend you were a "mad" scientist hoping that you could genetically engineer a "super-intelligent" chicken named "Huevo Rancheros" who could perform all of your research for you and ensure that you won a triple crown: a Nobel Prize, Turing Award, and Field Medal. Would you start your creative process with an unhatched egg or mature chicken?

We can see that man's long journey began with the creation of a prototypical ancestor from uncommon and unique means, and we have been adapting in our environments ever since. So, if your goal is creating the software equivalent of a Huevo Rancheros, a phenomenon of a product, use nature's example.

Start by creating a quality prototype which you can evolve. The creation of the prototype might be more chaotic and less structured than the process of generating its adaptable offspring, but this "bootstrapping" is fundamental  in the nature of the creative process. After a few generations of evolution you might produce the equivalent of a "golden" egg!

To become conversant in software prototyping terms, visit:

http://en.wikipedia.org/wiki/Software_prototyping

Enjoy your day. That promised algebraic specification will be coming soon. La-La.

A Note on Concern Partitioning

Team. An earlier post described a method for multidimensional concern partitioning. This pattern of the separation of concerns is compatible with most if not all software development life-cycles. Some of you might have thought that the technique was taken directly from the old Waterfall Model; however, there are not any reasons why the features, requirements, specifications, abstract and detailed designs, implementations, and test cases be fixed at the end of their stage of development. With the highly trace-able nature of this approach, it is completely possible that one might modify a specification when a discrepancy is found in a design or implementation object. Remember the Number Theory of Computing, software development is iterative and optimizing. With this hill climbing approach, we are working toward finding the "unique" number that perfectly describes our system.

Also, further elaboration on the multidimensional nature of concern partitioning is needed. Each traceable path describing a concern within a system represents a point in n-dimensional space. These traces are ( feature, requirement, specification line item, abstract design object, detailed design object, implementation object, test case ). Each ordinate in these tuples is a value on a "nominal" scale. Many different scales exist for measurement. We most frequently work with ordinal scales that represent a total ordering of values. But, scales can be nominal and unordered such as the axes with the values ( apples, oranges, grapes ) and ( celery, carrots, lettuce). Example points in such a 2-dimensional nominal space would be: (apples, lettuce), ( grapes, celery), ( oranges, carrots) , and etc. Each one of our traces using this form of concern partitioning represents a collection or list of nominal values that one can interpret as a point in an n-dimensional nominal space.

For those of you familiar with calculus and the notion of summing an aggregate of point-values to produce and area using integration, the summation of all of the nominal n-dimensional point-traces describing a software represents the complete system. This is very much like the Riemann sums in calculus which is the sum of a number of discrete subareas.

This complete system is describe-able in many forms including the summation of the concern traces and that "special" number associated with each program. We will revisit these concepts when we start creating our development documents after the initial prototype.

These are just a few notes on the separation of concerns. We will talk about chickens and eggs in the morning! Please, pardon any typos. Time constraints prevented effective hunting, pecking, and thinking. This post was reviewed and re-edited around noon and again the following day. This corrected a few mistakes. Happy Coding. La-La.

Martin Luther King (MLK) Holiday.

Team. There will not be a post on 01.19.2015 since it is a national holiday in the United States where many of us celebrate by doing community service activities.

The web services are complete and we will be focusing on the algebraic specification next week. It will be included in-line in the post.

Have an enjoyable weekend. La-La.

Formalism in Engineering.

Team.

Formalism for CABOOSE:

Next week we will be working on creating a simple formal specification of the kernel of our general-purpose controller. For those of you unfamiliar with formal specification in software engineering, a chapter of an Ian Sommerville text on software engineering is available on-line at :

http://ifs.host.cs.st-andrews.ac.uk/Books/SE9/WebChapters/PDF/Ch_27_Formal_spec.pdf

It is about an hour and a half worth of thoughtful reading.

Ian Sommerville writes some wonderful text in software engineering for college students and practitioners who need review. 

Formalism in spoken language:

Besides formalism in engineering, there is also formalism in language and cultural mores. We apologize if the non-English text which we have included uses an overly informal form of "you". As you know, we have one "you" for formal and informal address and singular and plural in English. We are not sure if the translation service which we used provided us with the most appropriate form of "you" for the non-English text included in this weblog.

Hopefully, our blogging efforts will inspire some engineering work of your own.

Thank you for your time. La-La.

Preparing for Ports of CABOOSE. Volunteers Welcome.

Team. We are looking for a few well-qualified volunteers who might be interested in porting the CABOOSE MVC to other language platforms. Next, we are planning on .NET followed by the Ps (PERL,PHP, & Python). With JAVA, these likely cover most of the instances of web-scripts on the Internet which return dynamic content. If you are interested, join the CABOOSE project at java.net which provides a forum for communication. We can guide you through the development process with regular code reviews.

It might be between eighteen and twenty-four months before all of the ports are done with the resources that we currently have. As always, there is not any rush, but a few volunteers would expedite the development. Also, "well-qualified" means that you have completed at least one course in programming with a modern high-level computer language with a 'B' or better, understand proper separation of concerns, and can learn a popular integrated development environment (IDE). Also, it would be nice if you have written a few programs in the target language; however, language references and programmer's guides are readily available at developers' sites.

For our latest visitors : स्वागत है! हमें खुशी है कि तुम यहाँ रहे हैं रहे हैं।

We pray that this greeting was translated properly!

Enjoy this day. La-La.

Acronyms for JAX-WS and JAX-RS Explained.

Team. JAX-WS stands for the JAVA API for XML-based Web Services, and JAX-RS stands for the Java API for RESTful Web Services. An API is an application programming interface or library of functions (methods) which provide a way to interact with a system. A RESTful systems is one that supports Representational State Transfer. Finally, a web service is the provider portion of a service-oriented architecture (SOA) where its service consumer is a client such as a servlet, JSP, JSF, or JAVA class in a desktop application.

Since these web services work atop the hypertext transfer protocol (HTTP), they are inherently stateless. This means that the system's overall system state is not maintained between transactions much like traditional HTML pages without cookies or URL-rewriting. RESTful systems support mechanisms for maintaining system state. Upon reading more of the JEE 6 tutorial, we have found that JAX-WS is most commonly used for large web-services and JAX-RS for smaller services that might be an add-on for a larger system. Web Services are not our strength, but we will learn these concepts together as a team. Enjoy a day of endeavor, challenge, and success. La-La.

JAX-WS Webservices Primary and Secondary Up and Running

Team. This past weekend we successfully created  JAX-WS primary (server) web application and secondary (client) in our CABOOSE application which exchanged an acknowledgement message. This week we will work on adding a JAX-RS (RESTful) web-service primary and secondary.  Also, we will be brushing off our notes on algebraic specification so we can create the first draft of a formal treatment of CABOOSE. This might seem overly academic, but most of those in education say that these types of formal tasks should be performed more regularly among professional software engineers.  We will keep you abreast on our progress with JAX-RS webservices. Remember our motto: Hunt!Peck!Think! Happy Coding. La-La.

Saturday Afternoon Post

Team. NetBeans generates so much code in the creation of the web-services and their clients that it is not practical to place in-line in a daily post. Our goal is providing the final source for the prototype in the online repositories when completed. We apologize for any inconvenience that this might cause. Enjoy your weekend. For our faithful CABOOSE weblog viewers in France, Merci pour votre intérêt et support. La-La.

Links for Learning More About Web-Services with JAVA Enterprise Edition

Team. We are still working on adding the web services. One of the nice aspects of using an Integrated Development Environment (IDE) like NetBeans is that much of the web-services code is auto-generated. All one must do is complete the method stubs which the IDE generates and add any other supporting methods private, protected, package, or public.

For more information on web services with JAVA Enterprise Edition (JEE) see:

http://docs.oracle.com/javaee/6/tutorial/doc/

The JEE tutorial is rather large and more that 1500 pages in Adobe portable document format (PDF). However, the beginning of each chapter has a nice summary of the topics contained therein. It is best if you read the first paragraphs of each section of the chapter on web-services to become acquainted with them. This is only a few pages of reading in comparison with the whole text which covers other topics such as JAVA Security, JAVA Persistence, JAVA Server Faces (JSF), Servlets, and Enterprise JAVA Beans.

If you are a full-time software engineer whose primary skill-set is JEE and you have not read through this tutorial, you should. Much of it will likely be review, but you might fill in a number of gaps in your learning if there are any. You can easily skim five or ten pages in a day. In a year you will be done. It is probably best if  you try digesting it in small palatable portions.

Also, before building any web services on your own with NetBeans, please consider reading through the tutorials at:

https://netbeans.org/

Simply search for "web service tutorials". This will simplify the coding process. Enjoy this day of coding. La-La.

Making Progress Adding Web Queries

Team. We are making progress today on adding some "Hello World"-style web-service queries. This will be the bulk of our activities for this week. Have a Productive Day. La-La.

Deliverable Date Estimation and a Note On Concern Partitioning

Team. We estimate that the prototype will be completed by 02.15.2015. We will reason from it and evolve it to create our final product. This first cycle of evolution will take between nine and twelve weeks including testing. We have created a relatively small and simple project for a reason. As a well-known software engineer whose name escapes me has stated, one can create software systems which are so simple that any error would be apparent or so complex that there apparently are not any errors. Building small simple components is a good practice for software development. When developing large systems, one should develop smaller manage-able pieces which are assembled during integration testing. We have chosen a small system hoping that any error would be glaringly obvious.

A short note on discrete multidimensional concern separation:

Software is a collection of concerns. A concern is a characteristic of the system which we must consider when constructing it. This might be the nature and type of its modularity, architecture, intercommunication methods, or etc. When considering a system, one will find that during the phase of requirements engineering the software will be described as a set of features, requirements, and specification objects. Each feature produces one or more requirements. Each requirement produces one or more specification object. During the architectural and detailed design phase, implementation, and testing, the system takes the form of design objects and implementation objects which we verify with test cases. Each specification object becomes one or more architectural design objects which each becomes one or more detail design objects. Each detailed design object is an algorithm or data structure. These design objects in natural language can be directly transliterated producing implementation objects. These implementation objects are verified with test cases derived from the requirements. Each requirement produces one or more test cases. After successfully verifying our product, we must validate it. Validation is the process of receiving approval from our base of clients when they test it.

The above is a single iteration of a life-cycle using discrete multidimensional concern separation. Each set of concerns: features, requirements, and etc., represents a dimension. This approach works well for producing trace-able documents and is a wonderful strategy for a personal software process (PSP).

Remember always use the Bird Foraging Method (Hunt-Peck-Think) when coding. It makes for better software. Happy Coding, Team. La-La.

Making an Assessment of Progress and Deciding Future Directions

Team. These were the design goals for our prototype. So far, we have completed seven of ten. It has been about nine weeks with four to eight hours of effort each week. This was originally estimated at 160 hours since some of the project was unfamiliar territory. It has proven easier than expected. The outstanding goals are listed below. Since it only creates a minor speedup, we might save the enhancement with the SAX Reader until the first development cycle. The first cycle should be rather short and will involve armor-plating our prototype instead of throwing it away and starting afresh. We will consider and discuss a discrete method for multidimensional  separation of concerns (SoC) when creating our life-cycle documentation. This method might be useful for your personal software process(PSP). Software engineering research has found that all developers have one. This approach to concern partitioning might simplify yours. We might have lost a few of the more novice JAVA developers along the way. This is unfortunate. Do not give up; Ask questions and the unclear topics will resolve themselves eventually. Speed is not critical. Remember the turtle won the race and did some sightseeing along the way!La-La.

Prototype Design Goals:

Week   Goal
0      Project Overview and Discussion
1      Create "Hello World"-style program which serves up internally stored XHTML
2      Create "Hello World"-style program which serves up externally stored XHTML
3      Create "Hello World"-style program which serves up externally stored XHTML
          whose file-name we extract from an XML file
4      Extend the prototype so a method populates the #STENCIL_REPLACEMENT_VARIABLE#s
          in the XHTML page.
5      Extract the name of the method which populates the stencil replacement from an XML file
6      Consider converting between DOM and SAX XML reader for efficiency and user control over
         data structure which hold application configuration parameters.
7      Improve exception handling. Do not simply throw exceptions upward.
8      Add contracts for enforcing "program-correctness" within controller.
9      Deploy this first iteration of the evolutionary model at java.net/projects/caboose
10     Create life-cycle documents for development of the production product based on reasoning
         from this prototype

Outstanding Design Goals:

Weeks: 6,9,10 plus the following.

A. Creating and Algebraic Specification of the CABOOSE Servlet Kernel.
B. Integrating with a single Hibernate "Hello World" Query [DONE]
C. Integrating with a single JAX-WS Web Service "Hello World" Query
D. Integrating with a single Restful Web Service "Hello World" Query
E. Create test cases for each of the requirements list in the life-cycle documents.

We likely will do these in the following order C, D, A, 10, E, 9, and 6.

Goals for This Week.

Team. We should have some source on http://java.net/projects/caboose soon. Also, we should spend some time reviewing our goals and brainstorms in preparation for a presentation at the local JUG. This will likely be the bulk of activities for our week. La-La.