소프트웨어공학 - 1.소프트웨어 공학의 개요, 2. 객체지향 개념, 3.요구분석

01. 소프트웨어공학

• 정의 : 고객의 문제를 해결하기 위해 고품질 소프트웨어를 정해진 자원으로 개발하거나 발전시키는 체계적인 프로세스
• 고객의 문제 해결 
• 체계적인 개발과 발전
  • 잘 이해하고 있는 기술을 조직된 원리와 방법으로 적용하는 과정
  • 표준으로 받아들여진 기술 - ISO, IEEE, KS
  • 대부분은 발전적(evolution) 개발
• 대규모 고품질 S/W 시스템
  • 홀로 완성시킬 수 없기 때문에 엔지니어링 기술 필요
  • 팀워크와 협동이 필요
  • 작업의 분할과 시스템의 각 부분이 잘 작동하느냐가 관건
  • 최종 제품은 충분히 좋은 품질을 가지고 있어야
• 비용, 시간, 기타 제약
  • 한정된 자원
  • 얻는 이득이 비용을 초과하여야
  • 더 빠르고 싸게 개발하도록 다른 기업과 경쟁
  • 비용과 시간의 부정확한 예측으로 대부분의 프로젝트가 실패로 끝남
•  IEEE
  • 소프트웨어의 개발, 운용, 유지보수 및 파기에 대한 체계적인 접근 방법
• W. Humphery
  • 질 좋은 소프트웨어를 경제적으로 생산하기 위하여 공학, 과학, 수학적 원리에 의하여 소프트웨어를 개발
• 목표
  • 품질 좋은 소프트웨어를 최소의 비용으로 계획된 일정에 맞추어 개발하는 것
• 시스템 공학 : 다른 요소에 탑재될 목적으로 만드는 S/W시스템 
• 시스템 공학의 절차(요설개통설유)

• 시스템 공학 관련자(사고개관)
  • 사용자 : 소프트웨어를 사용하는 사람들
  • 고객 : 소프트웨어에 대하여 비용을 지불하는 사람
  • 소프트웨어 개발자 : 요구분석가, 데이터베이스 전문가, 기술문서 작성자, 프로그래머, 테스트 엔지니어, QA엔지니어
  • 개발 관리자 : 프로젝트 관리, 비지니스 경영

 

02. 소프트웨어 품질 (신유재사효 품질이 좋습니다)

• 사용용이성(usability) : 빨리 배우고 작업을 쉽게 하는 성질
  • 사용용이성을 높이면 효율성이 낮아질 수 있음
• 효율성(efficiency) : cpu시간과 메모리 같은 자원을 낭비하지 않음
  • 효율성 증진시키면 유지보수성이나 재사용성은 감소될 수 있음
• 신뢰성(reliability) : 요구한 기능을 실패 없이 할 수 있는 성질
• 유지보수성(maintainability) : 쉽게 변경할 수 있음
• 재사용성(reusability) : 부품이 다른 프로젝트에서 사용될 수 있는 성질
• 내부품질요소
  • 설계의 특징을 좌우
  • 외부 품질 특성에 영향을 줌
    • 예 : 원시코드에 있는 주석의 분량, 원시코드의 복잡성
• 단기적 품질 
  • 고객의 당장의 요구를 만족하고 있는가?
  • 현재 처리할 자료의 분량을 효율적으로 소화할 수 있는가?
• 장기적 품질
  • 유지보수성, 고객의 미래요구 

03. 소프트웨어 프로젝트 작업

• 요구분석과 명세화(도문추분명)
  • 도메인 분석
  • 문제의 정의
  • 요구 추출
    • 가능하면 많은 소스에서 입력을 취함
  • 요구 분석
    • 정보를 잘 정리하고 구성
  • 요구 명세화
    • 소프트웨어가 어떻게 작동하는지에 대한 자세한 명령을 작성
• 설계 : 요구가 가용 기술로 어떻게 구현되어야 하는지를 기술
  • 중요기술(설계는 데시사소서 -> 데지사소서로 외우자)
    • 시스템 엔지니어링 : 어떤 부분이 하드웨어, 시스템웨어가 되어야 하는지 결정
    • 소프트웨어 구조 : 시스템을 서브시스템으로 분할하고 서브시스템이 어떻게 작동하는지 결정
    • 서브시스템의 내부에 대한 상세 설계
    • 사용자 인터페이스 설계
    • 데이터베이스 설계
