ISO IEC 42010 Recommended Practice for Architectural description

1. ISO/IEC/IEEE 42010:2011

2. ISO 26262 Road vehicles - Functional safety Training by Korea Testing Laboratory
ⓒ-Copyright 2012 Korea Testing Laboratory 2 / 23
ISO/IEC/IEEE 42010:2010은 ?
System 및 software engineering을 위한 Architecture Description에 대한 표준
이 표준의 주요 내용은 5,6,7절에 기술되어 있다.
이 표준과 관련된 적합성(Conformance)은 다음의 네 가지 상황이 있을 수 있다.
• Architecture description – 5절에 기술
• Architecture viewpoint – 7절에 기술
• Architecture framework – 6.1절에 기술
• Architecture description language – 6.3절에 기술

3. ISO 26262 Road vehicles - Functional safety Training by Korea Testing Laboratory
ⓒ-Copyright 2012 Korea Testing Laboratory 3 / 23
3. Terms and definitions
3.1 architecting
process of conceiving, defining, expressing, documenting, communicating,
certifying proper implementation of maintaining and improving an
architecture throughout a system’s life cycle
3.2 architecture
<system> fundamental concepts or properties of a system in its environment
embodied in its elements, relationships, and in the principles of its design
and evolution
3.3 architecture description(AD)
work product used to express an architecture

4. ISO 26262 Road vehicles - Functional safety Training by Korea Testing Laboratory
ⓒ-Copyright 2012 Korea Testing Laboratory 4 / 23
3. Terms and definitions
3.4 architecture framework
conventions, principles and practices for the description of architectures
established within a specific domain of application and/or community of
stakeholders
EXAMPLE 1 Generalised Enterprise Reference Architecture and
Methodologies (GERAM) [ISO 15704] is an architecture framework.
EXAMPLE 2 Reference Model of Open Distributed Processing (RM-ODP)
[ISO/IEC 10746] is an architecture framework.
(1) 어플리케이션의 특정 도메인 혹은 (2)이해관계자들의 community내에서
인정받은 architecture의 description에 대한 (3)conventions, (4)principles, (5)
practices

5. ISO 26262 Road vehicles - Functional safety Training by Korea Testing Laboratory
ⓒ-Copyright 2012 Korea Testing Laboratory 5 / 23
3. Terms and definitions
3.5 architecture view
work product expressing the architecture of a system from the perspective of
specific system concerns
3.6 architecture viewpoint
work product establishing the conventions for the construction,
interpretation and use of architecture views to frame specific system
concerns
특정 system의 관심 있는 부분(concerns, interest)의 관점에서 system의
architecture를 표현한 work product
특정 시스템의 관심사항을 기술하기 위한 틀을 잡기 위해
1) Construction convention
2) Interpretation of architecture
3) Use of architecture
을 정립한 work product

6. ISO 26262 Road vehicles - Functional safety Training by Korea Testing Laboratory
ⓒ-Copyright 2012 Korea Testing Laboratory 6 / 23
3. Terms and definitions
3.7
concern
<system> interest in a system relevant to one or more of its stakeholders
3.8 environment
<system> context determining the setting and circumstances of all
influences upon a system
3.9 model kind
conventions for a type of modeling
3.10 stakeholder
<system> individual, team, organization, or classes thereof, having an
interest in a system
하나 또는 그 이상의 이해관계자들과 관련 있는 시스템에서의 관심사항

7. ISO 26262 Road vehicles - Functional safety Training by Korea Testing Laboratory
ⓒ-Copyright 2012 Korea Testing Laboratory 7 / 23
4. Conceptual foundations
4.1 Introduction
4절의 구성은 다음과 같다.
4절에서 소개된 개념들은 5절에서 7절의 요구사항을 표현하기 위해 사용된다.
절 내용
4.2 Architecture description의 conceptual model로 구성되어있는
architecture description의 conceptual foundation
4.3 lifecycle에서의 architecting의 역할
4.4 architecture description의 사용
4.5 architecture frameworks, architecture description language

8. ISO 26262 Road vehicles - Functional safety Training by Korea Testing Laboratory
ⓒ-Copyright 2012 Korea Testing Laboratory 8 / 23
4. Conceptual foundations

