Computers/SW Engineering

day 3. 전통적 S/W 개발방법 - 요구사항 분석, 자동화 도구, 설계

emzei 2016. 3. 21. 02:09
  • 전통적(고전적) 소프트웨어 개발방법
    • (= 구조적 소프트웨어 개발방법)
    • 과거의 개발 경험을 토대로하여 제안한 것


  • 요구사항 분석
    • 특징
      • 소프트웨어 개발의 실제 첫 단계
      • 개발 대상에 대한 사용자의 요구사항 이해 및 문서화
    • 분석 작업 단계
      • 문제 인식 : 사용자와 회의, 설문조사, 각종 문서 검토 등을 통해 요구사항 파악
      • 평가와 종합 : 요구사항에 대한 정보 평가 및 해결책 종합
      • 모델 제작
      • 문서화 및 검토 : 요구사항 분석 명세서 작성
    • 요구사항 분석의 한계
      • 대화 장벽
        • 사용자와 개발자 간의 의사소통 어려움
        • 솔루션 : 다이어그램, 프로토타입
      • 시스템 복잡도
        • 소프트웨어 체계화에 따른 새로운 개념 요구
        • 시스템 규모와 대상이 광범위해짐에 따른 소프트웨어 복잡화
        • 솔루션 : 구조적 분석, 객체지향 분석
      • 요구 변경
      • 요구 명세화
    • 요구사항 분석가의 자질
      • 요구사항 분석가 : 요구사항을 효율적으로 분석하고 정확한 명세화 제공

  • 구조적 분석 기법
    • 자료의 흐름과 처리를 중심으로 하는 요구사항 분석 방법
    • 특징
      • 도형 기반 분석용 도구와 분석 절차 이용하여 사용자의 요구사항 파악 및 문서화
      • 도형을 이용하므로 사용자와의 대화 용이
      • 하향식 방법을 이용한 시스템 세분화 (분석의 중복 피할 수 있음)
      • 요구사항이 논리적으로 표현됨 --> 시스템을 일관성 있게 이해할 수 있음
      • 분석의 질 향상. 개발 전 단계에서 필요한 명세 작성 용이
    • 모델링에 사용되는 도구들 (구조적 분석 도구)
      • 자료 흐름도(DFD, data flow diagram)
        • (= 자료흐름 그래프, 버블 차트)
        • 특징
          • 요구사항 분석에서 사용
          • 자료의 흐름 및 변환 과정과 기능을 도형 중심으로 기술
          • 자료 흐름과 기능을 자세히 표현하기 위하여 단계적으로 세분화
          • 자료는 처리(process)를 거쳐 변환될 때마다 새로운 이름 부여, 처리(process)는 입력 자료가 발생하면 기능 수행 후 출력 자료 산출
        • 자료 흐름도의 세분화(상세화)
          • 요구 사항 분석이 진행됨에 따라 하나의 자료 흐름도를 보다 자세히 표현하기 위해 다른 자료 흐름도를 생성하는 것
          • 세분화 단계가 많아질수록 소프트웨어 설계와 구현이 용이
          • 단계(레벨) 0의 자료 흐름도 --> 기본 시스템 모델 (배경도)
          • 예) 단계 N 이 이름짓기라면 n+1 단계에는 이름짓기를 세분화하여 성 고르기, 이름 고르기 이런 식으로...
        • 자료 흐름도 구성요소 표기법
          • 프로세스(process)
            • 처리 과정을 나타냄.
            • = 처리/기능/변환/버블
            • 원 또는 둥근 사각형으로 표시
          • 자료 흐름(flow)
            • 자료의 이동(흐름) 표시
            • 화살표 이로 자료 이름 기입
          • 자료 저장소(data store)
            • 시스템의 자료(파일, 데이터베이스) 표시
          • 단말(terminator)
            • 시스템과 교신하는 외부 개체
            • 입력 데이터가 만들어지고 출력 데이터를 받음
      • 자료사전 (DD, Data dictionary)
        • = 데이터의 데이터, 메타데이터
        • 흐름도에 있는 자료를 더 자세히 정의하고 기록한 것. 데이터를 설명하는 데이터. 
        • 자료사전에 사용하는 기호
          • = : 자료의 정의.
          • + : 자료의 연결 (그리고)
          • ( ) : 자료의 생략(옵션)
          • [ | ] : 자료의 선택
          • { } : 자료의 반복
          • * * : 자료의 주석
      • 소단위 명세서(Mini spec)
        • 세분화된 자료 흐름도에서 최하위 단계의 프로세스(버블)의 처리 절차를 기술
        • = 프로세스 명세서
        • 분석가의 문서. DFD 지원하기위한 문서
        • 구조적언어, 의사 결정표(판단표, decision table) 이용
      • 개체관계도 (ERD, Entitiy relationship diagram)
        • 개체 관계도 기호
          • 개체 - 사각형, 속성 - 타원, 관계 - 다이아몬드
        • 작성 순서
          • 주요키를 포함한 개체 속성 파악
          • 기본 개체와 주요키 정의 및 개체 사이의 관계 파악
          • 1:M 관계를 단순화하기위해 속성 개체 추가, 연관 관계 정의하여 M:N 관계로 표현
          • 각 개체를 정규화, 누락된 개체 점검 및 클래스 구조 필요성 파악
      • 상태전이도 (STD, State Transition Diagram)
        • 시스템에 어떤 일이 발생할 경우, 시스템의 상태와 상태 간의 전이를 모델화 한 것
        • 상태전이도를 통하여 개발자는 시스템의 행위를 정의할 수 있음
      • 제어명세서 등...


  • CASE (자동화 도구)
    • 요구사항을 자동으로 분석하고, 요구사항 분석 명세서를 기술하도록 개발된 도구
    • 장점
      • 표준화
      • 보고를 통한 문서화 품질 개선
      • DB를 모두가 이용할 수 있기에 분석자들 간 적절한 조정 가능
      • 교차 참조도와 보고서를 통한 결함, 생략, 불일치 발견 용이
    • 종류
      • SADT (Structured Analysis and Design Technique)
        • softtech사에서 개발. 구조적 분석 및 설계 도구
        • 구조적 요구 분석을 위한 블록 다이어그램 사용 
      • SREM (Software Requirements Engineering Methodology)
        • trw사가 실시간 처리 소프트웨어 시스템에서 요구사항을 명확하게 하기위해 개발
        • RSL 및 REVS 이용
          • RSL (Requirement Statement Language) : 요구사항 기술 언어
          • REVS(Requirement Engineering and Validation System) : RSL로 작성된 요구사항을 자동으로 분석하여 분석 명세서 출력
      • PSL(Problem Statement Language) /PSA(Program Statement Analyzer)
        • 미시건 대학에서 개발
        • PSL : 문제(요구사항) 기술 언어
        • PSA : PSL 로 작성된 요구사항 자동 분석
      • TAGS (Technology for Automated Generation of Systems)
        • 시스템 공학 방법 응용에 대한 자동 접근법
        • 개발 주기 전과정에서 이용 할 수 있음 (통합 자동화 도구)
        • IORL : 요구사항 명세 언어

  • HIPO(hierarchy input process output)
    • 시스템 분석 및 설계, 문서화 시 사용되는 기법
    • 특징
      • 시스템 실행 과정 (입력/처리/출력) 기능 수행
      • 하향식 소프트웨어 개발을 위한 문서화 도구
      • 체계적 문서관리
      • 기호, 도표를 이용 --> 이해하기 쉬움
      • 기능과 자료의 의존관계 표현 가능
      • 변경, 유지보수 용이
    • 종류
      • 가시적 도표 (도식 목차)
        • 전체적 기능 및 흐름 파악 --> 트리(계층) 구조
      • 총체적 도표 (총괄 도표, 개요 도표)
        • 기능(입출력, 처리)에 대한 전반적 정보 제공
      • 세부적 도표 (상세 도표)
        • 총체적 도표에 표현된 기능을 구성하는 기본요소를 상세하게 서술



  • 설계
    • 구조적 설계 기법 (전통적!)
      • 자료의 흐름을 중심으로 설계 (= 자료 흐름 중심 설계 기법)
      • 자료 흐름도, 자료사전, 개체관계도, 소단위 명세서 등이 준비된 이후에 설계
    • 개요
      • 요구사항 분석 명세서의 기능이 실현되도록 알고리즘가 해당 자료구조를 문서화하는 것
      • 좋은 소프트웨어 개발을 위한 핵심 기술. 품질 평가를 위한 지침이 됨
    • 소프트웨어 설계 모형 (기술적 관점)
      • 데이터 설계 - 요구사항을 바탕으로 하여 필요한 자료 구조 설계
      • 구조설계 - 모듈 간 관계 및 프로그램 구조 정의
        • *구조적 설계.
        • 정보 흐름의 유형 >> 흐름의 경계 표시 >> 흐름도를 이용하여 프로그램 구조도 작성 >> 제어계층을 분해하여 정의 >> 경험적 방법을 통한 구체화
      • 인터페이스 설계
      • 절차 설계 - 모듈이 수행할 기능을 절차적 기술로 변환
        • 그래픽 설계 표기
          • 흐름도 (flowchart) : 순차,선택,반복 으로 구성
          • N-S 차트 : 순차, 선택, 반복 + 선택 + 다중 
        • 프로그램 설계 언어 (PDL)
      • cf. 사용자적 관점 : 내부설계 vs. 외부 설계
      • cf. 관리적 관점 : 기본설계 vs. 상세 설계
    • 설계의 기본 원리
      • 모듈화 (Modularity)
      • 추상화 (Abstraction, 개념화)
        • 기능 추상화
        • 제어 추상화
        • 자료 추상화
      • 단계적 정제 (Stepwise Refinement)
      • 정보은닉 (Information Hiding)
      • 프로그램 구조 (Program Structure, 제어 계층 구조)
        • 모듈의 계층적 구조를 나타냄.  (트리구조)
        • 용어
          • 공유도 (fan-in, 팬-입력) : 어떤 모듈을 제어(호출)하는 모듈의 수
          • 제어도 (fan-out, 팬-출력) : 어떤 모듈을 제어(호출)하는 모듈의 수
          • 깊이(depth), 넓이(width), 주종적모듈, 종속적모듈
      • 자료 구조
    • 바람직한 설계의 특징 ( 소프트웨어 설계의 지침, 좋은 설계의 기준)
      • --> 모듈단위로 구성하는 것!
      • 소프트웨어 구조를 나타냄
      • 요소(모듈) 간의 효과적인 제어를 위해 계층적 자료 조직이 제시되어야 함
      • 자료아 프로시저 간의 분리된 표현 필요
      • 적당한 모듈크기, 모듈관의 상관성(결합도)낮추기, 응집도 높이기
      • 포괄적 개념 설계 후 세부 개념 구체화

  • 모듈화
    • 소프트웨어를 각 기능별로 분할
    • 소프트웨어의 복잡도 감소

  • 모듈의 속성
    • 입출력 요소/ 기능 요소/ 기관요소/ 내부자료 요소
    • 구성 - 호출, 피호출 모듈

  • 모듈의 기능적 독립성
    • 모듈의 기능이 독립 <-- 모듈화, 추상화, 정보은닉의 결과물
    • 독립성 측정은 결합도(coupling)과 응집도(cohension) 바탕으로 이루어짐
    • 높은 독립성 --> 낮은 결합도, 높은 응집도, 작은 크기의 모듈

    • 결합도(coupling)
      • 모듈 간의 상호 의존 정도, 혹은 연관 관게
      • 결합도가 강하면 구현 및 유지보수가 어려움.
      • 결합도 종류 (강함 ---> 낮은 순서)
        • 내용 결합도 (아주강함)
          • 한 모듈이 다른 모듈의 내부 기능 및 자료를 직접 참고
          • 참고) 한 모듈에서 다른 모듈의 중간 지점으로 분기되는 경우에도 해당
        • 공통 결합도
          • 공유되는 공통데이터 영역을 여러 모듈이 사용할 때
          • 공통 데이터가 변경되면 모든 모듈에 영향을 미침. 모듈의 독립성 저하
        • 외부 결합도
          • 모듈에서 외부로 선언한 변수를 다른 모듈에서 참조할 때
          • 참조되는 데이터의 범위는 각 모듈에서 제한할 수 있음
        • 제어 결합도
          • 한 모듈에서 다른 모듈로 논리적 흐름을 제어하는 데 사용하는 제어 요소가 전달될 때
          • 함수, 스위치, 태그, 플래그 등
          • 상위 모듈에서 하위 모듈에 대한 이해가 필요. 기능이 두 모듈로 분리된 경우
        • 스탬프 결합도
          • 모듈 간 인터페이스로 자료구조(배열 등)가 전달될 때
          • 두 모듈이 동일한 자료구조 조회. 자료구조의 변화가 다른 모듈에 영향 미침 (call by reference 느낌 ?)
        • 자료 결합도 (아주 약함)
          • 인터페이스가 자료 요소로만 구성
          • 다른 모듈 호출 시 매개 변수 넘겨주고 결과값 돌려받음 (call by value 느낌 ?)
          • 모듈 간의 내용을 전혀 알 필요 없는 상태. 모듈 변경이 다른 모듈에 영향 없음



      • 응집도 (cohesion)
        • 정보 은닉 개념의 확장
        • 모듈 안의 요소들의 관련 정도. 모듈이 얼마나 독립적인 기능을 갖고 있는 지
        • 응집도가 강하다 --> 모듈의 독립성이 높다
        • 응집도 종류 (강함 --> 약함)
          • 기능적 응집도 (매우 강함)
            • 모듈 내 기능 요소가 단일 문제와 연관
          • 순차적 응집도
            • 모듈 내 하나의 처리로 나온 결과가 그 다음 처리 순서의 입력 데이터로 사용
          • 교환(통신)적 응집도
            • 동일한 입출력을 사용하여 서로 다른 기능을 수행하는 구성 요소가 모임
          • 절차적 응집도
            • 하나의 모듈이 다수의 관련 기능을 가질 때, 모듈 안의 구성 요소들이 기능을 순차적으로 수행할 경우
          • 시간적 응집도
            • 특정 시간에 처리되는 몇개의 기능을 모아 하나의 모듈로 작성
          • 논리적 응집도
            • 유사한 성격을 갖거나 특정 형태로 분류되는 요소들로 하나의 모듈 형성
          • 우연적 응집도 (매우 약함)
            • 모듈 내 요소가 관련이 없는 것들로 구성

      • 효과적인 모듈화
        • 낮은 결합도, 높은 응집도!
        • 제어 영역 안에서 영향 영역 유지