6-1. UML(패키지,엑티비티, 컴포넌트, 배치)

지난 거에 가장 중요한 다이어그램은 클래스, 시퀀스가 가장 중요하고 그 뒤에 중요한 것은 유스케이스

패키지로 묶을 때 사용

패키지 다이어그램(package)

• 패키지로 묶을 때 사용, 패키지와 패키지 사이의 관계를 표현
  • 자바의 패키지를 의미함. c++의 네임 스페이스 같은 것
  • 관련있는 것끼리 꾸렁이로 묶어놓는 것
• 복잡한 다이어그램을 논리적으로 모듈화함
• 분석설계에서 클래스 다이어그램에서는 세부적인 것을 보여주지만 상위 레벨 개관을 보여줌. 위에서 볼 떄는 패키지로 보는 편

• 패키지가 될 수 있는 것들은 패키지 element가 될 수 있는데 패키지는 패키지 자신을 가질 수도 package element도 가질 수 있고 패키지는 엑터, 유스케이스, 클래스, 컴포넌트 모두 묶을 수 있다
• C1,c2가 논리적으로 연관이 있다면 p1에 c1, p21가 연관이 있다면 p2로 묶을 수 있다.

자바의 패키지 생각하면 된다

패키지의 바람직한 특성

• 개념적 유사성
• 기능적 유사성
• 변화의 유사성
• 관리적 유사성

→ 개념적으로 유사하거나 기능적으로 유사하거나 관리하기 유사하거나 할 경우 패키지로 묶는다 기업의 업무 도메인을 보면 어떤식으로 패키지를 해야 할지 보인다.

변화가 유사한 것들을 묶어서 패키지로 하면 된다

패키지 다이어그램- 요구사항 단계

• 요구사항 단계에서 각 기능을 묶어서 사용자 관리로 묶을 수 있다.  보통 업무를 관련있는 것 끼리 패키지로 묶을 수 있다.
• 요구사항 단계에서는 사용자의 요구사항을 묶을 수 있다

패키지다이어그램 - 분석/설계 단계

분석.설계에서는 복잡하게 묶을 수 있다

패키지 안에 클래스들은 표시 안해도 된다(패키지를 열면 클래스다이어그램이 존재할 것)

큰 개괄을 볼 수 있음

• 패키지 사이에는 의존관계가 존재

Ex)공통 ui는 사서 Ui과 대출자 ui에 의존,도서관리 ui는 사용자 관리 패키지에 의존, 사용자관리에는 로그인 관리가 있는데 개인정보 관리에 의존 등등..

• 패키지는 보통 아키텍처가 레이어로 쪼갤 수 있으며 맨 밑부분이 보통 db나 저장을 해주고 그 위에 논리적인 제어해주는 부분, ui부분으로 나눌 수 있음.

액티비티 다이어그램(activity)

• 액티비티 다이어그램도 많이 쓰이고 화면 흐름을 표현할 때도 많이 사용
• 모듈분석 뿐만 아니라 Ui 분석도 같이하는데 화면의 흐름을 나타낼 때 엑티비티 다이어그램으로 표현 가능(동그라미가 화면이 되어서 액티비티로 표현)
• 흘러가는 거는 모두 엑티비티 다이어그램으로 표현 가능

• 시스템의 실행과 행위의 흐름을 표현
• 작업 흐름(workflow)나 유스 케이스의 이벤트 흐름(flow of event)를 표현하는데 적합
• 클래스 다이어그램은 구조를 표현(정적인 측면)하지만 시퀀스 다이어그램은 객체들 간의 인터렉션, 액티비티 다이어그램은 시스템과 행위를 표현하는 동적인 측면을 표현
• 작업이 어떻게 흘러가는지 유스케이스이벤트 흐름,일의 흐름, flow를 설명하는 것,flowchart와 비슷

엑티비티 다이어그램 요소

1) 행위노드(action node)

• 활동(activity) 안에서 구별된 원소적인 작업 단위를 표현

메소드 안에 로직 설명에서도 사용함,UML은 flow chart를 사용하지 않기 떄문

