1강
소프트웨어: 프로그램의 개발, 운용 보수에 필요한 자료의 일체-> 이러한 모든 것이 엔지니어의 작업결과이기 때문
소프트웨어 엔지니어링의 특징
- 타 작업보다 실체를 감지하기가 어렵다
- 품질 평가, 구조파악이 어렵다
- 적은 비용으로 복제 및 대량샹산이 가능하다-> 대부분 비용은 설계와 개발단계에 들어감
- 노동집약적이며, 완전히 자동화하기가 어렵다
- 다양한 설계 기술이 필요하다.
- 완전히 파악하지 못하더라도 쉽게 변경이 가능하다
설계가 취약하면 구조가 악화된다 -> 공학기법의 학습 및 연구가 필요하다
소프트웨어의 유형
-
주문형 소프트워어: 특정 고객의 수요를 위해 개발된 소프트웨어
-
패키지형 소프트웨어: 저렴하고 범용적이며 신뢰도가 높으나, 특정기관의 요구에는 꼭 맞지 않을 수도 있다
-
임베디드 소프트웨어: 하드웨어에 탑재되는 소프트웨어
하드웨어 교체, 또는 업데이트가 필요하다
자료처리방식에 따른 유형
리얼타임 소프트웨어
- 제어, 모니터링 소프트웨어
- 외부의 반응에 신속히 반응한다
- 시간제약을 엄수하여 안정성 확보가 중요하다
자료처리 소프트웨어
- 비지니스 경영에 사용되는 소프트웨어는
정확성 및 보안 중시 - 자료가 발생된 시점이 아닌, 모아서 한번에 처리
(batch program, bat)
※리얼타임과 자료처리 소프트웨어의 성질을 둘다 가진 경우가 있다
소프트웨어 공학의 등장 -> 점점 복잡해 지면서 설계가 중요하게 됨
소프트웨어 공학의 정의
고객의 문제를 해결해주기 위해 품질 높은 대규모 소프트웨어를
정해진 시간과 비용으로 개발, 발전시키는 체계적인 과정(학문)
고객의 문제해결
- 소프트웨어 공학의 궁극적인 목적
- 개발 or 개발된것을 사용하는 것이 효과적인지 판단해야함
- 불필요한 기능이 있는지 확인
- 효과적인 의사소통이 중요하다
체계적인 발전
- 소프트웨어 개발: 엔지니어가 이해하고 있는 기술을 조직된 원리와 방법으로 소프트웨어 개발에 적용하는 과정
- 빠르게 표준화되고 있다
- 유지보수(발전적인 과정)가 주이다-> 소프트웨어를 지속적으로 수정하는 유지보수 과정은 중요한 부분이다
대규모 고품질 소프트웨어 시스템
- 대규모 프로그램은 체계적인 설계, 공학적 원리가 필요하다
- 팀워크는 필수
- 최종개발된 제품은 충분히 좋은 품질을 가져야한다
비용과 시간의 제약
- 가성비 좋은 개발을 해야한다(경제적인 제약)
- 부정확한 예측으로 인해 시간과 비요의 제약을 못지키는 경우가 많다
- 빠르고 정확하게 개발해야 한다( 타기업과 경쟁)
소프트웨어 공학의 목표
품질 좋은 소프트웨어를
최소의 비용으로
계획된 일정에 맞추어 개발한다
시스템 공학
- 타요소에 탑재하기위해 개발된 소프트웨어-> 임베디드 시스템
- 시스템 공학의 절차
시스템 요구 정의-> 시스템 설계->
[하드웨어 개발][기계적 요소 개발] [소프트웨어 개발][인력자원개발] ->
시스템융합 -> 시스템설치 및 유지보수
소프트웨어 품질을 바라보는 관점
- 각 직군에 따라 관점이 다르다 -> 평가 요소가 다름
소프트웨어 품질의 특성
- 사용용이성
- 효율성
- 신뢰성
- 유지보수성
- 재사용성
소프트웨어 프로젝트의 유형
새 시스템의 개발
- 설계를 위한 의사결정이 자유롭다
- 많은 작업과 시간이 소요된다
진화유형
- 유지보수 및 새 기능 추가
- 새 메이저 버전업을 위한 사용자가 원하는 새기능을 대규모로 추가하는
유형 - 내부적인 설계를 바꾸는 리엔지니어링 유형
- 기존 시스템의 이해가 중요하다
컴포넌트 기반
- 컴포넌트(프레임워크 등)을 조립, 혹은 없는 부분을 채워 넣으면 개발
- 요구사항에 맞게 개발
요구사항분석과정
- 도메인 분석
- 문제 정의
- 요구수출
- 요구분석
- 요구 명세화
객체지향 소프트웨어 공학
'시스템이 객체로 구성되고, 관련된 객체간의 상호작용'
- 객체지향 패러다임: 모델링과 언어, 방법론으로 구성
☆최신 소프트웨어 공학의 핵심기술☆
- 추상: 문제의 핵심을 개괄적으로 표현하여 집중하는 것
- 분석과 설계방법
- 사용자 인터페이스 프로토타이핑
- 소프트웨어 구조
- 소프트웨어 프로세스
- 재사용
- 측정: 프로세스, 방법, 자원 등을 향상하려는 노력
측정 -> 통계-> 해석 -> 해법구현
2강
객체지향이란?
프로시서 추상화와 데이터 추상화를 묶어 놓은 것
프러시저 추상화
- 함수의 역활만 알면 됨
- 단순한 데이터에 적합
=관점=
프로그램은 프러시저의 집합으로 구성된다
데이터 추상화
- 특정 의미의 데이터 조각을 모아 그룹화 -> 오퍼레이션 또한 정의
- 시스템의 복잡성을 줄이는 데 도움이 됨
=관점=
의미있는 데이터들을 모아 큰단위로 만들어 정의함
-> 코드조각이 여러 곳에 산재되어 수정이 어려움
객체지향 패러다임
- 주어진 작업의 수행을 위해 협력한 객채들의 모임
-객체들 끼리 메시지를 주고 받으면서 작업한다
클래스와 객체
객체(인스턴스)
- 프로그램이란 객체들의 모임
- 구조화된 상태와 행위의 덩어리들
- 모든 객체는 상태와 행위라는 두 요소를 가지고 있다
상태: 데이터의 성질(제이터, 변수)
행위: 함수. 어떻게 작동하고 반응하는지 나타냄
객체의 행위를 시뮬레이션 할 수 잇음
클래스(데이터, 프로시져에 대한 추상화)
- 속성(객체의 상태의 값), 메소드(객체의 행위를 규현한 프로시져)를 가짐
- 데이터를 추상화하는 단위
- 유사 객체(인스턴트)를 정의한 모듈
- 소프트웨어에서의 모듈이란속성을 가진것
객체의 행위를 구현하는 메소드를 저장한 것
-클래스가 될 수 있는 조건-
인스턴스를 가질 수 있는것
인스턴트 변수
- 각 객체에 존재하는 변수를 저장하기 위해 클래스 안에 정의한 변수
- 속성: 객체의 상태를 나타내는 값(단순한 데이터)
- 관계: 클래스의 인스턴스와 타 클래스의 인스턴스 간의 연관관계
클래스 변수(전역변수)
- 클래스에 속하는 객체들이 공유해야 하는 값 -> 타 객체가 저장한 값에 접근 할 수 있다
- 객체를 참조
- 시점마다 다른 객체를 담고 있을 수 있음
- 클래스 변수로 만드면 좋은 경우
- 자주 사용하는 산수 값
- 항목을 가리기 위한 테이블, 구조체
메소드와 오퍼레이션
- 클래스의 행위를 구현하기 위한 일종의 프로시저(함수)
- 오퍼레이션: 클래스 행위의 타입
- 여러 클래스는 같은 이름의 메소드를 사용할 수 있다(다형성)
- 메소드를 통해 객체의 속성을 조작한다
상속
- 수퍼클래스에 정의한 내용을 서브클래스가 묵시적으로 소유하는 것
- 일반화: 서브클래스의 공통적인 특성을 묶는 것
다형성
- 오퍼레이션이나 속성이 하나 이상의 클래스에서 정의되고, 각 클래스에서 다른 형태로 구현될 수 있는 개념
- 속성이나 변수가 서로 다른 클래스에 속하는 객체를 지칭할 수 있는 개념
- 객체지향을 간결하게 만든다
실질적으론 다른 메소드를 같은 이름으로 만드는 이유 -> 간결해지니까!
동적바인딩: 실행되는 정확한 코드가 런타임에 정해지는 기법
- 타깃 객체가 최종실행 단계에서 결정된다
오버로딩: 같은 클래스 내에서 이름이 다른 여러 오퍼레이션을 정의하는 것
(다형성은 서로 다른 클래스에서, 오버로딩은 한 클래스에서 정의)
함수 재정의(오버라이딩)
- 상위에서 정한 개념을 하위에서 재정의 하는 것
추상 클래스
- 추상연산을 하는 클래스
- 구체적인 인스턴스를 가지지 못한채 개념만 가지고 있다
- 서브클래스에게 상속할 기능을 정의한다
UML
- 원활한 의사소통을 위해선 복잡한 아이디어를 간결하고 정확히 표현해야 한다
- uml은 표기법으로 소프트웨어 제품, 도구, 방법론이 아니다
관점에 따라
- 기능적
- 정적
- 동적
으로 구분된다
특징
- 비쥬얼화: 소프트웨어의 구성요소와 그것들의 관계 및 상호작용을 시각화한 것
- 명세: 분석, 설계, 구현의 정확하고 완벽한 모델을 제공(뼈대 코드)
- 구축(> 구현): 객체지향 언어와 호환된다 -> 코드 자동 생성 or 모델을 추출하는 역공학을 제공한다
즉 모델과 코드의 양방향 추적성 제공
- 문서화: 문서화 작업 중 모순되는 곳을 줄일 수 있다
- 테스트 기준: 설게 작업, 설계를 분석하고 검토시 사용
3강
요구분석
- 시스템의 외형적 기능이나 내부성능, 조건
도메인분석
- 엔지니어가 개발하려는 분야의 배경지식을 알아가는 과정
도메인 - 예상되는 고객이 일하는 분야의 비지니스나 기술을 의미
- 그 분야에 지식이 많은 사람 -> 도메인 전문가
장점
빠른 개발
좋은 시스템
확장예견
도메인분석서에 들어가야할 내용
- 개요
- 용어
- 개괄적 지식: 전문가가 알고 있는 중요한 사실, 규칙
- 고객과 사용자
- 환경: 사용하는 장비, 시스템
- 경쟁 소프트웨어; 시장분석 및 장단점
- 도메인과 조직의 유사도: 타 조직과ㅏ의 차이점, 공통점 파악
문제 정의와 프로젝트 범위 설정
문제
- 사용자, 고객이 당면한 어려운점
- 생산성, 판매량을 높여 이익을 얻을 수 있는 기회
- 문제를 정상적으로 해결하기위해선 대부분 소프트웨어 개발이 수반될 수 밖에 없다
잘된 문제 정의서는 간결하다. 한두 문장으로 표현하는 것이 좋음
시스템의 목적은 문제를 더 상세히 정의하여 범위를 좁히는것
- 시스템이 할수 있는 모든 일을 상상한 후 리스트로 작성
- 범위가 넓으면 일부를 배제, 너무 좁으면 상위목표로 설정
범위가 작을수록 시스템은 간결해짐
요구수출
요구사항 분석->추출-> 분석-> 명세화-> 확인
요구
- 시스템이 무엇을 하는지 나타낸 문장
- 관련자들이 모두 동의한것
특징
- 요구는 문장이다 -> 짧고 간결한 정보
- 시스템이 무엇을 하는지 나타낸 것
- 관련자 모두가 동의한 것
- 문제를 적절히 해결하기 위한 것
요구의 유형
기능적 유형: 시스템이 무엇을 하는지 기술한것
- 입출력
- 저장
- 컴퓨팅
- 타이밍과 동기화-> 꼭 동시에 작동하는 것이 아닌, 연동도 포함
비기능적요구: 고수해야할 제약조건
- 검증이 가능할 수 있도록 해야한다
-
사용용의성, 효울성, 신뢰성, 유지보수성, 재사용성 등 수준을 맞추기 위한 사항
-반응시간
-처리량
-자원사용량
-신뢰도
-가용성
-장애에서의 회복
-유지보수와 확장의 허용
-재사용성의 회복 -
시스템의 환경과 기술
-플랫폼
-사용기술 -
프로젝트 개발방법에 대한 계획
-사용하는 개발 프로세스(방법론)
-비용과 납기일
요구수출 방법
관찰
- 관련 문서 등을 읽고 사용자와 심각하게 논의
- 시간이 많이 소요
- 잠재적 사용자가 수행하는 복잡한 작업을 관찰
인터뷰
- 잘 계획해야 좋은 정보를 얻을 수 잇다
브레인스토밍
프로토타이핑
- 예상기능의 일부를 빠르게 구현해보는것
- 전용 프로토타이핑 언어로 모의 사용자 인터페이스를 만드는 것
- 피드백을 받을 필요는 없으나 아키텍처를 설계할 필요는 없다
- 요구를 취합하는 도구로만 사용
메뉴얼
- 어떤 일이 일어날지 기록
- 가장 간단한 형태
사용사례 분석
액터찾기
- 사용자 클래스 또는 다른 시스템을 결정하는 일
사용사례찾기
- 각 액터가 시스템을 사용할 필요가 있는 작업을 결정하는 일
사용사례 다이어그램 그리기
사용사례간 관계
- 액터가 시스템과 상호작용할 때 여러가지 이벤트가 발생할 수 있다
확장단계
- 선택적인 상호작용을 명시할 때 또는 예외적인 경우를 다룰때
- 별도의 사용사례를 분리해서 나타내면 기본 사용사례가 간단해진다
이떄, 모든 단계를 기술한 후 예외상황 처리도 포함이 되어야 한다는 점이다
상세화 단계
- 일반적인 사용사례와 여러 유사 사용사례 관계를 나타낸다
- 상세화된 사용사례는 더 상세한 사건 흐름이 제공
(공통된 부분이 있을때, 일반적인 상황일때, 사용사례를 공유할때)
포함단계
- 공통적인 부분이 있을때 -> 여러 사용사례가 일련의 액션을 공유할때
- 중복되는 부분을 되풀이하기보단 특수한 사용사례를 만들어서
타 사용사례에 사용하는 것이 효과적
(특수 상황일때, 액션을 공유할때)
상세화와 확장 단계를 구분하긴 어렵다
사용사례 작성의 실제
사용사례 이름
액터: 사용자, 외부시스템
목적
시작조건: 액터가 이 사용사례를 구동하기 위한 조건, 상태
관련사례: 사용사례 사이의 연관성
사건의 흐름
종료 조건: 사용사례 종료 후 시스템의 상태 기술
주의점
-시스템에 계산 내용을 작성 할 필요 없음
-특정 인터페이스 설계와 관계없이 작성
-엑터가 시스템과 상호작용한 액션만 포함
-사용사례간 관계는 접점을 표시해야 한다
사용사례의효과
-시스템의 범위를 정하는데 도움
-개발 프로세스를 계획할 때 도움이 된다
-요구를 발견하고 검토시 사용
-테스트 케이스를 계획할때 기초가 된다
-사용자 메뉴얼 구성에 사용
요구 문서화
요구문서의 구조
작성해야할 사항
-
시스템의 크기
-상세한 요구 문서가 필요
-서브시스템으로 분활하여 타 부서에서 개발하도록 해야함 -
다른 시스템에 대한 인터페이스 요구
-클라-서버 통신 프로토콜 등을 작성해야 한다 -
목표로 하는 독자
-
개발을 위한 계약
-
요구취합 단계
-첫 사이클에선 간결한 문장으로 정의한 요구를 프로토타이핑으로 구현하는 것이 적합 -
도메인 및 기술에 대한 경험 수준
-
잘못된 요구에 대한 비용
-시스템이상으로 인한 안전/환경 위험 여부 확인
요구검토
=개발 대비 투자 효과
=문제의 우선 순위
- 파례토 법칙: 문제의 80%는 작업의 20%가 해결 할 수 있다
- 필요 이상의 요구를 리스트로 만들 필요는 없다
=명확하고 일관성 있는 표현
=모호하지 않은 표현
=일관성
- 표준규격, 타 요구와의 일관성, 상하위 시스템의요구와 잘 부합하는지
=품질 좋은 시스템의 유도
=추적 가능성
4강
클래스 다이어그램의 구성요소
-클래스: 속성과 오퍼레이셔의 집합체
-데이터의 타입선언과 같은 의미
-속성: 인스턴스에서발견할수 있는 데이터 타입
객체의 상태, 성질을 나타내는 자료값
-오퍼레이션: 클래스에 포함된 함수
-상속: 클래스를 그루핑한 상속구조
-일반화: 클래스를 상속구조로 그룹화
속성
-객체의 상태, 성질을 나타내는 자료값
-속성은 변수가 아니다
-/속성은 다른 속성에서 유추가능 -> 읽기전용이 되어야 한다
오퍼레이션
-getter, setter를 이용해 속성값을 이용한다
-오버로딩을 이용하면 한 함수를 다중정의 할수 있다
가시성
+: public
-: private
#: protected
추상 오퍼레이션과 추상클래스
-구현이 없는 오퍼레이션(연산)
-추상클래스는 객체가 없는 클래스 -> 오직 상속만을 위해 존재
상속: 수퍼클래스의 속성과 메소드를 서브클래스가 묵시적으로 소유하는 것
연관관계
-각 클래스가 어떻게 관련이 있는지 나타내는 것
-양 끝에 다중도를 표시한다
-이름은 동사, 동사구로 표현
다중도
-불필요한 1 대1 관계는 피한다
-*, n..s 등으로 범위를 표시
-융통성 있는 다중도 표현을 이용
링크
-연관관계의 인스턴스
-방향성이 있으나 일반적으로 양방향이다
연관클래스
-두개의 연관클래스에 관한 속성을 어느 한쪽에 위치시킬수 없을 경우
-두 클래스 사이에 위치시킨다
재귀연관관계
-클래스는 자기자신과 연관관계를 맺을 수 있다
일반화 관계
-두개 이상의 서브클래스로 구체화 시키는 것
-인스턴스가 되어야 할 것을 무리하게 상속하지 않도록 주의
-상태와 상속을 혼동하지 않을것
구분자(discriminator): 상세화 기준을 나타내는 레이블
-서로소(disjoint): 하위 클래스에 중첩되는 것이 없음
-overlapping:하위 클래스에 중첩이 있음
-completed: 서브클래스의 객체가 수퍼클래스의 개념을 모두 포함
-incompleted: 모두 포함하지 않음
전체-부분관계
-전체개념에 해당되는 클래스와 이를 이루는 부품에 해당되는 클래스의 관계
=집합관계(◇)
-부분 혼자서 존재할 수 있는 관계
-집합관계가 아닌 것을 마름모로 표시하는 것은 혼란을 초래한다 -> 확실하지 않으면 연관관계로 표시
ex: 동호회 -> 회원
=합성관계 (◆)
-전체개념 소멸시 부분개념도 소멸되는 강력한 관계
-부분 혼자서 존재하지 못하는 관계
ex: 건물 -> 방
인터페이스
-객체집합이 가지는 행위를 일부 가시화하여 나타낸것
-추상 메소드만으로 구성 -> 객체, 구현되는 메소드가 없다
-<>로 표시
추가정보 표현법
=상세문서와 다이어그램
=노트 -> 주석과 같은 역활
=제약
-컴퓨테에 의해 해석될 수 있는 정형적 언어
-역활은 노트과 같음
-추천언어는 ocl
OCL
-소프트웨어 모델의 제약사항을 정해진 키워드로 나타내도록 정형화된 언어
-명세언어 -> 논리적인 사실을 간결하게 표현
-제약사항은 부작용이 없어야 하며, 논리적이여야함
-다른 자료를 조작해선 안된다
-다이어그램에 직접표시하지 않고 다른 곳에 표시
클래스 다이어그램의 OCL은 속성과 연관관계가 어떤값을 가져야하는지 나타낼 수 있다
클래스 다이어그램의 작성과정
-반복-점증적 방법 -> 필요하면 추가 및 삭제
작성 순서
1. 클래스 후보 집합을 파악한다
2. 최중요한 클래스부터 연관관계와 속성을 추가한다
3. 가장 확실한 일반화관계부터 시작한다
4. 클래스의 중요임무를 찾아 나열, 수행될 기능을 간단한 문장으로 나타냄
5. 임무를 기준으로 필요한 오퍼레이션을 결정한다
6. 전체과정 반복
-
클래스 후보 선정법
-도메인 모델을 개발시 클래스를 찾아내려고 노력
-ui, 시스템구조 작업을 할때 필요한 클래스를 찾는다
-유사 시스템을 살펴보기
-요구기술서 살펴보기 -
연관관계와 속성추가
-중심이 된다고 생각되는 클래스부터 시작
-분명하고 확실한 데이터를 포함할 수 있는 것
-다른 클래스와 관계가 명확한것
-더 작은 자료를 다룬다면 더 간단한 시스템을 구축할 수 있다
-> 꼭 필요한 속성/연관관계인지 확인 -
일반화 관계와 인터페이스 파악
-상향식 접근 법 -> 점점 일반화
-하양식 -> 점점 상세화
=다음에 해당될 경우 인터페이스를 고려
-클래스가 몇개의 공통적인 오퍼레이션을 제외하곤 유사하지 않을때
-하나 이상의 클래스가 수퍼 클래스를 형성하고 있을때
-같은 클래스의 다른 구현이 필요할때
- 임무부여
-시스템이 수행하도록 하는 요구사항
-분산 -> 임무를 클래스에 분산하여 단일 클래스가 과도하게 복잡하지 않도록 하기
-주어진 클래스의 모든 임무는 서로 연관되어야 한다
-어떤 클래스에 임무가 없다면 그 클래스는 필요없다
임무를 결정한느 좋은 방법-> 사용사레 분석을 해보는 것
명세에서 액션을 기술하는 명사와 동사를 찾는 것
- 오퍼레이션 파악
-각 클래스의 임무를 실현할때 필요
-하나의 임무를 실현하기 위해 여러 클래스가 필요할 수 있고,
단일 클래스가 책임을 질 수도 있다
-임무를 수행하는 메인 메소드: public
-협력하는 메소드: private
코드매핑
속성: 일반적으로 인스턴스 변수로 구현
-인스턴스 변수를 사용하여 구현
-양방향연관관계는 두개의 단방향 연관관계로 나눈다
일반화: extends을 이용
인터페이스: implement로 구현
--------5강---------
UML을 이용한 객체지향 설계는 사용사례를 찾고 이를 모델링하는 작업부터시작
-엑터릐 관점에서 외부에 보이는 GUI 프로토타입을 상상하여, 사용사례를 찾아낸다
클래스 다이어그램: 코딩과 밀접하게 관련있는 다이어그램
객체지향에서 가장 어려운것
-사용사레와 코드사이의 차이를 줄이는 것
동적 모델링: 시스템의 행위를 나타냄
-구동되는 정확한 코드가 런타임에 결정되됨
-중요한 요소: 객체, 메소드
인터렉션 다이어그램: 시퀀스 + 커뮤니케이션 다이어그램
행위 다이어그램: 상태 + 액티비티 다이어그램
- 시퀀스 다이어그램
-시간 축에 초점을 두고 시간의 흐름을 명시적으로 나타낸다
요소
라이프라인(점선): 객체가 시스템에 존재하는 시간
메시지(화살표): 보내는 객체의 타임라인에서 시작하여 받는 객체의 타임라인까지 연결
액티비션 박스: 객체가 활성화되어 실행되는 기간
객체소멸( X ): 객체가 시스템에 존재하지 않음을 나태냄
포크: 스레드와 같이 병렬 메소드 호출을 한경우, 두개의 라이프아인으로 나타낸다
프레임: 다이어그램의 일부가 묶여 조건에 의한 택일, 반복구조를 이룬다
반복 메시지: 프레임으로 둘러싼다
회귀 메시지: ㄷ다로 표시
다중객체: 상자를 곂쳐서 표시
메소드: 클래스에 정의된 오퍼레이션이 객체의 임무를 위해 구현된것
이벤트: 객체의 조전을 인터랙트하는 액션(조건 만족시 행위 발생)
-정상적인 흐름을 중지시키고 다른 메소드를 호출하는 비동기적
-일정시간이 지나고 발생하는 동기적 타임이벤트
비동기 메시지
-동기메시지: 메시지를 받는 객체의 수행(반응)을 기다리는 것
-비동기 메시지: 메시지를 보내고 계속 실행할 수 있는 경우
- 커뮤니케이션 다이어그램
-인터렉션을 실행하기 위해 여러 객체가 협력하여 동작하는 것을 네트워크 형태로 나타낸 것
-라이프라인과 액티베이션 박스가 없다는 것을 제외하고 시퀀스 다이어그램과 매우 유사
요소
-객체 사이의 메시지는 객체와 직접 연결된 선 위의 화살표 위에 표시
커뮤니케이션 다이어그램의 커뮤니케이션 링크는클래스 다이어그램의 연관관계 인스턴스와 일치할 필요는 없다
어떤 객체가 타 객체에게 메시지를 보낼때 항상 커뮤니케이션 링크가 존재한다
=두 객체의 클래스가 연관관계에 의해 결합된 경우
-연관 관계는 한쪽 방향으로 정의
<>
<>
<>
<>
커뮤니케이션 다이어그램을 그리는 법
1. 모든 객체를 찾는다
2. 메시지를 시간순으로 나타낸다
3. 중심 객체를 중앙에 놓고 상호작용하는 객체를 주위에 놓는다
4. 화살표로 메시지를 표시하다
5. 이하 반복
- 상태 다이어그램
-시스템이나 객체가 어떤 오퍼레이션에 의해 어떻게 동적으로 변하는지 기술
-시스템이나 개별객체에 대해 외부에서 보이는 행위를 기술
시스템, 객체는 주어진 시점에 어떤 상태에 있다고 한다
-> 객체의 상태를 표시가능
심벌
시작 상태( ● ): 시작상태
종료상태 ( ◎ ): 종료상태: 다수의 동료상태가 존재할 수 있다
트랜지션의 종류
-이벤트에 대한 상태 변화 -> 즉시 일어난느 것이 원칙
=경과 시간 표시 오퍼레이션
-시간이 표시된 오퍼레이션
-일정한 시간이 경과된 후 발생하기도 함
=조건 표시 트랜지션
-어떤 조건이 만족되면 트렌지션이 이루어지는 사례
액티비티
-시스템이 특정상태에 있을때 일정시간동안 발생하는 것
-시스템은 액티비티가 완료된 응답으로 어떤 상태를 빠져나오는 트랜지션을 일으킨다
-do: 상태에 있을때 동작 기술
액션: 다음 상태에서 즉시 발생
-시스템이 특정 트랜지션을 일으킨다
-특정상태로 진입시
-특정상태에서 탈출할때
-메시지를 보내거나, 하드웨어 장치를 구동하거나, 변수값을 할당하는 것돠 같이
단순해야함
표시
진입: Enter/액션
탈출: Exit/액션
서브상태
-상태 안에 내장된 상태를 정의 할 수 있다
-↑정의한 내부 다이어그램의 상태
액티비티 다이어그램
-내부 이벤트에 의해 발생
-객체, 컴포넌트가 수행하는 작업의 흐름을 이해하는데, 사용사례 사이의 인터렉션을 가시화하는데 사용
-병행 액티비티를 나타낼 수 있다
병행처리
-포크: 두개의 병행 스레드로 분리
-조인: 모든 입력 트렌지션이 트리거 되었을때
-랑데부: 다수의 입력 트랜지션이 트리거 되면 시스템이 모든 출력 트랜지션을 별도의 스레드로 보낸다
스윔레인
-다수의 클래스 관점으로 나타낸것
동적다이어그램
-시스템에서 가장 복잡한 부분은 인터렉션, 행위 다이어그램을 사용하여 표현해야 한다
상태 모델링 접근법
-설계 정보를 찾아내는 과정을 반복하면서 문제를 해결해 나간다
1. 경험있는 개발자가 모델링 프로세스를 주도
2. 중요한 클래스에 대해 상태 다이어그램
3. 다시 클래스 다이어그램으로 돌아가 추가, 수정
기타: 자동화 도구 이용(case tool)
------6강--------
설계란:
비기능적 요구사항 떄문에 나타나는 제약을 반영하고,
좋은 품질을 만들려는 이론에 충실하면서
시스템의 기능적 요구사항을 구현
의사결정 과정
-몇가지 선택적인 해결책이 있다
-최선의 선택을 위해 고려하는 것을 정하는 과정도 포함
->
필요한 정보
-요구사항에 관한 정보
-이전까지 이루어진 설계작업에 관한 정보
-활용가능한 기술에 관한 정보
-소프트웨어 설계이론과 가장 좋은 사례에 관한 정보
-과거에 잘된 설계에 관한 정보
설계범위
-여러가지 대안의 집합을 총망라함으로 달성할 수 있는 모든 설계방법을 나타낸것
병렬설계 작업
-가장 좋은 설계방법을 찾아내는 방법
-여러명의 설계자가 독립적으로 설계하여 최종산출물 완성
설계문서
-왜 이렇게 만들었는지 기술
컴포넌트
-명백한 역활을 가짐
-독립적으로 존재할 수 있는 소프트웨어, 하드웨어의 한부분
-재사용이 가능하도록 설계
-같은 기능을 가진 다른 컴포넌트가 있다면 대체
-특정 목적, 사용자 인터페이스를 제공하는 기능만을 수행하는 경우가 있다
-종류: 프레임워크, 원시코드 파일, 실행파일, 동적 링크 라이브러리, 데이터베이스
모듈
-프로그래밍 언어 수준에서 정의된 컴포넌트
-자바: 메소드, 클래스, 패키지
-c: 파일, 함수
=시스템
-어떤 책임과 목적을 가지고 소프트웨어, 하드웨어로 구성된 논리적 개체를 말한다
-명세를 가질 수 있고 컴포넌트에 집합에 의해 구현
-시스템은 컴포넌트가 시간의 흐름에 따라 변하거나 다른 컴포넌트로 교체되어도 지속적으로 존재한다
=서브 시스템
-보다 큰 시스템의 일부분으로 확정된 인터페이스를 갖는다
=========7장===========
디자인패턴
- 시행착오를 거치며 비슷한 역활의 클래스 유형을 자주 사용하게 됨
-> 자주반복되는 패턴
패턴의 존재이유
● 재사용성, 유지보수성
-타 클래스의 의존 최소화
-코드의 일반화
-설계의 재사용
●강건성(robustness
-신뢰성있는 설계, 설계 및 코드 재사용
●충분성, 정확성
-모듈화된 설계
-신뢰성있는 코드 재사용
-> 소프트웨어 품질과 관계됨
디자인패턴의 개념
-증명된 솔루션의 체계적으로 정리한 것
-1980년대부터 연구
-싱글톤 패턴 -> 시스템 안에 하나의 인스턴스를 존재하게 만드는 설계법
ex) 시스템의 형상정보는 한 객체에만 존재하게 하여 전역변수처럼 존재하여야 한다
클래스 다이어그램: 참여객체와 그것들의 의무, 관계를 표시
시퀀스 다이어그램: 참여객체가 문제를 해결하기 위해 상호작용하는 방법
기본패턴
-개념실체패턴: 각 객체의 공동 정보를 공유할때 사용
-플레이어 역활 패턴: 하나의 클래스에 다양한 역활을 표현하고 싶을 떄
-위임패턴: 다른 클래스가 가진 특정 오퍼레이션을 통해 책임을 위임하고 싶을때
-계층구조 패턴: 계층과계를 가진 객체들을 묶어 동일한 처리를 하고 싶을때
생성패턴
-간단한 블록의 코드로 여러가지 다양한 객체를 생성함
특징
-실행시간에 객체의 다양한 버전을 생성
-생성한 객체에 제한을 가함. 예를 들면 클래스 인스턴스 생성을 하나로 제한
생성유형(처음엔 5개였으나 증가함)
-싱글톤 패턴만 알면 된듯
구조 패턴
-더 큰 구조를 형성하기 위해 클래스를 구성하고 합성하는 문제를 다룬다
-> 주로 인터페이스를 상속받아 구현하여 합성
퍼사드 패턴
-서브시스템 내부가 복잡하여 클라이언트 코드를 사용하기 힘들때 사용
-간단한 인터페이스로 서브시스템의 주요기능을 사용할 수 있다
-퍼사드 패턴은 복잡하게 얽혀있는 것을 정리하여 높은 레벨의 인터페이스를 제공함
-패턴의 구조: 외부에서 호출한 기능을 내부의 다른 클래스에 위임형태로
전달함으로서 외부 클라이언트에게 내부의 복잡한 사정을 감춘다
결론
-패키지 사용을 용의하게 함
-다른 패키지와의 의존도를 낮춘다
==========8장===========
준비사항
1. 설계서 확인
2. 시간측정양식 측정
3. 결함기록 양식 작성
4. 코딩표준 숙지
5. 과거자료 참조
객체지향 방법론
요구분석-> 설계 -> 구현 -> 테스트
통합 프로세스
정립-> 발전-> 구축-> 전환단계
통합 프로세스의 구현모델
-구현단계의 생산물이 어떻게 구성되며 설계요소와 어떤 식으로 연관되는 지 나타낸다
-시스템 단계에서 정의한 시스템의 인터페이스가 프로그래밍 언어 수준으로
어떤 클래스에서 구현되는지 나타낸다는 것이다
-사용하는 언어는 설계에도 영향을 끼친다
코딩원리
-요구에 맞게 원시코드를 정확히 작성해야 한다
-컴파일 전 코드를 확인하는 것은 프로그래머의 의무
좋은 코딩 원리
- 재사용
- 믿을 만한 코드를 재사용한다
-구현하려는 컴포넌트가 이미 있는지 검색하는 것도 좋음
-GUI, 자바빈 등 미리 만들어진 컴포넌트를 이용하면
효율적일 뿐만이 아니라 신뢰도 높은 프로그램을 만들 수 잇다
- 의도확립
-코드를 특정 방향으로만 사용하려면 다른 방법으로 실행할 수 없도록 작성해야 한다
(의도 확립의 원리)
-의도를 정확히 나타내기 위해 final 등의 수식어를 사용한다
-상수, 변수, 클래스는 가능한 로컬로 만든다
-싱글톤 패턴 적극 이용
-타입이 다른 입력은 받지 않는다
-게터, 세터 이용
-메소드를 알파벳 순으로 나열
- 포인터와 레퍼런스
-포인터를 매개변수로 사용하는 것을 피하고 레퍼런스 타입을 사용하길 권장
-> 그래야 포인터에 상관 없이 코딩 가능
- 동적으로 할당된 레퍼런스에 대한 포인터를 가급적 리턴 하지 않는다
-메모리 누수 현상을 조절하기 위해 팩토리 타입의 유틸리티를 사용하도록 구정
-
함수
-타입에 대한 질의는 필요한 경우만 사용 -> 런타임이 늘어난다
-C++의 프렌드 함수(GOTO느낌)을 피한다
-함수의 의미를 오해하지 않도록 오버로딩 함수는 각별히 신경쓴다 -
예외처리
-try-catch문을 이용하되, 잘 모르면 throws문을 이용
예외처리시 유의할 사항
-예외를 처리할 수 있는 다른 넓은 범위에서 다루어야 한다
-예외의 일부를 처리할 수 있다면 부분처리만 진행
-예외 처리전 호출자의 성능을 예상한다.
처리하지 못한 예외가 영향을 줄 수 있을 경우 다른 설계방법을 찾는다
-테스트 중이하면 예외처리하지 않은 경우를 주의한다
-예외처리하는 것과 계속 진행하는 법 중 후자를 선택한다 -> 어플리케이션이 멈추는 것보다 진행하는 편이 좋다
오류처리 방법
-대부분의 프로그래밍을 오류를 처리하기 위한 것
사전에 오류를 배제하는 법
=잘 정의된 프로세스를 사용하여 각 단계마다 검토를 수행한다
-매개변수에 올수 있는 값이 한계가 있으나 무수히 많다면 별도의 클래스를 사용하는 것이 효과적이다
=입력이 처리되기 전 미리 데이터의 소스와 상호작용하여 정상적인 것으로 바꾸어 놓는다
-설계하는 입장에선 모든 일관성, 경계검사를 하는 것은 부담이다
-리스트 박스, 사용자 인터페이를 통해 정상적인 입력만 받자
ex) 리스트 박스 -> 한영이 바끼는 기능 등
잘몬된 입력을 처리하는 법(비정상적인 입력을 다루는 법)
-품질이 떨어지거나 결함이 있어도 계속 실행되어야 할 경우
-> 의미가 없더라도 모든 입력을 받아야 함
-> 안전한 디폴트 값을 지정한 후 예외처리를 통해 throw 문장을 작성하여 호출자에게
잘못된 입력의 책임을 넘긴다
-이는 데이터를 받는 메소드가 특정 데이터를 받을 것으로 설계되었기 때문이다
-> 따라서 어플리케이션은 데이터가 적합하지 않더라도 실행되어야 한다
-> 데이터는 검증되어야 하고 오류는 요구에 일치하도록 처리되어야 한다
요구사항에 없는 데이터 처리법
-전제조건을 확인하는 코드 삽입
-어플리케이션의 상태와 일치하지 않은 답을 리턴하지 않도록 미리 확인
-> 만족하지 않을 경우 내부가 수행되지 않도록 막는다
-한정된 시간내에 정확도 확인보다 오류에 대한 자동 보호기능의 코드를 삽입하는 것이 더 중요하다
객체지향 코딩 규칙
-
단일 책임
-클래스는 오직 한가지 이유로만 변경되어야 한다
-클래스는 여러 모듈에서 같은 코드 형태로 사용되지만 사용하는 이유는 모듈마다 다르다
-코드를 두 클래스로 분리하면 코드 길이는 길어지나 응집도는 향상되엇다 -
개방패쇄
-모듈은 확장은 용의, 수정은 차단해야 한다
-수정대신 확장을 해야 한다 -> 견고성이 강화됨
-상속과 다형성을 적극 이용해야 한다 -
리스코프 대체
- 서브 클래스는 다신의 베이스 클래스로 대체될 수 있어야 한다
-파생된 클래스는 기능을 유지하면서 단순히 확장하는 것
- 인터페이스 분리
- 여러 클래스로 구성된 모듈을 클라이언트가 쉽게 사용하게 하려면 추상화된 인터페이스를 제공하는 것이 좋다
- 즉 관심의 대상이 되는 인터페이스만 분리하여 제공해야 한다는 규칙
- 의존관계 역전
-자주 변경되는 구체적 클래스에 의존하지 말아야 함 -> 가능하면 추상화된 클래스에 의존
코딩표준
-코드를 읽기 쉼고 이해하기 쉽게 작성하기 위한 규칙과 가이드라인을 제공 하는 것
코딩 스타일을 표준화 하면 개발 및 유지보수 비용과 시간이 줄어들어 생산성과 품질을 높일 수 있다
↑핵심 문장
명명규칙
- private int _클래스 변수
파일구성 규칙
-파일의 이름을 붙이는 법과 무엇을 담아야한느지 정한다
-각 파일에는 하나의 외부 클래스나 인터페이스를 담고, 클래스 이름 = 파일이름
-한줄의 길이는 80증(column)이 넘지 말아야 하며,
쉼표 이후 분할하고 오퍼레이터 인전에 분할한다
-1)주석 2)패키지 import 문장 3)클래스 인터페이스 순으로 작성
문장규칙
365p참고
주석 처리법
-코드를 이해하는데 도움을 주는 문장
-원시코드를 요약하여 다시 쓰는 것을 목적으로 한다
-
헤더 주석
-모듈 단위로 달경우 컴파일 및 테스트 하는데 유용하다 -
주석의 문서화
-주석만 가져오면 하나의 문서가 된다 -
주석의 사용법
-문서화 주석(/*)의 중요한 목적은 클라이언트와 서비스 제공자의 계약관계를 정의하는 것
레이아웃 규칙
-들여쓰기(indentation)를 어떻게 하는지 나타낸것
설계와 매핑
-객체지향의 장점: 분석과 설계에서 코딩으로의 전환이 매끄러움
-IDE에서 자동으로 다이어그램을 코드 골격으로 변환
372p 부터 읽어보기
리펙토링
-보다 쉽게 이햐하고 적은 비용으로 수정할 수 있도록 내부구조를 수정하는 것
-애자일, 진화적 접근 방법의 핵심
-애자일 방법론에선 최선의 디자인이 수많은 반복에 의해 진화되어 나오는 것으로 생각한다
-작동하는 것과 작동하지 않는 것을 알아내면서 계속 피드백 해야함
작업과정
1. 작음 변경을 한다
2. 테스트한다
3. 잘되면 다음으로 넘어간다
4. 안되면 기존 코드로 되돌려 놓는다
코드 스멜
-설계를 수정하기 어렵게 만드는 코드
=클래스 수출
-단일 책임 클래스를 위한 리펙토링
=인터페이스 수출
-다목적 인터페이스를 만드는 것보다 다양하게 구현된 특별한 인터페이스가 많아야 한다
-인터페이스 분리 규칙을 따를 것
=메소드 수출
-코드의 중복을 제거하는 메소드
-너무 많은 일이 포함된 메소드가 있을 경우, 너무 길경우
-> 재사용이 어렵다
검토
-인스펙션(inspextion): 코드의 결함을 찾아내고 이를 확인하는 방법
-품질 개선과 초기 결함 발견에 효과적
수행시기: 프로그램이 성공적으로 컴파일되고 정적 분석 도구가 적용된 후
목적: 코드에 존대하는 결함과 비효율성 등 코드의 품질에 영행을 주는 결함을 찾는 것
======9장=========
테스트:
-시스템을 개발할 때 요구되는 동작과 실제 개발한 후 동작이 다르지 않은지 분석 및 확인하는 작업
-수동, 자동 으로 검사하는 일련의 작업
-시스템 모델의 결함을 반증하는 작업
-소프트웨어의 신뢰도를 높여줌
어떤 테스트 작업도 소프트웨어의 동작이 요구와 다르단 것을 반증할 수 없다면
릴리즈 된 준비가 된것
-테스트 대상 컴포넌트: 분리하여 시험할 수 있는 시스템의 요소
-결함: 소프트웨어 동작 수행에서 인간의 실수, 의도한 동작에서 거리가 멀어짐
-오류: 결함의 표시
-고장: 명세와 실무의 차이
-신뢰도: 시스템의 동작과 명세의기술된 동작이 일치하는 정도
-테스트 케이스: 컴포넌트를 검사하기 위한 입력과 예상결과의 집합
-테스트 스터브: 테스트 컴포넌트가 호출하는 컴포넌트의 부분적인 구현
-테스트 드라이버: 테스트될 컴포넌트를 호출하는 컴포넌트의 부분적인 구현
소프트웨어의 고장은 오류에서 비롯된다
그러나 모든 오류는 결함이 되는 것은 아니다
테스트 케이스
-결함을 발견할 목적으로 준비된 입력 데이터와 예상 결과의 집합
오류수정
-결함을 고치기 위해 컴포넌트를 변경하는 작업
-단일 컴포넌트를 수정하는 단순 작업~자료구조나 서브시스템을 다시 설계하는 작업
결함을 발견하는 법
-버그 트레킹: 컴포넌트를 수정할 때 작업의 기록을 남기는 것
-리그레션 테스트: 개발된 기능이 아무런 영향을 받지 않았음을 확인
-> 자동화되지 않으면 비용이 많이 든다
-문서화: 여러 수정에 대한 변경이유를 기록한다
-단위테스트: 모듈/컴포넌트 테스트 -> 컴포넌트 내부의 데이터 구조와 로직, 입출력 자료의 경계 조건을 확인
-통합 테스트: 컴포넌트를 독립적으로 테스트 한 후 그것들 사이의 인터페이스를 테스트 하는 것
-> 컴포넌트들이 시스템 명세에 나타낸 것 처럼 작동하는 지 확인하는 과정
-시스템 테스트: 컴포넌트를 통합하여 하나의 시스템으로 빌드한 후 잘 작동하는지 테스트 하는 것
-인수 테스트: 요구사항대로 작동하는지 고객과 확인하는 작업
블랙박스 테스트
-테스트하려는 대상을 블랙박스로 보고 그 기능이 올바른지 확인하는 작업
경계값 분석: 오류가 많이 발생하는 경계값을 분석하여 이 부분을 집중테스트
원인 결과 분석: 원인과 결과의 관계를 파악하여 테스트 케이스를 찾는다
동등분활 테스트
-입력의 결과가 동등한 클래스를 분활하여 대푯값을 주는 방법
-테스트 사례의 개수를 최소화하는 테스트 방법
동치 클래스를 결정하기 위해 사용하는 선택기준
-포함정도: 가능한 모든 입력은 동치 클래스 중 어느 하나에 반드시 속해야 한다
-비결합성: 같은 입력이 여러개 존재하면 안된다
-표현성: 동치 클래스의 a 멤버가 입력일때 오류라면, a의 다른 멤버의 입력도 오류가 나와야 한다
테스트 할 입력 데이터 선택
-공통 사례를 조사하는 전형적인 입력 데이터
-컴포넌트의 예외사례를 처리하는 비정상적인 입력 데이터
테스트 입력 데이터는 동치 클래스의 모든 요소를 커버해야한다
커버되지 않는 다면 더 작게 쪼개야 하며,
테스트 입력 데이터가 새로운 동치 클래스의 모든 요소를 커버하는지
다시 확인
경계값 확인
-개발자가 동치 클래스의 경계에 있는 특수한 경우를 때댸로 간과 한다는 것을 전제로 한다
-테스트 입력 데이터로 경계값을 선택한다
원인 결과 분석
-주어진 결과와 그 결과에 영향을 주는
모든 영향을 주는 모든 요인 사이의 관계를 그래픽적으로 표현하여 알아내는 법
-출력에 주는 입력과 조건의 관계를 파악하여 의사 결정표로 만들고
이를 이용하여 테스트 케이스로 만든다
입출력 관계를 불린 함수로 바꿀 수 있다는 가정을 바탕으로 한다
화이트 박스 테스트
-모듈 안의 내부 구조와 실행 흐름을 자세히 참조하는 방식
-자료 흐름에 기반을 둔 테스트
경로 테스트: 원시 코드와 자료구조에 대한 지식이 필요하다
-테스트 케이스를 작성ㅇ하려면 흐름도를 파악 후 액티비티 다이어그램을 살펴본다
-그래프 이론: 모든 간선을 커버하는데 필요한 최소한의 테스트 횟수는 흐름도에서 독립경로의 개수와 같다
경로 테스트의 한계
-모든 오류를 발견할 수 있는 것은 아님
자료구조 관련
-경로 테스트가 이 동치 테스트에 대한 테스트 케이스를 제대로 생성하지 못한다
-자료구조에서 배열의 한계값을 넘어가는 것과 같은 오류를 발견하기 어렵다
객체지향 시스템 관련
-다형성: 가능한 모든 바인딩을 파악하고 테스트 해야 한다
-짧은 메소드: 알고리즘이 여러 메소드에 퍼져 구현되기 때문에 오류 발견 가능성을 낮춘다
테스트 커버리지
-소트프웨어의 총량에 대해 테스트된 아이템의 비율
-품질 목표인 동시에 품질 목표 성과의 측정
코드의 구조를 이루는 요소: 문장, 분기, 경로, 조건
객체지향 테스트
사용사레 기반 테스트: 사용사례 명세로부터 테스트 케이스를 추출
상태기반 테스트
-객체지향 시스템에 초점을 둔 새로운 테스트 기법
-> 새로운 형태의 오류를 발생
-각 상태에 대해 변환을 일으키는 외부 자극의 집합을 파악
->클래스의 속성을 삽입 -> 외부 자극이 주어진 후에 특정 상태에 도달하는지 테스트
상태기반 테스트는 여러 난해한 면이 있다
-클래스의 상태가 캡슐화 되어 있기 때문에 클래스가 원하는 상태로 되는 순서를 테스트
-클래스 속성값을 확인하기 위해 원시코드를 삽입
현재 임베디드 및 통신 소프트웨어의 적합성 시험에 표준으로 사용되나 자동화가 관건
통합 및 시스템 테스트
통합 테스트
-두개 이상의 컴포넌트에 초점을 두어 단위 테스트에서 발견하지 못한 결함을 찾는 작업
-통합 테스트를 체계적으로 하려면 시간이 많이 필요
-> 테스트 하는 순서가 통합 테스트에 소요되는 노력에 영향을 줄 수 있기 때문
동시식 통합
-모든 컴포넌트를 개별적으로 테스트 한 후 이것들을 동시에 통합하여 단일 시스템으로 테스트 하는 방법
장점: 테스트 스터브/드라이버가 필요하지 않다는 것
단점
-단순해 보이나 비용이 많이 듬-> 고장 발견시 관련된 특정 컴포넌트를 찾아내기가 쉽지 않기 때문
-발견된 고장이 컴포넌트인지, 인터페이스인지 알 수 없다
상향식 통합
-하위층의 컴포넌트를 테스트 후 다음 위층의 컴포넌트를 차레로 통합해 나간다
-인터페이스의 결함을 쉽게 발견
-하위층 컴포넌트의 동작과 컴포넌트 인터페이스에 감추어진 가정에 대해 정확한 모델을 가지고 있기 때문
단점
-가장 중요한 사용자 인터페이스가 나중에 테스트됨
-최상위층에서 발견도니 결함은 서브시스템의 분할을 변경 가능하며,
서브시스템의 인터페이스도 영향을 줄 수 잇음
샌드위치 통합
-두가지 방법의 혼용
-타깃층을 중심으로 위쪽은 하양식, 아래는 상향식으로 병행하여 테스트
-결과적으로 최상/하위층에선 테스트 스터브와 드라이버가 필요하지 않다
시스템 테스트
-전체 시스템을 빌드 후 요구사항 중심의 테스트
-기능적/ 비기능적 요구 사항 만족 여부 확인
기능테스트(요구 테스트)
-기능적 요구와 시스템의 차이를 발견하는 것
-블랙박스 기법으로 테스트 사례를 사용사례 모델에서 추출
주의
-기능테스트는 사용사레 모델과 테스트하는 시스템 동작 사이의 차이를 발견하는 것이며
-사용용의성 테스트는 사용사레 모델과 시스템에 대한 사용자 예상 사이의 차이를 발견하는 것
-유즈 케이스 모델을 검토하고 오류를 일으킬만한 인스턴스 찾기
성능 테스트
-시스템이 부하에 잘 견디는지 확인
-동시에 발생하는 여러 요구에 시스템이 반응할 수 있는지 확인
다음의 테스트가 있다
-스트레스 테스트: 시스템이 부하에 잘 견디는 지 확인.
동시에 발생하는 여러 요구에 대해 시스템이 반응 할 수 잇는지 확인
-볼륨 테스트: 대규모 데이터와 관련된 오류를 찾는다
-보안 테슽: 보안 취악점 및 오류를 찾아내기 위한 테스트
-타이밍 테스트: 타이밍 테스트를 위반하는 시스템의 동작을 파악
-복구 테스트: 오류로 부터 시스템이 복구되는 능력을 평가한다
파일럿 테스트
- 시스템을 설피 후 선발된 사용자들이 사용해 본다
-어떠한 가이드라인, 테스트 시나리오도 존재 하지 않음
-알파테스트: 개발환경에서 사용자가 파일럿 테스트를 함
-베타 테스트: 목표환경에서 한정된 수에 사용자에 의해 실행되는 인수 테스트
차이점: 최종사용자들이 사용하는 것을 일일이 기록하지 않는다
인수테스트
-시스템이 가동되는 상태에서 전형적인 조건을 나타내는 테스트 사례
-벤치마크 테스트는 테스트 팀에 의해 이루어 질 수 있다
-리엔지니어링 프로젝트에서 사용하는 경쟁테스트
-> 새로운 시스템을 기존 시스템과 비교
-그림자 테스트(경쟁 테스트의 하위호완): 새로운 시스템과 노후 시스템을 병렬로 수행하여 비교
설치 테스트
-시스템이 인수된 후 목표시스템에 설치
-결과는 시스템이 모든 요구를 정확히 수행하는 것
-결과에 만족하면 시스템 테스트가 완결된 것
테스트 관리
-비용, 납기의 문제가 생기는 시점
효과적인 테스트 케이스를 조기에 선정하는 것
-사용사례가 완성되면 기능테스트를 설계할 수 있다
-개발자는 시스템이 완성되지 전에 모델에 존재하는 오류를 발견 할 수도 있다
테스트 작업을 병렬로 진행
-오류가 없다고 판단된 컴포넌트는 다른 컴포넌트가 수정되는 동안 더블 테스트를 할 수 있다
테스트 관리 문서
-테스트의 관리적인 측면에 초점을 주고 테스트 작업 범위와 접근방법, 자원, 일정을 문서화한것
-테스트할 컴포넌트와 요구사항이 명시됨
테스트 케이스 명세서
-테스트 과정에서 수행될 작업을 기술
목차
테스트 케이스 명세 식별법
테스트 아이템
입력 명세
출력 명세
요구 환경
테스트 순서에 대하 특별 요구
테스트 케이스 사이의 관계
테스트 실행 보고서
-테스트의 실행결과는 문서로 작성
-예상 결과의 차이를 기록하고 테스트 하면서 경험할 결합도 열거
테스트 요약 보고서
-발견된 모든 오류를 나역
-개발자는 이 문서를 보고 오류 분석 후 시스템이나 모델을 수정할 계획을 세운다
완벽히 테스트하고 수정은 불가능하다
-> 다음의 기준을 세운다
1. 테스트 케이스를 중요도에 따라 1, 2, 3으로 나눈다
2. 레벨 1에 해당된 테스트 케이스를 모두 통과시킨다
3. 레벨 2, 3 테스트 케이스는 미리 정한 비율을 넘는 다면 통과시킨다
4. 적어도 두 사이클의 빌드 과정을 거친다
테스트 작업 할당
-컴포넌트 개발에 참여하지 않았거나 분석에 능통하고 모순점을 잘 발견할 수 있는 사람
-품질 관리 담당 팀이 테스트를 담당하기도 한다
테스트 자동화 도구
-
정적 분석 도구
-코드 분석 도구: 원시 코드의 문법적인 적합성을 자동으로평가하여 결함을 찾아냄
-구조검사 도구: 원시코드의 그래프를 생성하여 논리 흐름을 찾고 구조적인 결함이 있는지 확인
-데이터 분석도구: 원시코드에 정의된 구조, 선언, 컴포넌트 인터페이스를 검사하여 잘못된 사용을 발견한다
-순서 검사 도구: 이벤트의 순서를 확인 -
동적 분석 도구
-이벤트의 상태를 파악하기 위해 특정 변수나 조건의 스냅숏을 생성한다
테스트 케이스의 생성 도구
-자료 흐름도: 원시 프로그램을 입력 받아 파싱 후 자료흐름도를 작성하여 정의-사용 관계를 찾는다
-기능 테스트: 기능을 구동하는 모든 상태를 파악하여 이에 대한 입력을 작성
-입력 도메인 분석: 입력 변수가 가질 수 있는 값의 도메인을 분석하여 테스트 데이터를 만드는 방법
-렌덤 테스트: 입력값을 무작위로 추출함. 시스템의 신뢰성 분석에 사용
테스트 실행의 도구
캡쳐 및 리플레이: 테스트 데이터를 자동으로 입력한 후 화면 및 결과를 캡쳐하여 예상 결과와 비교하는 도구
-오류를 발견한 후 수정하는 작업이 올바른지 확인하는데 유용
테스트 스터브, 드라이버: 자동으로 생성하는 도구도 잇다
자동 테스트 환경: 테스트 수행도구들이 테스트 환경으로 통합되어 제공되는 형태
10장
유지보수
-소프트웨어는 사용하면서 계속 개선 및 변경 된다
-기간은 5~10년 정도
교정형: 테스트단계에서 발견되지 않은 오류를 교정
적응형: 운영환경 변화에 따라 변경되는 경우
시스템이 진화함에 따라 적응하도록 함
개선형: 새로운 기능을 추가하는 형태의 유지보수
수정형: 결함에 따른 유지보수
리먼의 원리
-소프트웨어는 계속 변경된다
-복잡도가 계속 증가한다
-대규모 소프트웨어의 유지보수에는 일정한 특성이 있다
-> 그 크기, 버전간의 기간, 오류의 개수 등 고유의 특성을 가진다
유지보수에는 추세가 있으며 그 추세를 벗어나지 않는다
한번에 일어나는 변경에는 한계가 있다
-대규모 서프트웨어는 안정화 상태인 경우가 많다
-이전버전과 친근성을 유지하려고 한다
-기능은 계속 증가한다
-운영환경에 적응하지 못하면 품질이 저하된다
-소프트웨어는 피드백을 통해 진화해 나간다
개발과 유지보수의 사이
-유지보수 작업은 포괄적이고 단발적으로 수행
-개발과는 달리 처음 이해 단계에 많은 비용이 들고 실제 코드를 수정하는 단계에는 적게 든다
-유지보수는 이해 중심적인 작업
유지보수를 지원하는 도구는 이해중심적으로 설계되어야 한다
-개발에 쓰이는 도구는 유지보수를 위한 통합적인 환경을 제공하지 못한다
유지보수의 접근법
-형상관리에 좌우
-형상관리: 소프트웨어의 변경과정을 잘 보관하는 작업
형상관리가 잘 안된경우
-사항을 이해하지 못하고, 변경할 위치를 찾지 못하며 리그레션 테스트도 불가능하다
소프트웨어 역공학
-원시코드를 유지보수하기 위해 정보를 회복시키는 기술
-여러 참고표, 자료흐름도, 논리흐름도, 설계도등을 추출
-소프트웨어 재공학은 역공학에서 발전한 개념
영향을 주는 요소
-사용자: 불편이나 오류의 개선
-환경: 운용환경, 조직 환경의 변화
-유지보수 프로세스: 사용자의 변경요청을 찾는 작업, 이해하고 변경하는 작업 등
-소프트웨어 제품
-> 관련 문서, 운용절차등도 변경
->따라서 유지보수 작업은 도메인의 안정성, 문서의 품질, 원시코드의 품질 등에 따라 좌우됨
한계
-개발단계에서 소프트웨어 공학 원리르 ㄹ철저히 적용하지 않으면, 유지보수단계에서 노력이 더 필요하다
문제점
-변경이 수시로 일어나는데 문서에 반영하지 않은 경우
-다른 사람이 작성안 소스는 이해가 쉽지 않음
-변경을 가정하고 수정하는 경우가 드물다
-관리적인 요소에서 동기부여 불가
-적극적인 도구 활용 불가 -> 테스트, 디버깅 도구만 사용
유지보수 작업 단계
-변경사항 분석: 변경이나 추가에 의해 시스템이 어떻게 영향을 받는지 조사하는 작업
- 이해
=형상 관리 양호
-개발문서, 메뉴얼을 읽고 윤곽 파악-> 도메인 지식 습득 -> 프로그램(코드) 리딩
=형상관리 미흡
-원사코드에 의존 -> 주석을 읽거나 모듈호출 그래프 등 제작 -> 의미 파악 -> 멘탈모델로 표현
상향식과 묶음화
-원시코드에서 의미있는 묶음을 발견하고, 계속 더 큰 구조로 올라가 모든 시스템이 이해 될떄까지 반복
-
변경요구 분석
-불가피한 이유와 요구 분석 -
변경영향 분석
-변경이 필요한 부분을 모두 찾는다
-또 다른 방법이 있는지 확인
-여러 컴포넌트가 결합되어 있는 경우 작업이 어렵다
-여러 방안을 검토 후 각 방안의 유지보수 방안을 고려
-리스크를 해결했다는 것을 알 수 있는 테스트 기준도 있어야 함
설계 다이어 그램을 이용한 변경영향분석은 여러 문제와 관련된다
클래스 구현과 다이어그램이 다를 수 도 있다 -> 연관관계가 불확실 하다
따라서 설계 다이어그램을 근거로 한 영향 분석은 잘못된 결과를 낳을 수 있다
- 리그레션 테스트
-코드 변경 후에도 같은 기능을 하는지 판별하는 테스트
-변경에 의해 영향을 받는 부분만 테스트
-테스트 결과는 잘 보관해야 함
유지보수 작업 모델
즉시 수정 모델
-임시방편
-구조적인 파급효과를 고려하지 않고 바로 수정 -> 문서 변경 최소
반복적 개선 모델
-소프트웨어 개발 생명 주기 동안 시스템이 계속 개선된다는 전제가 바탕
-기존 시스템을 분석하며 변경이 일어나면 새 시스템을 개발하는 사이클
-완벽한 문서화와 유지보수 팀이 완벽이 분석할 능력이 있음이 전제
재사용 중심모델
-유지보수 작업 = 컴포넌트의 재사용이라고 본다
-컴포넌트를 분류하고 변경을 가능하게 하는 프레임워크가 필요하다
-생명주기의 시작은 어느 단계에서든 가능
-재사용 컴포넌트를 선택하고 맞춤화하는 작업 지원
형상관리
-소프트웨어를 이루는 부품의 베이스라인을 정하고 변경을 철저히 통제하는 것
-소프트웨어의 변경을 통제하지 않으면 통합이 이루어지지 않거나 제대로 빌드되지 않는다
-> 철저한 관리 필요
*베이스라인: 일종의 참조 시점
통제되지 않은 변경에 대한 취약성을 줄이는 것이 목표
형상요소 파악
-프로젝트 크기, 개발 프로세스, 가요자원 등 여러가지 요인을 고려하여 문서를 관리할 필요가 있다
-베이스 라인과 형상항목의 정의가 선행되어야 한다
-단순/복합 항목
-> 복합 항복은 다수의 항목을 포함
형상 변경 제어
-변경이유 파악
소프트웨어 결함, 하드웨어 변경, 운영요구의 변경, 고객으로 부터의 개선 요구,
예산, 프로젝트, 기간의 변경
-변경 분석
-변경요청 준비
-변경요청 평가
-변경추가
형상검사
-베이스라인을 구축하기 위한 메커니즘을 정의
-형상 항목을 검ㅌ토
-형상 항목을 확인
형상 상태 보관
-형상항목에 대한 정보를 추적하고 보고하는데 필요한 작업
-형상관리 DB는 프로젝트가 진행되면서 데이터양과 복잡도 증가
리엔지니어링
-소프트웨어의 품질, 모안, 성능 등 어떤 측면을 개선하기 위해 시스템 또는 컴포넌트를 재구조화 하는 작업
-소프트웨어는 지속적으로 변하나 구조는 계속 나빠진다는 것을 의미
-개선하는 작업에서 사용하며 대상 시스템을 새로운 요구에 맞도록 개조
소프트웨어에서의 역공학
-유지보수와 기능 향상에 도움을 주는 설계에 대한 충분한 이해가 그 목적
리엔지니어링의 목적
-소프트웨어 아키텍처 개선
-복잡도 경감
-변경ㅇ 대한 적응성 개선
-성능, 효율성, 자원 유용성 개선
-소프트웨어 시스템의 유지보수 개선
리엔지니어링과 추상화 수준
-생명주기모델: 방향성 그래프로 표현
-대상 시스템: 역공학에도 대상시스템이 있으며 이로부터 작업이 시작됨
-추상화 수준: 초반-> 추상적이고 일반적인 느낌
후반 -> 구현 중심
소프트웨어 리엔지니어링도 추상화된 정보를 얻기 위해 수행하는 역공학과
새로운 요구에 맞추어 구현하는 정공학을 포함하는 작업
-역공학: 대상 시스템을 분석하여 시스템의 구성요소와 그 관계를 파악하고 시스템을 달리 표현
-재문서화: 같은 수준의 추상표현을 만들거나 다시 개작
-재구조화: 기능변화 없이 같은 추상 수준에서 하나의 표현형태로 부터 다른 형태로 바꾸는 것
-> 대상 시스템의 상태를 개선하기 위한 유지보수에 이용
작업과정
개선이 필요한 위치 파악-> 개선전략 선택-> 제안된 개선 구현 -> 목표를 기준으로 시스템 평가
11장
pm: 프로젝트 관리자
-인사관리 등을 함
프로젝트 관리작업
프로젝트 계획과 수행에 필요한 여러가지 작업을 해야 한다
