[소프트웨어 공학] 유스케이스와 UML

1. 설계의 중요성

소프트웨어(SW) 개발이라는 것은 집을 짓는 것과 같습니다.

집을 짓기 전에 설계도를 그린다는 것은 흔히 알고 있습니다.

왜냐하면 큰 건물을 짓기 위해서는 막대한 자본과 시간 등이 필요하기 때문이고, 중간에 건물구조를 바꾸면서 시공 할 수 없기 때문이죠.

그렇다면 SW 개발은 어떨까요?

구구단을 출력하는 프로그램을 개발한다고 가정해보겠습니다.

이중 for문을 수행하면서 변수명을 바꿔보고, 몇 단까지 출력할 것인지 조건도 바꿔보고 등 자유자제로 코드를 수정할 수 있습니다.

때문에 SW 개발함에 있어서 설계는 필요하지 않아 보입니다.

그러나 구구단 출력 프로그램이 아닌 몇 억원이 오가는 대규모 프로젝트를 개발한다고 가정해보겠습니다.

개발 기한이 정해져 있고 억대의 돈이 오가는 프로젝트에서 설계를 하지 않는다면 어떤 상황이 벌어질까요?

개발 중간 중간에 프로그램 구조를 바꾸고, DB 테이블과 그 관계들을 뒤엎다 보면 그 자체만으로도 큰 손실이며 개발시간이 늦어질 뿐만아니라, 개발을 할 수록 이전 과정이 헷갈리기 시작합니다.

즉 목표를 달성하기 위한 청사진이 없기 때문에 이 프로젝트는 실패할 확률이 매우 높습니다.

또한 고객의 요구사항을 명확히 파악하지 못한다면 고객이 원하는 것이 아닌 엉뚱한 결과를 만들어버리게 됩니다.

설령 개발이 된다 해도 가이드라인이 없이 개발이 이루어졌기 때문에 코드가 엉망진창이 되며, 유지보수가 힘들어집니다.

설계는 이해당사자(고객과 분석가, 개발자)들간의 약속된 문서입니다.

이 문서를 통해서 이해 당사자들이 시스템에 대해 얘기를 나누고, 시스템의 목적을 분명히 합니다.

따라서 설계가 이루어진다면 고객의 요구사항을 명확히 파악할 수 있기 때문에 시스템의 목적을 분명히 할 수 있습니다.

또한 가이드라인이 있기 때문에 개발상황을 파악할 수 있으며, 후에 유지보수를 수월하게 할 수 있습니다.

때문에 SW 개발에서도 설계는 매우 중요하다고 할 수 있습니다.

2. 시스템 개발 과정

1) 프로젝트 계획

프로젝트 수행에 요구되는 모든 활동을 구체화한 청사진을 그리는 것을 말합니다.

이 단계에서는 시스템을 요구한 고객이 무엇을 요구하는지 명확하게 이해를 하는 것이 중요합니다.

2) 요구사항 분석

고객이 요구한 사항들을 분석하는 것을 요구사항 분석이라고 합니다.

고객이 요구한 것이 분석가가 이해한 것과 맞는지 끊임없이 얘기를 해야하고, 그것이 실현이 가능한지, 얼만큼의 시간이 소요되는지 등을 파악해야 합니다.

이 단계에서 구체적인 구현 방법(How to)는 생각하지 않으며 오직 시스템의 목표(What)만을 생각합니다.

또한 이 단계의 산출물 문서는 요구사항 명세서로서 고객과 개발사의 약속 문서로서 앞으로 시스템은 이 문서를 통해 얘기를 하게 됩니다.

따라서 요구사항 명세서는 개발에 대한 지식이 없는 사람도 이해할 수 있을만큼 쉬운 용어로 작성되어야 하며, 용어들을 모호하게 작성하지 않아야 합니다.

3) 설계

요구사항 분석을 통해 시스템의 목표를 확립했으면, 이제 이를 어떻게 구현할 지 결정하는 단계입니다.

예를들면 회원가입이라는 기능을 고객이 요구할 때, 비밀번호 암호화를 어떤 것(MD5, SHA-512, PBKDF2 등)을 사용할지 결정하는 단계입니다.

