Michael's Coding Den: Design

ADL: Architecture Description Language

Sat, 12 May 2007 09:38:29 GMT

Recently on the MSDN "Architecture" forum the ADL subject was treated slightly. I used ADL 3 years ago, and would like to summarize what is it.

First of all, ADL means Architecture Description Language. It used to define and describe software architecture (the models and etc) prior to the system implementation. It improves understandability of design between stakeholder vs enterprise engineers and enterprise engineer vs software developers, mitigating:

Mutual communication

Embodiment of early design decisions

Transferable abstraction of a system

Among the described issues, ADL addresses the following specifications:

Behavior
Protocol
Connector

To cover these ADL requirements, several specification were introduced.

Aesop: specify and analyze architecture styles
Rapide: specify large component-based architecture
Wright: specify communication protocols
MetaH: specify physical processed and algorithms
UniCom: specify packaging

There are some other ADL specs, links to them are available on the wiki.

Resources:

Office "Ribbon" is under licensing

Mon, 27 Nov 2006 14:28:43 GMT

MS have licensed the Office UI paradigm to "avoid several inconsistent variants". It means that if you want to create the app which looks like the Office's one you need to follow the MS guideline to keep consistency.

I found it rather reasonable. There are many applications around us, but few of them have handy and usable design/usability. In general, companies have no design/interaction developers who makes product really usable for the end-users. The step that was undertaken by MS, in the area of UI design, is really wise solution to spur companies to meet the design requirements to some extent.

5 tips for the Enterprise Architects

Thu, 21 Sep 2006 13:04:54 GMT

Dan Massey (chief architect at Borland) published "5 Practical Tips for the Enterprise Architects", which comprise:

Communicate using a formal design language
It's very important to have any design language for communication - it doesn't matter whatever you choose, it's important that you use at least one. You can be sure that what you create is clearly understand to others in terms of models and interactions and can be used to communicate. It helps you to increase quality and productivity.
Establish, maintain, and mandate architectural standards
Create baseline in standardizing everything from project directory to code review helps you to reduce risks and get improvement with your processes and projects. Everything should be under control to avoid duplication of work, and find out the weak processes that wastes time and inefficient.
Create a domain model, and focus on becoming a business domain expert
Don't make up your own approach - use existing business domain modeling frameworks. The key anti-pattern is trying to cataloging all services/components that you need to realize - start with the business process the business is asking you to automate. Take the business process models and see if you have services that map to the services they require. Become an expert in the business domain, whether that domain is software development, financial services or retail.
Train teams on the architecture standards and domain model
Everyone team member must be trained to follow defined standards, models and policies. By following the standards and model, they will create an environment where anyone on the team, regardless of location, can review anyone else's code, and knowing they are all part of the same process can improve upon it efficiently. This process helps eliminate friction and allows everyone on the team to focus on solving business problems more quickly.
Always consider your customer
Enterprise architects and product owners should be distributed equally with the development teams in various location, but you need adopt development methodology (Scrum for example) to decrease time to marker to allow enterprise architects works with each team closely.

Defining code changing through versioning

Sun, 21 May 2006 17:17:30 GMT

"Breaking Changes" design guideline shows most common issues that may meet in our code when we refactor and and create new versions.

This document includes a lot of samples of "weak" code that is likely be broken in process of creating new version of application. There are solutions how to fix it and how to write pure, long-lived code.

Assessing Quality of requirements

Thu, 02 Mar 2006 08:57:56 GMT

Being an Architect each of us responsible for writing non-functional requirement, but this leads us to the common misunderstanding when we need to control the meeting these requirements by designers afterwards. The question is "how to measure and assess" this non-requirements stuff. I've met several cases when good writing non-functional specwas realized wrong and vice versa. But what does "good wrining" means in this context.

There are a several articles relates to creating measurable non-requirement specification to be on the one trail with designers: http://blogs.msdn.com/randymiller/archive/2005/11/28/497694.aspx and http://realworldsa.dotnetdevelopersjournal.com/qualityattributefactortable.htm

Extensive describing of MVP pattern

Sat, 25 Feb 2006 13:37:24 GMT

One of these days Joanna Carter gave a note about Model-View-Presenter pattern: ftp://www6.software.ibm.com/software/developer/library/mvp.pdf
It’s rather broad explanation of this pattern.

There http://www.codeproject.com/useritems/ModelViewPresenter.asp is a good example demonstrating the MVP in ASP.net and there http://haacked.com/archive/2006/08/09/ASP.NETSupervisingControllerModelViewPresenterFromSchematicToUnitTestsToCode.aspx is sampe of using Supervising Controller and Rhino Mocks.

What’s most surprise me, that this pattern was developed at Xerox in the late 1970’s. For the last 10 years in IT every new thing I’ve been opening for myself is only revised old one, but in new context (at best). There are a lot of samples. Having take an idea of N-Tiers application in .NET, for example – there are a lot of books related this topic, but they give you nothing more new that was described in 1997 by Mary Kirtland, who was working on the COM+, in her book “Designing Component Based Application”. She explained all bases of n-ties apps. And now each book I’ve ever seen about n-ties in .net only rewrite her ideas, bringing nothing new. What's the worst all IT books are similar to each other, with several exceptions.

As for me, IT books became loosing its values as books, because writing “such-kind” of books is worthless. What do we need is really good books, writing professionally to be read easily, opening topics wide, and not a bulk of tech articles from MSDN on the shelves published as Books.

This brings us that it’s hard to find really useful book, without reading sources from the third hand.

DI vs Factory patterns

Sun, 29 Jan 2006 12:53:51 GMT

Recently, in microsoft.public.dotnet.distributed_apps I was asked about the reason of using DI instead of conventional factory patterns.
The reason is that DI gives you flexibility in loosely coupled systems. GOF described factory patterns without taking into account using them in distributed systems. These systems shift aspect of design and standard approaches don’t work such effectively as they did it before.

Drawbacks of factories:

not reusable across other applications
no runtime support
no flexibility with decoupling base interface

Griffin Caprio in his MSDN article describes how to overcome these shortcomings with DI and containers.

Great article, thanks Griffin.

Patterns quiz

Fri, 09 Sep 2005 16:13:08 GMT

Fine patterns quiz: http://home.earthlink.net/~huston2/dp/patterns_quiz.html

It rocks

Discovering Patterns in .NET Framework

Wed, 10 Aug 2005 18:33:11 GMT

Rob Pierry published an interesting article about design patterns in August MSND Magazine: "Discover the Design Patterns You're Already Using in the .NET Framework"