학교 수업 정리/소프트웨어공학

[소공 수업 정리] Software & System Modeling UML

hjr067 2024. 12. 10. 21:42

UML Manual

 

소프트웨어 모델링

  • 모델 : 대상을 특정 관점을 기준으로 표현하는 것
  • 소프트웨어 모델 : 수행해야 하는 기능의 관점에서 소프트웨어를 표현 - 전체 시스템을 포괄적으로 표현
    • 다양한 모델링 관점 사용:
      • 구조적 모델 - class diagram, object diagram etc.
      • 동적 모델 - 상태 diagram, sequence diagram etc.
      • 행위 모델 - usecase diagram, activity diagram etc.
  • 논리적 모델 (What) : 시스템은 무엇이며 어떤 기능을 해야 하는가를 표현 - 시스템의 개념적 설계나 데이터와 그 관계를 추상적으로 표현한 것 (기술적인 세부사항 배제, 본질적인 부분만을 설명)
    • 시스템이 무엇을 해야 하고, 어떤 데이터를 다루는지, 사용자는 어떤 기능을 이용할 수 있는지
    • ER diagram, UML usecase diagram etc.
  • 물리적 모델 (How) : 시스템이 실제 어떻게 구현되어야 하는지 기술적인 면을 고려하여 표현
    • 기술적 제약 사항(언어, 플랫폼, 하드웨어)을 반영, 기술 스택, 데이터베이스 세부 구현 사항
  • 모델링: 모델을 만드는 것
    • 모델링 3요소
      • 규약 - 모델링에 사용되는 요소의 정의
      • 표현 - 규약을 이용하여 모델링 한 결과
      • 명세 - 표현된 모델에 대한 상세 내용을 서술하는 것
  • 객체 지향 - 주요 개념: Abstraction, Encapsulation, Inheritance, Polymorphism
    • 클래스
    • 객체
    • 메소드

UML (the Unified Modeling Language) : 1980-90년대에 객체지향설계(OO-object oriented)를 설명하기 위한 다양한 표기법이 제안됨 -> 이러한 표기법들을 하나로 통합한 것

  • UML은 객체 지향 분석 및 설계 도중 생성될 수 있는 다양한 모델에 대한 표기법을 나타낼 수 있음, 객체 지향 모델링 (OO modeling)의 사실상 표준
  • OMT + Booch + OOSE + ...
  • Views of UML
    • Use-case view : 시스템의 기능적인 측면 / use-case diagram
    • Logical view : 시스템의 기능들이 내부적으로 어떻게 설계될 수 있는지 / package diagram, class diagram. state diagram, sequence diagram, communication diagram(collaboration diagram), activity diagram
    • Component view : 컴포넌트와 컴포넌트와 관계를 보여주는 / component diagram
    • Concurrency view : 시스템 요소들에 대한 처리 방식(요소들 간 동기/비동기, 상호작용에 대한 사항 등). 개발자와 시스템 통합자를 위한 것 / dynamic diagrams(state, sequence, communication(collaboration) diagram), implementation diagrams (component, deployment diagrams)
    • Deployment view : 컴퓨터와 주변 장치로 구성된 컴퓨터의 실제 배치 / deployment diagram

Relationship 

  • 의존관계 (Dependency) - 어떤 spec에서 한 변화가 다른 것에 영향(역은 성립할 필요 X)
  • 연관관계 (Association) - 한 사물의 객체가 다른 객체와 연결 / binary association(common), n-ary도 가능 / name, role, multiplicity
  • 일반화 (Generalization) : superclass(parent)와 subclass(child) / "is-a-kind-of" relationship / parent가 사용되는 곳이면 어디든 child도 사용가능 (역은 X)
  • 집합 (Aggregation) : "has-a" relationship ("whole/part")
  • 집합 (Composition) : "has-a" relationship ("whole/part") / 강한 집합

 