이 단계의 산출물 문서는 설계 문서입니다.

4) 구현

요구사항 명세서와 설계 문서를 통해 실제로 시스템을 구현하는 단계입니다.

5) 테스트

고객이 요구한대로 시스템이 잘 작동하는지 테스트하는 단계입니다.

또한 테스트는 요구사항 명세서를 통해 이루어집니다.

6) 유지보수

테스트를 마치고 시스템을 관리하는 단계입니다.

이 글에서는 요구사항 분석을 위주로 시스템의 목표가 무엇인지 파악하는 방법에 대해 알아보려고 합니다.

그 방법으로는 모델링, 유스케이스 기법과 UML 기법이 있으며 이제 이것들이 무엇인지 살펴보도록 하겠습니다.

3. 모델링

추상화란 실세계의 모습에서 관심분야를 제외한 나머지를 불완전하게 표현한 것을 의미합니다.

즉 추상화 작업을 통해 현재의 목적과 무관한 부분을 제거하여 시스템을 분석할 수 있도록 도와줍니다.

그 결과로 시스템을 간단한 물리적인 모형으로 표현하는 모델링을 할 수 있습니다.

모델링은 시스템을 어떻게 바라보느냐에 따라 3가지 모델링(정보 모델링, 기능 모델링, 동적 모델링)으로 나뉩니다.

예를들어 정보 모델링은 시스템의 "정보"에 대해서만 바라보아 분석합니다.

기능 모델링은 시스템의 "기능"에 대해서만 분석하며, 여기서 시스템의 "정보"는 중요하지 않습니다.

이것이 바로 추상화의 힘입니다.

추상화는 현재 목적과 무관한 불필요 부분을 제거함으로써 목표에 집중할 수 있도록 도와주는 기법입니다.

1) 정보 모델링

시스템의 변하지 않는 정적인 정보를 포착하는데 집중하여 시스템을 분석하는 것을 말합니다.

예를들어, 인간의 신체기관에는 눈, 코, 입, 팔, 다리 등이 있으며 인간이라는 시스템을 변하지 않는 정보인 신체 부위로 분석한 것이 정보모델링입니다.

정보 모델링은 변하지 않는 것이므로 시스템 개발에 있어 튼튼한 기초를 제공합니다.

2) 기능 모델링

시스템이 어떤 기능을 수행하는가에 초점을 맞추어 시스템을 설명하는 것을 말합니다.

예를들어, 인간이라는 시스템은 눈으로 사물을 보는 기능이 있으며, 코로 냄새를 맡는 기능이 있습니다.

이처럼 시스템이 어떤 기능을 수행하는지 파악하는 것이 기능 모델링입니다.

3) 동적 모델링

시간의 변화에 따라 시스템의 동작과 제어에 초점을 맞추어 시스템의 상태와 상태를 변하게 하는 요인들을 분석하는 것을 말합니다.

예를들어, 인간이 아픔을 인지하는 과정은 다음과 같이 ( 피부 -> 척추 -> 뇌 -> 척추 -> 반응 )등의 일련의 과정을 거칩니다.

이처럼 시간의 변화에 따라 시스템의 상태를 파악하는 것이 동적 모델링입니다.

4. 유스케이스(use case : 사용사례) 기법

유스케이스 기법이란 시스템을 블랙박스로 보고 행위자 입장에서 시스템을 어떻게 사용하는지 분석하는 것을 말합니다.

1) 블랙박스 분석

예를들면 제가 TV의 리모콘을 조종한다고 가정해보겠습니다.

저는 TV의 전원을 눌러서 TV를 켜고, 끄면 되고 채널을 돌리거나 음량을 조절하는 등 리모콘의 조작방법만 알면 됩니다.

제가 리모콘의 버튼을 누름으로써 리모콘 내부의 과정과 그 신호가 TV의 수신부로 전달되는 과정을 알 필요가 있을까요?

아쉽게도 저는 리모콘을 설계하는 사람이 아니라서 이에 대한 관심이 없습니다.

