Software Architecture In Practice: Exercises

---

Chapter 4

---

4.1

A use case includes one or more quality attributes scenarios. If we want to add quality attribute information to a use case, we need to add a new relevant scenario to the use case.

4.2

Infinite. Because for a specific tactic, when it is in different scenarios, the architect should adjust it to make it more adaptive to the scenario. So, since there are infinite scenarios in real life, we may need infinite tactics.

4.3

Some programming languages are created for specific kinds of development. For example, the HTML. If we are going to build a web, we may choose HTML instead of others. Because the structure or layout of your HTML source code has a close relationship with the architecture of your web. Due to the difference of capabilities of the languages, the choices on the other six categories are different.

---

Chapter 5

---

5.1 

5.2

Source: Internal power monitor,

Stimulus: Low-power message,

Artifact: Processor,

Environment: Normal operation,

Response: Active auxiliary power (prevent the fault from becoming a failure),

Response measure: Time consumed during activation.

5.3

Source: Physical environment,

Stimulus: Computer crashes,

Artifact: Persistent storage,

Environment: Normal operation,

Response: Automatically save and then exit,

Response measure: Time to repair.

5.4

With some form of redundancy	Without any redundancy
Voting Active Redundancy Passive Redundancy Spare Rollback Software Upgrade Shadow State Resynchronization Escalation Restart Non-Stop Forwarding Predictive Model  Exception Prevention	Ping/echo Monitor Heartbeat  Timestamp Sanity Checking Condition Monitoring  Exception Detection Self-Test Exception Handling Retry Ignore Faulty Behavior Degradation Reconfiguration Removal from Service Transactions Increase Competence Set

5.5

Apply redundancy tactics to ensure that the system is still available while being modified.

A software upgrade is another preparation-and-repair tactic whose goal is to achieve in-service upgrades to executable code images in a non-service-affecting manner. This may be realized as a functioning patch, a class patch, or a hitless in-service software upgrade (ISSU). A function patch is used in procedural programming and employs an incremental linker/loader to store an updated software function into a pre-allocated segment of target memory. The new version of the software function will employ the entry and exit points of the deprecated function.

5.6

5.7

Ping/echo: When there isn't any fault, the system maintains normal. When there is a fault, the pinging component has to wait for a period of time. This makes the information exchange on the network slow.

Heartbeat: When a fault appears in the process being monitored, it takes monitor some time to post and get the detection message. And the monitor also has to spend time on resetting the process.

System monitor: It orchestrates software using other tactics, so it may need more resource to perform.

Voting: It employs three components to do the same things, and all the components have their own outputs which are going to be put to voting logic. Here, three components take up more memory and other resources. And so does the voting logic. It is slower than doing the thing with only one component.

Exception detection: This tactic requires the system to detect its state periodically. The implication it has on system processing speed depends on its detection intensity. However, the cost is usually not expensive.

---

Chapter 6

---

6.1

Source: The client system,

Stimulus: Request to retrieve specific data,

Artifact: The server,

Environment: At runtime,

Response: The request is accepted, and the information exchange is successful.

Response measure: 100% of information exchanges correctly processed.

6.2

When two or more parts are involved to process faults and failures in a system, if the interoperations between them are not successful, the system cannot correctly process faults and failures, which means the availability is affected. When a system only has one section to process faults and it doesn't interoperate with others, the interoperation may not affect the availability.

It's the same for the rest of the quality attributes. If a specific scenario of the quality attribute involves interoperation, then it has a close relationship with the interoperability, otherwise not.

6.3

Yes. See more details on http://www.360doc.com/content/16/1027/13/35012241_601777569.shtml.

6.4

UDDI defines a standard frame for companies to use, but it doesn't specify any implementation detail. So, it is cross-platform, which means different systems can interoperate with each other. So, UDDI respects with interoperability, making it so popular.

6.5

6.6

6.7

ATM is kind of end device, it has to be capable to interoperate with users, which requires it to be easy to understand and use. It also has to interoperate with the databases to modify the information of users' accounts. During the process, it has to be protected by a security system. So it interoperates with users, transaction processing system, databases, and the security system.

