[소프트웨어공학] 기말고사 정리

동적모델링

시스템의 기능을 만족하기 위해 각 빌딩 블록이 어떻게 상호작용하는지를 표현

유스케이스로 표현된 기능을 만족하기 위해 시스템 내부의 구성요소들이 어떻게 협력하는지를 나타냄

 

동적 모델을 표현하기 위한 UML 다이어그램

1. 시퀀스 다이어그램

    시스템의 동적인 행위에 대해 유스케이스 단위로 객체들 간의 메시지 교환과 상호작용을 나타냄

2. 상태 다이어그램

    클래스의 동적인 측면을 표현, 오퍼레이션에 의한 상태 변화를 표현

 

시퀀스 다이어그램

시스템의 동작 과정을 시각화 하는데 도움

유스케이스의 각 task를 수행하기 위해 객체들이 메시지를 교환하는 순서를 나타냄

usecase realization이 구체적으로 시각화 된 것

 

시퀀스 다이어그램의 요소

1. 객체(클래스의 인스턴스)

object name : class name

박스 안에 클래스 이름, 객체 식별자를 명시하고 밑줄

2. 액터

3. 메시지

 

객체는 다이어그램에 수평으로 정렬됨

액터는 가장 왼쪽에 표시

수직 축은 시간의 흐름을 나타냄

객체마다 라이프라인이라 불리는 수직 점선을 붙임

activation box : 객체의 활성화를 표현

메시지로 인해 객체가 생성되는 경우, 높이를 낮게 표현

메시지 : method call or signal 전달

 

시퀀스 다이어그램 예시

객체가 소멸된 후에는 라이프 라인이 중지되며, X로 표시

prereq := 받아올 값

[hasPrerequisite] 조건

<<create>> 객체 생성

 

Combined fragments and operators

opt와 alt를 이용한 분기

opt는 if에 해당

opt는 바로 옆에 [조건]

 

alt는 if-else if-else문에 해당

실행문 위에 [조건]

 

loop and break

loop min, max [condition] : 조건을 만족하지 않으면 min번, 조건을 만족하면 max번 반복

loop [condition] : break전까지 계속 반복

 

상태 다이어그램

시스템 전체, 시스템의 일부, 개별 객체에 대한 동작을 기술하기 위한 목적

상태 : 둥근 사각형 안에 상태 이름

검은 원 : 시작 상태

원에 둘러쌓인 검은 원 : 종료 상태

 

트랜지션

즉시 일어남이 원칙

트랜지션 위에는 상태 변화를 일으키는 이벤트를 표시

- 조건 표시 트랜지션

 

액티비티

- 액티비티가 완료되면 어떤 상태에서 빠져나오는 트랜지션이 발생

- 일정 시간이 소요됨

 

액티비티 인터럽트

- 액티비티가 완료되기 이전에 다른 트랜지션이 먼저 트리거 될 경우 발생

- 액티비티를 중단하고 그 상태에서 빠져나옴

- 상태에 진입했을 대 무엇을 수행할 것인지 표현

액션

- 시간 경과 없이 즉시 일어날 수 있는 동작

- 감지할 수 없는 적은 시간을 소비

- 특정 트랜지션이 이루어질 때

- 특정 상태로 진입할 때

- 특정 상태에서 빠져나올 때

Enter/action 또는 Exit/action

Event/action

상태 다이어그램이 상태 안에 내장될 수 있음

 

시퀀스 다이어그램 작성

하나의 순서화된 시나리오를 기반으로 하나의 시퀀스 다이어그램 작성

 

상태 다이어그램 작성

시퀀스 다이어그램에서 시작

입력이벤트 -> 상태 전이

선행자가 없는 상태 => 시작 지점

후행자가 없는 상태 => 종료 지점

레이스 조건 주의

 

응집력, 응집도(Cohesion) 100% 나옴

한 모듈 내에서

1. 기능적 응집도

    특정 결과를 계산하기 위한 코드만이 모여 있고 나머지는 배제

    이해하기 쉬움(단일 기능, 외부에 영향을 미치지 않음)

    재사용하기 쉬움

    대체하기 쉬움

