04. An Introduction to UML

2. UML 2.0 기준 다룰 내용

• 13가지 다이어 그램을 다 다룰 예정

---

2.0.1 UML 이란?

• UML이 SW Design에서 사용되는것이 아니라 범용적으로 여러 도메인에서 사용된다
  • SW Design에서 Objedct/Component Modeling이 주로 사용되나,
  • 비지니스 업계족에선 Workflow와 같은 모델링도 사용됨
• software-intensive systems의 문서화된 결과물로 주로 SRS(Software Requirements Standards)/SDS(Software Design Standards)로 작성될때 사용됨

• 모델링 랭귀지 UML이라서 Semantics(=의미론)를 정의를 해야함
• UML 13가지를 조합하여 Semantics/Syntax를 정의함
  • 다른 프로그래밍 랭기지와는 다르게 자기 자신을 사용해 semantics/synctax를 정의함
  • ex. class diagram + sequence diagram = class diagram을 정의함
  • +TMI. 일반적인 프로그래밍 랭기지는 lex/yacc를 사용해서 Semantics/Syntax를 다르게 정의함.
• UML semantics를 보면,
  • 4 layer로 구성
    • M3 : MOF 레벨(ex. 자동차에 대한 모델링을 수행할때 자주 사용되는 엔진 모델/클래스등을 미리 다 정의해놓은 클래스 다이어그램의 샘플) layer = 프로파일 모델이라고도 함(UML에서 스테레오 타입으로 <<Profile>>로 되어 있는 것들이 해당됨)
    • M2 : UML 13가지를 정의해놓은 layer (모델레이어의 모델을 정의한다고 해서 메타 모델 레이어)
    • M1 : class/sequence diagram등 을 그리는 layer
    • M0 : 구현되서 런타임상 실제 동작 정보를 보이는 layer (ex. new로 class instnace화 후 task로 쓰레드에 assign 등등)

• 주로 M1 layer에서 아래와 같은 모델리을 수행
  • Person은 클래스이고 이를 <---로 연결시킨 Albert Person은 인스턴스
  • 런타임 레이어에선 클래스를 new로 생성해서 보이는 aPerson이 보이며, 얘는 Albert Person과 같은 애를 동적으로 생성함을 보임
  • M3는 M2에서 사용되는 모델을 클래스 notaion을 통해 정의
  • 이 모든것들을 통합해서 보이는게 MOF인 M4 Layer

• UML 2.2는 잘 안씀 x 표시를 제외하면 2.0이다
• 옆으로 누워있는 Diagram는 abstraction class란 의미 = 자기 자신을 인스턴스화 하지 않고, 자기 자신을 상속 받은 차일드 클래스들만 new해서 인스턴스를 만들어 쓰도록 했다는 의미(Structure/Behavior Diagram 들이 다 해당됨)
• 화살표인데 속이 안찬건 generalization instance 의미
• 따라서 abstration class를 제외하면 실질적인 클래스는 13개가 있음
• OOAD를 할떄 주로 많이 쓰는게 3가지 UC/SD/CD임(Usecase/Siquence/Class Diagram)
  • OOA(Use Case + Domain Model)/ OOD ( Sequence Diagram + Class Diagram)
    • Domain Model의 경우 Notaion이 Class Diagram을 사용하지만 UML의 diagram에 포함되지는 않음
• Activiy : 비지니스 도메인에선 사용할수도 있는 옵셔널 다이어그램

• State Machine Diagram : Activity와 동일

• 아래 3개 diagarm은 개발 초기엔 볼 수없는 diagram으로 개발 후기 막바지에 확인이 가능함(수업때도 잘 다루지 않음)
  • Package : 동일한 로직들을 모아놓은 다이어그램
  • Component Diagrm : Package을 모아 하나의 컴포넌트 모델로 설명할때 사용
  • Deployment Diagram : physical한 레이더 단계로 어떻게 배포되는지 보임
