architecture

I finally got around to trying out SQL Server 2005 (a.k.a. Yukon) and <strong>reading</strong> up a little on how it operates under the covers. I had earlier <strong>discussed</strong> SQL Server Express. This is my first of series of posts where I will be highlighting some of the new things a developer can do in SQL Server 2005 from a .NET perspective, since there are many DBA’s who live and breathe SQL Server I will leave all the database and T-SQL specific stuff to them....

Well, this was long overdue. I had <strong>promised</strong> to upload my article that won a contest by osnews.com. I finally found a little time to upload it here, though the formatting is still a bit screwed especially on the code snippets. You can <strong>read the article</strong> . If you would like a pdf version of the same let me know and I can either put it up here or email it to you....

As Ramesh writes in an old <strong>post</strong> , the Class Designer is not a UML tool but uses the notation. He goes on to say the prime audience for this tool is the Developer then what do the Architects use? Is there a different version? I personally am a bit cheesed off by this. I love UML and have used it extensively and know the value (and pains) it can bring, like with everything else there are pros and cons....

Microsoft has a site <strong>dedicated</strong> towards Architects geared towards VSTS where if you are an Architect (or an aspiring one) then you can learn more on this and also provide feedback back to Microsoft. Of interest on the same lines would be the following blogs too: <strong>Keith Short</strong> <strong>R Ramesh</strong> <strong>Stuart Kent</strong> Here is an excerpt from the site: Building complex service-oriented solutions requires several architectural considerations including services and contract design, communications security, operations manageability and provisioning, and so on....

The System Definition Model (SDM) provides the basis for the underlying metamodel used by <strong>DSD</strong> . The SDM describes distributed systems as four layers: Applications Application hosts Network Topology OS and physical hardware or devices. For each layer, the model describes the connections between systems and their configurations. By adopting a common model for all these layers, the model makes it possible for you to define and express requirements and policies across these layers....

This is part 3 of the testing-series of posts where I cover White-Box testing (inspired by Microsoft’s upcoming Testing Series of good advise from PAG). You can check out the earlier post <strong>here</strong> . White-Box testing (Glass Box/Clear Box/Open Box testing) White box testing assumes that the tester can take a look at the code for the application and create test cases which look for any potential failure scenarios. You need to determine the suitable input data for testing of various APIs and the special code paths that need testeing by analyzing the source code for the application....

This is really part II of my testing series (as I have become to call it) - I had an earlier post on <strong>Unit Testing</strong> . I recently had the opportunity to review some of the new stuff coming out of the <strong>Prescriptive Architecture Group</strong> at Microsoft and here is some of the interesting things proposed by them. When you are doing Functional Testing of your application or code, it can be of two kinds - Black Box and White Box....

As Paul Dilascia discusses in his article in MSDN Magazine (most of which I am gonna mooch-off here), What is good code? Does good code mean that the program works as it is meant to without bugs? Well if that is your only criteria, then I don’t think so, that is something that is expected. One also needs to look at it internally - as they say beauty is beneath the skin (or something like that anyways)....

PAG group just released the new <strong>library</strong> . If you have been playing with the beta of this, you know there is lots of good stuff. A excellent reference to keep near you! Now that this is “public” I will be posting some of the things I find here - watch this space, and till then, read up and enjoy!

There has been a very interesting (imho) multi-part <strong>interview</strong> with the author of <strong>Beyond Software Architecture</strong> where he discussing various aspects like the relationship between Architecture, Culture and Goodness. Also goes on to discuss the social role of an architect, conceptual integrity and the importance of domain knowledge. I particularly like the quote … “ An architecture is like a dirt road. The first time a car drives over it, the road looks about the same....

In a loosely coupled system (e.g. Service Oriented Architecture i.e. SOA), the dependencies can be either a Real Dependency or an Artificial Dependency. Real dependencies are the services that you need to fulfil your need, this is something that cannot be eliminated or reduced. Artificial dependency on the other hand are the features you need to adhere to in order to consume the services you need. Typically these fall in the categories of platform dependencies, API dependencies, language, etc....

I posted an article (click here or on the title) on what the Zachman Framework is all about. I find it so surprising that in today’s world, I came across a whole bunch of people who call themselves as “Architects” who have no idea or clue as to what the Zachman Framework is. I am not trying to be critical towards those people, they are probably very smart and know their stuff, but I figured maybe its a time for a crash course....