On Software Engineering

Model-View-Presenter (MVP)

2011-01-19T11:21:00.000-08:00

The main purpose of the Model-View-Presenter (MVP) design pattern is to separate domain and application-specific logic (the Model) from the user interface (the View) of the application. The advantages of this separation of concerns are three-fold:

1. Domain logic is not dispersed in the user interface code. When domain logic is strongly coupled with the user interface code, there is a high likelihood of code duplication. Less duplication facilitates debugging, maintenance, enhancements and promotes code reuse.

2. The user interface can be changed independently of the Model in many cases where the application requirements have not fundamentally changed. For example, to enhance usability it may be desirable to change a spin control to a slider control. Similarly, the actual implementation of the Model may be changed to use a different persistence model or to use a smarter algorithm

3. Last but not least, the separation of domain logic from the user interface greatly facilitates unit testing of the code.

Now that we have established the goals and benefits of separating domain and application-specific logic (the Model) from the user interface (the View), let’s delve into how MVP design pattern is useful. It is noteworthy that there are several variations of MVP and its predecessor Model-View-Controller (MVC) design pattern. For the purpose of this discussion, we will let our intuition derive a practical variant of MVP. To begin, we pose this question: Based on the goals and benefits of separating domain and application-specific logic from the user interface, what are some of the desirable attributes of an implementation? We explore this question through a few concrete examples:

1. We want to be able to change the gadgets and controls used on the View without massive refactoring of the code.

2. We want to be able to use a desktop database for one version of our application and a client-server database for another version of our application without having to duplicate too much code.

3. Based on a user, we want to display only certain fields on the View.

4. For an advanced user we want multiple views to show the same information in different ways (for example, a chart and a grid). We want these views to remain synchronized when any of the views are updated.

It is evident from the examples above that we need a degree of separation between the View and the Model. This is where the Presenter comes into the picture. Presenter is essentially the go-between the View and the Model. So what would we expect a Presenter to do? Here are some common tasks suited for the Presenter:

1. Create and display the View

2. Obtain data from the Model and pass it along to the View for display to the user

3. Be aware when a User modifies data on the View. Presenter may need to update the Model or ask the Model for recalculation of some sort. Presenter may need to update some other portion of the View as a result. The View handles basic user interaction (processing of keystrokes to accept data from the user) whereas the Presenter is responsible for making application-specific responses (update the Model and triggering a recalculation).

Now let’s examine some things the players in the MVP implementation must not do:

1. Presenter must not call or manipulate the widgets (controls) on the View directly. We want the ability to swap one implementation of the View with another. If the Presenter called methods on the widgets (controls) directly, this ability will be compromised.

2. View must not manipulate the Model directly. Recall it is the job of the Presenter to marshal the data between the Model and View. This might seem a bit cumbersome but in the bigger scheme of things it is desirable to separate the Model from the View. For example, if there is a need to change the Model later, we will need to change the Presenter and the View code as apposed to just the Presenter code.

We now see dependencies and interactions developing among the players in an MVP implementation:

1. Presenter relies on the View and the Model. Presenter is responsible for preparing and formatting the data suitable for display by the View. The Presenter provides this data to the View through a well-defined interface. The View is responsible for actual visualization of data for the user. The Presenter is also responsible for retrieving any modified data from the View. The Presenter is responsible for preparing and formatting the data suitable to be passed onto the Model for further processing or persistence. Again, the data is passed to the Model through a well-defined interface.

2. The implementation of the View and the Model shall remain independent of the Presenter. To achieve this, we need well-defined interfaces for the View and the Model that the Presenter can talk to. Any View or Model that implements an interface expected by a Presenter can be readily plugged into implementation.

3. The Presenter is also an observer of the events that occur in the View and the Model. Consequently, the View and the Model must publish events that the Presenter can subscribe to. For example, a Presenter may subscribe to a new user data entry event published by the View. Upon receiving notification of such an event, a Presenter may update the Model. A Presenter may also subscribe to data change event published by the Model. For example, if the Model changes due to some outside operation, the Presenter is made aware of the change and can accordingly update the View. Using this mechanism, a Presenter can even manage multiple Views and keep them synchronized.

Figure 1 summarizes the dependencies discussed above.

To be precise, the Presenter interacts with a Model and View that implement interfaces expected by the Presenter. We call these interfaces IModel and IView, respectively in Figure 2. Any View or Model that implements the interfaces expected by the Presenter can be plugged into the implementation.

Finally, let’s put everything together. We begin with construction of a Presenter object. The Presenter object either takes a View and a Model object as arguments in its constructor or instantiates these objects in the constructor. Usually there is a method called Initialize() on the Presenter object that sets the wheels in motion. Presenter.Intialize() creates the View and provides data to the View obtained from the Model. The Presenter then displays the View to the user. The Presenter also subscribes to events of interest published by the View and the Model. Upon receiving such events, the Presenter takes appropriate actions such as updating portions of a View or updating the Model.

Figure 3 shows a sequence diagram summarizing what happens when a user updates data on a View.

The user enters data in one of the controls displayed by the View. The View notifies the Presenter of this data entry. The Presenter asks the View for the updated value. Finally, the Presenter formats this data appropriately and passes it onto the Model for persistence.

