유스케이스

    *** 유스 케이스

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

   ** 유스케이스 이름

  * 명명 규칙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)로 구성

프로그래밍 언어의 역사

  ** OOP는 필연성을 가지고 등장

  * 객체지향 기술에 대한 일반적인 견해
 – 현실 세계의 사물을 보는 견해에 따라 소프트웨어를 만드는 전혀 새로운 사고 방식
 – 종래의 개발 기술을 바꾸어 놓을 것.

  * OOP(필자의 견해)
 – 그 이전의 프로그래밍 기술을 기초로 결점을 보완하기 위해서 고안된 것.

  * 객체지향 기술
 – OOP를 발전, 응용한 것으로 종래부터 있던 우수한 개발 기술의 연장 선상에 있던 것.
 – 품질 좋은 프로그램을 높은 생산성으로 만들기 위한 실천적인 기술.

   ** 초창기에는 기계언어로 프로그램을 작성

  * 컴퓨터?
 – 2진수로 스여진 기계 언어밖에 해설할 수 없음.
 – 1940년대 처음 등장

   ** 프로그램 언어의 첫걸음은 어셈블리 언어

   ** 고급 언어의 발명으로 보다 친숙해진 프로그램

  * 고급언어
 – 컴퓨터가 이해하는 명령어를 하나하나 기술하는 것이 아님
 – 보다 사람이 알기 쉬운 “고급스러운” 형식으로 표현
 – FORTRAN(1957년), COBOL(1960년)

  * 1960년대 말 북대서양조약기구(NATO)
 – “소프트웨어 위기” 선언

   ** 알기 쉬움을 중시하는 구조적 프로그래밍

  * 구조적 프로그래밍
 – “소프트웨어 위기”에 대응하기 위해 제안된 아이디어
 – 기본적인 사상
+ 바르게 동작하는 프로그램을 작성하기 위해서는 알기 쉬운 고조로 하는 것이 중요하다.
 – 구체적인 방법
+ GOTO문 폐지
+ 프로그램 논리를 3가지 구조(순차 진행, 조건 분기, 반복)만으로 표현

   ** 서브루틴의 높은 독립성을 유지보수에 강점

  * 서브루틴?
 – 1940년대 발명
 – 여러 장소에 나타나는 같은 명령의 나열을 한곳에 모음
 – 효과
+ 프로그램 사이즈가 작아짐
+ 프로그램 작성 시간 절약

  * 서브루틴의 독립성을 높이는 방법
 – 메인루틴과 서브루틴에서 공유하는 정보를 적게 하는 것.

  * 전역변수(global variable)의 문제점
 – 프로그램 전체의 어디에서도 접근 가능
 – 어느 서브루틴이 언제 변경하거나 참조하고 있는지 알기 어려움
 – 전역변수의 변경 시 : 프로그램 전체 논리 확인 필요

  * 전역 변수 문제점의 해결 방안
 – 지역변수 사용
 – 값 복사에 의한 인수값 전달 방법(Call by value)

   ** “GOTO 없는 프로그램” 구조적 언어

  * 구조적 언어 등장
 – 구조적 프로그램 이론을 기초로 함
 – ALGOL, Pascal, C언어 등
 – 명확한 제어 기술 가능
+ if문, case문, while문, for문 등의 명령을 사용
+ 당시 COBOL과 FORTRAN등에서는 기본 3구조를 기술할 수 없음
 – 별칭 “GOTO없는 프로그래밍”
 – 대표적인 언어 : C

   ** 진화 방향은 유지보수성과 재사용성

 – 기계언어 : 컴퓨터가 직접 해석하는 기계 언어를 2진수/16진수로 기술
 – 어셈블리 언어 : 기계 언어를 기호로 기술
 – 고급 언어 : 복수의 기계 언어를 중요한 고급 문법으로 기술
 – 구조적 언어 : 기본 3구조(GOTO 없는)의 제공으로 서브루틴의 독립성 강화

   ** 남겨진 문제는 전역변수와 빈약한 재사용

  * 구조적 프로그래밍
 – 수년 전까지 대학과 기업의 신입사원 연수에서 거론되는 주제
 – 아직 해결되지 않은 2가지 주제가 남아 있음
 – 2가지 문제
+ 전역변수
+ 빈약한 재사용

  * 전역변수 문제
 – 해결안 : 지역변수 사용, Call by value
 – 미해결 부분 : 전역변수로 보전
 – 대규모 프로그램에서 전역변수 문제는 심각

  * 빈약한 재사용의 문제
 – 구조적 언어에서 재사용 가능한 것은 “서브루틴”

