This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
dido:public:ra:1.4_req:2_nonfunc:20_maintainability:modifiability [2021/07/26 13:02] murphy |
dido:public:ra:1.4_req:2_nonfunc:20_maintainability:modifiability [2022/01/27 06:04] (current) nick |
||
|---|---|---|---|
| Line 17: | Line 17: | ||
| Accessed 5 August 2020 | Accessed 5 August 2020 | ||
| [[https://www.sciencedirect.com/book/9781558609006/java-web-services-architecture]] | [[https://www.sciencedirect.com/book/9781558609006/java-web-services-architecture]] | ||
| - | )): | + | )) during [[dido:public:ra:xapend:xapend.a_glossary:p:peer_review | Peer Review]]: |
| <table modifyquestiobs> | <table modifyquestiobs> | ||
| Line 75: | Line 75: | ||
| Layering involves separating the system or programs based on technical responsibilities, usually using an [[dido:public:ra:xapend:xapend.a_glossary:n:n-tier]]. Generally, these tiers are referred to as the //presentation tier//, //processing tier// and //data management tier//. Often the tiers are both logically and physically separated, with each tier running on its own dedicated platforms. In a [[dido:public:ra:xapend:xapend.a_glossary:d:distsystem|distributed system]], the tiers do not follow the [[dido:public:ra:xapend:xapend.a_glossary:c:client-server|client-server]] architecture but use a [[dido:public:ra:xapend:xapend.a_glossary:p:p2p]] architecture. However, the peers can be categorized as fulfilling presentation, processing, and data management functionality. | Layering involves separating the system or programs based on technical responsibilities, usually using an [[dido:public:ra:xapend:xapend.a_glossary:n:n-tier]]. Generally, these tiers are referred to as the //presentation tier//, //processing tier// and //data management tier//. Often the tiers are both logically and physically separated, with each tier running on its own dedicated platforms. In a [[dido:public:ra:xapend:xapend.a_glossary:d:distsystem|distributed system]], the tiers do not follow the [[dido:public:ra:xapend:xapend.a_glossary:c:client-server|client-server]] architecture but use a [[dido:public:ra:xapend:xapend.a_glossary:p:p2p]] architecture. However, the peers can be categorized as fulfilling presentation, processing, and data management functionality. | ||
| - | In addition, systems or programs that are declarative and configurable are more modifiable, especially if the configuration describes the details of connectivity between the [[dido:public:ra:xapend:xapend.a_glossary:m:module|modules]] (or peers). In other words, these descriptions provide the context and should address the 5-Ws of **who**, **what**, **when**, **where** and **why**; as well as, the **how**. For example: | + | In addition, systems or programs that are [[dido:public:ra:xapend:xapend.a_glossary:d:declarative | declarative]] and configurable are more modifiable, especially if the configuration describes the details of connectivity between the [[dido:public:ra:xapend:xapend.a_glossary:m:module|modules]] (or peers). In other words, these descriptions provide the context and should address the 5-Ws of **who**, **what**, **when**, **where** and **why**; as well as, the **how**. For example: |
| <table 5ws> | <table 5ws> | ||
| Line 85: | Line 85: | ||
| ^ where | Where can the module (peer) be found: paths, endpoints, etc. | | ^ where | Where can the module (peer) be found: paths, endpoints, etc. | | ||
| ^ why | Why is the module (peer) defined: documentation, rules, filters, etc. | | ^ why | Why is the module (peer) defined: documentation, rules, filters, etc. | | ||
| - | ^ how | How is the module (peer) accessed: Library, RESTFul, [[dido:public:ra:xapend:xapend.a_glossary:r:rpc]], DDS, Message queue, etc. | | + | ^ how | How is the module (peer) accessed: Library, RESTFul, [[dido:public:ra:xapend:xapend.a_glossary:r:rpc]], DDS, [[dido:public:ra:xapend:xapend.a_glossary:m:mq|Message queue]], etc. | |
| </table> | </table> | ||