Figure 4 shows how the Presenter reacts when the Model is changed externally.

A change is detected by the Model as a result of an outside operation such as an update to the database or an update to the Model by another component. The Model notifies the Presenter of the change. The Presenter obtains the updated data from the Model. The Presenter properly formats the data and passes it onto the View for display to the user. Note if the Presenter is managing multiple Views, the Presenter is in an excellent position to update and synchronize all the Views it is managing.

The apparent disadvantage of using MVP is the extra coding involved in separating the Model, View and Presenter. However, for most applications that involve user interaction, time invested in implementing MVP is well worth the benefits that come with separating domain and application-specific logic from the user interface.

Dimensions of Software Testing

2011-01-18T16:04:00.000-08:00

As Agile developers, we are most accustomed to writing Unit Tests for our code. There is a lot more to software testing than Unit Testing alone. In order to release a robust software product, we need to devise and implement tests to cover other dimensions of software as well. Testing can be can be sliced in various ways. The following are several different ways to view software testing.

Purpose

Correctness
Scalability
Performance
Load (Stress)

Granularity

Unit
Functional
Integration

Tier

User Interface
Business
Service
API
Database

Proof

Positive
Negative

Environment

Operating System
Database Server
Application Server
Web Server
Browser
Runtime, Virtual Machine

Scope

Smoke
Regression
Full

Deployment

New
Existing (Upgrade)
Various Platforms

Three things all Units Tests must do

2011-01-18T15:59:00.000-08:00

Unit Tests verify correctness of a discrete piece of code. Regardless of the application domain and the unit test tools utilized, there are three things a well-written unit test must do:

Create and verify prerequisite state for the action to be tested
Execute the action to be tested
Verify post-action state

Example

Let's say we have a system that allows warehouse employees to ship products. A ShippingOrder is an object in the system that contains the products to be shipped. Our business rule states that a ShippingOrder can only be processed (shipped) if all products in the ShippingOrder are in stock. In other words, we want to verify that either all products in a ShippingOrder are shipped or none of the products in the ShippingOrder are shipped based on stock availability. Our Unit Test will verify this behavior of the ShippingOrder.

1. Create and verify prerequisite state

Before a test is executed, we want to ensure that the environment in which a test is about to be executed is known and verified. It is important to stress that it is not sufficient to bring the test environment into a known state but also to explicitly verify the state before execution of the action. This is typically done using ASSERTs provided by the Unit Testing framework. In our example, we have at least three stock level conditions:

S_1. All Products in the ShippingOrder are in stock

S_2. None of the Products in the ShippingOrder are in stock

S_3. Some the products in the ShippingOrder are in stock

We have identified three states of product stock levels and hence we will be executing at least three tests. Before each of the three tests is executed, the corresponding state of the stock levels of products in the ShippingOrder must be established and verified by our test setup code. Our test code will create three distinct ShippingOrder objects corresponding to these states. Lets call these objects SO_1, SO_2, and SO_3. The test setup code must also verify that these three ShippingOrder objects are in Pending state.

2. Execute the test
Our test is going to verify that a ShippingOrder can only transition to a Shipped state when our business rules are satisfied. We will be writing at least 3 actions:

T_1. Use SO_1. Try to transition ShippingOrder to a Shipped state.

T_2. Use SO_2. Try to transition ShippingOrder to a Shipped state.

T_3. Use SO_3. Try to transition ShippingOrder to a Shipped state.

3. Verify post-action State

Once the test action is executed, we verify the post-action state of SO_1, SO_2, and SO_3 using ASSERTs provided by the Unit Testing framework:

V_1. Verify SO_1 is in Shipped state

V_2. Verify SO_2 is in Pending state

V_3. Verify SO_3 is in Pending state

SOA Application Blueprint

2011-01-18T15:52:00.000-08:00

Here is a simple blueprint for building an application based on the Service Oriented Architecture (SOA).

The various participants in this architecture are as follows:

Application Domain Layer (ADL)
ADL is where the business logic or the brains of the application resides. ADL is the most valuable piece of this architecture. ADL should closely model the business entities, processes, and workflows without regard to data persistence or the user interface. ADL should be testable in isolation. Full suite of unit, functional and regression tests must be maintained and continuously executed. To isolate ADL from the Data Persistence Layer (DPL), a Data Persistence Adapter (DPA) is introduced.

Data Persistence Adapter (DPA)
DPA implements a well-defined interface that ADL uses to persist itself. A concrete implementation of DPA makes specific calls to the Data Persistence Layer (DPL) to do the actual saving and loading the of the data. A concrete, mock DPA should be written that emulates known data save and load behaviors. The mock DPA can be utilized by the ADL Test Suite to exercise the functionality of ADL on an ongoing basis.

Data Persistence Layer (DPL)
In most system implementations, this is the relational database management system such as Oracle, Microsoft SQL or equivalent. ADL never talks to DPL directly. Only Data Persistence Adapter (DPA) has direct interaction with Data Persistence Layer (DPL) usually through ODBC, JDBC, or a .NET Data Provider.

