제목dasan.sejong.ac.kr/~smchoi/se_13.ppt · PPT file · Web view · 2007-11-23구현 단계 Overview Choice of programming language Fourth generation languages Good programming

구현 단계

Software Engineering 2

Overview Choice of programming language Fourth generation languages Good programming practice Coding standards Module reuse Module test case selection Black-box module-testing techniques Glass-box module-testing techniques Code walkthroughs and inspections Comparison of module-testing techniques Cleanroom Potential problems when testing objects Management aspects of module testing When to rewrite rather than debug a module CASE tools for the implementation phase Air Gourmet Case Study: Black-box test cases Challenges of the implementation phase


13.0 구현 단계 개요 구현 (implementation)

상세 설계를 코드로 변환하는 프로세스 프로덕트

프로덕트의 다른 컴포넌트를 동시에 팀이 맡아 구현

programming-in the many 라고 불림


11.1 프로그래밍 언어의 선택 비용 - 이익 분석을 사용하여 결정 추정 이익과 추정 비용간의 차이가 커서 가장 기대가 되는

언어가 적합한 구현 언어 언어의 잠재적 위험과 이를 해결하는 방법을 목록으로

작성한후전체 위험이 가장 적은 언어 선택 오늘날에는 갹체지향 소프트웨어 중심으로 C++,JAVA 등으로

작성 . C 는 구조적 파라다임의 프로덕트 , C++, JAVA 는 객체지향

파라다임용 프로덕트 객체지향 기법을 사용하면 객체와 클래스로 구성 소프트웨어 전문가들은 객체지향 파라다임에 관한 교육 필요 JAVA 프로그래머는 시작부터 객체지향 파라다임 사용 4 세대언어에서 구현이란 무엇을 의미하는가 ? 다음절에서 학습


13.2 4GL

1 세대 언어 (first generation language) 이진수 기계어 코드

2 세대 언어 (second generation language) Assembler

3 세대 언어 (third generation language) 한 문장은 5~10 개의 Assembler 문과 같음 FORTRAN, ALGOL 60 또는 COBOL 등 컴파일러 언어 고급 언어

유지보수에 적은 비용 소요


4GL

4 세대 언어 (fourth generation language) 4GL 문장이 30~50 개의 기계 코드 명령어와

동등 FOCUS 나 Natural 과 같은 4GL 로 작성된 프로덕트는

코드가 짧아서 단기간 개발 유지보수 용이

프로그래밍 작성 용이 4GL 들은 비절차적 (nonprocedural) 언어

디버깅 용이 사용자 친숙


4GL

4GL 전환시 모순된 이유 하나의 4GL 이 모든 프로덕트에 부적합 많은 4GL 이 강력한 CASE 워크벤치와 환경의 지원이

필요 4GL 의 실패는 4GL 의 자체보다 연관된 CASE 환경 영향 내재된 위험

4GL 설계 목적 end-user programming

위험 엔드 - 유저 프로그래밍은 위험할 수 있음 데이터베이스를 업데이트하는 4GL 프로덕트를 작성하는

경우 사용자가 만든 프로그래밍의 오류는 전체 데이터베이스를 변조시킴

4GL 의 최종 선택은 관리자 책임


13.3 옮바른 프로그래밍 습관

좋은 프로그래밍 습관 권고사항1. 일관되고 의미 있는 변수명을 사용

소프트웨어 공학에서 의미 있는 (meaningful) 이라는 용어는 “미래에 유지보수를 담당하는 프로그래머 관점에서도 의미 있는”이라는 의미

변수명은 의미적으로 같아야 함 일관성에 관한 두 번째 측면

변수명의 컴포넌트들의 순서


Good Programming Practice

2. 자기 문서화 코드의 문제 다른 프로그래머와 품질 보증 활동을 하는 SQA 그룹 , 또 많은

유지보수 프로그래머들에게 모듈이 읽기 쉽고 모호성 배제 모듈의 비문서화 코드는 경험 있는 프로그래머도 부분적으로만

