[SAD] 3. Object-Oriented Analysis (1)
> Go to Software Analysis and Desgin Contents
Unified Process for Developing OOSW
- 소프트웨어 개발 절차

Unified Process (UP)
객체지향 SW를 개발할 때 주로 사용되는 반복적 SW 개발 절차
- 고정된 기간 내에서 반복적으로 수행
- Agile 정신으로부터 영향을 받았다.
4 Phases of Unified Process
UP에서는 개발 과정을 4 Phase로 나눈다.
Phase 1. Inception (도입부)
프로젝트의 방향(vision), 요구 및 사용사례(case), 범위(scope), 비용(cost)등을 대략적으로 파악하는 구간
Phase 2. Elaboration (세부화)
위의 단계에서 정의된 초기 계획과 개념을 자세히 확장/명시화 한다.
초기 설계 및 계획을 확립하고 리스크를 관리하는데에 중점을 둔다.
Phase 3. Construction (구축)
이전 단계에서 정의된 요구사항, 아키텍쳐 및 설계를 기반으로 SW를 반복적으로 개발
실질적으로 개발이 시작되는 부분
Phase 4. Transition (전환)
사용자들이 소프트웨어를 사용할 수 있도록 준비 (베타 테스트, 배포, 유지 보수 등)
9 Disciplines of Unified Process

Key Practices of Unified Process
- 초기 단계에서 어떤 작업이 high-risk & high value 인지 파악
- 초기 단계에 핵심 아키텍쳐 구축
- UML로 시각적 모델링
- 사용자로부터 지속적으로 평가와 피드백
- 다양한 문서, 모델, 코드와 같은 산출물 생성 및 관리
OOAD with UML
- Object-Oriented analysis (OOA)
- Domain concepts 또는 objects를 파악 및 도출
- Object-oriented design (OOD)
- SW objects를 정의 (static)
- 정적인 것
- 요구사항을 만족될 수 있도록 객체 간의 협력을 정의 (dynamic)
- 시간에 따라
- SW objects를 정의 (static)
UML
Unified Modeling Language
- 시스템의 설계를 시각화 하여 표준화된 방법론을 제공하는 모델링 언어
- 설계를 표현하는 수단 (방법론이나 프로그래밍 언어는 아님)