Application Service Layer (ASL)
ASL is the immutable interface to the System. The existing service methods and data contracts of ASL are never changed once published. However, new service interfaces, methods and data contracts can be added to extend the functionality of the application. The primary consideration in the design of this layer is the ease and efficiency of consumption of ASL Services by its clients such as the Application Presentation Layer (APL) and the Batch and External Systems (BES).

Application Presentation Layer (APL)
APL is the user interface of the application. It usually takes form of a Web Site or a Desktop Application. APL never calls ADL, DPA, or DPL directly. It does all data querying and manipulation through the Application Service Layer (ASL).

Batch and External Systems (BES)
An application may require offline, asynchronous, or batch processing. Furthermore, external systems may need to access the System to query or update data. Like APL, BES never calls ADL, DPA, or DPL directly. It does all data querying and manipulation through the Application Service Layer (ASL).

Using Queues to improve performance and reliability

2011-01-18T15:49:00.000-08:00

Enterprise Systems typically involve two or more applications that collaborate with each other to run a business process. One of the ways that participants of an Enterprise System can share information is queuing. Logically speaking, queues are a system resource where applications in an Enterprise System can place messages for each other. Microsoft Message Queuing (MSMQ) is an example of such a queue.

Message queues provide a repository for inter-application messages and ensure guaranteed delivery of messages. In MSMQ, a queue may be defined as a transactional queue ensuring that the messages are enqueued, and hence dequeued and delivered, in the original order. Furthermore, a transactional queue persists each message received to ensure guaranteed delivery in case of a system crash.

Queues are useful in many Enterprise System scenarios. These scenarios have one thing in common: one application places a message in the queue and another application picks up the message from queue and acts on it. This allows us to distribute work among applications in an Enterprise System. Queues can also improve throughput of an Enterprise System.

Let's consider a stock order processing system that receives a stock order from client applications through a web service call to an endpoint it hosts. The orders must be processed in the order they are received and must not be lost. During peak trading hours of trading, it is likely that the stock order processing system will be receiving orders at a much higher speed than it can process them. In a monolithic, single-threaded stock order processing system, the throughput of the stock ordering system is constrained by the speed at which it can process the orders. Granted to improve performance we can spin two threads: one to receive orders and the other to process the order. But to ensure guaranteed delivery and in-order processing of stock orders received we will have to cook up our own scheme.

Now consider how we can design the stock order processing system more elegantly using queues. Our System will have three components:

Transactional Queue
Listener Application
Order Processing Application

Transactional Queue

A transactional queue can be created using MSMQ.

Listener Application

The job of the listener application is to simply host the endpoint for the receiving the stock order requests and to enqueue these requests as messages into the Transactional Queue.

Order Processing Application

The job of the Order Processing Application is to dequeue a message from the Transactional Queue and to act on it (i.e. to route stock orders to an external trading system).

Some of the benefits of this queue-based design are follows:

Stock orders delivered guaranteed because of the Transaction Queue
Stock orders are processed in the order they are received because of the Transaction Queue
The Listener Application continues to enqueue Stock Order messages even if the Order Processing Application goes down or can't keep up with the rate at which the stock orders are being received
We are able to scale Order Processing Application up (more powerful machine) or out (more machines) to improve throughput of the stock order processing system

Enterprise Application Integration Patterns

2011-01-18T15:45:00.000-08:00

Messaging Pattern

The Applications participating in an Enterprise Solution communicate with each other using a common messaging system. The message publishing application follows the fire and forget model where it places a message in the shared messaging system and forgets about it. Other interested applications listen for these messages and act on them as business rules dictate. The most common implementation of a messaging system is a queue. The queue semantics ensure delivery of messages in the order they are received. A robust messaging system guarantees delivery via local persistence of message and multiple delivery attempts. The delivery guarantee is important because all participant applications in an Enterprise Solution may not be online all the time. Microsoft Message Queuing (MSMQ) and Oracle Advanced Queues are examples of messaging systems.

Shared Database Pattern

If all applications participating in an Enterprise Solution have access to a common database, the applications can exchange data by reading/writing to the common database. This is a less robust solution than the Messaging Pattern because a change in the common database schema may require modifications to participating applications.

Service Oriented Architecture (SOA) Pattern

The applications participating in an Enterprise Solution expose their functionality as a Public API that other applications can consume. This approach is more robust than sharing a database but still causes some coupling between applications due to dependence on the Public API. There is also an implicit assumption that all collaborating applications are online all the time. The most common incarnation of SOA are SOAP and RESTful Web Services.

Shared File Pattern

In this pattern, the publishing application writes a file with appropriate data and/or instructions to a shared network resource. The interested applications read this file and act on it as appropriate. On the surface, this approach seems to be a highly decoupled and robust. However, for a complex application this method of collaboration can be cumbersome and requires agreement on content location, file access policies, shared file disposal, frequency of file drops and retrievals, and meaning of the file content and format.

Messaging + SOA Pattern

For a complex Enterprise Solution with many participating Applications, Messaging provides the most robust solution. Messaging Pattern is even more effective when it is used as a way to communicate Commands among participating applications rather than detailed application data. Following the preceding paradigm, the Messaging Pattern can be combined with the SOA Pattern. For example, let's say an Enterprise Solution consists of an Accounting Application and a Shipping Application. When a payment is received from the customer for an order, the Accounting Application publishes a message stating that an order is OK to ship. The message contains the May Ship Order command with an additional parameter Order Id (Messaging Pattern). When the Shipping Application receives the message, it calls the Public API of the Accounting Application (SOA Pattern) to get the details of the order to ship and proceeds with shipping.

