소프트웨어 공학 - [제9강] 객제지향 분석과 설계

소프트웨어 공학 - [제9강] 객제지향 분석과 설계

주요용어

• OOA/OOD: 객체 지향 분석과 설계는 상호작용하는 객체들로 시스템을 모델링하는 방법이다. 분석 과정에서는 문제 도메인을 분석하여 다루어야 하는 정보들에 관한 개념 모델을 작성하는 것에 주안점을 둔다. 설계 과정에서는 비기능적 요구사항과 아키텍처를 고려하여 개념 모델을 변환하여 구현을 위한 명세를 작성한다.
• 유스케이스: 사용자가 의도된 작업을 위해 수행하는 시스템과의 일련의 상호 작용 또는 구체적 사용 시나리오로 기능적 요구사항을 의미한다.
• 시스템 설계: 분석 모델을 시스템 설계 모델로 변환하는 일이다. 주요 작업은 아키텍처를 정하는 일이며 구현과 관련된 여러 제약 사항들에 관한 결정이 이루어진다. 아키텍처 설계를 객체지향 방법에서는 시스템 설계라는 용어로 표현한다.
• 객체 설계: 시스템 설계가 후에 수행되는 클래스를 설계하는 작업이다. 클래스에 대한 완전한 정의를 하고 각 오퍼레이션에 대한 알고리즘과 인터페이스가 정의된다.
• 엔터티/경계/제어 객체: 

엔터티 객체는 시스템이 유지해야 하는 정보를 표현하고, 

경계 객체는 시스템의 인터페이스를 의미하며, 

제어 객체는 유스케이스를 실현하는 객체이다.

• UP: UML의 저자들이 제안한 반복적이고 점증적인 개발을 지원하는 프로세스 프레임워크이다. 유스케이스 기반이며 아키텍처 중심적 프로세스와 위험 관리를 강조한다.
• RUP: UP를 상세히 다듬은 버전으로, 프로세스를 HTML로 문서화하여 상용화한 제품이다.

객체지향 분석과 설계 개요

객체지향 분석과 설계

시스템을 상호작용하는 객체들로 모델링

객체의 협력과 상호작용을 표현하는 모델을 생성

정적 구조, 동적 행위, 시스템 구성 등을 UML로 표현

객체지향 분석과 설계 과정은 일반적으로 반복적 점증적 프로세스

객체지향 분석

결과물은 시스템이 기능적으로 무엇을 수행하는지를 설명

문제 도메인을 분석하여 개념 모델을 작성

유스케이스 다이어그램, 클래스 다이어그램, 상호작용 다이어그램

객체지향 설계

결과물은 시스템을 어떻게 만들 것인가를 설명

개념 모델을 비기능적 요구사항과 아키텍처를 고려하여 변환

응답 시간, 처리율, 실행 플랫폼, 개발 환경, 프로그래밍 언어를 고려    

개념 클래스는 구현 클래스로 변환됨

요구사항 추출

요구 공학

고객이 이해할 수 있는 요구사항 명세서를 작성

요구사항 명세서는 분석 활동 동안 구조화되고 정형화되어 분석 모델이 만들어짐

요구사항 명세서와 분석 모델은 같은 정보를 표현한 것

요구사항 추출을 위한 활동

액터 찾기, 시나리오 찾기, 유스케이스 찾기, 유스케이스 상세화, 액터와 유스케이스들 간의

관계 찾기, 비기능 요구사항 찾기

요구사항 추출과 분석은 사용자 관점의 작업임

액터 찾기

액터는 시스템과 상호작용하는 사람이나 외부 시스템

액터의 식별은 요구사항 추출의 첫 단계로 시스템이 지원해야 하는 사용자를 식별함

액터는 시스템 경계의 외부에 존재

액터를 찾기 위한 질의

시스템의 지원을 받는 사용자

시스템의 주요 기능을 실행하는 사용자 그룹

유지보수나 감독 일을 하는 사용자 그룹

시스템과 상호작용하는 외부 하드웨어나 소프트웨어 시스템

시나리오 찾기

시나리오는 액터가 보는 시스템의 기능을 이야기 식으로 기술한 것

응용 분야의 용어를 사용하여 단일 기능을 표현함

개발자는 시나리오 찾기를 통해 시스템의 범위와 사용자 작업 프로세스를 이해하게 됨

