CodeFlow

Roles and Responsibilities of a Software Architect

noreply@blogger.com (dilan) — Sat, 05 Mar 2011 20:26:00 +0000

The following is a list (which is not intended to be comprehensive, by any means) of the roles and responsibilities of a Software Architect.

Roles of a Software Architect

Customer Facing - Evangelist, Negotiator
Team Facing - [Designer, Programmer], Process Guide
Management Facing - Evangelist, Negotiator

Responsibilities of a Software Architect

Estimation
Analyze skill requirements
Ensure requirements make sense (esp. NFRs)
Prepare domain model
Design solution architecture (candidate + selected)

Balance trade offs
Capture rationale

Select technology
Provide technical guidance (research, samples, references, training to team)
Define development environment

Automated Builds
Continuous Integration
Unit Testing
Software Configuration Management (SCM)
Metrics

Pioneer new technologies; training team where gaps exist
Troubleshooting/Performance optimization (especially in maintenance)
Maintain engineering discipline/rigor
Monitor and control via reviews
Risk/Issue assessment
Input to defect triage process
Assess team member performance, provide feedback
Recruitment (conducting interviews, identifying organizational skill gaps)
Pre-sales (especially in a consultancy environment)

If this describes what you do, you just might be a Software Architect...

StyleCop

noreply@blogger.com (dilan) — Thu, 13 May 2010 20:02:00 +0000

