1. A Survey of Self-Management in Dynamic Software Architecture Specifications
Jeremy S. Bradbury, James R. Cordy, Juergen Dingel, Michel Wermelinger
  "International Workshop on Self-Managed Systems(WOSS'04), Newport Beach,
   California, USA, October/November 2004."
09월30일
Software Engineering Lab.
석사 1기 허 석

2. Support for self-management
Content
Abstract
Introduction
Formal specification
Support for self-management
Expressiveness
Type of Change
Selection
Scalability
Conclusions and Future work
References

3. Abstract
In this paper we survey 14 formal specification approaches based on graphs, process algebras, logic, and other formalisms
Our survey will evaluate,
the ability of each approach to specify self-managing systems
the ability to address issues regarding expressiveness and scalability
이 논문에서 우리는 graphs, process algebras, logic, 그리고 기타 formalisms(형식주의들) 에 기반을 둔 14개 formal specification approaches 에 대해 조사하였다.
우리의 조사들이 평가하는 것으로는,
Self-managing systems 을 기술하기 위한 각각의 approach 의 능력
Expressiveness 와 scalability(범위성) 에 관하여 이슈들을 기술하기 위한 능력

4. Introduction - Definition
Dynamic software architectures modify their architecture and enact the modifications during the system’s execution
This behavior is most commonly known as run-time evolution or dynamism
Self-managing architectures are a specific type of dynamic software architectures
We define a system that enacts architectural changes at run-time as having a self-managing architecture if the system not only implements the change internally but also initiates, selects, and assesses the change itself without the assistance of an external user
Programmed dynamism, self-organising architectures, self-repairing systems, and self-adaptive software are all examples of self-managing architectures
• Dynamic software architectures 는 그들 자신의 architecture 을 수정하고 system의 실행 동안에 수정들이 일어난다.
∙ 이러한 행위는 대부분 일반적으로 run-time 진화 또는 dynamism 으로 알려졌다
• Self-managing architectures 는 dynamic software architectures 의 특정 형태이다.
• 우리는 system이 만약 외부 사용자의 간섭 없이 자신을 변화하는 것에 대해 initiates, selects, 평가하는 것 뿐만 아니라 내부적으로 변화를 구현한다면 self-managing architecture로써 run-time 에 architectural changes 가 일어나는 것을 system으로 정의한다.
∙ Programmed dynamism, self-organising architectures, self-repairing systems, 그리고 self-adaptive software 는 self-managing architectures 의 모든 예제들이다.

5. Introduction - Background
Dynamic software architectures and specifically dynamic components have been identified as “challenging in terms of correctness, robustness, and efficiency?”
This is especially true for self-managing architecture since systems that are self-managed have to implement the initiation and selection of a change.
User-managed architectures usually exhibit ad-hoc change in which the initiation and selection occur external to the software, thus simplifying the development.
• Dynamic software architectures 와 특히 dynamic components 는 “correctness, robustness, 그리고 efficiency 에 대한 도전과제인가?” 라는 질문으로써 식별되어진다.
∙ self-managing architecture 은 systems 이 change 의 initiation 과 selection 을 구현해야 하는 self-managed 이기 때문에 더욱 사실이다.
• 사용자 관리 architectures 는 software 에 대해 외부에서 발생하는 initiation 과 selection 로 ad-hoc change 를 나타내며, 이러한 software 는 간단하게 개발한다.

6. Introduction – Formal specification
Formal specification is one way to support the development of correct and robust dynamic software architectures
Our goal is to focus on the ability of each approach to specify self-managing architectures
We determine if each specification approach supports our definition of a self-managing architecture
We evaluate each approach with respect to the expressiveness of the approach in specifying different types of change and different levels of change from a fixed selection approach to an unconstrained approach
We compare the scalability of the approaches to specify decentralized management schemes which are more likely in large-scale systems
After evaluating all of the specification approaches we use the results to make recommendations on how formal specification approaches for dynamic software systems in general, and self-managing in particular, can be improved
• Formal specification 는 correct 하고 robust 한 dynamic software architectures 의 개발을 지원하기 위한 하나의 방법이다.
* 우리의 목표는 self-managing architectures 을 기술하기 위해 각각의 approach 의 능력에 초점을 맞춘다
∙ 우리는 각각의 specification approach 가 self-managing architecture 의 우리의 정의를 지원하는지 안 하는지를 결정한다.
∙ 우리는 change 의 다른 형태들과 고정된 selection approach로부터 자유스러운 approach까지 change 의 다른 levels 을 기술하는데 approach 의 expressiveness 에 기대하는 각각의 approach 을 평가한다.
∙ 우리는 대규모 systems에서 더욱 있음직한 분산 관리 스키마들을 기술하기 위해 approaches 의 scalability 을 비교한다.
* Specification approaches 의 모든 것들을 평가한 후에 우리는 일반적으로 dynamic software systems 을 위한 formal specification approaches, 그리고 특히 self-managing 을 향상시킬 수 있는 방법에 대한 추천들을 만들기 위해 평가결과들을 사용한다.