2. 계층적 응집도

    연관되는 서비스를 제공하거나 접근하는 기능들을 같은 수준의 계층에 모아놓고 그 이외의 것은 배제

    상위 층은 하위 층의 서비스에 접근

    하위 층은 상위 층에 접근 불가

    프로시저의 집합을 API라고 함

    다른 층에 영향을 주지 않고 층을 대체할 수 있다.(API복제)

3. 순차적 응집도

    한 프로시저의 출력이 다음 프로시저의 입력이 될 때 이들을 함께 두고 나머지는 배제

    Data, Control에 의해 묶임

4. 교환적 응집도

    특정 데이터에 접근하거나 조작하는 요소는 같이 두고 그 이외의 것은 배제

    데이터에 대한 변경을 수행할 필요가 있을 때, 한 곳에서 관련된 모든 코드를 찾을 수 있음

5. 절차적 응집도

    차례로 수행되는 프로시저를 모아 놓은 경우

    순차적 응집도는 데이터 및 제어에 의해 묶이지만, 절차적 응집도는 Control에 의해서만 묶임

6. 시간적 응집도

    프로그램의 수행에서 같은 시점에 수행될 연산들을 같이 두고 나머지는 배제

    시스템의 시작이나 초기화 기간 동안에 사용되는 코드들을 같이 모아둠

7. 실용적 응집도

    논리적으로 다른 응집 단위에 배치될 수 없는 관련 유틸리티들을 함께 두는 경우

    다른 많은 서브시스템에 널리 활용되는, 재사용을 위해 설계된 프로시저나 클래스

    ex) java.lang.Math class

 

결합력, 결합도(Coupling)

두 모듈 사이에 의존관계가 있을 때 발생

1. 내용 결합도

    한 컴포넌트가 다른 컴포넌트의 내부 데이터를 비밀리에 수정하는 경우

    내용 결합을 피하기 위해 모든 인스턴스 변수를 캡슐화

    변수를 private로 선언, getter, setter함수 제공

2. 공통 결합도

    전역변수를 사용할 때 항상 발생

    전역변수를 사용하는 모든 모듈은 전역변수를 선언한 모듈과 결합됨

    singleton 패턴은 객체에 캡슐화된 전역변수를 제공

3. 제어 결합도

    프로시저가 플래그나 커맨드를 사용하여 다른 프로시저를 호출하여 제어하려는 경우 발생

    변경하려면 호출하는 메소드와 호출되는 메소드 모두를 변경하여야 함

    다형성을 사용하여 해결

    제어 결합을 감소시키기 위해 lookup 테이블 이용

4. 스탬프 결합도

    응용 클래스들 중 하나가 메소드 매개변수의 타입으로 선언될 경우

    다른 클래스를 매개변수로 사용하기 때문에 시스템의 변경이 쉽지 않다.

    인터페이스를 매개변수 타입으로 사용

    단순 변수를 전달

5. 자료 결합도

    메소드의 매개변수 타입이 기본 자료형이거나 단순한 라이브러리 클래스인 경우

    메소드의 매개변수가 많으면 많을수록 결합도는 높아짐

    불필요한 매개변수를 줄여서 결합도를 낮춘다.

    자료 결합과 스탬프 결합은 trade-off 관계인데,

    3~4 매개변수인 경우는 자료결합, 4개 이상의 매개변수인 경우에는 스탬프 결합을 사용하는 것이 좋다.

6. 루틴 호출 결합도

    하나의 루틴이 다른 루틴을 호출할 때 결합이 발생

7. 타입 사용 결합도

    어떤 모듈이 다른 모듈에서 정의한 자료형을 사용할 때 발생

    타입의 정의가 바뀐다면 타입을 사용하는 쪽도 영향을 받음

    항상 변수의 타입을 선언할 때는 요구되는 오퍼레이션을 포함하는 가장 일반적인 클래스나 인터페이스를 이용

8. 포함 결합도

    컴포넌트가 패키지를 import 또는 다른 파일을 include하는 경우

    imported 컴포넌트 안의 요소와 상충될 경우 importing 컴포넌트의 변경

9. 외부 결합도

    어떤 모듈이 운영체제, 공유 라이브러리, 하드웨어 등에 의존하는 경우

    퍼싸드 패턴으로 외부 결합을 줄일 수 있음

 

아키텍처 패턴

1. 계층구조 스타일

각 서브시스템이 하나의 계층이 되어 하위층이 제공하는 서비스를 사용