SW 프로젝트 작업

    1.6 소프트웨어 프로젝트 작업

  * 소프트웨어 프로젝트 작업
 – 요구분석, 설계, 프로그래밍, 품질보증, 프로젝트 관리
 – 작업의 종류와 순서는 개발 프로세스 모형에 따라 다름

   1.6.1 요구분석과 명세화

  * 고객 문제 해결 방법
 – 고객의 비지니스 환경, 문제점, 기술 이해
 – 작업과 순서 결정
 – SW가 제공해야 할 기능 결정

  * 도메인 분석
 – 관련 배경 지식 이해
 – ex) 기업회계 SW : 장부기장 방법, 회계 시스템
 – ex) 운영체제 SW : 프로세스 관리, 메모리 관리, 파일관리 기법

  * 문제 정의
 – 시스템의 범위를 더 좁혀 나가는 작업

  * 요구 추출
 – SW가 해야 하는 일에 대한 사람들의 아이디어 취합

  * 요구 분석
 – 정보 정리, SW기능 결정

  * 요구 명세화
 – 기능 정의를 위해 명령어 형태로 작성

   1.6.2 설계

  * 요구 사항들을 어떻게 구현할 것인가를 결정하는 과정

  * 시스템 엔지니어링
 – HW구현 부분, SW구현 부분 결정
 – 임베디드 시스템, 리얼타임 시스템에서만 필요

  * SW 아키텍처
 – 서브시스템으로 분할 방법, 서브시스템간의 상호 작용 결정

  * 상세 설계
 – 각 서브시스템의 상세한 사항데 대한 구성 방식 결정
 – 상세 사항 : 자료구조, 클래스, 알고리즘, 프로시져

  * 사용자 인터페이스
 – 사용자가 시스템과 어떻게 상호작용 하는지 결정

  * 자료저장 형태 결정
 – 자료를 어떻게 저장하는지 결정

   1.6.3 모델링

  * 모델링[정의]
 – 도메인이나 SW의 표현을 만들어 나가는 과정
 – 요구 분석, 설계에서 모델링 접근 방법 사용

  * 사용사계 모델링
 – SW 사용자에 의하여 수행 되는 작업을 순서대로 표현

  * 정적 모델링
 – 도메인이나 SW에 존재하는 클래스나 객체를 표현

  * 동적 모델링
 – 시스템의 상태 변동 또는 수행하는 작업과 같은 것을 나타냄

   1.6.4 프로그래밍

  * 프로그래밍
 – SW ENG.의 모든 작업을 통합
 – 높은 수준의 설계를 정해진 프로그래밍 언어로 옮김.
 – 디자인의 마지막 단계

  * SW Architect
 – 상위 수준의 설계를 담당하는 인력

  * SW ENG.연구의 목적
 – 프로그래밍의 자동화

  1.6.5 테스트

  * 단위(모듈) 테스트
 – 개별 코드 테스트

  *통합 테스트
 – 모듈을 연결하여 테스트
 – 전체 모듈이 모두 연결될 때 까지 하나식 점증적으로 추가

  * 시스템 테스트
 – 완성된 시스템이 원하는 대로 작동하는지
 – 성능은 어떤지 요구 분석 결과와 비교

   1.6.6 품질 보증

  * 품질 보증[정의]
 – 품질 목표를 달성하려고 작업하는 모든 프로세스

  * 리뷰와 인스펙션
 – 요구, 설계, 코드가 원하는 수준에 맞는지 토의

  * 테스트
 – SW가 예상대로 작동하는지 체계적으로 수행

  * 검증(Validation)
 – 요구가 교객이 요구하는 문제인지 아닌지를 결정

  * 검토(Verification)
 – 요구를 설계하고 구현하는 과정이 맞는 것인지 판단

   ** 프로세스 관리(관리자의 역할)

  * 시스템 비용 추정
 – 요구사항 연구, 디자인, 구현하는데 드는 노력 결정

  * 계획
 – 개발자들에게 일 할당
 – 완료 일정 결정

   ** SE 토픽 1.5 – ISO 12207 SW 프로세스 표준
 – SW 개발 관리를 위한 절차, 방법, 도구들을 자세히 정리하여 틀을 정해 줌.
 – SW 공급자나 발주자 사이에 정확한 의사 전달을 위하여 사용

 – 입찰 준비부터 공급하기까지 프로젝트의 계약에 관한 작업
 – 개발, 운영, 유지보수 하는 입장의 작업
 – 품질 관리 등 보조 작업
 – 프로세스 관리차원의 작업

   ** 초보 엔지니어링에게 가이드 역할
 – SW 개발 프로세스의 성숙도 평가에 관한 기준으로 사용