ㅁ 웹상으로 바로 하려면 https://app.diagrams.net/
[01 UML 개요]
[02 StartUML5 설치]
[03 요구사항 개념]
[01 UML 개요]
ㅁ 유스케이스, 클래스, 시퀀스 다이어그램
- 이 외에도 더 많은 다이어그램이 존재하지만, 실무에서는 이렇게 3가지 정도를 주로 사용한다.
- 실무에서 어떤 프로젝트냐에 따라서 세 개 중에 두 개의 다이어그램을 사용하는 경우도 있고,
PM(프로젝트 팀장)의 성향에 따라서 아예 생략하는 경우도 많다.
ㅁ 학생들이 모델링 관련된 수업을 들으면서 항상 힘들어하거나 어려워하는 부분이 내가 만든 결과물이 정답인가? 틀렸나? 맞다 아니다를 생각하는 것이다.
- 모델링이란 정답이 없다. 모델링은 각자 생각하는 바에 따라 다르게 표현된다.
다만 권장하는 모범 답안이 존재할 뿐이다.
ㅁ 모델링 Modeling
- 말 그대로 모델을 만드는 작업을 뜻함.
즉, 현실 세계를 단순화 시켜서 표현하는 기법이다.
- 현실 세계를 단순화시켜서 코드나 프로그램으로 구현하기 위해 모델링을 통해 모델 작업을 한다.
ㅁ 건축과 마찬가지로 프로그램도 개발하기 앞서서 기본적인 틀을 만들어야 한다.
- 여러 개발자들 그리고 그 프로그램을 의뢰한 고객사가 함께하는 공동작업이기 때문에 모델링 작업은 필수적이다.
- 그런데 실제로 실무에서 직접 모델링 작업을 하진 않는다.
팀장급 되는 사람들이 보통 설계, 분석 이런 모델링을 맡아서 한다.
우리들은 팀장급 즉 PM이 작성한 모델링 결과물들을 보고 개발(구현)을 할 줄 알아야 한다. 즉 볼 줄 알아야 한다.
- 또 회사마다 다르지만 신입끼리 팀을 꾸려서 작은 프로젝트를 만들어봐라하는 경우도 간혹 있다.
이때는 여러분들이 직접 모델링을 진행해야 한다.
ㅁ 모델링의 역사
- 초기 모델링 기법은 절차지향 모델링 기법을 사용했다.
- 자바는 객체지향.
절차지향은 흐름을 중심으로 생각한다.
객체지향은 객체를 중심으로 생각한다.
객체지향이라고 해서 흐름을 무시하는건 아니고, 흐름을 생각하기 전에 객체를 먼저 생각하고 흐름을 생각한다.
- 객체지향 언어가 붐이 일어나면서 자바가 많이 사용되었다.
객체지향 언어로된 프로그램을 모델링해야 하는데 절차지향 모델링 기법은 한계가 있어서 객체지향 모델링 기법이 등장했다.
- 그런데 사람들마다 표기법이 너무 다양해서 호환성 문제가 발생했다.
그래서 공통적인 표기법을 만들자해서 나온게 UML이다.
ㅁ UML
- 통합 모델링 언어(UML, Unified Modeling Language)는 소프트웨어 공학에서 사용되는 표준화된 범용 모델링 언어다.
- 소프트웨어 개념을 다이어그램으로 그리기 위해 사용하는 시각적인 표기법이다.
ㅁ UML의 필요성
(1) 의사소통에 좋다.
- 개발할 시스템의 기능이 어떤 것들인지, 시스템 내부 구조는 어떤지에 대한 다양한 형태들의 모델들을 가시화시킴으로써
고객사와 개발자들 간의 의사소통을 원활하게 해줄 뿐만 아니라 요구 사항에 부합한 시스템을 개발할 수 있도록 해준다.
(2) 대규모 프로젝트 구조의 로드맵을 만들 때 유용하다.
- 로드맵을 통해 클래스와 클래스 간의 의존하는 관계 등등을 개발자가 빨리 파악할 수 있다.
(3) 개발할 시스템 구축에 대한 기초를 마련할 수 있다.
- 모델링 단계에서 만들어낸 산출물을 통해 CASE 도구에서 소스코드 생성 기능같은 것들을 제공한다.
ex) 우리가 만든 클래스 다이어그램을 통해 소스코드를 바로 뽑아낼 수 있다.
- 로직이나 일부 내용만 수정하면 되기 때문에 구현 시간을 단축시킬 수 있다.
(4) 백엔드 문서용으로 좋다.
- 프로젝트를 진행하다가 다른팀에 넘기는 경우 이어서 맡은 팀이 유용하게 사용할 문서를 만들 수 있다.
따라서 분석, 설계 단계에서 모델링을 끝내는게 아니라 구현할 때, 구현을 마쳤을 때도 틈틈히 수정하는 작업을 하는 것이 좋다.
ㅁ UML 작성 시 주의할 점
(1) 핵심적인 기능 위주로 작업할 것 (행위를 가장 우선적으로 작업해라)
- 위와 같이 다이어그램을 복잡하게 그리면 모델링 작업도 힘들 뿐더러 다른 사람이 알아보기도 어렵다.
(2) 반복을 통해 다듬을 것
- 분석, 설계 단계에서 UML을 통해 모델링 했다고 해서 끝이 아니라 구현 하면서도 발생하는 수정 사항들을 반복을 통해 다듬어야 한다.
(3) 코드를 마음속에서 그려볼 수 있는 힘이 중요
- 내가 생각한 아이디어를 코드로 작성하지 않고 간결한 그림으로 표현하기 위해 모델링 작업을 하는 거지 다이어그램으로 코드를 대신하려는 것이 아니다.
- 모델링 후 다이어그램을 딱 봤을 때 코드가 머릿속에 그려지지 않는다면 잘못된 모델링이다.
ㅁ UML 표기법으로 그릴 수 있는 다이어그램들은 종류가 엄청 많다.
- 크게는 정적이냐 동적이냐로 나뉜다.
- 동적 다이어그램은 행위(기능) 위주다. 움직임이 있다는 것.
- 정적 다이어그램은 말 그대로 정보 그대로를 표현하는 다이어그램이다.
- 클래스 다이어그램 : 프로그램 안의 주요 클래스와 주요 관계를 보여주는 다이어그램.
- 유스케이스 다이어그램 : 시스템과 사용자가 상호작용하는 경우를 나타내는 기능 위주의 다이어그램.
- 시퀀스 다이어그램 : 기능뿐만 아니라 시간 흐름에 따른 객체 사이의 상호작용을 표현하는 다이어그램.
ㅁ 클래스 다이어 그램
- 클래스 다이어그램 : 프로그램 안의 주요 클래스와 주요 관계를 보여주는 다이어그램.
- 3칸으로 나뉘어 있다. 클래스명, 변수명, 메소드명.
- 각 클래스마다 어떤 관계들이 있는지를 표현한다.
- 클래스 다이어그램을 토대로 소스코드를 뽑아낼 수 있다.
이 클래스를 구현하기 위해서 처음부터 끝까지 코드를 다 칠 필요가 없다.
메소드들 내부의 로직만 채우면 된다.
ㅁ 유스케이스 다이어그램
- 유스케이스 다이어그램 : 시스템과 사용자가 상호작용하는 경우를 나타내는 기능 위주의 다이어그램.
- 이 프로그램의 사용자들.
- 각 사용자마다 사용하는 기능들을 동그라미 안에 작성한다.
- 이 유스케이스 다이어그램을 가지고 고객사와 의사소통을 한다.
ㅁ 시퀀스 다이어그램
- 시퀀스 다이어그램 : 기능뿐만 아니라 시간 흐름에 따른 객체 사이의 상호작용을 표현하는 다이어그램.
[02 StartUML5 설치]
ㅁ UML 툴 설치
- 5.0 버전 말고 최신버전 다운로드
- UML을 통해서 모델링을 하기 위해 사용할 프로그램.
- StarUML은 UML 모델링 툴 중 가장 대중적인 프로그램이다.
대부분의 사람들이 UML할 때 StarUML을 사용한다.
- 그런데 UML도 버전별로 사실상 표기법이 다르다.
UML이 1 버전에서 2 버전으로 바뀌면서 표기법이 상당 부분 바뀌었다.
2 버전으로 진행한다.
- StarUML은 UML 1.4버전에 기반을 두고 2.0 버전의 표기법도 적극 지원한다.
- 5.0버전. Tools - Java - Generate Code를 클릭하면 Java Profile has not included라는 오류창이 뜬다.
- 자바 프로파일을 추가. Model - Profiles...를 누르고 자바 프로파일을 클릭하고 include하고 close하면
이제 클래스 다이어그램 작업할 때 Generate Code 기능을 사용할 수 있다.
이거는 클래스 다이어그램에서 테스트해본다.
ㅁ Model Explorer
- untitled는 이름을 Properties에서 Test로 바꿨다.
- 그리고 우클릭해서 "add" - "model".
이렇게 생성된 model 폴더는 작업으로 나오는 다이어그램(산출물)들을 보관하는 폴더다.
model 폴더 이름을 TestModel로 바꿨다.
- TestModel 폴더 우클릭 - "add diagram"하면 다이어그램을 만들 수 있다.
"usecase diagram"을 클릭한다.
ㅁ
- usecase 동그라미는 행위를 뜻한다.
[03 요구사항 개념]
ㅁ 프로세스별 다이어그램
- 프로그램을 개발하기에 앞서 어떤 진행절차로 이루어지는지에 대해 살펴본다.
- 여러분이 실무에 투입될 때는 구현 단계를 맡게 된다.
구현 전 단계들은 PM이 진행한다.
- 요구사항 부터 프로그램 설계까지를 모델링 단계라고 한다.
- 모델링 단계에서도 각각 사용되는 다이어그램이 다르다.
- 1~3단계 모든 단계를 통틀어서 패키지 다이어그램을 사용한다.
- 요구사항 단계에서는 유스케이스 다이어그램만을 사용한다.
- 분석, 설계 단계에서는 저 5개 다이어그램을 사용한다.
그런데 분석에서 사용하는 다이어그램과 설계에서 사용하는 다이어그램들은 사실상 모양이 다르다. 다르게 구현된다.
(클래스, 시퀀스 다이어그램은 설계 단계에 초점을 맞추어 진행한다)
- 그리고 설계 단계에서는 저 4개 다이어그램을 추가로 사용한다.
- 상호작용 다이어그램 안에 시퀀스 다이어그램이 있다.
ㅁ UML의 V 프로세스
- V 모델은 소프트웨어 공학에서 많이 사용되는 모델이다.
여기서의 V 모델은 프로그램 분석-설계 단계(모델링 단계)에서의 V 모델이다.
- V 모델은 이 외에도 많은 곳에서 사용된다.
- 행위자부터 요구사항 명세서까지의 전체적인 흐름(과정)을 한 눈에 파악하기 쉽다.
- UML에서의 V 모델은 크게 블랙박스 분석(사용자 관점), 화이트박스 분석(시스템 관점)으로 나뉜다.
- 블랙박스 분석은 개발하고자 하는 프로그램을 실제로 사용하는 사용자의 관점으로 분석하는 단계다.
사용자가 이 프로그램을 이용할 때 어떤 기능을 사용할 수 있는지 등.
- 화이트박스 분석은 사용자의 관점이 아니라 시스템 내부적으로 돌아가는지 코드는 어떻게 구성되는지를 분석하는 단계다.
- 기능 모델링과 동적모델링이 동적 모델링이다. 정보 모델링이 정적 모델링이다.
- 기능 모델링은 기능 위주 모델링을 하는 경우, 거기에 시간의 흐름이 추가되면 동적 모델링이다.
- 여러분들은 UML 모델링을 진행하면서 먼저 행위자(사용자) 관점에서 기능 모델링인 유스케이스 모델링 작업을 한다.
- 유스케이스 모델링 작업에서 도출된 유스케이스 모델을 통해서 유스케이스 별로 시나리오를 작성하는 동적 모델링 작업을 진행한다.
유스케이스 시나리오에서는 이 기능을 할 때 정상적으로 진행됐을 때, 예외가 발생했을 때 어떻게 흘러가는지, 사용자가 어떤 선택을 하냐에 따라서 어떻게 흘러가는지에 대해서 나타낸다.
- 유스케이스 시나리오에서 도출된 정보들이 해당된다.
유스케이스 시나리오의 정보를 이용해서 클래스, 시퀀스 다이어그램을 만든다.
- 액티비티 다이어그램은 유스케이스 시나리오에서 정상적으로 흘렀을 때가 아니라 어떤 예외가 발생했을 때, 사용자가 어떤 선택을 하냐에 따라서 그런 흐름들을 표현한다고 했었죠. 그래서 이런 예외 흐름이나 선택 흐름에 해당되는 제어흐름들을 나타내는게 액티비티 다이어그램이다.
액티비티 다이어그램을 최종적으로 하고 요구사항 명세서를 기록하게 된다.
- 액티비티 다이어그램으로 할 필요 없이 시퀀스 다이어그램에서도 제어 흐름을 나타낼 수 있다.
실무에서도 시퀀스 다이어그램에서 제어흐름을 나타낸다. 그래서 시퀀스 다이어그램까지 진행한다.
ㅁ 요구사항
- 요구사항은 시스템 개발에 앞서 고객과 소프트웨어 개발 관련자들이 개발될 프로그램에 대해 정의하는 조건이나 기능을 말합니다. - 시스템이 수행해야 할 작업, 필요한 성능, 제한사항 등을 포함하며, 성공적인 시스템 개발을 위해 명확하게 정의되고 이해되어야 합니다.
- 요구사항을 통해서 시스템이 어떤 기능을 제공해야 하는지를 표현한다.
- 프로젝트 전에 참조해야 할 절대적인 이정표.
ㅁ 요구사항 유형
ㅁ 요구사항 프로세스
- 요구사항도 진행절차가 있다.
- 요구사항 추출 : 고객사와 시스템 사용자, 시스템 개발과 관련된 당사자들과 미팅, 인터뷰를 통해서 의사소통해서 실제로 개발하고자하는 시스템에 대한 요구를 찾아내는 과정이다.
- 요구사항 분석 : 소프트웨어 환경을 분석하고, 전 단계에서 추출한 요구사항들이 적절한 요구사항인지 분석한다.
그래서 그걸 토대로 유스케이스 다이어그램을 작성하는 과정을 거친다.
우리는 요구사항 분석 단계를 통해 유스케이스 다이어그램을 만드는 과정을 진행한다.
- 요구사항 명세 : 본격적으로 요구사항 명세서를 작성한다.
요구사항이 요구사항 조건에 부합하는지를 판단하는 단계이다.
분석단계에서 그려진 유스케이스 다이어그램을 통해 각 유스케이스별로 어떤 사용자가 어떤 기능을 하는지, 예외가 발생했을 때는 어떻게 처리할 것인지 등을 보고서 형태로 처리한다.
- 요구사항 검증 : 프로그램을 의뢰한 고객사와 함께 검토를 한다.
객관성을 확보하기 위해 제 3자의 입장도 같이 자리하게 되어 검토를 한다.
검증단계에서 별 문제없이 통과되면 요구사항 단계는 끝난다.
그리고 분석, 설계 단계로 들어간다.
- 요구사항 유지보수 : 검증단계에서 통과되지 않고 뭔가 피드백이 있다면 유지보수 단계로 들어가 다시 요구사항 추출부터 모든 과정을 반복적으로 진행한다.
ㅁ 요구사항 조건
(1) 명확성
- 기술된 요구사항은 항상 동일한 의미로 해석되어야 한다. 모호하지 않아야 한다.
(2) 완전성
- 사용자가 기대하는 모든 요구사항이 기술되어야 한다. 누락되어서는 안 된다.
ex) 도착했을 때만 메시지를 보내지 않고 도착하지 않고 있을 때도 메시지를 보낸다.
(3) 일관성
- 서로 상충되는 요구사항이 있어서는 안 된다.
(4) 검증 가능성
- 객관적으로 검증할 수 있도록 구체적이어야 한다.
ex) "빨리"가 어느 정도인지.