하나의 계층은 바로 아래 계층과만 커뮤니케이션(API를 이용하여 상호작용)

복잡한 시스템은 추상 수준을 높이며 층을 포개어 구성할 수 있음

하위층은 공통적 / 일반적인 서비스를 제공

 

2. 클라이언트-서버 스타일

서버 : 연결을 기다리고 처리해주는 역할

클라이언트 : 서비스를 제공 받으려고 연결을 시도하는 하나 이상의 컴포넌트

Peer-to-peer 스타일

- 클라이언트-서버 스타일의 확장된 형태

- 여러 호스트에 분산되어 있는 여러 소프트웨어 컴포넌트로 구성됨

 

3. 브로커 스타일

여러 다른 노드에 소프트웨어 시스템을 투명하게 분산할 수 있음

객체가 어디에 위치하는지 알 필요 없이 원격 객체의 메소드를 호출할 수 있음

 

4. 트랜잭션 처리 스타일

연속적인 입력을 하나씩 읽어 트랜잭션으로 명시

각 트랜잭션에 대해 무엇을 할 것인지 결정한 다음, 그 트랜잭션을 처리할 수 있는 컴포넌트에 배정

배정하는 역할을 수행하는 트랜잭션 dispatcher

 

5. 파이프 필터 스타일

비교적 단순한 형태의 데이터 스트림이 프로세스에 차례로 전달되어 처리되는 구조

입력 데이터를 가공 또는 특정한 형태로 변환시키는 filter 존재

프로세스는 병렬적으로 실행 가능

 

6. MVC 스타일

Model, View, Controller로 분리

Model : 내용, View : 표현, Controller : 상호작용을 제어

 

클래스 설계 원칙

1. 단일 책임의 원칙

클래스는 한 가지 종류의 책임만을 가져야 한다.

loose coupling, high cohesion을 실현

설계 수정 및 교체 등의 작업, 유지보수 작업을 용이하게 함

설계 시간이 다소 길어짐

2. 개방 폐쇄의 원칙

확장에 대해서는 open, 변경에 대해서는 close

모듈 자체를 변경하지 않고도 그 모듈을 둘러싼 환경을 바꿀 수 있어야 한다는 의미

변하는 것과 변하지 않는 것을 엄격히 구분

이 두 모듈이 만나는 지점에 인터페이스를 정의

3. 인터페이스 분리의 원칙

클라이언트는 자신이 사용하지 않는 메소드와 의존 관계를 갖지 않아야 한다.

여러 개의 클라이언트가 어떤 클래스만 이용하는 경우

- 각 클라이언트가 해당 클래스의 특정 부분만을 이용

적용규칙

클라이언트에게 딱 필요한 메소드만 있는 인터페이스를 제공한다.

4. 리스코프 교체 원칙

자식 타입은 언제나 부모 타입을 대체할 수 있어야 함

개방-폐쇄 원칙의 기반이 됨

부모 클래스 사용자가 자식 클래스를 부모 클래스로써 사용할 때

- 원래 부모 클래스를 사용하는 것처럼 그대로 사용할 수 있어야 함

- instanceof나 downcast를 할 필요가 없어야 함

5. 의존 관계 역전의 원칙

클라이언트는 구체적 클래스가 아닌 인터페이스나 추상 클래스에 의존해야 함

구체적 클래스는 변화 가능성이 많지만

추상 클래스나 인터페이스는 상대적으로 변화 가능성이 적기 때문

- 상위 단계의 모듈은 하위 단계에 의존하지 않아야 함

- 추상적인 것이 구체적인 것에 의존하지 않아야 함

 

디자인패턴

1. 기본 패턴(아래 3개 패턴에 포함되지 않는)

2. 생성 패턴

3. 구조 패턴

4. 행위 패턴

 

각 패턴들이 갖는 목적, 사례를 잘 이해해야 함.
구성, 구조에 대해서도 알아야 함.

 

기본 패턴

1. 개념 실체 패턴 : 각 객체의 공통 정보 공유

- 개념클래스 : 공통 정보를 담는 클래스

- 실체 : 공통된 정보를 가진 멤버

- 개념 클래스와 실체 클래스를 분리하는 이유 : 중복되는 정보를 저장하지 않기 위해

 

