요구사항 확인

< 현행 시스템 파악 절차 >

1단계

- 시스템 구성 파악 : 기간/지원 업무

- 시스템 기능 파악 : 주요/하부/세부 기능

- 시스템 인터페이스 파악 : 단위 업무 시스템 간 주고받는 데이터의 종류, 형식, 연계 유형, 주기 명시

2단계

- 아키텍처 구성 파악 : 업무 수행에 어떠한 기술 요소들이 사용되는지

- 소프트웨어 구성 파악 : SW들의 제품명, 용도, 라이선스 적용 방식, 라이선스 수 명시

3단계

- 하드웨어 구성 파악 : 이중화 적용 여부

- 네트워크 구성 파악

 

< OS >

- 컴퓨터 OS : Windows, UNIX, Linux

- 모바일 OS : iOS, Android

 

< DBMS >

DB 관리, 종속성/중복성 문제 해결

 

< WAS >

세션관리, 트랜잭션 관리를 위한 라이브러리 제공

ex. Tomcat, GlassFish, jBOSS

 

< 요구사항 >

● 유형 : 기능/비기능/사용자/시스템

● 개발 프로세스 단계

1. 도출 : 개발 생명 주기동안 반복( 인터뷰, 설문, 브레인스토밍 )

2. 분석 : 요구사항 중 명확하지 않거나 모호한 것 발견하여 걸러내기 위한 과정

3. 명세 : 요구사항 문서화

4. 확인 : 요구사항 명세서 검토

 

< 요구공학 >

무엇을 개발해야 하는지 요구사항을 정의하고 분석/관리하는 프로세스를 연구하는 학문

 

< 요구사항 분석 >

- 개념 모델링 : 현실 세계의 상황을 단순화하여 개념적으로 표현

- 정형 분석 : 구문과 의미를 갖는 정형화된 언어 이용

- 요구사항 분류

 

< 요구사항 확인 >

- 요구사항 검토 : 요구사항을 훑어보면서 확인

- 프로토타이핑 : 개발동안 요구사항을 반영하면서 지속적으로 프로토타입 재작성

- 모델 검증 : 개발된 모델이 요구사항을 충족시키는지 검증

- 인수 테스트 : 사용자 입장에서 확인

 

<  UML >

OMG에서 표준으로 지정, 대표적 객체지향 모델링 언어

- 사물 : 구조, 행동, 그룹, 주해

- 관계

1. 연관 관계 : 연관되 있음을 표시( A -> B )

2. 집합 관계 : 하나가 다른 하나에 포함( 포함 되는 쪽 -◇ 포함 하는 쪽 )

3. 일반화 관계 : 하나가 다른 하나에 비해 구체적임( 구체적인 개념 -▷ 일반적인 개념 )

4. 의존 관계 : 연관은 있으나 필요에 의해 짧게 연관 유지( 영향을 주는 쪽 ---> 영향을 받는 쪽 )

ex. 등급 ---> 할인율( 등급이 높으면 할인율 적용 / 등급이 낮으면 할인율 X )

5. 실체화 관계 : ex. 관리자/회원 ---▷ 로그인

 

< 다이어그램 >

- 구조적 다이어그램

1. 클래스 : 클래스 사이 관계, 시스템 구조 파악, 구조상 문제점 도출

2. 객체 : 인스턴스를 관계로 표현

3. 컴포넌트 : 컴포넌트 간 인터페이스 표현( 구현단계에서 사용 )

4. 배치 : 물리적 요소들 위치 표현( 구현단계에서 사용 )

5. 복합체 구조 : 복합 구조 가질 경우 그 내부 구조 표현

6. 패키지 : 패키지들의 관계 표현

- 행위 다이어그램

1. 유스케이스 : 요구 분석

2. 시퀀스 : 메시지 표현

3. 커뮤니케이션 : 메시지와 객체들 간 연관관계 표현

4. 상태 : 상태 변화 표현

5. 활동 : 처리의 흐름을 순서에 따라 표현

6. 상호작용   7. 타이밍

 

< 유스케이스 다이어그램 >

● 기능 모델링 : 시스템이 갖춰야 할 기능들을 정리한 후 사용자와 공유

● 구성 요소 : 시스템 범위, 액터, 유스케이스, 관계

- 엑터 : 사람/외부 시스템

- 유스케이스 : 서비스/기능, 타원으로 표현

- 포함관계 : 두 개 이상의 유스케이스에 공통적으로 적용, 원래 유스케이스에서 포함되는 유스케이스로 화살표