신호를 보낼 때 사용 : iot,실시간 시스템떄문에 임베디드 시스템 설계하는 것이 많아 시그널을 보낸다.

신호 송신 및 이벤트 수신 노드

신호 송신

• 신호 인스턴스를 생성하고 대상 객체에 전송하는 것을 표현

이벤트 수신 행위

• 이벤트를 기다리는 것을 표현
• 독자적으로 사용할 수도 있고 신호송신과 함꼐 사용될 수 있음

시간 이벤트 수신 행위(accept time event)

• 시간에 반응하는 행위를 표현

2) 제어노드(control node)

• 활동 흐름을 제어함
• 제어 흐름(control flow)
  • 하나의 노드에서 다르노드로 제어가 흘러가는 것을 표현
  • 보호 조건(guard condition)을 가질 수 있음

Decision 노드와 Merge 노드

Decision node – 하나의 입력단과 여러 개의 출력단을 가짐 – 각 출력단은 보호조건(guardcondition)으로 보호됨 – 입력단에 토큰이 전달되면 모든 출력단에 제공되고, 각 출력단의 보호조건 으로 판단하여 참인 하나의 출력단으로만 출력됨 – 조건문에 해당함 Merge node – 여러개의 입력단과 하나의 출력단을 가짐 – Decision노드에서 분기된 제어흐름 중 하나라도 Merge노드에 도달하면 Merge 노드를 통과함

– 논리 OR

Fork 실행노드와 Join 노드

Fork node – 하나의 입력단과 여러 개의 출력단을 가짐 – 입력단에 토큰이 전달되면 동시에 모든 출력단에 복제되어 제공됨 – 하나의 입력흐름을 다중병렬흐름으로 분할함 – 병렬실행에 해당함(multi process) Join node – 여러개의 입력단과 하나의 출력단을 가짐 – 모든 입력단의 토큰의 흐름을 동기화하고 결합하여 하나의 출력단에 제공함 – 논리AND : 둘 다 만족해야 한다. – Decision노드에서 분기된 제어흐름 중 하나라도 Merge노드에 도달하면 Merge노드를 통과하지만 Fork 실행 노드에서 분기된 모든 제어 흐름이 Join 노드에 도달해야만 다음 노드로 제어 흐름이 흘러갈 수 있다.

3) 객체노드(object node)

• 활동 안에서 사용되는 객체를 표현
• 객체 흐름(object flow)
  • 활동 안에서 데이터의 흐름을 표현
  • 객체 노드에서만 사용할 수 있음

사각형으로 객체를 표현

객체를 주고받을 수 있으며 예외처리도 가능

파티션(partition) / 구획면(swimlane)

• 업무처리 등에 많이 사용
• 공통적인 특징을 갖는 행위를 식별하기 위한 활동 그룹
• 일반적으로 비즈니스 모델(요구사항 단계에서 도메인 분석 시 분석) 에서 조직단위에 해당함

비지니스 모델에서 수영장에 레인이라고 부름 : 구획면

이걸 쳐주면 누가 액션을 하는지 알 수 있음. 파티션하면 누가 그 액션을 하는지 주문부서, 회계부서, 고객이 시작을 한다는 것을 알 수 있음

ex) 주문부서에서 주문을 받으면 오더가 거절되면 끝나고 accept되면 주문서를 채우고 fork해서 동시에 shipping(발송)하면서 동시에 회계부서에서 송장 발부와 송장 객체를 만들어져서 고객은 지불을 하게 됨 -> 회계 부서는 지불을 받아서 지불과 ship하면 join되어 모두 끝나서 주문을 끝냄

• 누가 하는지 분석하고 요구사항 찾을 때 많이 사용
  • 스윔레인 없이 표현하게 되면 누가 하는지 모르게 됨

똑같은 건데 interrupt가능(cancle)할 수 있으므로 객체가와서 닫히게 된다, 나머지는 동일

활동 다이어그램의 활용

• 유스 케이스 간의 선후관계 표현
  • 스케이스하면 엄청 실수하는데 유스케이스간의 일의 흐름을 나타낼 때. 유스케이스는 액티비티처럼 일의 흐름을 이렇게 그리면 안됨.
  • 유스케이스 간의 선후관계를 표현하고 싶을 때 엑티비티 다이어그램을 사용하면 된다
