3 minute read

> 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)
      • 시간에 따라

UML

Unified Modeling Language

  • 시스템의 설계를 시각화 하여 표준화된 방법론을 제공하는 모델링 언어
    • 설계를 표현하는 수단 (방법론이나 프로그래밍 언어는 아님)

OOA: Requirement Analysis

  • Requirements (요구)
    • 시스템이 반드시 따라야 하는 기능, 내부 성능, 조건 등
  • Requirement analysis (요구 분석)
    • 시스템이 필요한 것이 무엇인지 찾고 정리
    • 고객 및 개발자에게 모두 명확하게 표현될 수 있어야함
    • 요구가 반복적으로 분석/수정 됨

요구의 유형 (FURPS)

  • 기능적 요구 (Functional)
    • Function(기능): 시스템이 외형적으로 나타내는 기능
      • 사용자 인증, 데이터 검색 및 처리 등
  • 비기능적 요구 (non-functional)
    • Usability(사용성): SW를 쉽게 이해/사용하게 하기
      • UI, 도움말 등
    • Reliability (신뢰성): SW가 안정적으로 동작하게 하기
      • 오류 복구, 장애 안정성 등
    • Performance (성능): SW의 성능에 관한 사항
      • 응답 시간, 처리량, 대기 시간 등
    • Supportability (지원성): 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 문서 작성

  • 사용자 시나리오와 요구 사항을 문서화
    • 각 사용 사례에 대해 사용자와 시스템의 동작을 사건 기록 일지처럼 작성한다