[SWAD] Ep.3 OOA(1)

GLICO·2024년 10월 25일

SWAD

목록 보기
3/12

Contents

  • 객체지향 SW 개발 절차 - Unified process
  • 요구사항 및 사용사례 분석

Unified Process for Developing OOSW

SW development process

  • 소프트웨어 개발, 배포, 관리에 대한 체계적인 접근 방법

Unified Process (UP)

  • 객체지향 SW를 개발할 때 주로 사용되는 반복적 SW 개발 절차
    고정된 기간내에서 반복적으로 수행.
    Agile 정식으로부터 영향을 받음(Iterative & Incremental)

4 Phase of Unified Process

    1. Inception (도입부)
      프로젝트의 방향(vision), 요구 및 사용사례(case), 범위(scope), 비용(cost) 등을 대략적으로 파악
    1. Elaboraton (세부화)
      Inception 단계에서 정의된 초기 계획과 개념을 자세히 확장/명시화
    1. Construction (구축)
      이전 단계에서 정의된 요구사항, 아키텍처 및 설계를 기반으로 SW을 반복적으로 개발
    1. Transition (전환)
      사용자들이 소프트웨어를 사용할 수 있도록 준비하는 단계

Key practices of UP

  • 초기 단계에서 어떤 작업이 high-risk & high value인지 파악
  • 초기 단계에서 핵심 아키텍처를 구축하고 이를 중점으로 개발 진행
  • UML을 이용해서 시각적으로 모델링하기
  • 사용자로부터 지속적으로 평가와 피드백을 받기
  • 지속적으로 quality verification & test를 수행
  • 분야에 맞추어 다양한 역할과 책임 부여됨
  • 다양한 문서, 모델, 코드와 같은 산출물(artifacts) 생성되고 관리됨

OOAD with UML

Object-oriented analysis(OOA)

  • Domain conecepts 또는 Objects를 파악/도출

Object-oriented design(OOD)

  • SW objects를 정의(Static)
  • 요구 사항을 만족할 수 있도록 객체 간의 협력을 정의(Dynamic)

OOAD Example with UML

  • OOA
    Doman Model
    Use-case Model(+ System Sequence Diagram)

  • OOD
    Sequence Diagrams
    Class Diagrams

UML

  • Unified Modeling Language
  • 시스템의 설계를 시각화하여 표준화된 방법론을 제공하는 모델링 언어

OOA : Requirement Analysis

Requirements (요구)

  • 시스템이 반드시 따라야하는 기능, 내부 성능, 조건 등을 말함

Requirement analysis (요구 분석)

  • 시스템이 정말로 필요한 것이 무엇인지 찾고 정리하는 과정
  • 고객 및 개발자에게 모두 명확하게 표현될 수 있어야 함
  • UP에서는 요구가 반복적으로 분석/수정 됨

요구의 유형 (FURPS)

기능적 요구 (Functional)

  • Function(기능) : 시스템이 외형적으로 나타내는 기능

비기능적 요구 (non-Functional)

  • Usability(사용성) : SW를 쉽게 이해/사용하게 하기
  • Reliability(신뢰성) : SW가 안정적으로 동작하게 하기
  • Performance(성능) : SW의 성능에 관련된 사항
  • Supportability(지원성) : SW 유지 보수 및 지원

OOA : Use Case Analysis

사용 사례 분석

사용 사례(Use-case) 분석

  • 시스템 사용에 대한 시나리오로 사용자 관점에서 시스템을 모델링
  • 사용자가 시스템에 대하여 바라는 바를 표현
  • 일반적으로 기능적 요구에 대해서 사용 사례 분석을 함

사용 사례 분석 과정

  1. 시스템 요구 분석
  2. System 및 Actors 정하기
  3. Use case 정하기
  4. Use case diagram 그리기
  5. Use case sepcification 문서 작성

Systems

  • 만들려고 하는 대상
    직사각형으로 표시
    직사각형 내로 시스템의 범위를 정함 (External / Internal world)

Actors

  • 시스템을 사용하려고 하는 대상
    사람, 조직, 디바이스, 다른 시스템 등등.
    Stick figure로 표현 (External world에 위치해야함, 카테고리로 표현)

Primary actors

  • 시스템의 사용을 시작하는 actor (시스템 왼쪽에 위치)

Secondary actors

  • 요청에 반응하여 서비스를 제공하는 actor (시스템 오른쪽에 위치)

Use-case

  • 시스템이 제공하는 기능
    타원형으로 표현, 최대한 간결하게, 논리적 순서대로 배치

Association

  • Actor와 use-case간의 상호 작용
    선으로 이어 표현

Inclusion(포함)

  • Base use case가 수행되면 Included use case는 반드시 수행되어야 하는 경우
    Base Use Case ---- << include >> ----> Extend Use Case

Extension(확장)

  • Base use case가 수행되고 특정 조건을 만족하는 상황에 수행
    Base Use Case <---- << extend>> ---- Extend Use Case

Multiple Inclusions

Inclusion vs Extension

  • Inclusion은 반드시 수반되어 수행되지만, Extension은 수행될 수도 안될 수도 있음(특정 상황에서만 수행)
  • 화살표 방향에 유의!!

Generalization(일반화)

  • 유사한 actor/use case에서 공통된 부분을 묶어 일반화한 관계

Extension Points

  • 확장 관계의 Detailed version
    더 많은 extension을 표현
    필요하면 조건에 대한 내용을 노트로 추가

사용 사례 명세서(Specification)

사용자 시나리오와 요구 사항을 문서화

  • 각 사용 사례에 대해 사용자와 시스템의 동작을 사건 일지 처럼 작성

사용 사례 명세서 작성 가이드 라인

  • 사용 사례 이름
  • 액터 : 사용자/외부 시스템
  • 목적 : 액터가 얻으려는 목적 설명
  • 시작 조건 : 액터가 이 사용 사례를 구동하기 위해 선행되어야 할 조건
  • 관련 사용 사례 : 사용 사례 사이의 연관성
  • 사건의 흐름 : 액터가 취한 액션과 시스템의 반응을 시간 경과 순으로 나열
  • 종료 조건 : 사용 사례가 종료된 후 시스템의 상태
profile
Its me Glico

0개의 댓글