9. ISO 26262 Road vehicles - Functional safety Training by Korea Testing Laboratory
ⓒ-Copyright 2012 Korea Testing Laboratory 9 / 23
4. Conceptual foundations
Stakeholder는 system에 관심이 있는데, 이는 system concern으
로 표현이 된다.
Purpose는 system concern의 한 종류이다.

10. ISO 26262 Road vehicles - Functional safety Training by Korea Testing Laboratory
ⓒ-Copyright 2012 Korea Testing Laboratory 10 / 23
4. Conceptual foundations
1) System이란 용어는 아키텍처가 흥미로운 개체들을 언급하기 위해 사용된다.
2) System의 stakeholder는 System에 관심(interest)이 있는 무리들이다.
3) Stakeholder의 관심은 concerns로서 표현된다.
4) Stakeholder들은 시스템에 대한 다양한 Purpose들을 표현한다.
5) Purpose는 concern의 한 종류이다.

11. ISO 26262 Road vehicles - Functional safety Training by Korea Testing Laboratory
ⓒ-Copyright 2012 Korea Testing Laboratory 11 / 23
4. Conceptual foundations
System은 Environment내에 놓여지게 된다

12. ISO 26262 Road vehicles - Functional safety Training by Korea Testing Laboratory
ⓒ-Copyright 2012 Korea Testing Laboratory 12 / 23
4. Conceptual foundations
1) System은 Environment내에 놓여지게 된다.
2) Environment는 system의 life cycle동안 environment와의
interaction을 포함한 system에 대한 영향들의 전체를 결정한다.
3) System의 environment는 다른 system을 포함할 수 있다.
4) System의 architecture는 environment와 관련하여 고려되는
system에 대한 핵심적인 것들로 구성된다. 무엇이 핵심적인지 혹은
중요한지에 대한 특성은 없다.
5) 특성은 아래의 어떤 것들 혹은 모두와 연관이 있다.
• 시스템 구성 요소 혹은 엘리먼트
• 어떻게 시스템 엘리먼트가 배치되어 있거나 밀접한 관련이 있는가
• 시스템의 구성 혹은 디자인 원칙
• 시스템의 라이프사이클에 걸친 시스템의 진화를 지배하는 원칙
시스템의 모든 측면이 표현되는 것이 아니라,
특징적인 것만 간추려서 architecture description으로 표현된다.

13. ISO 26262 Road vehicles - Functional safety Training by Korea Testing Laboratory
ⓒ-Copyright 2012 Korea Testing Laboratory 13 / 23
4. Conceptual foundations
1) System은 Environment내에 놓여지게 된다.
2) Environment는 system의 life cycle동안 environment와의
interaction을 포함한 system에 대한 영향들의 전체를 결정한다.
3) System의 environment는 다른 system을 포함할 수 있다.
4) System의 architecture는 environment와 관련하여 고려되는
system에 대한 핵심적인 것들로 구성된다. 무엇이 핵심적인지 혹은
중요한지에 대한 특성은 없다.
5) 특성은 아래의 어떤 것들 혹은 모두와 연관이 있다.
• 시스템 구성 요소 혹은 엘리먼트
• 어떻게 시스템 엘리먼트가 배치되어 있거나 밀접한 관련이 있는가
• 시스템의 구성 혹은 디자인 원칙
• 시스템의 라이프사이클에 걸친 시스템의 진화를 지배하는 원칙

14. ISO 26262 Road vehicles - Functional safety Training by Korea Testing Laboratory
ⓒ-Copyright 2012 Korea Testing Laboratory 14 / 23
4. Conceptual foundations
System은 architecture를 보인다.
Architecture description은 architecture를 표현한다.

15. ISO 26262 Road vehicles - Functional safety Training by Korea Testing Laboratory
ⓒ-Copyright 2012 Korea Testing Laboratory 15 / 23
4. Conceptual foundations
Architecture description은 관심 있는 system에 대한 architecture
를 표현하기 위해 사용된다

16. ISO 26262 Road vehicles - Functional safety Training by Korea Testing Laboratory
ⓒ-Copyright 2012 Korea Testing Laboratory 16 / 23
4.2.2 Architectures and architecture descriptions
Architecture description은 system 및 software architecting의 work product이다.

17. ISO 26262 Road vehicles - Functional safety Training by Korea Testing Laboratory
ⓒ-Copyright 2012 Korea Testing Laboratory 17 / 23
4.2.2 Architectures and architecture descriptions
Architecture description은 다음의 요소들을 포함한다. (다이어그램의 다이아몬드는
is part of 관계이다.)
1) Architecture viewpoint
2) Architecture view
3) Architecture Rationale
4) Correspondence
5) Correspondence rule

