Computer Science/Software Engineering

[CS][소프트웨어공학] 객체지향방법론, UML, 유스케이스 다이어그램

y-seo 2023. 10. 16. 16:03
 
 

[1] 객체지향 개념

  • 객체지향 방법론
    • 현실세계의 개체(Entity)를 속성과 메소드를 결합시킨 객체 형태로 표현하는 개념
    • 객체 간의 메시지 통신을 통해 시스템을 구현하는 개발 방법
  • 객체지향의 핵심개념은 객체와 "클래스"이다.
  • 객체지향의 기본원리
    • 캡슐화(Encapsulation)
    • 정보은닉(Information hiding)
    • 상속(Inheritance)
    • 다형성(Polymorphism)
  • 객체(Object)는 현실세계에 존재하거나 생각할 수 있는 개념을 표현한 것이다.
    • 물리적 객체, 개념적 객체가 있다.
  • 객체가 되려면 상태를 가져야 한다.
    • 객체가 가지는 자료 값이 상태를 표현한다.
    • 시간이 흐르면서 변화할 수 있어야 한다.
    • Ex. 강좌의 상태 : open & close
  • 객체는 잘 정의된 오퍼레이션이 있어야 한다.
    • 객체의 오퍼레이션은 동작을 결정한다.
    • 객체가 무얼하는지 결정한다.
    • 객체 외부에서 요구할 때 오퍼레이션을 호출한다.
    • Ex. 강좌 시간 결정, 수강생 추가, 수강생 삭제
  • 객체는 고유한 identity가 있어야 한다
    • 객체를 구별할 수 있는 수단이다.
    • 객체에 고유한 이름을 부여하여 객체명으로 구분하는 것이 일반적이다.
  • 클래스 (class)
    • 공통의 속성과 행위를 가진 객체를 묶어 추상화한 개념
    • 객체를 구현하는 방법
    • 객체의 틀이라고도 한다.
    • 인스턴스 (instacne) : 클래스에서 파생된 하나의 실제 객체 (objects = instances of classes), 값을 가지는 것
    • Ex. 클래스는 설계 도면으로 이걸 토대로 상체가 만들어지면 객체라고 한다.
  • 클래스 & 객체
    • 클래스는 개념적인 의미, 객체는 구체적인 의미라고 볼 수 있다.
    • 한 클래스에서 생성된 객체들은 같은 속성과 같은 연산에 대한 정의를 가진다.

 

 
 

[2] 객체지향의 원리

  • 상속(Inheritance)
    • 객체지향 패러다임만이 갖는 고유 특성
    • 클래스 간의 계층구조를 통해 상위클래스의 모든 특성을 물려받는 것
    • 상위 클래스가 가지고 있는 것은 하위 클래스도 자동으로 가진다.
    • 이미 정의한 클래스를 재사용하고, 확장 할 수 있도록 지원하는 개념
  • 캡슐화(encapsulation)
    • 객체에 대한 외부로부터 접근을 제한
    • 데이터를 밖에서 함부로 접근할 수 없도록 막은 것
    • 공개된 부분인 인터페이스를 통해서면 접근할 수 있도록 한다.
    • 접근제어자(private, public)을 통해 손쉽게 제어 가능
    • 관련된 항목을 모아서 하나의 단위로 취급하는 것
    • 객체내부의 변경이 시스템 전체(외부)에 주는 영향을 최소한으로 억제하낟.
  • 데이터 은닉 (information hiding)
    • 캡슐화와 데이터 은닉이라는 개념을 거의 같게 본다.
    • 캡슐화와 비슷한 개념으로 객체의 상세한 내용을 객체 외부에 철저히 숨긴다.
    • 단순히 메시지만으로 객체와의 상호작용을 하게 만든다.
    • 외부에서 알아야 하는 부분만 공개하고, 나머지는 숨김으로써(추상화의 원리) 대상을 단순화시키는 효과가 있음 (독립성 → 유지보수성 → 이식성 모두 보장) 
    • 단위를 꼭 잘 만들어 놔야 한다.
    • 객체지향언어의 접근 제어방식으로 구현 : public/private/protected
  • 다형성(polymorphism)
    • 객체지향 패러다임만이 갖는 고유 특성
    • 여러 가지 형태를 가질 수 있다는 것을 뜻한다.
    • 프로그램 언어의 각 요소들(상수, 변수, 식, 오브젝트, 함수, 메소드 등)이 다양한 data type에 속하는 것이 허가되는 성질
      • Ex. 같은 이름으로 함수를 만들 수 있음 (이때 매개변수의 구성은 다르게 해야 한다.)
    • 즉, 서로 다른 객체가 동일한 메시지에 대하여 서로 다른 방법으로 응답할 수 있는 기능이다.
      • Overriding : 같은 이름의 메소드가 여러 클래스에서 다른 기능을 하는 것
      • Overloading : 같은 이름의 메소드가 인자의 개수나 자료형에 따라서 다른 기능을 하는 것

 

 
 

