# HIGH LEVEL DESIGN
###### tags: `software architecture`

## Communicating architecture
### Kruchten's 4+1 model view
### UMS Component diagram
### UMS Package diagram
### UML Deployment diagram
### UML Activity diagram

## Architecture styles
### Language-based Systems
#### Abstract Data Types and Object Oriented
#### Main Program and Subroutine
### Repository-based systems
#### Database
### Layered Systems
#### Layered systems
#### Client Server n-Tier
### Integreter-based Systems
#### Intepreters
#### State Transition System
### Dataflow Systems
#### Pipes and Filters
### Implicit Invocation Systems
#### Event based
### Process Control Systems
#### Process Control

## Quality attributes




## Analyzing and Evaluating an Architecture
### Using Quality Attribute Scenario
- Each quality attribute measures a functional or nonfunctional requirement of the system, but how do we perform the measurement?
- All quality attributes use **quality attribute scenarios** to determine if a system is able to meet the requirements that are set for the quality attribute.
- A **general scenario** is used to characterize any system,
- a **concrete scenario** is used to characterize a specific system.
- Each scenario consists of
- a **stimulus source**: The stimulus source is anything that creates a stimulus, a source can be internal or external to the system.
- For example, an internal source can be an internal timer, and an external source could be the end user.
- a **stimulus**: is a condition that will cause the system to respond. Since the source of the condition can originate internally or externally, you will need to differentiate the types of conditions, and be specific. A specific internal error could be a buffer overflow, and a specific external error could be incorrect user input.
- an **environment**: is the mode of the system when it is receiving a stimulus. The environment of a scenario is particularly important if your system involves distributive computing. Or if the system can exist in operational modes besides just running and stopped, like recovering from a failure.
- an **artifact**: is the part of the system that is affected by the stimulus. In large scale systems, a stimulus should not directly affect the entire system. Instead, a stimulus should cause a response within a sub-system, which then sends a stimulus to another sub-system
- a **response** is how the artifact will behave as a result of receiving a stimulus. This can include handling an error, recovering from a failure, updating system logs, dispatching security alerts, or changing the current environment
- a **response measure** is a metric used to quantify the response, so that the quality attribute can be measured. The metric should be quantitative and objective, such as probability of failure, response time, repair time, and average system load.

##### General availability scenario example


##### Specific availability scenario example
- Availability of a web server can be hindered in its ability to process requests when at resource limits, or under heavy load. So you can measure a server's availability under different conditions. In this concrete scenario, a customer needs to wait for the system to finish processing previous orders for concert tickets, before they're able to send their purchase request. The system is unavailable for customers if a system can't accept the request for tickets, which has a negative effect on the availability quality attribute of the system.


### ATAM - Architecture Tradeoff Analysis Method
- Developed by the Software Engineering Institution at Carnegie Mellon University.
- The advantage of ATAM is that the evaluators do not need to be familiar with the architecture or the problem space. This allows outsiders to evaluate your system, or for you to evaluate the architecture of a project you are not involved in.
#### ATAM involves three different groups of participants.

- **evaluation team**, which has three different subgroups **designers, peers, or outsiders**. The most important characteristic for the evaluation team is that they be unbiased.
- **Designers** are the ones involved with the architectural design. This group naturally follows an **iterative, hypothesis-driven method** when designing. Which involves (1) analyzing the system requirements, (2) creating a design to address the requirements, and then (3) reviewing the design to see if it works.
- **peers** are part of the project, but are not involved in the design decisions. This allows you to get different viewpoints on your design decisions.
- The last group are outsiders, who are external to the project or to your organization. The main reason to involve an outside group to do an evaluation is because it completely eliminates any bias towards the project. Outsiders should have experience and expertise in analyzing architecture, so you can be confident with their evaluation.
- The second participant group of ATAM involves **project decision makers**. They are project representatives with the authority to make project decisions. This could include project managers, clients, products owners, software architects, and technical leads.
- The third participant group involves the **architecture stakeholders**. This includes anyone who wants the architecture to successfully address the business needs, but is not actively involved in the evaluation process. End users, developers, and support staff would belong in this group. Let's look at the high level flow of ATAM before diving into the details.

#### High level flow of ATAM

- The **business drivers** initiate the software project because of the need for a system to address some problem. These drivers go hand in hand with the **system architecture**, which is created as a solution to the business issues.
- The business drivers and system architecture determines the quality attributes of the system, the architectural approach taken, and the design decisions that are made. These ultimately combine together to allow you to create quality attribute scenarios. These scenarios are analyzed, resulting in an evaluation of the system, which includes tradeoffs, sensitivity points, non-risk scenarios, and risk scenarios. Since the risk scenarios have a negative impact on the quality of the system, we analyze each of them and categorize them into risk themes.

Architecture trade-off sample

#### ATAM Process
(1) **Present the ATAM**, the evaluation team presents the ATAM process. Which includes the context for the evaluation, expectation, procedures, outputs, and addresses any concerns about the evaluation.
(2) **Present the business drivers**, the project decision makers present the business problem, and the goals for the system. They also present the system's features and requirements, project constraints, and scope.
(3) **Present the architecture**, the current and expected state of the architecture is presented. Constraints of the project that can affect the architecture, such as time, cost, difficulty of the problem, and quality expectations are also presented.
(4) **Identify the architectural approaches**, this is the first analysis activity, which involves examining the architectural patterns that have been used in the system so far. In this step, you analyze the documentation, the notes from the presentations, and ask questions to get more clarity about the system.
(5) **Create a quality attribute utility tree**, the requirements for each quality attribute is detailed in a quality attribute utility tree. You can gain insight about the system and identify the quality priorities, by working with the project decision makers to refine your utility tree. A utility tree captures all the quality related architecturally significant requirements, also known as ASRs, which arise from the business drivers. The overall utility of a system is broken down into quality attributes, however, quality attributes are general. So the utility tree further refines quality attributes into attribute refinements, which are more specific qualities of a system. Once we have refined the quality attributes, we can then associate the ASRs with the appropriate attribute. Each ASR is given a priority value to denote if they are must-haves or not. In this example, we have used High, Medium and Low, designated by H, M and L, respectively. The priority values used may differ from system to system.