18. ISO 26262 Road vehicles - Functional safety Training by Korea Testing Laboratory
ⓒ-Copyright 2012 Korea Testing Laboratory 18 / 23
4.2.2 Architectures and architecture descriptions
Architecture description은 다음의 요소들을 포함한다. (다이어그램의 다이아몬드는
is part of 관계이다.)
1) Architecture viewpoint
2) Architecture view
3) Architecture Rationale
4) Correspondence
5) Correspondence rule
이를 다른 말로 바꾸어서 표현하면,
Architecture description을 표현하기 위해서는 위의 다섯 가지 요소가
필요하다는 의미가 된다.

19. ISO 26262 Road vehicles - Functional safety Training by Korea Testing Laboratory
ⓒ-Copyright 2012 Korea Testing Laboratory 19 / 23
Architecture view와 Architecture viewpoint간의 관계
- Architecture viewpoint를 이용하여 architecture view를 기술한다.
- Architecture viewpoint는 architecture view를 기술하기 위한 frame이다.
3.5 architecture view
특정 system의 관심 있는 부분(concerns, interest)의 관점에서 system의
architecture를 표현한 work product
3.6 architecture viewpoint
특정 시스템의 관심사항을 기술하기 위한 틀을 잡기 위해
1) Construction convention
2) Interpretation of architecture
3) Use of architecture
을 정립한 work product

20. ISO 26262 Road vehicles - Functional safety Training by Korea Testing Laboratory
ⓒ-Copyright 2012 Korea Testing Laboratory 20 / 23
4.2.2 Architectures and architecture descriptions
Architecture description은 다음의 요소들을 포함한다. (다이어그램의 다이아몬드는
is part of 관계이다.)
1) Architecture viewpoint
2) Architecture view
3) Architecture Rationale
4) Correspondence
5) Correspondence rule
Architecture를 기술하기 위해서는 여러 가지 종류의 architecture view를 필요
로 한다. Architecture view들을 이해하기 쉽도록 구성하기 위해서는
architecture view들 간의 대응 규칙(correspondence rule)을 필요로 하며, 그
규칙에 따라서 문서를 읽어야 stakeholder가 오해하지 않고 쉽게 이해할 수 있
다. 또한 stakeholder에 따라서 관심 있는 architecture view가 다르기 때문에
이를 대응하여야 할 필요도 있다.
Why ?

21. Architecture Viewpoint는
1) 하나 이상의 Stakeholder가 갖고 있는
Concern을 Frame한다.
2) Architecture View를 지배한다.
3) 하나 이상의 Model kind로 이루어져있다.
Architecture view는
1) Stakeholder가 갖고 있는 Concern을 표현
한다.
2) Architecture Viewpoint에 의해 지배된다.
3) 하나 이상의 Architecture Model로 이루어
져있다.

22. ISO 26262 Road vehicles - Functional safety Training by Korea Testing Laboratory
ⓒ-Copyright 2012 Korea Testing Laboratory 22 / 23
3. Terms and definitions
3.9 model kind
conventions for a type of modeling
모델링 하는 타입에 대한 방식
NOTE Examples of model kinds include: data flow diagrams, class diagrams,
Petri nets, balance sheets, organization charts and state transition models.
Data flow diagram은 system의 data의 동적인 흐름관점에서 표현된 기술 방식이다.
Class diagram은 software의 구조에 대해 정적으로 표현된 기술 방식이다.
State transition model은 software의 행동 관점에서 조건에 대한 상태변화를 표현한 기술
방식이다.
각 model kind는 system의 특정 속성에 대한 concern에 대해 기술하기 위한 방식이다.

23. Architecture Description은 다음을 식별해야만
한다.
1) Concern
2) Stakeholder
3) System-of-interest
Architecture Description은 위의 식별된 내용을
바탕으로 Architecture를 표현해야 한다.
Stakeholder는 시스템의 특정 영역에 대하여 관
심을 가지고 있다.
(Ex: 개발자, 유지보수자, 프로젝트 매니저, 테스
터들은 아키텍처의 stakeholder이지만 각기 시
스템에 공통적으로 관심이 있을 수도 있지만,
특정 부분에만 관심이 있을 수 있다.)