[정보처리기사 실기] 2장 요약 키워드 정리 _ 요구사항 확인

[2] 요구사항 확인

2.1 현행 시스템 파악

현행 시스템 파악 절차

- 새로 개발하려는 시스템의 개발 범위를 명확히 설정하기 위해 현행 시스템을 파악함.

- 1단계: 시스템 구성 파악, 시스템 기능 파악, 시스템 인터페이스 파악

- 2단계: 아키텍처 구성 파악, 소프트웨어 구성 파악

- 3단계: 하드웨어 구성 파악, 네트워크 구성 파악

​

시스템 구성 파악

- 조직의 주요 업무를 담당하는 기간 업무와 이를 지원하는 지원 업무로 구분하여 기술함.

- 조직 내에 있는 모든 정보 시스템의 현황을 파악할 수 있도록 각 업무에 속하는 단위 업무 정보 시스템들의 명칭과 주요 기능을 명시한다.

(예) 금융기관의 여신관리 업무 시스템 현황

구분	시스템명	시스템 내용
여신관리 업무	여신기획 관리 시스템	여신기획 관리를 위한 연간 여신요율 책정 등의 기능을 제공하는 시스템

​

시스템 기능 파악

- 단위 업무 시스템이 현재 제공하는 기능들을 주요기능/하부기능/세부기능 으로 구분하여 계층형으로 표시.

(예) 여신상담 관리 시스템의 주요기능과 하부, 세부 기능

단위 업무 시스템	Level 1 주요 업무 기능	Level2 세부 업무 기능	Level3 세부 업무 기능 활동
여신 상담 관리	여신 기획 관리 ​ ​ 여신 상담 관리	여신요율 책정 여신 운용지침 수립 거래처 정보 관리 여신 상담	​ ​ ​ 거래처 정보 등록 대상거래 파악 상담결과 보고 신용조사 의뢰

​

시스템 인터페이스 파악

- 단위 업무 시스템 간에 주고 받는 데이터의 종류, 형식, 프로토콜, 연계 유형, 주기 등을 명시함.

- 데이터를 어떤 형식(XML, 고정포멧 등)으로 주고 받는지, 통신 규약(TCP/IP, X25등)은 무엇을 사용하는지, 연계 유형(EAI, FEP 등)은 무엇인지를 반드시 고려해야 함

(예) 여신상담관리 시스템의 인터페이스 현황

송신 시스템	수신시스템	연동데이터	연동 형식	통신규약	연계 유형	주기
여신상담관리시스템	여신관리센터	연체정보	XML	TCP/IP	EAI	하루

​

아키텍처 구성 파악

- 업무 수행에 어떠한 기술 요소들이 사용되는지 최상위 수준에서 계층별로 표현한 아키텍처 구성도로 작성됨.

- 아키텍처가 단위 업무 시스템별로 다른 경우에는 가장 핵심이 되는 기간 업무 처리 시스템을 기준으로 표현함.

(예) 회원정보 관리 시스템 아키텍처 구성도

​

소프트웨어 구성 파악

- 단위 업무 시스템별로 업무 처리를 위해 설치되어 있는 소프트웨어들의 제품명, 용도, 라이선스 적용 방식, 라이선스 수 등을 명시함.

- 시스템 구축비용 면에서 소프트웨어 비용이 적지 않은 비중을 차지하므로 상용 소프트웨어(정식으로 대가를 지불하고 사용해야 하는 것)의 경우 라이선스 적용 방식(사이트, 서버, 프로세서(CPU), 동시사용, 코어, 사용자 수 등)의 기준과 보유한 라이선스의 파악이 중요함.

​

하드웨어 구성 파악

- 단위 업무 시스템들이 운용되는 서버의 주요 사양(서버의 CPU 처리속도, 메모리크기, 하드디스트의 용량)과 수량, 그리고 이중화 적용 여부(운용 서버의 장애 시 대기 서버로 서비스를 계속 유지할 수 있도록 운용 서버의 자료 변경이 예비 서버에도 동일하게 복제되도록 관리하는 것)를 명시한다.

- 서버의 이중화는 기간 업무의 서비스 기간, 장애 대응 정책에 따라 필요 여부가 결정됨.

- 현행 시스템의 이중화가 적용된 경우 대부분 새로 구성될 시스템에도 이중화가 필요하므로 이로 인한 비용 증가와 시스템 구축 난이도가 높아질 가능성을 고려해야 함.

 

네트워크 구성 파악

- 업무 시스템들의 네트워크 구성을 파악할 수 있도록 서버의 위치, 서버 간의 네트워크 연결 방식을 네트워크 구성도로 작성함.

- 네트워크 구성도를 통해 서버들의 물리적인 위치 관계를 파악할 수 있고 보안 취약성을 분석하여 적절한 대응을 할 수 있음.

- 네트워크에 장애가 발생한 경우 발생 원인을 찾아 복구하기 위한 용도로 활용될 수 있음.

​

​

2.2 개발 기술 환경 파악

개발 기술 환경의 정의

- 개발하고자 하는 소프트웨어와 관련된 운영체제, 데이터베이스 관리 시스템, 미들웨어(운영 체제와 해당 운영 체제에 의해 실행되는 응용 프로그램 사이에서 운영체제가 제공하는 서비스 외에 추가적인 서비스를 제공하는 소프트웨어) 등을 선정할 때 고려해야할 사항을 기술함.

- 오픈 소스 사용시 주의해야할 내용을 제시함.

​

운영체제(Operating System)

- 컴퓨터 시스템의 자원들을 효율적으로 관리하며, 사용자가 컴퓨터를 편리하고 효율적으로 사용할 수 있도록 환경을 제공하는 소프트웨어.

- 컴퓨터 사용자와 컴퓨터 하드웨어 간의 인터페이스로서 동작하는 시스템 소프트웨어의 일종으로, 다른 응용 프로그램이 유용한 작업을 할 수 있도록 환경을 제공해줌.

- 종류: Windows, UNIX, Linux, Mac OS, 모바일 OS- Android, iOS, Tizen 등

​

운영 체제 관련 요구사항 식별시 고려 사항

- 가용성(프로그램이 주어진 시점에서 요구사항에 따라 운영될 수 있는 능력)

• 시스템의 장시간 운영으로 인해 발생할 수 있는 운영체제 고유의 장애 발생 가능성
• 메모리 누수(응용 프로그램이 더이상 사용하지 않는 메모리를 반환하지 않고 계속 점유하고 있는 현상)로 인한 성능 저하 및 재가동
• 보안상 발견된 허점을 보완하기 위한 지속적인 패치 설치로 인한 재가동

- 성능

• 대규모 동시 사용자 요청에 대한 처리
• 대규모 및 대용량 파일 작업에 대한 처리
• 지원 가능한 메모리 크기 (32bit, 64bit)

- 기술지원

• 제작 업체의 안정적인 기술 지원
• 여러 사용자들간의 정보 공유
• 오픈 소스 여부 (Linux)

- 주변 기기

• 설치 가능한 하드웨어
• 여러 주변기기 지원 여부

- 구축 비용

• 지원 가능한 하드웨어 비용
• 설치할 응용 프로그램의 라이선스 정책 및 비용
• 유지관리 비용
• 총 소유 비용(TCO: Total Cost of Ownership, 어떤 자산을 획득하려고 할때 지정된 기간동안 발생할 수 있는 모든 직간접 비용)