시나리오가 유스케이스와 다른 점

특정 사례에 초점을 두며 모든 가능한 상황을 기술하는 것은 아님

시나리오는 차후 유스케이스로 형식화되어야 함

시나리오를 찾기 위한 질의

시스템이 수행해 주길 바라는 작업

액터가 엑세스하는 정보

액터가 알려 주어야 하는 외부 환경의 변화

시스템이 알려 주어야 하는 사건

유스케이스 찾기

시나리오는 유스케이스의 인스탄스

시나리오는 특정한 하나의 사례, 유스케이스는 유사 기능의 모든 사례

예) CheckOutResource는 유스케이스, CheckOutCDForProfessor는 시나리오

해당 기능의 모든 가능한 시나리오를 명세한 것

유스케이스는 액터에 의해 실행되며 상호작용에 관한 완전한 흐름을 표현하고 실행 후에는 다른 액터와 상호작용도 함

유스케이스의 이름은 액터 입장에서 동사구로 표현

참여 액터는 유스케이스를 시작시키는 액터와 정보를 제공받는 액터임

유스케이스의 기본 구성

선행 조건과 종료 조건: 유스케이스가 발생될 수 있는 조건과 유스케이스의 종료 조건을 기술

기본 이벤트 흐름: 시스템과 액터의 성공적 상호 작용을 기술

대체 이벤트 흐름: 부수적이며 선택적인 상호 작용을 기술

특수 요구사항: 비기능적 요구사항

유스케이스 상세화

요구사항을 상세히 명세하는 것으로 유스케이스의 완전성과 정확성을 위한 작업

시스템이 제공하는 기능을 자세히 기술함

시나리오에서 포함되지 못했던 기능을 파악하여 예외 사항으로 기술하거나 새로운 유스케이스를 추가함

고려 사항

시스템이 다루는 대상를 상세히 함

저수준의 상호작용, 예외 사항의 파악과 처리를 명시

유스케이스들에서 공통 기능의 추출

액터와 유스케이스의 관계 찾기

모델의 복잡성을 줄이고 이해도를 높이기 위한 것으로 통신, 확장, 포함 관계를 찾아 정리함

통신 관계

유스케이스와 이것을 시작시키는 액터 또는 유스케이스와 통신하는 액터 사이의 관계

시스템의 접근 권한이나 정보의 흐름을 보여줌

유스케이스들 간의 관계 찾기

확장 관계

특정 조건하에서 확장된 행위를 포함하면 확장 유스케이스로 분리

기본 유스케이스와 확장 유스케이스로 분리됨

기본 유스케이스에서 예외적이며 선택적인 사건의 흐름을 떼어 내는 것

기본 유스케이스가 짧아지고 이해가 쉬워지며 보통의 사례와 예외 사례에 다른 처리를 할수 있음

기본 유스케이스와 확장 유스케이스는 모두 완전한 유스케이스

포함 관계

유스케이스들에서 존재하는 공통의 기능을 분리

소스 유스케이스와 공통 유스케이스로 분리됨

중복성을 줄이기 위해 공통 유스케이스로 분리하는 것

확장 관계와 포함 관계의 비교

확장 관계

기본 유스케이스와 확장 유스케이스는 모두 완전한 유스케이스

확장 유스케이스를 호출하는 사건은 확장 유스케이스의 선행 조건으로 기술됨

확장 유스케이스는 예외적 상황이나 선택적 또는 드물게 일어나는 행위

포함 관계

공통 유스케이스가 없이는 소스 유스케이스는 완전한 유스케이스가 되지 못함

공통 유스케이스를 호출하는 이벤트는 소스 유스케이스의 이벤트 흐름 안에 기술됨

공통 유스케이스는 재사용될 수 있는 기능

상속 관계

액터들 사이나 유스케이스들 사이에도 상속 관계가 존재

분석

분석 모델

기능 모델

유스케이스와 시나리오로 표현됨

분석 객체 모델

응용 도메인을 설명하는 개념 모델로서 클래스 다이어그램으로 표현됨

동적 모델

개념 모델을 확장하여 액터와 시스템의 상호 작용을 표현하는 것으로 시퀀스다이어그램, 상태 머신 다이어그램으로 표현됨

분석 객체 모델

사용자 관점에서 시스템을 표현

다루어야 하는 개별 개념들과 그들 간의 관계를 표현

