2022. 10. 17. 02:50ㆍ학교수업
1장: 소프트웨어 개발 모델 - 생명 주기와 개발 모델*
2장: 2.2 UML*** (30), 2.3 설계 - 아키텍처*
3장: 3.2 의존성 주입과 IoC**
4장: 4.9 JUnit: 단위 테스트 프레임워크***
5장: 블랙박스 테스트***
7장: 7.2 JUnit을 활용한 TDD***
생명 주기와 개발 모델
생명 주기란 - 소프트웨어 라이프 사이클 .
요구사항 분석 -> 설계 -> 구현 -> 테스트 -> 유지보수 를 뜻한다.
요구사항 분석
1) 고객의 문제 해결, 목적 달성
2) 고객으로부터 수집, 분석, 명세
설계
1) 요구사항을 만족시키기 위하여 최적화된 해결책을 제시 및 선정
2) 응집도는 높고 결합도는 낮게 해야한다.
응집도 : 모듈의 목적 수행 정도(높아야 좋음)
결합도 : 모듈 간의 상호 의존 정도(낮아야 좋음)
구현
1) 프로그램 언어를 이용하여 고객의 요구사항을 개발
2) 견고성, 호환성, 이식성, 확장성, 가독성이 있어야한다.
테스트
- 개발된 프로그램이 요구대로 오류 없이 동작되는지 시험
유지 보수
- 개발 완료 후의 프로그램 수정및 보완
-> 수정 유지보수, 적응 유지보수, 완전 유지보수, 예방 유지보수
폭포수 모델 : 전통적인 모델, 선형적, 생명 주기 모델 기반
- 각 단게 종료 후 다음 단게로 이전(회귀 불가)
-> 모든 요구사항 완벽하게 수집, 분석 명섹세가 완료되면 변경 불가
구현->테스트 부분에서는 loop-back 가능
문제점 :
1) 요구사항의 잘못된 정의 -> 불완전한 반영, 왜곡된 해석 및 정의, 고객의 무지, 고객과 개발자 간의 잘못된 의사소통
2) 시간적 경과에 따른 요구사항의 변화
-> 요구사항은 변할 수 밖에 없다.
3) 고객의 피드백은 개발이 종료된 후 동작하는 소프트웨어를 통해서만 가능하다.
비용적인 측면에서 배포를 한 후 요구 수정 비용이 가장 비싸며, 오류는 요구사항에서 56%확률로 높다.
애자일 프로세스
- 반복적이며, 점진적인 개발 방법이다. (1~4주의 소규모 프로젝트)
우선순위로 할당된 요구사항 구현 -> 피드백 후 잔여 요구사항 구현 -> 반복
절차와 도구 보단 개성과 상호 협력,
포괄적 문서보다 동작하는 소프트웨어,
계약, 협상보다 고객과의 협력,
계획 준수보다 변화에 대한 대응
스크럼 프로세스
- 역할의 공유
제품 책임자(제품 백로그) -> 개발팀(스프린트 백로그) -> 일일 스크럼 회의, 스프린트 -> 검토 및 회고
1. 프로젝트 비전 수립
- 프로젝트를 통해 달성하고자 하는 구체적인 것
-> 이해 관계자의 의사결정 기반, 프로젝트 방향성
- 개방, 공유, 참여 (모든 이해 관계자)
-> 추상적 표현 지양(구체적, 정량적), 누가 구매하는가(목표 대상 고객), 고객이 원하는 것은?,
고객에게 가치를 전달하는 제품, 경쟁 제품 대비 고객에게 선호받는 차별적인 특징 등을 회의
2. 비즈니스 목적 설정
- 비즈니스 목적(상업적/공공 이익)과 프로젝트 요구사항 간의 연결 관계 표현
-> 수치와 기간 정보를 명시하여 구체적이고 정량적으로 기술
3. 제품 백로그
- 제품의 기능, 개발 업무 목록
-> 프로젝트 기간 동안 지속적으로 수정 및 조정
-> 제품의 기능적, 성능적 측면
-> 기술적/ 관리적 업무, 개선 사항, 오류 수정 등
- 누구나 제안 가능
- 제품 책임자가 지속적으로 관리
-> 우선순위 부여(고객 피드백 반영, 성능, 보안, 안정성 고려)
4. 스토리(제품 백로그) 포인트 추정
- 사용자 스토리(고객의 요구사항/기능)에 부여
- 스토리를 구현하는데 소용되는 상대적인 노력, 개발 복잡도, 내재된 위험성(개발팀 역량에 의존)
- Planning poker
-> 사용자 스토리 선정 -> 스토리 설명(제품 책임자, 고객) -> 질문, 토론 -> 추정치 제시(참여자) ->
최고/최저 추정치 참여자 설명 -> 새로운 추정치 제시 -> 의견의 수렴될 때까지 반복(3회 이내에 수렴 않되면 평균치로 추정)
- 스토리가 크면(분확실성 증가) 스토리 분할
5. 배포 계획
- 전체 일정 계획
-> 제품 백로그의 사용자 스토리 대상
-> 반복 주기(스프린트) x 반복 횟수
-> 전체 스토리 포인트 / 개발 속도
개발 속도 : 한 스프린트의 스토리 포인트 합계
프로젝트 기간 동안 지속적으로 변경 및 조정
6. 스프린트 계획
단기 일정 계획 : 하나의 스프린트 계획
- 스프린트 목표 및 백로그 작성
-> 스토리를 태스크로 분할하여 작업 시간 추정
-> 스토리 : 사용자 관점의 제품 기능
-> 태스크 : 개발자 관점의 작업 단위(1~4시간)
- 하나의 스토리를 여러 명이 개발(공유, 전문성)
- 스크럼 마스터가 주관(제품 책임자, 개발팀)
7. 일일 스크럼 회의
- 개발팀 공유 회의(정해진 장소에서 15분 이내, 어제 한 것, 오늘 할 것, 문제점)
- 스크림 마스터 주관(소멸 차트 갱신, 변화 관리)
8. 스프린트 검토
- 제품 증분 시연 : 고객의 평가 및 피드백, 제품 백로그 갱신,추가, 우선순위 조정(제품 책임자)
- 스프린트 회고 : 잘된 점, 잘못된점, 개선사항, 결심, 경험주의적 변화 관리(능동적 적응)
위험 기반 소프트웨어 개발
-> 안전성 필수 : 시스템의 기능 안전성 확보 -> 오작동 시 인명, 재산, 환경 피해( ex) 원자력 발전, 의료기기 )
국제 표준 제정 : ex) ISO 26262
UML
대표적인 시스템 모델링 언어(unified modeling language)
- 시스템을 상호작용하는 객체들로 모델링
- 분석 모델, 설계 모델이 동일
다이어 그램의 종류
- 행위 다이어그램 : 활동, 상태 머신, 유스케이프
- 구조 다이어그램 : 클래스, 객체, 복합체 구조, 배치, 컴포넌트, 패키지
- 상호작용 다이어그램 : 순차, 상호작용 개요, 통신, 타이밍
유스케이프 다이어그램
- 사용자 관점에서 시스템 사용 목적 기술
-> 목적 달성을 위한 사용자와 시스템 간의 상호작용
-> 시스템 기능, 서비스 정의, 시스템의 범위 결정
- 흐름도가 아니다.
- 구성요소 : 액터, 유스케이스, 관계 / 시스템 범위 : 시스템 내부의 유스케이프와 시스템 외부 환경 구분
액터 : 시스템과 상호작용하는 외부 개체
- 사람 : 막대 인간 모양(사용자, 관리자 등)
- 외부 시스템 : 박스 내에 <actor>로 표시 (인증 시스템 ,은행 시스템)
- 주액터 : 목적 달성을 위해 시스템의 서비스가 필요한 액터
- 부액터 : 주 액터의 목적 달성을 위해 시스템에 서비스를 제공하는 외부 개체
유스케이프 : 액터와 시스템 간에 수행하는 일련의 상호작용
- 요구사항 만족을 위해 시스템이 제공하는 기능 (시스템 구동/종료, 사용자 인증, 계좌 조회,이체 등)
- 상호작용의 목적을 단순명료하게 기술한 이름 (타원형으로 표시)
관계
- 액터-유스케이스 간의 관계
-> 유스케이스 목적 달성을 위해 액터가 시스템과 상호작용할 때 발생, 실선으로 연결
유스케이스-유스케이스 간의 관계
- 포함 관계 (선행->후속) : 필수적 수행
- 확장 관계 (특정한 조건) : 선택적 수행
- 일반화 관계 (그룹) : 보편적<-구체적
액터 식별 : 사용자, 관리자, 인증 시스템, 은행 시스템 등
액터별 유스케이스(기능/서비스) 식별
- 관리자 : 시스템 구동/종료, 인증
- 사용자 : 계좌 조회/이체, 트랜잭션
관계 식별
- 액터-유스케이스 : 관리자-시스템 구동/종료, 사용자-계좌 조회/이체
- 유스케이스-유스케이스 : 포함 관계, 일반화 관계
정리, 조정작업
유스케이스 실행순서 : 액티비티 다이어그램
클래스 다이어그램 (시스템의 정적 구조)
- 시스템을 구성하는 클래스와 그들 간의 관계 표현
- 속성과 연산의 접근 제어자 +(public) -(private) #(protected) ~(package)
- 속성의 표현 (static은 밑줄) [+|-|#|~]이름 : 타입[다중성 정보][=초기값]
- 연산의 표현 (static은 밑줄) [+|-|#|~]이름(인자1:타입1,...,인자n:타입n):반환 타입
제약 조건 : {}또는 노트 심볼 이용
다중성 : 1: 1개의 객체, 0..*(=*) : 0또는 그 이상의 객체, 1,3..5 : 1개 또는 3~5개의 객체가 연관
클래스의 관계 : 연관, 일반화, 실제화, 집합, 의존 관계
- 클래스의 연관 관계
연관 클래스 : 연관 관계에 속성 추가
한 클래스에서 다른 클래스를 사용하는 경우 (클래스의 속성에서 참조, 연산의 인자/지역변수로 참조)
- 클래스의 일반화 관계
기반 클래스와 파생 클래스 간의 is-a-kind-of 관계 (파생 클래스들의 공통 클래스)
- 클래스 실체화 관계
인터페이스와 상속 클래스 간의 관계 can do this 관계
- 클래스 집합 관계
전체와 부분 간의 관계
1) 집약 : 한 객체가 다른 객체를 포함, 생명 주기가 서로 독립적, 부분 객체는 다른 객체와 공유 가능
2) 합성 : 부분 객체가 전체 객체의 생명 주기에 종속, 전체 객체가 소멸되면 부분 객체도 소멸
- 클래스 의존 관계
일시적 연관 관계 : 서비스를 이용할 때마다 서비스 제공 객체가 변동, 연산의 인자/지역변수로 참조
ex) 사람-자동차 : 연관(지속적 서비스 제공), 자동차-주유소 : 의존(일시적 서비스 제공)
클래스 다이어그램 작성 : 유스케이스 기술서 등의 문서에서 명사 추출
- 클래수 후보 : 사물, 역할, 조직/구조체, 장소, 트랜잭션, 외부 시스템/장치
- 제외 대상 : 시스템 전체, 중복, 모호함, 지나치게 상세, 속성, 값, 연산
클래스 간의 논리적 관계 조사
- 객체 간의 상호작용 분석
패키지 다이어그램
패키지 : 관련 있는 모델 요소의 그룹화
- 패키지 내에 다른 패키지 포함 가능
- 구성 요소는 하나의 패키지에만 포함됨
- 패키지는 하나의 네임 스페이스로 구성
- 패키지 제거 시 패키지 내의 모델 요소도 제거됨
패키지 의존 관계
- ex) B 패키지 없이 A패키지 단독 재사용 불가능, B패키지 변경은 A패키지에 영향을 줄 수 있음
패키지 설계의 일반 원칙
- 응집도를 높이고 결합도를 낮춘다.
응집도 : 패키지 내 클래스의 목적 수행 정도
결합도 : 패키지 간의 상호 의존 정도
패키지 설계 원칙 1 : 응집도 증가
- REP 재사용 릴리즈 등가 원칙 : 재사용 릴리즈 단위는 패키지
- CRP 공통 재사용 원칙 : 패키지 내의 클래스는 함께 재사용, 패키지 내의 일부 클래스의 분리,제거 불가
- CCP 공통 폐쇄 원칙 : 패키지 변경 필요 시 패키지 내의 클래스만 변경
패키지 설계 원칙 2 : 결합도 감소
- ADP 의존 비순환 원칙 : 패키지의 의존 관계는 비순환되도록
- SDP 안정적(변경이 곤란한) 의존 원칙 : 자신보다 안정적인 패키지로 의존 관계 구성
-> 도입 결합도 Ca : 패키지에 의존되는 클래스 수
-> 도출 결합도 Ce : 패키지가 의존하는 클래스 수
-> 비안정성 요소 : I = Ce/(Ce+Ca)
- SAP 안정적 추상(확장이 용이한)원칙
-> 안정된 패키지는 추상 클래스나 인터페이스로 구성
순차 다이어그램
- 서비스 제공 과정 표현 모델
- 서비스 객체 정의 : 객체 간 메세지 송수신 과정을 시간 순서에 따라 정의
-> 객체명 : 클래스명 형식으로 맨 위에 객체 표시
-> 왼쪽에서 오른쪽으로 객체 나열
- 객체 간의 송수신 메세지 형식
-> [시퀀스 번호][가드] : 리턴 값 := 메세지명(인자...)
-> 위에서 아래방향으로 시간 진행
-> 가드 : 메세지 송신 조건
프레임 : 다이어그램을 특정하는 wrapper
- 왼쪽 위 모서리에 다이어그램 타입과 이름 기입
-> sd(순차), ud(유스케이스), cd(클래스)
- 다이어그램 외부에서 ref 키워드로 참조 가능
-> 객체 간의 상호작용을 효율적으로 표현
-> 결합 프래그먼트로 반복 조건 명시 : 조건opt, 택일alt ,병행par, 참조ref
객체지향 개발 프로세스
요구사항
JRP 등을 이용하여 이해 관련자로 부터 수집, 용어집으로 용어 표준화
- 기능적 요구사항 : 유스케이스 다이어그램 (문제 해결을 위해 시스템이 제공해야 할 서비스)
- 비기능적 요구사항 : 부가사항 명세서 (시스템 품질/제약사항)
요구사항 검증 기준
- 명확성, 완전성, 일관성, 추적 가능성, 검증 가능성,
분석
- 개발자 관점에서 유스케이스 실체화 (클래스 다이어그램, 순차 다이어그램)
- 설계, 구현 기술/방식을 감안하지 않음
설계
- UI/영속성 드을 고려하여 기존 클래스 보완
- 기능, 품질 속성을 고려하여 아키텍처 설계
- 외부 자원/오픈 소스 등 활용
- 아키텍처 스타일 (계층, 파이프&필터, 블랙보드, MVC)
설계2
계층 : 수행하는 책임/관심에 따라 계층으로 나누어 설계
- 계층 내에서는 협업, 계층 간 결합도 최소화
- 서비스 제공 관계 : 하위 -> 상위 계층
3계층 아키텍처(PL>BLL>DAL)
- 프레젠테이션 계층(UI) : 화면 조작 및 입출력
- 비즈니스 로직 계층(BLL) : 애플리케이션 로직 실행, 비즈니스 도메인 기능
- 데이터 접근 계층 (DAL) : 비즈니스 로직 수행에 필요한 정보 조회, 저장
설계3
파이프&필터
- 필터 : 시스템을 구성하는 컴포넌트 : 입력 데이터 받아 출력 데이터 생성(변환기)
- 파이프 : 필터간의 연결 관계 : 이전 필터 출력을 다음 필터 입력으로 전달
- 필터 설계시 고려사항 : 필터 상호 간에 상태정보 공유x, 현재 필터는 앞뒤 필터에 대한 정보x
-> 병렬적으로 수행, 파이프를 통해 동기화
설계4
블랙보드 : 시스템의 현재 상태를 저장하는 중앙 자료 저장소
- 컴포넌트 간에는 블랙보드를 통해 상호작용(컴포넌트 간 결합도 낮음) -> 재사용/추가 용이
- 자료 저장소 상태 변화 시 모든 컴포넌트에 알림 (자료 저장소와 컴포넌트 간의 결합도는 높다)
설계5
MVC(모델-뷰-컨트롤러)
- 모델 : 데이터와 기능 제공
- 뷰 : UI, 모델로부터 입력 받아 화면 표시
- 컨트롤러 : 사용자/ 시스템과 상호작용 (모델 생성, 뷰 순정)
- 모델과 뷰 간의 결합관계 약화(MVC의 효과)
티어 : 물리적인 배치 단위
1티어 아키텍처 : 손쉬운 구성<->확장성,이식성 결여
2티어 아키텍처 : DB server 공유<->성능부하
3티어 아키텍처 : 보안,성능,확장성 우수 (WAS 웹 애플리케이션 서버)
-> tier에 load balancer를 설치하여 여러 개의 서버 운영 (가용성 향상)
구현
설계를 바탕으로 소프트웨어 구현, 프로그래밍 언어를 이용한 실체화
의존성 주입과 IoC
클래스 간의 의존관계
- 한 클래스가 실행할 때 다른 클래스의 서비스 필요
- 서비스를 다른 클래스로 변경해도 높은 결합도를 유지해야함
의존성 주입이 필요하다(인터페이스를 이용하면 결합도가 낮다)
- 이용할 객체를 속성에 설정(주입)
-> 직접 객체 생성및 주입 : 생성자/setter를 통한 의존성 주입
-> 프레임워크에서 객체 생성,주입(IoC) ex) Google Guice, Spring 프레임워크
Spring 프레임워크를 이용한 의존성 주입
- DI컨테이너가 @Autowired 멤버변수에 대해@Component이 선언된 클래스 중에 해당 타입 클래스를 찾아 객체 주입
-> byType방법(클래스 이름), Bean 정의에서 클래스 스캔 범위 지정
- DI 컨테이너(객체 사이의 의존관계 주입 가능)
-> 클래스의 인스턴스화(객체 생성)기능 : singleton 효과(객체 수명주기 관리), 컴포넌트화(클래스 간의 독립성)
5가지 설계 원칙
SRP : 클래스는 하나의 작업만 함
OCP : 기존 코드 변경없이 새로운 기능 추가 (캡슐화)
LSP : 기반 클래스와 파생 클래스에서 제공하는 연산은 일관성이 있어야함
ISP : 클래스에 특호된 인터페이스로 분리(객체 지향 설계 원칙)
- 어떤 클래스가 다른 클래스에 의존 시 최소한의 인터페이스 사용
DIP : 의존관계는 가변적인 것보다 불변적인 것으로 설정(가변 : 구체적 사물, 불변 : 추상적 개념)
ex) 사람->개 사람->고양이 보다는 사람->애완동물(추상적)
소프트웨어 테스트
- 정적 테스팅 : 오류 발견 및 방지 목적으로 프로그램,문서 분석과정
- 동적 테스팅 : 오류를 발견하기 위해 프로그램 실행, 품질 평가 및 향상을 위해 프로그램 실행
JUnit : 단위 테스트 프레임워크
- 자바 프로그램의 단위 테스트 프레임워크
-> 애너테이션으로 쉽고 간결한 테스트 코드, 테스트를 위해 코드에 출력문 삽입할 필요 없음
@BEFORE(준비) -> @Test(동작,확인) -> @After(해체 종료) //@Test가 많으면 순서를 바꿔가며 테스팅
동일 패키지에 애플리케이션 코드, 테스트 코드 생성 -> protected 메서드도 테스트 가능
애플리케이션, 테스트 코드가 생성된 폴더는 다르다 -> 애플리케이션 코드 분리하여 배포하기 용이
Run As > JUnit Test로 테스트 코드 실행
- Failure : 테스트 코드의 단정문이 실패한 경우
- Error : 테스트 코드를 실행할 때 전혀 예기치 않은 곳에서 예외 발생
@BeforeClass, @AfterClass는 최초/최후 1회만 실행
블랙박스 테스트 : 명세기반테스트
- 명세에 따른 올바른 구현여부 테스트
명세 정보 등을 이용하여 테스트 케이스 설계
- 요구사항분석/ 시스템 인터페이스/ UI명세
-> 원시코드 정보x, 사용자 입장에서 테스트 케이스 설계 가능
- 개발 초기 단계부터 테스트 케이스 설계 가능
-> 단위, 통합, 시스템, 인수 테스트 전 과정에 사용
- 동일 명세로 구현된 여러 시스템에 재사용 가능
- 기능 오류/ 명세 오류 검출
동등 클래스 분할 (동치류 분할)
- 입력 영역을 여러 동치류로 분할하여 대표 값 선정 -> 테스트 개수 감소
-> 대표 값이 오류 발생시 대표 값의 동치류도 오류 발생
동등 클래스 수행 절차
1. 명세로 부터 입력 인자 식별
2. 입력 인자를 동치류로 분할
3. 각 동치류를 적절한 조합 연산자를 이용하여 조합
4. 불가능한 조합 점검 및 제거
5. 조합된 클래스의 대표 값 선정, 테스트 케이스에 반영
경계 값 분석 : 입력 영역의 경계에서 오류 발생 경향
- 동치류의 경계 값으로 테스트 케이스 선정
- 도메인 오류 검출에 효과적
-> 도메인 오류 : 올바른 경로가 아닌 잘못된 경로 실행
-> 계산 오류 : 올바른 경로지만 잘못된 계산(로직) 실행
- 도메인 테스트의 가장 간단한 형태
BVA 수행 절차
1. 명세로부터 입력 인자 식별
2. 입력 인자를 동치류로 분할 -> 경계 값 추출 (최소 경계 min- min+, 최대 경계 max- max+ 조합)
3. 각 경계 값을 적절한 조합 연산자를 이용하여 조합
-> 최종 조합에 여역 내부 값 1개 추가 -> n개 입력 인자 : 4n+1 테스트 케이스 생성
4. 불가능한 조합 점검 및 제거
5. 조합된 클래스의 대표 값 선정, 테스트 케이스에 반영
동등 클래스 분할과 경계 값 분석의 문제 : 입력 인자간 관게 고려x 입력 범위만 고려
- 입력 인자간 관계가 있는 테스트 케이스 : 테스트 케이스가 많아진다.
도메인 테스트
- 입력 인자간 관계를 고려하여 경계 값 테스트를 구한다.(입력 인자들이 구성하는 영역의 경계 분석)
도메인 테스트 용어
- on 포인트 : 경계에 있는 값
- off 포인트 : 경계에 있지 않은 값
- in 포인트 : 경계 조건을 만족하고 경계에 있지 않는 값
- out 포인트 : 경계 조건을 만족하지 않고 경계에 있지 않을 값
AII Combination은 테스트 케이스가 너무 많고 Each Choice는 유용한 테스트 케이스 누락 가능
-> 페어와이즈 테스트 : 입력 인자 쌍의 모든 짝을 조합하여 테스트
페어와이즈 조합 생성 방법
1. 직교 배열 방법
2. IPO 방법 : P1, P2로 이루어진 모든 조합 구성 : 입력 인자를 하나씩 추가하며 테스트 케이스 추가
-> 수평확장 (새로운 입력 인자 추가), 수직확장 (테스트 케이스 추가) 반복
ex) A,B,C 입력인자가 있으면 A,B의 모든 조합 구성 이후 A,C 조합 구성, B,C 조합 구성
3. 입력 인자 C 수평확장 - (A,C),(B,C)쌍에서 삭제 -> t1,t2,t3,.... 남은 쌍 없을 때까지 확장
기반 선정 조합 테스트
- 기반이 되는 테스트 조합을 미리 선정(기반 조합)
-> 사용자 관점에서 선택 빈도가 가장 높고, 선택 빈도가 높으며, 단순, 정상 동작 가능
- 선정된 기반 조합에서 하나의 인자 값만 변경, 나머지 인자 값을 고정하여 기반 선정 조합 테스트 케이스 생성
다중 기반 선정 조합 테스트
- 기반 조합이 2이상인 기반 선정 조합 테스트
'학교수업' 카테고리의 다른 글
데이터베이스 6주차 (0) | 2022.10.18 |
---|---|
데이터베이스 5주차 (0) | 2022.10.17 |
컴퓨터그래픽스 5주차 (0) | 2022.10.05 |
컴퓨터 그래픽스 4주차 (0) | 2022.09.28 |
모바일 프로그래밍 4주차 (0) | 2022.09.27 |