[3] UML의 이해

  • UML(Unified Modeling Language)
  • 초기엔 대표적인 모델링 언어
  • 객체 지향의 처음과 끝이라고 할 수 있다.
  • 객체 지향 방법론 = UML, 거의 대신하는 대상이 되었다.
  • 1990년 초기 객체지향 방법론 등장하면서, 표기법의 차이가 문제로 대두 → OMT + OOSE + OOAD 합쳐버림
  • 1997년 OMG에 의해 표준 채택이 되었다.
    • Object Management Group (OMG) : 컴퓨터 산업 표준화 컨소시움
  • 가장 최근 버전 : 2017년 발표된 UML 2.5.1
  • 특징 (UML이 제공하는 것)
    • 가시화
      • SW 개념 모델을 시각적인 그래픽 형태로 표기
      • 표기법에 사용하는 기호에 명확한 정의를 부여하는 것
      • 의미를 직관적으로 이해할 수 있게 하는 것
      • 사용자 요구를 전달 받거나 개발자들 사이의 의사소통에서도 중요하게 사용된다.
    • 명세화
      • 정확하고 명백하며 완전한 모델을 만드는 것
      • 시스템 아키텍처와 모든 상세 내역에 대한 문서화가 가능해지도록 한다.
      • 요구사항이 다 들어가 있어야 한다.
    • 구축
      • UML로 명세화 된 설계 ↔ 소스코드
      • 바로 자동 전환/변환 가능
      • 가능한 이유 : 객체지향 방법론은 분석과 설계가 구분되어 있지 않기 때문이다.
  • UML 확장 메커니즘
    • 추가로 필요한 것을 만들어 쓸 수 있게
    • 스테레오타입(stereotype)
      • 기본적인 요소 외에 새로운 요소를 만들기 위함
      • << >> 기호를 사용
      • Ex. <<subsystem>>
    • 꼬리표값(tagged values)
      • 구성 요소가 갖는 속성을 확장하여 구성요소의 명세서에 새로운 정보를 추가
      • 값을 지정
      • tag = value 기호를 사용
    • 제약(constraints)
      • 구성 요소에 있는 이전의 규칙을 수정하거나 새롭게 값을 생성하기 위함 
      • 제약 사항 표시
      • 꼬리표값과 함께 사용되기도 함
      • { } 기호를 사용

 

 
 

[4] 객체지향방법론

  • 구조적 개발 방법론과 비교된다.
  • 1970년대
    • 프로그램을 여러 개 작은 부분으로 쪼개어 개발하는 "구조적 개발방법론" 사용
    • 프로그램의 논리와 데이터를 분리해서 소프트웨어를 설계 → 개발단계 별로 자연스럽게 연결되지 않고 유지보수 비용이 많이 발생
      • 유지보수가 쉬우려면 모듈이 잘 설계되어 있어야 함 → 이걸 위해 객체지향 개발방법론이 탄생
    • 객체지향 개발방법론 등장 : 인간이 사고하는 방식대로 프로그램을 개발하려는 노력으로 탄생
    • 구조적 개발방법론과 객체지향 개발방법론은 접근 방법 자체가 다름
  • 1990년대 들어서면서 여러 SW 기술 중에 객체지향방법론이 가장 중요한 기술로 인식됨
    • SW 위기 현상이 객체 지향 기술로 인하여 해결될 수 있다는 공감대가 형성됨
    • 소프트웨어 생산기술의 초점이 프로그래밍에서 분석, 설계로 옮겨지면서 더욱 주목을 받음 ★★★
      • 잘 쓰려면 분석/설계가 잘 되어야 한다
      • 그 관점에 한 몫을 한 것이 객체지향
      • 객체지향은 분석/설계/구현이 하나의 흐름이므로 수월
    • 개발생산성을 높이는 방법을 제공 (재사용 지향)
    • 일관된 소프트웨어 개발 모델 제공
  • 구조적 개발방법론
    • 특징 : 함수, 처리, 프로세스가 중요 
    • 단점 : 분석/설계/구현 단계마다 용어/개념이 다름, 작은 변화에도 영향이 큼
  • 객체지향 개발방법론
    • 클래스인 객체 사이의 호출/응답이 중요, 클래스를 어떻게 잘 설계할지가 관건
    • 함수와 자료를 함께 객체로 추상화함 → 변화에 영향을 덜 받음
    • 장점 : 분석/설계/구현이 하나의 개념으로 연결됨, 추상화/정보은닉 등 설계 원리에 충실(class가 이것을 잘 반영), 복잡함을 잘 다룰 수 있음(class를 묶어 package도 만드는 중)
    • 특징 : 뚜렷하게 구별되는 단위인 객체(object)로 분할, 코드 재사용에 의해 생산성을 높임, 빠른 속도로 적용하여 산업계 표준화가 됨
  • 객체지향 개발의 특징
    • 반복적인 프로세스
    • 솔기 없는 프로세스
    • 상향식 접근 방식
    • 재사용을 고려

 

 
 