개념은 클래스로 표현되며 속성과 오퍼레이션을 가짐

엔터티/ 경계/ 제어 객체

경계 객체

액터와 연결된 시스템 인터페이스

엔터티 객체

정보 자체를

제어 객체는

유스케이스의 기능을 표현

객체의 유형을 구분함으로써 작고 특화된 객체를 만들게 되고 변경이 용이해 짐

객체의 종류를 구분하기 위하여

스테레오타입을 사용하거나 이름에 접미사를 사용

예) 《boundary》, 《control》, 《entity》

예) Loan은 엔터티 객체, LoanForm은 경계 객체, LoanControl은 제어 객체

동적 모델

시퀀스 다이어그램

단일 유스케이스에서 객체들의 상호 작용을 표현

개별 클래스에 책임을 할당

하나의 클래스는 소스 코드 상에서 하나 이상의 구현 클래스에 대응됨

상태 머신 다이어그램

단일 객체 관점에서 시스템의 행위를 표현

긴 생명주기와 상태 종속적 행위를 하는 객체들만을 고려하는 것이 좋음

대개 제어 객체를 대상으로 작성함

작성 과정에서 객체의 행위를 정형화하며 빠뜨린 오퍼레이션을 발견할 수 있음

분석 활동

자연언어 분석 방법: 명사는 클래스, have 동사는 집합 관계, be 동사는 상속 관계, 형용사는 속성이 될 수 있음

엔터티 객체 찾기

유스케이스 작성을 위해 명확히 규정한 용어, 반복적으로 등장하는 명사를 조사

실세계의 개체나 유지해야 하는 행위 정보, 데이터 소스나 종착지 등

경계 객체 찾기

사용자 인터페이스를 모델링 한 것

액터에게 받은 정보를 엔터티 객체나 제어 객체가 사용할 수 있는 형태로 변환함

각 액터는 적어도 하나의 경계 객체를 통해 상호 작용 함

사용자 인터페이스 컨트롤, 데이터 입력 폼, 사용자에게 제공하는 메시지 등이 후보가 될 수 있음

제어 객체 찾기

실제적 기능을 수행하는 부분으로 경계 객체와 엔터티 객체 사이의 조정자

경계 객체로부터 정보를 받아 엔터티 객체로 보내는 역할

유스케이스당 하나 또는 유스케이스의 액터당 하나의 제어 객체가 필요

유스케이스가 시작될 때 만들어지고 유스케이스가 끝날 때 없어짐

유스케이스를 시퀀스 다이어그램으로 변환하기

유스케이스를 실현하는 객체들의 협력을 표현

이 과정에서 요구사항 명세서에 빠져 있는 객체나 행위들을 발견할 수 있음

연관 찾기

동사나 동사구를 조사

객체들 간의 상호의존성을 표현

연관의 이름, 연관에 참여하는 클래스의 역할, 관계의 다중성을 표현

집합체 연관 찾기

전체-부품 관계(또는 포함 관계)를 표현하는 특별한 유형의 연관

구성 집합체(검은 마름모)는 부품의 존재가 전체에 의존하는 경우

공유 집합체(빈 마름모) 연관은 부품이 독립적으로 존재할 수 있음

속성 찾기

객체의 특성을 표현

소유의 의미를 가지는 단어나 형용사를 조사

구현할 때는 Customer와 Resource 사이의 연관 관계에서 resourceList가 Customer의 속성으로 표현될 수 있음

객체의 상태 종속적 행위를 모델링하기

상태 머신 다이어그램은 단일 객체의 행위를 기술

긴 생명주기와 상태 종속적 행위를 가지는 제어 객체들을 표현

객체 간의 상속 관계 모델링하기

상속 관계를 이용하여 모델에 등장하는 중복성을 제거할 수 있음

시스템 설계

시스템 설계

분석 모델을 시스템 설계 모델로 변환하는 일

분석 모델은 시스템의 내부 구조, 하드웨어 형상 및 구현 방법 등에 관한 정보를 포함하지 않음

설계의 결과

설계 목표: 시스템의 품질

소프트웨어 아키텍처의 결정

경계 조건: 시스템의 설치, 시작, 종료 및 예외 처리 사항

서브시스템은 하나의 팀에 배정되어 구현될 수 있어야 함

설계 목표의 설정