이해 프롤로그의 코멘트 (Prologue Comment) 는 단일 모듈이 필수적 모듈의 최상단에 제공되어야 하는 최소 정보

모듈 이름 모듈이 무엇을 하는지에 대한 서술

프로그래머 이름 모듈이 작성된 날짜 : 모듈이 승인된 날짜와 승인한 사람 모듈 인수들 알파벳순으로 작성된 변수명의 목록과 사용 접근한 파일명 모듈에 의해 변경된 파일명 등



3. 파라미터의 사용 변수의 값이 결코 변하지않는 불변의 상수인 경우는

드물다 . 고로 이를 해결하기 위해 변수를 사용 . 다음의 선언 예를 보면 알수 있음 public static final float salesTaxRate = (float) 6.0; 즉 이 선언은 판매세 값이 필요할 때마다 숫자 6.0 을

사용하지 않고 상수 salesTacRate 사용



4. 가독성 증가를 위한 코드 배치 모듈을 읽기 쉽게 만드는 것 한 문장은 한 라인 들여쓰기는 가독성을 증가시키는 중요한 기법 공백줄에 의해 구분



5. 중첩된 if 문 If- if 구조를 포함하는 복잡한 코드를 만났을때

이것을 단순화 시킴 .즉 다음의 if-if 조합 if<condition1> if<condition2> 은 다음의 단일조건으로 단순화 시킴 . if<condition1> and if<condition2>






13.4 코딩 표준 코딩 표준 (coding standard) 은 장단점을 동시에 포함 모든 모듈은 35~50 개 사이의 실행 가능한 문장으로 구성 중요점

모든 환경에서 적용할 수 있는 코딩 표준이 없음 코딩 표준이 기계에 의해 체크될 수 없다면 SQA 그룹의 시간이 많이 낭비되거나 프로그래머나 SQA 그룹에 의해 쉽게 무시될수 있음 .다음과 같은 규칙을 살펴보자 .예

1) if 문의 중첩 3 단계 이상 초과하지 암ㅎ도록 함 . 2) 모듈은 30~50 개의 문으로 구성되어야 함 . 3) goto 문의 사용 회피해야 함 . 그러나 팀 리더로 허락을 받으면

에러처리를 위해 사용가능 . 이러한 규칙은 표준에 어긋난 것을 잡아내는 메커니즘이 제공되면

기계가 체크함 . 어떤 조직은 모듈명과변수명에 관한 엄격한 표준을 갖고 있음 . 코딩 표준 목적은 유지보수를 용이하게 하는데 있음 . 즉 유지보수 용이성임 .


13.5 모듈 재 사용 Reuse 의 중요성은 아무리 강조해도 지나치지 않음 . 소프트웨어의 모든 프로세스 단계에서의 컴포넌트들은 명세 , 계약 , 계획 , 설계 , 그리고 모듈 등의 각 부분에서 재사용 가능


13.6 모듈 테스트 사례 선택 방법론적인 테스팅 두 가지 기본 타입

모듈이 팀에 의해서 검토되는 비실행 - 기반 테스팅

모듈이 테스트 사례에 반대로 실행되는 실행 -기반 테스팅

모듈을 테스트하는 최악 방법 우연한 테스트 데이터 사용

테스트 사례들은 반드시 체계적으로 구축


모듈 테스트 사례 선택 모듈 테스트 데이터 구축 두 가지

명세 테스트 블랙 박스 (block-box), 구조적 (structural), 데이터 중심

(data-driven), 기능적 (functional), 입력 / 출력 중심 (input/output-driven) 테스팅이라고 불림

코드 자체는 무시되고 테스트 사례를 기술하는데 사용되는 정보는 명세 문서

코드 테스트 테스트 사례를 선택할 때 명세 문서를 무시 글래스 박스 (glass-box), 화이트 박스 (white-box), 행위 (behavioral), 논리 중심 (logic-driven), 또는 경로 지향 (path-oriented) 테스팅이라고 불림


