참고 서적 : C로쓴 자료구조론
참고 사항 : my think
모든 프로그램들은 시스템 생명 주기라 불리우는 개발 단계를 거친다.
이러한 주기는 요구사항,분석,설계,코딩,검증 과정으로 구성되어 있다.
이러한 과정이 독립적이라고 간주한다 할지라도 이 과정들은 상호 밀접한 관계를 가지고 있다.
1) 요구사항 ( 고객 미팅 )
프로그래머에게 주어진 데이터 입력과 프로그래머가 생성해내야 하는 결과(출력)에 관한 정보를 기술한다.
종종 이 초기 명세가 애매모호하게 정의되어 있는데 요구사항은 모든 경우에 대한 입력과 출력의 기술을
명확하고 정밀하게 작성하여야 한다.
2) 분석 ( 요구 분석 )
요구사항 단계가 끝나면 분석 단계가 시작된다.
분석 단계에서는 각각의 문제(요구사항)들을 실제 다룰 수 있을 정도의 작은 단위들로 나눈다.
분석 단계는 상향식(bottom-up)과 하향식(top-down)접근방법으로 나눌수 있는데, 각각의 설명은 다음과 같다.
.상향식(bottom-up) :
오래전에 제안된 방법으로 코딩에 주안점을 둔 비구조적방법이다.
일반적인 청사진을 토대로 마치 건물을 축조하는 것과 같다. 즉 모든 빌딩은 동일하다는 가정하에
건물은 별돌과 지붕,배관,난방시설 등을 갖추고 있다라는 전제로 전체에서 부분들로 코딩해 나가는 방식이다.
하디만 실제 축조된 빌딩의 목적은 이러한 관점과 무관하다. 많은 프로그래머들, 특히 초보자들은 이렇게
사전 계획없이도 완벽하고 오류없는 프로그램을 만들 수 있다고 믿는다.
.하향식(top-down)
최종 결과 프로그램을 우리가 다룰 수 있을 정도의 프로그램 단위로 분리한다는 의도로부터 시작되었다.
이러한 기술은 시스템을 설계하는 데 사용되는 다이어그램을 생성한다.
이 단계에서는 여러가지 프로그래밍 문제를 발견할 수 있으며 동시에 여러 가지 해결책들이 만들어지고
비교 분석하게 된다.
3) 설계 ( 기본 설계 )
설계 단계는 분석 단계에서 완료된 작업들을 계속한다.
설계자는 프로그램이 필요로 하는 테이터 객체들과 이들 위에서 수행될 연산들의 관점에서 시스템에 접근한다.
( 설계자는 각각의 데이터와 기능들과의 상호관계를 베이스로 시스템을 구체화 한다?)
( 일반적으로 현업에서 기능리스트와 각각의 기능에서 취급할 데이터를 구체화 해서 문서화 한다 : 기본설계 일부)
그 첫번째 관점은 추상 데이터 타입(abstract data type)으로 되지만, 두번째 관점은 알고리즘의 명세와 그 알고리즘
설계 기법의 고려를 요구한다. 예를 들어, 우리가 대학의 일정 시스템을 설계한다고 가정하자.
일반적인 데이터 객체로는 학생,과목이 포함되고 일반적인 연산들로는(기능들로는) 각각의 객체나 객체들간에
삽입(추가/등록),삭제,수정,검색이 포함된다. 즉, 대학 강의과목 리스트에 새로운 과목을 추가하거나 어떤 교수가
담당하는 과목이 무엇인지를 검색하기를 원하기 때문이다.
설계 단계에서는 프로그램 개발 언어등 구현을 위한 결정 사항들은 뒤로 연기해 둔다.
각각의 데이터 객체가 요구하는 정보(엔티티 정의)를 명확하게 기술하여야 하는 것은 당연하지만
실제 코딩에 필요한 세부 사항들은 무시한다.
예를 들어, 학생 데이터 객체에는 이름,주민등록번호,전공, 전화번호 등이 설계 단계에서 결정될 수 있다.
그러나 학생 리스트 구현에 대한 구체적인 방법은 결정하지 않는다. 구현에 배열을 사용할지
링크 리스트 혹은 트리를 사용할지에 대한 협의 및 검토는 이 단계에선 무시한다.
구현에 관한 사항을 가능한 한 뒤로 미루는 이유는 여러 가지 언어로 구현할 수 있게 시스템을 생성할 수 있을
뿐만 아니라 선택한 언어의 범주내에서 가장 효과적인 구현을 택할 수 있기 때문이다.
4) 정제와 코딩 ( 상세 설계 )
이 단계에서는 데이터 객체에 대한 표현을 선택하고 그들 위에 수행되는 연산에 대한 알고리즘을 작성한다.
( 각각의 데이터 타입과 크기등을 명확하게 기술하고 각각의 데이터와 상호작용하는 기능에 대한 구체적인
알고리즘을 기술한다.? )
이 시점에서 종종 우리는 보다 나은 시스템을 생성할 수 있었다는 것을 실감하게된다.
유사한 프로젝트를 수행했던 친구와 이야기를 나눈 적이 있다거나, 또는 다른 여러 설계들 중에 어느하나가
더 우수하다는 것을 알았을 경우 등이다.
만약 우리의 처음 설계가 훌륭하다면 그 설계는 이러한 변화들을 쉽게 수용할 수 있다.
만일 전체 작업에 대한 내용을 정리해 두었다면 좀더 빠르고 좀더 오류없이 새로운 시스템을 기술하기가 업려지 않을
것이다.
( 즉 잘 작성한 설계서가 있다면 더 좋은 방법으로 설계 수정이 용이하고 이러한 설계서가 많이 존재한다면
새로운 시스템을 재 설계할때 좀더 빠르고 좀더 오류없이 설계가 가능하다? )
5) 검증 ( 테스트 )
프로그램의 정확성 증명, 다양한 입력 데이터를 이용한 프로그램의 테스트 그리고 오류 검출 및 제거로 구성된다.
.정확성 증명
보통 수학에서 사용하는 기법들을 이용해서 정확성을 증명하는데 이러한 증명은 상당히 많은 시간을 필요로 한다.
그렇기 때문에 대형 프로젝트에서 이러한 수학적 증명을 실시하기엔 매우 무리가 있고 시간적 제약 ( 납입 스케쥴)
으로 인해 완벽한 증명을 하지 못할 리스크가 크다. 하지만 미리 (이미,예전에,과거에,어느 천재가) 누군가가 정확
성을 증명한 알고리즘을 선택하여 사용한다면 오류의 발생수를 줄일 수 있다.
(자료구조에는 이미 증명된 여러가지 알고리즘을 제공한다. 즉! 중요하다.
황금같은 주말에 다시 자료구조를 정리하는 이유중에 하나이다.ㅎㅎㅎ)
참고 :
알고리즘은 프로그램 언어로 기술(코딩)하는 것이 아니기 때문에 ( 그럴 필요가 없기 때문에 ) 우리는 코딩 단계혹은 그 이전 단계에서도 정확한 증명을 할 수 있다..
.테스트
실제 데이터와 실제 코드를 이용하여 문제가 없는지 테스트를 하는데,
데이터는 모든 가능한 경우들이 포함되도록 신중히 만든다.
( 예로 숫자만 입력이 가능할 경우 숫자와 특수문자등 모든 입력값을 이용해 정말 숫자만 입력가능하도록 되어
는지 확인 )
종종 초보 프로그래머들은 구문 오류없이 수행되는 프로그램을 정확하다고 간주한다. 그리고는 입력 데이터에
대해 별로 개의치 않고 한 가지 데이터만을 테스트에 사용하곤 한다.
훌륭한 테스트 데이터는 모든 프로그램 단위들이 정확히 수행되는가를 검증할 수 있어야 한다.
초기 시스템 테스트는 프로그램이 정확히 수행되는가를 검증하는데만 초점을 맞춘다.
이러한 테스트가 매우 중요하긴 하지만 프로그램의 실행 시간 역시 매우(아주) 중요하다.
오류가 없는 프로그램이더라도 매우 느리게 실행된다면 ( 사용 못하는 프로그램 ) 별반 다를게 없다.(가치하락)
참고 :
알고리즘에 대해 실행 시간의 이론적 추산벙법들을 이용해서 부분적 코드 성능을 추산하여 집계를 하도록 한다.
.오류제거
정확성 증명과 테스트에서 오류가 발생된 코드가 검출되면 이 단계에서 수정및 제거를 실시한다.
문제는 이 단계는 실제 설계와 코딩의 영향을 상당히 많이 받는데 예로 설명문이 전혀 들어 있지 않은
스파게티 코드로 쓰여진 ( 주석이 없거나 혹은 설계서가 없고 있다해도 요구조건 변경후 설계서
갱신이 제대로 반영되어 있지 않는 경우등 ) 프로그램의 오류를 수정할 때면 가끔 정정된(수정된)오류가
또다른 새로운 오류들을 만들수도 있다.
반면 설명이 잘 기술되어 있고 매개 변수를 통해 독립적인 단위로 구성된 프로그램들은 그 수정작업이 휠씬 쉽게 된다. 특히 이런 프로그램 단위들을 별도로 테스트하고(유닛 테스트 및 단계 테스트 )난 뒤에 전체 시스템으로
통합한다면(통합 테스트/시나리오 테스트) 매우 효과적이다.
( 전역 변수 사용 줄임 / 각각의 객체의 독립화( 객체 설계 ) / 디자인 패턴 적용 / 팩토리 실시등으로 예방 )
모든 개발 과정을 실시한다면 시스템의 안정성과 효율성 그리고 유지보수의 효율이 높아지겠지만,
모든 시스템 개발엔 예산과 시간이 ㅡㅡ 목을 조른다..콜록! 콜록! 콜록! 밤샘!!?? ㅠㅠㅎ