시스템 설계의 시작으로 설계 목표는 대개 비기능 요구사항과 응용 도메인으로부터 유도됨

성능 요인

반응 속도, 처리량, 메모리 용량 등

의존성 요인

강건성: 부정확한 사용자 입력에 견디는 능력신뢰도: 고장 없이 명세된 대로 행위하는 능력

가용성: 시스템을 사용할 수 있는 시간의 백분율

결함 내성: 잘못된 조건하에서 동작할 수 있는 능력

보안: 악의적 공격을 이길 수 있는 능력

안전: 오류나 고장이 생겨도 생명의 위협을 피할 수 있는 능력

비용 요인

개발과 배포에 드는 비용

유지보수 및 관리에 드는 비용

새 제품으로의 전환 비용이나 하위 호환성을 보장하는 비용

유지보수 요인

확장성, 수정성, 적응성, 이식성, 가독성, 요구사항 추적성 등

사용자 요인

유용성, 사용성 등

아키텍처 설계에서 다루는 문제

하드웨어와 소프트웨어의 연결

어떤 하드웨어에 어느 기능을 배치할 것인가

컴퓨터들 간의 통신을 어떻게 구현할 것인가 결정. 

기성 컴포넌트나 COTS의 사용을 고려

데이터 관리

 데이터베이스 관리 시스템이나 데이터 관리를 전담하는 서브시스템의 선정

접근 제어

 데이터 접근에 관한 정책을 정하고 어떻게 구현할지 정함

제어 흐름

이벤트 중심 제어나 동시 사용자의 허용 여부를 결정, 시스템의 동작순서

      경계 조건

시스템이 어떻게 시작되고 종료되는가와 예외 상황을 어떻게 처리할 것인지 고려

객체 설계

객체 설계

응용 객체를 구현 객체로 바꾸는 작업

분석 객체 모델을 구현을 위한 객체 설계 모델로 변환

서브시스템을 구현할 솔루션 객체를 찾고 구체화함

빠뜨린 솔루션 객체를 찾고, 기존 클래스를 재사용하거나 새롭게 개발함

객체 설계 모델에서 빠져 있는 속성과 오퍼레이션을 찾음

전체적으로 서브시스템과 클래스의 인터페이스를 정확히 기술

기성 컴포넌트를 사용하면 예외 처리 방법이나 서브시스템 인터페이스에 영향을 줌

기성 컴포넌트의 수정이 필요하기도 함

객체 설계 모델이 안정화되면 재구조화와 최적화 작업을 수행

객체 설계 작업

재사용

재사용 가능한 기성 컴포넌트를 찾음

컴포넌트의 수정을 고려하며 컴포넌트를 구입할 것인가 새로 개발할 것인지를 결정

인터페이스 명세

서브시스템을 구성하는 각 클래스의 인터페이스를 정확히 명세

빠뜨린 속성과 오퍼레이션을 찾고 가시성을 정의하며 오퍼레이션의 인터페이스를 명세재구조화

이해성과 확장성을 고려하여 객체 설계 모델을 수정하고 개선

유사 클래스의 통합, 상속과 패키징으로 클래스나 오퍼레이션을 재배치

최적화

성능 요구사항을 충족시키고자 객체 설계 모델을 변환

알고리즘의 수정, 속도를 고려하여 연관을 중복시키는 일, 실행 순서의 조정,

통합 프로세스

통합 프로세스(Unified Process)

객체지향 분석과 설계를 위한 방법론

여러 개발 방법론의 장점을 통합한 프로세스

반복적이고 점증적인 프로세스를 위한 프레임워크

RUP는 UP를 상세히 다듬고 HTML로 문서화한 제품임

UP 생명주기

도입, 정련, 구축, 전이의 4단계로 구성됨

정련, 구축, 전이는 각각 일련의 반복으로 구성됨

하나의 반복은 짧고 고정된 기간으로 소규모 프로젝트라 할 수 있음

소규모 프로젝트의 결과물은 하나의 점증으로 실행 가능한 시스템 릴리스가 됨

RUP는 작업을 프로세스 분야(discipline)에 따라 구분함

6개의 공학 분야(비즈니스 모델링, 요구사항, 분석과 설계, 구현, 테스트, 배포 )

3개의 지원 분야(형상 관리, 프로젝트 관리, 환경)

도입, 정련, 구축, 전이의 반복 단계에서 각 분야의 비중이 다름