• 모델링 : 도메인이나 소프트웨어의 표현을 만들어 나가는 과정(모델링은 사정동에 산다)
  • 사용 사례 모델링
  • 정적 모델링
  • 동적 모델링
• 프로그래밍
• 품질 보증
  • 리뷰, 인스펙션
  • 테스트
• 설치
• 프로젝트 관리
• ISO 12207 - 프로세스 표준

04. 객체지향 방법론

• 객체 사이의 상호 작용을 중시
• 객체지향 모델링과 설계 언어(객유유)
  • 유즈케이스 모델링
  • UML(Unified Modeling Language)
• 객체지향 개발 프로세스
  • 반복, 점증적
  • 잦은 변경과 빠른 기술 발전
• 객체지향 방법론
  • 각 단계 작업 방법

 

 

---

01. 객체지향이란?

• 절차적 패러다임 
  • 소프트웨어가 프로시저 단위로 구성됨
    • 명령의 순차적 실행
  • 프로시저 추상 
    • 단순한 데이터에는 적합하나 복잡한 데이터를 가진 응용문제에는 부적합
  • 데이터 추상
    • 특정한 의미를 이루는 데이터 조각들의 집합
    • 시스템의 복잡도를 줄이는데 도움 ex) 레코드, 구조체 
  • C, BASIC
• 객체지향 패러다임
  • 프로시저 추상을 데이터 추상 관점으로 구성
  • 객체란 상태를 의미하는 기억장소와 상태를 변경할 수 있는 연산의 집합
  • 객체는 클래스로 그룹화
  • 클래스의 인스턴스 : 선언된 객체의 실제 예
  • C++, Java, c#

 

추상화(abstraction)의 개념

• 주어진 작업이나 객체를 속성들의 일부분을 가지고 필요한 만큼 묘사할 수 있는 방법을 지원하는 것
• 필수적인 속성만으로 주어진 것을 묘사하므로 나머지 속성들은 추상화, 은닉, 또는 삭제됨

 

추상화의 범주(자제)

• 자료추상화  : 문자열, 수, 트리와 같은 계산 될 자료의 특성을 추상화
• 제어추상화(알고리즘추상화) : 실행 순서를 제어하는 특성을 추상화, 반복문조건문프로시저 호출 등

 

추상화 종류(기구단을외자 기구단을외자, 기추변배 구추 배선반, 단추 객체)

• 기본추상화 : 가장 지역적인 기계정보에 대한 추상화
  • 자료 : 변수
  • 제어 : 배정문
• 구조추상화 : 보다 전역적인 정보인 프로그램의 구조에 대한 추상화 
  • 자료 : 배열, 구조체
  • 제어 : 선택문(if문), 반복문(while문, for문)
• 단위추상화 : 단위 프로그램 전체에 대한 정보의 추상화
  • 객체

 

객체지향 패러다임

• 문제를 해결하기 위한 모든 계산이 객체(object)라는 것을 기본으로 수행되는 방법
• 객체는 클래스의 인스턴스. 클래스는 자료가 추상화된 것이며, 동시에 객체를 조작하는 프로시저에 대한 추상
• 실행 프로그램은 특정 작업을 수행하기 위하여 모인 객체의 집합

 

---

요구 추출

• 요구 : 제안된 시스템이 무엇을 하는가를 나타낸 문장
  • 짧고 간결한 정보
  • 시스템이 무엇을 하는가를 나타냄
  • 관련자 모두가 동의한 것
  • 고객의 문제를 적절히 해결한 것
  • 요구를 모아 놓은 것 -> 요구분석서

 

요구의 유형

• 기능적 요구: 시스템이 무엇을 하여야 하는지를 기술한 것
  • ex) 현금 인출, 잔금 조회, 계좌 이체, 현금서비스 등의 외형적 기능
• 비기능적 요구 : 개발 과정에 고수하여 할 제약 조건
  • ex) 하드웨어 자원의 제약, 소프트웨어 품질 특성에 대한 수준

 