​

데이터베이스 관리 시스템(DBMS)

- 사용자와 데이터베이스 사이에서 사용자의 요구에 따라 정보를 생성해주고 데이터베이스를 관리해주는 소프트웨어

- 기존의 파일 시스템이 갖는 데이터의 종속성과 중복성의 문제를 해결하기 위해 제안된 시스템. 모든 응용 프로그램들이 데이터베이스를 공용할 수 있도록 관리해 줌.

- 데이터베이스의 구성, 접근 방법, 유지 관리에 대한 모든 책임을 짐.

- 종류: Oracle, IBM DB2, Microsoft SQL Server, MySQL, SQLite, MongoDB, Redis 등

​

DBMS 관련 요구사항 식별시 고려 사항

- 가용성

시스템의 장시간 운영으로 인해 발생할 수 있는 운영체제 고유의 장애 발생 가능성

DBMS의 결함 등으로 인한 패치 설치를 위한 재가동

백업이나 복구의 편의성

DBMS 이중화 및 복제 지원

- 성능

대규모 데이터 처리 성능

대용량 트랜잭션 처리 성능

비용기반 질의 최적화(사용자의 질의에 대한 최적의 실행 방법을 결정하기 위한 것. 질의에 대한 다양한 실행 방법을 만들고 각각의 방법에 대해 비용을 추정함. 비용 추정은 실행에 필요한 소요 시간과 자원 사용량을 기준으로 추정하며 추정된 비용이 가장 최소적인 방법을 선택하게 됨) 지원

- 기술지원

제작 업체의 안정적인 기술 지원

여러 사용자들간의 정보 공유

오픈 소스 여부 (Linux)

- 상호호환성

설치 가능한 운영체제의 종류

JDBC(Java Database Connectivity: 자바와 디비를 연결해주는 인터페이스)와 ODBC(응용 프로그램과 디비를 연결해주는 표준 인터페이스)와의 호환 여부

- 구축 비용

라이선스 정책 및 비용

유지관리 비용

총 소유 비용

웹 어플리케이션 서버 (WAS)

- 정적인 콘텐츠 처리를 하는 웹 서버와 달리 사용자의 요구에 따라 변하는 동적인 콘텐츠(주식 시세 정보, 날씨 위성 정보와 같이 실시간으로 변하는 자료)를 처리하기 위해 사용되는 미들웨어.

- 웹어플리케이션 서버가 JSP나 서블릿과 같은 프로그램을 구동하여 동적 자료를 처리한 후, 해당 정보를 웹 서버로 보내면 이를 클라이언트로 보내는 것.

- 데이터 접근, 세션 관리, 트랜잭션 관리 등을 위한 라이브러리 제공

- 주로 데이터베이스 서버와 연동해서 사용.

- 종류: Tomcat, GlassFish, JBoss, Jetty, JEUS, Resin, WebLogic, WebSphere 등

​

웹 어플리케이션 서버 관련 요구사항 식별시 고려 사항

- 가용성

시스템의 장시간 운영으로 인해 발생할 수 있는 운영체제 고유의 장애 발생 가능성

WAS의 결함 등으로 인한 패치 설치를 위한 재가동

안정적인 트랜잭션 처리

WAS 이중화 지원

- 성능

대규모 트랜잭션 처리 성능

가비지 컬렉션(GC, 실제로는 사용되지 않으면서 가용 공간 리스트에 반환되지 않는 메모리 공간인 가비지를 강제로 해제하여 사용할 수 있도록 하는 메모리 관리 기법)의 다양한 옵션

- 기술지원

제작 업체의 안정적인 기술 지원

여러 사용자들간의 정보 공유

오픈 소스 여부

- 구축 비용

라이선스 정책 및 비용

유지관리 비용

총 소유 비용

​

오픈 소스 사용에 따른 고려 사항

- 오픈소스: 누구나 별다른 제한 없이 사용할 수 있도록 소스코드를 공개한 것으로 오픈 소스 라이선스를 만족하는 소프트웨어

- 라이선스의 종류, 사용자 수, 기술의 지속 가능성을 고려해야 함.

​

 

2.3 요구사항 정의

요구사항의 개념 및 특징

- 소프트웨어가 어떤 문제를 해결하기 위해 제공하는 서비스에 대한 설명과 정상적으로 운영되는데 필요한 제약 조건 등을 나타냄.

- 소프트웨어는 사용자의 요구사항을 충족시키기 위해 설계되고 개발됨.

- 소프트웨어 개발이나 유지 보수 과정에서 필요한 기준과 근거를 제공.

- 개발하려는 소프트웨어의 전반적인 내용을 확인할 수 있게 하므로 개발에 참여하는 이해관계자들 간의 의사소통을 원활하게 하는데 도움을 줌.

- 요구사항이 제대로 정의되어야만 이를 토대로 이후 과정의 목표와 계획을 수립할 수 있음.

​

요구사항의 유형

- 기술하는 내용에 따라 기능 요구사항/비기능 요구사항으로 구분하며, 기술 관점과 대상의 범위에 따라 시스템 요구사항/사용자 요구사항으로 나뉨.

- 기능 요구사항

• 시스템이 무엇을 하는지, 어떤 기능을 하는지에 대한 사항.
• 시스템의 입력이나 출력으로 무엇이 포함되어야 하는지, 시스템이 어떤 데이터를 저장하거나 연산을 수행해야 하는지.
• 시스템이 반드시 수행해야 하는 기능
• 사용자가 시스템을 통해 제공받기 원하는 기능

- 비기능 요구사항

• 시스템 장비 구성 요구사항: 하드웨어, 소프트웨어, 네트워크 등
• 성능 요구사항: 처리 속도 및 시간, 처리량, 동적/정적 적용량, 가용성 등
• 인터페이스 요구사항: 시스템 인터페이스와 사용자 인터페이스에 대한 요구사항으로 다른 소프트웨어, 하드웨어 및 통신 인터페이스, 다른 시스템과의 정보 교환에 사용되는 프로토콜과의 연계도
• 데이터 요구사항: 초기 자료 구축 및 데이터 변환을 위한 대상, 방법, 보안이 필요한 데이터 등 데이터를 구축하기 위해 필요한 요구사항
• 테스트 요구사항: 도입되는 장비의 성능 테스트나 구축된 시스템이 제대로 운영되는지를 테스트하고 점검하기 위한 요구사항
• 보안 요구사항: 시스템의 데이터 및 기능, 운영 접근을 통제하기 위한 요구사항
• 품질 요구사항: 관리가 필요한 품질 항목, 품질 평가 대상에 대한 요구사항. 가용성(사용하고자 할 때 언제라도 사용할 수 있는 정도), 정합성(데이터의 값이 서로 모순 없이 일관되게 일치하는 정도), 상호 호환성(다른 소프트웨어와 정보를 교환할 수 있는 정도), 대응성(발생한 상황에 대처하는 정도), 신뢰성, 사용성, 유지/관리성, 이식성(다양한 하드웨어 환경에서도 운용 가능하도록 쉽게 수정될 수 있는 정도), 확장성(규모나 범위를 넓힐 수 있는 정도), 보안성 등으로 구분하여 기술
• 제약사항: 시스템 설계, 구축, 운영과 관련하여 사전에 파악된 기술, 표준, 업무, 법/제도 등의 제약조건
• 프로젝트 관리 요구사항
• 프로젝트 지원 요구사항

