UML for automotive s/w architecture_Lecture 2

s/w architecture 설계 과정

1. Specify software system and context

Context란 어떤 프로젝트의 범위를 가시화 하는 것으로, 보통 모델링에 있어 sysML의 context diagram이 사용된다. 참고로 UML은 system 단위의 specification이 정립된 이후 s/w specification을 목적으로 약속된 언어이다.

Context diagram을 그리는 방식은 따로 어려울건 없고 그저 관심 system에 대해서 소유권이 정립된 형태를 유념하면 된다. 예를 들어 현금인출기(ATM) s/w 로직을 설계하기 위해 architecture를 설계한다고 했을 때, 제일 먼저 context diagram을 통해 ATM과 card reader기, receipt printer, cash tray, keypad display의 기능을 포함하는 것을 명시해 준다.

context diagram을 그린 이후에는 이를 토대로 s/w static diagram을 작성해준다. context diagram의 경우 ATM 시스템이 card reader기, receipt printer, cash tray, keypad display를 포함하는 개념이지만, s/w static diagram의 경우 ATM s/w에 대해서 card reader 기능, 영수증 출력 기능, 현금 인출칸, keypad display는 external input/output에 해당한다.

2. Analyze functional requirements

s/w의 static diagram을 명시했다면, actor와 use case를 구분하여 UseCase Diagram 모델을 통해서 functional requirement를 파악한다. use case란 system이 어떠한 유의미한 산출물(output)을 내도록 하는 action의 sequence로, 예를 들어 ATM s/w의 경우 사용자(actor)가 카드를 넣어(action) ATM기가 bank server와 통신을 통해 PIN넘버를 조회하는(Output) 등의 행위를 말한다.

여기서 모든 use case에 대하여 가능한 모든 시나리오를 도출한다. 이 시나리오 하나하나가 모두 functional requirement가 되는 것이다. 이 과정 중에서 action을 잘게 decompose하는 과정 중에 actor가 추가적으로 명시될 수도 있으며, 너무 많은 시나리오를 줄이기 위해 actor가 제한 될 수 도 있다. 이는 설계자의 역량이며, 한번에 설계가 완료되는 것이 아니라 incremental 하게 시행착오를 거치며 수행되어야 한다.

3. Analyze non-functional requirements - Quality Attributes

Architecture를 설계하기 위해 1.전체 시스템 및 s/w 시스템의 context를 분석하고, 2.funcitonal requirements를 분석하기 위해 use case modeling을 사용했다면, 이제 non functional requirements를 분석하기 위해 quality attribute (품질 속성)을 분석하도록 한다. 참고로 non functional requirements의 경우 크게 quality attribute와 constraint 이 두가지로 나눠지지만, constraint(제약 조건)의 경우 따로 분석할 필요 없이 명백하기 때문에 (예를 들어 sampling time이 x\mathbf{ms}이하) 생략한다.

Quality attribute는 어떠한 특성이라고 생각하면 편하다. 기능성, 응답성, 보안성 등…. 또한 국제 표준으로 그 종류들이 명확하게 정의되어 있다. ISO/IEC 25010 에 따르면 비기능 요구사항에 해당하는 품질 속성은 아래와 같이 분류된다. 각 기능에 대한 설명은 표준 문서를 참고하기 바란다.

• Functional stability (기능 안전성)
• Performance Efficiency (성능 효율성)
• Compatibility (호환성)
• Usability (사용성)
• Reliability (신뢰성)
• Seceurity (보안성)
• Maintainability (유지보수성)
• Portability (이식성)

만약에 ‘사용자가 초록색 버튼을 누르면 선택 대화상자가 나타난다’에 대하여 비기능 요구사항을 분석한다면 아래와 같다. (by chatgpt)

1. 사용성: 초록색 버튼이 사용자에게 적절하게 인식되고, 쉽게 눌러질 수 있도록 디자인되어야 한다.
2. 성능 효율성: 버튼을 눌렀을 때 선택 대화상자가 빠르게 나타나야 한다. 또한, 대화상자가 빠르게 나타나야 한다.
3. 안정성: 선택 대화상자가 예기치 않게 종료되거나 오류가 발생하지 않도록 안정성이 보장되어야 한다.
4. 호환성: 초록색 버튼과 선택 대화상자는 다양한 환경에서도 동작할 수 있도록 플랫폼 호환성을 보장해야 한다.
5. 보안성: 민감한 정보를 입력하는 경우, 이를 적절하게 암호화하고 보안성을 확보해야 한다.

