IT chump information technology and system administration

Home
IT Strategies
Business Applications
Information Security
Systems Management
Resources

Software Development and Programming

Framework with the following components.

  1. Components library. Components are now standardized and reused throughout the application. This will increase developer productivity and reduce go-forward maintenance time and efforts. The following components of the application have standardized.
    • Database Access – SQL and C# Code. This is accessed via a DLL and not available for developer modification. The template generation of this layer reduces the risk of bugs, reduces the developer learning curve and increases productivity as the developer’s need not concern himself with data access. Maintenance cost is also reduced.
    • Business Entities – These are classes that represent database tables. This layer is also generated with templates. The above benefits apply here as well.
    • UI to Business Layer (Page Controllers) these controllers have an object oriented model. Since all page controllers follow the same pattern the risk of bugs is reduced and time to develop is also reduced. Software modification and maintenance is also reduced due to more consistent code.
    • UI
      • AJAX (Asynchronous JavaScript and XML) is the communication layer that avoids the “post back” effect. Each page that makes use of AJAX calls the same library. 
      • xGrid. Our grid for displaying rows of data is a component and it is used in all grid use cases. The functionality is self contained and built in.
      • Form rendering engine. The Forms rendering engine can be used for AFE and non AFE forms. This accelerates development.
      • Dynamic SQL generator to support the navigator views and queries.  A high performance dynamic SQL Generator generates configurable RDBMS syntax allowing vendor to choose an alternate RDBMS (such as Oracle).
      • Profile and Child Profile implementation has been reduced to a pattern similar to the Model – View – Controller (MVC). It also uniquely uses the Inversion of Control pattern to display the fields on the form.
      • Pop-ups are standardized in the way they are called and the way they transfer data between the popup ad the calling page.
      • JavaScript libraries. Every page uses the same libraries. There is very little “one off” JavaScript.
    • New high performance Entity level security system (In progress). This is a highly scaleable system to secure entity objects in the application. It leverages built-in SQL server functionality in a unique way that limits risk of bugs and provides high performance. The security system is based on a Department of Defense approved white paper. This is particularly useful for clients which utilize a ‘negative’ security model (everything is restricted unless otherwise granted) with multiple security virtual roles.
  2. Automated data access code generation using CodeSmith. CodeSmith is a commercial developer productivity tool that enables developers to use (netTiers) templates to control formatting and desired code output. CodeSmith provides a layer of abstraction between the application development environment and the SQL data access layer (DAL) – by manipulating the API that integrates with SQL and supporting different SQL dialects (to support both SQL Server and Oracle). The benefits of using a code generator include the following:
    • A development template system for all data access code generation. DAL code for an application is one of the most monotonous, time consuming, repetitive, and likely bug-ridden aspects of building software. CodeSmith using netTiers automates this otherwise cumbersome process.
    • CodeSmith automatically produces stored procedures, C# code, data objects, web services(?), and the data access API (Gary – more than one API?). The netTiers templates could be modified to even have the CodeSmith engine produce Java code (at the DAL only).
    • DAL code now follows common rules and is consistent regardless of developer.
    • Support for a multi-database environment – namely Oracle – if desired. Note that while code can be generated for multiple SQL flavors to support a multiple database environment, this only applies to the data access layer. vendor continues to only operate on a Windows network operating system.
    • The DAL produced is the lowest level API for our system. This abstraction layer does not incorporate business rules (therefore, not applicable for client integration). Currently we are proving the technology of Server side scripting. It is our intent to deploy a server side scripting engine (Python.Net developed by Microsoft). There will be two levels. Standard business rules will be added to the system via server side scripts called before or after any CRUD event. The code to call this will be added to the DAL templates. It will use the observer pattern currently in 1.28 that updates the default security on any CRUD operation on an account. The second will be UI business rules. These are rules that need to be visible in the UI, i.e. “set the date field to today when checkbox is checked”.
    • Model-driven development is inherently more productive and agile as developers write less conventional code since more powerful application abstractions can be utilized. This approach to model-driven development is part of an initiative at Microsoft called Software Factories. Software Factories are described in depth in the book "Software Factories: Assembling Applications with Patterns, Models, Frameworks and Tools" by Jack Greenfield and Keith Short, with Steve Cook and Stuart Kent.
    • The application follows the Model-View-Controller pattern. The Model is responsible for the data, the View for the UI and the controller manages the communication between the two as well as the business logic. In our application we decided to modify it somewhat to have a controller for a page (view) because our UI is unique and another object (currently also named controller but in actuality is a mediator or broker) for each business entity. This is so we can connect any other system to the business entity brokers and still follow the same established business rules and logic UI. It is our intent to refactor these objects into the template system and in doing so rename them appropriately.
    • By following the principal that an Object has “one and only one responsibly” we have better code clarity, code is easier to modify and bugs can be isolated easier and when fixed should impact fewer subsystems. This also reduces the amount of regression testing during maintenance or version releases. In the application the UI only communicates with its assigned controller. The controller is assigned via a configuration file. This allows for rapid replacement of controller logic. The page controllers communicate with the entity brokers. The entity brokers communicate with their respective entity objects. The entity objects communicate with data access components. The data access components know how to perform the DRUD operations  

      MS released the T4 Template Engine as part of its Guidance SDK. This code producing engine does not use NetTiers. Gary anticipates modifying the syntax in the NetTiers templates to get our templates to work with T4. The advantages of using T4 instead of CodeSmith include 1) native integration into Visual Studio (therefore can execute from with VS - don’t need to go to external engine like CodeSmith) and 2) the ability to extend templates beyond the data access API (to custom forms). The T4 system is part of Microsoft’s “Guidance framework” and “Domain Specific Languages” (DSL) SDK.  The T4 system has more features than are available in Code Smith. By writing the appropriate templates we can provide developers the ability to invoke a UI to add a new profile. This UI would collect the data and then:
      1. Create the SQL Table script
      2. Create the CRUD SQL Code script
      3. Generate the business entity.
      4. Generate the business entity broker
      5. Generate business rule stub script files.
      6. Update the Meta data system.
      7. Generate the Page Controller
      8. Generate the .ASPX page
      9. Generate the FDD.xml
      10. Make appropriate configuration entries