초기에는 요구사항, 분석과 설계가 비중이 큼

후반에는 구현, 테스트의 비중이 높아짐

UP가 강조하는 사항

반복적 개발

유스케이스 기반의 개발

아키텍처를 중요시함

프로젝트 초기에 중요한 위험을 다룰 것

UP 4단계

도입(Inception)

1주 정도의 짧은 기간에 수행

시스템의 범위를 정하며, 비즈니스 사례를 파악하고 비전을 세움

주요 요구사항을 나열. 10% 정도의 유스케이스를 상세히 작성

가능성 있는 해결 방안과 아키텍처를 검토하고 위험 요소를 식별

일정과 비용의 개략적 추정. 실현 가능성을 조사

정련(Elaboration)

핵심 아키텍처를 구축하고 대부분의 요구사항을 명확히 정의

초기에 30%, 종료까지 80% 정도의 유스케이스를 상세히 작성

높은 위험 요소를 해결하고, 일정과 자원을 상세히 추정

2~6주 기간의 반복을 2~4회 수행함중요 요구사항을 설계하고 구현. 전체적으로 15% 정도를 구현

구축(Construction)

남아 있는 부분을 설계하고 구현하여 통합함

최종적으로 고객에게 인도할 준비를 함

전이(Transition)

사용자 환경으로 시스템을 옮김

반복은 사용자 피드백을 받아 보수하는 작업

