21년 1회차
○ 사용자 스토리(user story)
○ 소규모 릴리즈(small release)
○ 짝 프로그래밍(pair programming)
○ 테스트 우선 개발(test-first development)
제시된 특징은 모두 익스트림 프로그래밍(XP)의 대표 실천 기법이다.
XP는 애자일 방법론으로, 사용자 스토리로 요구를 받고 짝 프로그래밍·테스트 우선 개발·리팩토링·소규모 릴리즈로 짧게 반복한다.
- COCOMO: 개발 방법론이 아니라 LOC 기반의 비용 추정 모델이다.
- 통합 프로세스(UP): 유스케이스 중심·아키텍처 중심의 반복적 프로세스로, 짝 프로그래밍·테스트 우선 개발을 핵심 실천으로 두지 않는다.
- 폭포수 모델: 단계를 순차로 진행하는 전통적 모델로, 소규모 릴리즈·리팩토링 같은 반복 실천과 거리가 멀다.
○ 하나의 데이터를 다양한 그래프로 보여 줄 수 있는 데스크탑 응용 프로그램 개발
○ 데이터베이스 연동 부분과 사용자 웹 화면 제공 부분으로 나눈 웹 기반 응용 프로그램 개발
데이터·제어·화면을 분리하는 구조는 MVC(Model-View-Controller) 패턴이다.
Model은 데이터 관리, View는 화면 표시, Controller는 사용자 상호작용 제어를 맡으므로 하나의 데이터를 여러 뷰(다양한 그래프)로 보여 줄 수 있고, 웹에서도 DB 연동부와 화면부를 나누기 좋다.
- 리포지토리: 여러 컴포넌트가 중앙 저장소의 데이터를 공유하는 구조로, 화면·제어 분리가 핵심이 아니다.
- 트랜잭션 처리: 사용자 요청을 트랜잭션 단위로 처리해 데이터베이스 일관성을 유지하는 구조이다.
- 파이프 필터: 데이터가 필터를 차례로 거치며 변환되는 데이터 흐름 구조이다.
개발에 소요되는 시간은 20개월이다.
개발 기간 = 총 LOC ÷ (개발자 수 × 1인당 월평균 생산성)으로 구한다.
(개월)
팀 전체의 월 생산량이 4,000 LOC이므로 80,000 LOC를 완성하는 데 20개월이 걸린다.
시스템 구조·서브시스템 구조는 설계 단계에서 다룰 내용이므로 요구분석 명세서의 특성으로 옳지 않다.
요구 명세는 시스템이 무엇을(what) 해야 하는지를 기술하고, 어떻게(how) 구현할지는 설계에서 정한다.
- 서로 모순되는 부분이 없어야 한다: 일관성(consistency)으로 바람직한 특성이다.
- 고객과 개발자가 동의한 것: 합의된 명세여야 개발·검증의 기준이 된다.
- 고객과 개발자 모두 쉽게 이해: 이해 용이성으로, 양측이 함께 검토할 수 있어야 한다.
클래스·컴포넌트의 종류와 관계에 초점을 두는 것은 유스케이스 관점이 아니라 논리(logical) 관점이다.
4+1 관점에서 유스케이스(시나리오) 관점은 나머지 네 관점을 하나로 묶어 주는 시스템 기능 시나리오를 기술한다.
- 배치(물리) 관점: 처리 장치 간 물리적 배치를 다룬다는 설명이 옳다.
- 프로세스 관점: 런타임에 상호작용하는 프로세스의 구성을 보여 준다는 설명이 옳다.
- 구현(개발) 관점: 서브시스템 모듈의 구조화에 관심을 둔다는 설명이 옳다.
Animal a; a = new Dog( ); a.makeSound( ); // “멍멍” 출력함 a = new Cat( ); a.makeSound( ); // “야옹” 출력함
같은 메시지로 객체에 따라 다른 구현이 호출되는 개념은 다형성이다.
Animal 타입 변수 a가 가리키는 실제 객체(Dog, Cat)에 따라 재정의된 makeSound()가 실행 시점에 결정된다(동적 바인딩).
- 정보 은닉: 내부 구현을 감추고 인터페이스만 공개하는 원칙이다.
- 정적 바인딩: 호출 대상을 컴파일 시점에 고정하므로 객체에 따라 다른 구현이 호출되지 않는다.
- 캡슐화: 데이터와 연산을 하나의 단위로 묶는 개념이다.
이 제어흐름 그래프의 순환 복잡도는 4이다.
순환 복잡도는 V(G) = E − N + 2로 구한다. 간선은 1→2, 1→3, 1→4, 4→3, 2→5, 5→2, 3→6, 5→6의 8개이고 노드는 6개이다.
분기 노드(1에서 세 갈래, 5에서 두 갈래)로 세어도 판단 수 + 1, 곧 (2 + 1) + 1 = 4로 같다.
- 복잡도 2는 노드 1의 세 갈래 분기만으로도 넘어서므로 작다.
- 복잡도 3은 5에서 2로 되돌아가는 반복 경로를 빠뜨린 값이다.
- 복잡도 5는 간선을 하나 더 세었거나 노드를 하나 덜 센 값이다.
‘추가이체’는 ‘계좌이체’에 <<extend>> 관계로 연결되어 있으므로, 계좌이체가 수행되면 추가이체도 수행된다는 설명이 옳지 않다.
extend는 기본 유스케이스에 특정 조건이 만족될 때만 선택적으로 덧붙는 확장 기능이고, include는 기본 유스케이스가 수행될 때 반드시 함께 수행되는 공통 기능이다.
- ‘해외이체’에서 ‘계좌이체’로 속이 빈 삼각형 화살표(일반화)가 이어지므로, 계좌이체가 해외이체보다 일반화된 유스케이스라는 설명은 옳다.
- 사용자 액터가 계좌조회·계좌이체·해외이체에 각각 연결되어 있으므로 세 유스케이스를 사용자가 수행한다는 설명은 옳다.
- 계좌조회와 계좌이체가 각각 <<include>>로 ‘인증’을 가리키므로, 인증이 두 유스케이스에 포함되어 수행된다는 설명은 옳다.
서버·클라이언트 구분 없이 모든 노드가 연산을 수행하는 비중앙집중 구조는 피어 투 피어(P2P) 아키텍처이다.
각 피어가 서비스 요청자이자 제공자 역할을 함께 하며, 중앙 서버 없는 파일 공유 네트워크가 대표 사례이다.
- 마이크로서비스: 시스템을 독립 배포 가능한 작은 서비스로 나누는 구조로, 서버·클라이언트 구분이 없어지는 것이 아니다.
- 분산 컴포넌트: 여러 노드에 컴포넌트를 분산 배치하고 미들웨어로 연결하는 구조이다.
- 서비스 지향: 서비스 제공자와 소비자가 표준 인터페이스로 서비스를 주고받는 구조이다.
abstract class Shape {
public void paint() { draw(); }
abstract public void draw();
}
abstract class Circle extends Shape {
public int radius;
public Circle(int radius) {
this.radius = radius; }
double getArea() {
return (3.14 * radius * radius); }
}
public class NamedCircle extends Circle {
String name;
public NamedCircle(int radius, String name) {
super(radius);
this.name = name;
}
public void draw() {
System.out.println("반지름이 " +
radius + "인 원을 그리다.");
}
public static void main(String[] args) {
Shape s;
s = new Shape();
NamedCircle w = new NamedCircle(5, "Ring");
System.out.println(w.getArea());
w.draw();
}
}오류가 나는 문장은 추상 클래스 Shape를 new로 생성하는 문장이다.
abstract 클래스는 구현되지 않은 메서드(draw)를 가지므로 직접 인스턴스화할 수 없다. 다만 추상 클래스 타입의 참조 변수 선언은 가능하다.
- super(radius): Circle에 int 매개변수 생성자가 있으므로 정상 호출이다.
- Shape s: 추상 클래스 타입 참조 변수 선언은 허용된다.
- w.getArea() 출력: NamedCircle이 Circle의 getArea()를 상속받으므로 정상이며, draw도 NamedCircle에서 구현되어 객체 생성이 가능하다.
코드 인스펙션은 프로그램을 실행하지 않고 검토하는 정적(static) 테스트이므로 동적 테스트라는 설명이 옳지 않다.
훈련된 검토자들이 체크리스트를 바탕으로 코드·문서를 읽어 결함을 찾는 공식 검토 기법이다.
- 품질 보증 활동: 결함을 조기에 발견하는 대표적 품질 보증 활동이다.
- 사전 문서 배포: 회의 전에 코드·분석·설계 문서를 배포해 검토자가 미리 준비한다.
- 전문가 팀과 검사목록: 관련 전문가로 팀을 구성하고 검사목록을 제공한다.
(나) 겉으로 보이는 동작이나 외부 행위를 바꾸지 않고 소프트웨어 내부 구조를 바꾸며 점진적으로 설계를 향상시키는 기법
(다) 기존 시스템을 이해하여 새로운 기능을 추가하거나 성능을 향상시키는 등의 새로운 형태로 변경하는 것으로, 단순히 설계정보를 끌어내는 것뿐만 아니라 이 정보를 사용하여 보다 나은 시스템을 만드는 것
(가)는 역공학, (나)는 리팩토링, (다)는 재공학이다.
문서 없이 코드에서 설계 정보를 추출하는 것이 역공학이고, 그 정보를 활용해 더 나은 형태로 시스템을 바꾸는 것이 재공학이다. 재공학은 역공학을 포함하는 더 넓은 개념이다.
- 역공학–프로토타이핑–재공학: 프로토타이핑은 요구 확인용 시제품을 만드는 기법으로, 외부 동작을 유지한 채 내부 구조를 개선하는 (나)의 리팩토링과 다르다.
- 재공학–리팩토링–역공학: 설계 정보 추출만 하는 (가)가 역공학, 이를 바탕으로 개선까지 하는 (다)가 재공학이므로 두 용어가 뒤바뀌었다.
- 재공학–프로토타이핑–역공학: (가)·(다)가 뒤바뀌었고 (나)도 리팩토링이 아니다.
물리적 노드와 통신 경로를 육면체와 선으로 표시하는 것은 배치 다이어그램(deployment diagram)이다.
컴포넌트 다이어그램은 소프트웨어 컴포넌트와 그 인터페이스·의존 관계를 나타낸다.
- 상태 다이어그램: 이벤트에 따른 객체의 상태 변화를 나타낸다.
- 클래스 다이어그램: 클래스와 클래스 간 관계를 나타내는 정적 모델이다.
- 활동 다이어그램: 업무 흐름이나 유스케이스의 처리 흐름을 나타낸다.
바람직한 설계는 결합도를 약하게, 응집도를 강하게 유지하므로 결합도를 강하게 유지한다는 설명이 옳지 않다.
결합도가 강하면 한 모듈의 변경이 다른 모듈로 퍼져 유지보수성이 떨어진다.
- 유지관리 고려: 유지보수가 쉬운 설계는 바람직한 설계의 목표이다.
- 분할과 정복: 문제를 모듈로 나눠 복잡도를 줄이는 모듈화 원리이다.
- 변경 용이성과 영향 최소화: 낮은 결합도와 정보 은닉으로 달성하는 바람직한 특성이다.
ㄴ. 수학적 증명 기술을 이용하여 완전성을 검증할 수 있다.
ㄷ. 자연어를 기반으로 작성하기 때문에 쉽게 작성할 수 있다.
옳은 것은 ㄱ과 ㄷ이다.
자연어 비정형 명세는 작성·이해가 쉽지만 표현이 모호해 해석이 달라질 수 있다.
- ㄱ(옳음): 자연어의 모호성 때문에 읽는 사람마다 해석이 달라질 수 있다.
- ㄴ(틀림): 수학적 증명으로 완전성을 검증하는 것은 정형 명세(Z, VDM 등)의 특징이다.
- ㄷ(옳음): 별도 표기법 없이 자연어로 쓰므로 작성이 쉽다.
한 번 수정할 때 여러 클래스를 동시에 조금씩 고쳐야 하는 악취는 기능의 산재(shotgun surgery)이다.
하나의 책임이 여러 클래스에 흩어져 있어 생기며, 관련 코드를 한 클래스로 모으는 리팩토링(메서드·필드 이동)으로 해결한다.
- 과잉 중개 메서드: 클래스가 대부분의 일을 다른 클래스에 위임만 하는 경우이다.
- 메시지 체인: 객체에서 객체로 연쇄적으로 접근 메서드를 호출하는 경우이다.
- 직무 유기 클래스: 하는 일이 거의 없어 존재 가치가 낮은 클래스이다.
| 문장 번호 | 소스 코드 | 테스트 입력 |
|---|---|---|
| void temp(int x, int y) { | T = {t1:(x=-2, y=3), t2:(x=2, y=0)} | |
| 1 | if(x < 0 && y >= 0) | |
| 2 | printf("%d",y); | |
| 3 | if(x >= 0) | |
| 4 | printf("%d",x); | |
| } |
T로는 조건 y ≥ 0이 거짓이 되는 경우가 없으므로 조건 커버리지는 100%가 아니다.
t1(x=-2, y=3)은 문장 1·2·3을, t2(x=2, y=0)는 문장 1·3·4를 실행한다. 개별 조건을 보면 x < 0과 x ≥ 0은 참·거짓이 모두 나오지만 y ≥ 0은 두 입력 모두 참이다.
- t2만 사용한 문장 커버리지: 문장 4개 중 1·3·4를 실행하므로 75%이다.
- T의 문장 커버리지: t1이 문장 2를, t2가 문장 4를 실행해 4개 모두 실행되므로 100%이다.
- T의 분기 커버리지: 첫째 if는 t1에서 참·t2에서 거짓, 둘째 if는 t1에서 거짓·t2에서 참이므로 100%이다.
구획면(swimlane)은 활동 다이어그램에서 책임 주체별로 활동을 나누는 요소로, 시퀀스 다이어그램에서는 쓰지 않는다.
시퀀스 다이어그램은 생명선·메시지·활성화로 객체 간 상호작용을 시간 순서대로 표현한다.
- 메시지: 객체 간 호출·응답을 화살표로 나타낸다.
- 생명선: 객체가 존재하는 기간을 세로 점선으로 나타낸다.
- 활성화: 객체가 동작을 수행 중인 구간을 생명선 위의 가는 직사각형으로 나타낸다.
(나) 테스트를 통과하도록 소스 코드를 작성한다.
(다) 테스트 코드를 작성한다.
(라) 소스 코드와 테스트 코드를 리팩토링한다.
(마) 구현해야 할 소스 코드가 남아 있으면 위의 단계를 반복한다.
TDD는 테스트를 먼저 작성한 뒤 이를 통과하는 코드를 쓰므로 순서는 (가)→(다)→(나)→(라)→(마)이다.
실패하는 테스트 작성(Red) → 통과하는 코드 작성(Green) → 리팩토링(Refactor)의 주기를 구현이 끝날 때까지 반복한다.
- (가) 다음 바로 소스 코드를 작성하는 순서: 테스트 코드보다 구현이 앞서 테스트 우선 원칙에 어긋난다.
- 소스 코드 작성으로 시작해 테스트 코드 작성 후 리팩토링하는 순서: 무엇을 테스트할지 정하기 전에 구현부터 하므로 TDD가 아니다.
- 소스 코드 작성 후 리팩토링을 거쳐 테스트 코드를 작성하는 순서: 테스트 없이 리팩토링하게 되어 TDD 주기와 맞지 않는다.
복잡한 메서드 호출 과정을 숨기고 단순한 상위 인터페이스를 제공하는 것은 퍼사드 패턴이다.
퍼사드는 구조 패턴으로, 서브시스템의 여러 클래스 앞에 창구 객체를 두어 클라이언트가 내부 호출 순서를 몰라도 되게 하고 결합도를 낮춘다.
- 어댑터 패턴: 호환되지 않는 인터페이스를 클라이언트가 기대하는 인터페이스로 변환한다.
- 추상 팩토리 패턴: 관련 객체군을 구체 클래스 지정 없이 생성하는 생성 패턴이다.
- 컴포지트 패턴: 객체를 트리 구조로 구성해 개별 객체와 복합 객체를 동일하게 다룬다.
int max(int a, int b, int c) {
int result = a;
if (b > result)
result = b;
if (c > result)
result = c;
return result;
}독립 경로를 모두 실행하는 입력 집합은 (1,1,1), (1,1,2), (1,2,2)이다.
if 문이 2개이므로 순환 복잡도는 이고, 독립 경로는 두 조건의 결과가 (거짓, 거짓)·(거짓, 참)·(참, 거짓)인 3개로 잡을 수 있다.
(1,1,1)은 두 조건 모두 거짓, (1,1,2)는 c > result만 참, (1,2,2)는 b > result만 참이 되어 세 경로를 모두 실행한다.
- (1,2,3) 하나: 두 조건이 모두 참인 경로 1개만 실행한다.
- (1,1,1), (1,2,1): 두 조건 거짓 경로와 b만 참인 경로 2개뿐이다.
- (1,2,3), (1,3,2), (2,3,3): b > result가 항상 참이라 첫 조건이 거짓인 경로가 없어 독립 경로 3개를 채우지 못한다.
‘구매’ 클래스는 ‘구매자’와 ‘자동차’ 사이 연관선에 점선으로 붙어 있는 연관 클래스로, 그 연관 관계에 속성이나 행위를 추가하기 위해 쓰인다.
그림의 나머지 표기는 이렇게 읽는다. 판매자 쪽의 꽉 찬 마름모는 합성(composition), 하위 클래스에서 자동차로 향하는 실선과 속 빈 삼각형은 일반화(상속)이다.
- 연관선의 화살표가 구매자에서 자동차 쪽으로만 향하므로, 자동차가 구매자를 직접 참조한다는 설명은 틀리다.
- 자가용차·영업용차는 실선과 속 빈 삼각형으로 연결된 일반화 관계이며, 점선을 쓰는 실체화 관계가 아니다.
- 판매자와 자동차는 꽉 찬 마름모의 합성 관계이므로 판매자 객체가 소멸되면 자동차 객체도 함께 소멸된다. 집약이라고 본 설명은 틀리다.
B. 기능점수 측정 유형 결정
C. 미조정 기능점수 계산
D. 조정 인자 계산
올바른 연결은 (가) 기능점수 측정 유형 결정, (나) 계산 범위 및 애플리케이션 경계 식별, (다) 미조정 기능점수 계산, (라) 조정 인자 계산이다.
IFPUG 절차는 먼저 개발·개선·애플리케이션 중 측정 유형을 정하고, 그 유형에 맞춰 계산 범위와 경계를 식별한다. 이어 데이터 기능과 트랜잭션 기능의 복잡도를 합산해 미조정 기능점수를 구하고, 별도로 구한 조정 인자를 반영해 조정 기능점수를 얻는다.
- 범위·경계 식별을 맨 앞에 둔 연결은 측정 유형이 정해지기 전에 범위를 잡는 셈이라 순서가 틀리다.
- (다)에 조정 인자, (라)에 미조정 기능점수를 둔 연결은 데이터·트랜잭션 계산 결과가 합산되는 단계를 잘못 짚었다.
- 조정 인자 계산을 맨 앞에, 측정 유형 결정을 (라)에 둔 연결은 절차의 시작과 병행 단계를 뒤바꾼 것이다.
| 작업 | 선행작업 | 소요기간(일) |
|---|---|---|
| A | D | 15 |
| B | A, D, E | 10 |
| C | E | 15 |
| D | - | 5 |
| E | - | 10 |
| F | A, B | 20 |
| G | B, C | 15 |
프로젝트 완료 최소 시간은 임계 경로 D→A→B→F의 길이인 50일이다.
가장 이른 시작–종료를 차례로 구하면 D 0–5, E 0–10, A 5–20, C 10–25, B 20–30(A·D·E 중 가장 늦은 A 종료 후), F 30–50, G 30–45이다.
마지막 작업 F와 G 중 늦게 끝나는 F가 완료 시점을 정하므로 일이고, 이 경로가 임계 경로이다.
- 40일: 어느 종료 경로보다도 짧아 선행관계를 충족할 수 없다.
- 45일: G가 끝나는 시점일 뿐 F가 더 늦게 끝나므로 부족하다.
- 90일: 모든 작업 기간을 단순 합산한 값으로, 병행 가능한 작업을 고려하지 않았다.
alt는 조건에 맞는 여러 대안 중 하나만 수행하며, 각 피연산자 구역을 점선으로 나눈다는 설명이 옳다.
alt는 if-else, opt는 단일 if, par는 병행, ref는 다른 상호작용 참조에 대응한다. 나머지는 의미가 서로 뒤바뀐 것이 함정이다.
- ref 설명: 동시 실행은 par의 의미이고, ref는 다른 다이어그램(상호작용)을 참조할 때 쓴다.
- opt 설명: 다른 다이어그램 참조는 ref의 의미이고, opt는 조건을 만족할 때만 수행하는 선택적 상호작용이다.
- par 설명: 조건부 수행은 opt의 의미이고, par는 동시에 실행되는 병렬 상호작용이다.
○ 사용자 스토리(user story)
○ 소규모 릴리즈(small release)
○ 짝 프로그래밍(pair programming)
○ 테스트 우선 개발(test-first development)
제시된 특징은 모두 익스트림 프로그래밍(XP)의 대표 실천 기법이다.
XP는 애자일 방법론으로, 사용자 스토리로 요구를 받고 짝 프로그래밍·테스트 우선 개발·리팩토링·소규모 릴리즈로 짧게 반복한다.
- COCOMO: 개발 방법론이 아니라 LOC 기반의 비용 추정 모델이다.
- 통합 프로세스(UP): 유스케이스 중심·아키텍처 중심의 반복적 프로세스로, 짝 프로그래밍·테스트 우선 개발을 핵심 실천으로 두지 않는다.
- 폭포수 모델: 단계를 순차로 진행하는 전통적 모델로, 소규모 릴리즈·리팩토링 같은 반복 실천과 거리가 멀다.
○ 하나의 데이터를 다양한 그래프로 보여 줄 수 있는 데스크탑 응용 프로그램 개발
○ 데이터베이스 연동 부분과 사용자 웹 화면 제공 부분으로 나눈 웹 기반 응용 프로그램 개발
데이터·제어·화면을 분리하는 구조는 MVC(Model-View-Controller) 패턴이다.
Model은 데이터 관리, View는 화면 표시, Controller는 사용자 상호작용 제어를 맡으므로 하나의 데이터를 여러 뷰(다양한 그래프)로 보여 줄 수 있고, 웹에서도 DB 연동부와 화면부를 나누기 좋다.
- 리포지토리: 여러 컴포넌트가 중앙 저장소의 데이터를 공유하는 구조로, 화면·제어 분리가 핵심이 아니다.
- 트랜잭션 처리: 사용자 요청을 트랜잭션 단위로 처리해 데이터베이스 일관성을 유지하는 구조이다.
- 파이프 필터: 데이터가 필터를 차례로 거치며 변환되는 데이터 흐름 구조이다.
개발에 소요되는 시간은 20개월이다.
개발 기간 = 총 LOC ÷ (개발자 수 × 1인당 월평균 생산성)으로 구한다.
(개월)
팀 전체의 월 생산량이 4,000 LOC이므로 80,000 LOC를 완성하는 데 20개월이 걸린다.
시스템 구조·서브시스템 구조는 설계 단계에서 다룰 내용이므로 요구분석 명세서의 특성으로 옳지 않다.
요구 명세는 시스템이 무엇을(what) 해야 하는지를 기술하고, 어떻게(how) 구현할지는 설계에서 정한다.
- 서로 모순되는 부분이 없어야 한다: 일관성(consistency)으로 바람직한 특성이다.
- 고객과 개발자가 동의한 것: 합의된 명세여야 개발·검증의 기준이 된다.
- 고객과 개발자 모두 쉽게 이해: 이해 용이성으로, 양측이 함께 검토할 수 있어야 한다.
클래스·컴포넌트의 종류와 관계에 초점을 두는 것은 유스케이스 관점이 아니라 논리(logical) 관점이다.
4+1 관점에서 유스케이스(시나리오) 관점은 나머지 네 관점을 하나로 묶어 주는 시스템 기능 시나리오를 기술한다.
- 배치(물리) 관점: 처리 장치 간 물리적 배치를 다룬다는 설명이 옳다.
- 프로세스 관점: 런타임에 상호작용하는 프로세스의 구성을 보여 준다는 설명이 옳다.
- 구현(개발) 관점: 서브시스템 모듈의 구조화에 관심을 둔다는 설명이 옳다.
Animal a; a = new Dog( ); a.makeSound( ); // “멍멍” 출력함 a = new Cat( ); a.makeSound( ); // “야옹” 출력함
같은 메시지로 객체에 따라 다른 구현이 호출되는 개념은 다형성이다.
Animal 타입 변수 a가 가리키는 실제 객체(Dog, Cat)에 따라 재정의된 makeSound()가 실행 시점에 결정된다(동적 바인딩).
- 정보 은닉: 내부 구현을 감추고 인터페이스만 공개하는 원칙이다.
- 정적 바인딩: 호출 대상을 컴파일 시점에 고정하므로 객체에 따라 다른 구현이 호출되지 않는다.
- 캡슐화: 데이터와 연산을 하나의 단위로 묶는 개념이다.
이 제어흐름 그래프의 순환 복잡도는 4이다.
순환 복잡도는 V(G) = E − N + 2로 구한다. 간선은 1→2, 1→3, 1→4, 4→3, 2→5, 5→2, 3→6, 5→6의 8개이고 노드는 6개이다.
분기 노드(1에서 세 갈래, 5에서 두 갈래)로 세어도 판단 수 + 1, 곧 (2 + 1) + 1 = 4로 같다.
- 복잡도 2는 노드 1의 세 갈래 분기만으로도 넘어서므로 작다.
- 복잡도 3은 5에서 2로 되돌아가는 반복 경로를 빠뜨린 값이다.
- 복잡도 5는 간선을 하나 더 세었거나 노드를 하나 덜 센 값이다.
‘추가이체’는 ‘계좌이체’에 <<extend>> 관계로 연결되어 있으므로, 계좌이체가 수행되면 추가이체도 수행된다는 설명이 옳지 않다.
extend는 기본 유스케이스에 특정 조건이 만족될 때만 선택적으로 덧붙는 확장 기능이고, include는 기본 유스케이스가 수행될 때 반드시 함께 수행되는 공통 기능이다.
- ‘해외이체’에서 ‘계좌이체’로 속이 빈 삼각형 화살표(일반화)가 이어지므로, 계좌이체가 해외이체보다 일반화된 유스케이스라는 설명은 옳다.
- 사용자 액터가 계좌조회·계좌이체·해외이체에 각각 연결되어 있으므로 세 유스케이스를 사용자가 수행한다는 설명은 옳다.
- 계좌조회와 계좌이체가 각각 <<include>>로 ‘인증’을 가리키므로, 인증이 두 유스케이스에 포함되어 수행된다는 설명은 옳다.
서버·클라이언트 구분 없이 모든 노드가 연산을 수행하는 비중앙집중 구조는 피어 투 피어(P2P) 아키텍처이다.
각 피어가 서비스 요청자이자 제공자 역할을 함께 하며, 중앙 서버 없는 파일 공유 네트워크가 대표 사례이다.
- 마이크로서비스: 시스템을 독립 배포 가능한 작은 서비스로 나누는 구조로, 서버·클라이언트 구분이 없어지는 것이 아니다.
- 분산 컴포넌트: 여러 노드에 컴포넌트를 분산 배치하고 미들웨어로 연결하는 구조이다.
- 서비스 지향: 서비스 제공자와 소비자가 표준 인터페이스로 서비스를 주고받는 구조이다.
abstract class Shape {
public void paint() { draw(); }
abstract public void draw();
}
abstract class Circle extends Shape {
public int radius;
public Circle(int radius) {
this.radius = radius; }
double getArea() {
return (3.14 * radius * radius); }
}
public class NamedCircle extends Circle {
String name;
public NamedCircle(int radius, String name) {
super(radius);
this.name = name;
}
public void draw() {
System.out.println("반지름이 " +
radius + "인 원을 그리다.");
}
public static void main(String[] args) {
Shape s;
s = new Shape();
NamedCircle w = new NamedCircle(5, "Ring");
System.out.println(w.getArea());
w.draw();
}
}오류가 나는 문장은 추상 클래스 Shape를 new로 생성하는 문장이다.
abstract 클래스는 구현되지 않은 메서드(draw)를 가지므로 직접 인스턴스화할 수 없다. 다만 추상 클래스 타입의 참조 변수 선언은 가능하다.
- super(radius): Circle에 int 매개변수 생성자가 있으므로 정상 호출이다.
- Shape s: 추상 클래스 타입 참조 변수 선언은 허용된다.
- w.getArea() 출력: NamedCircle이 Circle의 getArea()를 상속받으므로 정상이며, draw도 NamedCircle에서 구현되어 객체 생성이 가능하다.
코드 인스펙션은 프로그램을 실행하지 않고 검토하는 정적(static) 테스트이므로 동적 테스트라는 설명이 옳지 않다.
훈련된 검토자들이 체크리스트를 바탕으로 코드·문서를 읽어 결함을 찾는 공식 검토 기법이다.
- 품질 보증 활동: 결함을 조기에 발견하는 대표적 품질 보증 활동이다.
- 사전 문서 배포: 회의 전에 코드·분석·설계 문서를 배포해 검토자가 미리 준비한다.
- 전문가 팀과 검사목록: 관련 전문가로 팀을 구성하고 검사목록을 제공한다.
(나) 겉으로 보이는 동작이나 외부 행위를 바꾸지 않고 소프트웨어 내부 구조를 바꾸며 점진적으로 설계를 향상시키는 기법
(다) 기존 시스템을 이해하여 새로운 기능을 추가하거나 성능을 향상시키는 등의 새로운 형태로 변경하는 것으로, 단순히 설계정보를 끌어내는 것뿐만 아니라 이 정보를 사용하여 보다 나은 시스템을 만드는 것
(가)는 역공학, (나)는 리팩토링, (다)는 재공학이다.
문서 없이 코드에서 설계 정보를 추출하는 것이 역공학이고, 그 정보를 활용해 더 나은 형태로 시스템을 바꾸는 것이 재공학이다. 재공학은 역공학을 포함하는 더 넓은 개념이다.
- 역공학–프로토타이핑–재공학: 프로토타이핑은 요구 확인용 시제품을 만드는 기법으로, 외부 동작을 유지한 채 내부 구조를 개선하는 (나)의 리팩토링과 다르다.
- 재공학–리팩토링–역공학: 설계 정보 추출만 하는 (가)가 역공학, 이를 바탕으로 개선까지 하는 (다)가 재공학이므로 두 용어가 뒤바뀌었다.
- 재공학–프로토타이핑–역공학: (가)·(다)가 뒤바뀌었고 (나)도 리팩토링이 아니다.
물리적 노드와 통신 경로를 육면체와 선으로 표시하는 것은 배치 다이어그램(deployment diagram)이다.
컴포넌트 다이어그램은 소프트웨어 컴포넌트와 그 인터페이스·의존 관계를 나타낸다.
- 상태 다이어그램: 이벤트에 따른 객체의 상태 변화를 나타낸다.
- 클래스 다이어그램: 클래스와 클래스 간 관계를 나타내는 정적 모델이다.
- 활동 다이어그램: 업무 흐름이나 유스케이스의 처리 흐름을 나타낸다.
바람직한 설계는 결합도를 약하게, 응집도를 강하게 유지하므로 결합도를 강하게 유지한다는 설명이 옳지 않다.
결합도가 강하면 한 모듈의 변경이 다른 모듈로 퍼져 유지보수성이 떨어진다.
- 유지관리 고려: 유지보수가 쉬운 설계는 바람직한 설계의 목표이다.
- 분할과 정복: 문제를 모듈로 나눠 복잡도를 줄이는 모듈화 원리이다.
- 변경 용이성과 영향 최소화: 낮은 결합도와 정보 은닉으로 달성하는 바람직한 특성이다.
ㄴ. 수학적 증명 기술을 이용하여 완전성을 검증할 수 있다.
ㄷ. 자연어를 기반으로 작성하기 때문에 쉽게 작성할 수 있다.
옳은 것은 ㄱ과 ㄷ이다.
자연어 비정형 명세는 작성·이해가 쉽지만 표현이 모호해 해석이 달라질 수 있다.
- ㄱ(옳음): 자연어의 모호성 때문에 읽는 사람마다 해석이 달라질 수 있다.
- ㄴ(틀림): 수학적 증명으로 완전성을 검증하는 것은 정형 명세(Z, VDM 등)의 특징이다.
- ㄷ(옳음): 별도 표기법 없이 자연어로 쓰므로 작성이 쉽다.
한 번 수정할 때 여러 클래스를 동시에 조금씩 고쳐야 하는 악취는 기능의 산재(shotgun surgery)이다.
하나의 책임이 여러 클래스에 흩어져 있어 생기며, 관련 코드를 한 클래스로 모으는 리팩토링(메서드·필드 이동)으로 해결한다.
- 과잉 중개 메서드: 클래스가 대부분의 일을 다른 클래스에 위임만 하는 경우이다.
- 메시지 체인: 객체에서 객체로 연쇄적으로 접근 메서드를 호출하는 경우이다.
- 직무 유기 클래스: 하는 일이 거의 없어 존재 가치가 낮은 클래스이다.
| 문장 번호 | 소스 코드 | 테스트 입력 |
|---|---|---|
| void temp(int x, int y) { | T = {t1:(x=-2, y=3), t2:(x=2, y=0)} | |
| 1 | if(x < 0 && y >= 0) | |
| 2 | printf("%d",y); | |
| 3 | if(x >= 0) | |
| 4 | printf("%d",x); | |
| } |
T로는 조건 y ≥ 0이 거짓이 되는 경우가 없으므로 조건 커버리지는 100%가 아니다.
t1(x=-2, y=3)은 문장 1·2·3을, t2(x=2, y=0)는 문장 1·3·4를 실행한다. 개별 조건을 보면 x < 0과 x ≥ 0은 참·거짓이 모두 나오지만 y ≥ 0은 두 입력 모두 참이다.
- t2만 사용한 문장 커버리지: 문장 4개 중 1·3·4를 실행하므로 75%이다.
- T의 문장 커버리지: t1이 문장 2를, t2가 문장 4를 실행해 4개 모두 실행되므로 100%이다.
- T의 분기 커버리지: 첫째 if는 t1에서 참·t2에서 거짓, 둘째 if는 t1에서 거짓·t2에서 참이므로 100%이다.
구획면(swimlane)은 활동 다이어그램에서 책임 주체별로 활동을 나누는 요소로, 시퀀스 다이어그램에서는 쓰지 않는다.
시퀀스 다이어그램은 생명선·메시지·활성화로 객체 간 상호작용을 시간 순서대로 표현한다.
- 메시지: 객체 간 호출·응답을 화살표로 나타낸다.
- 생명선: 객체가 존재하는 기간을 세로 점선으로 나타낸다.
- 활성화: 객체가 동작을 수행 중인 구간을 생명선 위의 가는 직사각형으로 나타낸다.
(나) 테스트를 통과하도록 소스 코드를 작성한다.
(다) 테스트 코드를 작성한다.
(라) 소스 코드와 테스트 코드를 리팩토링한다.
(마) 구현해야 할 소스 코드가 남아 있으면 위의 단계를 반복한다.
TDD는 테스트를 먼저 작성한 뒤 이를 통과하는 코드를 쓰므로 순서는 (가)→(다)→(나)→(라)→(마)이다.
실패하는 테스트 작성(Red) → 통과하는 코드 작성(Green) → 리팩토링(Refactor)의 주기를 구현이 끝날 때까지 반복한다.
- (가) 다음 바로 소스 코드를 작성하는 순서: 테스트 코드보다 구현이 앞서 테스트 우선 원칙에 어긋난다.
- 소스 코드 작성으로 시작해 테스트 코드 작성 후 리팩토링하는 순서: 무엇을 테스트할지 정하기 전에 구현부터 하므로 TDD가 아니다.
- 소스 코드 작성 후 리팩토링을 거쳐 테스트 코드를 작성하는 순서: 테스트 없이 리팩토링하게 되어 TDD 주기와 맞지 않는다.
복잡한 메서드 호출 과정을 숨기고 단순한 상위 인터페이스를 제공하는 것은 퍼사드 패턴이다.
퍼사드는 구조 패턴으로, 서브시스템의 여러 클래스 앞에 창구 객체를 두어 클라이언트가 내부 호출 순서를 몰라도 되게 하고 결합도를 낮춘다.
- 어댑터 패턴: 호환되지 않는 인터페이스를 클라이언트가 기대하는 인터페이스로 변환한다.
- 추상 팩토리 패턴: 관련 객체군을 구체 클래스 지정 없이 생성하는 생성 패턴이다.
- 컴포지트 패턴: 객체를 트리 구조로 구성해 개별 객체와 복합 객체를 동일하게 다룬다.
int max(int a, int b, int c) {
int result = a;
if (b > result)
result = b;
if (c > result)
result = c;
return result;
}독립 경로를 모두 실행하는 입력 집합은 (1,1,1), (1,1,2), (1,2,2)이다.
if 문이 2개이므로 순환 복잡도는 이고, 독립 경로는 두 조건의 결과가 (거짓, 거짓)·(거짓, 참)·(참, 거짓)인 3개로 잡을 수 있다.
(1,1,1)은 두 조건 모두 거짓, (1,1,2)는 c > result만 참, (1,2,2)는 b > result만 참이 되어 세 경로를 모두 실행한다.
- (1,2,3) 하나: 두 조건이 모두 참인 경로 1개만 실행한다.
- (1,1,1), (1,2,1): 두 조건 거짓 경로와 b만 참인 경로 2개뿐이다.
- (1,2,3), (1,3,2), (2,3,3): b > result가 항상 참이라 첫 조건이 거짓인 경로가 없어 독립 경로 3개를 채우지 못한다.
‘구매’ 클래스는 ‘구매자’와 ‘자동차’ 사이 연관선에 점선으로 붙어 있는 연관 클래스로, 그 연관 관계에 속성이나 행위를 추가하기 위해 쓰인다.
그림의 나머지 표기는 이렇게 읽는다. 판매자 쪽의 꽉 찬 마름모는 합성(composition), 하위 클래스에서 자동차로 향하는 실선과 속 빈 삼각형은 일반화(상속)이다.
- 연관선의 화살표가 구매자에서 자동차 쪽으로만 향하므로, 자동차가 구매자를 직접 참조한다는 설명은 틀리다.
- 자가용차·영업용차는 실선과 속 빈 삼각형으로 연결된 일반화 관계이며, 점선을 쓰는 실체화 관계가 아니다.
- 판매자와 자동차는 꽉 찬 마름모의 합성 관계이므로 판매자 객체가 소멸되면 자동차 객체도 함께 소멸된다. 집약이라고 본 설명은 틀리다.
B. 기능점수 측정 유형 결정
C. 미조정 기능점수 계산
D. 조정 인자 계산
올바른 연결은 (가) 기능점수 측정 유형 결정, (나) 계산 범위 및 애플리케이션 경계 식별, (다) 미조정 기능점수 계산, (라) 조정 인자 계산이다.
IFPUG 절차는 먼저 개발·개선·애플리케이션 중 측정 유형을 정하고, 그 유형에 맞춰 계산 범위와 경계를 식별한다. 이어 데이터 기능과 트랜잭션 기능의 복잡도를 합산해 미조정 기능점수를 구하고, 별도로 구한 조정 인자를 반영해 조정 기능점수를 얻는다.
- 범위·경계 식별을 맨 앞에 둔 연결은 측정 유형이 정해지기 전에 범위를 잡는 셈이라 순서가 틀리다.
- (다)에 조정 인자, (라)에 미조정 기능점수를 둔 연결은 데이터·트랜잭션 계산 결과가 합산되는 단계를 잘못 짚었다.
- 조정 인자 계산을 맨 앞에, 측정 유형 결정을 (라)에 둔 연결은 절차의 시작과 병행 단계를 뒤바꾼 것이다.
| 작업 | 선행작업 | 소요기간(일) |
|---|---|---|
| A | D | 15 |
| B | A, D, E | 10 |
| C | E | 15 |
| D | - | 5 |
| E | - | 10 |
| F | A, B | 20 |
| G | B, C | 15 |
프로젝트 완료 최소 시간은 임계 경로 D→A→B→F의 길이인 50일이다.
가장 이른 시작–종료를 차례로 구하면 D 0–5, E 0–10, A 5–20, C 10–25, B 20–30(A·D·E 중 가장 늦은 A 종료 후), F 30–50, G 30–45이다.
마지막 작업 F와 G 중 늦게 끝나는 F가 완료 시점을 정하므로 일이고, 이 경로가 임계 경로이다.
- 40일: 어느 종료 경로보다도 짧아 선행관계를 충족할 수 없다.
- 45일: G가 끝나는 시점일 뿐 F가 더 늦게 끝나므로 부족하다.
- 90일: 모든 작업 기간을 단순 합산한 값으로, 병행 가능한 작업을 고려하지 않았다.
alt는 조건에 맞는 여러 대안 중 하나만 수행하며, 각 피연산자 구역을 점선으로 나눈다는 설명이 옳다.
alt는 if-else, opt는 단일 if, par는 병행, ref는 다른 상호작용 참조에 대응한다. 나머지는 의미가 서로 뒤바뀐 것이 함정이다.
- ref 설명: 동시 실행은 par의 의미이고, ref는 다른 다이어그램(상호작용)을 참조할 때 쓴다.
- opt 설명: 다른 다이어그램 참조는 ref의 의미이고, opt는 조건을 만족할 때만 수행하는 선택적 상호작용이다.
- par 설명: 조건부 수행은 opt의 의미이고, par는 동시에 실행되는 병렬 상호작용이다.