- 사용자 요구사항

• 사용자 관점에서 본 시스템이 제공해야 할 요구사항
• 사용자를 위한 것으로 친숙한 표현으로 이해하기 쉽게 작성됨

- 시스템 요구사항

• 개발자 관점에서 본 시스템 전체가 사용자와 다른 시스템에 제공해야 할 요구사항.
• 사용자 요구사항에 비해 전문적이고 기술적인 용어로 표현
• 소프트웨어 요구사항이라고도 함.

​

요구사항 개발 프로세스

- 개발 대상에 대한 요구사항을 체계적으로 도출하고 이를 분석한 후 분석 결과를 명세서에 정리한 다음 마지막으로 이를 확인 및 검증하는 일련의 구조화된 활동.

- 도출 -> 분석 -> 명세 -> 확인

- 요구사항 개발 프로세스가 진행되기 전에 개발 프로세스가 비즈니스 목적에 부합되는지, 예산은 적정한지 등에 대한 정보를 수집, 평가한 보고서를 토대로 타당성 조사가 선행되어야 한다.

- 요구사항 개발은 요구 공학의 한 요소이다.

- 요구 공학(Requirement Engineering)

• 무엇을 개발해야 하는지 요구 사항을 정의하고 분석 및 관리하는 프로세스를 연구하는 학문.
• 점점 복잡하고 대형화 되는 소프트웨어 개발 환경에 따라 사용자 요구사항도 더욱 복잡해지고 잦은 변경이 발생하는데, 이는 요구사항에 문제가 발생할 가능성을 높이며 요구사항 관리가 잘못될 수 있는 원인이 된다.
• 요구 공학은 요구사항 변경의 원인과 처리 방법을 이해하고 요구사항 관리 프로세스의 품질을 개선하여 소프트웨어 프로젝트 실패를 최소화하는 것을 목표로 함.
• 요구 공학 > 요구 사항 관리 > 요구사항 개발

​

요구사항 도출(Requirement Elicitation, 요구사항 수집)

- 시스템, 사용자, 시스템 개발에 관련된 사람들이 서로 의견을 교환하여 요구사항이 어디에 있는지, 어떻게 수집할 것인지를 식별하고 이해하는 과정.

- 소프트웨어가 해결해야 할 문제를 이해하는 첫 번째 단계.

- 이 단계에서 개발자와 고객 사이의 관계가 만들어지고 이해관계자가 식별됨.

- 다양한 이해관계자 간의 효율적인 의사소통이 중요.

- 요구사항 도출은 소프트웨어 개발 생명 주기 동안 지속적으로 반복됨.

- 주요 기법: 인터뷰, 설문, 브레인스토밍, 워크샵, 프로토타이핑(프로토타입을 통해 효과적으로 요구 분석을 수행하면서 명세서를 산출하는 작업. 종이에 대략적인 순서나 형태를 그려 보여주는 것), 유스케이스(사용자의 요구사항을 기능 단위로 표현하는 것)

요구사항 분석(Requirement Analysis)

- 개발 대상에 대한 사용자의 요구사항 중 명확하지 않거나 모호하여 이해되지 않는 부분을 발견하고 이를 걸러내기 위한 과정.

- 사용자 요구사항의 타당성을 조사하고 비용과 일정에 대한 제약을 설정함.

- 내용이 중복되거나 하나로 통합되어야 하는 등 서로 상충되는 요구사항이 있으면 이를 해결함.

- 도출된 요구사항들을 토대로 소프트웨어의 범위를 파악하고, 소프트웨어와 주변 환경이 상호 작용하는 방법을 이해함.

​

요구사항 명세(Requirement Specification)

- 요구사항을 체계적으로 분석한 후 승인될 수 있도록 문서화하는 것을 의미함.

- 요구사항을 문서화 할 때는 기능 요구사항은 빠짐없이 완전하고 명확하게 기술해야 하고, 비기능 요구사항은 필요한 것만 명확하게 기술해야 함.

- 요구사항은 사용자가 이해하기 쉬우며, 개발자가 효과적으로 설계할 수 있도록 작성되어야 함.

- 설계 과정에서 잘못된 부분이 확인될 경우, 그 내용을 요구사항 정의서에서 추적할 수 있어야 함.

- 소프트웨어 요구사항 명세서

• 업계 표준 용어로 소프트웨어가 반드시 제공해야 하는 기능, 특징, 제약 조건을 명시함.
• 시스템의 모든 동작 뿐만 아니라 성능, 보안, 사용성과 같은 품질도 기술되어야 함.
• 시스템 기능, 데이터, 외부 인터페이스, 품질 요구사항은 요구사항 단위별로 개별 요구사항 명세서를 작성함.

​

요구사항 확인(Requirement Validation, 요구사항 검증)

- 개발 자원을 요구사항에 할당하기 전에 요구사항 명세서가 정확하고 완전하게 작성되었는지를 검토하는 활동.

- 분석가가 요구사항을 정확하게 이해한 후 요구사항 명세서를 작성했는지 확인하는것이 필요하다.

- 요구 사항 명세서의 내용이 이해하기 쉬운지, 일관성은 있는지, 회사의 기준에는 맞는지, 누락된 기능은 없는지 검증하는 것이 중요함.

- 요구사항 문서는 이해관계자들이 검토해야 함.

- 일반적으로 요구사항 관리 도구를 이용하여 요구사항 정의 문서들에 대해 형상관리를 수행.

- 형상관리: 형상(소프트웨어 개발 단계의 각 과정에서 만들어지는 프로그램, 설명 문서, 데이터 등을 통칭하는 말) 관리는 소프트웨어의 개발 과정에서 만들어지는 형상들의 변경 사항들을 관리하는 일련의 활동.

​

2.4 요구사항 분석 기법

요구사항 분석 기법

- 개발 대상에 대한 사용자의 요구사항 중 명확하지 않거나 모호한 부분을 걸러내기 위한 방법.

- 종류: 요구사항 분류, 개념 모델링, 요구사항 할당, 요구사항 협상, 정형 분석 등

​

요구사항 분류(Requirement Classification)

- 요구사항을 명확히 확인 할 수 있도록 다음과 같은 기준으로 분류

기능 요구사항, 비기능 요구사항

하나 이상의 상위 요구 사항에서 유도된 것인지, 또는 이해 관계자나 다른 원천으로 부터 직접 발생한 것인지 분류

개발할 제품에 관한 것인지, 개발 과정에 관한 것인지

우선순위에 따라

소프트웨어에 미치는 영향의 범위에 따라

생명 주기 동안에 변경 가능성이 있는지 여부에 따라.

​

개념 모델링(Conceptual Modeling)

-모델: 요구사항을 보다 쉽게 이해할 수 있도록 현실 세계의 상황을 단순화하여 개념적으로 표현한 것, 모델링: 이러한 모델을 만드는 과정

- 모델은 문제가 발생하는 상황을 쉽게 이해시키고 해결책을 설명할 수 있으므로 실세계 문제에 대한 모델링은 소프트웨어 요구사항 분석의 핵심이다.

