UML for automotive s/w architecture_Lecture 1

s/w architecture 개요

s/w architecture 등장 배경

자동차에 들어가는 소프트웨어는 해가 갈수록 양이 방대해지고 있다. 1938년에 폭스바겐의 beetle의 경우 소스 코드가 한줄 도 없지만, 임베디드 C 기반으로 코드의 양이 점차 증가하면서 1985년에는 자동차 한대에 4천만 줄 가량의 코드가 들어갔고 2030년에는 3억라인정도의 코드가 들어갈 것으로 전망되고 있다.

코드의 양이 방대해질 수록 거기서 나타나게 되는 문제는 필연적이게 된다. 갈수록 human error가 나타날 확률이 필연적으로 증가하기 때문이다. 테슬라의 FSD 소프트웨어의 경우 정지해 있는 트럭을 하늘로 오인식 하여 차가 트럭에 그대로 받혀 사람이 사망하는 사건이 일어나는 등 특히 자동차 업계에서 소프트웨어 결함은 사람의 목숨과 직결되는 중대한 사안이라고 볼 수 있다.

따라서 점차 비중이 늘어나고 있는 s/w에 대해 체계적인 설계의 필요성이 대두되고 있으며, 이를 위해 s/w의 architecture 설계에 대한 방법론이 필요해진다.

s/w architecture 설계의 목표

s/w architecture는 s/w system의 functional/non-functional requirement중 non-functional requirement를 충족시키는 것이 핵심이며, 이는 VDA에서도 명시되어 있다. s/w system의 functional requirement와 non-functional requirement에 대한 설명은 다음과 같다.

자동차로 예를 들자면 이동 및 운송수단으로서의 기능은 자동차라면 당연히 수행해야할 functional requirement 에 해당한다. 보통 input을 받아들여 정의된 규칙(rule)에 따라 출력(output)을 만들어내는 단위를 functional requirement로 해석한다. 반면에 non-functional requirement는 요구사항 중 특히 ‘특성’에 관련된 것을 지칭한다고 생각하면 쉽다. 예를 들면 소프트웨어의 유지 보수성 및 안정성 등이 있다. 이러한 특성을 모두 ‘quality attribute’(품질 속성)이라고 하며 이외에도 ‘constraint’(제약사항)도 non-functional requirement에 해당한다. (cycle time은 50ms이내로 한다 등).

non-functional requirement을 충족하기 위한 s/w architecture는 한 개의 형태로 존재하는 것이 아니라 여러가지 형태로 나올 수 있기 때문에 trade off를 고려하여 대안 architecture중 하나를 선택해야 한다. s/w architect 엔지니어는 해당 구조를 선택했을 때 s/w의 risk가 어떤 것인지 파악하여 s/w 개발의 방향성을 잡아야 한다.

s/w architecture의 정의

s/w architecture란 개념의 등장 배경과 목표를 고려해서 내려진 정의는 다음과 같다.

“소프트웨어 아키텍처란 시스템을 추론하는 데 필요한 구조의 집합이다. 이러한 구조는 소프트웨어의 구성요소와 이들 사이의 관계, 그리고 이들 요소와 관계의 속성으로 구성된다.”

여기서 시스템을 추론한다는 것은 시스템의 품질속성(non-functional requirement)이 어떤 지 보는 것이다. 즉, s/w architecture는 functional requirement 보다 non-functional requirement에 더 초점을 두고 정의된 것임을 알 수 있다. s/w system을 구성하는 functional requirement와 non-functional requirement에 대한 설명은 후술하도록 한다.

집합이란 표현은 나올 수 있는 아키텍쳐의 형태가 여러가지 일 수 있다는 것을 의미한다. 따라서 이전에 설명했던 것처럼 대안 architecture 여러 개를 만들고 (보통 이전 프로젝트에서 누적된 경험을 많이 활용하는게 효율적이다.) 거기서 trade off 관계를 따져가면서 평가를 한 뒤 최선의 선택을 하는 편이다.

소프트웨어의 구성요소에는 Class, Function, Interface(정적 측면) Process, Sequence, dataflow(동적 측면), Computers, Devices, Networks(물리적 측면) 등 이있고 이들 사이의 관계, 그리고 이들 요소와 관계의 속성은 static view와 dynamic view를 통해 여러 diagram으로 표현된다. 말그대로 ‘건축물(architecture)’에 비유를 하자면 하나의 건물 을 설계하는데 평면도, 단면도, 건물 배치도와 같이 여러 도면으로 나타내는 것처럼, s/w system도 static 및 dynamic 측면으로 나타낸다는 것이다. 다만 도면에 나타나는 대상이 기둥, 계단, 바닥, 지붕 같은게 아니라 class, function, device 등과 같은 s/w 요소(element)로 이루어져있을 뿐이다. static view는 소프트웨어의 구성요소들의 독립적인 기능을 위주로 정리해 놓은 ‘해부도’로 생각하면 되고, dynamic view는 구성 요소간 상호작용을 위주로 정리해 놓은 도면으로 생각하면 쉽다.

s/w architecture 설계 방법론: Modeling & UML

Modeling

s/w 설계가 어려운 이유는 본질적으로 s/w가 가지는 특성인 모호함(ambiguity) 때문이다. 알고리즘 자체는 목적이 뚜렷한 성격을 지니지만, 사용자의 요구사항을 구현하는 과정에서 사용자의 주관이 투영되기 마련이며, 알고리즘을 이용하여 주관(~한 기능이 빠르게 구현되어야 한다. ~한 데이터들이 손 쉬운형태로 parsing 되어야 한다. ~한 기능이 수행됨에 있어 문제가 없어야 한다 등)이 섞인 요구사항을 해결하기 때문에 s/w는 모호함을 가질 수 밖에 없다.

따라서 s/w architecture를 설계함에 있어 modeling이 필수적이며, model을 적용한다는 것은 모호함을 명확함으로 바꾸는 방법론을 사용한다는 것이다. modeling에는 여러 방식이 존재하며, 예를 들어 functional requirement와 non-functional requirement를 명시하기 위한 모델에는 각각 대표적으로 UseCase diagram, Quality Attiribute Workshop(QAW)가 있다. s/w 개발 프로세스의 경우 waterfall process를 자동차 업계에 맞게 개선시킨 V-cycle도 이러한 모호함을 해소하기 위해 도입된 대표적인 model이다.

UML

개발 프로세스 표준인 ASPICE의 VDA scope은 크게 static/dynamic view 를 사용하여 architecture를 설계할 것을 요구하는데, 이를 UML diagram을 통해 base practice를 만들어야 한다. static 그리고 dynamic view에 맞춘 대표적인 UML diagram은 아래와 같다.

• Structural Diagram(static view)
  • Package Diagram
  • Class Diagram
  • Object Diagram
  • Composite Structure Diagram
  • Component Diagram
  • Deployment Diagram(보통 s/w와 비s/w mapping 관계 설명 시 사용하는 모델)
• Behavioral Diagram(dynamic view)
  • Usecase Diagram
  • Activity Diagram
  • State machine Diagram
  • Sequence Diagram
  • Communication Diagram
  • Timing Diagram
  • Interaction Overview Diagarm