In each of the above the template would generate all stub method with a TODO comment for anything not able to be handled by the developer.

  • Data access code generation templates. netTiers is a .NET-based template library of CodeSmith templates which abstract the data handling from the business logic (for the programmer). netTiers is an open source project (on SourceForge) consisting of a collection of templates written in C#. Templates provide the following benefits:
    • Templates use database meta-data to provide instructions to the code generation engine on what code to generate.
    • Gary estimates that 30% to 40% of version 128 bugs were related to data access errors. Templates better support code reuse and reduce the surface area of bug possibilities.
  • Automated testing system. A test framework has been created to test the web application in an automated fashion (e.g. substantiate the browser, put values in fields, test CRUD operations). The Ruby developed program doesn't yet work well with pop-ups and will continue advancement. This testing system is extendable and permits developers to test their own projects. The Ruby development language was used as Gary found an existing test library to extend, as Ruby integrates with N unit testing and as Ruby is interpreted, not compiled, which makes it much easier and faster to work with it. Another third party tool, FXcop, has yet to be implemented. vendor still needs to add and disable the desired rules which will integrate to our build process and identify coding violations. Gary is holding off until after globalization (strings) are completed.

The synergistic result of these software development automation components it to advance vendor’s development framework toward the increased utilization of modeling with patterns. This model driven process, referred to by Microsoft as the Software Factory, achieves several strategic benefits:

  • Model-driven development has migrated from the prior era of being used for conceptual documentation to actual code artifacts with precise syntax and domain specific concepts used for compilation thereby providing a level of abstraction whereby developers write less code and generated code becomes more flexible and consistent. In this way, a model is a lot like a source code file and the methods to utilize it with other artifacts are a lot like compilers.
  • Since models can abstract and aggregate information from a number of artifacts, they can more readily support consistency checks and other forms of standardization and analysis.
  • Models can be implemented by a process similar to compilation, where the code, configuration files, and other implementation artifacts generated by the compiler are never edited by hand. More often, however, they are implemented by a combination of generated and hand-edited artifacts.
  • Models used in this way are referred to as Domain Specific Languages (DSLs). A DSL is a language designed to be useful for a specific task in a fixed domain (such as CRM), in contrast to a general-purpose language. Using domain-specific languages, one can build customized modeling tools and essentially define a new modeling language and implement it very simply. For example, a specialized language may be used to describe a user interface, a business process, a database, or the flow of information, and then used to generate code from those descriptions. DSLs identify patterns used by developers, encapsulate them into a modeling language and use them to generate code. DSL authoring is supported in Visual Studio Professional Edition and above.
  • Software factories use custom collections of DSLs to build layers of abstraction and generate code for specific application types such as vendor’s CRM solution. Software Factories consist of specialized tools, processes, and other assets, such as patterns, architectures, frameworks, templates, requirements, test cases, and deployment topologies; that encapsulate the business and technical knowledge of specific problem or subject matter domain (such as CRM). Software Factories make developers more productive, by automating rote and menial tasks, and by helping them work at higher levels of abstraction. Building a factory is a lot like building a framework. It involves harvesting and implementing patterns and other best practices to make them easy for developers to apply. Using a factory is more efficient than building systems by hand from scratch because instead of scanning through catalogs and repositories, hoping to find reusable components, developers using a factory have reusable components appropriate for each aspect of the system under development immediately available in the context of the system architecture and development process. Reference MSDN Home > Visual Studio Home > Domain-Specific Language (DSL) Tools for more content.

elogo

Search | Links | Library | Rants | Raves | Site Map