- 개념 모델은 문제의 주체인 개체(Entity, 현실 세계의 사람과 같은 물지겆이고 개념적인 것으로 요구사항 분석에서는 기능이 적용 되는 시스템이나 기능을 사용하는 사람 등을 의미함)들과 그들간의 관계 및 종속성(Dependency, A가 B를 통해서만 수행할 때 A는 V에 종속적이라고 표현)을 반영한다.

- 요구사항을 이해하는 이해 관계자별로 관점이 다양하므로 그에 맞게 개념 모델도 다양하게 표현되어야 함.

​

요구사항 할당(Requirement Allocation)

- 요구사항을 만족시키기 위한 구성 요소를 식별하는 것.

- 식별된 구성 요소들 간에 어떻게 작용하는지 분석하는 과정에서 추가적인 요구사항이 발견될 수 있음.

​

요구사항 협상(Requirement Negotiation)

- 요구사항이 서로 충돌될 경우 이를 적절히 해결하는 과정.

- 요구사항이 다음과 같은 이유(두명의 이해관계자의 요구사항이 충돌, 요구사항과 자원이 서로 충돌, 기능 요구사항과 비기능 요구사항이 충돌)로 충돌된다면 어느 한쪽에 맞추기 보다는 적절한 기준점을 찾아 합의해야 함.

- 요구사항이 충될될 때 각각 우선순위를 부여하면 문제 해결에 도움이 될 수 있음.

​

정형 분석(Formal Analysis)

- 구문과 의미를 갖는 정형화된 언어를 이용해 요구사항을 수학적 기호로 표현한 후, 이를 분석하는 과정.

- 요구사항 분석의 마지막 단계에서 이루어짐.

​

SCRIPT

document.write('<p><ins class="adsbygoogle" style="display: block; text-align: center;" data-ad-layout="in-article" data-ad-format="fluid" data-ad-client="ca-pub-1737028579323819" data-ad-slot="1404114538"></ins></p>'); (adsbygoogle = window.adsbygoogle || []).push({});

2.5 요구사항 확인 기법

요구사항 확인 기법

- 요구사항 개발 과정을 거쳐 문서화된 요구사항 관련 내용을 확인하고 검증하는 방법.

- 요구사항에 자원이 배정되기 전에 문제 파악을 위한 검증을 수행해야 함.

- 종류: 요구사항 검토, 프로토타이핑, 모델 검증, 인수 테스트 등

​

요구사항 검토(Requirement Reviews)

- 문서화된 요구사항을 훑어보면서 확인하는 것으로 가장 일반적인 요구사항 검증 방법.

- 요구사항 검토자들은 요구사항 검토를 통해 명확하지 않은 내용은 없는지, 가정이 잘못되지는 않았는지, 정해진 기준을 벗어나지는 않는지 등을 찾아냄

- 요구사항 검토자 그룹을 구성할 때는 구성 방법이 중요한데 예를 들어 고객 중심 프로젝터에 대한 검토자 그룹에는 고객 대표자가 꼭 포함되어야 함.

- 검토는 시스템 정의서, 시스템 사양서, 소프트웨어 요구사항 명세서 등을 완성한 시점에 이루어짐.

​

프로토타이핑(Prototyping)

- 초기 도출된 요구사항을 토대로 프로토타입을 만든 후 대상 시스템의 개발이 진행되는 동안 도출되는 요구사항을 반영하면서 지속적으로 프로토타입을 재작성하는 과정.

- 프로토타입: 상품이나 서비스가 출시되기 전에 개발 대상 시스템 또는 그 일부분을 개략적으로 만든 원형

- 프로토타이핑을 수행하면서 새로운 요구사항이 도출될 수 있음.

- 소프트웨어 요구사항에 대한 소프트웨어 엔지니어의 해석이 맞는지 확인하기 위한 수단으로 주로 사용.

- 장점

• 빠르게 제작할 수 있으며 반복되는 제작을 통해 발전된 결과물을 얻을 수 있음.
• 최종 시스템을 완성하기 전에 추가/변경 요구사항이나 아이디어 등에 대한 피드백이 가능.
• 이해하기 쉬워 사용자와 개발자 사이의 의사소통이 원활해짐.
• 개발될 시스템의 사용에 대한 문제점을 시스템 완성전에 식별할 수 있음,.
• 프로토타입이 개선될 수록 변동 가능한 요구사항이 감소함.

- 단점

• 사용자의 관심이 핵심에서 벗어나 프로토타입 제작에만 집중될 수 있음.
• 개발 대상의 일부만을 대상으로 프로토타입이 제작된 겨우 대상 범위를 잘못 이해하여 사용성이 과대평가될 수 있음.
• 지속적이고 반복적인 프로토타입의 개선으로 인한 비용이 부담될 수 있음.

​

모델 검증(Model Verification)

- 요구사항 분석 단계에서 개발된 모델이 요구사항을 충족시키는지 검증하는 것.

- 객체 모델의 경우 객체들 사이에 존재하는 의사소통 경로를 검증하기 위하여 정적 분석을 수행하는 것이 유용함.

- 정적 분석: 실행을 통해서 확인하는 것이 아니라 명세서의 정확성이나 일관성 등을 확인하거나 분석 도구를 사용해 확인하는 방법. 직접 실행을 통해 확인하는 방법은 동적분석.

​

인수 테스트(Acceptance Tests)

- 사용자가 실제로 사용될 환경에서 요구사항들이 모두 충족되는지 사용자 입장에서 확인하는 과정.

- 각각의 요구사항을 어떻게 확인할 것인지에 대한 계획 필요.

- 종류: 사용자 인수 테스트, 운영상의 인수 테스트, 계약 인수 테스트, 규정 인수 테스트, 알파 검사, 베타 검사

​

2.6 UML(Unified Modeling Language)

UML의 개요

- 시스템 분석, 설계, 구현 등 시스템 개발 과정에서 시스템 개발자와 고객, 또는 개발자 간의 의사소통을 원활하게 이루어지도록 표준화한 객체지향 모델링 언어.

- 모델링 언어: 우리가 만들고자 하는 것을 시각적으로 표현할 수 있는 표기법, 도구 등

- UML은 Rumbaugh(OMT), Booch, Jacobson 등의 객체지향 방법론의 장점 OMG에서 표준으로 지정함.

- UML을 이용하여 시스템 구조를 표현하는 6개의 구조 다이어그램과 시스템의 동작을 표현하는 7개의 행위 다이어그램을 작성할 수 있음.

-각각의 다이어그램은 사물과 사물 간의 관계를 용도에 맞게 표현함.

- 구성요소: 사물, 관계, 다이어그램

​

사물(Things)

- 모델을 구성하는 가장 중요한 기본 요소로 다이어그램 안에서 관계가 형성될 수 있는 대상들.

- 구조 사물

• 시스템의 개념적, 물리적 요소를 표현.
• 클래스, 유스케이스, 컴포넌트(소스코드, 라이브러리와 같은 모듈화된 자원으로 재사용이 가능), 노드 등

- 행동 사물

• 시간과 공간에 따른 요소들의 행위를 표현.
• 상호작용, 상태머신 등

- 그룹 사물

• 요소들을 그룹으로 묶어서 표현
• 패키지

- 주해 사물

• 부가적인 설명이나 제약조건 등을 표현
• 노트

​

관계(Relationships)

- 사물과 사물 사이의 연관성을 표현하는 것.

- 종류: 연관관계, 집합관계, 포함관계, 일반화관계, 의존 관계, 실체화 관계 등

