[TIL]221018 - UML 적용: 오퍼레이션 약정 및 OCL, 설계, 논리적 아키텍쳐

Jimin·2022년 10월 19일
0
post-thumbnail
post-custom-banner

UML의 적용: 오퍼레이션, 약정 및 OCL

  • 오퍼레이션(Operation)

    • 실행하기 위해 객체가 호출될 수 있는 변환이나 질의에 대한 명세
    • 오퍼레이션은 구현이 아닌 추상화
  • 메소드

    • 오퍼레이션에 대한 구현으로 관련된 알고리즘 또는 절차를 명세
  • UML에서 사전조건과 사후조건 형태로 명세할 수 있는 제약사항들을 이용해 오퍼레이션의 의미 정의

  • UML 오퍼레이션 명세서는 알고리즘이나 솔루션을 보여줄 필요는 없음.

    • 오직 상태 변화나 오퍼레이션의 효과

OCL로 표현되는 오퍼레이션 약정

  • UML과 관련된 OCL이라고 하는 형식 언어로, 모델에서 제약 조건을 표현하는 데 사용할 수 있음
  • OCL은 작업에 대한 사전 및 사후 조건을 지정하기 위한 공식 형식을 정의함
System::makeNewSale()
	pre:	<statements in OCL>
	post: …
  • 단순하게 유지하고 OCL대신 자연어 사용
  • 공식 명세 언어에어 유래
    • Eiffel과 같은 일부 언어는 불변 및 사전, 사후 조건에 대한 최고 수준의 지원을 제공함
  • 결론
    • 프로그램 자동 생성/검증 등을 위한 기본 작업
    • 학습, 적용, 수정 및 관리가 감당할 수 없는 비용을 요구해 비현실적

  • Contract는 세부적인 시스템 동작을 설명함
  • Contract는 오퍼레이션, 상호 참조, 사전 및 사후조건 (가장 중요한 부분)을 가짐
  • 사후조건은 도메인 모델에서 객체의 상태 변화를 설명함
  • 도메인 모델가 가지는 상태 변화는?
    • 인스턴스 생성
    • 연관 관계 연결 및 해제
    • 속성 변화
  • 대부분 constract를 elaboration 단계 동안에 작성됨


From Requirements to Design In this Iteration

  • 객체 디자인 기술과 UML 표기법 지식(중요하지 않음)의 중요성

    • 객체 설계 기술이 중요하다!
  • 반복적으로 올바른 일을 하고 그 일은 올바르게 하세요! (Do the right thing, Do the thing right)

    • 요구 사항: do the right thing
    • 디자인(설계): do the thing right

    On to Object Design

  • 객체 설계

    • OOP에 기반한 논리적 솔루션을 개발함
    • 이 솔루션의 핵심은 상호 작용 다이어그램을 만드는 것
    • Iteraction Diagram은 요구 사항을 충족하기 위해 협력하는 방법을 보여줌

Importance of Object Design Skill vs UML Notation Skill

  • UML Interaction 다이어그램을 그리는 것은 객체 디자인에 대한 결정을 반영하는 것
  • 객체 디자인 기술이 더 중요
    • 책임 할당의 원칙
    • 디자인 패턴(ID 그리는 노하우)


논리적 아키텍처와 계층

  • 논리적 아키텍처
    • 소프트웨어 클래스들을 패키지(또는 네임 스페이스), 서브시스템, 계층과 같은 큰 단위로 구성
    • 물리적 배치와 관계 없으므로 논리적 계층
  • 계층 구조
    • 시스템의 클래스들을 계층이라는 서브시스템으로 분류
    • 계층화된 논리적아키텍처를 UML PackageDiagram으로 표현

UI: javascript library 이용, 화면 생성
Domain: 서버 코드 (Node.js, php)
Technical Services: DB(99% 차지)


논리적 아키텍처와 계층이란?

  • 논리적 아키텍처

    • 소프트웨어 클래스들을 패키지(또는 네임 스페이스), 서브시스템, 계층과 같은 큰 단위로 구성
    • 물리적 배치와 관계 없기 때문에 논리적 계층!
  • 계층 구조

    • 시스템의 클래스들을 계층이라는 서브시스템으로 분류
    • 상위 계층이 하위 계층을 호출
    • 가장 일반적인 아키텍처
      • 사용자 인터페이스 (UI와 Domain의 communication)
        • 어플리케이션 로직과 도메인 계층 (예. 판매, 지불 등)
        • 기술적 서비스 (예. DB, Log, Network 등)

    소프트웨어 아키텍처

  • 아키텍처: 중요한 결정의 집합

    • 소프트웨어 시스템의 조직
    • 시스템을 구성하는 구조적 요소 및 인터페이스 선택, 이러한 요소 간의 협업에 지정된 동작과 함께
    • 이러한 구조적 및 행동적 요소를 점진적으로 더 큰 하위 시스템으로 구성함
    • 요소, 인터페이스, 협업 및 구성을 가이드(안내)하는 아키텍처 스타일

    UML의 적용: 패키지 다이어그램

  • 패키지 (묶어 놓은 것)

    • 논리적 아키텍처는 페키지 다이어그램으로 표현
    • 패키지는 하나의 계층으로 표현
    • 패키지는 클래스, 다른 패키지, 유즈케이스 등 무엇이든지 묶을 수 있음
  • Name Space

    • 예.
      • java::util::Date
        • Date는 util 패키지에 포함
        • util 패키지는 java 패키지에 포함

중접된 패키지의 종속관계 표현

  • 패키지 간의 의존 관계: dependency line으로 표현

계층을 이용한 설계

  • Layer Pattern
  • 해결되는 문제점
    • 소스의 변경이 전체에 파급됨
    • 인터페이스 변경이 용이
    • 범용적인 기술 서비스의 재활용 촉진
    • 높은 결합도 해소
  • 계층 사용의 이점
    - 문제점 반대
    • 응집도 향상
    • 팀단위 개발 용이
post-custom-banner

0개의 댓글