모듈 테스트 사례 선택 명세에 대한 테스팅의 타당성

예제 어떤 데이터 프로세싱 프로덕트의 명세가 수수료의 5

가지 유형과 할인의 7가지 유형이 통합되어야 하는 것을 기술하고 있다고 가정하자 수수료와 할인의 가능한 모든 조합에 대한 테스팅 35 개의 테스트 사례 요구 오직 두 가지 인자만 존재 수수료와 할인으로 각각 5 가지와 7가지 값 만약 20 개의 인자를 갖고 각각 오직 4 개의 다른 값을 갖는다면 , 전체 420 또는 1.1*1012 개의 테스트 사례 검사


모듈 테스트 사례 선택 코드 태스팅의 타당성

코드를 테스트하는 공통적인 형태는 모듈을 통하는 각 경로는 적어도 한번 이상 실행 요구 그림 13.6 순서도 중앙에 진하게 만든 6

개의 박스 그룹을 통해 5개의 가능한 경로가 있다 . 그리고 순서도를 통한 가능한 경로의 개수는 다음과 같다 51 + 52 + 53 + … + 518 =

4.77 * 1012

가능한 경로수가 커도 명세에 철저한 테스팅을 실행할 수 없지만 코드에는 철저한 테스팅 필요



코드의 테스팅은 테스터에게 모든 경로 조사 요구 코드 테스팅

신뢰성 결여 그림 13.7 코드

프래그먼트 (code fragment) 를 생각해 보자

If ((x+y+z) /3 == x) System.out.println(“x,y,z are in valu

e”);Else System.out.println(“x,y,z are Unequa

l”);

Test case 1 : x =1, y = 2, z = 3Test case 2 : x = y = z = 2

그림 13.7 세 개의 정수가 두개의 테스트 사례와 함께 같은지 결정하는 부정확한 코드 프래그먼트



첫 번째 테스트 경우 평균값은 6/3 또는 2 이므로 1 과 다름 프로덕트는 정확하게 테스터에게 x,y,z는 같지 않음을 알림

두 번째 테스트 경우 정수 x,y,z은 모두 2 와 같으므로 프로덕트는 2 와

같이 평균 계산 x값과 같아서 프로덕트는 정확하게 세 수는 같다는

결론


모듈 테스트 사례 선택 경로 테스팅의 어려움

경로가 제시된 경우에만 테스트 그림 13.8(a) 코드

프래그먼트 d=0 d≠0 도 테스트할 수

있는 두 가지 경로 존재 그림 13.8(b)

단일문은 만약에 프로그래머가 코드에서 d=0 을 체크하는 것을 생략했다면 , 이 프로그래머는 잠재적인 위험을 인식하지 못해 d=0인 경우가 프로그래머의 테스트 데이터에 포함되지 않음

If (d == 0) zeroDivisionRoutine();ElseX = n / d;

(a)

X =n / d;

(b)

그림 13.8 몫을 계산하는 두개의 코드 프라그먼트


모듈 테스트 사례 선택 경로 테스팅의 어려움

조합의 급격한 증가 때문에 명세에 대한 철저한 테스팅도 코드에 대한 철저한 테스팅도 사실상 수행 불가능 중재안은 가능한 한 많은 결함을 알아낼 수 있는 기법

필요 해결 방법

블랙 -박스 테스트 사례 ( 명세에 대한 테스팅 ) 글래스 -박스 ( 코드에 대한 테스팅 ) 사용하여 추가 테스팅 사례 개발


13.7 블랙 - 박스 모듈 테스팅 기법테스팅의 기술은 결함을 발견할 기회를

최대화시키면서 한 개 이상의 테스트 사례로 같은 결함을 찾게 해서 낭비를 최소화시키기 위해 작고 관리하기 쉬운 테스트 사례 집합을 고안하는 것