​

연관(Association) 관계

- 2개 이상의 사물이 서로 관련되어 있음을 표현함.

- 사물의 사이를 실선으로 연결, 방향성은 화살표로 표현.

- 양방향은 화살표 생략.

- 다중도: 연관에 참여하는 객체의 개수를 선 위에 표시함.

• 1 : 1개의 객체가 연관되어 있다.
• n: n개의 객체가 연관되어 있다.
• 0..1: 연관된 객체가 없거나 1개다.
• 0..* 또는 ..*: 연관된 객체가 없거나 다수.
• 1..*: 연관된 객체가 적어도 1개
• n..*: 연관된 객체가 적어도 n개
• n..m: 최소 n개에서 최대 m개

​

집합(Aggregation) 관계

- 하나의 사물이 다른 사물에 포함되어있는 관계를 표현.

- 포함하는 쪽(전체)과 포함되는 쪽(부분)은 서로 독립적.

- 포함되는 쪽(부분)에서 포함하는 쪽(전체)으로 속이 빈 마름모를 연결하여 표현.

(예) 프린터는 컴퓨터에 연결해서 사용할 수 있으며, 다른 컴퓨터에 연결해서 사용할 수도 있다.

​

포함(Composition) 관계

- 집합관계의 특수한 형태로, 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계.

- 포함하는 쪽(전체)과 포함되는 쪽(부분)은 서로 독립될 수 없고 생명 주기를 함께함.

- 포함되는 쪽(부분)에서 포함하는 쪽(전체)으로 속이 채워진 마름모를 연결하여 표현.

(예) 문을 열 수 있는 키는 하나며 해당 키로 다른 문은 열 수 없다. 문이 없어지면 키도 더이상 필요하지 않는다.

​

일반화(Generalization) 관계

- 하나의 사물이 다른 사물에 비해 더 일반적인지 구체적인지를 표현.

- 보다 일반적인 개념을 상위(부모), 보다 구체적인 개념을 하위(자식)라고 부름.

​

의존(Dependency) 관계

- 사물 사이에 서로 연관은 있으나 필요에 의해서 짧은 시간 동안만 서로에게 영향을 주는 관계를 표현.

- 하나의 사물과 다른 사물이 소유 관계는 아니지만 사물의 변화가 다른 사물에게도 미치는 관계.

(예)등급이 높으면 할인율을 적용하고, 등급이 낮으면 적용하지 않는다.

실체화(Realization) 관계

- 사물이 할 수 있거나 해야하는 기능(행위, 인터페이스)으로 서로를 그룹화 할 수 있는 관계를 표현.

(예) 비행기는 날 수도 있고 새도 날 수 있음. 그래서 비행기와 새는 날 수 있다는 행위로 그룹화 할 수 있음.

​

다이어그램(Diagram)

- 사물과 관계를 도형으로 표현한 것.

- 여러 관점에서 시스템을 가시화한 뷰를 제공함으로써 의사소통에 도움을 줌.

- 정적 모델링에서는 주로 구조적 다이어그램을 사용하고 동적 모델링 에서는 주로 행위 다이어그램을 사용.

- 6종류의 구조적 다이어그램과 7종류의 행위 다이어그램

​

구조적 다이어그램의 종류

- 클래스 다이어그램

• 클래스와 클래스가 가지는 속성, 클래스 사이의 관계를 표현.
• 시스템의 구조를 파악하고 구조상의 문제점을 도출할 수 있음.

- 객체 다이어그램

• 클래스에 속한 사물, 즉 인스턴스를 특정 시점의 객체와 객체 사이의 관계로 표현.

- 컴포넌트 다이어그램

• 실제 구현 모듈인 컴포넌트 간의 관계나 컴포넌트 간의 인터페이스를 표현.
• 구현 단계에서 사용되는 다이어그램.

- 배치 다이어그램

• 결과물, 프로세스, 컴포넌트 등 물리적인 요소들의 위치를 표현.
• 노드와 의사소통(통신) 경로로 표현.
• 구현 단계에서 사용되는 다이어그램.

- 복합체 구조 다이어그램

• 클래스나 컴포넌트가 복합 구조를 갖는 경우 그 내부 구조를 표현.

- 패키지 다이어그램

• 유스케이스나 클래스 등 모델 요소들을 그룹화한 패키지들의 관계를 표현.

​

행위 다이어그램의 종류

- 유스케이스 다이어그램

• 사용자의 요구를 분석하는 것으로 기능 모델링 작업에 사용.
• 사용자와 사용 사례로 구성되며, 사용 사례 간에는 여러 형태의 관계로 이루어 짐.

- 시퀀스 다이어그램

• 상호 작용하는 시스템이나 객체들이 주고 받는 메시지를 표현.

- 커뮤니케이션 다이어그램

• 동작에 참여하는 객체들이 주고받는 메시지 뿐만 아니라 객체들간의 연관까지 표현.

- 상태 다이어그램

• 하나의 객체가 자신이 속한 클래스의 상태 변화 혹은 다른 객체와의 상호 작용에 따라 상태가 어떻게 변화하는지를 표현.

- 활동 다이어그램

• 시스템이 어떤 기능을 수행하는지 객체의 처리 로직이나 조건에 따른 처리의 흐름을 순서에 따라 표현.

- 상호작용 개요 다이어그램

• 상호 작용 다이어 그램 간의 제어 흐름을 표현.

- 타이밍 다이어그램

• 객체 상태 변화와 시간 제약을 명시적으로 표현.

​

2.7 유스케이스(Use Case) 다이어그램

기능 모델링의 개념

- 사용자가 요구한 기능들이 어떻게 작동하는지를 설명하기 위해 구현될 모습을 그림으로 표현한 것.

- 개발될 시스템의 전반적인 형태를 기능에 초점을 맞춰 표현함.

- UML의 기능 모델링 종류: 유스케이스 다이어그램, 활동 다이어그램

​

유스케이스 다이어그램의 개념

- 개발될 시스템과 관련된 외부 요소들(사용자와 다른 외부 시스템들이 개발될 시스템을 이용해 수행할 수 있는 기능)을 사용자의 관점에서 표현한 것.

- 외부 요소와 시스템 간의 상호 작용을 확인할 수 있음.

- 사용자의 요구사항을 분석하기 위한 도구로 사용된.

- 시스템의 범위를 파악할 수 있음.

​

유스케이스 다이어그램의 구성요소

- 종류: 시스템/시스템 범위, 액터, 유스케이스, 관계

​

시스템/ 시스템 범위

- 시스템 내부에서 수행되는 기능들을 외부 시스템과 구분하기 위해 시스템 내부의 유스케이스를 사각형으로 묶어 시스템의 범위를 표현함.

- 사각형 안쪽 상단에 시스템 명칭을 기술

(예) 사각형을 통해 <상품 주문> 시스템의 범위를 알 수 있음.

​

액터

- 시스템과 상호작용을 하는 모든 외부 요소. 사람이나 외부 시스템을 의미함.

- 시스템에 대해 수행할 수 있는 역할을 의미하기도 함.

- 액터 이름이 구체적이면 안됨. 예제의 회원 액터의 이름을 홍길동이라고 하면 그 한 사람만 사용할 수 있다는 의미가 됨

- 주액터(Primary Actor)