(7) **Analyze the architectural approaches**, using the prioritized ASRs from you utility tree, examine the architecture, and determine how it addresses each ASR. This allows you to identify and document the risk and non-risk scenarios, sensitivity points, and tradeoffs. A sensitivity point identifies processes in a system that could affect the specific quality attributes of a system relative to an ASR. For example, high traffic may cause an increase in the system's latency. Tradeoffs occur when you sacrifice one quality for improvements in another. For example, you could limit the number of concurrent users allowed on your system. This would limit the system's availability, but in return, you don't need to worry about increased latency due to growing system traffic. This step allows you to drill down into the capabilities of the system, and the consequences of its design decisions. It's not meant to be comprehensive, but aims to identify the connections between the business drivers and system architecture.
(8) **Brainstorm and prioritize scenarios**, each group of participants creates quality attributes scenarios that are important to them, and that they would expect when using the system. Scenarios that have similar quality concerns or behaviors can be merged together. This is meant to give you an idea of what the day-to-day system usage looks like, an insight into the environment that the system can be in.
The scenarios are prioritized based on importance to each stakeholder. And the evaluation team compares the list with the prioritized ASRs in the utility tree. If the priorities of the stakeholders match closely with the priorities in the utility tree, then there is good alignment. Any additional scenarios discovered by the stakeholders beyond the original set of ASRs are usually considered a risk, if there are lots of them. This means that the architecture is not able to the address the needs of those who will be using or relying on the system.
Reanalyze the architectural approaches, similar to the the earlier analysis, you create a utility tree. But you will use the top five to ten scenarios prioritized in the previous step. Using this new utility tree, you can talk with the system architect and discover how each scenario can be achieved with the system design.
(9) **Present the results**, finally, the results of the evaluation are compiled and presented. The risk scenarios are grouped together and are categorized into risk themes. Risk themes help to identify which business drivers are affected. The information presented includes all architecture documents, utility tress, risk and non-risk scenarios, sensitivity points, tradeoffs, and risk themes.

Modern systems are becoming more complex, in order to address a variety of business problems. The challenge of designing system architectures is to be able to create complex systems, while achieving all the requirements for the quality attributes. The architectural tradeoffs analysis method is a common approach for analyzing and evaluating system design. ATAM doesn't require you to have intimate knowledge of the system. It involves all important stakeholders, and it puts emphasis on the system's quality attributes. Knowing the risks, sensitivity points, and tradeoffs of your system is important. In order to produce a high quality system, you want to minimize risks by discovering and addressing them, minimize the effects of sensitivity points, and be sensible about your tradeoffs. In a case study, the Software Engineering Institute of Carnegie Mellon University used ATAM to analyze and evaluate the product line systems program developed by Avionics Systems. The SEI found that ATAM helped to expose unseen risks to the stakeholders involved in the architectural process. In addition, ATAM helped to facilitate communication between stakeholders, found issues with newly discovered functionalities that the stakeholders express to be important, and elevated the role of software architecture. Designing systems is becoming more complex and difficult, as technology grows to meet the demands of the work place. By analyzing and evaluating your architecture, you can successfully create high quality systems.

### Attributes

#### [ISO 25010](https://iso25000.com/index.php/en/iso-25000-standards/iso-25010)

(From Software Architecture in Practice 3rd - p194)

Reference:

#### Availability
- docker swarm, kubernete
- HA proxy
#### Interoperability
#### Modifiability
#### Performance
#### Security
#### Testability
#### Usability
####

------------------
## Collected Design Style
### Writing a High Level Design - David Van Couvering
Source: https://david-vancouvering.medium.com/writing-a-high-level-design-26280ee88480

- High-level design documents provide a framework and guidance for driving the more detailed design and implementation of a feature/system.
- **Start with requirements** defined as scenarios, use cases, or acceptance criteria
- **Domain Model**
- use the E/R diagram standards to indicate cardinality (one-to-many, many-to-many), they are easier for non-technical folks to understand than UML.
- Add a set of bullet points below providing a summary of each of the concepts introduced in the diagram.
- Keep it as **living document** for updating
- Example

    - An Answer is a specific answer to a survey Question by a particular
    Person. Note that depending on the type of the Question, the valid values 
    for an Answer may differ

- **System diagram**
- It’s important to lay out the actual components that will be built to implement this design
- The main thing is to show what the components are that will need to be built or interacted with to support this design. A UML component diagram works nicely for this.
- **Exercise the Domain Model and Components**
- Your scenarios are your test cases for this model and components
- I usually do this is by having a separate paragraph for each scenario, and show how the system will interact/behave for that scenario
- The judicious use of sequence diagrams is an excellent tool for this kind of exploration. (recommend using [WebSequenceDiagrams](https://www.websequencediagrams.com/))
- **Don’t Forget the Error Cases**
- Think about what happens when things go wrong. *How should things respond? How can you be resilient to failure? How can you avoid failure altogether?*
- What I’ve found is that often the analysis of failure scenarios has a deep impact on your design