7. Introduction – Related work
Related work to our survey includes several papers that have surveyed Architecture Description Languages (ADLs) and provided broad comparisons [6, 18]
The survey in [6] compared ADLs on attributes related to scope of language, expressive power, tool maturity, and others
The survey in [18] compared ADLs in terms of their ability to model components, connectors and configuration as well as tool support for such things as analysis and refinement
Our work differs from previous work in that we consider only formal specification approaches and provide a narrower comparison, focusing on the ability of each approach to specify self-managing architectures.
The previous approaches have not focused on self-managing architectures. In fact, only the survey in [18] even considers run-time evolution in its evaluation
• 우리의 조사에 대한 관련 연구는 여러 페이퍼에 걸쳐서 조사된 ADLs 와 제공된 6, 18번 논문의 폭 넓은 비교를 포함한다.
∙ 6번 논문내의 survey 로는 language 의 범위, expressive power, tool maturity, 그리고 기타 다른 것들과의 관계되는 ADLs 속성들에 대해 비교하였다.
∙ 18번 논문내의 survey 로는 분석과 정제와 같은 것들을 지원하는 툴뿐만 아니라 컴포넌트, 커넥터, configuration 을 model 하기(만들기) 위한 그들의 능력에 대해 ADLs 을 비교하였다.
우리의 작업은 이전의 작업과 다르게, 단지 formal specification approaches 을 고려하고 self-managing architectures 을 기술하기 위한 각각의 approach 의 능력에 초점을 맞춘 좁은 비교를 제공한다.
이전 접근방법들은 self-managing architectures 에 초점을 맞추지 않았다. 사실상, 오직 18번 논문의 survey 는 그들의 평가에 run-time evolution(발달)만을 고려하였다.

8. Formal specification – Four categories
Formal approaches to dynamic software architectures involve the specification of the architectural structure of a system, the architectural reconfiguration of a system, and usually the behavior of a system.
The formal approaches to specifying dynamic software architectures that we consider are divided into four categories
Graph-based approaches
Process algebra approaches
Logic-based approaches
Other approaches
• dynamic software architectures 을 위한 Formal approaches 는 system architecture 구조의 specification, system 의 architectural reconfiguration, 그리고 system 의 behavior 을 포함한다.
• dynamic software architecture 을 기술하기 위한 formal approaches 에는 4 category 로 나누어서 고려된다.
∙ Graph-based approaches
∙ Process algebra approaches
∙ Logic-based approaches
∙ Other approaches

9. Formal specification – Four categories
Graph-Based Approaches
A natural way to specify software architectures and architectural styles is to use a graph grammar to represent the style and a graph to represent a specific system’s architecture
A natural way to specify reconfiguration in a dynamic architecture is to use graph rewriting rules
Process Algebra Approaches
Process algebras are commonly used to study concurrent systems
Processes in the concurrent system are specified in an algebra and a calculus is used to verify the specification
• Graph-Based approaches
∙ software architectures 와 architectural styles 을 기술하기 위한 일반적인 방법은 architecture styles 을 나타내기 위해 graph grammar, 특정 system 의 architecture 을 나타내기 위해 graph 을 사용한다.
∙ dynamic architecture 내의 reconfiguration 을 기술하기 위한 일반적인 방법은 rewriting rules 에 graph 방식을 사용한다.
• Process Algebra Approaches
∙ Process algebras 는 일반적으로 concurrent systems 을 연구하기 위해 사용한다.
∙ concurrent system 내의 Processes 는 specification 을 증명하기 위해서 사용하는 algebra 와 calculus 을 기술한다.

10. Formal specification – Four categories
Logic-Based Approaches
Logic is also used as a formal basis for dynamic software architecture specification
Other Approaches
Other approaches exist that do not have a reconfiguration semantics based on graph theory, process algebra, or logic
• Logic-Based Approaches
∙ Logic 은 dynamic software architecture specification 을 위한 형식적인 원리로써 사용한다.
• Other Approaches
∙ 다른 approaches 는 graph theory, process algebra, or logic 에 바탕을 둔 reconfiguration semantics 을 가지지 않는 것을 나타낸다.