1. Refine and simplify the UI to make it user-friendly. 2. Connect it with a transaction system. The system processes the user's desired operation and display it on the screen and waits for the user's confirmation. And also, this system should be connected with the databases to modify data quickly and accurately. 3. Create a secure operating environment or lend from external security services to make sure that the system is free from attacks.

---

Chapter 7

---

7.1

7.2

7.3

1. Reduce the size of a module(Split module). Using two machines to respectively deal with tickets and changes. 2. Increase cohesion and reduce coupling. Split the two sections that do not serve the same purposes in a module into two independent modules.

Since the separate modules are independent of each other, when one does not work correctly, the other will not be affected. So the whole system is of high availability.

7.4 

Source: system administrator,

Stimulus: divide the system's functionality into two parts,

Artifact: components,

Environment: build time,

Response: make the modification, test the modification, and deploy the modification,

Response measure: costs of modification.

7.5

Reduce coupling. Other modules can only interoperate with the wrapped module through the wrapper, so we can know that the wrapper is an interface of the module, which is an indication of the application of reducing-coupling tactic. And the wrapper translates the inputs in the form of English measures to that of metric measures. Here the wrapper is as an intermediary between two independent modules, which also indicates the use of reducing-coupling tactic.

7.6

We can restrict dependencies. We can restrict the module's visibility to prevent it from being accessed directly. We can also apply authorization. All other modules are not authorized to access the module, but they are authorized to access through the intermediary.

7.7

Yes. A release version must be fully modified to ship, so the costs of modification should stop. What's more, when a version is ready to ship, a modification will just make it unstable for users to use. So, the modification should be avoided.

7.8

In the aspect of programming language, abstracting means introducing an interface for several classes that serve a similar function. After being abstracted, if we modify the interface, all the implementation classes will also be modified. But to increase cohesion, we hope to split the modules taking different responsibilities, so the modification of one will not affect others.

7.9

Source: system administrator,

Stimulus: intention to change UI,

Artifact: ATM UI,

Environment: design time,

Response: make the modification, test the modification, and deploy the modification,

Response measure: the costs of making the modification.

Maintain the ATM separate from other modules.

---

Chapter 8

---

8.1

Every system does have real-time performance constraints. Because the users want to perform some tasks in the system and complete them as soon as possible. If there is no constraint, when the resource is very limited, the process may be a very long time, which is not user-friendly.

8.2

Source: airline,

Stimulus: all the on-time arrivals,

Artifact: system,

Environment: normal operation,

Response: on-time arrival performances are recorded,

Response measure: average performance.

8.3

Source: users,

Stimulus: deposit, withdraw, etc,

Artifact: system,

Environment: normal operation,

Response: change the balance, dispense cash and change the balance, etc,

Response measure: worst-case latency of 10s, average-case latency of 5s, the throughput of 1, a jitter of 2s, miss rate of 0.

Modification: apply a more efficient algorithm, refine the databases.

8.4

Maintain multiple copies of data.

8.5

By using synchrony, the subsequent operation would be completed only after a response returned. So, synchronous interaction is stable and of a low miss rate. By using the asynchronous mechanism, after you post a request, you can continue doing other tasks or posting more requests.

8.6

Increase resources: put more checkout counters in place to process more queues,

Introduce concurrency: put more checkout counters in place to process more queues,

Bound queue sizes: bound the max capacity of a queue, avoiding that there are too many people in a queue while only a few people in another,

Schedule resources: dynamically manage the number of people in every queue.

8.7

Multiple-threading causes deadlock.

---

Chapter 9

---

9.1

Source: human

Stimulus: trying to make the ATM dispense cash without a card

Artifact: ATM system

Environment: online or offline

Response: the ATM is not usable when it is offline; when it is online, users can do nothing without a card and an authentication.

Response measure: the unauthenticated request is rejected.

Modification: add an authentication module into the ATM system.

9.2

9.3

1. If a system was attacked, the developers are able to find out the bug and fix it to make a more secure version of the system.

2. Reasonably apply some security tactics while developing a system to make the system more secure.

3. Prioritize the importance of the data in the system and protect them.

4. Create a secure deploying environment.

5. Use a more secure programming framework.

9.4

We should make a tradeoff analysis. In some cases, for example, in a payment system. Deploying a protection service and the requirement for password authentication are needed urgently, though, they slow the processing of users' orders. In this case, we have to sacrifice the speed for the security. Otherwise, we just make sure that the system can perform tasks fast and accurately.