Strategy Pattern

2011-01-18T15:41:00.000-08:00

What

Encapsulate a family of algorithms or behaviors into a set of interchangeable classes. The algorithm/behavior classes are made interchangeable via concrete implementations against a common algorithm/behavior interface.

Why

The algorithm/strategy classes can be modified independent of the classes that use them as long as they adhere to the original interface they implemented.
Code duplication is minimized because the same algorithm or behavior does not need to be implemented in each individual class that needs to have that algorithm/behavior.
The algorithm/behavior of the classes can be dynamically set at runtime via constructor injection or a setter property.

How

Say we need to apply a promotional discount to the total invoice amount. The promotional discount can vary based on the marketing campaign in effect.
interface IPromoDiscount
{
decimal ApplyDiscount(decimal amount);
}
// The logic to apply discount is encapsulated here
class PromoDiscount : IPromoDiscount
{
decimal m_DiscountRate;

private PromoDiscount() {}

public PromoDiscount(decimal discountRate)
{
    this.m_DiscountRate = discountRate;
}

public decimal ApplyDiscount(decimal amount)
{
    return (amount * (1 - m_DiscountRate));
}
}

class Invoice
{
// invoice does not know about the real implementation
// of IPromoDiscount
IPromoDiscount m_PromoDiscount;

private Invoice() {}

// Injecting the 'algorithm' to calculate discount
public Invoice(IPromoDiscount promoDiscount)
{
    this.m_PromoDiscount = promoDiscount;
}
private decimal CalculateSumOfAllInvoiceLines()
{
    ...
}

public decimal InvoiceTotal
{
    get
    {
       return m_PromoDiscount.ApplyDiscount(CalculateSumOfAllInvoiceLines());
    }
}
}
// Specify the discount to apply for an Invoice
// The same Invoice class can be used without modification
// for all three discount scenarios
Invoice invoiceNoDiscount = new Invoice(new PromoDiscount(0M));
Invoice invoiceWithTenPercentDiscount = new Invoice(new PromoDiscount(0.10M));
Invoice invoiceWithTwentyPercentDiscount = new Invoice(new PromoDiscount(0.20M));

OO Concepts - Abstraction, Inheritance, Polymorphism, Encapsulation (AIPE)

2011-01-18T15:38:00.000-08:00

Abstraction

Abstraction is describing the essential and omitting the irrelevant. Abstraction principle is used when modeling the problem domain using class objects and the interaction between these class objects. Abstraction implores us to describe our design in terms of the problem domain instead of getting bogged down in implementation details.

Inheritance

Inheritance is a mechanism whereby the functionality of existing (base) classes is reused by new (derived) classes. Inheritance allows us to share the data and behavior of one abstraction into another. The derived class reuses the behavior of the base class and overrides such behavior when necessary to create a specialized version of the base class.

Polymorphism

Polymorphism literally means having multiple forms. Using inheritance, a class can be used as more than one type; it can be used as its own type, any base types, or any interface type if it implements interfaces. Polymorphism allows a programmer to treat a derived class just like its parent class even though the derived class may have redefined the behavior of its base class.

Encapsulation

Encapsulation is the process by which details that do not contribute to its abstraction are hidden. Encapsulation means hiding of information that is not relevant to the outside world. Encapsulation when applied to design of a class is a technique to hide low-level details of the class from the users of the class. Only what is meaningful to the user of the class is exposed through public members. The rest is kept private and can be changed independently of the users of the class.

OO Principles

2011-01-18T15:34:00.000-08:00

Encapsulate that varies
Place functionality that may change into a separate class that can be utilized by other classes.

Favor composition over inheritance
Composition facilitates better reuse of code, results in less code duplication, and has fewer side-effects than inheritance. Instead of defining a common behavior in the base class, encapsulate that behavior in a separate class that can be utilized by classes in the inheritance hierarchy through composition.

Program to interfaces, not implementations
Encapsulate functionality into a class that implements an interface. The user of the functionality is coded against the interface of the class, not its concrete implementation.

Loose Coupling
When two or more classes or family of classes need to collaborate, share as little implementation details of classes with each other as possible. There are several techniques to achieve loose coupling. For example, program to interfaces instead of concrete class implementations. This allows us to swap class implementations without having to change the code that is written against an interface. When applicable, Observer Pattern is another way to achieve loose coupling where the Subject knows very little about its Observers and begins and ends its relationship with its Observers at runtime.

Open-Closed Principle
This principle advocates a design that is extensible without having to make modifications to existing code. Decorator Pattern illustrates the application of this principle very well.

Application Archetypes

2011-01-18T15:30:00.000-08:00

Online transaction processing systems - OLTP

Low latency
High responsiveness
Data integrity
Predefined UI worflows
Examples: crm systems, e-commerce sites, e-banking systems

Analysis systems - online analytical processing - OLAP

Produce complex analytical customizable queries
Large multidimensional datasets
Low latency response
Examples: Business intelligence systems

Batch systems

