Things on DotNet, programming, and other useless stuff

Pirates, Treasure Chests and Architectural Mapping

Pirate 1: Why do pirates create treasure maps?
Pirate 2: I do not know.
Pirate 1: So they can find their gold.

Yes, that was a bad joke, but it does illustrate a point. Pirates are known for drawing treasure maps to their most prized possession. These documents detail the decisions pirates made in order to hide and find their chests of gold. The map allows them to trace the steps they took originally to hide their treasure so that they may return. As software engineers, programmers, and architects we need to treat software implementations much like our treasure chest.

Why is software like a treasure chest?

  • It cost money, time,  and resources to develop (Usually)
  • It can make or save money, time, and resources (Hopefully)

If we operate under the assumption that software is like a treasure chest then wouldn’t make sense to document the steps, rationale, concerns, and decisions about how it was designed?

Pirates are notorious for documenting where they hide their treasure.  Shouldn’t we as creators of software do the same? By documenting our design decisions and rationale behind them will help others be able to understand and maintain implemented systems. This can only be done if the design decisions are correctly mapped to its corresponding implementation. This allows for architectural decisions to be traced from the conceptual model, architectural design and finally to the implementation. Mapping gives software professional a method to trace the reason why specific areas of code were developed verses other options.

Just like the pirates we need to able to trace our steps from the start of a project to its implementation,  so that we will understand why specific choices were chosen. The traceability of a software implementation that actually maps back to its originating design decisions is invaluable for ensuring that architectural drifting and erosion does not take place. The drifting and erosion is prevented by allowing others to understand the rational of why an implementation was created in a specific manor or methodology

The process of mapping distinct design concerns/decisions to the location of its implemented is called traceability. In this context traceability is defined as method for connecting distinctive software artifacts. This process allows architectural design models and decisions to be directly connected with its physical implementation.

The process of mapping architectural design concerns to a software implementation can be very complex. However, most design decision can be placed in  a few generalized categories.

Commonly Mapped Design Decisions

  • Design Rationale
  • Components and Connectors
  • Interfaces
  • Behaviors/Properties

Design rational is one of the hardest categories to map directly to an implementation. Typically this rational is mapped or document in code via comments. These comments consist of general design decisions and reasoning because they do not directly refer to a specific part of an application. They typically focus more on the higher level concerns.

Components and connectors can directly be mapped to architectural concerns. Typically concerns subdivide an application in to distinct functional areas. These functional areas then can map directly back to their originating concerns.
Interfaces can be mapped back to design concerns in one of two ways. Interfaces that pertain to specific function definitions can be directly mapped back to its originating concern(s). However, more complicated interfaces require additional analysis to ensure that the proper mappings are created.

Depending on the complexity some Behaviors\Properties can be translated directly into a generic implementation structure that is ready for business logic. In addition, some behaviors can be translated directly in to an actual implementation depending on the complexity and architectural tools used.

Mapping design concerns to an implementation is a lot of work to maintain, but is doable. In order to ensure that concerns are mapped correctly and that an implementation correctly reflects its design concerns then one of two standard approaches are usually used.

All Changes Come From Architecture
By forcing all application changes to come through the architectural model prior to implementation then the existing mappings will be used to locate where in the implementation changes need to occur.

Allow Changes From Implementation Or Architecture

By allowing changes to come from the implementation and/or the architecture then the other area must be kept in sync. This methodology is more complex compared to the previous approach.  One reason to justify the added complexity for an application is due to the fact that this approach tends to detect and prevent architectural drift and erosion. Additionally, this approach is usually maintained via software because of the complexity.
Taylor, R. N., Medvidovic, N., & Dashofy, E. M. (2009). Software architecture: Foundations, theory, and practice Hoboken, NJ: John Wiley & Sons

  • James87

    8/25/2011 9:39:42 AM |


    We create thus a lot of good points here which I read the article the couple of occasions. Your own views are within accordance with my own for the most component.

    This can be outstanding information for your own readers.

    Thanks  ..;)

  • jhas08

    8/30/2011 2:00:42 AM |


    I foud your blog in google search engine based on my keyword search. Just to let you know that your blog is friendly and lovingly like it\\\'s content. I got something really great online.

    Receive an Amazing Bonus worth $10,577.37+ 2,000,000  FRESH OPT-IN EMAIL LISTS. It will be given you away w/o any extra cost. There will be no escape for this moment to get this amazing offer. And a lot more in the inside.

  • Free Xbox Live

    9/12/2011 1:23:31 AM |

    Very good site.  Thank you so much for putting out a lot of effort in writing these kind of posts!

  • Andrew

    9/14/2011 5:52:27 PM |

    I do appreciate the manner in which you have presented this concern and it does indeed provide me a lot of fodder for thought. On the other hand, through what I have seen, I simply trust as the feedback pack on that men and women remain on point and not embark upon a tirade associated with some other news of the day. Anyway, thank you for this superb piece and whilst I can not necessarily go along with the idea in totality, I respect the point of view.

  • Website Designing

    9/17/2011 1:50:09 AM |

    Super-Duper web site! I’m loving it!! Will come back once more – taking you feeds also, Thanks.

  • bitcoin app

    9/22/2011 1:11:59 PM |

    Heyo, great blog post! How did you get so many people to read this? I have my own blog, but it's not quite as popular as yours. It is about Bitcoin, a digital currency that's becoming pretty popular. Anywho, seeya later

  • Andrew Tomson

    10/5/2011 8:56:44 AM |

    I appreciate you for the knowledge. Now i'm basically starting internet promotion and marketing and i'm in search of specifics on seo positioning and how to pull in links. I've published a keyword rich link to the website over my website. You should invest time to have a look Smile

  • reserver riad Marrakech

    10/12/2011 2:32:32 PM |

    I dugg part of you announce as I sentiment they were mere beneficial ready

Pingbacks and trackbacks (1)+

Comments are closed