UML v1.1 개념-Development Process

3.   Development Process

 

3.1.         개발 프로세스(Development Process)와 UML

: 우리는 UML의 전체구성과 세부내용을 언급 전에 개발 프로세스를 먼저 알아보아야 할 것이다. 먼저 개발 프로세스를 언급하는 이유는 UML이 위에서 언급했듯이 방법론이 아니고 방법론에 따르는 설계 시 사용되는 언어일 뿐이라는데 있다.. 그러므로 하나의 방법론을 적용하여 언제 어디에 사용되는지 알아봄으로써 UML의 이해를 도울 수 있을 것이다.

 

3.2.         구성

: Requirement Analysis(요구분석) -> Analysis(분석) -> Design(설계) -> Implementation (구현)-> Test(테스트) Development process의 구성은 대략 위와 같으며 이는 내용에 따라 구성된 것이다.

물론 여기에도 순서가 존재하고 순서에 맞게 진행되어야 한다.

그림 75 개발 Water Fall

 

 

3.3.         요구분석(Requirement Analysis)

: 요구분석은 말 그대로 사용자의 요구를 알아보는 것이다. 개발 초기에 용역을 맏기는 고객의 요구를 충분히 알기 위해 그리고 이러한 요구를 구축할 시스템에 충분히 반영하기 위하여 요구분석의 단계가 필요하고 이것의 문서화가 필요하다. 이 단계는 또한 고객과 공급자간의 마찰이 생길 때 이를 해결하기 위한 자료로써도 사용되어진다. 이러한 요구분석의 결과물로는 시스템에 요구하는 기능을 적어놓은 일반적인 문서가 된다.  UML에서의 Use Case Diagram과 간단한 Class Diagram 그리고 Activity Diagram으로 표현이 되어진다.

 

3.4.         분석(Analysis)

: 분석의 단계에서는 실제 풀어야 할 문제에 대한 분석을 필요로 한다. 하지만 이러한 분석에서 세부적인 기술(implementation)이나 특정 기술(technic)은 배제하고 실 세계의 존재물에 해당하는 모델들(classes, objects, interaction)에 관한 것이다.

 

분석단계에서 행하여지는 일들을 간단히 소개하면 다음과 같다.

 

n  해결 해야 될 문제의 영역에 대한 지식을 얻어야 한다. 이 지식은 기존 시스템의 기술(description), 사용자와의 대화, business process, term catalog, 같은 문제를 가지고 다른 팀. . 등등에서 가져올 수 있다.

n  적당한 클래스들의 후보(candidate)들을 찾아야 한다. 이 과정에서 brainstorming이 필요하며 이 과정이 끝난 후 모든 후보들에 대한 다시 한번 심각한 고찰이 필요하고 여기서 필요 없는 클래스가 생략되게 된다.

n  클래스들 사이의 정적인 관계가 모델링 되어진다. 예를 들어 association, aggregation, generalization, dependencies등으로 관계들이 표현되어진다.

n  오브젝트들 사이의 행위(behavior)와 협력(collaboration)등을 state diagram, collaboration diagram, sequence diagram, activity diagram으로 표현되어진다.

n  모든 다이어그램이 완성되면 종이에 시스템을 실행시켜보는 방법으로써 다시 한번 검증하는 것이 필요하다.

n  기본적인 user interface의 Prototype을 만들어야 한다.

 

결과적으로 분석의 단계에서 나오는 결과물로 UML에서는 class diagram, sequence diagram, collaboration diagram, state diagram, activity diagram이 나오게 된다.

 

3.5.         설계(Design)

: 설계 단계는 분석 단계의 결과물에 기술적인 부분을 첨가하여 확장하는 것이다. 기술적인 확장이란 시스템을 어떻게 구현(implement)할 것인지에 촛점을 두고 어떻게 동작하고 어떤 제약이 있어야 하는지에 관하여 생각하는 것이다. 이와 같이 설계 단계와 기술적인 하부구조를 분리하는 것은 분석 단계에서 만들어진 결과를 되도록이면 변화시키지 않고 유지하면서 하부구조를 좀 더 쉽게 변화시키거나 발전시킬 수 있도록 하기 위함이다.

 

설계단계에서 실제 일어나는 일은 다음과 같다.

n   분석단계에 나온 클래스들에서 기능적 패키지(functional package)들을 분리시킨다. 예를 들어 user interface, database handling, communication을 위한 패키지가 분석단계에서 나온 클래스들에 포함되어 있다면 기능적 패키지로 분리 시키고 없다면 첨가 시킨다.

n  동시성을 가진 행위의 경우 공유되는 자원에 대하여 active classes와 비동기적 메시지(asynchronous messages), 동기화 기술(synchronization technique)을 가지고 모델링 되어야 한다.

n  시스템의 출력에 해당하는 형식이 정해져야 한다. 시스템의 출력은 user interface, 기록, 다 른 시스템과의 통신등과 같은 것이다

n  필요한 외부 클래스 라이브러리나 컴포넌트를 명시하여야 한다

n  시스템에서 예상되는 예외(exception)상황에서의 에러처리를 고려하여야 한다.

 

설계단계에서의 결과물로 UML에서는 class diagram, sequence diagram, collaboration diagram, state diagram, activity diagram, component diagram, deployment diagram이 나오게 된다.

 

3.6.         구현(Implement)

: 구현의 단계는 실제로 소스코드로 생성하는 단계이다.  만약 설계를 완벽하게 마쳤다면 구현의 경우는 아주 쉬운 작업이 될 것이다.  이 단계에서는 다이어그램에서 특정언어의 구문으로 옮겨 적는 과정 그리고 컴파일하고 링킹하고 다시 디버깅하는 작업이 포함되어있다. 실제로 소스코드의 작성은 프로그래머에게 익숙한 작업이고 친근한 작업이다. 하지만 객체지향 분석과 설계에서는 코딩을 먼저 하는 것이 바람직하지 못하다. 분석과 설계의 과정을 충분히 거치지 않고 바로 코딩을 할 경우 분석하고 설계하는 단계를 다시 하는 경우가 빈번하며 이는 오히려 프로젝트를 망치거나 장기화 시킬 우려가 대단히 크다.

 

구현단계의 결과물로 어떤 다이어그램을 만드는 일은 드물다. 대신 설계 단계를 정정하는 것이 필요하다.

 

3.7.         테스트(Test)

: 마지막 단계로써 테스트의 목적은 코드에서의 에러를 발견하는 일이다. 여기서 에러의 발견은 프로그램에서의 실수가 아니고 성공이라고 보아도 좋다. 테스트 결과의 에러가 문서로 남게 되고 이것이 다음 버전에서

 

모델링 절차 (모델링 문서)

모델링 구분	활동내역		산출물
	단계	액티비티
사용자 요구사항 분석	분석	요구사항분석	문제기술서
			요구사항정의서
Use Case Modeling	분석	Use case 분석	Use Case Diagram
		Use case 절차분석	Use Case Description
Object Modeling	분석	객체도출/정제	Class Diagram
		Association맺기	Class Diagram
		Attribute/Operation	Class Diagram
	설계	속성,메서드 영문변환	Class Diagram
		컨트롤클래스추가	Class Diagram
Dynamic Modeling	분석	메시지분석	Sequence Diagram
		상태분석	Statechart Diagram
		흐름분석	Activity Diagram
	설계	메시지분석	Sequence Diagram
		상태분석, 동작분석	Statechart(State Machine), Activity
Physical	설계	컴포넌트분석	Component Diagram
		배치분석	Deployment Diagram