• 그 외,
  • Composite Structure Diagram : Component Diagram과 비슷함
  • Object Diagram : Class Diagram과 쌍으로 추가 설명할떄 사용함

---

2.1.1 Use Case Diagram

• Use Case와 액터를 시나리오 그반으로 보여주는 그림이며 아래와 같은 2가지 요소가 포함됨.
  • Use Case 그림 : 외부 액터가 우리 시스템을 어떻게 사용하는지 시나리오 기반으로 Use Case를 그림
    • ex. 슬라이드에서 다양한 사람이 우리 시스템을 어떻게 이용하는지 그림
  • Use Case Description(Text scenario): 각 UseCase에 대하여 일목요연하게 시나리오 기반으로 텍스트를 잘 적어줘야함
• +TMI. Use Case의 경우 brief / Casual / fully dressed로 OOA 단계에선 brief/casual만 사용되며, OOD에선 fully dessed가 사용되어 OOAD는 UseCase기반으로 디자인을 진행한다 생각하면 됨

---

2.2.1 Class Diagram ( = Static Diagram )

• 클래스 내 state/opration 구성과 간략히 colaboration이 어떻게 이뤄지는지 보임
  • 시나리오 기반으로 클래스간에 관계를 보임 (Assosiation/Multiplicity/lable/attribute/operation등 확인이 가능하나 언제 어떻게 정확히 몇개랑 관계를 맺는지 보이지 않음)
• OOA/OOD에서 class diagram notaion이 2번 사용됨
  • Domain Model : notaion을 class diagram을 따름
  • DCD(Design Level Classdiagram) : 위 도메인 모델 UseCase Diagram을 refinement(정제)함

---

2.2.2 Obejct Diagram

• 항상 그리는게 아니라 특정 타임에 인스턴스가 어떻게 생성되는지 설명하고자 할때 그림
• 클래스 다이어 그램에서는 작가가 있을수도 있고 없을수도 있는데(0,1), 있으면 컴퓨터는 (1~여러개, *)를 가질수 있음. one to many이지 정확히 몇개인지는 모름
  • Uses > 표기는 작가가 컴퓨터를 가져다 씀을 의미함
• 오브젝트 다이어 그램에서는 밥이라는 작가가 컴퓨터 2개를 정확히 가지고 있음을 확인이 가능

---

2.2.3 Package Diagram

• 여러 클래스를 하나의 패키지로 묶은 다이어 그램
• 초기 단계에선 잘 안보이나 Iteration을 여러번 돌린 후반부에 가면 보일 수 있음
  • ex. 몇 클래스는 클라이언트 쪽에서 사용하며, 몇 클래스는 서버쪽에서 사용하는 클래스 등으로 구분지어짐
• 실질적으로 구현되는 physical 단계 구조가 아닌 Logical 구조이다
• 대문자는 class/ 소문자 or 밑줄까지 그어져 있으면 object (class/object/package diagram 등등에서 다 공용으로 사용됨)
• 폴더 모양의 좌측 상단이 해당 페키지의 이름을 보임

---

2.2.3 Component Diagram

• 컴포넌트의 경우 개발 부서의 개발 스콥 단위로 보면 됨
• Logical 구조 단계를 다이어그램임(특정 하드웨어/노드위에 deploy 하여 인스턴스 해야 physical level)
• 동그라미가 주는 거고, 왼쪽 꺾새가 받는 표시임
• 오른쪽 상단에 IC 칩같은 모양이 Component임을 의미

---

2.2.4 Composite Structure Diagram

• Component Diagram을 Hierarchy하게 그린 diagram
• ex. 컴포넌트가 2개의 컴포넌트로 구성이 되며, 어떤개 주고 받는지를 보이며,
• 컴포넌트 내부를 구성하는 a part of component를 설명할때 Class/Object Diagram을 그릴수도 있으나 잘 보이진 않긴함