Perform operations on large datasets efficiently
Job execution coordination to maximize CPU utilization
Auto recover from exceptions
Examples: Billing systems, provisioning systems

Role of Software Architect in an Agile Environment

2011-01-14T15:38:00.001-08:00

Is the role of Software Architect still relevant in an Agile development shop? Given that Agile methodologies shun big up front design and take design-as-you-go approach, should there be a person or persons designated to look after the system architecture? The answer is unequivocally yes for any system of any significant size. For any significant system, there are key technology decisions that need to be made up front before development can even begin. For example, whether the system is going to be a desktop application or a web application? Will it be hosted on Windows or UNIX? Which programming language and class libraries to use? Key technology and architectural approaches must be vetted out carefully before coding can begin. Once coding begins, some architectural oversight has to be in place to ensure the system follows the planned architectural pattern. There is still plenty to do during the development Sprints. However, in an Agile environment, a Software Architect must adapt his or her approach towards creating, implementing and overseeing system architecture:

Live in the moment! Defer decisions to the last responsible moment. Let the architecture emerge. Only decide what needs to be decided right now. Set the direction and let the developers fill in the rest. To maintain oversight, pair program with developers especially in key areas where security, performance and scalability aspects of the application are at stake. In addition, review unit and functional tests.
Consider yourself part of the development team. To garner any respect or following from the development team, an Architect must be an excellent technologist. Absolutely write some production code. This is in addition to developing proof of concepts, prototypes, design patterns, and perhaps some base classes to kick start the development. At the outset of a new system (or subsystem) development, an Architect must validate the approach by creating a skeletal version of the application that hits all key technologies that will be utilized and simulate all application tiers that would be deployed in the production system.
Communicate in the language of the developers (e.g. class diagrams, code examples, whiteboard, not PowerPoint slides). High level artifacts do not resonate well with developers who are focused on what needs to be done right now to complete stories in the current Sprint. Maintain a development WIKI where engineers can document significant design decisions. For one, this makes engineers think harder about the design decision they are making and perhaps just as importantly provides some continuity as different Agile teams work on the same feature over time.
On top of all of the above, an Architect must have the temperament and patience to listen and balance the needs of all stakeholders. An Architect must be able to effectively communicate the system design, at different levels of detail, to internal (e.g. sales, marketing, documentation, executive team) and external stakeholders (e.g. users, customer leadership team, customer IT department) and explain how the system design meets everyone's business goals.

Source Code Branching for Release Management

2011-01-14T15:35:00.001-08:00

1. When features targeted for a particular release are code complete, a RELEASE branch is created. All fixes and changes including service packs for the release are made in this branch. The system is built and released from this branch.

2. Changes for future versions of the system can continue to be made in the MAIN line while fixes are being made in a RELEASE branch to service live customers. Any fixes made in the RELEASE branch that are applicable to the code in the MAIN line can be merged from the RELEASE branch to the MAIN line.

Writing effective stories for a Scrum Sprint

2011-01-14T15:33:00.001-08:00

A Story is a brief narration of a software requirement that describes desired functionality in terms of business value it brings to the Customer. A story is best expressed in terms of a Customer Goal. For example, compare the following two different ways of expressing the same requirement:

Form 1: Implement a query system to lookup inactive customers for a region.

Form 2: As a Regional Director, I would like to periodically find out which customers have been inactive for more than 30 days.

It can be argued that Form 2 is a substantially better way to express a requirement than Form 1. For instance, in Form 2 the team is introduced to the target user, a Regional Director. Given this information, the User Interface can be tailored to the particular needs of a person with computer skills of a typical executive. Furthermore, Form 2 states that the Regional Director is really only interested in finding out about customers that have been inactive for more than 30 days. This information allows the team to develop a query system that has just enough functionality to meet the Customer Goal. Any additional functionality can be added to the query system later as Customer requirements dictate.

Given only the information in Form 1, a team can easily embark on development of an all inclusive query system that has features that are never used or valued by the Customer.

Writing Unit Tests using Test Driven Development (TDD)

2011-01-14T15:32:00.001-08:00

Say a developer needs to write a new class called Person. A developer may proceed as follows:

Create class Person and define all its public properties and methods with { throw new NotImplementedException; } as the body.
Create a Unit Test class called PersonTest and write [Tests] to exercise the public behavior and state of Person class.
Run the tests. All tests should fail.
Continue implementation of the Person class until all tests pass.

When the above approach and naming strategy (classnameTest) is followed for Unit Tests, it is easier for developers to quickly locate, exercise and expand Unit Tests for a class when the functionality of that class is enhanced.

Top 5 Tools for .NET Agile Development

2011-01-14T15:31:00.000-08:00

In my opinion, the following are the top 5 tools for Agile Development in the .NET environment.

NUnit - Helps write automated Unit Tests

Automated Unit Tests are at the core of Agile development philosophy. NUnit Framework allows you to write automated Unit Tests for your .NET code.

http://www.nunit.org/index.php

Rhino Mocks - Helps write more robust Unit Tests

Think of Rhino Mocks as a supplement to NUnit. NUnit is very good at verifying the state of an object before and after execution. What RhinoMock adds is verification of object behavior (that is what methods are executed) during the test. The Rhino Mocks web site describes it as "A dynamic mock object framework for the .Net platform. It's purpose is to ease testing by allowing the developer to create mock implementations of custom objects and verify the interactions using unit testing."