2. 플레이어 역할 패턴 : 하나의 클래스에 다양한 역할 표현

- 플레이어가 환경에 따라 다른 역할을 해야 하는 경우

- 여러 다른 역할을 하는 클래스 생성

- 이를 각 역할의 집합에 대한 슈퍼 클래스와 연관 관계 형성

 

3. 위임 패턴 : 다른 클래스의 오퍼레이션에 작업을 요청

- 위임 받는 클래스와 연관 관계가 필수

- 상속보다 연관을 통해 효과적으로 재사용 가능(상속은 불필요한 정보도 함께 상속)

- 코드 중복을 피할 수 있음

- 연관으로 근접한 정보에만 접근

 

4. 계층 구조 패턴 : 계층 구조를 다룰 때 적용

 

생성 패턴

실행 시간에 객체의 다양한 버전을 생성

생성한 객체에 제한을 가함

1. 팩토리 패턴

- 객체 생성을 위해 인터페이스를 정의

- 어떤 클래스의 인스턴스를 생성할지에 대한 결정은 서브클래스에서 이루어지도록 생성의 책임을 미룸

    - 클래스 인스턴스를 다양한 형태의 객체로 반환

- 객체를 생성하는 코드를 별도의 클래스/메소드로 분리

베이스 클래스에 속하는 객체 중 하나가 필요한데,

자식 객체 중 어떤 것이 필요한지 실행 시간까지 알 수 없을 때 사용

 

2. 추상 팩토리 패턴

- 객체의 구체적인 클래스를 명시하지 않고서 그 객체와 연관되는 객체 그룹을 생성하는 인터페이스 제공

- 객체 그룹을 생성하거나 의존적인 관계의 객체를 생성할 때 객체 생성을 추상화 함

- 추상화를 통해 객체를 사용하는 모듈은 객체와 독립적으로 행동

 

팩토리 패턴과의 차이

- 팩토리 패턴의 개념을 사용

- 객체 그룹 생성 추상화(그룹 팩토리)

 

3. 프로토타입 패턴

- 객체를 사용할 때 다시 생성하지 않고 복사해서 사용

- 이미 생성된 인스턴스로부터 새로운 인스턴스를 생성

 

클론 메소드

데이터를 매개변수로 넘겨주면 원하는 형태의 객체를 생성

조금씩 다른 객체를 생성할 때 복제 후 간단히 변환하여 다른 객체 생성

 

4. 싱글턴 패턴

- 애플리케이션 전체에 인스턴스가 하나만 필요한 경우

- 오직 한 개의 객체만 존재해야 하므로 더이상 인스턴스를 생성하지 못하도록 안전하게 막아야 함

생성자를 private로 만들기

 

구조 패턴

더 큰 구조를 형성하기 위하여 클래스와 객체를 어떻게 구성하고 합성하는가?

인터페이스를 상속받아 구현하여 합성

새로운 기능을 구현하기 위해 객체를 구성하거나, 런타임에 객체 구조를 변경하여 유연성, 확장성을 높임

 

1. 컴포지트 패턴

- 객체의 트리를 나타내는데 사용

- 기본 클래스와 이를 포함하는 컨테이너 클래스를 재귀적인 형태로 표현

- 객체들의 집합을 다룰 때 유용

 

2. 데코레이터 패턴

- 런타임에 객체의 기능을 추가하기 위해 사용

- 객체 생성 없이 개별 객체에 데코레이터를 이용해 동작을 첨부

- 추가적인 동작을 첨부하기 위해서는 대상 객체를 원하는 기능을 가지고 있는 데코레이터에 파라미터로 전달

 

3. 어댑터 패턴

- 애플리케이션의 기능을 외부에서 필요한 형태로 수정하여 사용하기 위해 사용

- 원하는 인터페이스를 추상 클래스로 정의

- 이를 상속하는 어댑터 클래스를 만들고 이를 요구하는 기능을 가진 클래스(adaptee)와 메시지를 교환

- 기존의 클래스를 재사용하고 싶지만, 원하는 인터페이스와 맞지 않을 때

 

4. 퍼싸드 패턴(정문)

- 시스템을 구성하는 많은 기능의 간단한 입구 역할 제공

- 패키지 안의 여러 개의 클래스 중에서 특정 클래스를 인터페이스로 정의

