소프트웨어공학 중간정리

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이상인 기반 선정 조합 테스트