---

2.2.5 Deployment Diagram

• 특정 하드웨어/노드에 올려서 new를 하고 쓰레드 풀에 할당하는 execution 동작을 해야 돌아갈텐데 이를 보이는게 runtime configuration = Deployment diagram
• Operation System(OS)가 있으면 해당 OS 정보까지 다 보여줌
• 앞에는 안나오고 개발이 끝나는 후반부에 나올수 있음
• • 스코프 단위로 보면,
  • 클래스 다이어 그램 < 패키지 다이어 그램 < 컴포넌트 다이어그램 < 디플로이 다이어그램 순이며 이 단계별로 개발 과정이 이뤄짐

---

지금부터는 Behavior Diagram을 보인다

---

2.2.6 Sequence Diagram ( = OOD의 Dynamic model )

• Behavior Diagram 중 하나이며,
• 시간순서(time sequence)에 따라 오브젝트간에 커뮤니케이션이 어떻게 이뤄지는지 보임
• oject가 정해지지 않았을때는 anonymous obj으로 표기 가능 (ex. :클래스)
• 단점 : 복잡한 시스템에선 가로로 사이즈가 매우 길게 늘어지는 경향이 있음

---

2.2.7 Communication Diagram ( = Collaboration Digram으로도 불렸었음)

• sequence diagram과 동일하나 시간 순서가 아님
• sequence diagram의 시간 단계를 싹다 삭제하고, 라벨 화살표 단계로 표현
• sequence diagram의 단점을 보완하여 복잡한 시스템이여도 한눈엔 들어옴
• TMI. 표현력은 Sequence diagram과 동일하나 교과서나 누군가에게 설명할때만 사용하고, 주로 Sequence Diagramd을 사용함

---

2.2.8 Timing Diagram

• Timing sequence로 각 object간에 busy/idle 상태를 시간 순서로 확인 가능
• Sequence/Communication과 동일한 예제로 보임

---

2.2.9 Interaction Overview Diagram

• 명칭과 동일하게 Interaction을 Overview 다이어그램이며, activity diagram의 변종임.
  • active diagram은 flow chart를 말하는데 이러한 노드에 sequence/class diagram을 넣어둔 diagram임.
• 전체 시나리오가 어떻게 동작하는지 보일때, 시스템 태스트를 만들 때 주로 사용함
• TMI. a variant of (의 변종이며)

---

2.3.1 State (Statechart) Diagram

• Statecharts라는 포맷을 가지고 와서 UML 언어로 사용
• Finite State Machine(FSM)으로 시스템이 스테이트에 따라 동작이 어떻게 달라지는지 보여줌 (OOA/OOD 단계에서 옵셔널 하게 스테이트 기반으로 움직이는 것을 보여줄떄 그림)

---

2.3.2 Activity Diagram

• 비지니스 프로세스를 명세할때 사용하면 좋음(일의 순서를 표현하기 좋음)
• StateChart와 비슷함
  • StateChart는 이벤트가 발생하면 다른 스테이터스로 넘어가면서 일을하는데,
  • Activity Diagram에서는 state에서 일 끝나면 넘어감
• 일의 순서를 표현하긴 좋음. ex. 이일이 끝나면 A, 그다음 B, 그 다음 C ….

---

Quiz

정답 2.

1. Specification / visualization을 하기 위한 모델링 랭귀지일 뿐이라 맞는말
2. C언어를 배워 같은 문제를 풀어도 코드가 1000/10000줄등 다르게 나옴. 마찬가지임 UML도 잘 다룬다고 OOD를 잘하는건 아님 정답 OOA (Usecase Diagram/ Domain Model) / OOD (Class Diagram[static]/Sequence Diagram[dynamic] )

여기까진 전반적인 UML diagram에 대한 overview였으며, 앞으로는 OOA/OOD에서 중점적으로 사용되는 diagram들에 대해 더 자세히 배울 예정