1. web.xml → 한글 처리★
2. pom.xml → lib설정★
3. web-inf/root-context.xml★
4. resources/*.xml -> CRUD
5. dao → junittest
6. Controller 생성
7. view 연결
8. tile2 → template 설정
[01] 현행 시스템 분석하기 1) 현행 시스템 파악 - 개발하고자 하는 응용소프트웨어에 대한 이해를 높이기 위해, 현행 시스템의 적용현황을 파악함으로써
개발범위와 향후 개발될 시스템으로의 이행방향성을 분석할 수 있다
- 현행 시스템 파악의 개요
1. 현행 시스템 파악의 정의 및 목적
(1) 현행 시스템 파악의 정의
현행 시스템이 어떤 하위 시스템으로 구성되어 있는지, 제공하는 기능이 무엇인지,
다른 시스템들과 어떤 정보를 주고받는지, 어떤 기술요소를 사용하고 있는지, 사용하고 있는
소프트웨어 및 하드웨어는 무엇인지, 네트워크는 어떻게 구성되어 있는지 등을 파악하는
활동이다.
(2) 현행 시스템 파악의 목적
이를 통하여 향후 개발하고자 하는 시스템의 개발범위 및 이행방향성 설정에 도움을
주는 것이 목적이다.
2. 현행 시스템 파악 절차
아래와 같이 3단계로 구분하여 수행해야 할 활동들에 대하여 기술한다.
- 1단계 현행 시스템의 구성, 기능, 인터페이스 현황을 파악하는 단계
- 2단계 현행 시스템의 아키텍처 및 소프트웨어 구성 현황을 파악하는 단계
- 3단계 현행 시스템의 하드웨어 및 네트워크 구성 현황을 파악하는 단계
- 현행 시스템 구성/기능 및 인터페이스 1. 현행 시스템 구성 현황
- 현행 시스템 구성 현황의 정의
현행 시스템 구성 현황은 조직의 주요 업무를 처리하는 기간 업무와 이를 지원하는
지원 업무로 구분하여 기술한 것이다.
- 현행 시스템 구성 현황 작성 시 고려 사항
각 업무에 속하는 단위 업무 정보시스템들의 명칭, 주요 기능들을 명시함으로써 조직
내 존재하는 모든 정보시스템의 현황을 파악하도록 한다.
2. 기능 현황
- 기능 현황의 정의
단위 업무 시스템이 현재 제공하고 있는 기능을 기술한 것이다.
- 기능 현황 작성 시 고려 사항
단위 업무 시스템에서 제공하는 기능들을 주요 기능과 하부 기능으로 구분하여 계층
형으로 표시한다.
3. 인터페이스 현황
- 인터페이스 현황의 정의
단위 업무 시스템이 다른 단위 업무 시스템과 주고받는 데이터의 종류, 데이터 형식,
프로토콜, 연계유형, 주기 등을 명시한 것이다.
- 인터페이스 현황 작성 시 고려 사항
중요한 고려 사항으로는 어떤 형식(format)으로 데이터를 주고받는지(XML, 고정 포맷,가변 포맷 등),
어떤 통신규약(TCP/IP, X.25 등)을 사용하고 있고, 연계유형(EAI, FEP 등)은 무엇인지 등이 있다.
- 현행 시스템 아키텍처 및 소프트웨어
1. 현행 시스템 아키텍처 구성도
- 현행 시스템 아키텍처 구성도의 정의
기간 업무를 수행하기 위하여 계층별로 어떠한 기술 요소들을 사용하고 있는지 최상
위 수준에서 그림으로 표현한 것이다.
- 현행 시스템 아키텍처 구성도 작성 시 고려 사항
단위 업무 시스템별로 아키텍처가 다른 경우에는 가장 핵심이 되는 기간 업무 처리
시스템을 기준으로 한다.
※ [그림 1-2]에 대한 설명 전자정부 모바일 공통 컴포넌트는 효율적인 전자정부 기반 시스템의
구축? 운영을 통해 전자정부의 서비스 품질 및 정보화 투자 효율 향상의 기반을 확보하고,
모바일 전자정부 서비스에 대한 접근성을 제고하기 위해 모바일 표준 프레임워크 기반으로
개발된 공통 컴포넌트로서 주요 구성 요소는 다음과 같다.- 공통 기반 계층(Foundation Layer): 실행 환경 서비스 간에 공통적으로 사용되는 기능을 제공한다.- 화면 처리 계층(Presentation Layer/UX Layer): 업무 처리 서비스와 사용자 간의 인터페이스를
담당하는 서비스로 사용자 화면 구성 및 사용자 입력 정보 검증 등의 기능을 지원한다.
- 업무 처리 계층(Business Layer): 업무 프로그램의 업무 로직을 담당하는 서비스로 업무 흐름 제어,
트랜잭션 관리, 에러 처리 등의 기능을 제공한다.
- 데이터 처리 계층(Data Access Layer): 업무 프로그램에서 사용할 수 있도록 데이터에 대한
CRUD 기능을 지원한다.
- 연계 통합 계층(Integration Layer): 타 시스템과의 연동 기능을 지원한다.
2. 소프트웨어 구성도
- 소프트웨어 구성도의 정의
단위 업무 시스템의 업무 처리를 위해 설치되어 있는 소프트웨어들의 제품명, 용도,
라이선스 적용 방식, 라이선스 수를 명시한 것이다.
- 소프트웨어 구성도 작성 시 고려 사항
시스템 구축 시 인프라 구축 비용에서 하드웨어 비용뿐만 아니라 소프트웨어 비용이
적지 않기 때문에, 상용 소프트웨어의 경우에는 라이선스 적용 방식의 기준(사이트, 서
버, 프로세서, 코어(core), 사용자 수 등)과 보유한 라이선스 수량 파악이 중요하다.
- 하드웨어 및 네트워크
1. 하드웨어 구성도
- 하드웨어 구성도의 정의
단위 업무 시스템들이 어디에 위치하고 있는 서버에서 운용되고 있는지 서버의 주요
사양(CPU 처리 속도, 메모리 크기, 하드디스크의 용량 등)과 수량, 이중화가 적용되어
있는지 여부를 명시한 것이다.
- 하드웨어 구성도 작성 시 고려 사항
이중화는 기간 업무의 서비스 기간, 장애 대응 정책에 따라 필요성 여부가 결정되며,
현행 시스템에서 이중화가 적용된 경우에는 목표 시스템에서도 이중화가 필요한 경우
가 대부분이며, 이에 따라 인프라 구축 기술 난이도 및 비용 증가 가능성이 존재한다.
2. 네트워크 구성도
- 네트워크 구성도의 정의
업무 처리 시스템들이 어떠한 네트워크 구성을 가지고 있는지 그림으로 표현한 것이다.
- 네트워크 구성도 작성 시 고려 사항
네트워크 구성도의 작성을 통해 서버의 위치, 서버 간의 네트워크 연결 방식을 파악할
수 있다. 네트워크 구성도는 조직 내 서버들의 물리적인 위치 관계 파악, 조직 내 보
안 취약성 분석 및 대응, 네트워크 장애 발생 추적 및 대응 등의 다양한 용도로 활용
될 수 있다.
2) 개발 기술 환경 정의
- 개발 기술 환경 개발 기술 환경을 정의할 때 고려할 사항을 [그림 1-6]과 같이 운영체제, DBMS, 미들웨어,
오픈 소스 순으로 살펴본다.
1. 운영체제 주요 특징 및 고려 사항(1) 운영체제의 정의
운영체제(OS: Operating System)는 하드웨어와 소프트웨어 리소스를 관리하고 컴퓨터
프로그램을 위한 공통 서비스를 제공하는 소프트웨어를 의미한다. 관련 사이트 참고
(https://en.wikipedia.org/wiki/Operating_system)
(2) 운영체제의 종류 및 특징
주요 운영체제로는 마이크로소프트 윈도즈(Microsoft Windows), 유닉스(UNIX), 리눅스
(Linux), 아이오에스(iOS), 안드로이드(Android) 등이 있다.
자바 가상 머신(JVM: Java Virtual Machine)은 다양한 하드웨어 및 운영체제에서 자바 (Java) 언어로
작성된 애플리케이션을 수행하기 위한 사양(JVM Specification)의 구현체 (Implementation)를 의미한다.
오라클(Oracle)이 자바(Java) 상표를 소유하고 있으며, 핫 스팟(Hotspot) 구현체와 클래스 라이브러리(Class Library)
구현체를 배포하고 있다. 아 이비엠(IBM)의 J9, 오라클(Oracle)의 JRockit(이전 BEA System 제공) 등
벤더별로 여러 자바 가상 머신(JVM: Java Virtual Machine) 구현체를 배포하고 있다.
관련 사이트 참 고(https://en.wikipedia.org/wiki/Java_virtual_machine)
(3) 고려 사항
2. DBMS 주요 특징 및 고려 사항
(1) DBMS의 정의 사용자, 다른 애플리케이션, 데이터베이스와 상호 작용하여 데이터를 저장하고
분석하기 위한 컴퓨터 소프트웨어 애플리케이션으로, 데이터베이스 생성, 조회, 변경 등의 관리가
중요 기능이다. 관련 사이트 참고(https://en.wikipedia.org/wiki/Database)
(2) DBMS의 종류 및 특징
(3) 고려 사항
3. 미들웨어의 주요 특징 및 고려 사항
(1) 미들웨어의 정의
운영체제와 소프트웨어 애플리케이션 사이에 위치하는 미들웨어(Middleware)는 소프트
웨어 애플리케이션에게 운영체제가 제공하는 서비스를 추가 및 확장하여 제공하는 컴
퓨터 소프트웨어를 말한다. (https://en.wikipedia.org/wiki/Middleware) 여기에서는 미들웨
어 중 웹 애플리케이션 서버(WAS: Web Application Server)에 대해서 알아본다.
(2) 웹 애플리케이션 서버(WAS: Web Application Server)의 정의
동적인 웹 사이트, 웹 애플리케이션, 웹 서비스의 개발을 지원하기 위하여 설계된 소
프트웨어로서 데이터 접근, 세션 관리, 트랜잭션 관리 등을 위한 라이브러리를 제공하
고 있다. 관련 사이트 참고(https://en.wikipedia.org/wiki/Web_application_framework)
(3) 웹 애플리케이션 서버(WAS: Web Application Server)의 종류 및 특징
(4) 고려 사항
4. 오픈 소스 사용에 따른 고려 사항
(1) 오픈 소스의 정의
오픈 소스(Open Source)는 소스 코드를 공개해 누구나 특별한 제한 없이 그 코드를 보
고 사용할 수 있는 오픈 소스 라이선스를 만족하는 소프트웨어를 말한다
(2) 오픈 소스 사용 시 고려 사항
오픈 소스를 사용하는 경우에는 라이선스의 종류, 사용자 수, 기술의 지속 가능성 등
을 고려해야 한다. 라이선스의 종류 등 자세한 내용은 한국저작권위원회의 OLIS 사이
트(https://www.olis.or.kr)를 참조한다. 어떠한 오픈 소스를 사용해야 라이선스의 문제가
없을지 판단이 어려운 경우에는 전자정부 표준 프레임워크에서 사용 중인 오픈 소스
소프트웨어를 참조할 수 있다
- 시스템 용량산정 방법수집 및 분석된 온라인 트랜잭션 처리(OLTP: Online Transaction Processing), WEB/WAS 기초 자료 조사 항목의 값을 시스템 용량산정 엑셀 파일에 입력하여 CPU, 메모리,디스크
용량을 계산한다.(1) CPU 용량산정
(가) OLTP/Batch/데이터베이스 서버
온라인 트랜잭션 처리(OLTP: Online Transaction Processing)/일괄작업(Batch)/데이터베이스
서버의 CPU 용량을 산정하기 위한 상세 내용은 본 학습모듈의 부록을 참조한다.
구체적인 CPU 용량 산정 절차는 [그림 1-7]과 같다.
위의 절차대로 시스템 용량을 산정할 수 있도록 한국정보화진흥원에서는 엑셀
(Excel) 파일을 제공하고 있다.
(http://www.nia.or.kr/bbs/board_view.asp?BoardID=201111281321074458&id=1536&
Order=&search_target=&keyword=&Flag=) 아래는 이 파일의 온라인 트랜잭션
처리(OLTP) 서버의 CPU 용량산정 시트(Sheet)이다.
WEB/WAS 용량산정, 메모리 용량산정, 디스크 용량산정 시트도 제공하고 있다.
(나) WEB/WAS 서버
WEB/WAS 서버의 CPU 용량을 산정하기 위한 상세 내용은 본 학습모듈의 부
록을 참조한다. 구체적인 CPU 용량 산정 절차는 [그림 1-9]와 같다.
(2) 메모리 용량산정
서버의 메모리를 산정하기 위한 상세 내용은 본 학습모듈의 부록을 참조한다. 구
체적인 메모리 용량산정 절차는 [그림 1-10]과 같다.
(3) 디스크 용량산정
시스템의 디스크 용량을 산정하기 위한 상세 내용은 본 학습모듈의 부록을 참조
한다. 디스크 용량산정 절차는 [그림 1-11]과 같다.
[01] 요구사항 정의
학습목표:• 소프트웨어 공학기술의 요구사항 분석 기법을 활용하여 업무 분석가가 정의한 응용 소프트웨어의
요구사항을 확인할 수 있다.
• 업무 분석가가 분석한 요구사항에 대해 정의된 검증기준과 절차에 따라서 요구사항 을 확인할 수 있다
1) 요구공학 개요- 요구공학(Requirements Engineering)이란 요구사항을 정의하고, 문서화하고, 관리하는 프로
세스를 의미한다. (https://en.wikipedia.org/wiki/Requirements_engineering)
1. 요구사항 개발 프로세스
소프트웨어공학 지식체계(SWEBOK: SoftWare Engineering Body of Knowledge)에서는 이
프로세스를 요구사항 도출(Elicitation), 분석(Analsysis), 명세(Specification), 확인(Validation)
으로 구분하고 있다. (http://www.computer.org/web/swebok)
(1) 요구사항 도출(Requirement Elicitation)
(가) 요구사항 도출은 소프트웨어가 해결해야 할 문제를 이해하는 첫 번째 단계로서
요구사항이 어디에 있고, 어떻게 수집할 것인가와 관련되어 있다.
(나) 이 단계에서 이해관계자(Stakeholder)가 식별되고, 개발 팀과 고객 사이의 관계가
만들어진다.
(다) 이 단계에서는 다양한 이해관계자와 효율적인 의사소통이 중요하다.
(2) 요구사항 분석(Requirement Analysis)
(가) 요구사항들 간 상충되는 것을 해결하고, 소프트웨어의 범위를 파악하며, 소프트
웨어가 환경과 어떻게 상호 작용하는지 이해한다.
(나) 시스템 요구사항을 정제하여 소프트웨어 요구사항을 도출한다.
(3) 요구사항 명세(Requirement Specification)
(가) 요구사항 명세란 체계적으로 검토, 평가, 승인될 수 있는 문서를 작성하는 것을
의미한다.
(나) 시스템 정의, 시스템 요구사항, 소프트웨어 요구사항을 작성한다.
(4) 요구사항 확인(Requirement Validation)
(가) 분석가가 요구사항을 이해했는지 확인(Validation)이 필요하고, 요구사항 문서가
회사의 표준에 적합하고 이해 가능하며, 일관성이 있고, 완전한지 검증
(Verification)하는 것이 중요하다.
(나) 이해관계자들이 문서를 검토해야 하고, 요구사항 정의 문서들에 대해 형상 관리
를 해야 하는데, 일반적으로 요구사항 관리 툴을 이용한다.
(다) 리소스가 요구사항에 할당되기 전에 문제를 파악하기 위하여 검증을 수행한다.
위와 같은 요구사항 개발 프로세스 중에서 요구사항 확인하기와 관련된 단계는 분석 및
검증 단계이므로, 필요 지식에서는 도출 및 명세 단계를 생략한 분석 및 검증 단계에 대
해서만 기술하기로 한다. 요구사항 분석을 통해 요구사항을 기술할 때에는 아래의 작업들이 가능하도록 충분하고
정확하게 기술하여야 한다.
- 요구사항의 확인(Validation)
- 요구사항 구현의 검증(Verification)
- 비용 추정
분석기법으로 요구사항 분류((Requirement Classification), 개념 모델링(Conceptual Modeling),
요구사항 할당((Requirement Allocation), 요구사항 협상((Requirement Negotiation),
정형 분석(Formal Analysis) 등이 있다.
1. 요구사항 분류(Requirement Classification)
요구사항을 다음과 같은 기준으로 분류한다.
- 요구사항이 기능인지 비기능인지
- 요구사항이 하나 이상의 고수준 요구사항으로부터 유도된 것인지 또는 이해관계자나
다른 원천(Source)으로부터 직접 발생한 것인지
- 요구사항이 제품에 관한 것인지 프로세스에 관한 것인지
- 우선순위가 더 높은 것인지 여부
- 요구사항의 범위(요구사항이 소프트웨어에 미치는 영향의 범위)
- 요구사항이 소프트웨어 생명 주기 동안에 변경이 발생하는지 여부
2. 개념 모델링(Conceptual Modeling)(1) 개념 모델의 역할
(가) 실세계 문제에 대한 모델링이 소프트웨어 요구사항 분석의 핵심이며, 모델은 문
제가 발생하는 상황에 대한 이해를 증진시키고 해결책을 설명한다.
(나) 따라서 개념 모델은 문제 도메인의 엔터티(entity)들과 그들의 관계 및 종속성을
반영한다.
(2) 개념 모델의 종류와 표기법
(가) 유스케이스 다이어그램(Use Case Diagram), 데이터 흐름 모델(Data Flow Model),
상태 모델(State Model), 목표기반 모델(Goal-Based Model), 사용자 인터액션(User
Interactions), 객체 모델(Object Model), 데이터 모델(Data Model) 등과 같은 다양한
모델을 작성할 수 있다.
(나) 대부분의 모델링 표기법은 UML(Unified Modeling Language)을 사용한다.
(3) UML 다이어그램의 사용
(가) 사용 시나리오를 나타내기 위하여 유스케이스 다이어그램이 많이 사용되고 있다.
(나) 구조 다이어그램(Structure Diagram)은 시스템의 정적 구조(Static Structure)와 다
양한 추상화 및 구현 수준에서 시스템의 구성 요소, 구성 요소들 간의 관계를 보
여 준다.
(다) 행위 다이어그램(Behavior Diagram)은 시스템 내의 객체들의 동적인 행위(Dynamic
Behavior)를 보여 주며, 시간의 변화에 따른 시스템의 연속된 변경을 설명해 준다.
3. 요구사항 할당(Requirement Allocation)
(1) 요구사항을 만족시키기 위한 아키텍처 구성 요소를 식별하는 것을 요구사항 할당이
라 한다.
(2) 다른 구성 요소와 어떻게 상호 작용하는지 분석을 통하여 추가적인 요구사항을 발견
할 수 있다.
4. 요구사항 협상(Requirement Negotiation)
(1) 두 명의 이해관계자가 서로 상충되는 내용을 요구하거나, 요구사항과 리소스, 기능과
비기능 요구사항들이 서로 상충되는 경우, 어느 한 쪽을 지지하기보다는 적절한 트
레이드 오프 지점에서 합의가 중요하다.
(2) 요구사항에 우선순위를 부여하는 것은 중요한 요구사항을 필터링할 수 있으며, 요구
사항들 간 상충되는 문제를 해결하는 데 사용될 수 있다.
5. 정형 분석(Formal Analysis)
(1) 형식적으로 정의된 시맨틱(Semantics)을 지닌 언어로 요구사항을 표현한다.
(2) 정확하고 명확하게 표현하여 오해를 최소화시킬 수 있다.
(3) 정형 분석(Formal Analysis)은 요구사항 분석의 마지막 단계에서 이루어진다.
3) 요구사항 확인
분석가가 요구사항을 이해했는지 확인(Validation)하는 것이 필요하고, 요구사항 문서가 회
사의 표준에 적합하고 이해 가능하고, 일관성이 있고, 완전한지 검증(Verification)하는 것
이 중요하다. 이해관계자들이 문서를 검토해야 하고, 요구사항 정의 문서들에 대해 형상
관리를 해야 하는데 일반적으로 요구사항 관리 툴을 이용한다. 리소스가 요구사항에 할당
되기 전에 문제를 파악하기 위하여 검증을 수행한다.
1. 요구사항 확인 기법
(1) 요구사항 검토(Requirement Reviews)
(가) 요구사항 검증의 가장 일반적인 방법으로, 여러 검토자들이 에러, 잘못된 가정,
불명확성, 표준과의 차이 등을 찾아내는 작업을 수행하며, 검토자 그룹을 어떻게
구성하느냐가 중요하다.
(나) 예를 들어, 고객 중심 프로젝트에서는 검토자 그룹에 고객 대표자가 1명 이상 포
함되어야 한다.
(다) 검토는 시스템 정의서(System Definition Document), 시스템 사양서(System Specification),
소프트웨어 요구사항 명세서(SRS: Software Requirements Specification Document)
를 완성한 시점 등에서 이루어진다.
(2) 프로토타이핑(Prototyping)
(가) 프로토타이핑은 새로운 요구사항을 도출하기 위한 수단으로, 또한 소프트웨어 요
구사항에 대해 소프트웨어 엔지니어가 해석한 것을 확인하기 위한 수단으로 많
이 사용된다.
(나) 프로토타이핑의 장점은 분석가의 가정을 파악하고 잘못된 경우 유용한 피드백을
제공한다는 점, 사용자 인터페이스(User Interface)의 동적인 행위가 문서나 그래
픽 모델보다 프로토타입으로 이해하기 쉬운 점, 요구사항의 가변성이 프로토타이
핑 이후에 급격히 감소하는 점이다.
(다) 단점은 사용자의 관심이 핵심 기능에서 멀어지고 프로토타입의 디자인이나 품질
문제로 집중될 수 있으며, 프로토타입 수행 비용이 발생한다는 것이다.
(라) 잘못된 요구사항을 만족시키기 위하여 자원을 낭비하는 것을 방지할 수 있다는
점에서 프로토타이핑을 긍정적으로 검토할 수 있다.
(3) 모델 검증(Model Verification)
(가) 분석단계에서 개발된 모델의 품질을 검증할 필요가 있다.
(나) 예를 들어, 객체 모델의 경우 객체들 사이의 존재하는 의사소통 경로(Communication
Path)를 검증(Verify)하기 위하여 정적 분석(Static Analysis)을 수행하는 것이 유용
하다.
(4) 인수 테스트(Acceptance Tests)
(가) 요구사항의 중요한 속성은 최종 제품이 요구사항을 만족시키는지 확인이 가능해
야 한다는 것이다
(나) 각각의 요구사항을 어떻게 확인할 것인지에 대한 계획을 세워야 한다.
요구사항 검증 단계에서 사용되는 기법 이외에 요구사항 품질 검증을 위한 국내 표준을
활용하여 요구사항을 검증할 수 있다. 정보통신단체표준 TTAK.KO-11.0103 “소프트웨어
요구사항 품질 평가 항목”에서는 요구사항 명세의 품질을 객관적이고 정량적으로 평가하
기 위한 기준으로 평가 항목을 제시하고 있다. 구체적인 품질 모델, 품질 특성, 품질 특성
평가 항목은 부록을 참조한다.[02] 객체 지향 분석(Object Oriented Analysis) - UML: Usecase Diagram 정의
- Project main folder
. F:/javadb
. F:/javadb/datadown : 개발관련 프로그램
. F:/javadb/ojt/analyze_design : 각종 설계 문서 및 파일 자료
. F:/javadb/eclipse : main development tool
. F:/javadb/lib : jar Library
:
:
1. 요구 사항 정의(Defining Requirement)
- 기능적 모델링(Functional Modeling)
- 요구되는 기능 정의
1) 유스케이스 다이어그램(UseCase Diagram)
- 외부로 부터 본 시스템의 기능(행동)을 표현한다. 즉 어떤 시스템을 외부(사용자 등)에서 봤을때,
이 시스템에 어떠한 기능이 존재하는가를 확인할 수 있다.
- 요구 분석등의 상위작업에서 사용되며, 사용자의 '이 기능이 필요하다'라는 요구(기능 요구)를 정리
하여 개발 대상을 명확하게 하기 위해 사용한다.
2) 유스케이스 다이어그램(UseCase Diagram)의 주요 요소
- 액터(Actor)
어떤 시스템을 중심으로 봤을때, 그 외부에 존재하는 것을 나타낸다. 일반적으로 시스템의 사용자나
관련된 외부의 시스템을 나타낸다.
액터는 사람모양을의 아이콘으로 표기하며, 액터를 추상화 하거나 구체화할 경우에는 액터간의 일반화
(generalization) 관계로 표현할 수 있다.
일반화 관계는 객체 지향의 상속과 그 의미가 유사하며, 일반화 액터의 모든 기능을 특수화한 액터가 갖게
된다. 아래의 그림은 영업이 일반화 액터이고, 영업부장이 특수한 액터가 된다.
- 유스케이스(UseCase)
어떤 시스템을 외부에서 봤을 때, 그 시스템이 가지고 있는 기능을 나타내는 것이다. 그래서 외부로 부터
파악할 수 없는 레벨의 내부처리는 유스케이스로 표현하지 않는다.
유스케이스는 타원형으로 표기하고, 타원 안에 이름을 기술한다. 어떤 기능이 다른 기능을 포함할 경우에는,
유스케이스간에 포함(include)관계를 사용해서 표현한다.
또, 어떤 기능을 확장해서 기능(처리)를 추가할 경우에는 유스케이스 간에 확장(extends)의 관계를 사용해서
표현한다.
아래의 그림은 수주 내용을 등록하기 위해서 고객정보를 등록하는 작업을 확장(추가)하고, 고객정보를 확인
하는 작업을 포한 함고 있다.
- 관련(Association)
양쪽 끝에 화살모양이 없는 실선 모양으로 유스케이스와 액터간의 관련성을 나타낸다.
---------------------------------------------------------------------------------------------------------------
[UseCase Diagram 예]
[과제] 역활 분담 수정
- 요구사항 정의 후 발생된 내용을 가지고 역활 재 정의
3) 유즈케이스 정의서 작성
1. Usecase Specification(유즈케이스 정의서)
- 회사마다 독립적인 양식이 있으며 엑셀, 워드, 프로젝트 관리 솔루션등을
이용합니다.
Usecase 번호: mem01_회원가입
Actor System
----------------------------------
비회원 1) 아이디 중복 확인
- 아이디 중복되면 Ex01
2) 별명 중복 확인
- 별명 중복되면 Ex02
3) 주민등록번호 중복 검사
- 주민등록번호 중복되면 Ex03
4) 이메일 중복 검사
- 이메일 중복되면 Ex04
5) 기타 정보 입력 후 전송
예외 처리
Ex01: 아이디 중복 안내 창 출력
Ex02: 별명 중복 안내 창 출력
Ex03: 주민등록번호 중복 안내 창 출력
Ex04: 이메일 중복 안내 창 출력
2. Usecase Specification(유즈케이스 정의서)까지 만들어 질 경우 의뢰인의
의도를 구체적으로 어느정도 파악 할 수 있게 됩니다.
니가싫어도나는좋아.html
