|
process-1 |
process-2 |
process-3 |
조 true |
건 false |
true part |
else part |
③ repetition (반복 구조)
loop 구조 |
|
do-while part |
repeat-until part |
|
loop 조건 |
④ selection
case 조건 value value value |
|||||
case part |
case part |
case part |
...... |
case part |
3) 의사코드(Pseudo code)
- 문제처리를 위해 규칙에 맞게 도표가 아닌 자유로운 문장 형태로 논리체계를
작성한 것
- 프로그램의 이해와 내용 전달의 용이성을 위해 문법을 갖추지 않고 자연어를
기술한 언어로 PDL(Program Description Language)이라고 함
4) 모듈설계(Module Design = structured Design)
- 같은 조건하에 처리해야할 내용들을 블록으로 묶어서 처리하도록 하는 단위적
설계 기법
- 모듈설계는 구조적 프로그램 방식으로 구현
5) 판단도표
- 도표를 이용하여 수행문과 조건문을 수행하기위한 방법
6) IPO 도표(Input Processing Output)
- s/w 설계와 문서화 기법의 효율적인 처리를 위한 방법
6.3 HIPO(Hierarchy plus Input Processing Output)
(1) 의미
- 프로그램 논리의 문서화와 설계를 위해 도식적인 방법을 제공하는 기법
- 입력, 처리, 출력으로 구성되며 시각적으로 알아보기 쉽게 표현한 것
(2) 구성요소
- 도식목차 : HIPO의 전체적인 흐름과 구조를 나타내는 도표
- 총괄 다이어그램 : 입력, 처리, 출력등의 전반적인 기능을 명확히 표현한 도표
- 상세 다이어그램 : 총괄 다이어그램을 세부적, 구체적으로 설명한 도표
제 7 장. Object-Oriented Paradigm
7.1 개요
- oop는 s/w의 재사용, 확장성, 적용성을 중시한 프로그래밍 기법
(1) Object
- 현실 세계에서 행동의 주체인 대상
- 전용 자료와 method로 구성
: 전용자료는 개체의 물리적 구성요소
: method는 객체의 행위
: 절차지향 언어에서의 data와 알고리즘에 대응
- oop에서의 객체는 자기의 행위를 인식하는 실체
(2) Class
- 유사한 객체를 묶어서 공통된 특성을 표현
: 자료 추상화의 개념과 동일
- class는 oop에서 data type
- class는 계층구조를 가질 수 있다
: superclass - 기준 class 보다 상위의 class
: subclass - 기준 class 보다 하위의 class
(3) Instance
- class에 속하는 구체적인 객체
- class에 해당하는 실제 data
(4) Message
- object가 어떤 행위를 하도록 하는 명령
- 각 object들 사에에 주고 받음으로 program이 실행
- message를 받는 객체를 수신자, 보내는 객체를 송신자라 함
- 수신자는 자신이 모르는 message를 받으면 error를 유발
(5) Method
- object가 실행 해야할 구체적인 연산을 정의한 것
- 하나의 object는 하나 이상의 method 정의 가능
- 어떤 class의 method들의 집합을 class protocol 이라함
7.2 Object-Oriented 도식 표현 방법
7.2.1 object와 class의 도식
- object와 class 사이의 관계를 도식화
- object와 class의 관계를 모델링
- class 도식은 system modeling을 위해서 사용
- instance(object) modeling은 복잡한 class 도식을 명확화
7.2.2 Attribute
- object에 의해 소유되는 data value
- 하나의 class 내에서 unique
- 식별자가 없음
7.2.3 Operation and Method
- operation은 class 내의 객체에 의한 함수나 변형
- 하나의 class내의 모든 객체는 동일한 operation 공유
- object의 외부적 활동을 operation 이라함
- user는 object의 연산방법의 구현에 관계없이 object 사용
- method는 수행절차를 기술한 것
- method는 object의 data 구조와 결합되어 존재
- method는 smalltalk에서는 behavior, c++에서는 member function이라함
7.2.4 Link and Association
- link는 object instance 간의 연결
- association은 semantic과의 공통된 구조를 가짐
- association은 link의 구조
- 모든 link는 동일 class에서 객체를 연결
7.3 Object-Oriented Method & Structured Method의 비교
7.3.1 Structured Method
(1) 기능적 분할 방법
- system의 기능에 의해서 서브프로그램으로 나누는 방법
- 함수를 중심으로 설계 코드를 만든다
- 데이터 부분은 함수의 필요에 따라 중복 정의됨
- 대규모 프로그램에서는 코드의 크기가 늘어나는 원인
(2) 이벤트-반응 모델링 방법
- 사건과 반응을 관찰하여 서브프로그램으로 분할하는 방법
- 시스템을 하나의 블랙박스로 보고 사건과 반응을 프로세스로 정의
7.3.2 Object-Oriented Method
- object와 entity-relationship diagram을 사용하여 데이터 중심 modelin method
- object와 entity-relationship model을 object-oriented식으로 확장한 object model이
개발됨
- software system에서 강조되는 측면
1) process : 무엇이 수행되는가에 관한 것
2) data : process에서 동작되는 것
3) control : process의 수행순서와 시점을 지정
- data를 강조하는 이유는 data가 안정적이기 때문
- 세가지 방법에서 강조되는 system 측면
기능적 분할방법 이벤트-반응 모델링 객체지향 방법
프로세스 컨 트 롤 데 이 터
컨 트 롤 프로세스 컨 트 롤
데 이 터 데 이 터 프로세스
7.4 Object-Oriented Analysis(OOA) & Design(OOD)
- object-oriented system이 수행할 기능 파악이 중요함
: 기능 수행의 주체로 object를 파악
: 기능과 객체를 연결해서 파악
: object들 간의 다양한 관련성을 파악
- OOA의 6가지 단계
1) 문제분석의 단계
- 시스템에 대한 요구를 시스템이 수해해야하는 행위를 중심으로 파악
- 사용자와의 인터뷰, 실제상황에 대한 경험, 참고서적을 통해 시스템이 갖추어야
하는 기능의 흐름을 행위 기술서로 작성한다
2) 객체의 선정단계
- 시스템의 기능을 수행하는 주체로서의 객체를 파악
- 객체의 추출과 해당 객체에 대한 역할을 기술
3) 객체의 속성정의 단계
- 객체가 지닌 속성을 정의
- 각각의 객체에 대한 속성 파악과 속성에 대한 설명을 기술
4) 객체의 행위추출 단계
- 객체가 지닌 주체자로서의 행위와 피주체자로서의 행위를 기술
- 객체가 수행하는 행위에 대한 이름의 선정과 설명을 기술
5) 객체들 간의 관련성 정의 단계
- 객체의 행위와 속성을 기반으로 객체들간의 상속, 집합, link/association 관계
결정
- 추상화와 그룹화등의 기법의 적용으로 관련성을 추출하고 이를 모델링 카드에
반영
6) 각 객체별 카드 작성 단계
- 객체, 속성, 행위를 각 객체별로 정리하여 system을 구성할 객체 파악
- 하나의 객체가 system 기능중 담당할 기능을 기술
- 객체가 제공하는 service와 각 객체들의 책임한계를 정의
7.5 Object-Oriented Design
- 객체 지향 설계는 시스템 설계와 객체 설계로 나눈다
7.5.1 시스템 설계
- 시스템의 상위구조를 선택하는 작업
- 상세 설계를 위한 중요한 개념과 전략을 결정
- 서브시스템과 이들이 할당될 하드웨어를 결정
(1) 시스템을 서브시스템으로 분할
- 서브시스템이란 같은 특성을 가진 요소들의 모임
- 단순한 객체나 함수가 아니라 class, 관계, operation, 사건, interface로된 패키지
- 서브시스템을 전체 시스템의 부품으로 생각
- 운영체제에서의 파일 시스템을 서브시스템
(2) 문제안에 포함된 병행수행 가능성을 파악
- 실세계에서의 모든 객체는 가능성을 파악
- 동적 모형을 분석하여 병행수행성을 파악 가능
- 두 객체가 동일 시간에 상호작용이 없으면 병행 가능
- 항공기의 엔진제어와 날개제어 서브시스템은 동시수행 가능
(3) 서브시스템을 프로세서와 태스크에 할당
- 각 서브시스템에 필요한 자원 성능 조건 추정
- 하드웨어 및 소프트웨어 구현 방법 결정
(4) 자료보관 방법을 결정
- 시스템의 내부 및 외부 자료 저장소 형태 결정
- 메모리 및 디스크, 자료구조, 파일, 데이터베이스 자료저장소와 관련된 미디어와
보관방법 결정
- 각종 응용프로그램이 이용하는 자료나 다양한 하드웨어와 운영체제에서 사용하는
자료는 데이터베이스에 저장
- 대규모로 단기적으로 사용되거나 가공되지 않은 원시자료는 파일 시스템에 저장
(5) 공동자원의 접근 방법 결정
- 객체번호, 파일이름, 클래스이름 등의 논리적 식별자 등을 포함
- 프로세서, 테이프 장치, 통신선, 디스크 공간, 화면등도 포함
(6) 제어에 대한 구현 방법 결정
- 외부제어와 내부제어로 구분
- 외부제어는 외부에서 볼 수 있는 시스템내의 객체사이의 사건 흐름
- 외부사건은 절차 중심의 순서, 사건중심의 순서, 병렬로 구분
- 내부제어는 오퍼레이션 안에서의 제어 흐름
- 내부제어는 프로시쥬어 호출이나 테스크 사이의 호출로 구현
(7) 경계조건 처리방법을 결정
- 초기화상태, 종료상태, 비정상적 종료등 경계조건에서의 시스템 반응을 고려
(8) 우선 순위를 결정
- 설계목표와 상충되는 경우 하나의 목표를 희생하기 위하여 우선순위를 결정
7.5.2 객체설계
- 사용될 클래스와 클래스 사이의 관계를 정의
- 클래스안의 오퍼레이션을 구현하기위한 알고리즘을 정의
- 분석단계에서 만들어진 클래스, 속성, 관계들을 특정 자료구조를 이용하여 구현
- 다음의 순서로 설계
1) 세가지 모형을 이용하여 객체들에 대한 오퍼레이션을 파악
- 오퍼레이션들을 해당하는 객체와 묶어 표현
2) 오퍼레이션을 구현하기 위한 알고리즘을 정함
- 최적의 알고리즘을 선택하고 적합한 자료구조를 정한다
- 필요하다면 새로운 내부 클래스와 오퍼레이션을 정의 가능
3) 자료에 대한 접근 경로를 최적화 한다
- 자료의 접근 속도를 줄여야 한다
- 필요하다면 수행 순서를 조정 가능
- 계산과정을 통해 얻은 정보는 파생된 속성으로 저장
4) 외부와 상호작용하기 위한 제어 구현
- 프로그램 내부에서 변수값의 변화에 따른 제어 분리
- 상태 변화를 담당하는 클래스를 정의하여 구현
- 병행 태스크를 사용함
5) 상속성 향상을 위하여 클래스 구조 조정
- 클래스들 사이의 공통동작을 추출하여 상위 클래스로 정의
- 상속을 정의할 수 없는 경우 대표화하고 공동 구현
6) 관계를 설계한다
- 관계는 객체 사이에 접근 경로를 제공
- 관계는 분석과 모델화에 꼭 필요한 것
- 관계를 구현하는 방법을 결정
- 포인터, 양방향의 관계를 표현하는 객체를 도입 구현
7) 객체의 표현 방법을 결정
- 객체 표현의 형태와 관련된 객체의 그룹화를 결정
8) 클래스와 관계를 단일 모듈로 패키지화 한다
7.6 객체 모델링
7.6.1 개요
- 모델을 기반으로 주어진 문제를 분석하는 신사고 방법
- 사용자의 요구사항에 관한 정보를 추출하고 수집하는데 필요한 기법
- 의도한 것에 대한 추상화로 실제 만들기전에 이해하고자 하는 목적
- 모델은 원래보다 훨씬 이해가 쉽다는 특성
- 다양한 모델을 만들어 봄으로 얻는 잇점
: 실제를 만들기 전에 테스팅이 가능
: 고개과 대화의 수단으로 모델을 이용가능
- 하나의 시스템에는 하나의 모델만 존재하는 것은 아니다
- 좋은 모델은 완전하고 정확하기 보다는 추상화가 적절하게 이루어져야 한다
7.6.2 객체모델
- 시스템을 구성하는 객체의 구조를 기술
- 모델링의 가장 중요한 기반
- 객체와 클래스를 기본요소로 객체지향언어를 이용
: 구조적 방법은 알고리즘을 기본적인 요소로 구축하는 방법
(1) 추상화
- 불필요한 부분은 생략하고 객체의 속성 중 가장 중요한 것만을 개략화시킨 시스템
기술
(2) 캡슐화
- 객체의 데이터 부분과 함수부분 즉 처리에 필요한 작업을 하나로 묶은 개념
- 분석이나 설계단계에서 주어진 문제를 간단히 생각하는 추상화의 수단
- 추상화와 캡슐화는 상호 보완적인 방법
- 객체의 사용자가 내부 구현사항으로의 접근을 방지하므로 적은 노력으로 프로그램
수정 가능
(3) 모듈화
- 프로그램을 독립적으로 설계, 코딩하여 컴파일 가능한 모듈로 나누는 것
- 모듈간의 최단 연결을 갖게하여 실행
- 프로그램의 복잡도를 경감할 수 있다
(4) 계층화
- 계층구조가 문제이해를 증진 시킨다
- 추상화의 등급이나 순서를 정하므로 단계별 이해를 가능하게 한다
7.6.3 Dynamic Model
- 동적 모델의 구성요소는 사건과 상태
- 객체와 관련성등이 외부 자극에 반응해가는 동작들을 기술
- 사건에 의해 시스템이 변해가는 모양을 표현하는 상태전이도의 집합
- 하나의 객체가 행할 수 있는 행위의 순서가 중요
: 객체가 지니는 내부 상태에 의해 행위의 작동여부를 결정 가능
7.6.4 Object Modeling 분석의 기법
(1) 기능적 분해 기법
- 문제영역을 여러 가지 기능들과 하위의 부 기능들로 사상시키는 방법
- 주제 파악후 단계적 상세화와 기능적 추상화 관점에서 시스템이 제공해야 할
기능을 기수하는 방법
- 기능중심 분석은 요구명세서가 초기에 파악한 주제항목으로 사상이 곤란
- 적절한 기능 선택이 어렵다
- 기능성의 변화 가능성이 커서 추후의 변화에 대처하기가 곤란
(2) 자료흐름 기법
- 구조적 분석이라고 불림
- 실세계를 자료흐름의 에이지와 버블로 사상함
- 버블을 만들어 나가는 방법이 문제
1) 사건의 이동의 발생을 중심으로 버블을 만드는 방법
- 사건의 수가 늘면 버블 수가 늘어 이해가 곤란
2) 버블이 많으면 상위단계를 추가하는 방법
- 각 단계별로 레이블을 갖고 그들간의 연관성을 나타냄
- 자료사전의 크기가 문제
: 단계가 증가하면 자료사전의 수가 많아 지므로 복잡하다
: 복잡한 인터페이스로 자료사전의 크기가 증가하여 오류 유발 가능
(3) 정보 모델링 기법
- 객체를 찾고 객체가 갖고 있는 속성과 함께 기술하는 방법
- 객체들간의 관련성을 추가하고 정규화를 거쳐 완성함
- 문제 영역을 객체로 직접 사상 가능
- 정보모델링 기법의 부족한 부분
: 제공기능 - 다루어지게 될 처리와 관련 요구사항(오퍼레이션)
: 상속관계 - 속성과 제공 기능에서의 공통성 추출
: 메시지 - 객체들간의 잘 정의된 인터페이스
: 구조 - 분류구조와 집합구조
(4) 객체지향 모델링 기법
- 정보 모델링 기법의 가장 좋은 기법과 객체지향 프로그래밍 언어가 가진 기본적인
개념을 바탕으로 이루어진 기법
- 문제영역을 해결영역으로 직접 사상이 가능한 기법
- 객체 모델링 기법이 바람직한 이유
: 인간의 사고 또는 인간의 조직체가 지닌 요구(객체와속성, 분류구조와 집합구조)
를 그대로 정의 가능
: 문제영역의 이해에 중점을 둔다
: 속성과 속성을 다루는데 필요한 서비스를 취급
: 객체들간의 종속성을 최소화 한다
: 공통성과 추출이 가능하며 이를 나타내는 표현기법 소유
: 전과정이 일관되고 강력한 표현구조 소유
제 8 장. Program Language & Coding
8.1 개요
- 코딩 단계는 구현 또는 프로그래밍 단계
- 설계 명세서를 이용하여 소스 코드로 변환하는 단계
- 모듈의 내부설계 사양서를 '언어'로 기술하는 단계
- 이 단계의 주요 목표
: 명세와 코드가 일치하는 가의 점검
: 테스트와 변경이 용이하게 하는 소스 코드와 내부 문서 작성
- 이러한 목표를 달성하기 위하여
: 소스 코드를 간결하고 명료하게 작성
: 소스 코드를 작성하는 프로그램 언어의 선택이 중요함
8.2 Program Language의 선택
- 프로그래밍 언어의 선정시 고려해야 하는 요소
(1) 프로그래머가 프로그래밍 언어의 이용이 가능해야 함
- 컴파일러가 없으면 불가능
- 현재의 장비로 사용이 않되면 불가능
(2) 프로그래머가 프로그래밍 언어의 수와 사용의 통일을 희망
- 프로그래밍 언어가 난립하면 많은 프로그래머가 필요
- 훈련 경비와 소프트웨어의 유지보수비가 추가로 부담
(3) 어느 기계에나 설치가 가능해야 함
- 기계와는 무관하게 설치가 가능해야 한다
- 설치에 문제가 있다면 언어의 원활한 사용이 불가능
- 이기종 간에도 사용이 가능하면 보급이 광범위해진다
- 보급이 광범위해지면 프로그래머가 편리성을 제공받는다
(4) 프로그래머는 언어의 효율성을 고려해야 한다
- 효율은 시간과 기억장소의 양으로 표현한다
- 시간 효율은 처리시간과 번역시간으로 분리 가능
- 인터프리터를 사용할 때 기억장소가 적게 필요
- 컴파일러를 사용할 때 실행시간은 짧지만 번역시간이 길고 기억용량이 많이 필요
(5) 프로그래머는 응용목적에 알맞는 프로그래밍 언어를 선택해야 한다
- 프로그래밍 언어는 응용목적에 따라 각각 설계됨
- FORTRAN은 계산위주, COBOL은 데이터 중심언어, APL은 행렬계산을 목적
(6) 프로그래머의 개인적인 선호도
- 사용목적의 유사정도 효율면의 유사정도에 따라 언어 선정
- 목적이나 효율면이 유사한 언어는 거의 존재 불가능
- 언어의 선정은 개인의 선호도에 거의 의존적이다
8.3 자료 추상화
- Data Abstraction 또는 Data Capsulation 개념은 관심있는 특정자료를 여러 이름으로
여러 프로그램 언어에서 구현
- 자료를 수행할 연산과 함께 선언 기능과 정보은닉 개념의 도입으로 프로그램을 쉽게
읽고 유지보수가 용이하다는 중요 관점을 가짐
- 연산은 객체의 실체화, 구축, 소멸, 분리해내는 작업들을 포함
- 유사성을 표현하고 차이점을 삭제하여 관련 사항을 묶어 하나로 표현하는 방법
- Procedure는 어떻게 수행되는 가를 추상화시켜 주는 시간 중심의 연산 추상화 기법
- 프로그래밍 언어에서 자료 추상화는 자료형의 표현과 관련된 연산들을 함께 묶어
캡슐화하는 기법
- 캡슐화는 부적당한 사용자로부터 자료형을 보호하는 벽을 형성한다
- 호출하여 사용을 허락하는 것을 '창문'이라하고, 외부에 알려주는 부분을 공개부
또는 가시부라하고, 보호하는 부분을 전용부라 한다
- 공개하는 행위를 방출이라하고 다른 모듈에서 방출된 객체를 사용하도록하는 행위를
도입이라 한다
- 자료추상화의 설비는 새로운 자료형을 정의하고, 자료형의 변수를 선언하여 사용하게
한다
- 자료형의 표현을 보호하고 그 자료형에 사용될 연산을 구축하는 것을 제공한다
8.4 프로그램 언어의 분류
- 프로그래밍 언어는 구조적인 면, 기능적인 면, 자료구조를 처리하는 방법에 따라
구분 가능
- 정보처리 이용면에서 구분 가능
: 성형문법을 주요시하는 전통적인 언어
: 응용 위주의 응용 언어
: 기능적인 언어
- 전통적인 언어의 분류
1) 정적인 모델
- FORTRAN compiler
- program의 모든 변수를 처음에 할당하고 수행시에는 기억장소를 할당하지
않는 방법
- 기억장소의 낭비가 많음
2) 동적인 모델
- PASCAL, ALGOL
- 스택을 사용하여 프로그램 수행시에만 기억장소 할당하는 방법
- 기억장소의 절약 가능
8.5 Coding Style
- 소스 코드가 생성되면 설계명세서를 보지 않고도 기능을 알수 있도록 해야 한다
: 코드를 읽고 이해가 가능하도록 작성
- 코딩 스타일은 단순하고 간결해야하는 코딩 원칙에 따라야한다
- 코딩 스타일 결정요소
: Structured Coding
: 문서화 자료선언
: 문장의 작성 방법
(1) Structured Programming
- 신뢰성있는 소프트웨어의 생산과 코딩의 표준화등을 위해 개발된 방법
- Structured Programming의 Diagram에 따라 코딩하는 특징
: Structured Programming 기법을 적용한 일종의 기능 양식
: 우리의 자연언어인 한글로 기술 가능
: 프로그램의 생산성, 신뢰성 및 유지보수성을 향상 가능
- 프로그램 작성방법의 설명
- 프로그램의 기본구조 설명
- 프로그램의 기본구조와 응용 형태
(2) 코드의 문서화
- 소스 코드의 내부 문서화는 식별자 명칭의 선택, 비 실행문장의 참조, 프로그램의
외형까지를 포함
- 식별자의 명칭은 명칭자체가 특별한 의미를 가지도록 정의해야 한다
: 식별자 명칭의 레이블의 크기를 제한하므로 충분한 의미 부여가 불가능
: 식별자 명칭이 길 경우 논리적 흐름과 수정작업의 곤란 초래 가능
: 뜻이 있는 식별자 명칭을 사용하므로 프로그램의 인식을 용이하게 한다
- 소스 코드의 부분으로 비 실행 주석문의 사용에 대한 의문
: Comment는 어느 정도가 충분한가
: Comment는 어느 장소에 쓸 것인가
: Comment를 사용하면 논리적 사고를 방해하지 않는가
: Comment가 프로그램을 잘못 이해하도록 하지는 않는가
: Comment는 정비가 가능한가
- 소프트웨어는 반드시 문서화되어 있어야 한다
- Comment는 소프트웨어 Life Cycle 중 유지보수의 용이를 위한 지표
- 소프트웨어는 반드시 문서화가 되어 있어야 한다
- Comment는 소프트웨어 Life Cycle 중 유지보수를 위한 자료
- Comment 달기의 규약
: 다음을 사용하여 주석의 필요성을 최소화할 것
- 표준 프롤로그
- 구조적 프로그래밍 스타일
- 훌륭한 코딩 스타일
- 사용자 정의 자료형, 변수, 형식매개변수, 부울문자, 서브프로그램, 파일등에
대한 문제 영역으로 부터의 기술적 명칭
: 다음과 같은 기능을 갖는 Code Block에 주석을 달 것
- 주요 자료처리의 실행
- goto 문을 사용하여 구조적 제어 구조를 가장
- 예외 조치를 실행
: 주석 내에 문제 영역 관련 용어를 사용할 것
: 주석을 부각 시키기 위하여 빈줄, 테두리등을 사용할 것
: 변경과 개정 사항등은 맨 우측에 위치하도록 할 것
: 분명하지 않은 복잡한 문서를 코드화하기 위해서 긴 주석을 사용하지 말고
코드를 재작성 할 것
: 주석과 코드는 일치하며, 요구 사항과 설계사양과도 일치하는가를 항상 확인
(3) 자동 프로그래밍
- 최근의 소프트웨어 프로그래밍은 설계 데이터 베이스와 추상화 데이터로 설계된
소프트웨어 Component를 검색하여 번역을 자동적으로 하여 프로그램 작성
- 코드 Generator는 자동 프로그래밍을 실행해 주는 도구로서 CASE 환경에서 사용
- CASE는 소프트웨어 Life Cycle에 동원되는 도구의 집합체
- CASE의 구조
: Upper-CASE - front-end 도구로 분석과 설계를 메꾸어 주는 도구
: Lower-CASE - back-end 도구로 code generator를 말함
- 1988년부터 통합 CASE의 기능을 가지도록 개발 시작
- CASE는 중앙집중 설계 저장소나 자료사전에 의하여 통합기능 발휘 가능
- 또 다른 CASE의 통합은 Framework나 'Bridge'를 채택함
: 여러 개발자가 제공한 도구를 표준화된 인터페이스 양식에의해 설계 database를
만들어 수행하는 방법
- 현재 개발된 Code Generator
1) 4GL
: 비절차 언어
: Report 작업, Report의 검색과 편집등의 기능을 Compile 없이 번역 가능
: label-drivend 언어의 형식을 위하여 testing이나 prototyping을 빨리 수행
가능
2) Code Generator
: 4GL과 비슷한 고급 인터페이스
: 3GL 언어의 호환 Code나 system code 생성
: Program Language들은 Program 사이의 interaction이 복잡
3) 응용 생성기
: 특정분야의 응용 소프트웨어를 생성
: 표준화된 데이터 사전과 사용자 인터페이스를 사용해야한다
: 개발환경은 다음의 표준화된 문서환경을 제공한다
- input/output system 흐름도
- 물리적 설계 명세서(액세스 방법, 레코드 길이, 파일명 형식등)
- 스크린 레포트 출력 양식
- 필드 정의와 속성
- 중간 생성된 항목의 정의
- menu navigation tree
- 자료항목 요소들을 논리적 관계
- 자료항목과 모듈을 설명한 레포트
8.6 표준화
- 코딩의 표준화는 코딩 스타일에 대한 정의
- 효과를 얻기 위한 방법이 선택되면 선호하는 방법 정의
- 모든 코딩의 기술은 기본적인 표준 체제내에서 구사하는 것이 좋다
- 소프트웨어 프로젝트에 참여하는 모든 프로그래머는 일정한 질의 코드가 생산 가능
하도록 유사한 코딩 스타일을 채택하는 것이 바람직하다
- 프로그램의 표준보다도 프로그램의 지침이라는 용어로 선호하는 경향이 많다
- 프로그램의 지침
: 가능하면 goto문의 사용을 피한다
: 프로그램 구조에서 nesting의 깊이는 가능하면 5를 넘기지 않는 것이 좋다
: 서브프로그램내의 실행 가능한 문장의 수는 가능하면 30라인을 초과하지 않는
것이 좋다
: 이러한 지침을 벗어날 경우 프로젝트 리더의 승인 필요
- 이러한 프로그래밍 지침은 소프트웨어의 질을 향상시키기 위하여 개발되어야 한다
제 9 장. S/W Testing 방법
9.1 테스팅의 정의
- 테스팅 : 소프트웨어 개발 공정 중에서 가장 노력과 비용이 집중적으로 투자되는
수고스러운 작업으로 기능과 성능을 확인하는 작업
- 테스팅 방법 : 단위 테스트 → 통합 테스트 → 확인 테스트 → 시스템 테스트
9.1.1 단위 테스트
- 소프트웨어 설계의 최소단위인 모듈의 검증에 초점을 맞추어 상세설계 명세서를
지침으로 중요한 제어 경로들을 테스트
- 화이트박스 테스트라고 함
(1) 단위 테스트의 고려사항
- 모듈 인터페이스
: 테스트되는 모듈의 내부 또는 외부로 전달되는 정보를 보증하기위해 테스트
- 지역자료구조(local data structure)
: 알고리즘이 실행되는 모든 단계 동안에 값이 변하지 않게 일시적으로 저장된
데이터를 보증하기위해 검사
- 독립경로(independent path)
: 제어구조를 통해 기본이되는 경로들이 모듈간의 모든 문장들을 적어도 한번
실행하는지 테스트
- 에러처리(error handling)
- 경계조건 테스팅
: 단위 테스팅 중 가장 나중에 테스트하는 것으로 경계조건에 대한 잘못을 검사
(2) 단위 테스트의 절차
- 모듈은 독립된 프로그램이 아니므로 테스트 드라이버 또는 스텁(stub)이 만들어
져야 함
9.1.2 통합 테스팅
- 모듈을 몇 개 결합하여 하나의 시스템으로 완성시키는 과정에서의 테스트로 각
모듈간의 인터페이스를 검사
(1) 하향식 테스트
- 장점 : 하위모듈이 테스트 시에 테스트가 이미 끝난 상위 모듈을 이용하기 때문에
시스템의 실제 가동 환경과 유사한 환경에서 테스트가 이루어진다
: 테스트의 최초 단계에서 인터페이스의 검증이 가능
- 단점 : 테스트 초기에 병행 작업이 곤란
: 시스템 내용에 따라 스텁의 작성에 많은 노력 필요
(2) 상향식 테스트
- 시스템 하위 레벨의 모듈로부터 테스트를 진행
- 테스트 초기 단계부터 병행 작업이 가능하고 모듈단위의 테스트를 철저히 할 수
있다
- 인터페이스의 테스트가 가정인 상태로 행해짐
9.1.3 확인 테스팅
- 사용자 요구사항에 대한 만족 여부를 검사하는 블랙박스 테스팅을 통해 이루어진다
- 검사되는 요구사항
: 기능적요구, 성능요구, 문서화의 타당성, 전달 용이성, 에러 회복성, 유지 보수성
9.1.4 시스템 테스팅
- 서로다른 목적을 간진 일련의 테스트들로 이루어짐
- 모든 요소들이 적합하게 통합되고 올바른 기능을 수행하는지 검사
9.2 테스트 케이스 설계
9.2.1 테스트 케이스의 정의
- 프로그램 테스팅 과정중 가장 중요한 일은 효과적인 테스트 케이스를 설계하는 것
9.2.2 블랙박스 테스트
- 프로그램의 논리를 고려치 않고 프로그램의 기능이나 인터페이스에 관한 외부
명세로부터 직접 테스트하여 데이터를 선정하는 방법
1) 동등분할(equivalence partitioning)
- 프로그램의 입력 도메인을 테스트 케이스가 산출될 수 있는 데이터의 클래스로
분류하는 방법
2) 경계값 분석(boundary value analysis)
- 입력 조건의 중간값에서 보다도 경계값에서 에러가 발생될 확률이 높다는 점을
이용하여 이를 실행하는 테스트 케이스를 만드는 방법
3) 원인-결과 그래핑(cause-effect graphing)
- 외부 명세에 의해 원인에 해당되는 입력조건과 그 원인으로부터 발생되는 출력
결과를 논리적으로 연결시킨 그래프로 표현하여 테스트 케이스를 유도
9.2.3 화이트박스 테스트
- 프로그램 원시 코드의 논리적 구조를 커버하도록 테스트 케이스를 설계
- 프로그램 내부 구조에 존재하는 모든 경로를 실행하는 것이 목표
제 10 장. 소프트웨어 품질 관리
10.1 소프트웨어의 품질 목표
(1) 세가지 구성요소
- 시스템에 중요한 품질 관점을 확립하고 그의 우선순위를 결정 -> 시스템 품질목표
설정
- 이런 품질 목표의 개념을 가지고 시스템 설계
- 해당 품질 목표가 만나는 각 단계에서 시스템을 평가
(2) 시스템 품질관리 측면에서의 품질 목표
- 효율성(efficiency) - 융통성(flexibility) - 완전성(integrity)
- 상호운용성(interoperability) - 유지보수성(maintainability)
- 이식성(portability) - 신뢰성(reliability) - 정확성(correctness)
- 재사용성(reusability) - 테스트 용이성(testability) - 사용용이성(usability)
10.2 국제 표준기구(ISO)의 품질목표
- 기능성(functionality) - 신뢰성(reliability) - 사용성(usability)
- 효율성(efficiency) - 유지보수성(maintainability) - 이식성(portability)
10.3 소프트웨어 품질관리
- 소프트웨어 품질을 보증하기 위해서는 s/w 관리의 효율성을 증진 시켜야 함
(1) 품질관리를 위한 계획
- 프로젝트 수행계획의 수립
: 제어점 수립
: 표준화 수립
: 제어절차 수립
: 스태프 평가 수립
(2) 품질 보증팀의 조직관리
- 좋은 품질의 s/w를 생산하기 위해 요원들을 적절하게 조직하고 관리하는 문제는
s/w 프로젝트 관리의 중요한 문제
10.4 CASE 시스템
10.4.1 CASE의 목표
- 좋은 품질의 제품을 가능한 적은 노력과 비용을 들여 얼마나 많이 만들어내는가
- CASE(Computer-Aided Software Engineering)
: s/w 개발의 자동화
: s/w 생명주기의 전체 단계를 연결시켜주고 자동화 시켜주는 통합된 도구들 제공
: 전체적인 s/w 생산성과 신뢰성 문제에 초점을 맞춘다
- CASE 시스템의 잇점
: s/w 공학개념 적용, 자동화된 검사를 통한 s/w 품질향상, 프로그램 유지보수의
간편, 개발기간 단축 및 비용절감
10.4.2 CASE 도구
- 프로젝트를 포함하는 광범위한 s/w 개발 및 유지보수 작업의 자동화를 지원
(1) 다이아그램 작성도구 - 사용자나 시스템 설계자가 시스템의 범위와 내용에 관한
내용을 다이아그램 형태로 표현하고, 이해하고, 개선해 나갈
수 있게 해줌
(2) 설계 분석기 - 설계 명세에 있어서의 내부 불일치성, 모호성, 불완전성등을 자동검사
(3) 코드 생성기 - 다양하고 일관성있는 명세서로부터 고 수준의 프로그래밍 언어로
쓰여진 모듈화된 코드 생성
(4) 전문가 시스템 - 자료와 규칙을 포함하는 지식 베이스에 대한 추론 작업 수행
(5) 원형화 도구 - 시스템 요구사항을 결정하고 생산되어질 시스템의 작동에 관한 질문에
응답
(6) 프로젝트 관리 지원도구 - 작업능력 향상과 효율 극대화를 위해 CASE 정보저장소를
접근하여 정보를 얻는다
(7) 재공학 도구
제 11 장. S/W 유지보수
11.1 유지보수의 특성
(1) 소프트웨어 유지보수
- 소프트웨어가 제품으로 개발된 후 사용자가 사용하기 시작하면서부터 폐기될 때
까지 오류를 수정하거나 새로운 기능을 추가하기위해 소프트웨어를 변경하는
프로세스를 의미
(2) 유지보수의 구분
1) 완전화 보수(perfective maintenance)
- 입출력형식을 개선하는 경우로 기능상 변경없이 독해성을 향상시키는 보수형태
2) 적응 보수(adaptive maintenance)
- 소프트웨어를 운용하는 환경 변화에 대응하여 소프트웨어를 변경하는 경우
3) 수리 보수(corrective maintenance)
- s/w 테스팅 동안 밝혀지지 않는 모든 잠재적 오류를 수정하기 위한 보수
4) 예방 보수(preventive maintenance)
- 장래의 유지보수성 또는 신뢰성을 개선하거나 s/w 오류 발생에 대비하여 미리
예방수단을 강구해두는 경우
11.1.1 유지보수 비용
- 유지보수 비용 요인
1) 비 기술적 요인
- 응용분야, 유지보수 요원의 안정성, 프로그램 수명, h/w의 안정성, 외부환경
2) 기술적인 요인
- 모듈간의 독립성, 프로그래밍언어, 프로그래밍 스타일, 프로그램 검증과
테스팅, 프로그램 문서화의 양과 질
11.1.2 유지보수성의 척도
- 프로그램의 복잡도를 측정 : 상대치를 의미
11.2 유지보수 작업의 순서
- 기존 수정 : 이미 개발이 끝난 s/w의 구성요소에 있어서 일부를 수정
- 신규 추가 : 이미 개발이 끝난 s/w의 구성요소에 새로운 기능을 추가
- 순서
기존 s/w의 이해 → 신규 추가의 경우 신규 s/w의 개발, 기존 수정의 경우 기존
s/w의 수정 → 통합 테스트에 의한 일관성 검증 → 보수 완료시의 검사 실시 →
보수 상황 관리들의 작성, 관리
11.3 시스템의 재구성
- 현 시스템을 검사하여 전체 구조를 개선하기 위해 시스템의 일부를 재작성하는 것
- 고려사항
1) 변경부분과 빈도
2) 지원 소프트웨어에 대한 의존성
3) 재구성의 존재여부
11.4 소프트웨어 형상관리(configuration management)
- 소프트웨어에 대한 변경을 관리하기위해 개발된 일련의 활동
11.4.1 형상관리 계획
- 어떤 항목이 정형적인 형상관리하에 놓이게 되는지를 결정
11.4.2 변경 제어
- 소프트웨어 시스템에 대한 변경효과가 예측될 수 있도록 하는 것
11.5 유지보수 메뉴얼
- 시스템의 개발 및 보수, 운용에 필요한 모든 자료를 문서화한 것
11.5.1 문서의 표준화 목적
- 생산성 향상
- 고객의 신뢰
- 개발 비용 최소화
11.5.2 문서의 표준화 효과
(1) 개발자 측면의 효과
- 소프트웨어 및 시스템 기본 기능의 이해 편리
- 시스템 분석 및 설계 용이
- 프로그램 작성 용이
- 프로그램 수정의 효율이 증대
- 프로그램 보수, 개조가 용이
(2) 관리자 측면의 효과
- 작업 계획의 수정이 용이
- 작업 관리 용이
- 인원 투입 계획의 수립이 용이
- 작업의 분업 및 외주관리 용이
11.5.3 문서의 표준화시 주의사항
- 표준화에 대한 거부감을 갖지 않도록
- 표준화의 확실한 방향 제시
- 모든 사람이 만족하는 표준화 안의 작성이 어렵다
- 관리자의 확실한 의지 표명
- 새로운 기술의 적극 적용
- 즉각적인 수정을 하는 융통성
11.6 문서의 유지보수
- 프로그램에 변경이 발생했을 때 모든 관련 문서는 변경되어야 한다
|