( 화살표 위에 <<include>> )

- 확장관계 : 특정 조건에 부합되어 유스케이스 기능이 확장, 확장될 유스케이스에서 원래 유스케이스로 화살표

( 화살표 위에 <<extends>> )

 

< 활동 다이어그램 >

자료 흐름도와 유사, 복잡한 처리의 흐름을 명확하게 표현

● 구성 : 액션, 액티비티, 노드, 스윔레인

- 액션 : 더 이상 분해할 수 없는 단일 작업( 둥근 사각형 )

- 액티비티 : 몇 개의 액션으로 분리 될 수 있는 작업( 둥근 사각형 )

- 시작노드 : 액션/액티비티 시작( 검은색 원 )

- 종료노드 : 종료됨을 의미( 검은색 원을 포함한 원 )

- 조건노드 : 조건에 따라 제어 흐름 분리( 마름모, 들어오는 흐름 1개/나가는 흐름 여러개 )

- 병합노드 : 여러 경로 흐름이 하나로 합쳐짐( 마르모, 들어오는 흐름 여러개/나가는 흐름 1개 )

- 포크노드 : 액티비티의 흐름이 분리되어 수행( 굵은 가로선, 들어오는 흐름 1개/나가는 흐름 여러개 )

- 조인노드 : 분리되어 수행되던 액티비티가 다시 합쳐짐( 굵은 가로선, 들어오는 흐름 여러개/나가는 흐름 1개 )

- 스윔레인 : 액티비티 수행을 담당하는 주체 구분( 가로/세로 실선 )

 

< 클래스 다이어그램 >

구조적 다이어그램, 시스템 구성 요소를 문서화

● 구성 : 클래스, 제약조건, 관계

● 정적 모델링 : 기능 구현에 필요한 자료들의 논리적인 구조를 표현, 객체들을 추상화하여 표현

( UML을 이용한 정적 모델링 : 클래스 다이어그램 )

- 클래스 : 객체들의 속성과 오퍼레이션(동작)을 표현, 클래스 이름은 반드시 명시( 속성과 오퍼레이션은 생략 가능 )

- 속성 : 클래스의 상태나 정보

- 오퍼레이션 : 클래스가 수행할 수 있는 동작

- 제약조건 : 클래스 안에 제약조건 적을 때는 {} 이용, 그 외는 주석 도형안에 적어서 오퍼레이션과 점선 연결

 

<- 주석 도형

 

 

 

- 연관관계 : 두 클래스간 관계 표현( 실선, 실선 중간에 관계 이름 표기 가능 )

- 집합관계 : (  포함 되는 쪽 -◇ 포함 하는 쪽 )

- 포함관계 : 포함 하는 쪽이 없어지면 포함 되는 쪽은 쓸모가 없어짐( 포함 되는 쪽 -◆ 포함 하는 쪽 )

- 일반화관계 : 하위 클래스가 상위 클래스의 속성이나 메소드 사용 가능( 하위 클래스 -▷ 상위 클래스 )

- 의존관계 : ( 영향을 주는 클래스 ---> 영향을 받는 클래스 )

ex. 야구선수 ---> 연봉

- 접근 제어자 : public = +, private = -, protected = #, package = ~

 

< 시퀀스 다이어그램 >

객체들이 메시지를 주고받으며 시간의 흐름에 따라 상호 작용하는 과정을 그림으로 표현

● 동적 모델링 : 구성 요소들의 상태가 시간의 흐름에 따라 변화하는 과정, 이 과정에서 발생하는 상호작용 표현

ex. UML의 시퀀스 다이어그램, 커뮤니케이션 다이어그램, 상태 다이어그램

● 구성 : 액터, 객체, 라이프라인, 활성 상자, 메시지

- 객체 : 메시지를 주고받는 주체

- 라이프라인 : 객체 아래쪽에 점선을 그어 표현

- 활성 상자 : 객체가 메시지를 주고받으며 구동되고 있음을 표현

- 메시지

1. 동기 : -▶   2. 비동기 : ->   3. 생성 : --->   4. 응당 : ---▶

 

< 커뮤니케이션 다이어그램 >

객체들이 주고받는 메시지 표현, 객체들 간의 관계도 표현

● 구성 : 액터, 객체, 링크, 메시지

- 링크 : 객체들 간의 관계 표현

 

< 상태 다이어그램 >

이벤트에 의한 객체들의 상태 변화

● 구성 : 상태, 이벤트, 상태 전환