Having worked in both types of software companies (#1 - those that care about the quality of the code it produces, #2 - those that do not... and preferring the former by some way!), I was pleased to come across StyleCop - a tool that complements FxCop (which analyzes adherence to the Microsoft Design Guidelines for Developing Class Libraries in .NET assemblies) by checking source code for adherence to the coding standard.

Assuming company type #1, as the size of development teams increases with the scale of the project (and hence, the product under development), the importance of having source code developed in a consistent style increases. StyleCop is an invaluable tool in this regard; it checks source code from spacing between code elements to the correctness of documentation (albeit at a fairly rudimentary level). Even better, it allows integration with Visual Studio projects via MSBuild targets, which will force a build failure in the face of source code that falls short of the coding standard.

This does raise some issues for those that differ with Microsoft in the standards they apply; for these StyleCop provides 2 possible options:

Customize the StyleCop settings (optionally, writing custom analysis rules)
Change your coding standard

I took option #1, by disabling the settings that went against the coding standard - e.g. requiring that fields be defined at the end, methods be organized in order of visibility (as opposed to functionality/having overloads grouped together). StyleCop saves these settings in a Settings.StyleCop file; when analyzing source code, the merged StyleCop settings will be applied to all files in and below the closest folder containing the Settings.StyleCop file.

The merge mentioned above is implemented as follows: StyleCop applies settings from the global default included in the installation through the folder hierarchy, with the lowest level settings file having the highest priority. Hence, it is possible to define settings and override them at the required level of granularity. For example, I have a Settings.StyleCop file at the same level as the .sln file; however, I have another Settings.StyleCop file wherever an override is required (such as in IDE generated code), at a lower level in the source code structure. This also allows applying StyleCop within legacy codebases in areas where new features are being developed, for example.

Thus far, StyleCop is working just fine; a further minor adjustment to development protocol to require zero FxCop and StyleCop warnings when committing source code to version control will hopefully take the development team to the next level of code quality.

FxCop and Custom Dictionaries

noreply@blogger.com (dilan) — Thu, 13 May 2010 19:23:00 +0000

I've moved back to using FxCop 1.36 (instead of the Visual Studio Code Analysis feature), for the following reasons:

Managing exclusions/suppressions is easier than in code (especially in identifying the exclusions added without justification!)
Identification of issues that no longer exist in the codebase (near impossible in large codebases, with the SuppressMessage attribute)
Suppressions will not get built into the assembly as metadata

The main problem that I encountered in this move was with the use of custom dictionaries; while FxCopCmd.exe supports a /dictionary command-line switch, the FxCop GUI tool does not have a feature to add a custom dictionary.

There are some special paths which can be used to store the custom dictionary, such as the FxCop installation and User Profile paths - these have a major drawback in team development scenarios: they are not conducive for maintaining the dictionary in a common location in source control (in my case, in a path relative to the FxCop project file). Storing the custom dictionary in the same folder as the FxCop project file is supposed to work, but I could not get this to work as mentioned here, here and here.

The solution I came up with (quite by accident, while performing a diff on the FxCop project file after using FxCopCmd.exe with the /dictionary and /update switches!) was to add the relative path of the custom dictionary into a child element of the 'CustomDictionaries' element in the FxCop project file. I used the $(ProjectDir) variable within the FxCop project file to ensure the path of the custom dictionary would remain dynamic. As far as I can tell, this XML structure and the use thereof has not been documented by Microsoft.

A secondary benefit in using this approach is the facility to use the same custom dictionaries which were previously referenced from Visual Studio projects as Code Analysis Dictionaries, from source control.

A third tab in the FxCop GUI (in addition to the Targets and Rules tabs) to contain the dictionaries would be useful, to make using custom dictionaries easier. In essence, all it would have to do is handle adding/removing of CustomDictionary elements (i.e. a programmatic equivalent of my manual solution above).

Another great feature (on a slightly unrelated note) would be a set of MSBuild targets (in a .target file) that can be used to integrate with Visual Studio, a la the StyleCop VS integration.

EDIT: As per Steven's request, given below is the change I made to the .FxCop XML project file; under the 'ProjectOptions' element, I changed the 'CustomDictionaries' element to read as follows:

<CustomDictionaries SearchFxCopDir="True" SearchUserProfile="True" SearchProjectDir="True">
    <CustomDictionary Path="$(ProjectDir)/CodeAnalysisDictionary.xml" />
</CustomDictionaries>

Seems the word 'CodeDictionaries' had got stripped from the original post (as I'd used angle brackets); I've corrected the original article text.

Hope this explains my hack/fix sufficiently; I'd have liked to submit a .FxCop file, but it seems Blogger.com doesn't allow attachments.... :-(

Presentation on Software Design Principles

noreply@blogger.com (dilan) — Thu, 21 Jan 2010 17:47:00 +0000

This is a presentation on Software Design Principles, mainly based on the work of Bob Martin.

The slide deck is dedicated to Bob Martin and the other software engineering pioneers who set the foundation for the software we develop today. Thank you!

An educated guess (Timur Fanshteyn): Subversion pre-commit hooks

noreply@blogger.com (dilan) — Fri, 17 Oct 2008 06:54:00 +0000

Am in the middle of migrating a load of VSS databases to SVN repositories... and came across the following article which shows how to prevent developers from committing without adding comments.

Sweet! :-)

An educated guess (Timur Fanshteyn): Subversion pre-commit hooks

Ctrl-Shift-B: Interactive Application Architecture Patterns

noreply@blogger.com (dilan) — Tue, 05 Aug 2008 17:08:00 +0000

I've been looking into the viability of using the Model-View-Presenter pattern just recently and came across another in-depth article by Derek Greer.

This is easily one of the best articles I've read - get yours at Ctrl-Shift-B: Interactive Application Architecture Patterns.

It's a pity the guy doesn't seem to get to post more often - (being a software developer, it isn't surprising...)

I will be posting my findings on the Model-View-Presenter pattern soon, but I suggest you don't hold your breath.... (after all, I'm a software developer too!)

Ctrl-Shift-B: The Art of Separation of Concerns

noreply@blogger.com (dilan) — Mon, 04 Aug 2008 21:25:00 +0000

Derek Greer has written a detailed post on Separation of Concerns (SoC), at Ctrl-Shift-B: The Art of Separation of Concerns.

He also explains how we can achieve good SoC by decomposing a design into verticals (modules) and horizontals (layers), also looking at how aspects (AOP) allow us to take this to yet another level.

The post also discusses Inversion of Control (IoC) and Dependency Injection (DI)... and how they contribute to good separation as well.

All-in-all, a good read.

Remember:

(High SoC) == (High cohesion, Low coupling) == A Good Thing!

Concurrency & Nine 9's with Erlang

noreply@blogger.com (dilan) — Fri, 09 May 2008 08:27:00 +0000

Came across a post by an old friend on Concurrency & Nine 9's with Erlang - an interesting read.

Article on LoadRunner vs VSTS

noreply@blogger.com (dilan) — Thu, 16 Aug 2007 17:32:00 +0000

Just came across this article on LoadRunner against Visual Studio Team System, by Scott Moore.

NOTE: the article in question is not totally impartial (who is???), as Scott Moore is a consultant for a company partnering with HP/Mercury. The same goes for this blog, in a direction tending towards Microsoft.

There are some valid points made re. the versatility of LoadRunner - Microsoft is not going to get their hands on the innards of SAP and Oracle in the near(?) future, so it's unlikely that they will be able to compete on that front. That being the case, Scott Moore is (IMO) spot on with his call that VSTS is not going to be a LoadRunner killer. ERP solutions will always need load testing and LoadRunner will probably handle that admirably... but having tried both VSTS and LoadRunner, the ease with which a test can be recorded and parameterized without delving into script is pretty impressive. However, the lack of support for Opera/Firefox browsers on VSTS is a fairly large shortcoming, as-is the current shortcomings in data generation and binding.

Having read the article, I think I'll stand by my previous conclusion of horses for courses: ASP.NET or another web app, which can be tested off pure HTTP - use VSTS. Heavy duty requirements? Go with LoadRunner. Either option has a price tag beyond my personal reach, anyway...!

Unit Testing in Visual Studio 2008 ('Orcas') - Professional Edition

noreply@blogger.com (dilan) — Thu, 16 Aug 2007 17:32:00 +0000

The good word is that unit testing will be available in the professional editon of Visual Studio. This is a near mandatory feature in an IDE today, which most Java IDEs provide out-of-the-box; TDD in .NET would have been further along the road today if VS2005 Pro had included the unit testing feature.

Let's just hope that they don't provide unit testing while leaving out the code coverage feature! :P

Load testing with VSTS and LoadRunner

noreply@blogger.com (dilan) — Thu, 16 Aug 2007 17:32:00 +0000

I've not been able to post for a while - been knee deep in work and life, while standing on my head...

Anyway, I've been working with the QA team at my workplace on load testing some of our applications headed for Production over the last few days, getting a taste of both LoadRunner and VSTS.

LoadRunner is *the* heavy duty tool supporting loads of protocols, including SAP and Siebel (amongst others), in addition to the basic requirement of HTTP. We were testing an ASP.NET application which came a cropper when ViewState values would not get replayed, but until then recording a test, replaying it and configuring a load was fairly simple. Debugging is not A-grade AFAIK - but breakpoints and analysis of variables is provided. We tested this off a 10 day trial license, which restricts load to 10 virtual users; the real thing is *said* to be expensive (claims unverified).

On to Visual Studio Team System (VSTS) - Microsoft have done a good job making setting up a test easy, but the bias towards testing Microsoft stuff is definitely visible (e.g. in browser support). Setting up a test was easy, as was parameterizing it. LoadRunner has lots of features to generate data, but VSTS 2005 required some effort to bind to a data source. Thankfully, VSTS 2008 ('Orcas') will have data binding to CSV/XML files in-built; VSTS does provide for extensibility via Request/Test Plugins, which can be used to provide data. I did hit an issue where if an asp:Button has its UseSubmitBehavior switched off, the script records the Cancel button's existence on the page as well, leading to the subsequent HTTP request not being handled correctly by the server. Tests were conducted on a 180-day trial license, without any feature restrictions.

The comparison plays out like this - for basic web apps (definitely ASP.NET apps), VSTS should suffice. While not being cheap, VSTS does not cost as much as LoadRunner. However, LoadRunner is a far more mature product and versatile with it - having support for ERPs and protocols like CITRIX and RDP. The VSTS feature of rigging Unit Tests and Web Tests into Load Tests was pretty impressive and the .NET language + debugging features of the VS IDE outstripped LoadRunner by some distance.

Final word: select what you need for your specific requirement; but for the majority of small-medium business applications, VSTS should meet your need.

Anemic vs. Rich Domain Models

noreply@blogger.com (dilan) — Tue, 01 May 2007 11:23:00 +0000

There's debate at almost religious intensity on some forums as to the type of domain model to be used in developing applications.

The rich Domain Model (proposed by Martin Fowler) suggests having e.g. Employee objects, with all operations on an Employee provided by the class itself - such as Employee.Save(). Fowler argues that this makes for better object orientation, as there is greater encapsulation and the opportunity for polymorphic use of objects.

The alternative is the Anemic Domain Model (the term coined by Fowler himself makes clear how much he dislikes the model by using a term with negative implications) and probably inspired by the design of stateless session beans from EJB. This design has (to follow the above example) Employee objects containing their own data, but EmployeeManager or EmployeeService classes containing the operations - such as EmployeeManager.Save(Employee).

Wikipedia labels the latter as an anti-pattern; however, given that there are so many proponents of the Anemic Domain Model (ADM), labeling it an anti-pattern seems to be an extremist, dogmatic point of view. The pro-ADM argument is that breaking the functionality out into separate classes further enhances separation of concerns, which is a good design practice.

Personally, I've found the ADM to be a simple one to develop, lending itself well to generation of code via templates etc. Furthermore, with the whole SOA/Web Service buzz, services as per ADM make a lot of sense; even use of the GOF Facade design pattern would probably lead to the same solution. Say in a Web Service application, the designer would be forced to make the Domain Model dependent on the relevant Web Service - in my book, placing Web Service calls behind Employee.Save() would be mixing up far too many concerns (i.e. business logic + web service invocation code).

Fowler's rich Domain Model is an ideal solution - and I've used it successfully on several in-process solutions - and if it can be achieved outside of the pro-ADM arguments just outlined - I'm all for it. Maybe having the UI talk to a rich Domain Model (your formal API), which in turn talks to the back end comprising an ADM would be the answer... however, this would mean code that would be repetitive and leave that much more room for defects to creep in.

It all comes down to a question of how pragmatic a software designer is willing to be. The only certainty is that this argument will not be going away anytime soon.

A few blogs which have opinions on this topic:

Finding references on this matter is not hard at all...
Google for rich Domain Model
Google for Anemic Domain Model

Unit Testing Internal Types (2)

noreply@blogger.com (dilan) — Sun, 11 Feb 2007 18:14:00 +0000

It works!

In a previous article, I discussed unit testing internal classes which are typically instantiated using Reflection and are accessed via a Facade.

Learnings: When TestDriven.NET runs NUnit tests through the IDE, configuration values seem to be pulled from testassembly.dll.config.temp, while the specified configuration file is used if run through the NUnit GUI.

These files would have to be replaced with our custom content, to test the internal component, through the Facade.

Anyway, I scrapped together a helper class that would handle copying of the configuration content (overloads for config content as a string and alternatively, a source config file). The [TestFixtureTearDown] method is used to restore the original configuration, while individual [Test]s can use the helper to copy the relevant config file for running.

I'm glad that it worked, but given that it's a hacked together solution, could stop working with any forthcoming release of NUnit (e.g. if config files are locked for the duration of execution etc.).

Steven Cohn (in his blog) made good sense about not modifying the 'System Under Test', in order to test it. The only thing I've got to say about 'pragmatic unit testing' is, given all the restrictions in testing internal types, the most pragmatic thing would be to stop unit testing... :P

You'd think I'd be happy at having solved the problem (hack or otherwise), but strangely, jumping through hoops does sweet nothing for the temper! ;-)

Unit Testing Internal Types

noreply@blogger.com (dilan) — Sat, 10 Feb 2007 12:25:00 +0000

Problem: .NET classes of 'internal' visibility to be unit tested (in this case, using NUnit).

Complication: These classes are part of a 'provider' model (pluggable components instantiated via a Factory Method implementation, based on configuration settings). Access to the functionality to be tested would be via a Facade class, which looks up configuration and instantiates the relevant type using Reflection.

Known Solutions:

Use of Friend assemblies - however, to maintain security (ensuring only our Unit Test assembly invokes the internal types) we would need to strong name our assembly under test. This has a cascading effect, as all its references then need to be strong named. Not an option, when you consider that we might have a reference on an external vendor's component somewhere down the dependency chain.
Writing the Unit Tests in the same assembly - which clutters up the codebase goodstyle.
Write Reflection based wrappers (a la VSTS) - which the Professional edition of VS2005 does not have.

Yet another solution?

I'm sure there is a downside to the following approach, which I'm going to find out about the hard way - but till then:

The complication states that the required values need to be pulled from configuration. What price placing the default configuration file in the execution path during the method marked with [TestFixtureSetUp], to be overwritten at the beginning of the individual [Test] method by a separate configuration file containing the relevant settings, methinks... all this is very much guesswork, depending on NUnit allowing the configuration file to be overwritten.

I'm thinking a feature in NUnit like the VSTS [DeploymentItem] attribute would have been very helpful in this scenario...

Will blog about whether this works... if it works!

And about time too!

noreply@blogger.com (dilan) — Thu, 08 Feb 2007 14:58:00 +0000

Continuous Deprioritization: the reason why I never got around to running a blog thus far. After deliberating and procrastinating for a couple of years, I finally got around to starting up this blog.

And just like *that*, the words run dry!