• 시스템을 사용함으로써 이득을 얻는 대상으로 주로 사람이 해당됨.
• ​사람 형태를 간략화 하여 표현하며, 주로 시스템의 왼쪽에 배치
• 예제에서 ‘비회원’, ‘회원’, ‘고객’이 해당됨.

- 부액터(Secondary Actor)

• 주액터의 목적 달성을 위해 시스템에 서비스를 제공하는 외부 시스템. 조직이나 기관등이 해당됨.
• 주로 시스템의 오른쪽에 배치하며, 시스템 명을 사각형으로 묶은 후, 상단에 <<Actor>>라고 표기함.
• 예제에서 ‘재고시스템’, ‘결제 시스템’, ‘배송업체’​

유스케이스

- 사용자가 보는 관점에서 시스템이 액터에게 제공하는 서비스 또는 기능을 표현한 것.

- 타원으로 표현하며, 타원 안쪽이나 아래쪽에 유스케이스 이름을 기술함.

- 유스케이스 이름은 액터와 시스템 사이에서 이뤄지는 상호 작용을 목적을 내포하되 단순 명료하게 기술.

- 기능적 요소를 중심으로 기술하지만 비기능적 요소를 포함할 수 있음.

- 더 이상 분할되지 않는 기능의 단위.

- 액터에 의해 수행되며, 액터가 관찰할 수 있는 결과를 산출함.

- 하나의 유스케이스 안에서 수행되는 동작은 유스케이스 수행시 모두 수행되어야 하며, 부분적인 수행은 허용되지 않음.

- 유스케이스는 분석, 설계, 테스트 등 개발 전 과정에서 이용될 수 있음.

- 예제에서 상품조회, 리뷰작성 등이 해당됨.

​

관계

- 유스케이스 다이어그램의 관계는 액터와 유스케이스, 유스케이스와 유스케이스 사이에서 나타날 수 있음.

- 종류: 포함 관계, 확장 관계, 일반화 관계

- 포함 관계

두 개 이상의 유스케이스에 공통적으로 적용되는 기능을 별도로 분리하여 새로운 유스케이스로 만든 경우, 원래의 유스케이스와 새롭게 분리된 유스케이스와의 관계

원래의 유스케이스에서 새롭게 만든 포함되는 유스케이스 쪽으로 점선 화살표를 연결한 후 화살표 위에 <<include>> 라고 표기.

예제) 상품 주문 ---- > 로그인, 회원은 상품 주문을 수행하기 위해서 ‘로그인’을 수행해야 한다고 해석한다.

- 확장 관계

유스케이스가 특정 조건에 부합되어 유스케이스의 기능이 확장될 때 원래의 유스케이스와 확장된 유스케이스와의 관계

확장될 유스케이스에서의 원래 유스케이스 쪽으로 점선 화살표를 연결한 후 <<extends>>라고 표기.

예제) 리뷰 작성 < --- 사진 업로드, 회원은 리뷰 작성 수행 도중 경우에 따라 사진 업로드를 수행한다고 해석.

- 일반화 단계

유사한 액터나 유스케이스를 하나의 그룹으로 묶고 싶을 때 그보다 일반적인 액터나 유스케이스를 만들어 이를 연결하여 표현하는 관계

하위 액터/유스케이스가 상위 액터/유스케이스로 일반화되는 관계는 상위 액터/유스케이스가 하위 액터/유스케이스로 구체화되는 관계라고도 할 수 있음.

하위 액터/유스케이스가 상위 액터/유스케이스에게 역할이나 기능을 상속받는 관계.

하위 액터/유스케이스에서 상위 액터/유스케이스 쪽으로 속이 빈 삼각형 화살표를 실선으로 연결

예제) 상품조회 ◁ㅡㅡ 이름으로 조회/브랜드로 조회, 상품 조회의 종류에는 이름으로 조회와 브랜드로 조회가 있다.

​

유스케이스 명세서(기술서)

- 유스케이스 안에서의 액터와 시스템 간의 상호작용 과정을 글로 자세히 표현한 것.

- 유스케이스 다이어그램에 있는 모든 유스케이스에 대해 개별적으로 작성해야 함.

- 각 유스케이스 명세서에 작성된 사건의 흐름을 참고하여 활동 다이어그램을 작성함.

(예) 상품 주문 유스케이스 명세서 내용: 액터명, 목표, 시작 조건, 이후 조건, 정상적인 흐름, 대안 흐름(경우에 따라)

 

 

​

 

 

2.8 활동(Activity) 다이어그램

​

활동 다이어그램의 개념

- 활동 다이어그램은 자료 흐름도와 유사한 것으로, 사용자 관점에서 시스템이 수행하는 기능을 처리 흐름에 따라 순서대로 표현한 것.

- 자료 흐름도(DFD, Data Flow Diagram): 자료는 각 절차에 따라 컴퓨터 기반의 시스템 내부를 흘러 다니는데, 이를 자료의 흐름이라고 함. 자료 흐름도는 요구사항 분석에서 자료의 흐름 및 변환 과정과 기능을 도형 중심으로 기술하는 방법. 자료 흐름 그래프/버블차트 라고도 함.

- 하나의 유스케이스 안에서나 유스케이스 사이에 발생하는 복잡한 처리의 흐름을 명확하게 표현할 수 있음.

​

활동 다이어그램의 구성 요소

- 종류: 액션, 액티비티, 노드, 스윔레인

- 액션/액티비티

액션: 더 이상 분해할 수 없는 단일 작업.

액티비티: 몇개의 액션으로 분리될 수 있는 작업.

모두 테두리가 있는 둥근 사각형으로 표현

예제) 액션: 로그인 클릭, 주문 완료 / 액티비티: 회원 정보 입력, 주문 상품 선택, 상품 재고 확인

- 제어 흐름

실행의 흐름을 표현

화살표로 표현

- 시작 노드

액션이나 액티비티가 시작됨을 의미.

하나의 다이어그램 안에는 하나의 시작점만 존재

검은색 원으로 표현

- 종료 노드

액티비티 안의 모든 흐름이 종료된을 의미

하나의 다이어그램 안에 여러개의 종료 노드 있을 수 있음

검은색 원을 포함한 이중원으로 표현.

- 조건(판단) 노드

조건에 따라 제어의 흐름이 분류됨을 표현

마름모로 표현, 들어오는 제어 흐름은 한개이고 나가는 제어 흐름은 여러개

예제) 회원정보 입력에서 정보가 맞으면 주문 상품 선택으로 이동, 틀리면 다시 입력으로 이동

- 병합 노드

여러 경로의 흐름이 하나로 합쳐짐을 표현

마름모로 표현하며, 들어오는 제어 흐름은 여러개이며 나가는 제어 흐름은 하나.

예제) 결제 인증 성공/ 결제 인증 재시도 성공 흐름이 주문완료로 합쳐짐.

- 포크 노드

액티비티의 흐름이 분리되어 수행됨을 표현.

굵은 가로 선으로 표현하며, 들어오는 액티비티 흐름은 한개이고 나가는 액티비티 흐름은 여러개

예제) 주문 상품 선택되면 흐름이 결제 인증과 상품 재고 확인으로 분할 됨.

- 조인 노드

분리되어 수행되는 액티비티 흐름이 다시 합쳐짐.

굵은 가로선으로 표현하며, 들어오는 액티비티 흐룸은 여러개이며 나가는 흐름은 한개.

