[Thesis notes] using patterns to capture into tural decisions

ArticleDirectory

• Pattern: Concatenates the structure and Result
• Pattern: COUPLING STRUCTURE AND CONSEQUENCES
• Decision-making: capture key information
• Relationship between model and decision

Neil B. Harrison,Utah Valley State College

Paris avgeriou,University of Groningen

Uwe zdun,Vienna University of Technology

 

Decision Making in SA design is crucial, especially for QA.

However, architects usually do not fully record these decisions.

They do not pay attention to the benefits of recording, do not know how to record, or even do not know that they are making decisions.

Therefore, the lack of complete records leads to chaotic design in the later stages of the system and conflicts between decisions.

 

Researchers have proposed many methods and tools to help architects record decisions.

However, it is still difficult to lose information.

 

Arch pattern can capture structure and behavior information to solve the challenge of these records,

1. Architects can be encouraged to think carefully about decision-making and use a method that naturally does not affect the design process.
2. Arch pattern is easy to use and provides a rich set of information, including rationale, consequence, and related demo.
3. Essentially, it provides reusable knowledge.

This article discusses the relationship between pattern and describe, and how to use pattern to capture decisions.

 

Problem Overview

Most of the methods used to describe SA are a set of views.

Ideally, the decision is also represented in a view.

However, it is of little significance to only record decisions. To make the records really useful, the architect needs to capture alternatives, expected consequences, and rationale.

Current research: first-order entity, explicitly expressed. Generally, it is to expand the existing C & C view.

 

Knowledge Evaporation

The ultimate goal of recording decision-making is to solve the primary issue of knowledge evaporation.

As there is no record, important information is lost along with the development and evolution process.

However, decision-making cannot be explicitly extracted from semantic tural models.

In addition, they only exist in the minds of architects and others, and are inevitably lost.

"If something is not written down, it does not exist ."

 

Due to the problem of Knowledge evaporation, the system evolution cost is high, lack of stakeholder communication, limited asset reuse, and poor traceability (demand, architecture, implementation)

 

Record challenges

If the record is a standard practice, the record must be simple and automated to a certain extent.

The investigator provides some conceptual models, methods, processes, and tools used to record decisions.

There are still great difficulties, including:

1. The cost of recording is higher than the benefit
2. Architects sometimes do not know what to record because they are not aware of their own decisions or have not carefully considered them.
3. During the process of re-creation, the architect is used to delaying recording this matter;
   So many decisions and rationale are forgotten.
4. Architects do not know how to record these decisions

Obviously, these difficulties are difficult to record the decision-making process, leading to the loss of a lot of important knowledge.

 

Pattern solution the pattern Solution

Arch pattern is a solution to General architectural design problems that have been repeatedly used, verified, and documented.

Arch Pattern provides an effective way to capture some of the most important design decisions and provide appropriate alternative solution.

Mode records, including the usage environment of the mode-repeated problems solved by the mode, and the consequences of the mode.

Mode can help ease the burden on records:

1. Decision-making, including structure and behavior information, is easier to record
2. Record the pattern to encourage architects to reflect on these decisions
3. Pattern Selection is an important part of natural design, with a low record cost.
4. Pattern is easy to understand.

Pattern vs decisions: Concatenates the structure and result pattern: Coupling Structure and consequences.

A model describes a problem, its context, and a general solution.

Many developers use patterns to Record Solutions to software problems. The most famous is the design pattern in OO.

Arch pattern is similar to the DP in OO and provides an understanding of the context.

The difference is that AP does not directly generateCodeThe AP describes the AP at the arch design level.

Abstract, high-level system structure and its associated behavior.

The AP is usually at a high level, which gives the modular decomposition form of the system.

 

The advantage of an AP is that it can capture the general structure of the system (well known and easy to recognize) and the corresponding results.

This information is particularly useful in restructuring the system:

The system structure displays (explicit or implicit) AP.

The descriptions of these pattern Give the consequences of the decision (QA)

However, these consequences are not so obvious in the decision-making process.

 

Common AP types include:

Layers

Pipes and filters

Blackboard

For AP, Paris avgeriou and Uwe zdun provide a complete architecture pattern that has been recognized.

In addition, it can also be described by using the architectural style, which was first proposed by Shaw in 1988.

We generally think that the two are similar concepts, which are collectively called pattern.

Decision-making: capture key information

Structure of a decision affecting the system

Jan Bosch proposed that a decision should be based on needs and solutions. In addition, each decision should solve some requirements without considering other requirements.

According to Bosch, a decision may be:

1. Add a component
2. Specify functions for existing components
3. Increase demand for expected behavior of components
4. Add constraints to some or all existing Architectures

He also pointed out that a decision can represent the structure of many solutions, including style or pattern.

 

What information does demo-e need to collect and record?

Issue, demo-, alternative, reasoning,

Anton Jansen and Jan Bosch describe the information as problem, motivation, cause, context, potential solution, and demo-

Jeff Tyree proposed a template to record them.

 

The second important question is, what types of describe include?

1. Existence
2. Non-existence
3. Property decisions
4. Executive Decisions

 

Two types of knowledge:

Application-generic knowledge

Application-specific knowledge

 

The key is to record relevant information, rather than simply making decisions.

Model-driven development method the development tool can define architectural metamodel, and constraints, model-checking

We can extend the MSDS tools to model decisions and use them to define and automate inspection constraints.

However, no one has done this effectively yet.

 

Relationship between model and decision

Two complementary concepts.

A pattern is used to select one from a group of alternative, and therefore make a decision in the specific context of the target system.

For example, to design a user interface, you may consider MVC or PAC.

Advantages and disadvantages

Balance between architects

 

The greatest difference between a pattern and a decision, including the scope of information

Decision-making, specific, tentative (app-speific DGE dge)

Pattern, universal, proven (app-generic knowledge)

 

Although patterns and decisions come from different origins, comparing their record formats remains the same.

A decision includes the issue, alternative solution, final decision, and the reason for the decision;

A pattern similar to issue, decision, alternative solution is proposed and proved

 

Table 1 provides a general record decision and mode:

 

In addition to the form, another interesting question is how the two methods help to select solutions.

Pattern

An independent mode provides alternative solution,

Different pattern types have different variant types, which may be complementary. For example, Cs, P2P, publish-subcribe, etc.