소프트웨어공학 - 8. UML Class diagram

1. Object Diagram

- 밑줄이 쳐져있다. 

- 사각형으로 그린다.

- instance diagram이라고도 한다. 특정한 순간에 시스템을 구성하는 object들의 snapshot을 나타낸다.

- helenLewis:Student , object이름:class이름 을 나타낸다.

- object끼리 맺고 있는 관계는 Link로 나타낸다.

- object diagram은 class diagram으로 부터 만들 수 있는 instance이다. 

- 단순히 도메인 파악을 위해 그린 모델은 domain model, 설계를 염두하고 그린 모델은 Design class diagram(DCD)라고 부른다.

2. Class Diagram

- public 의 경우 +, private -, protected #로 표현한다.

- static 변수, 메서드의 경우는 밑줄을 쳐준다.

- body가 없는 abstract method나 abstract class는 어떻게 표현할까?

- <<abstract>>, {abstract}를 붙이거나 이탤릭체를 사용한다. 이런걸 guillemet이라고 한다.

- circle 이라는 concrete클래스가 Shape이라는 abstract클래스를 상속하고 있다. Shape이라는 추상클래스 안에 areaOf()가 abstract 메서드라고 표시되어있다.

- Renderer, render는 이탤릭체로 표현되어있다.

- 그럼 interface는 어떻게 표현할까?

- 참고로 interface는 하나 이상의 public abstract operation를 가지고 있는 class를 말한다.

- 표현방법1 : ball symbol로 인터페이스를 나타내고 인터페이스를 상속받아 구현하고 있는 클래스를 선으로 연결해서 표현

- 표현방법2 : <<interface>>를 적어주고 점선으로된 realization connector로 상속 관계를 나타낸다. 즉 TimerObserver가 Observer 인터페이스를 상속받아 구현하고 있다는 뜻이다.

- 총 세가지 표현방법이 있는데 모두 같은 뜻을 나타낸다.

- 다이어그램이 표현하고 있는 의미는 Timer라는 클래스가 observer라는 인터페이스 구현을 요구하고 있다는  뜻이다. (의존한다)

- 표현하려는 세부 내용의 정도에 따라서 class diagram을 그릴수도 있다. 

3. Class Diagram : Relationship

4.Class Diagram : Relationship : inheritance

- 상속관계를 나타낸다. Generalization이라고도 한다.

- subclass는 superclass의 attribute, operation을 상속받는다.

- abstract class를 상속하는 경우이다.

- 추상클래스는 Instance를 만들 수 없다. concrete한 subclass인 man, woman은 instance를 만들 수 있다.

- 어떤 언어에 한해서는 다중상속이 불가능할수는 있지만 표기상으로는 위처럼 한다.

- 상속을 활용한 diagram과 아닌 diagram을 비교해보자.

- 상속을 받으면 superclass가 맺고있는 관계도 subclass에게 귀속된다. 그래서 굳이 선으로 표시하지 않았지만 Administrative Employee는 Faculty와 관계를 맺고 있다.

- 상속을 활용하면 훨씬 적은 정보와 노력으로 명확한 관계를 표현할 수 있다.

5. Class Diagram : Relationship : composition

- 한 class가 다른 클래스의 object를 멤버로 포함할 때

- aggregation의 변종이다. 

- aggreation보다 더 강한 결합을 의미한다. 따라서 composite-part는 반드시 1대다, 1대1 관계만 맺을 수 있다.

- 속이 차있는 다이아몬드 모양을 사용한다.

- 만드시 composite 객체는 1개여야 한다.

- composite객체가 사라지면 Part들도 사라진다. 

- 만약 building이 사라지만 building에 강의실과 빔프로젝터들도 사라지는 관계이다.

- 주로 현실세계 물리적 모형을 대변할 때 사용한다.

6. Class Diagram : Relationship : aggregation

- 한 object를 여러 class들이 공유해서 소유하고 있을 때

- association의 일종인데 어떤 class가 다른 class의 부품,part라는 관계를 표현할때 사용한다.

- Shared Aggregation 

- 약한 소유관계를 나타낸다. LabClass에 여러 학생들이 소속되어 있지만 LabClass가 사라진다고해서 학생들도 사라지는 것은 아니다. 참고로 0..1대다관계이므로 학생은 한 LabClass에만 소속될 수 있다.

- StudyProgram에 course들이 속하지만 StudyProgram이 사라진다고 Course들이 사라지는 것은 아니다. 다대다 관계이므로 한 course가 복수개의 study program에 속할수도 있다.

- 이렇게 aggregation에서는 약한 결합이기 때문에 다대다, 1대다 관계가 모두 가능하다.

- 속이 빈 다이아몬드 모형을 사용한다.

- 첫번째 경우 자동차가 4개의 타이어를 소유하는 상태 (타이어는 반드시 한 차량에게 귀속됨), 혹은 타이어만 단독으로 존재하는 상태가 있을 수 있다. (0..1 - 4 관계이므로)

