Well, I decided again today to start working on my Microsoft Certified Architect credential.  It's been over a year already getting going on this, so I guess better late than never ;-)

This is prompted by some work I'm doing right now helping a client convert from J2EE to .NET, combined with some composite application work that I've been doing for another client.  So, I've been looking to get a framework together that can be used to articulate decisions that I make.

Like a lot of other things, there isn't a lot of documentation on this, so I figure I'll try to work on a template and that I should write about it here. 

But how to start?  Well, I've decided that I'm going to re-read the Application Architecture Guide 2.0 from MS Patterns and Practices.  It's a great reference for just this type of communication, and it sets out a lot of the things you need to think about as a software architect.

To start, I decided to recreate the diagram that is in the introduction that is used to describe the outline of the guide.  It is also a good diagram for showing various architectural components required in a system:


My posts over the next days, months (hopefully not years) will focus on explaining the parts of this diagram, as well as I'm sure extending the diagram as I see needed by applying it to several real world applications.  Anyway, I find that one of the best ways for me to remember things is to write them down (hence blogging), and I hope it is also useful for you.

Over the last few days I've added the capability to specify a different UI element for the nodes of the graph.  This picture shows the use of circles for the nodes.  Yeah, not too fancy, but its important moving forward.  I also added the ability to drag the nodes; that's actually a lot for fun.

One of the things that I did do when working in the drag functionality is to enable the framework to do the dragging.  I wanted this so that the programmer of the node need not worry about intercepting mouse events and handling the repositioning.

This was actually an interesting challenge.  Since the nodes can be of arbitrary shapes (rectangles, ellipses, polypolygons, ...), the framework can not know what the shape is and hence how to determine if the mouse is down in the visual element.

But wait...

What I did and something that Silverlight / WPF supports quite nicely, is that when the framework calls back into the client code to request creation of a node, the node can support a particular interface, and the framework will check for that interface on the node.  If it not supported, you do not get automatic drag.  If it is supported, it supports a single method that the framework will call that returns a UIElement to the framework that the framework will bind the mouse events to call into the framework.

This is interested for a few reasons.  First, take the sample shown above.  The XAML for the node is the following:

This is fairly straightforward XAML.  There are three elipses, the first two which form the teal background and white edge, and the third, which is named dragElement, that is for all intense purposes transparent and overlies the other two ellipses.

When the framework requests the UIElement to bind the mouse events to, this codebehind on this xaml returns the ellipse named drag element.  That element is then used to do dragging of the whole control.

There is a few subtle reasons why things are needed to be done this way.  For example, if you trapped the mouse events on the top level UserControl, mouse events outside of the ellipse but within the rectangle will also cause dragging.  Not good.

If you make it the white edge ellipse, then mouse events are only handled when the mouse is ac actually over the stroke, not inside the ellipse.  I found that interesting.

If you make it the Teal ellipse, then the border ellipse, being on top, prevents mouse events from going through when over the border of that ellipse.

Note: I realize I could use just one ellipse with a teal fill, and a white border.  However, if you notice, the opacity on the elements are different.  I wanted the teal to be slightly transparent, but I want the border to be totally opaque.

So, what I did is create the third ellipse, make it transparent, and to cover the exact size of the other ellipses.  This provides the drag capability I want, all with just supporting an interface and coding one method.

Note: I may change this model in the future.  This works well, but there may be better ways.  One way would be to create a property that can have an attribute that the framework looks for.  That might be better as it won't clutter the class definition with interfaces.  I don't know, I'm kind of 50/50 on that for now.n  If you've got an alternative way, let me know.

This model also will play nicely with irregular shapes as the UIElement returned could be a polygon, and all things should work the same.

Note: There are a few interesting things about the way this is programmed that I want to document in the future.  A lot of times in OOP to create a new control that would use different visual element, you might subclass the control and override virtual methods.  In this model, the framework uses events to request data from anyone that may be a client of the control.  I find this a lot cleaner as you get a better separation of concerns.  I'll elaborate on this more in another post. It's late now and I have a busy day tomorrow.

I'm also going to try and post a live version of this control during the week.

I was (am) listening to the Alt.Net podcasts today.  I just came across this podcast series last night.  I don't know why I didn't hear of this before, but perhaps it's because it's relatively new as it's only been publishing for a few months and is up to 8 episodes.

At the same time, I'm on a three hour train ride from Baltimore up to Connecticut to talk to a potential new client (to be specific, an interview).  The combination of brushing up on some things I don't do on a daily basis in case I'm asked about them, as well as some concepts discussed in this broadcast has brought me around to something that's on my mind relatively often but that I've never written down...

What are the key concepts in software engineering, as of today, in July 2008?  This is not meant to be an complete list, or that the items exhibit complete separation of concerns relative to each other.

Here my initial stab at what I think are the things you must exhibit to be an exceptional architect at this time:

• Domain Driven Design (DDD)
• Test Driven Design (TDD)
  
• Software Evolution / Continuous Improvement
• Patterns, Patterns, Patterns
• Dependency Injection and Inversion of Control
• Policy based programming
• Aspect Oriented Programming
  
• Doing things as much in a declarative nature as possible
  
• Domain Specific Languages
  
• Separation of concerns
• Design by contract / Interfaces
• Service Orientation
  
• Transparent translation of domain to persistent store
• Mocking
• Parallelism
• Caching
• Factories
• POCO 
• Event Driven Design
• Orchestration
• Rules
• Logging / Instrumentation
• RDBMS design
  
• Keep it simple stupid
  

I'm going to come back and expand this list as well as elaborate on each.

After several months of issues getting registered for it through Sylvan Prometric, I'm finally in and up and going on for the Microsoft Certified Architect certification, focusing on Solutions Architecture.  I'm not exactly sure where this will go, but I'll write about it during my journey.