• 연산의 알고리즘 표현
  • 알고리즘 표현할 때에도 flow chart가 없기 떄문에 엑티비티 다이어그램으로  써도 된다

컴포넌트 다이어그램(component diagram)

설계에서 많이 보임,  아키텍처 설계에서도 많이 보임.

• 아키텍서 설계에서 많이 보임

• 클래스보다는 상위 전체 뷰를 보여준다.

• 논리적 또는 물리적 시스템의 구조를 컴포넌트와 컴포넌트 인터페이스 관계를, 컴포넌트 사이의 관계를 표현하는 것
• 시스템의 소프트웨어 아키텍처의 논리적인 구조를 보여주는 논리뷰(logical view)를 표현
• 시스템의 소프트웨어 아키텍처의 물리적인 구조를 보여주는 물리 뷰(physical view)를 표현

클래스 다이어그램보다 단위가 큰 편

• 동그라미는 인터페이스를 의미하며 실체화를 실선으로 표현

주문관리 인터페이스는 주문관리자 컴포넌트가 구현함. 인터페이스는 약속, 스펙.  인터페이스 구현은 사실 클래스가 커지게 되면 더 큰 덩어리인 컴포넌트(패키지,클래스를 묶어놓은 형태)가 구현한다. 컴포넌트 안에 클래스, 추상 클래스, 인터테이스가 여러  개 있는데 그 중에서 주문관리자 컴포넌트는 (자바 압축파일)자르 파일로 되어 있음, 주로 약속된 인터페이스를 구현

배송관리자 컴포넌트는 배송관리라는 인터페이스를 구현했는데 주문관리자 컴포넌트는 배송관리자 인터페이스를 사용한다는 의미가 된다

즉, 주문을 하면 배송을 해야 하니까 주문관리자는 배송관리 인터페이스한테 오픈된 메소드를 호출

• O-는 구현, 인터페이스를 사용하다는 –(로 표시

실제 일은 인터페이스가 아닌 컴포넌트가 할 것

소웨공 주 목표는 소프트웨어도 하드웨어처럼 만들자. 유지보수하고 재생하기 쉽게 만들자. 인터페이스 구현 , 사용하는 축으로 나뉘기에 서로 서로를 알 필요 없이 인터페이스만 알면 된다. Consumer-provider 관계

따라서 구현하는 컴포넌트가 성능이 떨어지면 새로운 컴포넌트로 바꾸면 된다.

클래스 단위가 아니라 컴포넌트 단위로 이러한 작업이 일어난다.

• 컴포넌트에서 작은 네모 상자는 인터페이스를 의미, 컴포넌트에서의 내부는 블랙박스로 안보이고 일부만 외부로 보임. 정보를 공개한 부분

컴포넌트(component)

• 캡슐화되어 있으며 재사용할 수 있고 대체할 수 있는 소프트웨어 모듈
• 제공된 인터페이스를 구현하며 외부에 서비스르 제공

• 필수 인터페이스를 사용해서 내부기능을 구현

  

제공된 인터페이스(provided interface)

• 컴포넌트가 구현하여 제공하는 인터페이스

필수 인터페이스(required interface)

• 컴포넌트를 구현하는데 필수적으로 사용되는 인터페이스
• «use»의존성 관계

포트(port)

점점 그리는 방식이 바뀌면서 툴에서 포트를 만듦.

포트(통신할 수 있는 구멍)를 통해서 제공, 사용한 인터페이스를 묶어놓음

• 의미론적으로 서로 연관된, 제공된 인터페이스와 필수 인터페이스들을 하나의 그룹으로 묶어줌
• 제공된 인터페이스와 필수 인터페이스를 구조화함
• 컴포넌트와 다른 컴포넌트 사이의 상호작용 위치를 표시함

컴포넌트 상호작용

컴포넌트는 인터페이스룰 구현한다 가만히 있는 건 없음

• 지금 보는 것은 전체 구조의 논리적인 구조를 보여주기도 하고 논리적인 이름이 아니라 물리적인 컴포넌트로 파일이름을 쓸 수 있음.
• 나중에 배포, 실제로 인스톨해서 실행하려면 실제 파일 단위로 나뉘어야 하므로 물리적인 단어가 된다.물리적인 컴포넌트가 되면 물리적인 컴포넌트의 구조를 보여준다고 볼 수 있음.

배치 다이어그램(deployment)

실제로 물리적인 구조를 보여줌

• 실행 시에 물리적인 노드(node)에 소프트웨어 산출물(artifact)을 할당하고 매핑하는 시스템의 구조를 표현한다.

노드

• deployment 다이어그램에서의 단위
• 실행 컴퓨팅 리소스를 표현하며 일반적으로 메모리(및 프로세싱) 기능을 가짐

1) 디바이스(device)