- 외부에서 호출한 기능을 내부의 다른 클래스에 위임 형태로 전달

- 외부 클라이언트에게는 내부의 복잡한 내용을 감춤

 

5. 프록시 패턴(대리자)

- 시간이 오래 걸리는 객체를 좀 더 간단한 객체로 표현하여 그 객체가 필요할 때까지 생성을 지연

 

행위 패턴

- 객체 사이의 행위를 조직화하고 연합하는데 사용하는 패턴

- 클래스 사이의 책임과 협력에 대한 유형 제시

 

1. 옵저버 패턴

- 정보 제공자와 이용자 사이의 연관을 관리하는 패턴

- 정보 제공자의 변화 -> 이용 객체에 전달되어야 할 경우

- 특정 데이터나 객체를 감시하고 있다가 변화가 발생하면 이를 알리고

연관된 객체들이 적절한 작업을 실행

 

ConcreteObservable 클래스

- 상태 변화 발생 / 자신의 상태 변화 저장

- 상태 변화 통지 요청 : observable 클래스의 notifyObservers() 호출

Observable 클래스

- 상태 변화 통보 : Observer 인터페이스를 통해 ConcreteObserver 객체 안의 update 메소드 호출

 

2. 중재자 패턴

- 중재자 객체가 중간에서 객체 간의 변화나 메시지를 조정

- 다른 객체의 존재를 모르는 상태에서도 메시지를 주고 받을 수 있음

 

일반적인 구조

- Mediator(Colleague 객체들과 의사 소통에 필요한 인터페이스를 정의)

- ConcreteMediator(Colleague 객체들을 포함, 그들 간의 상호작용을 조정하여 협동 작업을 실현)

- Collegue classes(mediator 객체를 알고 있고 mediator 객체를 통해서만 상호작용을 수행)

장점

- 두 컴포넌트 간의 직접적인 의존관계 발생하지 않음

- 컴포넌트의 재사용성 증진

 

3. 책임 체인 패턴

- 사용자가 원하는 작업을 어떤 객체에게 맡길지 모를 때 그 작업을 다룰만한 객체들의 집합에 맡김

 

장점

- 메시지를 보내는 객체가 메시지를 받는 모든 객체를 다 알 필요가 없음

- 요구 요청 객체와 처리 객체 사이를 느슨하게 연결

 

4. 커맨드 패턴

- 객체 집단에서 처리를 담당할 객체를 직접 지정한 후 그 객체를 처리 박스에 요청하여 처리하는 패턴

- 타겟의 메소드를 직접 호출하는 대신 커맨드 인터페이스를 통해 타겟의 메소드를 호출(간접호출)

   - 유연성을 높이고, 명령을 취소할 때 필요한 커맨드 히스토리를 저장할 수 있음

 

5. 상태 패턴

- 객체의 상태에 따라 구체적인 행위가 달라지는 경우

- 프로그램 동작이 객체의 상태에 의존적일 때 상태를 객체화

- 상태를 객체로 만들고 상태 클래스 안에 정적 변수로 저장

- 위임 형태로 동작

   - 상태에 따라 특정 handleRequest() 메소드를 호출

 

장점

- 특정 상태에 종속적인 행위를 다른 상태와 분리

- 명확한 분리는 유지보수를 용이하게 함

- 상태 천이가 명시화

 

소프트웨어 테스트

Black Box 테스트 기법

- 내부를 알 수 없는 박스

- 테스트 대상 모듈M의 내용(논리 구조)을 볼 수 없다.

- 인터페이스를 통해 테스트 데이터를 입력하고 반환하는 방법을 이용

- 주어진 명세로부터 테스트 케이스 유도

 

테스트케이스 생성 방법

1. 동등 분할

   - 동치 클래스 결정

      - input space 또는 output space를 유한계의 상호 독립적인 집합으로 나눔

   - 테스트 케이스 선정

      - 각 등가 집합의 원소 중 대표값 하나를 선택하여 테스트 케이스로 선정

   - 유효한 입력 데이터 뿐만 아니라 유효하지 않은 입력 데이터에 대해서도 대표값 고르기

 

Test Driver

 - 바로 모듈 e를 독립된 환경에서 구동시켜줌

Test stub

 - 모듈 f를 흉내내주는 컴포넌트

 

