| <?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&#92;guidances&#92;examples&#92;&#92;architectural_mechanism_attributes.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: architectural_mechanism_attributes.xmi<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: presentationName<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:presentationName,_eQ_s8Om5Edupia_tZIXEqg CRC: 2419467452 -->Architectural Mechanism Attributes<!-- END:presentationName,_eQ_s8Om5Edupia_tZIXEqg --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: briefDescription<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:briefDescription,_eQ_s8Om5Edupia_tZIXEqg CRC: 69888862 -->This example illustrates how to represent attributes for Architecture Mechanisms.<!-- END:briefDescription,_eQ_s8Om5Edupia_tZIXEqg --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: mainDescription<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:mainDescription,-8LfKJab2khAUjdmnImaXPA CRC: 1073452811 --><p> |
| The following shows how to capture information for <a class="elementLink" href="./../../../openup/guidances/concepts/architectural_mechanisms_2932DFB6.html" guid="_mzxI0A4LEduibvKwrGxWxA">Architectural Mechanism</a>s. This example shows two possible mechanisms: Persistence and Communication. |
| </p> |
| <h3> |
| Persistence |
| </h3> |
| <p> |
| For all classes with instances that may become persistent, you need to identify: |
| </p> |
| <ul> |
| <li> |
| <p> |
| <b>Granularity</b><b>:</b> What is the range of size of the objects to keep persistent? |
| </p> |
| </li> |
| <li> |
| <p> |
| <b>Volume</b><b>:</b> How many objects (number) do you need to keep persistent? |
| </p> |
| </li> |
| <li> |
| <p> |
| <b>Duration</b><b>:</b> How long does the object typically need to be kept? |
| </p> |
| </li> |
| <li> |
| <p> |
| <b>Retrieval mechanism</b><b>:</b> How is a given object uniquely identified and retrieved? |
| </p> |
| </li> |
| <li> |
| <p> |
| <b>Update frequency</b><b>:</b> Are the objects more or less constant? Are they permanently updated? |
| </p> |
| </li> |
| <li> |
| <p> |
| <b>Reliability</b><b>:</b> Do the objects need to survive a crash of the process, the processor, or |
| the whole system? |
| </p> |
| </li> |
| </ul> |
| <h3> |
| Communication |
| </h3> |
| <p> |
| For all model elements that need to communicate with components or services that are running in other processes or |
| threads, you need to identify: |
| </p> |
| <ul> |
| <li> |
| <p> |
| <b>Latency</b><b>:</b> How fast must processes communicate with another? |
| </p> |
| </li> |
| <li> |
| <p> |
| <b>Synchronicity</b><b>:</b> Asynchronous communication |
| </p> |
| </li> |
| <li> |
| <p> |
| <b>Size of message</b><b>:</b> A spectrum might be more appropriate than a single number |
| </p> |
| </li> |
| <li> |
| <p> |
| <b>Protocol:</b> Flow control, buffering, and so on |
| </p> |
| </li> |
| </ul> |
| <p> |
| Notice that there is no design-level information or specification here. Instead, this is more about collating and |
| refining architecturally significant requirements. |
| </p><!-- END:mainDescription,-8LfKJab2khAUjdmnImaXPA --> |
| </body> |
| </html> |