블랙 -박스 기법 경계값 분석 (boundary value anaylsis) 을

결합시킨 동등 테스팅 (equivalence testing) 임


블랙 - 박스 모듈 테스팅 기법 동등 테스팅과 경계값 분석

동등 클래스 (equivalence class) 테스트의 사례 집합으로서 좀 더 정확하려면 , 레코드개수의 범위가 프로덕트의 다음에 정의된 세 개의 동등 클래스를 처리할 수 있도록 기술

동등 클래스 1 : 1 개의 레코드보다 적음 동등 클래스 2 : 1레코드에서 16,383레코드 까지 동등 클래스 3 : 16,383레코드보다 많음


블랙 - 박스 모듈 테스팅 기법 동등 클래스의 기법을 사용한 데이터베이스 테스팅

각각 동등 클래스로부터 하나의 테스트 사례가 선택되는 것을 요구 성공적인 테스트 사례는 이전에 발견되지 않은 결함을 발견하는 것 .

결함을 발견하는 기회를 최대화하기 위한 high-payoff 기법이 경계값 분석 (boundary value analysis) 임 .

경험에 의하면 동등클래스의 경계한쪽 측면이 선택되었을 때나 결함이 발견될 확률의 가능성이 증가하는 것을 보여줌 .

동등 클래스의 사용은 입력명세와 출력명세 모두를 테스트하기 위해서 경계값 분석과 함께 가치 있는 기법


블랙 - 박스 모듈 테스팅 기법 기능 테스팅

블랙 -박스 테스팅 대안은 모듈의 기능성에 관한 테스트 데이터에 기반을 두고 있음 .

기능 테스팅 (functional testing) 에서 모듈에 구현된 기능성이나 기능의 각 항목이 식별되어야 함 .

모듈의 모든 기능이 결정된 후 , 테스트 데이터는 각 기능을 독립적으로 테스트하기 위해 고안 만약 상위 - 단계 기능이 다음의 형식으로 구성되었다면

<상위 - 단계 기능> ::= if<조건식> <하위 - 단계 기능 1>; else <하위 - 단계 기능 2>;


블랙 - 박스 모듈 테스팅 기법 이는 <조건식 >, <하위 - 단계 기능 1>, 그리고 <하위 - 단계 기능 2>가 기능 테스팅에 종속되므로 <상위 - 단계 기능 >은 글래스 -박스 기법과 분기 수렴을 사용하여 테스트 가능 하위 - 단계 기법

블랙 -박스 기법 사용하여 테스트 상위 - 단계 기법

글래스 -박스 기법 사용하여 테스트


13.8 글래스 -박스 모듈 태스팅 기법

Glass-box technique 에서 테스트 사례는 명세보다는 코드 조사에 근거하여 선택

글래스 -박스 테스팅은 문 (statement), 분기 (branch), 경로범위 (path coverage) 를 포함하는 많은 다른 형식이 있음 .

13.8.1 구조적 테스팅 : 문 , 분기 , 경로범위 Statement coverage: 글래스 -박스 테스팅중 가장 단순한 형태로 , 모든 문은

적어도 한번씩 수행되는 동안에 일련의 테스트 사례가 실행 됨 . CASE툴은 각 문이 얼마나 테스트되었는지를 기록 .

Branch coverage: 문범위에 대한 개선책으로 모든 분기는 적어도 한번은 테스트된다는 일련의 테스팅을 실행한다는 의미 .틀은 평상시 테스터가분기들이 테스트되었는지를 확인하는데 도움을 줌 .

비고 ;문이나분기범위와 같은 기법을 구조적 테스트 (structural test) 라고 부름 . path coverage: 구조적 테스팅의 가장 강력한 형식 . 모든 경로의 테스팅임 . All-definition-use-path coverage: 테스트할 경로의 수를 감소시켜주는 또 다른

방법 임 . 이는 비교적 소수의 테스트 사례로 많은 결함을 발견하는 우수한 테스트 기법임 . 그러나 경로수의 상한선 2**d인 것이 단점임 .d 는 프로덕트에서 결정 문 (branch) 들의 수 .

