[정보처리기사] 1.소프트웨어 설계 - 요구사항 확인(분석모델 확인)

용어 정리

UML(Unified Modeling Language): 표준화된 범용 모델링 언어

객체지향 설계를 위한 표준언어로, 시스템을 시각적으로 모델링하기 위한 모델링 언어이다. 시스템 개발 과정의 광범위한 분야에 사용 가능하다.

Stereo Type (스테레오 타입)

1. UML에서 제공하는 기본요소 외에 추가적인 확장요소를 나타내는 것이다.

2. 길러멧(guillemet, <<>>) 사이에 적는다.

3. ex) <<interface>>, <<utility>>, <<abstract>>, <<enumeration>>

---

요구사항 분석 기법

순서

이름	목적
1. 요구사항 분류(Requirement Classification)	요구사항이 기능인지 비기능인지
	요구사항이 하나 이상의 고수준 요구사항으로부터 유도된 것인지
	이해관계자나 다른 Source로 부터 직접 발생한 것인지
	요구사항이 제품에 관한 것인지
	프로세스에 관한 것인지
	우선순위가 더 높은 것인지 여부
	요구사항의 범위(요구사항이 소프트웨어에 미치는 영향의 범위)
	요구사항이 소프트웨어 생명 주기 동안에 변경이 발생하는지 여부
2. 개념 모델링(Conceptual Modeling)	실세계 문제에 대한 모델링이 소프트웨어 요구사항 분석이 핵심
	모델은 문제가 발생하는 상황에 대한 이해를 증진시키고 해결책을 설명
	개념 모델은 문제 도메인의 엔티티(entity)들과 그들의 관계 및 종속성을 반영
	대부분의 모델링 표기법은 UML(Unified Modeling Language)을 사용
	사용 시나리오를 나타내기 위해 Usecase Diagram을 많이 사용
3. 요구사항 할당(Requirement Allocation)	요구사항을 만족시키기 위한 아키텍쳐 구성 요소를 식별하는 것
	다른 구성 요소와 어떻게 상호작용하는지 분석을 통하여 추가적인 요구사항을 발견할 수 있음
4. 요구사항 협상(Requirement Negotiation)	두 명의 이해관계자가 서로 상충되는 내용을 요구하거나, 요구사항과 리소스, 기능과 비기능 요구사항들이 서로 상충되는 경우, 적절한 트레이드 오프 지점에서 합의가 중요
	요구사항에 우선순위를 부여하여 요구사항을 필터링할 수 있음.
5. 정형 분석(Formal Analysis)	형식적으로 정의된 시멘틱(Semantics)을 지닌 언어로 요구사항을 표현
	정확하고 명확하게 표현하여 오해를 최소화
	정형 분석은 요구사항 분석의 맨 마지막 단계에서 이루어짐

 

정형 명세기법 VS 비정형 명세기법

비정형 명세기법	정형 명세기법
자연어를 기반으로 서술	수학적 원리와 표기법
작성하기 쉬우나, 애매모호한 표현으로 달리 해석될 위험이 있음	Z 정형 명세 언어

 

UML의 구성요소

 

UML에서 활용되는 다이어그램

 

유스케이스(Usecase) 다이어그램

시스템을 사용하는 목적을 사용자 관점에서 기술한 다이어그램이다. 목적 달성을 위한 사용자와 시스템 사이의 상호작용을 알 수 있다. 또한 시스템이 제공하는 기능과 서비스 등을 정의하고 시스템의 범위를 결정한다.

유스케이스 다이어그램 작성 시 고려할 사항

1. 누가(또는 어떤 시스템이) 해당 시스템을 사용할 것인가?

2. 시스템은 사용자를 위해 무엇을 해야하는가?

3. 사용자와 상호작용하기 위해 시스템이 제공해야할 인터페이스는 무엇인가?

유스케이스 다이어그램 - 시스템

1. 만드려는 어플리케이션이다.