Use Case Diagram

  • Actor와 Use Case의 관계를 도식화
    • Actor: 시스템에 대한 사용자 (non-human actor도 가능)
    • Usecase: User-visible function
  • Use Case는 시스템이 제공하는 기능을 나타내며, Actor에 의해 바라보는 관점으로 표현된다.
  • Use cases for the MHC-PMS : 나중에 test 시나리오를 작성하는 기반이 됨
  • use case modeling
    • 시스템과 사용자간의 인터랙션 식별
      • 각각의 use case는 actor(시스템을 사용하는 주체)가 정의되어야 한다.
      • 모든 usecase를 취합하면 시스템 모습이 된다.
    • 고객이 이해하기 쉬움
    • 요구사항을 모델링
      • (고객으로부터) 요구사항을 추출하는 초기단계 동안 수행 - 프로젝트에 대한 요구사항을 정의하는 과정에서 상위 수준의 usecase 모델 작성
    • 소프트웨어 test 시나리오 작성의 기반
  • Usecase 식별시 고려사항 (기능도출) : usecase는 어떤 일이 처리되는 각 단계가 아님! usecase는 시스템의 도움을 받아 처리하고자 하는 Actor의 요구작업 → process가 아니라 큰 기능 !!!

시나리오 (세부적인 내용은 알지 못하기에)

real-life example

- Usecase Scenario : 이름, 시작 행위자, 목표, 선행 조건, 정상 시나리오, 예외 시나리오, 동시 발생 가능한 내용, 종료 조건

  • Usecase Relationship (  -  -  -  <<include>> -  -  -   > ) ; 화살표 머리가 있는 쪽이 포함되어지는 usecase (하위) 
    • INCLUDE (포함): usecase가 다른 usecase를 포함하는 관계 (사용관계(USE))
      • 포함된 usecase는 절대로 단독으로 존재할 수 X, 현재 usecase의 부분으로만 존재
      • 여러 usecase에서 공통으로 중복되는 시나리오 (반복적으로 사용되는 기능 / 공통적인 작업) = 여러 개에서 INCLUDE되어있다는 관계라는 것. 이 시나리오를 따로 분리하여 새로운 usecase로 만들고, 새로 만든 걸 각 usecase마다 "INCLUDE" 시킨다.
    • EXTEND (확장): usecase 시나리오에서 어떤 조건에 따라 다른 usecase를 확장  ( -  -  - <<extend>>-  -  -  >) 
      • 확장 용도로 사용하기 위해 참조되는 usecase를 Extended Usecase라고 함
      • 참조하는 usecase : Base Usecase (여기에 화살표 머리를 둠)
      • 확장 usecase를 참조하는 지점 : Extended Point
    • GENERALIZATION (일반화): usecase를 상속하는 것을 의미
      • 자식 usecase는 부모 usecase의 모든 행동, 의미를 물려 받으며, 자신만의 행동을 추가 가능
      • 일반화 관계는 Actor 사이에도 적용 가능 (____▷) 머리쪽이 parent use case

Class Diagram - 좀 더 구체화를 시켜야 하는 것(반복해서 update 해야 됨)

Class = 속성 (attribute) + 메소드 (method, operation)

  • class 는 임의의 유사한 객체들을 명세하기 위한 스펙, 각 객체 생성 위한 템플릿
  • 속성 및 operation의 return type 표현식
    • + : Public, - : Private, # : Protected
  • 문장에서 명사는 class, 동사는 method 후보, class의 명사와 관련된 명사와 형용사는 속성(attribute) 후보, 클래스와 클래스 사이의 관계를 나타내는 동사는 관계(relation) 후보
  • Class 사이의 relationship
    1. Association : 클래스가 개념적으로 서로 연결되어 있음(1:1, 1:n, m:n)
    2. Qualifier - 식별 정보
      • 일대다(one-to-many)의 다중성 연관관계에서 한 객체가 특정한 객체를 가려내어야 하는 상황이 발생 할 때 식별 정보 지정 가능
      • Qualifier는 one-to-many의 다중성 연관관계를 one-to-one 다중성으로 줄이는 효과
    3. Inheritance (상속 관계) : "Is a kind of" Relation, Generization
      • root class : super class를 가지지 않음
      • Leaf class : sub class를 가지지 않음
    4. Aggregation - 하나의 클래스가 여러 개의 클래스로 구성되어 있는 경우
      • 부분 - 전체 (Part of) , "has-a", "consists-of" relationship
      • Notation: 빈 마름모
    5. Composition - 강한 집합 연관으로써 각 sub class가 오직 하나의 super class에 대하여만 의미를 가질 때
      • Notation: 채워진 마름모
    6. Dependency - 한 클래스(의 Operation)가 다른 클래스를 사용하는 관계를 말한다.
      • 시스템 클래스의 화면 표시 서식이 폼 클래스를 사용하면, 폼 클래스에 따라 서식이 달라짐

