*** 유스 케이스

 – 시스템이 제공하는 각 기능

   ** 유스케이스 이름

  * 명명 규칙1 : 행위 또는 동작을 뜻하는 명사 사용
 – 시스템의 기능을 나타내어야 함
 – ex) 수강 -> 수강신청, 출석부 -> 출석부 조회

  * 명명 규칙2 : 사용자가 얻고자 하는 목적이 명확히 나타나야 함.
 – ex) 수강 과목 선택 -> 수강 신청

  * 명명 규칙3 : 사용자(액터)의 입장에서 명명되어야 함
 – ex) 성적 관리 -> 성적 등록
 – ex) 수강 신청 관리 -> 수강 신청

  * 요약 : 사용자의 관점에서 바라보고 시스템이 제공하는 기능을 이용하여 궁극적으로 하고자 하는 행위를 나타내는 명사를 사용한다.

   ** 유스케이스 설명

  * 유스케이스를 이용하는 사용자에게 이 유스케이스를 통해서 시스템이 어떤 기능을 제공하는 지를 한/두 문장으로 간단하고 명확하게 기술하는 것

   ** 유스케이스의 특성

  * 특성 1 : 하나의 유스케이스는 일련의 액션들로 표현

  * 특성 2 : 하나의 유스케이스는 여러 variants를 포함
 – 기본 흐름(basic flow) : 가장 전형적이고, 정상적인 경우
 – 대안 흐름(alternative) : 기본 흐름을 벗어나는 다른 상황을 나타냄
 – 각 대안 흐름 별로 별도의 유스케이스를 정의하지 않음
 – ex) 카드 판독 실패 이벤트 흐름
+ 카드 판독이 불가능함을 사용자에게 알리고 카드를 배출시킨다.
+ 사용자는 카드를 회수한다.
 – ex) 잔액 부족 이벤트 흐름
+ 잔액 부족을 사용자에게 알리고, 카드를 배출하고, 영수증을 인자한다.
+ 사용자는 카드와 영수증을 회수한다.

  * 특성 3 : 유스케이스는 시스템이 제공하는 기능
 – 시스템에서 제공하지 않을 기능이 유스케이스에 포함되어서는 안됨
 – 수작업을 통해서하는 작업을 유스케이스에 포함시켜서는 안됨
 – ex) 학교에서 배포된 성적표로 성적 확인은 유스케이스에 포함시켜서는 안됨

  * 특성 4 : 유스케이스는 액터가 관찰할 수 있는 결과를 산출
 – ex) 현금 자동 인출기 시스템의 출금 유스케이스
+ 카드 판독의 성공 표시 및 거래 종류의 일력을 요청하는 화면
+ 암호의 입력을 요청하는 화면
+ 암호의 확인 성공 표시 및 인출할 금액의 입력을 요청하는 화면
+ 출금이 진행 중임을 표시하는 화면
+ 출금 시 배출된 현금과 영수증
 – 유스케이스는 액터가 궁극적으로 원하는 결과를 내야 한다.

  * 특성 5 : 유스케이스는 액터에 의해서 수행이 시작
 – ex) 출금 유스케이스 : 사용자 액터가 카드를 삽입함으로써 수행
 – 유스케이스의 이벤트 흐름은 반드시 액터에 의해서 시작된다.

  * 특성 6 : 한 유스케이스 내의 액션들을 트랜젝션처럼 수행
 – 한 유스케이스의 이벤트 흐름을 구성하는 각 이벤트들은 유스케이스가 수행될 때 모두 발생하는 것이며 부분적인 발생은 허용되지 않음.
 – 이벤트 흐름의 부분만을 수행하는 것이 가능하면 그것을 하나의 유스케이스라고 볼 수 없음.
 – ex) 성적 등록
 – ex) 출석부 조회

   ** 유스케이스 찾기

 – 질문1 : 사용자 액터가 시스템이 제공하기를 원하는 기능은 무엇인가?
+ ex) ATM : 입금, 출금, 조회, 이체, 통장 정리
+ ex) 대학 정보 시스템 : 학생(수강신청, 성적조회), 교수(출석부 조회, 성적 등록)
 – 질문2 : 시스템이 어떤 기능을 제공하면 사용자 액터의 일상 작업이 효율적이고 편해지는가?