01
객체지향 분석과 설계 과정에 관한 설명으로 옳지 않은 것은?
1 객체지향 분석 과정에서 문제 도메인에 관한 개념 모델을 작성한다.
2 객체지향 설계 과정에서 분석 모델은 솔루션 도메인에 관한 모델로 변환된다.
3 객체지향 분석 과정의 결과물은 시스템이 기능적으로 무엇을 하는지에 관한 설명이다.
4 객체지향 분석 과정에서는 응답 시간, 실행 플랫폼, 개발 환경, 프로그래밍 언어 들을 고
려해야 한다.
정답 | 4
해설 | 일반적으로 분석 과정에서는 구현과 관련된 제약 사항을 고려하지 않는다.
02
객체지향 개발 방법에서 유스케이스 추출 후에 일어나는 분석 과정의 활동으로 보
기 어려운 것은?
1 객체 또는 클래스 찾기 2 클래스의 속성 찾기
3 객체의 메소드 구현하기 4 시퀀스 다이어그램 만들기
정답 | 3
해설 | 요구사항 분석은 추출 과정에서 만들어진 요구사항 명세서(유스케이스와 유스케이스
다이어그램)를 정형화하고 구체화하는 작업이다. 이 과정에서 개념 모델(클래스 다이어그램)
과 액터와 시스템 간의 상호작용(시퀀스 다이어그램)을 표현한다. 시퀀스 다이어그램을 작
성하면서 빠져 있는 객체, 속성, 오퍼레이션 등을 추가할 수 있다.
03
객체지향 개발 방법에서 분석 객체 모델은 엔터티 객체, 경계 객체, 그리고 제어
객체들로 구성된다. 다음 중 엔터티 객체에 관한 설명은 무엇인가?
1 사용자와의 상호 작용을 담당
2 액터와 연결된 시스템 인터페이스
3 시스템이 유지해야 하는 영구적 정보를 표현
4 유스케이스의 기능을 실현
정답 | 3
해설 | 경계 객체는 시스템의 인터페이스를 의미하며, 제어 객체는 유스케이스를 실현하는
객체이다.
04
유스케이스 분석은 구조적이지 않은 방법으로 확보된 사용자 요구사항을 재정리하
는 과정이다. 이때 액터를 식별하는 일이 필요하다. 액터란 무엇인가?1 시스템과 상호작용하는 외부 개체
3 사용자 관점의 요구사항
2 외부에서 본 시스템의 기능
4 다른 사람과 소통할 수 있는 메커니즘
정답 | 1
해설 | 액터는 시스템과 상호작용하는 사람 또는 외부의 시스템이다.
05
유스케이스들 간의 확장 관계와 포함 관계를 설명한 것이다. 잘못된 것은?
1 포함 관계에 공통 유스케이스를 만드는 것은 공통의 기능이 반복되어 표현되는 것을 피
하기 위함이다.
2 확장 관계에서 확장 유스케이스는 조건이 만족되는 경우에만 실행된다.
3 확장 유스케이스는 예외적 또는 선택적으로 일어나는 행위를 표현한다.
4 포함 관계에서 점선의 화살표는 공통 유스케이스에서 소스 유스케이스로 향한다.
정답 | 4
해설 | 포함 관계에서 소스 유스케이스가 실행되면 공통 유스케이스는 항상 실행되나 확장
관계에서 확장 유스케이스는 조건이 만족될 때만 실행된다. 포함 관계에서 화살표의 방향은
소스 유스케이스에서 공통 유스케이스로 향한다.
06
객체지향 개발 방법에서 프로젝트의 설계 목표를 정의하고 시스템을 서브시스템들
로 분해하는 단계로 볼 수 있는 것은?
1 요구사항 분석 단계
3 객체 설계 단계
2 시스템 설계 단계
4 통합과 테스트 단계
정답 | 2
해설 | 아키텍처에 관한 구체적 설계는 시스템 설계 단계에서 이루어진다.
07
객체지향 개발 방법에서 프로젝트의 설계 목표를 정의하고 시스템을 서브시스템들
로 분해하는 단계로 볼 수 있는 것은?
1 요구사항 분석 단계
3 객체 설계 단계
2 시스템 설계 단계
4 통합과 테스트 단계
정답 |2
해설 | 아키텍처를 설계하는 일은 전체 제어 구조나 동시성 관리, 데이터 관리, 접근 제어
등을 포함하는 것으로 시스템 설계 단계에서 수행된다.
08
UP 개발 과정의 4단계에 관한 설명으로 맞지 않는 것은?
1 도입-시스템 범위의 설정, 타당성 조사
2 정련-10% 정도의 유스케이스를 상세히 작성
3 구축-남아 있는 덜 중요한 부분을 구현하고 통합함
4 전이-사용자 환경에서 시스템을 설치
정답 | 2
해설 | 정련 작업이 끝나는 시기에서는 80% 정도 즉 대부분의 요구사항이 상세히 작성되
어진다. 또한 정련 단계에서는 중요 요구사항을 설계하고 구현까지 한다.
09
시스템을 설계하기 위해서는 먼저 설계 목표를 정해야 한다. 다음이 설명하는 것과관련 있는 것은 무엇인가
반응 속도: 사용자 요청에 빨리 반응해야 한다.
처리량: 주어진 시간 안에 많은 작업을 처리한다.
1 성능 2 강건성
3 유용성
4 확장성
정답 | 1
해설 | 성능과 관련된 설계 목표는 대개 비기능적 요구사항으로 명시되어 있거나 응용 도
메인으로부터 자동 유도된다.
정리하기
01
시나리오와 유스케이스의 차이는 무엇인가?
시나리오는 특정 단일 사례를 표현한 것으로 보통은 성공적 사용 사례를 표현한 것이다. 반
면에 유스케이스는 유사 사례들을 통합하여 일반화시킨 것으로 예외적 사례도 포함한다.
02
객체 지향 분석이란 무엇인가?
요구사항 명세서로부터 분석 객체 모델과 동적 모델을 만드는 작업이다. 요구사항 명세서는
유스케이스 다이어그램과 관련 문서로 이루어진 기능 모델로 주어지며 분석 과정에서 수정
되고 개선된다.
03
경계 객체, 제어 객체, 엔터티 객체의 의미는 무엇인가?
경계 객체는 액터와 연결된 시스템 인터페이스로 각 유스케이스는 적어도 하나의 경계 객체
와 연결되어야 한다. 경계 객체는 액터로부터 받은 데이터를 제어 객체나 엔터티 객체가 사
용할 수 있는 형태로 바꾼다. 제어 객체는 주로 비즈니스 로직을 담당하며 유스케이스가 시
작될 때 만들어져 끝까지 존재한다. 또한 경계 객체로부터 받은 정보를 엔티티 객체로 전달
한다. 엔터티 객체는 시스템에서 유지해야 하는 데이터를 가지고 있는 객체이다.
04
구성 집합체 연관과 공유 집합체 연과의 차이는 무엇인가?
둘 모두 전체와 그것을 구성하는 요소들 간의 관계를 말한다. 구성 집합체 연관에서 부분과
전체의 생명 시간은 일치한다. 즉 부분의 존재는 전체에 의존적이며 언제나 단 하나의 전체
에만 속한다. 공유 집합체 연관에서는 부분은 전체 없이도 존재할 수 있으며 또한 하나 이
상의 전체 속할 수 있다.
05
RUP에서 도입 단계를 설명하라.
도입 단계는 프로젝트의 타당성을 조사하는 단계로 성공적 비즈니스 사례가 있는지 파악하
고 비전을 세우며 시스템의 범위를 정한다. 주요 요구사항을 나열하고 전체적으로 10% 정
도의 유스케이스를 상세히 작성하며 가능성 있는 해결 방안과 아키텍처를 검토하며 위험 요
소를 식별한다.