• 프로세싱 기능을 갖는 물리적인 컴퓨팅 리소스
• 디바이스는 중첩될 수 있음
• 하드웨어 노드

2) 실행환경

• 특정한 실행 플랫폼을 표현함
• 하드웨어 노드에서 실행됨
• 운영체제, 웹 서버, 애플리케이션 서버 등

장치일 경우에는 서버(실제 물리적인 장치, 컴퓨터 서버)를 말하면 실행환경은 보통 소프트웨어 spring, jbuilder 등등을 말함.

통신 경로(communication path)

• 물리적인 장치들이 표시되기 때문에 통신 경로를 표시, 주로 프로토콜을 스테레오 타입으로 표현함.
• 노드가 연결되어 실행 시에 서로 통신함을 표현함
• 통신 방법은 스테레오 타입으로 표현

아티팩트(artifact)

• 소프트웨어와 모든 문서

• 아티팩트는 물리적 실체를 모델화함 – 물리적인노드에배포되는실체 – 파일,실행파일,데이터베이스테이블,웹페이지등

   – <<manifest>>의존성관계
        • 모델 요소와 그것을 구현하는 아티팩트 사이의 관계
        • 아티팩트로 모델 요소를 물리적으로 구현함
  

아티팩트는 산출물, 소프트웨어든지 개발과정에 나오는 모든 문서를 아티팩트라고 한다. 코드 산출물들이 논리적인 개념을 산출물이 명백히 했다, 즉 고객 컴포넌트를 얘가 구현했다

논리적인 컴포넌트와 물리적 컴포넌트

설계단계에서 논리적 컴포넌트가 나오면 실제 물리적으로는 오른쪽 파일을 가지고 있다.

노드가 있는데 그 안에 실행환경이 있고 디비 서버 실행화경에는 오라클이 있고 수강신청 서버에는 세대가 있고 실행환경이 올라와 있고 수강신청  세대에는 browser는 매우 많다.

브라우저와 서버는 http 통신을 하고 서버와 서버 사이는 tcp ip 통신을 함

테그로 수행환경을 표시한다.

UML 확장 메커니즘

기존 모델링 언어를 수정하지 않고 모델링 기능을 확장

• 스테레오 타입(streotype) : «» 이나 이미지로 표현
• 테그값(tagged value) : 노트나 제약형식으로 표현
• 제약(constraint) : 자연어나 의사코드, 수식으로 표현

cf. Manifest vs deploy

배포는 실제 파일을 물리적인 실행환경 어딘가에 개시해서 실행시키는 것, manifest는 논리적인 것을 구현한 물리적인 것, 파일 얘는 가만히 있으면 실행 안됨. 그걸 실행하려고 deploy하는 것 배포 배치

바로 실행한 게 이미 배포한 것, 큰 서버용이 되면 pc에 올리는 것이 아니라 서버에 올리는 것 실행환경이 여러개일 수도 있고 등등… 컨테이너는 버추얼 머신이 돌아가는 것을 말함

그 환경에서 시행시키는 것.

Manifest는 명백히 하다. 즉 논리적인 개념을 실제로 코딩해서 구현했을 때 산출물인 파일이 나옴을 의미, 명백히 했다. 구현했다를 의미

실행은 구현된 얘를 deploy해야 실행된다