비고 : 구조적 테스팅을 사용할때 테스터는 특정 문 , 분기 , 경로를 조사하는 테스트 사례에 대처할수 없는 상황이 발생할수 있음 .


구조적 테스팅 문 범위 (statement coverage)

문이 실행되는 트랙을 유지하기 위해서 CASE 툴은 각 문이 일련의 테스트를 얼마나 많이 실행하는지 기록 접근법 단점

분기의 모든 결과가 타당하게 테스트를 보장할 수 없음 그림 13.9 의 코드

프로그래머는 복합조건 s > 1 && t == 0 를 s > 1 || t == 0로 읽는 실수를 할 수 있다 . 그림에서 테스트 데이터는 결함 발견 없이 문 x = 9 를 실행한다

개선책 분기 범위 (branch coverage) 모든 분기는 적어도 한번은 테스트된다고 보장하는 일련의 테스팅 실행이 필요


구조적 테스팅 문이나 분기 범위와 같은 기법 강력한 형식

경로 범위 (path coverage) 모든 경로의 테스팅

경로를 선택하는 한 가지 기준은 코드 순서를 순차적으로 하는 테스트 사례로 제한 선형 코드의 순서 L 의 요소의 시작되고 L 요소로 끝나는 경로 모든 경로 테스트를 하지 않고 많은 결함을 발견한 이 기법은 성공적임


구조적 테스팅 : 문 , 분기 , 경로 범위 All-definition-use-path coverage

비교적 소수의 테스트 사례로 많은 결함을 발견하는데 우수한 테스트 기법

테스트할 경로의 수를 감소 실제 프로덕트에서는 상한선 2**d 에 도달하지 않고

경로의 실제 수는 d 에 비례 이론적인 상한선보다 상당히 작기 때문에 테스트 사례

수가 필요 실질적인 테스트사례 선택 기법 단점

경로수의 상한선 : 2d(d : branch 의 수 )


13.8.2 복잡도 매트릭

품질 보증 관점은 글래스 -박스 테스팅 다른 접근법을 제공 결함의 수를 예측하는 간단한 매트릭 코드 라인수 결함의 수

전체적으로 프로덕트의 크기에 관련이 있다는 것을 제시


복잡도 매트릭

순환 복잡도는 모듈의 분기 범위에 필요했던 테스트 사례의 수에 대한 매트릭으로 사용될 수 있다 . 이것은 이른바 구조적 테스팅의 기초가 된다

복잡도 매트릭 결함율을 예상하는 코드 라인에 대한 작은 개선책 제공

McCabe 의 순환 복잡도 코드의 라인으로 쉽게 계산 M값이 높다면 모듈이 결함을 포함한 확률이 커짐 Halstead 의 소프트웨어 과학 매트릭도 결함 예측에 사용

JAVA 와 C++ 같은 근래의 언어에 적용할 때는 문제 발생


복잡도 메트릭

Halstead 의 Software science( 소프트웨어 과학 ) 또한 결함 예측에 사용 , 이의 네 가지 기본 요소 (Halstead 제안 ,77)중 두 가지는 모듈 내의 연산자수

n1 과 피연산자 수 n2 대표적인 연산자 : +, *, if, g

oto 가 포함 피연산자 : 사용자 정의

변수나 상수 두 가지 기본 요소

연산자의 총수 N1 과 피연산자의 총수 N2

네 가지 기본 요소는 결함 예상 매트릭의 입력으로 넘김


Problem with These Metrics

Both Software Science, cyclomatic complexity Strong theoretical challenges Strong experimental challenges High correlation with LOC

Thus we are measuring LOC, not complexity Apparent contradiction

LOC is a poor metric for predicting productivity No contradiction-LOC is used here to predict fault ra

tes, not productivity


13.9 코드 워크스루와감사