http://ayende.com/projects/rhino-mocks.aspx

NCover - Helps gauge if enough tests are written

Simply put NCover monitors and reports the percentage code that is executed during a test run. The Code Coverage Percentage is a useful metric in itself. However, more importantly, NCover is really handy in discovering areas of codes that do not have Unit Tests written for them at all.

http://www.ncover.com/

CruiseControl - Facilitates continuous integration

If you work in a team of more than one, CruiseControl is a must-have. CruiseControl serves the dual-purpose of a build/test machine as well as a continuous integration server. Equally important is the ability of CruiseControl to send build/test failure notifications to the developers. CCTray is a handy tool for developers to proactively monitor the CruiseControl server for build/test failures.

http://cruisecontrol.sourceforge.net/

http://confluence.public.thoughtworks.org/display/CCNET/CCTray

Visual Studio - Helps with refactoring

Visual Studio provides a robust IDE for .NET development. The "Refactor" context menu options are particularly useful when refactoring code. For example, Refactor | Rename can be used to rename a variable or a method. Upon rename, Visual Studio will not only rename the variable or the method declaration but also all the references to the variable or the method. In addition to renaming, there are several other refactoring helpers available in Visual Studio.

http://msdn.microsoft.com/en-us/visualc/aa700831.aspx

Agile Principles

2011-01-14T15:29:00.000-08:00

YAGNI - You aren't going to need it

Don't anticipate features and try to adapt your design or code to the features that are not necessary to complete the stories at hand. The chances are that either the requirements will change over time or the features you anticipate are never really needed. Do the simplest thing that will work.

DRY - Don't repeat yourself

Factor out common code into helper classes, methods and components. This makes the testing effort more concise and helps track down bugs to a single place in code instead of several repeating code sections.

Minimize Code

Minimize the amount of code you have to write to solve a problem. The less code there is, the lesser the chance of buggy code. Code Minimization goes beyond DRY in that you may opt to look at alternate design approaches that minimize the amount of code you have to write to begin with.

Write testable code

Structure and implement your code so that it is easily testable. This mind set will naturally help you write code that is loosely coupled and minimizes interdependencies. The loose coupling is essential for testing a class or a component in isolation as is necessary when writing Unit Tests.

Write automated tests

By all means write automated Unit Tests. Better yet, take the Test Driven Development (TDD) route. That is, devise and write your tests before you start developing. TDD will greatly help in the design of the system in addition to the more obvious benefit of having a more complete set of automated tests. Having good automated unit tests allow us to refactor our code confidently.

Refactor, Refactor, Refactor

Over the time, the code will naturally decay. You will see violations of DRY, Minimize Code and even YAGNI principles. It is imperative to take time to periodically refactor the code to ensure its maintainability over time.

Integrate often - Fail fast

Don't sit on pending changes. Check them in right away to find any incompatible changes. It is better to fail fast and correct the problem earlier in the cycle than to sit on a change and having to figure out why things don't work due to a change you made last week.

Coherent Architectures

2010-11-02T20:38:00.000-07:00

In his paper, Urban and Enterprise Architectures: A Cross-Disciplinary Look at Complexity, Roger Sessions talks about Coherent architectures that are:

Easier to implement
Easier to maintain
Easier to adapt
Are less complex

By gleaning into architecture of buildings, Sessions finds four attributes of architecture that make an architecture coherent. He contends these attributes are equally applicable to Enterprise architecture.

Scale Range - There must be a range of architectural scales ranging from the very small to very large. For example, in buildings bricks make up the walls, walls make up the rooms, and rooms make up the building. Similarly, in an Enterprise architecture, there is a scale range of artifacts: data rows, tables, databases, programs, APIs, services, components, sub-systems, systems
Scale Hierarchy - There is an obvious hierarchy of elements in a building. Buildings contain rooms, rooms contain walls, and walls contain bricks. Similarly, in Enterprise systems, raw data is contained in data rows, data rows are contained in tables, tables in databases, and databases are usually accessed through a well-defined programmatic interface. In a Coherent architecture, this hierarchy is clearly decipherable.
Scale Connections - Couplings are between elements of like scale. For example, bricks couple with bricks to form a wall. Walls couple with other walls to form a room. In an enterprise system, for example, Web Services collaborate with other Web Services, but not with the underlying database of another system.
Scale Tightness - The higher up you go in the hierarchy, the weaker the connection strength and there are fewer connection points. For example, two autonomous systems are likely to communicate through an asynchronous message rather than a synchronous method invocation. Furthermore, connection points will be fewer between the two autonomous systems than between a data access layer of a subsystem and its database.

Reference: http://www.objectwatch.com/whitepapers/SessionsSalingaros01.pdf

Enterprise Service Bus

2010-10-19T07:42:00.000-07:00

Enterprise Service Bus (ESB) is an architecture style that provides plumbing for heterogeneous systems (legacy, client-server, SOA, message-oriented middleware, MOM) in an enterprise to collaborate in order to carry out the business processes. ESB utilizes the following primary constructs:

Messages/Events - ESB orchestrates routing of the messages to systems to support stateful and stateless business processes. ESB employs adapters to transform messages into a format suitable for the target system on the ESB
Standards-based messaging - Supports complex Message Exchange Patterns (MEPs) such as Web Services, Messaging Middleware, Intelligent routing, Request/Response communication, One-way event notification
Service Registry - Provides a common directory of all services provided by systems in the Enterprise. Service Registry provides another layer of indirection to where these Services are physically present. The participants in ESB access all services through the Service Registry and are agnostic to physical addresses of these services

ESB attempts to reduce strong coupling between systems by providing for abstractions over underlying Services, APIs and Messaging Systems. ESB ensures delivery of messages:

To the Right place (system)
At the right time (messages are delivered in correct sequence and within specified timeframes)
In the right format (ESB uses adapters to convert messages into appropriate formats for seamless consumption by target systems)

ESB goes beyond traditional Hub and Spoke architecture prevalent in Enterprise Application Integration (EAI) by supporting a distributed architecture for message routing and transformation. All systems communicate in the same way with the ESB. ESB transforms and routes the message to the target consumer per the configuration. ESB also provides mechanisms for monitoring messages as they are move through the enterprise.

P versus NP Problem

2010-09-07T15:01:00.000-07:00

Is every algorithmic problem whose solution can be efficiently verified is efficiently computable?

Efficient Computation

Runs in time that is a fixed polynomial of the input size

P - Polynomial Time

Class of problems with efficient solutions are known as P problems

NP - Non-Deterministic Polynomial Time

Class of problems whose solution can be verified efficiently but are difficult solve especially for large inputs (e.g. Traveling Salesman problem). That is, the problem cannot be solved in deterministic polynomial time (or in other words, efficient computation is not possible).

NP-Complete

Given a set of very hardest NP problems, find an efficient algorithm for one member in the set and then you can certainly found an efficient algorithm to solve all of the members of set

P = NP

If this is proven to be true, we can find an efficient algorithm to solve any problem that has an efficiently verifiable solution. An efficient solution to any NP-complete problem would imply P=NP and hence an efficient solution to every NP-complete problem.

P ≠ NP

Most computer scientists believe P ≠ NP. That is, not every solution-verifiable problem has an efficient solution.

MapReduce

2010-08-15T11:53:00.000-07:00

MapReduce is used to process large data sets. It comprises of two steps.

Use a Map function to break-down original (large) data sets into key/value pairs. These are the intermediate key/value pairs.
Use a Reduce function combine the intermediate key/value pairs to arrive at the final answer

MapReduce lends itself very well to parallel processing. Multiple clusters of compute nodes can independently work on different segments of data during both the Map and Reduce steps.

Example

Objective

Produce a word count from a large text corpus

Map Step

Iterate through all documents in the corpus. For each document:

Parse words
Create a key (word) /value (count, 1) pairs for each word found

Reduce Step

Sum together counts for all intermediate keys (words) to arrive at count for each word in the corpus

Hadoop MapReduce is a programming model and software framework for writing applications that rapidly process vast amounts of data in parallel on large clusters of compute nodes.
See: http://hadoop.apache.org/mapreduce/

Observer Pattern

2010-07-11T21:06:00.000-07:00

What

Let's say we have an object O whose state may change at anytime. There are other objects in our system that are interested in knowing when the state of object O changes. What we need is a way for object O to notify all the interested objects when its state changes. The Observer Pattern facilitates exactly that. It defines a one-to-many relationship between objects such that when one object changes its state, all dependent objects are notified. There are two kinds of the participants in the Observer Pattern:

The Subject also known as the Observable or the Publisher
The Observers also known as the Subscribers

The Observers register themselves with the Subject. The Subject notifies the registered Observers when a change in its state occurs. The order of notification to the registered Observers by the Subject is non-deterministic. That is, an Observer does not know whether it received the update notification from the Subject before or after other Observers.

Why

The biggest benefit of the Observer Pattern is the loose coupling between the Subject and the Observers. As long as the Observers implement an update notification interface supported by the Subject, they may register themselves for the update notifications. Conversely, the Observers know the Subject through Subject's well-defined interfaces. An Observer may unregister with the Subject if it is no longer interested in the notifications.

How

interface IObservableSubject
{
void RegisterObserver(IObserver observer);
void UnRegisterObserver(IObserver observer);
void NotifyObservers();
}
interface IObserver
{
void Update(IObservableSubject observableSubject);
}

A concrete ObservableSubject class implements the IObservableSubject interface along with its other core functionality. Internally, ObservableSubject object keeps a list of registered Observers and notifies them by calling their Update() method. Once notified of the update, the Observer objects may call query methods on the ObservableSubject object to retrieve the state they are interested in.

A concrete Observer class implements the IObserver interface along with its other core functionality. The Observer class gets a reference to the concrete ObservableSubject class through its constructor. Typically in its constructor, the Observer object adds itself to the list of observers maintained by the ObservableSubject object by invoking the IObservableSubject::RegisterObserver() method.

The implementation of Observer Pattern through interfaces is preferred over inheritance because an interface allows us to turn existing classes into Observers by simply implementing the IObserver interface. The same argument holds true when turning an existing class into an ObservableSubject by implementing the IObservableSubject interface.

