Archive

Archive for the ‘Development Guidance’ Category

3 Ideas to Make Architecture Executable in Visual Studio 2010

May 19, 2010 Leave a comment

One of the main complaints people have about architects is that we set a bunch of standards and produce a bunch of paper but little else even when they appreciate the visionary aspect we bring to the table.  While concepts, standards, and white papers  can provide valuable guidance, ultimately the value proposition is only as good as organizational adoption.

One of the question I always ask myself is how can I make this concept tangible to my audience. Further, how can I make what I’m promoting normal part of the workflow without  introducing additional ceremony.

I think Visual Studio 2010 introduces new opportunities for organizations using the MS platforms to make technical architecture executable for their technical teams. Here are few ideas you might want to incorporate:

  1. Make coding standards executable: StyleCop and Code Analysis (or  FxCop) are free code analyzers. StyleCop works on non-compiled code while Code Analysis/FxCop work on IL. While these are not new tools for VS2010,they were improved, and  you should consider incorporating them into your build processes. Instead of just writing coding standards  (which usually also include  simple design rules in addition to formatting guidelines)  configure StyleCop and CodeAnalysis to evaluate the rules at build time or compile time. This can be done on developer machines, even if you haven’t implemented a CI process. Modify your coding standards document indicate which rules are executable.  Custom rules can  be implemented to reflect the needs of your organization. (Note: integrating the execution of StyleCop into TFS 2010 will require you to create a custom workflow activity.) Choosing this strategy instead of a document has several benefits: allows standards to be quickly and consistently evaluated so that code reviews can focus on more valuable design related activities, provides metrics regarding standards compliance — maybe your standards are unrealistic and need to be evaluated or developers require more education, and allows standards to be available from within in the normal development workflow instead of spending time switching between coding and reading a document to ascertain compliance (a not very Lean practice).  More information on the tools are available at:
  2. Make high level architectural patterns available in the IDE. Layers (http://www.openloop.com/softwareEngineering/patterns/architecturePattern/arch_Layers.htm)  are probably one the most commonly used architectural pattern. 
    Layer Diagram

    Pretty Boxes

     

    There are few systems that don’t refer to themselves as n-tier or MVC these days. Layering is even used to describe infrastructure in commonly used tools such as the OSI model.  Solutions architects typically articulate their grands visions for how their systems should be implemented using layers and how those layers should interact in a few ways: reference implementations, pretty boxes (my fave – you can’t tell me you’ve never drawn a bunch of nebulous boxes on the white board:)), or UML package/component diagrams. Why not use the same pretty picture for your software architecture document to actually validate the code that is being delivered. I will wait a moment for your wow :).  A new option with Visual Studio 2010 are layer diagrams.Layer digrams allow you to define the layers of your system within Visual Studio, define the relationship and constraints among layers, associate the layers namespaces, and validate that the implemented code conforms with layer diagram. You can easily imagine a scenario where you can quickly perform an audit to determine how many new web  applications developed for  the quarter conform with the MVC architecture. You could also use the diagrams as part of SLA agreements with your solution providers to ensure they are conform with approved enterprise architectural patterns. More information on the use and capabilities of layer diagrams is available at:

  3. Generate code. There have long been numerous model driven architecture tools available for .Net.  Visual Studio 2010 is throwing it’s hat in the arena to arguably make it simpler. VS2010 allows you to create UML diagram and apply stereotypes to the diagrams that represent your intended design. You can then use T4 to generate code from the models. I estimate that 40%-60% of code could be generated in this way for most common applications. (Note: True DSL support for the MS platform is a little spotty but most organizations have reached a point which true DSL use is pervasive.) It should be noted that code generation as a strategy is most effective if you have well-defined standards for development including cross cutting concerns. For example if my ORM standard is nHibernate I can easily generate a domain model that leverages nHibernate for persistence. The benefit of code generation are numerous: time and delivery cost, delivery consistency, increased focused on value add portions of the application that actually drive competitive advantage instead of expending resources on infrastructure code, increased focused on business needs and domain modeling and code as a mechanism to support it instead of the reverse, and rapid spiking/prototyping. Additional information is available regarding UML and code generation at:

I am not suggesting that these things were not achievable before using a combination of open source tools and commercial products for the MS platform. However, Visual Studio 2010 provides a fairly significant set of tools that may not be being completely leveraged it the tool is primarily used for “just coding”. Obviously you don’t have to implement all of these ideas, but some may provide benefits in your organization.

Advertisements

Thinking About Exceptions

April 5, 2010 Leave a comment

Application and operational architects should consider what can wrong in applications whether or not the scenario is officially documented as a non-functional requirement or in a use story. While you must be practical because there are always trade offs between bullet proofing and delivery time frames, lack of requirements should never be an excuse to deliver software with poor operational supportability.

 The table below includes sample exception situations that could occur in an application and suggestions for system responses. The goal of this list is to help you identify potential problems that could occur in your code and so that they can be appropriately addressed.

SCENARIO EXAMPLE BEHAVIOR
A resource call does not return within a reasonable period of time (applicable to synchronous events but should also be considered for long running BPM processes)Examples:
A call to a persistence layer takes longer than it must.
* Session bean call does not return within a reasonable period of time.
Treat as a timeout
* Give user the option of interrupting the call
*The system must keep the state of data consistent (rollback transaction) so that a user retry can be performed.
A resource request times out.
Examples:
* DB query times out
* A Web service request times out.
The system must keep the state of data consistent (rollback transaction) so that a user retry can be performed.
Resource conflict, in which two or more users attempt to access a resource in a manner that causes one or both requests to fail (not time out).
Examples:
* An attempt by a user to perform an update using data is stale, causing the application to detect that the user update is in conflict with an earlier update (i.e., the “optimistic locking” paradigm).
* Attempts by two users to perform operations that are only allowed to be performed by one user at a time, based on application rules.
The exception that is thrown must indicate which data is affected by the conflict.
* The system must keep the state of data consistent (rollback transaction) so that a user retry can be performed.
Data not yet available, due to delays.
Examples:
* A precursor process has not yet completed.
The system must keep the state of data consistent (rollback transaction) so that a user retry can be performed.
Server-based resource runs out of a type of resource that it requires.
Examples:
* Database table space (especially temporary tables).
* memory
Technical support must be notified automatically. Can be handled via logging level.
* To the extent possible, no database data must become corrupt or inconsistent as a result of the failure.
* The exception that is returned to the caller must specify the specific condition (for example, which server resource could not be connected to) and the completion status of any transactions that were in progress on the caller’s behalf, and any inconsistencies that might have resulted.
* Any exception that is logged must include the full context of the error, including the stack trace, the user identity, and a request or task identity for the purpose of correlating log events across different environments.
* A GUI-level client must instruct the user to wait until a message is received indicating that the resource is available again.
* When the system becomes usable again, users must receive a message instructing them with what operations they must re-perform.
An attempt to establish a connection to or otherwise obtain a resource fails.
Examples:
* An attempt to establish a database connection fails.
* A utility such as a task management system, a queuing system, or a file transport system is unavailable.
Same as previous.
A resource connection fails unexpectedly.
Examples:
* A remote machine is being rebooted or was shut down.
Same as previous.
An attempt to locate (resolve) a resource fails Examples:
* A database table is not found because it is not in the user’s schema.
Same as previous.
There is a version mismatch between two ends of a remote connection or session.
Examples:
* An XML message or Web Service invocation fails a schema or DTD validation (at either endpoint).
Same as above.
There is a protocol usage or internal error of some kind that is not immediately identifiable as a version incompatibility.
Examples:
* A semantic error within a Web Service message, such that the message is ill-formed based on usage rules that are not encoded in the schema, or no schema is being used.
Same as previous.
An internal error in a server-based application occurs when making a remote call to the application.
Examples:
* A Web Service throws a RuntimeException or Error.
Same as previous.
An attempt to authenticate to a resource or to obtain authorization to access the resource fails.
Examples:
* An attempt to update a database table fails with an authorization exception.
* An attempt to access a file fails due to lack of the required access permission.
All exception information must be logged in a secure manner, and the exception must then be replaced with a generic exception indicating an authentication or authorization failure, as appropriate.
Input validation error. Any exception that is returned to the caller must indicate the specific input items that were problematic. If the caller is a user interface, the specific problematic items must be visually indicated.
* The intended transaction must not occur.