11. Support for self-management – Change process
• 모든 dynamic architectural 변화들은 4가지 단계를 가진다.
변화의 Initiation, architectural 변환의 selection, reconfiguration 의 구현, reconfiguration 후 architecture 의 평가
All dynamic architectural changes have four steps (see Figure 1): initiation of change (1), selection of architectural transformation (2), implementation of reconfiguration (3), and assessment of architecture after reconfiguration (4)

12. Support for self-management – Change process
We defined a self-managing architecture as an architecture in which the entire change process occurs internally
We determine which specification approaches support self-management by considering if the initiation of the change occurs internal to the software
In all of the approaches, if the initiation occurs internally then the selection and other steps of the change process can also be specified internally
Internal initiation usually involves monitors that provide the run-time information on which self-management decisions are based
• 우리는 내부적으로 일어나는 change process 에 architecture로서 self-managing architecture 을 정의한다.
• 우리는 change 의 initiation 이 software에서 내부적으로 일어나는지 아닌지를 고려하는 것에 의해서 self-management 을 지원하는 specification approaches 을 결정한다.
• approaches 의 모든 것들은 만약 initiation 이 내부적으로 발생한다면, selection 과 change process 의 다른 단계들은 내부적으로 기술될 수 있다.
∙ 내부 initiation 은 보통 self-management 결정들에 기반을 둔 run-time 정보를 제공하는 monitors 을 포함한다.

13. Support for self-management – Example
An example of an approach that supports internal initiation is the Le Metayer approach which provides this support through side conditions in the rewriting rules
For example, consider the rule given in
which removes a component c and two connectors CR and CA. The side condition c.leave=true in this rule refers to a public variable leave in a component c being true
• 내부 initiation 을 지원하는 approach 의 예제로는 rewriting rules 속에 조건들을 통하여 내부 initiation 지원(Monitor) 을 제공하는 Le Metayer approach 이 있다.
• 예제로 ‘ C(c), c.leave=true, CR(c, m), CA(m, c) -> 0 ’ 과 같은 규칙에서 C 컴포넌트와 CR, CA 커넥터를 제거한다. 이 규칙 내의 조건인 c.leave=true 는 public 변수인 컴포넌트 C 의 leave 가 true 되는 것을 말한다.

14. Support for self-management – Change initiation support
Of the fourteen specification approaches surveyed, we evaluated each approach to see if it supported internal initiation, external initiation, or both.
We include the notion of a criterion being not application because not every specification approach can be classified perfectly using our criteria
We also include support unknown because despite our best effort we were occasionally unable to discern how all of the approaches fit
• 이러한 14가지 specification approaches 을 보면, 우리는 software가 내부 initiation, 외부 initiation, 또는 둘 다 지원되는 것으로부터 각각의 approach 는 평가된다.
• 우리는 기준이라는 관점에서 생각해보면 모든 specification approach 이 우리의 기준 안에서 사용하는 것을 완벽하게 분류될 수 있는 것은 아니기 때문에 application이 되지 못한다는 것을 알아야한다.
• 또한, 최대한의 노력에도 불구하고 우리는 때때로 approaches 의 모든 방법들이 적절한지에 대해 분별할 수 없기 때문에 unknown 을 지원한다는 것도 알아야한다.

15. Expressiveness - Definition
We will only discuss the approaches that explicitly support internal initiation since these are approaches that satisfy our definition of self-management
Our definition of a self-managing architecture includes systems with very limited forms of self-management
The ability of a system to manage its own architecture is, in general, limited by the types of changes it can make and the freedom to choose the appropriate change
• approaches 는 self-management 의 정의를 만족하는 이후로 명확하게 내부 initiation 을 지원하는 approaches 로만 논의할 것이다.
• self-managing architecture 의 정의로 극히 제한된 self-management 의 형태를 가진 systems 을 포함한다.
• 자기 자신의 architecture 을 관리하기 위한 system 의 능력으로 일어 날 수 있는 변화의 형태와 적절한 변화를 선택하기 위한 자유에 의해서 한정된다.

16. Expressiveness – Types of Change
The types of change that a self-managing system can make are limited at the architectural level by the reconfiguration operations that are available
In the context of change type we consider the ability of each approach to specify basic reconfiguration operations (the addition and removal of components and connectors) and composite reconfiguration operation
In composite reconfiguration operations we consider not only the ability to add or remove subsystems or groups of architectural elements but also the constructs that can be used in specifying the operation (e.g., sequencing, choice, and iteration)
• Types of Change는 이용할 수 있는 reconfiguration operations 에 의해서 self-managing system 이 architectural level 에 제한되게 만들 수 있다.
• change 의 context 는 basic reconfiguration operation 과 composite reconfiguration operation 을 기술하기 위해 각각의 approach 의 능력을 고려한다.
• composite reconfiguration operations 는 subsystems 또는 architectural elements 의 그룹을 추가 및 제거하는 능력과 operation 을 기술하는데 사용할 수 있는 constructs 을 고려한다.