단지 리모콘의 조작방법만 알면되죠.

이것이 블랙박스 분석입니다.

사용자가 시스템의 어떤 기능을 사용(use)할 수 있는지를 파악하며 시스템 내부를 알 필요가 없이 시스템을 외부에서 바라보는 것이죠.

반대로 리모콘이 내부에서 어떻게 동작하는지 파악하는 과정 등은 화이트 분석이라고 합니다.

유스케이스 분석에서는 화이트 분석을 수행하지 않습니다.

2) 행위자

시스템을 사용하는 대상은 여러 부류가 있습니다.

예를들어 제가 네이버 카페를 생성했다고 가정해보겠습니다.

네이버 카페를 사용하는 사람은 저를 비롯한 등급별로 나뉜 회원들과 비회원이 있을 수 있으며, 네이버 직원일 수도 있습니다.

각 부류의 대해서 카페를 접근할 수 있는 권한이 달라지기 때문에 사용(use)할 수 있는 범위가 정해집니다.

이처럼 시스템을 사용하는 객체들을 행위자라고 합니다.

유스케이스를 분석하기 위해서는 행위자를 먼저 파악해야 하며, 각 행위자에 따라 시스템을 블랙박스로 바라보아 시스템의 기능을 파악하는 것이 유스케이스 기법의 목표입니다.

이 그림은 영화 예매 시스템의 유스케이스 다이어그램입니다.

행위자는 고객과 관리자가 있으며, 각 행위자에 따라 수행할 수 있는 기능이 다릅니다.

블랙박스 분석답게 기능의 내부에 대해서는 관심이 없고 행위자가 무엇을 사용할 수 있는지에 대해서만 관심이 있습니다.

3) 유스케이스 시나리오

1), 2)와 같은 방법으로 시스템을 분석하는 것은 기능 모델링을 수행한 것입니다.

이제 각 사용사례에 대해 기능들이 시간에 따라 어떻게 동작하는지, 어떤 정보들을 주고 받는지 등을 파악하는 분석을 수행합니다.

이러한 모델링을 동적 모델링, 정보 모델링이라고 합니다.

유스케이스 시나리오는 행위자가 어떤 사용사례를 수행하기 위한 시나리오를 작성해보는 것입니다.

예를들어, 제가 엘레베이터를 탑승한다고 가정해보겠습니다.

올라가기 버튼 누르기 -> 엘레베이터 문이 열린다 -> 문이 잠시 멈춰있는다 -> 올라가는 층을 누른다 ->문이 닫힌다 -> 엘레베이터가 올라간다 ...

엘레베이터라는 시스템은 이와 같은 과정을 수행할 것입니다.

이처럼 기능에 대한 사용 사례를 알기 쉽게 풀어쓴 것을 유스케이스 시나리오 작성이라고 합니다.

지금 수행하고 있는 요구사항 분석의 결과물인 요구사항 명세서는 기술적인 배경이 없어도 이해할 수 있도록 작성되어야 한다는 것을 기억해주세요. 아래의 시나리오는 이후 시스템 테스트의 절차가 됩니다. 물론 요구사항 명세서의 한 문서가 됩니다.

   

이 시나리오는 영화 예매에서 관리자가 수행할 수 있는 기능인 상영관 등록 유스케이스 입니다.

자바 콘솔창을 기준으로 시스템을 작성했다는 점 참고하시기 바랍니다.

유스케이스의 과정을 표현했습니다.

이 그림은 조금 뒤에 살펴 볼 UML의 V 프로세스의 일부 입니다.

5. UML 기법과 UML의 V프로세스

유스케이스 분석을 통해 시스템을 블랙박스에서 바라보아 분석을 했다면, UML기법은 시스템을 내부에서 바라보는 화이트분석을 수행합니다.

1) 클래스 다이어그램

유스케이스 시나리오에서 밝혀지는 정보들을 통해 시스템이 존재해야 할 클래스들을 식별하고, 클래스의 속성 및 클래스간의 관계를 파악합니다. 클래스 다이어그램을 도출하는 것은 정보 모델링을 수행하는 것입니다.