- 설계를 표현하는 수단 (방법론이나 프로그래밍 언어는 아님)
OOA: Requirement Analysis
- Requirements (요구)
- 시스템이 반드시 따라야 하는 기능, 내부 성능, 조건 등
- Requirement analysis (요구 분석)
- 시스템이 필요한 것이 무엇인지 찾고 정리
- 고객 및 개발자에게 모두 명확하게 표현될 수 있어야함
- 요구가 반복적으로 분석/수정 됨
요구의 유형 (FURPS)
- 기능적 요구 (Functional)
- Function(기능): 시스템이 외형적으로 나타내는 기능
- 사용자 인증, 데이터 검색 및 처리 등
- Function(기능): 시스템이 외형적으로 나타내는 기능
- 비기능적 요구 (non-functional)
- Usability(사용성): SW를 쉽게 이해/사용하게 하기
- UI, 도움말 등
- Reliability (신뢰성): SW가 안정적으로 동작하게 하기
- 오류 복구, 장애 안정성 등
- Performance (성능): SW의 성능에 관한 사항
- 응답 시간, 처리량, 대기 시간 등
- Supportability (지원성): SW 유지 보수 및 지원
- 시스템 업그레이드, 기술 지원 등
- Usability(사용성): SW를 쉽게 이해/사용하게 하기
Example
- Banking App. 모바일 기기를 이용하여 원격으로 금융 거래를 하는 시스템
| 기능적 요구 | 비기능적 요구 |
|---|---|
| 사용자 인증 (Log in) | 거래는 2초 내에 수행되어야 함 |
| 사용자 프로필 설정 (Set up profile) | 자료 백업을 위해 00:00부터 10분 동안의 다운을 허용 |
| 계좌 잔고 확인 (Check balance) | 중복 거래는 발생해서 안됨 |
| 송금 (Transfer funds) | 자주 이용하는 고객을 위해 시스템 확장 가능하도록 설계 |
| 결제 (Make payments) | 자주 사용하는 기능에 대한 도움말 준비 |
| …… | …… |
요구를 정리하는 법
- 요구 분석서의 작성
- 문제: 시스템이 해결하고자 하는 문제 (간단명료하게 작성)
- 배경: 요구를 이해하는데 도움이 되는 사전 정보
- 환경 및 시스템: 시스템이 수행될 배경 / 시스템 및 서브시스템의 개요
- 특히 큰 시스템이 작은 여러 서브시스템으로 나눈 경우
- 기능적 요구: 사용자나 다른 시스템을 위해 제공하는 기능적 서비스
- 시스템이 사용되는 시나리오를 기반으로 사용 사례 (use-case)를 기술
- Use-case diagram/Use-case specification 작성
- 비기능성 요구: 시스템 설계에 부여되는 상세 및 제약 사항
- 보통 문서의 형태로 정리 (bulletized)
- 이러한 문서를 supplementary specification이라고 함
OOA: Use Case Analysis
- 사용 사례 (use-case) 분석
- 시스템 사용에 대한 시나리오로 사용자 관점에서 시스템을 모델링
- 사용자가 시스템에 대하여 바라는 바를 표현
- 프로젝트 초기 단계에서 목표 시스템의 세부 기능을 파악하는데 도움
- 일반적으로 기능적 요구에 대해서 사용 사례 분석을 함
Step 1.시스템 요구 분석 및 System, Actor, usecase 정하기
시스템이 어떤 기능이 필요한지 먼저 정한 후,
System및 Actors를 정한다. (Actor: system을 사용하려는 대상)
그 후 Actor에 따른 Usecase를 정한다.
Step 2. Use case diagram 그리기 (overview)
Use-case 범위

- 만들려고 하는 대상
- 직사각형으로 표시
- 직사각형 내로 시스템의 범위를 정함
Actors

- 시스템을 사용하려고 하는 대상
- 사람, 조직, 디바이스, 다른 시스템 등등
- Stick figure로 표현
- System 밖에 위치
- 카테고리로 표현 (General)
- Primary actors: 왼쪽에 위치
- 시스템의 사용을 시작하는 actor
- Secondary actors: 오른쪽에 위치
- 요청에 반응하여 서비스를 제공하는 actor
Use-case
- 시스템이 제공하는 기능
- 타원형으로 표현
- 동사로 시작 (action)
- 충분히 설명이 될 수 있되 최대한 간결하게 표현
- 논리적 순서로 use cases를 배치
Association Relationship
- Actor와 use-case 간의 상호 작용
- 선으로 이어서 표현
Inclusion Relationship
- Inclusion (포함)
- Base use case가 수행되면 included use case는 반드시 수행되어야 하는 경우
Extension Relationship
- Extension (확장)
- Base use case가 수행되고 특정 조건을 만족하는 상황에 extension 수행
Inclusion v.s. Extension?
Inclusion: 반드시 수반되어 수행!
Extension: 특정 상황에서만 수행 (안될수도 있음)
- 화살표 방향에 유의하기!!!
- include: base to included
- extend: extended to base
Multiple Inclusions
두가지 상황에서 모두 돈이 있는지 확인
Generalization Relationship
- Generalization (일반화)
- 유사한 actor/use case에서 공통된 부분을 묶어 일반화한 관계
Use-case with Extension Points
- 확장 관계의 detailed version
- 더 많은 Extension 표현
- 필요하면 조건에 대한 내용을 노트로 추가
ㅌ
Use case specification 문서 작성
- 사용자 시나리오와 요구 사항을 문서화
- 각 사용 사례에 대해 사용자와 시스템의 동작을 사건 기록 일지처럼 작성한다