[소프트웨어공학] 9. Modeling Concept

지금까지 소프트웨어 공학의 중요성 및 주요 개발 프로세스 모델들의 특징과 객체 지향 개념에 대해서 정리하였다.

이번 글부터는 '요구사항 분석 - 설계 - 구현 - 검증 - 유지보수' 단계에서 요구사항 분석, 설계, 검증에 대한 내용을 자세히 정리한다.

 

먼저 요구사항 분석에 앞서 요구사항을 분석한 내용을 기반으로 다이어그램을 그릴 필요가 있기 때문에, '모델' 과 '다이어그램' 에 대해서 간단히 정리해보려고 한다.

 

모델

모델은 현실 또는 상상의 무언가를 표현하는 것을 말한다.

이때 모델이 유용하려면 아래로 내려갈수록 디테일하게 적절히 계층적 구조로 묘사되어야 하고, 현재 task에서 중요한 부분을 잘 나타내어야 한다.

지금은 소프트웨어 공학을 보고 있으므로 소프트웨어 시스템을 모델로 표현하게 되는데, 대부분의 소프트웨어 시스템 모델은 '다이어그램'  형태로 표현한다.

 

 

다이어그램

다이어그램은 현실 속 존재나 행위를 추상화된 그림으로 표현한 것을 말한다.

다이어그램은 정해진 규칙이나 표준을 지켜야 하며, 이 규칙이나 표준은 서로 다른 사람들이 봐도 동일한 방식으로 이해할 수 있도록 정해야 한다.

 

세탁과 관련된 다이어그램

 

다이어그램은 새롭게 떠올린 아이디어나 가능성을 정해진 방식으로 표현하여 누구나 해당 아이디어를 같은 방식으로 이해할 수 있도록 하는 것이 사용 목적이다. 아이디어의 구조나 관계같은 세부적인 내용들을 다이어그램으로 표현하고, 이를 기반으로 아이디어가 괜찮은지 테스트하고 예측할 수 있다.

 

책을 출판하는 과정을 나타낸 다이어그램

 

예를 들어 책을 출판하는 과정을 위와 같이 액티비티 다이어그램으로 표현할 수 있다.

저자가 챕터 내용을 작성하면, 리뷰어가 챕터를 리뷰하고, 각각의 챕터를 수정하기를 반복한다.

이때 다이어그램은 마치 객체지향에서 캡슐화하듯, 구체적인 내용을 숨긴다.

 

 

예를 들어 '챕터를 작성한다' 라는 부분을 들여다보면 해당 챕터의 내용을 어떻게 작성할 지 계획을 세우고, 초안을 작성하고 만족할 때까지 계속 수정한 뒤, 예제를 추가하고 참고 문헌을 추가하여 마무리한다.

하지만 이런 자세한 과정을 액티비티 다이어그램에 적지 않는다.

오히려 그런 디테일한 내용들 때문에 전체 흐름을 파악하는데 방해가 되기 때문이다.

 

그래서 다이어그램을 통해 모델링을 할 때도 '계층적으로' 세부 사항을 나눠서 표현해야 한다.

자세하게는 다음과 같이 모델링을 해야 한다.

 

1. simple

최대한 단순하게 표현해야 한다.

 

2. completeness

하지만 빠진 부분없이 완전하게 표현해야 한다

 

3. internal consistency

내부적으로 일관되어야 한다.

같은 개념을 표현할 때는 같은 방식으로 표현해야 한다.

이를 위해 보통 다이어그램을 그리는 툴을 활용한다.

 

4. hierarchical representation

큰 시스템을 잘게 나눠서 디테일한 부분은 아랫 계층에서 자세하게 표현해야 한다.

 

 

UML

unified modeling language 의 줄임말로 소프트웨어 시스템을 시각적으로 모델링할 때 사용하는 비주얼 언어를 말한다.

객체지향적인 관점에서 모델링하는데 사용한다.

물론 UML 을 사용하지 않고 c와 같은 절차지향 프로그램을 모델링할 수 있다.

UML은 모델링하는 한 가지 방법일 뿐이다.

 

 

UML 에서 사용하는 다이어그램은 이렇게 분류된다.

분류를 제외하고 실제 다이어그램만 세면 leaf node 만 세서 14가지의 다이어그램이 있으나, SW를 설계할 때는 class diagram, use case diagram, sequence diagram 또는 communication diagram 이 최소한으로 필요하고 나머지는 필요한 상황에서 그린다.

(시퀀스 다이어그램과 커뮤니케이션 다이어그램을 둘 중 하나만 그리면 나머지 다이어그램은 툴로 변환해서 어렵지 않게 그릴 수 있다.)

 

UML은 소프트웨어를 설계할 때 사용하는 유용한 '도구' 이다.

따라서 다이어그램을 그리려면 어떻게 그려야 하는지 아는 것보다, 다이어그램을 통해서 어떻게 소프트웨어를 설계하는지 이해하는 것이 중요하다.

 

다음 글에서는 요구사항을 분석하고, 분석한 내용을 기반으로 use case diagram을 그리는 과정을 따라가본다.