예제) 결제 인증이 성공하고 재고시스템에서 재고 확인되어 주문 완료로 가는 흐름이 합쳐짐.

- 스윔레인

액티비티 수행을 담당하는 주체를 구분

가로 또는 실선을 그어 구분

예제) 결제, 회원, 재고 시스템을 서로 구분하기 위한 선이 스윔레인.

​

기능 모델링 검증

- 기능 모델링이 끝나고 구조 모델링이나 동적 모델링으로 넘어가기 전에 확인할 필요가 있음.

- 유스케이스 다이어그램, 유스케이스 명세서, 활동 다이어그램이 모두 같은 기능 요구를 하고 있는지 확인해야 함.

​

​

2.9 클래스(Class) 다이어그램

​

정적 모델링의 개념

- 사용자가 요구한 기능을 구현하는 데 필요한 자료들의 논리적인 구조를 표현한 것.

- 기능 모델링은 사용자가 요구한 기능들이 어떻게 작동하는지 사용자 관점에서 설명한 것이라면, 정적 모델링은 기능을 구현하는데 필요한 자료들의 논리적인 구조를 개발자 관점에서 그림으로 표현한 것.

- 시스템에 의해 처리되거나 생성될 객체들 사이에 어떤 관련이 있는지를 구조적인 관점에서 표현.

- 객체들을 클래스로 추상화 하여 표현. 객체가 가질 수 있는 속성과 동작을 추상적으로 표현한 것이 클래스. 예를 들어 고양이는 이름, 성별, 나이 속성을 가질 수 있고 밥을 먹고 잠을 잔다는 동작을 수행할 수 있음. 이처럼 정적 모델링은 하나의 객체가 가질 수 있는 속성과 동작을 컴퓨터 내부의 클래스라는 단위로 추상화하여 표현하는 것.

- UML을 이용한 정적 모델링의 대표적인 것이 클래스 다이어그램.

​

클래스 다이어그램의 개념

- 시스템을 구성하는 클래스, 클래스의 특성인 속성과 오퍼레이션, 속성과 오퍼레이션에 대한 제약조건, 클래스 사이의 관계를 표현한 것.

- 시스템을 구성하는 요소에 대해 이해할 수 있는 구조적 다이어그램.

- 시스템 구성 요소를 문서화하는 데 사용됨.

- 코딩에 필요한 객체의 속성, 함수 등의 정보를 잘 표현하고 있어 시스템을 모델링 하는데 자주 사용됨.

- 클래스 다이어그램의 구성: 클래스, 제약조건, 관계 등

(예제) 프로야구리그에 필요한 정보를 표현한 클래스 다이어그램

​

클래스

- 각각의 객체들이 갖는 속성과 오퍼래이션(동작)을 표현

- 일반적으로 3개의 구획으로 나눠 클래스의 이름, 속성, 오퍼레이션을 표기.

- 속성이나 오퍼레이션은 생략할 수 있지만 이름은 반드시 병시해여 함.

- 속성이나 오퍼레이션이 생략되면 구획선을 그리지 않아도 됨.

- 속성(Attribute)

클래스의 상태나 정보 표현

[접근제어자] 속성명: 자료형[다중성][=초기값]

접근 제어자: 속성과 오퍼레이션의 노출 정도 제어

자료형: UML에서 기본적으로 제공하는 자료형이나 사용자가 새롭게 정의한 자료형

다중성: 배열과 같은 의미

초기값: 데이터를 입력하지 않았을 때 기본적으로 입력되는 값.

- 오퍼레이션(Operation, 연산)

클래스가 수행할 수 있는 동작. 함수, 메소드라고도 함.

[접근제어자] 오퍼레이션명(매개변수:자료형) : 반환 자료형

​

제약조건

- 속성에 입력될 값에 대한 제약 조건이나, 오퍼레이션 수행 전후에 지정해야 할 조건이 있다면 적는다.

- 주석 도형안에 제약조건을 적은 후 제약 조건이 적용될 속성이나 오퍼레이션을 점선으로 연결한다.

- 클래스 안에 적을 때는 중괄호를 이용한다 {}

​

관계

- 클래스와 클래스 사이의 연관성을 표현.

- 클래스 다이어그램은 클래스가 서로 연결되어 있음을 의미하는 연관관계를 기본으로 함.

- 관계에 참여하는 객체의 수(다중도)를 연관관계 선 위에 표기

- 클래스 다이어그램의 관계 종류: 연관 관계, 집합 관계, 포함 관계, 일반화 관계, 의존 관계

- 연관 관계

• 두 클래스 간의 관계를 명확하게 표현하기 위해 관계 표현 실선의 중간 지점에 관계의 이름을 표기할 수 있음.
• 해당 클래스 관계 실선 바로 옆에 클래스의 역할 표기할 수 있음 (예제) 야구선수 - 출전선수
• 추가적으로 표현해야 할 속성이나 오퍼레이션이 있는 경우 연관 클래스 사용.
• 두 클래스가 서로 연관 관계에 있을 때는 클래스 안에 연관된 클래스를 이용하여 객체 변수를 생성할 수 있음.
• 예제1) 야구선수는 자기가 소유하고 있는 유니폼에 대해 알고 있지만 유니폼은 누구에 의해 자신이 소유되고 있는지 모름.

예제2) 야구 선수는 경기에 출전하고 경기는 야구선수에게 경기 결과를 제공하므로 서로 연관이 있음.

- 집합 관계

두 클래스가 서로 집합 관계에 있을 때는 집합 관계에 있는 클래스의 객체 변수를 매개 변수로 사용할 수 있음

예제) 야구선수에게는 팬이 있으며 팬은 다른 야구 선수의 팬이 될 수 있음.

- 포함 관계

두 클래스가 서로 포함 관계에 있을 때는 포함 관계에 있는 클래스를 이용하여 생성된 객체 변수를 이용하여 새로운 객체 변수를 생성할 수 있음.

예제) 야구선수는 하나의 팀에 소속되며, 팀이 해체되면 야구선수도 더이상 필요하지 않다.

- 일반화 관계

일반적인 개념을 상위(부모)클래스, 구체적인 개념을 하위(자식)클래스라고 부름

두 클래스가 서로 일반화 관계에 있을 때는 하위 클래스가 상위 클래스의 속성이나 메소드를 사용할 수 있음

예제) 주전 선수와 후보선수는 야구 선수이다.

- 의존 관계

두 클래스가 의존 관계에 있을 때는 영향을 주는 클래스(사용자)의 특정 메소드가 수행될 때만 영향 받는 클래스(제공자)가 사용된다.

예제) 야구선수의 승점이 높으면 연봉을 조정함. 낮으면 조정하지 않음.

​

연관 클래스

- 두 클래스가 연관 관계에 있을 때 추가적으로 표현해야 할 속성이나 오퍼레이션이 있는 경우에 사용.

- 두 클래스의 연관 관계를 나타내는 선의 가운데로부터 점선을 연관 클래스로 이어 표시함.

- 예제) 팀이 경기에 참여하는 상황에서 참여 횟수와 참여 결과를 팀과 경기 사이의 연관 클래스의 속성으로 다룸.

​

2.10 시퀀스(Sequence) 다이어그램

동적 모델링의 개념