Decorator Pattern

2010-06-04T21:11:00.000-07:00

What

Decorator Pattern is used to extend existing functionality through composition instead of inheritance. Decorator Pattern can be used to intercept and modify the behavior of an existing class object. For example, say client code uses class object XYZ that implements an interface, ISomeInterface. Currently, the client code instantiates class object XYZ and uses it through its ISomeInterface. XYZ is almost perfect for us except a few behaviors we would like to tweak. We do not want to touch the code for XYZ because it has been tested and has been functioning well. Furthermore, we do not want to substantially change the client code that uses XYZ. Following the Decorator Pattern, we implement a new class KLM that implements ISomeInterface. KLM contains an instance of XYZ class object. KLM delegates the desired behavior to the contained XYZ class object but overrides undesired behavior where necessary. The only change that the client code needs to make is to instantiate KLM instead of XYZ and use it through its ISomeInterface as before.

Decorator Pattern can be applied in a variety of modeling scenarios. Let's say we have an application that calculates the price of a car. There is the base price of the car and then there are additional costs for options such as sports suspension, all weather package and so on. The base price and the price of options may vary independent of each other. Further, the list of available options may change over time. Decorator Pattern is one way to model this kind of scenario.

One way to visualize how the Decorator Pattern works is to visualize an onion. An onion has layers. Let's say the cost of each layer in the onion is different. The cost of the onion is equal to the cumulative cost of all layers. This visualization of the onion costing is not all that different from the car pricing scenario described above. We start with the base model for the car and decorate or wrap it with options. To calculate the total price of the car, we ask the outermost layer what is your cost. The outermost layer asks the layer next to it: what is your cost and adds to its own cost. The inner layer in turn asks the layer next to it what is your cost and adds to its own cost and so on.

In the car pricing example, we can think of the base price and options as just car components. We wrap each component around another component until we have the car with the desired options. We ask the outermost car component to calculate its cost which in turn requests the cost from inner components to calculate the total cost of the car.

The salient features of the Decorator Design Pattern are as follows:

Common Super Type

All decorators used in a scenario derive from the same type or implement the same interface so that they can be used interchangeably. For the car pricing example, all car components implement the same interface in the code example below.

Composition

Each concrete implementation of a decorator contains a reference to the class object that it wraps. The object that a decorator wraps has the same super type as the decorator. For the car pricing example, the innermost decorator would not be wrapping or decorating anything because it is the base price for the car.

Delegation

Each decorator knows how to compute itself but delegates the computation of the decorator objects it wraps to the wrapped objects themselves.

Why

The decorator objects are independent of each other except that they share a common super type or interface. We can leave existing class implementations untouched while extending their behavior through composition and delegation. A decorator does not care about how many other decorators there are in its family. At runtime, a client can create a custom scenario or configuration by composing desired decorators. When new decorators are needed, they are simply implemented and used by the client following the same pattern as before. This is a perfect example of extension of functionality without modification to existing code (decorators). In object oriented terms, this is an application of the open-closed principle. The design is open for extension but closed to modification of existing decorator classes. In the car pricing example above, if we used inheritance instead of composition, the open-closed principle would be much harder to follow. By using the Decorator Pattern, we can implement additional options (decorators) for the car without having to touch code for existing options (decorators).

How

// Common interface all decorators in our car example implement
interface ICarComponent
{
decimal Cost();
}

// Implements common functionality for all Car Components
abstract class CarComponent : ICarComponent
{
protected decimal m_ThisComponentCost;

public CarComponent (decimal thisComponentCost)
{
    this.m_ThisComponentCost = thisComponentCost;
}

public decimal Cost()
{
    // m_ThisComponentCost is set by the constructor
    decimal cost = m_ThisComponentCost;

    // Cost of the car component this component decorates
    if (m_CarComponent != null)
        cost += m_CarComponent.Cost();
    return cost;
}
}

// Base Price for the car
class AMWTurboBasePrice : CarComponent
{
public AMWTurboBasePrice ()
    : base (33000m) // base price for the car
{
    this.m_CarComponent = null;
}
}

// Pricing for Sports suspension
class SportsSuspension : CarComponent
{
public SportsSuspension (ICarComponent carComponent)
     : base (4000m) // price for sports suspension
{
    this.m_CarComponent = carComponent;
}
}
// What is the price of AMWTurbo with sports suspension
ICarComponent basePrice = new AMWTurboBasePrice();
ICarComponent basePriceWithSportsSuspension =
new SportsSuspension(basePrice);
Console.WriteLine(
   String.Format("The cost of car is {0}", basePriceWithSportsSuspension.Cost());

// All Weather package just became available for our car
// We implement a new decorator
class AllWeatherPackage : CarComponent
{
public AllWeatherPackage (ICarComponent carComponent)
     : base (2000) // cost of all-weather package
{
    this.m_CarComponent = carComponent;
}
}
// What is the price of the AMWTurbo with
// sports suspension AND all weather package
ICarComponent basePriceWithSportsSuspensionAndAllWeatherPkg =
   new AllWeatherPackage(basePriceWithSportsSuspension);
Console.WriteLine(
   String.Format("The cost of car is {0}",
   basePriceWithSportsSuspensionAndAllWeatherPkg.Cost());