코드 감사는 수정적 유지보수 비용을 95% 까지 감소 코드 감사 수행하는 이유

대안인 실행 - 기반 테스팅 ( 테스트 사례 ) 이 두 가지 방법에서 상당한 비용 소요 시간 소비 감사는 실행 - 기반 테스트보다 생명주기의 초반에 결함 발견과 수정

테스트 사례 실행 비용이 많이 드는 극단적인 경우 NASA Apollo Program 의 소프트웨어 예산 중 80% 가 테스팅에 사용되었음


13.10 모듈테스팅 기법들의 비교 Myers 는 블랙 -박스 테스팅 , 블랙 -박스와 글래스 -박스 테스팅의 조합 , 그리고 3인 코드 워크스루 비교 비용 -효과면에서는 코드 워크스루가 다른

기법에 비해 적다는 것이 판명 Hwang 은 블랙 -박스 테스팅 , 글래스 -박스 테스팅 , 그리고 한 사람이 읽는 코드 비교 각 기법마다 장단점을 가지고 있었지만 효과는

같았다


모듈 테스팅 기법들의 비교 주요 실험은 Basili 와 Selbi 가 수행

블랙 -박스 테스팅 , 글래스 -박스 테스팅 , 그리고 한 사람의 코드 읽기였다

분수의 인수 (fractional factorial) 설계는 프로덕트가 다른 참여자들이 다른 방법으로 테스트되었다는 사실을 보완하는데 사용

비 참여자도 동일한 프로덕트를 한 가지 이상의 방법으로 테스트

코드 감사가 적어도 글래스 -박스와 블랙 -박스 테스팅과 같이 결함 발견에는 적어도 성공적임을 알 수가 있다

이 결론을 잘 사용해서 만든 개발 기법이 클린룸 (Cleanroom) 소프트웨어 개발 기법


13.11 Cleanroom

Cleanroom 기법 점진적 생명주기 모델 , 명세와 설계에 관한 정형 기법 ,

그리고 코드 읽기 등과 같은 비실행 - 기반 모듈 테스팅 기법 , 코드 워크스루와 감사와 같은 많은 소프트웨어 개발 기법들의 조합체

모듈은 비실행 - 기반 테스팅이 성공적으로 달성된 후에만 컴파일

결함 카운팅은 실행 - 기반 테스팅을 통해서 계속 진행 Cleanroom 이 사용될 때 감사시에 발견된 결함과 컴파일

이전에 있는 다른 비실행 - 기반 테스팅 프로시저는 확실히 기록

테스팅 결함율로는 카운트 되지 않음


13.12 객체를 테스팅할 때 잠재적 문제점

클래스에서 실행 - 기반 테스팅을 수행하는 것은 불가능

감사와 같은 비실행 - 기반 테스팅만 수행 정보은닉과 많은 메소드가 테스팅에서 큰 영향력

미침 상속된 메소드 테스트 필요 복잡성이 객체지향 파라다임을 포기할 만한 이유가

아니다라는 것은 즉시 지적 첫째 단지 메소드들 (displayNodeContents 와 PrintRoutin

e) 의 상호작용을 통해 발생 둘째 재테스팅이 필요할 때 결정 가능


13.13 모듈 테스팅의 관리 측면 모든 모듈의 개발시 결정할 주요 사항

해당 모듈 테스팅에 얼마나 많은 시간이 걸리는지 , 경비는 얼마나 드는지를 결정

비용 - 이익 분석은 유용한 역할 담당 신뢰성 분석 (reliability analysis) 기법

아직도 얼마나 많은 결함이 남아있는지를 통계적인 평가로 제공하기 위해 사용


13.14 모듈의 디버깅보다 재작성할 시기

모듈에 있는 결함의 분포는 확실히 균일하지 않다

Documents

제목dasan.sejong.ac.kr/~smchoi/se_13.ppt · PPT file · Web view · 2007-11-23구현 단계 Overview Choice of programming language Fourth generation languages Good programming