Team. Inspired after a brisk walk on a treadmill, we felt enough motivation for zipping a couple of Microsoft Windows folders and placing them on Google Drive. The PHP archive contains the CABOOSE Type-II MVC and the StoryBoard archive holds the multi-page XHTML 1.0 CABOOSE site.
You will see that some trade-offs exist when the site is implemented as a CABOOSE MVC. First, a slight increase in the total number of lines of code occurred; however, the total man-hours were less. For one, each of the views share a single XHTML template. This provides a single location for any needed modifications. When building the storyboard, we started with a standard XHTML template and built the CABOOSE HomePage. After we produced a product with which we were satisfied, we replicated it and modified the core body content. Then while testing, a short revision cycle occurred. But, since we had a number of webpages, tweaking was required in more than one place so each page would have an identical header and footer. This increased the effort more than writing a couple of PHP methods in a page handler for returning the body content. The second downside of CABOOSE development it the computational overhead associated with using dynamic invocation in certain languages. In PHP, this in minor and only requires a couple of extra steps when evaluating an expression. We believe that it is not as expensive as using the reflective invoke in JAVA; however, this itself is not overly costly. Initially, JAVA reflective capabilities were extremely expensive in terms of computation cycles. The engineers at Sun greatly improved upon this time cost over the years. It is now minimal. But, a cost still exists; however, using the reusable CABOOSE kernel as a servlet or ViewEngine with Ozark has the potential for greatly reducing development effort. Consider structuring an development team as a tree after the initial storyboard which defines all of the dynamic content areas has been developed. The tier of team leads can partition the needed handler methods and any associated data transactions among their subordinates. Each of these subordinates is a leaf in a communications tree which resembles a top-down development architecture. Requests travel downward and the responses that result in the assembly of a complete system travel upward. This structure alleviates some of the communication overhead found in teams whose structure is a clique as described in the Mythical Man-Month. Trees are the sparsest of all connected graphs having at most n-1 edges which represents the bi-directional communication channels for n nodes or employees. In contrast, a clique structure has n(n-1)*0.5 bi-directional communication channels which lessen the effectiveness of crash cost when additional developed resources are placed on a team near a deliverable date. More communication pathways increase the possibility of miscommunication and added confusion in those last few hectic hours of a project. With the proper structure, the CABOOSE approach might lessen communication overhead and by supplying a better organization of concerns reduce time cost.
Also, although building a CABOOSE MVC might not be extremely simple for a novice developer, using this approach when provided the reusable controller likely has a lesser learning curve than other MVC products.
That is Enough Effort For This Weekend. Happy Coding.
The CABOOSE Team
No comments:
Post a Comment