요구 추출 방법(x)

• 요구를 효과적으로 추출하고 분석하는 체계화된 기술
  • 관찰
    • 작업 방법 : 사용자의 업무를 관찰하며 메모
    • 특 징 : 감추어진 문제를 잘 드러냄
  • 인터뷰
    • 작업 방법 : 여러 관련 당사자를 만나 준비된 질문과 대답
    • 특 징 : 정확한 요구추출, 요구에 대한 오해를 줄일 수 있음
  • 브레인스토밍
    • 작업방법 : 여러 사람이 모인 그룹에서 아이디어를 쏟아 놓는다
    • 특징 : 효과적인 정보 추출
    • JAD - 집중 브레인스토밍 세션
  • 프로토타이핑
    • 작업방법 : 시범적으로 시스템을 구현
    • 특징 : 요구에 대한 빠른 피드백
  • 사용사례 분석 : 개발한 소프트웨어를 가지고 사용자가 무엇을 할 수 있는지를 분석
    • 작업방법 : 시스템 외부 기능 파악
    • 특징 : 체계적 요구 구성
    • 액터찾기 : 서비스받는사용자, 연결된외부시스템, 시스템과 관련된 외부 요소
    • 사용 사례 
      • 일반적으로 사용사례는 작업의 시작부터 끝까지 전 단계를 커버
      • 사용자가 시스템과의 상호작용을 나타냄
      • 특정 사용자 인터페이스 설계와 독립적으로 작성
      • 액터가 컴퓨터와 상호작용 하는 액션만을 포함

 

사용 사례 다이어그램

• 사용 사례 :  사용자가 주어진 작업을 완료하기 위하여 수행할 일련의 액션이나 이벤트
• 사용 사례를 분석하는 목적은 시스템을 모델링 하는 것
  • 특정 목적을 달성하려고 할때
  • 사용자가 시스템과 어떻게 상호작용 하는지에 대한 관점으로
• 사용사례 모델은
  • 사용 사례 집합과 사용사례에 대한 설명, 사용사례 사이의 관계로 구성

확장 (Extend)

• 선택적인 인터랙션을 명시적으로 나타날 때 또는 예외적인 사례를 다룰 때 사용
• 사용사례 확장을 분리함으로써 기본적인 사용사례의 표현이 간단해 진다
• 사용사례 확장도 사용사례의 처음부터 끝까지 모든 단계를 나열하여야 함
  • 특수한 경우의 처리도 포함

일반화(generalization) 

• 속이 빈 화살표 
• 클래스 다이어그램에서 슈퍼클래스와 유사
• 일반화된 사용사례는 여러 유사 사용사례를 표현
• 상세화 된 여러 사용사례가 유사 사용사례의 상세한 내용을 제공

 

포함(include)

• 하나의 유스케이스가 다른 유스케이스의 실행을 전제로 할때 형성
• 여러 사용사례들 사이에 공통적인 부분을 표현
• 다른 사용사례들 안에
  • 일련의 액션을 공유
  • 다수의 사용사례 사이에 중복을 피함
• 하위 수준의 작업의 수행을 하위 수준의 목표로 표현

 

사용사례 다이어그램 예

 

사용사례의 장점

• 시스템의 범위를 정하는데 도움이 됨
• 개발 과정을 계획하는데도 사용됨
• 요구를 개발하고 검증하는데 사용 됨
• 테스트케이스를 정의하는데 기초가 됨
• 사용자 매뉴얼 구성하는데 사용될 수 있음

 

요구 검토

• 각 요구 사항이 다음을 만족하였는지
  • 개발 비용을 능가하는 이익이 있는지
  • 현재 당면한 문제가 해결되었는지
  • 명확하고 일관성 있는 표현이 되었는지
  • 모호한 점이 없는지
  • 논리적으로 일관성이 있는지
  • 시스템의 충분한 품질을 유도하는지
  • 가용 자원으로 실현가능한지
  • 검증 가능한지
  • 식별 가능한지
  • 설계를 과다하게 제한하고 있지 않는지
• 요구문서 : 추적가능성