[5] 객체지향방법론의 특징

  1. 반복적인 프로세스
    • 분석&설계가 구분 없이 계속 반복됨 (만들어 둔 것을 계속 refine)
    • 소프트웨어 생명주기를 반복하여 적용하도록 제안
  2. 솔기 없는 프로세스
    • seamless 프로세스
    • 프로세스를 구성하는 각 단계 간의 경계선이 불분명
  3. 상향식 접근 방식
    • 구조적 방법론 : 하향식 (Top Down) 프로세스를 사용
    • 객체지향 방법론 : 상향식 프로세스를 사용
    • 가장 작은 단위를 찾아내어 넓혀감 (컴포넌트→시스템)
  4. 재사용을 고려
    • 구조적 방법론 : 성공적인 SW 산출물을 만들고자 하는 개발 공정에 치중
    • 객체지향 방법론 : 재사용이 고려되어 프로세스가 진행
  • 객체지향 방법론은 크게 3가지가 있다.
    1. 기능 모델링
    2. 구조 모델링
    3. 행위 모델링

 

 
 

[5.1] 기능 모델링 개요

  • 소프트웨어 분석을 위한 객체지향 방법론의 첫번째 활동
  • 사용자로부터 도출한 요구사항으로부터 소프트웨어 시스템이 해야 할 기능이 무엇인지를 식별해가는 과정
  • 유스케이스 다이어그램 
    • 시스템과 관련된 외부 요소들을 표현
    • 얘로 기능 모델링 표현
    • 배경도와 비슷한 의미
    • 가장 많이 쓰이는 것
    • 나와 소통하는 다른 것들 표현
  • 유스케이스 작성
    • 시스템이 사용자에게 눈에 보이는 결과를 생성하기 위해 수행하는 작업을 순서대로 정리 해 놓은 것
    • 유스케이스 다이어그램 작성 후 해야 할 일
    • 각 유스케이스마다 작성해야 함
  • 유스케이스 작성의 목적
    • 외부 액터에 의해 인식되는 시스템의 기능과 요구사항을 보여주기 위함
    • 시스템의 범위를 정하는데 도움이 됨
    • 개발 과정을 계획하는데 사용
    • 요구를 개발하고 검증하는데 사용
    • 테스트케이스를 정의하는데 기초가 됨 → 사용자가 원하는 것이 잘 만들어졌는지 확인하기 위해
    • 사용자 매뉴얼 구성하는데 사용될 수 있음

 

 
 

[5.1.2] 유스케이스 다이어그램

  • 시스템 최상위 수준에 해당하는 기능을 사용자 관점으로 나타내는 것
    • 사용자가 시스템을 통해 제공받는 주요 기능과 시스템과 사용자 간의 상호작용을 표현
  • 유스케이스 (UseCase, 사용사례, 쓰임새)
    • 외부에서 본 시스템의 뷰
    • 사용자의 관점에서 시스템이 제공하는 서비스를 나타낸 것
    • 시스템과 외부 사용자(액터, actor) 사이의 목표지향적인 인터랙션의 집합
  • 유스케이스 다이어그램 구성요소
    • actor, usecase, 관계
  • 작성 절차
    1. 요구사항 정의 내용을 검토한다.
    2. 요구사항을 토대로 시스템의 경계를 결정한다.
    3. 경계가 설정된 시스템에 대한 명칭(시스템 명)을 정의한다.
    4. 시스템 외부에 존재하는 액터를 식별하고, 각 액터의 역할을 정의한다.
    5. 각 액터가 시스템에서 사용하는 기능을 식별한다.
    6. 식별된 기능(유스케이스)과 액터 간의 관계를 정의한다.
    7. 유스케이스 명세서(Use Case Description)를 작성한다. = Use Case를 작성한다.
  • TIP
    • 간단한 것이 좋다.
    • 기능은 다 표현되어야 한다.
    • 복잡할 필요가 없다.
    • 관계를 잘 설정해야 코드를 잘 작성할 수 있다.

 

 
 