chatGPT에 의해서 멋지게 비기능 요구사항이 요약되었지만, 위 결과는 반쪽자리이다. 왜냐하면 비기능 요구사항이 측정가능한 상태로 정의되지 않았기 때문이다. 위 결과는 아직 모호함이 남아있다. 예를 들어 1. 사용성: 초록색 버튼이 사용자에게 적절하게 인식되고, 쉽게 눌러질 수 있도록 디자인되어야~ 나, 2. 성능 효율성: 버튼을 눌렀을 때 선택 대화상자가 빠르게 나타나야 한다 에서 볼 수 있듯이, 측정가능하지 않은 표현은 최대한 배제해야 한다.

따라서 품질 속성들을 측정 가능한 형태로 변환시켜야 하며, 보통 Quality Attribute Scenario(QAS)를 사용한다. 이는 기능 요구사항을 뽑아낼 때 use case를 통해 scenario를 뽑아내는 것과 같은 맥락이다. QAS는 아래와 같이 6개의 요인으로 품질속성을 분해하는 것이다.

• Stimulus: System에 적용되는 조건들
• Response: Stimulus 결과 반영되는 결과들
• Source: Stimulus를 발생시키는 원인
• Environment: Stimulus가 발생할 때 연계되는 외부 조건들
• Artifact: Stimulus에 의해 영향 받는 산출물들
• Response Measure : System에 반영되는 결과를 수치화 하는 지표

예를 들어 1. 사용성의 경우 ‘웹사이트 유입 사용자들에 대해서 초록색 버튼에 대해서 user interface 설문을 돌렸을 때 ‘만족스럽다’라는 답변이 전체 설문조사 중 70% 이상이 나오고, 눌려진 횟수가 전체 방문 수 대비 50%가 나오도록 디자인 되어야 한다’ 정도로 바뀌어야 한다. Stimulus는 웹사이트 방문, Response는 출력되는 GUI 화면, Source는 각 사용자의 다양한 유입경로, Environment는 초록색 버튼과 함께 출력되는 다른 GUI 환경, Artifact는 GUI 버튼들의 클릭 수, Response measure는 클릭 수 및 만족도로 설정된 것이다.

• 참고로 비기능 요구사항과 기능 요구사항을 합쳐 관용적으로 architectural driver라고 부른다.
• 전체 s/w 시스템이 간단하여 functional requirements들만 만족하는 거로도 충분했던 과거에는 비기능 요구사항이랄게 따로 없었다. (예를 들어 코드 몇 십줄로 끝나던 간단한 시스템) s/w에 architecture 개념이 정립되기 시작한 것은 규모가 방대해지면서 non-functional requirements를 만족시킬 필요성이 대두되고 나서부터였다.

4. UML을 활용한 static/dynamic view 표현

지난항목에서 건물의 설계도를 평면도, 배치도 등 다양한 방면으로 표현하는 것 처럼, s/w architecture 역시 하나의 설계도로는 표현하지 않고 크게 static/dynamic view로 표현한다. 하나의 관점에서 표현할 수 있는 방식 또한 여려가지 인데, 이는 여러 stakeholder(이해 관계자)들의 요구사항에 적합한 설계도가 하나로 정해져 있지 않기 때문이다.

Static Modeling

Static view를 표현하기 위해 모듈을 decompose하는 방식은 아래와 같이 s/w 구성요소를 stereotype이 부여된 형태로 나누는 것이다.

1. Boundary Object: Boundary Object는 interface와 관련이 있다. 사용자와 직접 맛닿는 곳이나 모듈간 Input/output을 교환 하는 곳, 그리고 외부 시스템(external system)과 맛닿아 있는 곳은 따로 proxy라고 부르기도 한다.

2. Entity Class: Entity는 쉽게 말해서 데이터로, s/w system이 프로그램을 수행하기 위해 중간에 저장해야 할 데이터들의 모음을 말한다.

3. Control Class & Objects: Control은 s/w system이 프로그램을 수행하는데 있어 모든 과정을 총괄하는 coordinator를 말한다. 모든 기능 모듈을 호출하는 main module이 control을 담당한다고 볼 수 있다.