클래스는 유사한 객체들의 공통된 속성을 모아놓은 추상화 개념입니다.

예를들어 고양이 한마리 한마리를 객체라고 봤을 때 고양이들은 페르시안, 코리안숏헤어, 러시안블루 등의 종으로 나뉩니다.

페르시안 종으로 분류될 수 있는 고양이 객체들은 페르시안 클래스에 속하게 되고, 코리안숏헤어, 러시안블루들도 마찬가지로 각각 클래스가 됩니다.

더 나아가서 페르시안, 코리안숏헤어, 러시안블루 클래스는 고양이라는 클래스가 됩니다.

이처럼 클래스 간에는 부모와 자식간의 관계가 형성되며, 자식 클래스는 부모 클래스의 속성, 기능들을 물려받습니다.

이렇게 클래스로 분류할 수 있는 것은 객체들이 유사한 속성을 지녔기 때문입니다.

또한 클래스에 속하는 모든 객체들은 수행할 수 있는 기능이 같습니다.

( 모든 고양이는 점프력이 높고 냥냥펀치 공격을 합니다. )

따라서 클래스 다이어그램에서는 클래스의 속성과 기능을 명시해줘야 하는데 클래스의 기능은 시퀀스 다이어그램을 수행한 후 다시 이루어집니다.

영화 시스템의 클래스의 속성을 파악하고, 클래스 간의 관계를 다이어그램으로 표현했습니다.

이 다이어그램은 DB 테이블을 설계하는 것과 같다고 보시면 됩니다.

제 배움이 짧아 옳지 못한 분석이 있을 수 있으니 참고만 해주시기 바랍니다.

2) 시퀀스 다이어그램

시퀀스 다이어그램은 클래스를 바탕으로 시스템 내부의 객체들이 상호작용하는 과정을 조사하는 것으로 동적모델링에 해당합니다.

유스케이스 시나리오와 다르게 시퀀스 다이어그램은 시스템 내부에서 클래스들이 어떤 정보들을 주고받는지 분석하는 것이다.

이 때 행위들은 함수로써 표현이 되며, 정보의 입출력은 함수의 매개변수와 리턴값이 됩니다.

아래의 예에서 화살표들은 전부 함수가 됩니다.

     

시퀀스 다이어그램은 유스케이스 시나리오를 참고하여 작성하는 것입니다.

시나리오와 비교하면 동작과정이 같다는 것을 확인할 수 있습니다.

위의 클래스 다이어그램 중 영화클래스입니다.

시퀀스 다이어그램을 수행하면 클래스 다이어그램에 기능을 추가할 수 있습니다.

따라서 클래스 다이어그램의 완성본은 이와 같습니다.

3) 액티비티 다이어그램

액티비티 다이어그램은 객체들 사이의 이벤트에 대한 논리적 처리과정이 존재하거나 업무 프로세스의 상호작용에 대한 추가적인 이해가 필요한 경우 작성하는 다이어그램입니다. 이는 기능모델링에 해당합니다.

위의 3가지 다이어그램 과정을 표현했습니다.

유스케이스 분석을 토대로 다이어그램을 작성하며, 유스케이스 분석과 모델링 순서가 반대입니다.

블랙박스 분석과 화이트박스 분석을 통합하면 위의 그림과 같이 UML의 V프로세스가 됩니다.

고객의 요구사항 분석은 위와 같이 UML의 V프로세스 과정을 통해 요구사항을 분석하며,

최종적으로 요구사항 명세서를 도출할 수 있게 됩니다.

다시 말씀드리지만 요구사항 명세서는 분석과정에서 매우매우 중요한 문서입니다.

이상으로 유스케이스와 UML 기법에 대해 알아보았습니다.

책 한 권 분량을 게시글 한 개로 작성하려니 내용을 많이 축약했음에도 글이 길어졌네요.

글에서 활용된 예제들은 제가 수업들은 소프트웨어 공학 한 학기 과제의 일부입니다.

때문에 많이 부족하며, 틀린 부분이 많이 있을 것입니다....

[ 참고 ]

소프트웨어 공학 에센셜 - 윤청 교수님