- 시스템 내부의 구성 요소들의 상태가 시간의 흐름에 따라 변화하는 과정과 변화하는 과정에서 발생하는 상호작용을 표현한 것.

- 기능 모델링: 사용자 관점에서 제공할 기능 표현 / 정적 모델링: 개발자 관점에서 시스템 내부 구성 요소 표현 / 동적 모델링: 시간의 흐름에 따른 시스템 내부 구성요소의 상태 변화 표현.

- 시스템 내부 구성 요소들 간의 이루어지는 동작이라는 관점에서 표현.

- 시스템이 실행될 때 구성요소들 간의 메시지 호출, 오퍼레이션을 통한 상호작용에 초점을 둠.

- UML의 동적 모델링: 시퀀스 다이어그램, 커뮤니케이션 다이어그램, 상태 다이어그램

- 시스템 내부 구성 요소들의 동작을 표현하는 방법에 따라

메시지에 따른 상호작용을 표현: 시퀀스 다이어그램, 커뮤니케이션 다이어그램

동기에 의한 상태 변화를 표현: 상태 다이어그램

​

​

시퀀스 다이어그램의 개념

- 시스템이나 객체들이 메시지를 주고 받으며 시간의 흐름에 따라 상호 작용하는 과정을 액터, 객체, 메시지 등의 요소를 사용하여 그림으로 표현한 것.

- 시스템이나 객체들의 상호작용 과정에서 주고받는 메시지를 표현함. 시퀀스 다이어그램에서는 클래스의 오퍼레이션을 메세지로 표현.

- 각 동작에 참여하는 시스템이나 객체들의 수행 시간을 확인할 수 있음.

- 클래스 내부에 있는 객체들을 기본 단위로 하여 그들의 상호 작용을 표현.

- 시퀀스 다이어그램은 주로 기능 모델링에서 작성한 유스케이스 명세서를 하나의 표현 범위로 하지만, 하나의 클래스에 포함된 오퍼레이션을 하나의 범위로 표현하기도 함.

​

시퀀스 다이어그램의 구성요소

- 구성 요소: 액터, 객체, 라이프라인, 활성 상자, 메시지 등

(예제) 회원의 상품 주문 과정에서 재고 시스템과 결제 시스템에 관계되어 상호작용하는 과정을 표현한 시퀀스 다이어그램.

- 액터

시스템으로부터 서비스를 요청하는 외부 요소로 사람이나 외부 시스템을 의미

예제) 회원, <<Actor>> 재고 시스템, 결제 시스템

- 객체

메시지를 주고받는 주체

콜론(:)을 기준으로 앞쪽에는 객체명, 뒤쪽에는 클래스 명을 기술

예제) : 로그인화면, :회원정보, 카드: 결제화면 등

- 라이프라인

객체가 메모리에 존재하는 기간

객체 아래쪽에 점선을 그어 표현

객체 소멸이 표시된 기간까지 존재

- 활성상자

객체가 메시지를 주고받으며 구동되고 있음을 표현

라이프라인 상에 겹쳐 직사각형 형태로 표현

- 메시지

객체가 상호작용을 위해 주고 받는 메시지

메시지의 전달 순서는 메시지의 위치에 따라 묵시적으로 (위에서 아래 순) 결정되지만 메시지에 번호를 표기하여 전달 순서를 표현할 수 있음.

화살표의 방향은 메시지를 받는 쪽으로 향하게 표현함.

메시지의 종류: 동기, 비동기, 생성, 응답

동기	메시지를 보낸 후 결과가 반환될 때까지 기다림
비동기	메시지를 보낸 후 결과가 반환될때까지 기다리지 않고 다른 작업을 수행.
생성	메시지를 받는 새로운 객체를 생성.
응답	동기 메시지에 대한 수행 결과

​

- 객체 소멸

라이프라인 상에서 객체 소멸 표시를 만나면 해당 객체는 더이상 메모리에 존재하지 않음.

마지막에 X 표로 표현.

- 프레임

다이어그램 전체 또는 일부를 묶어 표현.

전체, 복합적인 부분, 반복구조, 선택 구조 등이 프레임 안에 표현.

프레임 왼쪽 위에 다이어그램의 종류와 제목 표기.

예제) 직사각형, 왼쪽 상단에 SD 상품 주문

​

2.11 커뮤니케이션(Communication) 다이어그램

​

커뮤니케이션 다이어그램의 개념

- 커뮤니케이션 다이어그램은 시스템이나 객체들이 메시지를 주고받으며 시간의 흐름에 따라 상호작용하는 과정을 액터, 객체, 링크, 메시지 등의 요소를 사용하여 그림으로 표현한 것.

- 커뮤니케이션 다이어그램도 시퀀스 다이어그램과 같이 동작에 참여하는 객체들이 주고받는 메시지를 표현하는데, 메시지 뿐만 아니라 객체들 간의 관계를 파악하는데 사용됨.

- 클래스 다이어그램에서 관계가 제대로 표현됐는지 점검하는 용도로 사용됨.

- 초기에는 협업 다이어그램이라고도 불림.

​

커뮤니케이션 다이어그램의 구성요소

- 액터

시스템으로부터 서비스를 요청하는 외부 요소로 사람이나 시스템을 의미

예제) 회원, <<Actor>> 재고 시스템

- 객체

메시지를 주고받는 주체

콜론(:) 앞에는 객체명, 뒤에는 클래스명 기술

- 링크

객체들간의 관계 표현..

실선을 그어 표현함.

링크에 메시지 표현

- 메시지

객체가 상호 작용을 주고 받는 메시지

화살표 방향은 메시지를 받는 쪽으로 향하게 되어있음.

순서를 숫자로 표현할 수 있음.

종류는 시퀀스 다이어그램과 동일

​

2.12 상태(State) 다이어그램

상태다이어그램의 개념

- 객체들 사이의 상호작용에 의한 객체들의 상태 변화를 그림으로 표현한 것.

- 어떤 이벤트에 의해 객체 자신이 속한 클래스의 상태 변화나 객체가 다른 객체와 상호작용하는 과정에서의 상태 변화를 표현함.

- 객체의 상태란 객체가 갖는 속성 값의 변화를 의미. (예) 결제 객체에서 결제 대기 > 결제 승인으로 상태 변경

- 상태 다이어그램은 특정 객체가 어떤 이벤트에 의해 상태 변환 과정이 진행되는지 확인하는데 사용됨.

- 상태 다이어그램은 시스템에서 상태 변환 이벤트를 확인할 필요가 있는 객체만을 대상으로 그림.

​

상태다이어그램의 구성 요소

- 상태

객체의 상태를 표현

객체의 상태를 둥근 사각형 안에 기술

- 시작 상태

상태의 시작을 표현

속이 채워진 원으로 표현

- 종료 상태

상태이 종료를 표현

속이 채워진 원을 둘러싼 이중원으로 표현

- 이벤트

상태에 변화를 주는 현상

이벤트에는 조건, 외부신호, 시간의 흐름이 있음.

조건 이벤트: 결제 정보가 입력되어 상태가 전환되면 조건 이벤트에 따라 상태가 전환된 것.

외부 신호 이벤트: 외부 결제 시스템에 의해 결제 정보 일치한다는 신호를 받아 상태 전환될때.

- 상태 전환

상태 사이의 흐름, 변화를 화살표로 표현.

화살표에 이벤트를 표현

- 프레임

상태 다이어그램의 범위