2. 사각형을 그리고, 시스템 명칭을 쓴다.

유스케이스 다이어그램 - 액터

1. 시스템의 외부에서 시스템과 상호작용하는 사람 또는 다른 시스템이다.

2. 사람 모양으로 표현하고 액터명을 표시한다.

유스케이스 다이어그램 - 유스케이스

1. 시스템이 액터에게 제공하는 기능이다.

2. 타원으로 표시하고 그 안쪽에 유스케이스명을 기술한다.

3. '~한다' 의 동사로 표현한다.

4. 각 유스케이스가 개발될 기능 하나와 연결된다.

유스케이스 다이어그램 - 관계

액터와 유스케이스 사이의 관계를 의미한다.

관계 - 연관관계

관계 - 포함관계

1. 하나의 유스케이스가 다른 유스케이스의 실행을 전제해야할 때 사용한다.

2. 포함되는 방향으로 화살표를 점선으로 연결한다.

관계 - 확장관계

1. 유스케이스가 특정 조건에 따라 확장될 수 있는 옵션일 때 사용한다.

2. 기본 유스케이스는 독립적으로 유지되면서 선택적, 추가적인 행동을 하는 것을 의미한다.

3. 확장 기능 유스케이스를 기본 유스케이스로 화살표를 점선으로 연결한다.

관계 - 일반화 관계

1. 유사한 유스케이스(또는 액터)들을 모아 추상화한 유스케이스(또는 액터)이다.

2. 구체적인 유스케이스들에서 추상적인 유스케이스 방향으로 끝부분이 삼각형의 테두리인 화살표를 실선으로 연결한다.

 

유스케이스 다이어그램 만드는 순서

1. 액터 식별

- 누가 정보를 제공하고 사용하고 삭제하는가?

- 누가 또는 어떤 조직에서 이 시스템을 사용할 것인가?

2. 유스케이스 식별

- 액터가 요구하는 서비스 / 정보를 유스케이스로 식별할 수 있는가?

- 액터가 시스템과 상호작용하는 행위를 유스케이스로 나타낼 수 있는가?

3. 관계 정의

- 액터간, 유스케이스간의 일반화, 연관관계를 정의할 수 있는가?

- 유스케이스 간 포함, 확장관계를 정의할 수 있는가?

 

분석 자동화 도구 - CASE(Computer Aided Software Engineering)

특징

1. 컴퓨터 지원 시스템 공학

2. 시스템 개발 방법론들의 자동화를 지원하는 소프트웨어 도구를 제공해 개발자의 반복적인 작업량을 줄여준다.

3. CASE 도구들은 문서의 생성과 개발팀 간의 협업을 돕는다.

4. 작업된 내용을 검토하고 수정하기 위해 서로 다른 사람의 파일에 접근하도록 허용해 팀 구성원들이 서로의 작업을 쉽게 공유할 수 있다.

5. CASE 도구들은 강력한 그래픽 기능이 있으며 PC 기반에서 운영된다.

6. CASE 도구들은 차트와 다이어그램을 자동으로 생성하는 그래픽 기능, 화면과 리포트 생성기, 데이터 사전, 분석과 검사도구, 코드생성기, 문서 생성기 등을 제공한다.

 

CASE의 장점

장점

1. 구조적인 것들을 그대로 활용할 수 있다.

2. 교차 참조도와 보고서를 통한 결함, 생략, 불일치 발견이 쉽다.

3. 요구 정보를 추출하고 분석하는 것을 도와준다.

4. 원형(prototype)이나 프로그램의 개발 및 유지가 용이하다.

5. 개발자들이 반복적인 업무에서 벗어나 창의적인 업무에서 몰두할 수 있게 해준다.

6. 소프트웨어의 점진적 개발이 가능하다.

7. 소프트웨어의 재활용성을 재고시켜준다.

8. 모든것들이 그림으로 표현되어 있어서 개발자들간에 정보시스템의 공유가 쉽다.