Pirates, Treasure Chests and Architectural Mapping
Pirates, Treasure Chests and Architectural Mapping
Join the DZone community and get the full member experience.Join For Free
The Future of Enterprise Integration: Learn how organizations are re-architecting their integration strategy with data-driven app integration for true digital transformation.
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 it make sense to document the steps, rationale, concerns, and decisions made 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 the 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 through the architectural design and finally to the implementation. Mapping gives software professionals 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
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 ArchitectureBy 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
Published at DZone with permission of Todd Merritt , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.