| <?xml version="1.0" encoding="UTF-8"?> |
| <!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd"> |
| <!-- VERSION rmc:7.1.0 --> |
| <html xmlns="http://www.w3.org/1999/xhtml"> |
| <head> |
| <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/> |
| <!-- START NON-TRANSLATABLE --> |
| <title>\openup_basic\guidances\concepts\arch_mech.xmi</title> |
| </head> |
| <!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. --> |
| <body> |
| Element Name: arch_mech.xmi<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: presentationName<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:presentationName,_mzxI0A4LEduibvKwrGxWxA CRC: 469363530 -->Architectural Mechanism<!-- END:presentationName,_mzxI0A4LEduibvKwrGxWxA --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: briefDescription<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:briefDescription,_mzxI0A4LEduibvKwrGxWxA CRC: 2553675936 -->Architectural Mechanisms are common solutions to common problems that can be used during development to minimize complexity.<!-- END:briefDescription,_mzxI0A4LEduibvKwrGxWxA --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: mainDescription<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:mainDescription,-SJrpVySJ2npYs8NwGvnHjw CRC: 3554619484 --><p> |
| Architectural Mechanisms are used to satisfy architecturally significant requirements. When fully described, |
| Architectural Mechanisms show patterns of structure and behavior in the software. They form the basis |
| of common software that will be consistently applied across the product being developed. They also |
| form the basis for standardizing the way that the software works; therefore, they are an important element of the |
| overall software architecture. The definition of architecture mechanisms also enable decisions on whether existing |
| software components can be leveraged to provide the required behaviour; or whether new software should be bought or |
| built. |
| </p> |
| <p> |
| The key point to take on board when discussing architecture mechanisms is that the defining them is all about making |
| choices about *what* technology will be used to satisfy architecturally significant requirements. It is not about |
| producing detailed design or software. This is a common misunderstanding. The creation of detailed design |
| and software that shows *how* specific mechanisms are satisfied is a development task. |
| </p> |
| <p> |
| The value in defining architecture mechanisms is that it |
| </p> |
| <ol> |
| <li> |
| explicitly calls out aspects of the solution mechanics that are common across the system. This aids planning. |
| </li> |
| <li> |
| puts down markers for the developers to build those aspects of the system once and then re-use them. This reduces |
| the workload. |
| </li> |
| <li> |
| promotes the development of a consistent set of services. This makes the system easier to maintain. |
| </li> |
| </ol> |
| <p> |
| An Architectural Mechanism can have three states: Analysis, Design and Implementation. These |
| categories reflect the state of the architectural mechanism over time. The state changes as successive levels of |
| detail are uncovered during the refinement of architecturally significant requirements into working software. The |
| categories are summarized in the table that follows. |
| </p> |
| <strong>States of an Architectural Mechanism</strong> |
| <table style="WIDTH: 806px; HEIGHT: 228px" cellspacing="0" cellpadding="2" width="806" |
| summary="Types of Architectural Mechanism" border="1"> |
| <tbody valign="top"> |
| <tr> |
| <th scope="col"> |
| State |
| </th> |
| <th scope="col"> |
| Description |
| </th> |
| </tr> |
| <tr> |
| <td> |
| Analysis |
| </td> |
| <td> |
| A conceptual solution to a common technical problem. For example, persistence is an abstract solution |
| to the common requirement to store data. The purpose of this category is simply to identify the need for an |
| Architectural Mechanism to be designed and implemented; and capture basic attributes for that mechanism. |
| </td> |
| </tr> |
| <tr> |
| <td> |
| Design |
| </td> |
| <td> |
| A refinement of an Analysis Mechanism into a concrete technology (for example, RDBMS). The purpose of this |
| category is to enable initial design specifications to be produced and to guide precise product or |
| technology selection. |
| </td> |
| </tr> |
| <tr> |
| <td> |
| Implementation |
| </td> |
| <td> |
| <p> |
| A further refinement of a Design Mechanism into a specific technology or product that implements |
| the required Architectural Mechanism. For example, MySQL, as a database product, implements the |
| Analysis Mechanism <strong>Persistence</strong> and Design Mechanism <strong>RDBMS.</strong> |
| </p> |
| <p> |
| This essentially represents the point at which the decision is made to re-use, buy or build specific |
| software to provide the services defined by the mechanism. |
| </p> |
| </td> |
| </tr> |
| </tbody> |
| </table> |
| <br /> |
| <p> |
| Be aware that these states are frequently referred to themselves as Analysis, Design and Implementation |
| mechanisms. These are synonyms and merely represent the architecture mechanisms in different states of |
| development. The transition from one state to another can often be obvious or intuitive. Therefore, it can be |
| achieved in a matter of seconds. It can also require more considered analysis and design, thus take longer. The |
| following diagram illustrates the transition of Architectural Mechanisms from one state to another. |
| </p> |
| <p> |
| <strong>State Machine for Architectural Mechanisms</strong> |
| </p> |
| <p> |
| <img style="WIDTH: 876px; HEIGHT: 115px" height="113" alt="Architectural Mechanism States" |
| src="./resources/ArchMechanismsStatemachine.JPG" width="600" /> <br /> |
| </p> |
| <br /><!-- END:mainDescription,-SJrpVySJ2npYs8NwGvnHjw --> |
| </body> |
| </html> |