IUT(implementation under test)

Test Driver - IUT 호출 + 다른 내용들(테스트 케이스를 읽어서 IUT에 전달)

 

2. 경계 값 분석

- 동등 분할의 경계부분에 해당되는 입력 값에서 결함이 발견될 확률이 경험적으로 높기 때문에

경계 값을 테스트케이스로 선택하는 기법

- 경계 값 : 해당 분할영역의 최소값과 최대값

   - 유효경계값 : 유효한 분할영역의 경계값

   - 비유효경계값 : 유효하지 않은 분할영역의 경계값

 

White Box 테스트 기법

- 소프트웨어나 시스템의 코드와 구조를 중심으로 테스팅 하는 것

- 커버리지 : 시스템 또는 소프트웨어의 구조가 테스트 스위트에 의해 테스트된 정도

 

1. 구문 테스팅과 커버리지

- 테스트 케이스에 의해 실행된 구문이 몇퍼센트인지 측정

- 적은 개수의 테스트 데이터로 100%를 쉽게 달성 가능, 보장성이 낮다.(오류 발견 가능성이 낮음)

- 포함관계가 더 큰 커버리지를 달성하면 저절로 달성

 

제어 흐름 그래프

하나의 실행문은 하나의 노드

실행문 간의 제어 흐름은 노드 간의 엣지로 표현

 

unreachable statement : 어떤 입력 값이 주어지더라도 결코 실행될수 없는 문장

t1케이스는 x가 -3, y가 -5

coverage : covered stmt / (total stmt - unreachable stmt)

 

2. 결정 테스팅과 커버리지

- 테스트 케이스에 의해 실행된 조건문 내의 결정 포인트가 몇 퍼센트인지 측정하고 평가

- 결정 포인트의 전체 조건식이 참, 거짓의 모든 값을 갖게 되어 모든 분기로 제어가 흐르면 커버됨

 

coverage = # of decision outcomes covered / total # of decision outcomes

 

3. 조건 테스팅과 커버리지

- 결정 포인트 내에 있는 각각의 개별조건식이 참과 거짓의 모든 값을 갖는지 테스트

- 조건 커버리지가 결정 커버리지를 포함하지는 않음

 

coverage = # of Boolean values of conditions covered / total # of Boolean values of conditions

 

4. 다중 조건 커버리지

- 결정 포인트 내에 있는 모든 개별 조건식의 모든 가능한 논리적인 조합을 고려

- 출시 전에 반드시 100% 결함을 제거해야 하는 제품 테스트에서 주로 사용됨

 

 

개발 단계를 기준으로 한 분류

1. 단위 테스트

- 화이트박스 테스트 이용

- 각 모듈의 인터페이스, 자료구조, 경계 조건, 제어 흐름/오류 처리 확인

2. 통합 테스트

- 모듈 통합 과정에서 수행하는 테스트

3. 시스템 테스트

- 기능 테스트

- 비기능 테스트(성능, 보안, 스트레스 등)

4. 인수 테스트

- 시스템이 고객의 요구대로 잘 작동하는지 고객과 함께 확인

- 알파 테스트

   - 개발 환경에서 진행, 개발팀의 감독 하에 사요아 또는 고객이 수행

- 베타 테스트

   - 사용자의 컴퓨터 환경, 실제 운영 환경에서 수행

 

 

대형 시스템 테스트 전략

빅뱅 테스트 : 전체 시스템을 하나의 단위로 테스트

점진적 테스트

- 하향식 테스트

   - 하부 기능은 stub에 의해 시뮬레이션 됨

   - 단점 : 스텁 작성 비용

- 상향식 테스트

   - 가장 낮은 수준의 sw부터 테스트

   - 하위 계층을 테스트하려면 드라이버 필요

- 샌드위치 테스트

   - 상향식 + 하향식

   - 스텁을 사용하여 사용자 인터페이스를 별도로 테스트

   - 드라이버를 사용하여 가장 낮은 레벨의 기능을 테스트

   - 전체 시스템이 통합되면, 최종 테스트 세트를 수행할 중간 계층만 남음

 

테스터에 따른 분류

- 개발자 테스트(sw개발자가 수행하는 테스트)

- 독립적인 테스트(3자 테스트, 별도의 그룹에 의해 수행됨)