- 두번째 경우 타이어만 단독으로 존재할 수 없다. 반드시 자동차가 4개의 타이어를 소유하는 상태만 표현이 가능하다. (1 - 4 관계이므로)

- 세번째 경우 타이어가 여러 차량에 부품으로 속할 수 있다. 

- 네번째 경우 타이어의 종류를 차량이 공유한다는 의미이다. A종류, B종류의 타이어가 a차량에 사용될 수 있고 마찬가지로 b차랑에도 사용될 수 있는 개념이다.

7. Class Diagram : Relationship : association

- 두 objects가 관련된 작업을 하고 있을 때

- 관계를 읽는 방향(ex. 교수가 강의를 한다 학생에게)을 reading direction으로 표현할 수 있다.

- n대n (ex. *:*)관계까지 표현이 가능하다. 

- professor instance의 역할은 lecturer임을 나타내고 있다.

- Student는 Professor의 public같이 visible한 attribute, operation에 접근이 가능하다. (Navigability)

- 반면 Professor는 Student의 어떤 attribute, operation도 접근이 불가능하다. (Navigability)

- 만약 명시적으로 navigability 화살표가 기술되어있지 않으면 (엄연히 다른 것이긴 하지만) 관행적으로 양방향으로 화살표가 있다고 가정한다.

- 현실에서는 uml을 제작하는 단계에서는 navigability까지 확실하게 표현하기 애매할수 있다. 따라서 추후에 해석을 어느정도 자유롭게 할수 있도록 관행적으로 이해한다.

- 같은 표현법이지만 초록 박스로 표시한 방법이 더 선호된다.

- 1대n관계이다 즉 Lecturer한명이 여러개의 assignment를 낼 수 있다. (한개의 assignment는 1명의 lecturer에게서만 나온다.)

- 관계를 나타낼 때 role도 명시할 수 있다.

- 맨 마지막 예시 Charles가 자기 자신과 wife, husband 관계를 맺는 예시는 현실적으로 말은 안되지만 class diagram이 충분히 표현할수는 있는 instance이다.

- association에 attribute를 추가하면 association class가 만들어진다.

- 관계 자체가 속성을 지니면서 하나의 class형태를 띠는 것이다.

- student, studyprogram의 관계에 enrollment라는 class가 만들어진다.

- student, exam, lecturer가 맺는 관계에 grade라는 class가 만들어진다. 이 역시 class이기 때문에 다른 class와 관계도 충분히 맺을 수 있다.

- 1대다 관계에서는 다쪽에 association class를 넣어버릴 수 있다.

- 1대1 관계에서는 아무쪽에 association class를 넣어버릴 수 있다. 

- association class를 그냥 regular class로 표현하면 되지 않느냐?라고 물을 수 있지만 명백히 의미적 차이가 있다.

- 밑의 예시처럼 클래스의 관계로 표현한 경우 P1, S1 사이에 새로운 Enrollment를 추가하면 P1, S1이 복수개의 관계를 맺는 경우를 허용하게 된다. association class를 활용한 경우는 위 상황을 허용하지 않는다.

- association은 기본적으로 단 한개만 허용하지만(unique pair) 위처럼 {non-unique}를 명시해주면 동일한 두 객체 사이의 복수개의 관계를 맺도록 할 수 있다.

- 학생이 수강한 과목에 대해서 grading을 2번 받을 수 있게 되었다.

- without qualification : 디렉터리와 파일 class는 서로 1대다 관걔를 맺는다.

- with qualification : qualified association, directory가 filename이라는 속성으로 특정한 File을 찾을 수 있다는 의미를 더 부각해서 표현하는 방법이다.

8. Class Diagram : Relationship : dependency

- 한 object가 다른 class의 메서드에서 잠깐 사용되는 정도의 아주 약간 관련성을 나타낼 때

- 매개변수로 잠깐 B를 받아서 사용하거나 return type이 B인 경우 처럼 아주 짧은 시간 관계를 맺을 때 사용한다.

- 가끔 의미를 더 명확히 하기 위해 <<use>> stereotype을 사용하기도 한다.

9. Stereotypes

- 만약 내가 실시간 시스템을 모델링하고 있다면 UML Standard만으로는 부족할 수 있다. 

- 그래서 standard modeling concept를 더 정제하여 특정 목적에 맞게 refine한 UML for CORBRA같은 새로운 concept가 얼마든지 생길 수 있다. 

- 이를 stereotype이라고 한다.

- 예를들면 GUI 모델 디자인에 더 특화하기 위해 기존 standard class를 확장하여 다양한 <<stereotype>> 클래스를 만들 수 있다. 이 새로운 버전의 UML을 간략히 소개하는 위 그림을 uml profile이라고 한다.

- profile을 사용하면 이렇게 모델링을 할 수 있을 것이다.

9. Example

- loyalty program의 관계를 class diagram으로 나타내 보았다.