Association

  • Abstract Class 추상 클래스
    • 객체 생성하지 않는 클래스 - 구현 : 상속받아서 구체화시킴
    • Notation: 이태릭체 클래스명

Package Diagram

대부분의 시스템은 수많은 클래스로 이루어져 있다. 패키지는 연관된 class들의 집합이다.

  • View (MVC Architecture)
    • Entity class - Model : 시스템의 중심이 되는 필요한 내용을 모델링 (시스템 내부적인 일 수행)
    • Boundary class - View : 시스템 내부와 외부환경 사이의 communication을 다룸 (사용자 or 다른 시스템과의 interface 제공) / Flow of event 기반 / GUI 메커니즘 / 통신 프로토콜
    • Control class - Controller : 1개 이상의 usecase에서 나타나는 연속적인 behavior를 modeling / 주관적 / 연결고리

Sequence Diagram

시간 경과에 따라 객체 상호간 교류 과정을 표현

- Simple message

- Synchronous message : msg 전송 후 수신 객체로부터 그 msg를 받았다는 답변이 와야 자신의 작업을 계속할 수 있음

- Asynchronous message : msg 전송 후 수신 객체로부터 답신을 받지 않고 작업 (수신 여부와 상관없이 계속 진행)

Communication(Collaboration) Diagram

서로서로 메세지를 어떻게 주고받느냐에 따라 어떤 객체가 어떻게 연관되어 있는지 -> 관계 파악 용이

  • 객체 간의 상호관계를 보여줌
  • sequence diagram은 시간 순으로 시나리오를, collaboration diagram은 class들의 관계 파악 용이

Activity Diagram

  • 병렬 관계 표시도 가능!
  • 전체 시스템에서 동적인 시스템을 나타내기 위해 사용 (전체적 내용처리 ex. 흐름 / 시스템 제공 전체적 기능 모습)
  • 업무 과정의 활동 흐름을 표현하거나, Operation의 알고리즘을 나타내는데 사용한다.
  • Swimline
    • Activity diagram에 역할(role)을 표시함으로써 각 활동의 책임이 누구에게 있는지 나타낼 수 있다. (주체가 누군지)

State Chart Diagram

활동들의 결과로 인해 어떤 상태로 변화하는지 - 설계, 분석 단계에서 많이 사용

  • 사건이나 시간에 따라 시스템 객체의 상태 변화를 표현 / 단일 객체의 상태를 나타냄
  • State: 모서리 둥근 상자, Activities(entry, do, exit) -> 각각 시스템이 상태로 들어갈 때 일어남, 시스템이 상태 안에 있는 동안, 시스템이 상태에서 빠져나올 때
  • 시스템의 변화를 잡아내기 위해 사용함
  • substate도 가능

Component & Deployment Diagram

< Component Diagram >

  • 컴포넌트는 개발환경 내에서 실제적인 소프트웨어 모듈에 대한 구성으로 패키지와 관련된 구성요소 (물리적인 구성요소) 이다. 패키지와 1ㄷ1 관계가 아닐 수 있다. 
  • 컴포넌트 (↓ 다 물리적 요소!)
    • 소스코드 컴포넌트 (.h, .cpp, .dat)
    • 런타임 컴포넌트 (.dll)
    • 실행 파일 컴포넌트 (.exe) 
  • 라이브러리에 직접 접근하지 않고, 라이브러리에 접근할 수 있는 interface를 이용해서 접근

< Deployment Diagram >

  • 전체 시스템 구성 요소들의 실제 하드웨어적인 배치와 연결 상태를 표현
  • 물리적 배치 상태 & 연결 상태
  • UML 확장
    • 스테레오타입 (class를 표현하는 방법)을 사용하여 사용자 정의 타입이나 아이템을 생성하여 UML을 확정
    • 스테레오타입은 관계 ( 연관, 상속), 클래스, 그리고 컴포넌트를 확장하기 위하여 사용
      • class stereotype : boundary, control, entity, utility, exception
      • 상속 sterotype : uses, extends
      • component sterotype : subsystem