17. Expressiveness – Selection
We distinguish between three levels of selection that a specification approach may support
Pre-defined Selection : Once a dynamic change has been initiated, a change operation is chosen based on a pre-defined selection made prior to run-time
Constrained Selection from a Pre-defined Set : Once a dynamic change has been initiated there is some choice in what operation to use
Unconstrained Selection : Once dynamic change has been initiated there is an unconstrained choice regarding the appropriate change to make
• specification approach에서 지원할 지도 모르는 selection 의 세 가지 levels 사이를 구분해야한다.
∙ Pre-defined Selection : dynamic change 가 initiate 할 때, change operation 은 run-time 이전에 만들어진 pre-defined selection 에 근거하여 선택된다
∙ Constrained Selection from a Pre-defined Set : dynamic change 가 initiate 할 때, 어떤 operation 을 사용하는 것에 따라 선택한다.
∙ Unconstrained Selection : dynamic change 가 initiate 할 때, 적절하게 change 하게 만드는 것에 관하여 자유롭게 선택한다.

18. Expressiveness – Reconfiguration operations support and Selection support

19. Scalability – Centralized or Distributed
Due to the growing size and complexity of software systems scalability is an important issue
In general, a decentralized or distributed approach is more likely to scale
Currently, the management used in most of the specification approaches is centralized, not distributed
This is primarily because early types of dynamic architectural change such as ad-hoc and programmed often had centralized management
In this approach a distributed management model was developed that would allowed programmed changes to be managed concurrently in a cooperative management setting
• software systems 의 증가하는 크기와 복잡성 때문에 scalability 는 중요한 이슈가 되었다.
• 일반적으로, 분산화 접근은 너무 방대하게 보인다.
• 일반적으로, specification approaches 의 대부분에서 사용되는 관리는 집중화 된다.
∙ 이러한 주요 원인으로는 dynamic architectural change 의 초창기 형태로 ad-hoc 과 programmed 과 같은 것들 때문이며, 이들은 자주 관리가 집중되었다.
• 이러한 분산 관리 모델은 협동적인 관리 환경에 동시에 관리되는 programmed changes 을 가능하게 하는 것들로 개발되었다

20. Conclusions and Future work – Conclusions
In this paper we evaluate the ability of current dynamic software architectures specification approaches to represent self-managing architectures
For each specification approach, we consider basic support for self-management by evaluating the ability of the approach to specify systems in which a change is initiated internally
We evaluate each approach in terms of expressiveness (ability to support multiple change types and selection approaches) and scalability (ability to support distributed management)
Selection is an important step in the dynamic architectural change process and needs to be better specified to enable more meaningful analysis
• 이 논문에서 우리는 self-managing architectures 을 나타내기 위해 dynamic software architectures specification approaches 의 능력을 평가한다.
• 각각의 specification approach 에 대해, 내부적으로 initiate 되는 change 로 systems 을 기술하기 위해 approach 의 능력을 평가하는 것으로부터 self-management 에 대한 basic support 을 고려한다.
• 우리는 expressiveness 와 scalability 에 관하여 각각의 specification approach 을 평가한다.
• Selection 은 dynamic architectural change process 내의 중요한 단계이고 더욱 의미 있는 분석을 가능하게 하기 위해 더 효율적으로 기술되는 것을 필요로 한다.

21. Conclusions and Future work – Future work
To summarize, current approaches do a good job with specifying basic support for self-managing architectures
However, the approaches need to be adapted and updated to address the current limitations in terms of both expressiveness and scalability
• 요약하자면, 현 approaches 는 self-managing architectures 에 대한 근본적인 지원을 기술하는 좋은 job 이다.
• 하지만, 이러한 approaches 는 expressiveness 와 scalability 에 관한 limitations 을 기술하기 위해서 adapted 와 updated 가 필요하다.

22. References
[6] P.Clements. A survey of architecture description languages. In Proc. Of the 8th Int. Work. On Software Specification and Design (IWSSD? 6), pages 16? 5. IEEE Computer Society,1996
[18] N.Medvidovic and R. N. Taylor. A classification and comparison framework for software architecture description languages. IEEE Trans. On Software Engineering, 26(1):70? 3,2000