객체지향 분석과 설계 과정에 관한 설명으로 옳지 않은 것은?

• 1 객체지향 분석 과정에서 문제 도메인에 관한 개념 모델을 작성한다.
• 2 객체지향 설계 과정에서 분석 모델은 솔루션 도메인에 관한 모델로 변환된다.
• 3 객체지향 분석 과정의 결과물은 시스템이 기능적으로 무엇을 하는지에 관한 설명이다.
• 4 객체지향 분석 과정에서는 응답 시간, 실행 플랫폼, 개발 환경, 프로그래밍 언어 들을 고려해야 한다.

확인

정답 및 해설

정답입니다.

정답 : 4번

일반적으로 분석 과정에서는 구현과 관련된 제약 사항을 고려하지 않는다. 

요구사항 분석 활동으로 보기 어려운 것은?

• 1 객체 또는 클래스 찾기
• 2 클래스의 속성 찾기
• 3 객체의 메소드 구현하기
• 4 시퀀스 다이어그램 만들기

확인

정답 및 해설

정답입니다.

정답 : 3번

요구사항 분석은 추출 과정에서 만들어진 요구사항 명세서(유스케이스와 유스케이스 다이어그램)를 정형화하고 구체화하는 작업이다. 이 과정에서 개념 모델(클래스 다이어그램)과 액터와 시스템 간의 상호작용(시퀀스 다이어그램)을 표현한다. 시퀀스 다이어그램을 작성하면서 빠져있는 객체, 속성, 오퍼레이션 등을 추가할 수 있다. 

유스케이스들 간의 확장 관계와 포함 관계를 설명한 것이다. 잘못된 것은?

• 1 포함 관계에 공통 유스케이스를 만드는 것은 공통의 기능이 반복되어 표현되는 것을 피하기 위함이다.
• 2 확장 관계에서 확장 유스케이스는 조건이 만족되는 경우에만 실행된다.
• 3 확장 유스케이스는 예외적 또는 선택적으로 일어나는 행위를 표현한다.
• 4 포함 관계에서 점선의 화살표는 공통 유스케이스에서 소스 유스케이스로 향한다.

확인

정답 및 해설

정답입니다.

정답 : 4번

포함 관계에서 소스 유스케이스가 실행되면 공통 유스케이스는 항상 실행되나 확장 관계에서 확장 유스케이스는 조건이 만족될 때만 실행된다. 포함 관계에서 화살표의 방향은 소스 유스케이스에서 공통 유스케이스로 향한다. 

객체지향 개발 방법에서 프로젝트의 설계 목표를 정의하고 시스템을 서브시스템들로 분해하는 단계로 볼 수 있는 것은?

• 1 요구사항 분석 단계
• 2 시스템 설계 단계
• 3 객체 설계 단계
• 4 통합과 테스트 단계

확인

정답 및 해설

정답입니다.

정답 : 2번

아키텍처를 설계하는 일은 전체 제어 구조나 동시성 관리, 데이터 관리, 접근 제어 등을 포함하는 것으로 시스템 설계 단계에서 수행된다. 

UP 개발 과정의 4단계에 관한 설명으로 맞지 않는 것은?

• 1 도입 - 시스템 범위의 설정, 타당성 조사
• 2 정련 - 10% 정도의 유스케이스를 상세히 작성
• 3 구축 - 남아 있는 덜 중요한 부분을 구현하고 통합함
• 4 전이 - 사용자 환경에서 시스템을 설치

확인

정답 및 해설

정답입니다.

정답 : 2번

정련 작업이 끝나는 시기에서는 80% 정도, 즉 대부분의 요구사항이 상세히 작성되어진다.
또한 정련 단계에서는 중요 요구사항을 설계하고 구현까지 한다.