9.5

1. Bandwidth: if a server doesn't utilize an effective firewall, it is likely to be attacked which may heavily overload the bandwidth and crash the server.

2. TCP/IP ports.

9.6

9.7

9.8

9.9

Pros: 1. Raise public awareness and warn other corporations of systems bugs. 2. Help develop more secure systems to avoid the same bugs.

Cons: 1. May cause more attacks pointing to the vulnerability revealed to the public. 2. Affect business profits.

---

Chapter 10

---

10.1

In my point of view, they are not incompatible. We can make our system detect, recover from faults and active a substitute program to prevent from faults. This means we hide the faults for now. And then record them and log them out to the developers for a further refinery.

10.2

I agree. First, a release version is with the least faults and is stable. It is not likely to crash frequently. There are only a few faults that do not affect normal uses. And for most users, they are not capable of testing skills. Even though some faults are revealed, it is always very difficult for end users to test and recover. So it is meaningless. It just informs end users of the existence of faults and inhibits them from normal uses.

10.3

When we test for some systems, it is likely that only some parts of a system contain faults, so we just test those modules. And for testing, we may apply limiting-complexity tactics, which means we may reduce the size of a module, or split it into several smaller submodules to lower our burden of testing. Because the smaller a module is, the easier for us to test it. When we split a module, we increase the cohesion and modifiability at the same time.

10.4

10.5

Conflict with: Performace

Compatible: Modifiability, Availability, Security

10.6

1. Increase response times in ping/echo and heartbeat of availability. 2. Decrease performance. 3. Assure security.

10.7

First, complete unit tests should be carried out before releasing. And then release a beta for a group of invited users to gather bugs and repair them.

1.

Source: unit testers,

Stimulus: tests of different units,

Artifact: corresponding units,

Environment: development time,

Response: results captured,

Response measure: over 90% of path coverage.

2.

Source: users,

Stimulus: tests of the system,

Artifact: the system,

Environment: running time,

Response: bugs reported,

Response measure: details of bugs.

10.8

In some cases, the service providers cannot monitor all the end systems deployed, since they have so many users. So when one of the end systems crashes, the executing system has to assert the fault and let the user determine whether he or she report this fault to the providers. For a pilotless auto system, the assertion is not needed. Because in the complex street environment, a driver doesn't have time to solve this assertion and it may arise panic. In this case, the system should just inform the driver of the switching driving mode.

---

Chapter 11

---

11.1

1.

Source: me,

Stimulus: trying to set my favorite radio stations,

Artifact: automobile,

Environment: runtime,

Response: radios set successfully,

Response measure:  time to set.

2.

Source: me,

Stimulus: trying to get navigation,

Artiface: automobile,

Environment: runtime,

Response: destination found,  a routine found,

Response measure: two tasks completed.

11.2

Source: users,

Stimulus: trying to withdraw,

Artifact: ATM system,

Environment: runtime,

Response: ATM dispenses a particular amount of cash,

Response measure: task completed in 30 seconds.

11.3

If the system supports user initiative to let user undo, cancel, or pause. The user may accidentally restore system variations or make new variations, which conflicts with security. If the system maintains a task model, when the user doesn't respect for the model, the system has to do some changes automatically, which increase time consumed.

11.4

1. Jingdong:

Response: order generation,

Response measure: in 1 second.

2. Taobao:

Response: order generation,

Response measure: in 1 second.

The two online shopping websites are all of the high performance while generating an order for specific items.

11.5

11.6

When we click a cancel button, the system should close the dialog and go back to the previous state. If a cancel button is unresponsive, it means, to some extent, that the system does not save the previous state. We the cancel button remains unresponsive because we cannot go back.

11.7

It's a kind of trick. In fact, in that case, the progress bar doesn't reflect the true progress of a task. If the progress is completing at an average low speed, the user may cancel it. If 90% of the progress is completed very quickly, then the user may patiently wait for the rest to be completed. Because the user does not want the previous to be futile.

11.8

In most systems, the security is provided by some of their modules. And some of the security modules can be human-involved. So, if the modules are not usable, some security problems spring out.

 ​​​​​