[5.1.2] 유스케이스 다이어그램 - 액터

  • 시스템으로부터 서비스를 받는 외부 요소
  • 사람(역할), 시스템, 조직을 표현한다.
  • 외부에 존재하는 상호작용 대상이다.
  • 역할을 중심으로 식별한다.
  • Ex. James라는 사람이 시스템 사용자이면서 시스템 관리자 역할을 할 때, 액터는 사용자와 관리자의 두 가지로 식별해야 한다.
  • 표현 모습

 

 
 

[5.1.2] 유스케이스 다이어그램 - 유스케이스

  • 액터에게 서비스를 제공하기 위해 시스템이 수행하는 중요 프로세스
  • 유스케이스 이름은 작업을 의미하는 동사구 형태
    • Ex. 도서주문, 회원가입, 처방전발급
  • 유스케이스는 액터에 의해 시작되어야 한다.
  • 단일 유스케이스가 여러 액터에 의하여 구동 될 때 분리할지 말지 고민해야 하는데, 다른 액터가 구동될 때 작업이 동일하면 같은 유스케이스이고, 이벤트 흐름이 다르면 다른 유스케이스이다.
  • 하나의 유스케이스는 동작 수행에 대한 종료를 포함하도록 정의해야 한다.
    • 유스케이스가 시작되기 위한 사전 조건이 필요하고, 끝났을 때 결과로 나올 사후 조건 존재한다.
    • 유스케이스 사이에는 흐름이 없다
    • 유스케이스 1개는 외부 액터와 어떻게 interaction 할지만 구성하면 된다.
  • 유스케이스는 level이 아닌 1개의 Diagram이다.
  • 유스케이스는 사이즈를 다들 비슷하게 설정해야 한다.

 

 
 

[5.1.2] 유스케이스 다이어그램 - 관계

  • 연관관계 (association)
    • 커뮤니케이션 관계로 유스케이스와 액터 사이의 관계
    • = interaction을 나타내는 것

  • 의존관계 (dependency) : 유스케이스들 사이의 관계, 업무의 흐름과 상관 없다, 의존성 여부를 나타내는 것
    • 포함 (include) 관계
      • 공통의 유스케이스를 별도로 정의
      • base 유스케이스를 실행하기 위해 반드시 included 유스케이스가 실행되어야 한다.
      • 예시 : 주문 변경을 하려면 주문을 찾는 것을 먼저 해야 한다.
      • 공통되는 유스케이스를 뽑아 따로 만든다.
      • 화살표 방향이 included 쪽으로 향하도록 표현한다.

  • 의존 관계 (dependency)  
    • 확장관계
      • 유스케이스의 동작을 조건적으로 확장
      • 이벤트의 추가나 예외적인 케이스
      • 화살표가 base 쪽으로 향하도록 표현한다.

  • 일반화 관계 (generalization)
    • 유스케이스와 유스케이스, 또는 액터와 액터 사이의 관계
    • 상속을 나타낸다.

 

 
 

[5.1.2] 유스케이스 작성

  • 모든 usecase에 대해 usecase 명세서를 작성해야 한다
  • 유스케이스에 대한 간단한 식별 정보와 유스케이스 내부에서 처리해야 하는 기능의 상세한 흐름을 나타낸다.

 

 
 

[5.1.3] 유스케이스 사건 흐름

  • 기본 흐름
    • 유스케이스의 여러 시나리오 중에서 가장 일반적이고 정상적인 상황을 나타내는 하나의 이벤트 흐름
  • 대안 흐름(Alternative Flow)
    • 한 유스케이스에서 기본 흐름이 표현하는 상황을 제외한 모든 다른 상황
    • 수행이 끝나면 기본 흐름으로 돌아오는 경우도 있고 대안 흐름에서 종료되는 경우도 있다.
    • 선택 흐름과 예외흐름이 있다.

 

저작자표시