Post

06. Class Diagram

OOP/OOAD/UML에 대해 알아보자

06. Class Diagram

2.2 Class Diagram

위와 같이 Class Diagram의 전반적인 Notation을 다를 예정이다 우선 순서대로 하나씩 보자

  • OOA/OOD 단계에 따라 관점이 다르게 작성됨
    • OOA : 도메인 모델 작성에 사용
      • Attribute/Behabor 생략하고 Association도 실선 한개만 그리고 두리뭉실하게 그림
    • OOD : DCD(Design Class Diagram)로 작성됨
      • 코드 레벨로 구현할수 있도록 위 생략된 부분들을 구체화 시켜 적음

  • Class Diagram UML에서 Object을 위와 같이 표현이 가능
    • 소문자(+밑줄도 가능) : Object
    • 소문자(+밑줄도 가능):Class : Object/Class
    • ‘:Class’ : Anonymouse Class(현재 시점에 오브젝 이름을 지칭할수 없을때사용)
    • 자세하게 Value까지도 표현 가능

  • Object Diagram으로 특정 시점의 존재하는 객체의 관계를 표현 가능
  • 특정 시점에 HelenLewis는 oom/iprog를 듣고 있고, mikefox는 iplog만 듣는게 확인 가능
  • Class Diagram으로 그려본다면 녹색과 같이 표현이 됨

  • Object에서 Class로 넘어갈떄 표현 방법
    • Class Attribute 표현, : 타입만 작성
      • 추가로 Attribute/Operations들을 Class를 정의함
    • Object는 Attribue, = 값 작성, `Operation은 작성할 필요 없음!

그외 Notation 설명

Default 표기 (Attribute는 -, Operation는 +)

+/age : Derived Attribue로 다른 값에 의해 계산되어 나오는 값임을 나타냄

dob(date of birth) : 값을 통해서 매년 값이 바뀌는 age를 계산하도록 함

attribute는 소문자로 시작

  • 타입은 데이터 타입과 클래스 타입이 있음(예시엔 클래스 타입은 안보임)
  • 데이터 타입의 경우 Primitive data/Enumerations(열거형) Type 이 있음
  • Primitive data 위 표처럼 쓰면 됨
    • 사용자 정의 타입을 적고자 할 경우 스테레오 타입 표기로 <<primitive>>로 하고 attribute/operation 다 적어주기 가능
    • Composite data type (Structure를 말함) : Operation이 없음. C의 Struct랑 동일하다 생각하면 되며 Operation이 있으면 Class가 됨.

  • Class Diagram이 아닌 Attribute의 Multiplicity 표현이 가능
  • 기본은 1이나 String[1...*]와 같이 표기된 경우 여러개가 올수도 있다는 뜻임
    • address의 경우 한줄로만 적을수도 있으나 2줄 이상으로 적을수도 있어 1…*로 표현

  • 거의 사용하진 않으나 특정 attribute의 초기값을 적어 놓기 가능

  • 특징들을 {} 안에 적어놓을 수 있음
    • 구현단계에서 코드 생성 시 참고용으로 notation을 적는 거임

  • Operation 파라미터 Syntax
    • C++/Java 등과 같은 문법을 고려하지 않고 사용하고 있지 않아 애매함. 포인터가 없는 언어의 경우 out을 구현하기 힘듦
    • 따라서 in만 사용하여 작성함
      • default는 in

  • Operation는 디자인 클래스 다이어 그램까지만 사용하고,
  • 코드 구현이 되었다면 Methods라고 사용해야함
    • Operation : 함수 이름만 정의하고 body를 채우지 않은 상태
    • Method : 구현한 결과물

  • class용 Variable/Operation를 사용할수 있음
    • static으로 인스턴스 생성 없이도 사용되는 변수/함수로 Attribute/Operation에 밑줄을 그어 표기
      • ex. 모든 객체가 공유해야하는 인스턴스 수 or 클래스 자체에 동작시켜야하는 로깅 시스템 초기화/유틸리티 함수 등

  • private variable에 대해서 getter/setter를 두어 조작하도록 함(Information Hiding)
  • private var이 생길때마다 getter/setter를 작성하기 귀찮음으로 UML Tool에서 자동으로 생성 또는 필터링 해주는 기능들이 요즘 있긴함

  • UML에 Note를 작성하는 방법 (접힌 종이 표기 후 쫙 적으면 됨)

  • 그떄 그떄 상황에 맞춰 그려주면 됨

  • 5 종류의 클래스 관계가 있으며, 오른쪽으로 갈수록 강하게 Coupled 되어 있음
    • Aggregation은 주로 (Shard Aggregation)으로 표현
    • Default는 Association이 default임
    • Dependency : 구현 직전인 Composition Diagram에만 주로 보이고 그 이전엔 잘 안씀
      • ex. 다른 객체로 부터 값을 전달 받아 사용하는 경우, 객체 ref를 전달 받아 local 변수로 copy해서 사용 시 해당 객체는 local 변수로 copy하는 순간 해제됨. 따라서 특정 시간이 아닌 work brief로 사용되는 경우에 표현
    • Association: 다른 클래스의 object와 특정 시간 같이 일을 하는 경우 Association 관계 표현(Has-a 관계로 생각해도 된다고 함)
    • Shard Aggregation(하얀 마름모) : obj life cycle동안 삭제해도 다른 obj와 shared 하는 녀석이라 삭제하지 않는 obj
    • Composition(검은 마름모) : obj life cycle동안 쭉 함께하는 관계
    • Inheritance(상속) : 상속 받는 경우(is a 관계)

  • Association

  • A->B A는 B의 public한걸 다 볼수 있으나 B는 A의 걸 다 못봄

  • 선으로 다 표현하기 어려움으로 주로 +로 적는걸 많이 씀

  • 최종적인 가이드라인
    • 일반적인 타입은 - default니 attribute를 적어주나,
    • custom or 다른 클래스인 경우 Association line으로 적어주는걸 권고함

  • 비지니스 프로세스 개발할떄 사용, SW에선 잘 안씀

  • 클래스 Association에 붙는 Association Class
  • 거의 잘 안쓰나 알아두면 좋음
  • Employment 정보를 company/person 두개중 어느곳에 놓아도 구조가 좋지 않음
    • company측에 들고 있자니 person은 너무 많음
    • person측 company는 1:1 관계가 아니라 1:N이라 person측에도 들고 있기 좋지 않음
    • 따라서 별도의 관계 클래스를 만들어서 Attribute를 표현. (구현은 HashTable로 salary를 가져오도록 구현)

  • 클래스당 obj이 1개만 나올 경우 싱클톤의 표현 오른쪽 위에 1을 표현
  • OOAD에선 클래스내 오브젝트관계에 collaborate가 원활하게 일어나야 좋음으로 singletone은 좋지 않음

  • active class : Thread가 되는 클래스를 말함 (양쪽에 선을 그어버리면 됨)

  • 클래스 다이어 그램 수준에서 인터페이스 클래스의 Implementation은 점선 화살표 연결
  • socket +lolipop 표현도 있음 (오른쪽에 있는거임)

Aggregation

  • Aggregation 관계는 2가지가 있음
    • Shared Aggregation : obj이 같이 del 될 필요가 없으면 흰색 마름모
    • Composition : obj이 같이 del 되어야하면 검은색 마름모(composition)

Aggregation - Shared Aggregation

  • B가 A를 가지고 있는 거임
    • LabClass가 없다고 해서 Student가 다 없어지진 않음

Aggregation - Composition

  • B가 A를 가지고 있는 거임
    • Building이 없어지면 LectureHall도 사라지며 Beamer도 없어짐

  • 하나의 차가 타이어 4개를 가지고 있을 떄 없어지면 타이어도 없어지니 첫번쨰는 맞음
  • 정비소가만 타이어만 있을수 있음으로 0/1 표기가 없는 composition 관계는 옳지 않음
  • 차가 타이어 4개를 공유하는 구조는 없음
  • 1개 또는 2개의 타입을 하나의 차가 공유는 가능(바퀴 교체할때 앞에만 교체하는 경우도 있음) => 추후 디자인 패턴 때 Aggregation에 따른 관계를 더 자세히 다룰 예정. 지금은 사라지냐/안사라지냐로 알고 있어도 될듯함

Generalization

  • 가장 강한 관계(Inheritance)
  • parent class의 모든 Association 관계 + Attribute/Operation들을 다 SubClass가 물려 받음

Generalization - Abstract Class

  • child만 new instance를 해서 사용하는 경우를 말함
  • (abstract)를 써도 되고 기울기 표기로 표시해도 됨

Generalization - Multiple Inheritance

  • 자바는 양쪽에서 상속을 받는게 안됨. C++는 가능

  • Generalization을 사용하면 이해는 쉬우나 클래스 개수가 더 늘어남
  • 적절하게 사용하면 됨

  • Class Diagram을 한번에 잘 그리는 방법은 없음.(There are no silber bullet in SW Architecture)
  • 명사는 클래스를 말하고, 형용사는 어트리뷰트, 동사는 operation을 말한다곤 하지만 경험을 잘 살려 작업해야함
  • 정도가 없이 수단과 방법을 가리지 않고 작성해야함

Quiz

Ans

  • 정답 4번, Attribue default private, operation default public!

Ans 1

  • 부모 클래스의 Public한 Attribue/Opertion만 내려감. Private한건 내려가지 않음

Ans

  • Generalization/Composition의 차이는 마름모 색을 채웠냐/비웠냐의 차이다
  • or 관계임을 [0…*] 으로 알수 ㅣㅣ

Homework

  • Homework 1

Ans 가게 하나에 오더 한개씩은? 의문이 좀 드는 부분 만든사람의 의도를 알 있고, student랑 강의실이랑 연결되어야하는데 안되어 있음.(빨간색 줄) 추가로 제일 왼쪽이랑 밑이랑 구성도 몇대몇인지 how to many 개수도 안적어 놓음 이건 그냥 참고용으로 이런 그림도 나올수 있음을 참고하라

  • Homework 2

    Ans

  • SW 도메인은 메세지 패싱으로 직접 콜을하여 필요 정보를 받아오는거나,
  • 얘는 Srk

  • Homework 3

    Ans 은행과 연동이 되어서 서비스 제공 필요

  • Homework 4 (41분)

    Ans

This post is licensed under CC BY 4.0 by the author.