+ 수업 담당자 : 수강료 청구서 발급
 – 질문3 : 사용자 액터가 시스템에 어떤 정보를 생성/조회/수정/삭제하고 싶어 하는가?
 – 질문4 : 시스템의 입력과 출력은 무엇인가?

    *** 요구사항 정리

 – 기초공사
 – 사용자로부터 필요
 – 시스템 구축의 첫 과정
 – 요구사항 도출, 기술, 확인하는 활동
+ 유스케이스 모델링 기법 이용
+ 체계적인 요구사항 도출
+ 명확한 기술 방법 설명

   ** 요구사항의 유형

  * 기능적 요구사항 : 시스템이 제공해야 하는 동작/행위에 대한 요구사항
 – 교수/학생 정보를 등록, 검색, 수정, 삭제, 조회할 수 있는 기능
 – 강좌/강의를 등록, 검색, 수정, 삭제, 조회할 수 있는 기능
 – 수강 신청, 성적 등록, 성적 조회, 출석부 조회 기능
 – 로그인, 로그아웃, 암호 변경 기능

  * 비기능적 요구사항 : 동작/행위와 관련된 제약사항
 – 성능
 – 신뢰도
 – 사용 편의성
 – 유지 보수성

   ** 비기능적 요구사항

  * 성능
 – 정해진 특정 시간 내에 결과가 나와야 한다는 조건
 – ex) “학번, 이름을 입력한 후에 검색 명령을 내리고 검색 결과를 2초 이내에 화면에 보여 주어야 한다.”
 – 설계 활동의 중요한 요소로 작용
 – ex) JDBC로 직접 데이터베이스 조작, 무상태 세션 빈 사용, 성능 향상을 위한 프로그래밍 기술 사용

  * 신뢰도
 – 오류가 발생하지 않으면서 시스템이 동작할 확률
 – ex) 항공기 제어 시스템, 미사일 추적 시스템 등의 실시간 시스템
 – 특별한 기술 사용

  * 사용 편의성
 – 사용자들이 얼마나 편리하고 쉽게 시스템을 사용할 수 있는가
 – ex) 효과적인 메뉴 체계 정의
 – ex) UI화면의 일관되고 효과적인 정의
 – ex) 도움말 온라인 제공

  * 유지 보수성
 – 얼마나 유지 보수를 쉬우면서 효율적으로 할 수 있는가의 정도
 – 설계 시 약속된 기능을 정확히 제공
 – 설계 시 유지 보수 측면 고려

   ** 요구사항 정의의 중요성

  * 요구사항 정의 활동의 산출물
 – 개발자들에게 구축할 시스템의 정보 제공
 – 개발할 시스템 파악(개발자)

  * 요구사항 정의 활동 개발자와 분석/설계 개발자가 다른경우
 – 산출물을 바탕으로 한 작업 진행
 – 정확성과 완전성이 중요함

  * 요구사항의 명확한 정의 이후 개발 진행

  * 결정된 요구사항에 대한 사용자와 개발자 간의 합의 필요

   ** 요구사항 정의 활동

 – 시스템이 제공할 기능과 범위 밖을 명확하게 구분
 – 시스템의 결계 결정

  ** 유스케이스 모델링

 – Ivar Jacobson에 의해서 제안
 – 요구사항 도출 및 기술에 사용
 – 액터 : 개발할 시스템 외부의 존재
 – 유스케이스 : 시스템 범위 안에서 개발될 시스템의 단위 기능

    *** 액터

  * 개발될 시스템과 상호 작용을 하는 모든 대상
 – 사용자 액터
 – 시스템 액터

  * 사용자 액터
 – 개발될 시스템의 기능을 이용하는 사용자

  * 시스템 액터
 – 개발될 시스템과 연동 되는 또 다른 시스템
 – ex) 신용 대출 시스템 : 신용 정보 제공 시스템
 – ex) 대학 정보 시스템 : 수강료 청구서 발급 시스템

   ** 액터 이름

  * 액터의 이름
 – 액터의 의미를 명확히 애해할 수 있는 단어 사용

  * 사용자 액터
 – 시스템 관점의 사용자 역할
 – ex) 교수, 학생, 학사 담당자, 수업 담당자
 – 역할 추측 가능한 구체적인 단어 사용

  * 시스템 액터
 – 해당 시스템의 이름 사용
 – 문제 기술서에 시스템의 이름이 명시되어 있음
 – ex) 수강료 청구서 발급 시스템, 신용 평가 시스템

   ** 액터 설명

  * 액터가 할 수 있는 일 기록
 – ex) 학사 담당자 : 교수 및 학생 정보를 관리한다.

   ** 액터의 특성

  * 개발될 시스템 범위 밖에 존재
 – 개발자가 개발할 범위가 아니라는 것.
 – ex) 대학 정보 시스템 : 수강료 청구서 발급 시스템

  * 역할을 나타내야 함
 – 구체적인 실제 사용자가 아님
 – 시스템의 관점에서 바라본 그 사용자의 역할
 – 한 명이 두 개 이상의 역할을 하는 경우 : 대응되는 각각 사용자 액터를 정의
 – ex) 1명(도서 관리, 학생/교수 관리) : 사서, 학사 담당자 액터

   ** 액터 찾기

  * 질문 :  누가 개발될 시스템의 주요 기능을 이용하는가?
 – 문제 기술서 활용
 – 학적과의 학사 담당자는 학생 및 교수 정보를 관리해야 한다.
 – 수업 담당자는 새로운 강좌를 등록할 수 있다.
 – 학생을 수강 신청을 온라인 상으로 직접 할 수 있다.
 – 교수는 매 학기마다 자신이 강의하는 강좌를 신청한 학생 명단을 확인할 수 있다.

  * 질문 : 누가 이 시스템을 통해서 자신의 업무를 지원 받을 수 있는가
 – ex) 대학 정보 시스템 : 학사 담당자

  * 질문 : 누가 시스템이 만들어 낸 결과에 관심을 가지는가?

  * 질문 : 누가 시스템이 잘 운영될 수 있도록 유지 보수 및 관리를 하는가?
 – Primary actor : 시스템 본연의 기능을 이용하는 사용자
 – Secondary : 시스템의 유지 보수 기능을 이용하는 사용자
 – 음료수 자동 판매기 : 청소 및 관리자
 – 현금 자동 인출기 : 유지 보수 담당자
 – 시스템이 유지 보수 기능을 제공하지 않으면 유지 보수 담당자는 액터로 표기될 수 없음

  * 질문 : 개발할 시스템과 연동되는 다른 시스템에는 어떤 것이 잇는가?
 – 시스템 액터를 찾을 때 유용
 – ex) 대학 정보 시스템 : 기존에 존재하는 수강료 청구서 발급 시스템

   ** 구조체와 클래스

  * 프로그램 작성 방식
 – 구조화되지 않은 프로그래밍
 – 절차식 프로그래밍
 – 모듈식 프로그래밍
 – 객체지향 프로그래밍

  * 구조체 VS 클래스

   ** 구조화되지 않은 프로그래밍

 – 메인 프로그램 속에 모든 것이 포함된 프로그램
 – C나 C++의 경우 프로그램 전체가 main 함수 하나로 작성된 경우

   ** 절차식 프로그래밍

 – 메인 함수 외에 여러 개의 함수로 구성
 – 프로그래밍 초기에 C만으로 코드를 작성할 때 효율적

   ** 모듈식 프로그래밍

 – 메인 함수 외에 여러 개의 함수로 구성
 – 각각의 모귤은 메인 함수와 관계를 가지며, 각각 별개의 객체로 존재

   ** 객체지향 프로그래밍

 – 메인 함수 없이 여러 개의 객체로 구성
 – 각각의 객체는 생성하고 소멸하는 일을 자체적으로 담당
 – 같은 종류의 객체가 여러 개 존재 가능
 – 메인 함수의 관리하에 데이터를 관리하고 처리하는 것이 아니라 객체들 간에 메시지가 교환

   ** 비 구조체

 – ex) 이름, 나이, 주민등록번호 등을 기록하는 신상카드의 코드화
 – 각가의 배열을 만들어 저장
+ 복잡하다.
+ 배열간에 서로 연결된 정보라는 어던 신호도 존재하지 않음.

   ** 구조체

 – 관리를 쉽게 하기 위해 구조체 도입
 – 구조체 : 다루고 싶은 데이터를 하나의 덩어리로 묶어주는 것.

   ** 클래스

 – 클래스 : 구조체와 같이 단순히 데이터를 묶어주는 것에 만족하지 않고 객체지향 프로그래밍의 특성을 살린 개념
 – Abstraction : 실제 상황으로부터 프로그램내에서 이용하는 모델을 얻어내는 것.
 – ADT(Abstract Data Type) : 사람자체가 아닌 사람의 몇가지 특징만을 뽑아 낸 모델
 – C++에서 사용하는 클래스라는 개념이 ADT의 개념
 – 클래스 : 여러 개의 데이터(abstract data structure)와 그 데이터를 사용하는 함수들(Operation)로 구성