Software Architecture: a Roadmap

I was attending a MSDN webcast last night and David Garlon was explaining the importance of software architecture and how it plays very important role in creating a quality ,scalable software even for small and large scale software projects.

I thought to write an article to our members sharing the importance of software architecture and try to adopt across all the projects. Nowadays anybody is writing a program even professional ,non-professionals and it turning a bit costlier for the softwares getting developed by them.

Just all they do is learning a syntax of a language either(C,C++,VB.NET,C#) for a while and sit as a programmer to write a worst code in thier life.Mc Darwin says cut the hands of the programmer whom writes a code which is not under a software ethic and I agree him 100%

Over the past  software architecture has received increasing attention as an important subfield of software engineering. During that time there has been considerable progress in developing the technological and methodological base for treating architectural design as an engineering discipline. However, much remains to be done to achieve that goal. Moreover, the changing face of technology raises
a number of new challenges for software architecture. This article examines some of the important trends of software architecture in research and practice, and speculates on the important emerging trends, challenges, and aspirations.

THE ROLES OF SOFTWARE ARCHITECTURE

While there are numerous definitions of software architecture, at the core of all of them is the notion that the architecture of a system describes its gross structure. This structure illuminates the top level design decisions, includeing things such as how the system is composed of interacting parts, where are the main pathways of interaction, and what are the key properties of the parts. Additionally, an architectural description includes sufficient information to allow high-level analysis and critical appraisal. 

To elaborate, software architecture can play an important role in at least six aspects of software development.

1. Understanding: Software architecture simplifies our ability to comprehend large systems by presenting them at a level of abstraction at which a system’s high-level design can be easily understood . Moreover, at its best, architectural description exposes the high-level constraints on system design, as well as the rationale for making specific architectural choices.

2. Reuse: Architectural descriptions support reuse at multiple levels. Current work on reuse generally focuses on component libraries. Architectural design supports, in addition, both reuse of large components and also frameworks into which components can be
integrated. Existing work on domain-specific software architectures, reference frameworks, and architectural design patterns has already begun to provide evidence for this.

3. Construction: An architectural description provides a partial blueprint for development by indicating the major components and dependencies between them. For example, a layered view of an architecture typically documents abstraction boundaries between
parts of a system’s implementation, clearly identifying the major internal system interfaces, and constraining what parts of a system may rely on services provided by other parts.

4. Evolution: Software architecture can expose the dimensions along which a system is expected to evolve. By making explicit the “load-bearing walls” of a system, system maintainers can better understand the ramifications of changes, and thereby more accurately estimate costs of modifications. Moreover, architectural descriptions separate concerns about the functionality of a component from the ways in which that component is connected to (interacts with) other components, by clearly distinguishing between components and mechanisms that
allow them to interact. This separation permits one to more easily change connection mechanisms to handle evolving concerns about performance interoperability,prototyping, and reuse.

5. Analysis: Architectural descriptions provide new opportunities for analysis, including system consistency checking, conformance to constraints imposed by an architectural style, conformance to quality attributes , dependence analysis,and domain-specific analyses for architectures built in specific styles.

6. Management: Experience has shown that successful projects view achievement of a viable software architecture as a key milestone in an industrial software development process. Critical evaluation of an architecture typically leads to a much clearer understanding of requirements, implementation strategies, and potential risks.

More I will write in my next article,Sorry If I was more hard.

Advertisements

Best design patterns for code reuse in ASP.NET

During my last UG meet , several members where asking which design pattern would be the best design pattern to promote code resuse  in ASP.NET and I am writing this article after a long day at office I dedicate this article to my friends Gopi & Mithun whom forced me to figure out the best design pattern and write article on the same.

When developing complex dynamic ASP.NET applications, it’s important to minimise code duplication to increase the reusability and flexibility of the application. In some applications, users may perform many different actions that have different controller logic but result in the same view (e.g., showing a products list and allowing a user to add or delete a product will lead to displaying the same products view with the modified data after the controller leads the user through the add or delete process).

The first step toward developing reusable logic is minimising the amount of code in scripted server pages. The logic on scripted pages is difficult or impossible to reuse and results in poor separation between the view and the controller. They are also more difficult to test and debug. Instead of adding script code to an .aspx page, it’s more efficient to implement the controller using classes, which allows you to implement common appearance and navigation across your Web application and reuse presentation logic throughout the application.

There are two different patterns that address the implementation of controller classes for ASP.NET applications. The Page Controller assists you in building an application in which the navigation patterns are static but the pages are generated dynamically. For more complex applications where the navigation is dynamic or configurable based on a set of rules (e.g., user privileges or application state), the Front Controller allows for a more efficient implementation. Let’s look at each of these patterns in more detail.

The Page Controller pattern
When using the Page Controller pattern, a central class called the BaseController implements all common behaviors required to handle the HTTP request, update the model, and then forward a request to the appropriate view. The BaseController handles common functions such as session management, security, and the retrieval of data from query strings or hidden fields. For each link in the Web application, you then create an individual PageController class that inherits from the BaseController. These individual PageControllers implement any page-specific behavior while using the core functions as implemented by the BaseController.

In many cases, your application can be decomposed into a series of common page types that share common logic. For example, you may have a series of data entry pages or grid view pages that all share logic. In such cases it may make sense to implement a DataEntryController or a GridViewController that inherits from the BaseController class. From these you can then implement PageControllers that use their common methods. You must be careful not to implement too many layers of inheritance or the application design may become difficult to maintain. You can minimise the inheritance chain by creating sets of “helper classes” with common code that any level of the chain may call.

To implement the Page Controller pattern, you create the BaseController class by inheriting from System.Web.UI.Page and then implementing the common application functionality. For example, the BaseController may implement a common look and feel by providing a header, footer, and some user-specific information (e.g., logon name and department). Then you create each page of the application by inheriting from this BaseController class and implementing its page-specific logic in classes placed in the codebehind file. This works for moderately complex applications with a fixed navigation path. If you need dynamic navigation, you need to implement the Front Controller pattern.

The Front Controller pattern
The Page Controller pattern becomes inefficient when you need to coordinate processing across multiple Web pages because of its implementation of a single object per logical page. The Front Controller is more efficient in such cases because it funnels all requests through a single controller and then directs requests through a single handler and a hierarchy of command classes. The handler retrieves parameters from the HTTP request, chooses the correct command, and transfers processing to it. After each command object performs the specified action, it can choose which view is required to render the page properly. Implementing the Front Controller results in more centralised application control because all page requests come through a single controller instead of being handled by different Page Controllers. But this can also be a liability if the handler does expensive processing, such as database lookups that could cause the entire application to operate slowly. The handler should be as efficient as possible and use external resources only when absolutely necessary. You should also consider caching any external resources to increase the handler’s performance.

You implement the FrontController class by creating a Handler and a CommandFactory, which determines the necessary command to execute in response to a request. ASP.NET provides the IHttpHandler interface to allow developers to create custom interfaces required to service incoming HTTP requests. You implement the Handler by inheriting from System.Web.IHttpHandler and adding the logic to instantiate and call the appropriate command from the CommandFactory. The CommandFactory defines a collection of commands and the logic that determines which of the commands should be executed. Calling the CommandFactory returns the appropriate Command object for which the Handler can call an Execute method. Using this pattern, you can create more robust navigation scenarios and implement them centrally by extending the CommandFactory logic and creating additional commands to handle the required scenarios.

Architectural patterns
.NET Architects should strive to use architectural patterns whenever possible. Patterns such as the Page Controller and Front Controller are easy to implement using built-in features of ASP.NET, and they result in highly reusable and extensible application designs and implementations.

RadGrid 5 PDF Export

I was doing some little bit R&D on RAD Grid last night and would like to share a good feature and here is that… 

The biggest new features in RadGrid 5.0 is support for export to PDF. For quite some time, RadGrid has supported direct export to Microsoft Word and Excel formats, but the addition of PDF export elevates the Grid’s exporting capabilities to unprecedented levels. Using the new export feature couldn’t be easier. As with previous export formats, all that is required is a call to a single simple RadGrid method:

this.RadGrid1.MasterTableView.ExportToPdf();

When you call this method, all of the data in the Grid is exported to a new PDF that the users can then save to their local file system. The PDF is saved in a format that is compatible with Adobe Acrobat Reader 4.x and higher and by default uses the file name “RadGridExport.pdf”. If you do not like this name, you can change it in the new RadGrid ExportSettings section. This section gives you control over a number of PDF and general export parameters, such as:

  • FileName: change the file name of the exported file
  • ExportOnlyData: indicates if links and other basic HTML will be preserved on export (CSS styling will not be exported)
  • PDF Specific Settings:
    • Author: sets PDF metadata author value
    • Creator: sets PDF metadata creator value
    • PaperSize: sets PDF paper size
    • PageTitle: sets PDF page title (rendered on top of page)
    • Title: sets PDF metadata title value
    • Keywords: sets PDF metadata keyword value
    • AllowPrinting/Add/Copy/Modify: indicates if users have permission to print/add/copy/modify exported PDF

There are more settings available for controlling RadGrid exports, but the basic point is that you have a fair amount of control over your exported documents. You don’t have total control, though, so don’t expect RadGrid to provide the same level of formatting that you can find in Telerik Reporting. Exporting data to PDF from RadGrid will not preserve the Grid’s skin. Data will be rendered without any of the CSS styling you see in the browser and will use only the default font settings. You cannot control the PDF’s font size, color, face, or other formatting settings. You essentially get to set the page size, margins, and metadata and then let RadGrid do the rest. For more advanced exporting, you’ll need to check out Telerik Reporting.

Still, if you’ve been dying to offer PDF export to your users for RadGrid-based data, this is an amazing feature. It works without any trouble right out of the box and doesn’t require any special coding or web.config changes. This should be a great feature for anyone looking for a “poor man’s” reporting solution or the flexibility to export data in a universally readable format.