4. Application logic Classes & Objects: Application logic은 말그대로 정해진 기능을 수행하는 로직과 관련된 것으로, 탐색, 정렬과 같이 최적화와 관련된 algorithm object, client에 별도로 요청을 받은 service object, 그 외에 일반적인(generic)한 business logic object로 구분된다.
   

소프트웨어 아키텍처의 다양한 Static Modeling 방법들이 있지만, 대표적인 것들은 다음과 같다.

• 클래스 다이어그램(Class Diagram)

  클래스 다이어그램은 객체 지향 프로그래밍에서 가장 많이 사용되는 Static Modeling 방법으로,클래스, 인터페이스, 연관관계, 상속관계 등을 나타내는 다이어그램이다.

• 객체 다이어그램(Object Diagram)

  객체 다이어그램은 클래스 다이어그램에서 정의된 클래스의 인스턴스를 표현한다. 객체 다이어그램은 클래스 다이어그램으로부터 얻어진 정보를 바탕으로 구체적인 객체들의 상호작용을 설명하는 데 사용된다.

• 컴포넌트 다이어그램(Component Diagram)

  컴포넌트 다이어그램에서는 시스템을 구성하는 다양한 컴포넌트 간 인터페이스, 의존관계 등을 표시한다. 여기서 컴포넌트란 실행 가능한 s/w 모듈로, 독립적으로 개발되어 특정 기능을 수행하거나 특정 서비스를 제공하는 단위로 구분한다. 보통 컴포넌트는 재사용 가능하며, 다른 s/w 시스템에서도 사용할 수 있다.

• 패키지 다이어그램(Package Diagram)

  패키지 다이어그램은 시스템을 구성하는 패키지들과 패키지 간 의존관계 등을 나타낸다. 여기서 패키지란 일반적으로 관련된 기능이나 서비스를 제공하는 컴포넌트끼리 구성된 ‘묶음’을 말한다.

• 배치 다이어그램(Deployment Diagram)

  배치 다이어그램은 시스템의 구성 요소들이 물리적인 장비에 어떻게 배치되는지를 보여주는 다이어그램이다. 배치 다이어그램은 논리적인 시스템 구조와 물리적인 시스템 구조 간의 관계를 설명하는 데 사용된다.

• 앞서 수행한 use case modeling과 sequence diagram 등을 참고하며 static modeling을 수행하며, 결과에 따라 다시 use case modeling이나 sequence diagram을 수정할 수 있다. (상호 보완적인 trial-and-error 과정 수행)

Dynamic Modeling

소프트웨어 아키텍처에서 Dynamic Modeling은 시스템의 동작을 모델링하는 방법으로, Dynamic Modeling은 소프트웨어의 실행 흐름과 상호작용, 상태 변화 등을 포착하기 위해 사용된다. 대표적인 Dynamic Modeling 방법으로는 다음과 같은 것이 있다.

• 유즈케이스 다이어그램(Use Case Diagram)

  유즈케이스 다이어그램은 시스템의 사용자와 시스템 간의 상호작용을 모델링하는 방법으로, 이전 포스트에서 설명했듯이 s/w system의 functional requirement를 분석하는데 주로 사용되는 방식이다.

• 순서도 다이어그램(Sequence Diagram)

  순서도 다이어그램은 객체들 간의 메시지 교환을 그래픽으로 나타내는 방법으로, 순서도 다이어그램은 객체 간의 상호작용과 시스템의 동작 흐름을 이해하는 데 사용된다. 보통 객체 간 메세지 전송 순서와 타이밍이 표현되어 있다.

• 활동 다이어그램(Activity Diagram)

  활동 다이어그램은 시스템의 동작 흐름을 그래픽으로 나타내는 방법으로, 프로세스의 동작과 상태를 기술하는 데 사용된다. 객체간 상호작용에 중점이 있는 순서도 다이어 그램과는 달리, 활동 다이어그램은 시스템이 수행하는 작업의 흐름을 중심으로 표현한다.

• 상태 다이어그램(State Diagram)

  상태 다이어그램은 객체의 상태 변화를 모델링하는 방법으로, 시스템의 동작과 객체 간의 관계를 설명하는 데 사용된다.

• 커뮤니케이션 다이어그램(Communication Diagram)

  커뮤니케이션 다이어그램은 객체 간의 메시지 교환을 그래픽으로 나타내는 방법입니다. 커뮤니케이션 다이어그램은 객체 간의 상호작용과 시스템의 동작 흐름을 이해하는 데 사용된다.