MQTT 프로토콜

IT 관련/기타 2019. 11. 20. 17:36

1. Mqtt 프로토콜이란?


Message Queue for Telemetry Transport


 발행-구독 기반 메시징 프로토콜로, 보통 TCP/IP 기반으로 구현된다.



2. 구조

사진 출처 : https://www.segger.com/products/security-iot/emmqtt/

 

 Mqtt는 하나의 브로커 서버와 다수의 클라이언트로 구성된다.


 위 그림에서 보듯이 냉장고, 스마트폰, PC 등이 클라이언트로 브로커 서버와 연결하고, 브로커 서버는 클라이언트들과 데이터를 주고 받는다.


 한 클라이언트가 메시지를 Publish하면 해당 메시지의 Topic을 Subscribe해둔 클라이언트들에게 메시지가 전달된다.


 클라이언트는 브로커 서버에게 어떤 Topic을 Subscribe하여 관심있는 메시지를 받아 볼 수 있다.


3. 특징


1) 발행-구독 기반

2) 가볍다

3) 1서버 - 다수의 클라이언트 구조

4) 3단계의 QoS 지원

5) 다양한 개발언어, 다양한 클라이언트 지원



1) 발행(Publish) - 구독(Subscribe) 기반

 Mqtt 프로토콜에서 주고받는 메시지는 (Topic + 메시지)로 구성되고, 각 클라이언트들은 특정 토픽들을 구독(Subscribe) 할 수 있다.

 한 클라이언트가 메시지를 발행(publish)하면 메시지의 Topic을 구독한 클라이언트들은 모두 그 메시지를 받고, 구독하지 않은 클라이언트들은 메시지를 받지 못한다.


2) 가볍다.

 Mqtt 프로토콜은 주고받는 메시지의 크기가 작기 때문에 IoT 디바이스 등 대역폭이 제한되는 디바이스에서 사용하기 좋다.


3) 1서버 - 다수의 클라이언트 구조

 Mqtt 프로토콜은 하나의 서버에 다수의 클라이언트가 연결하는 구조를 가진다.


4) 3단계의 QoS 지원

 Qos(Quality of Service).

 Mqtt 프로토콜은 0,1,2 세단계의 QoS를 지원한다.


 0 (fire and foget) 

 최대 1회 전송. Topic을 동해 메시지를 전송하고 클라이언트가 메시지를 제대로 받았는지 보장하지 않는다.


 1 (acknowledged delivery)

 최소 1회 전송. 구독하는 클라이언트가 메시지를 받았는지 불확실하면 정해진 횟수만큼 재전송한다.(중복 전송의 위험성 존재)


 2 (assured delivery)

등록된 클라이언트는 요구된 메시지를 정확이 한 번 수신할 수 있게 보장한다.


5) 다양한 개발언어, 다양한 클라이언트 지원

 C, 자바, Node.js, 파이썬 등 다양한 개발언어로 Broker/Client를 개발할 수 있는 라이브러리가 존재한다.


4. 레퍼런스

http://woowabros.github.io/experience/2017/08/11/ost_mqtt_broker.html

https://en.wikipedia.org/wiki/MQTT

http://mqtt.org/

'IT 관련 > 기타' 카테고리의 다른 글

MIT 라이센스  (2) 2019.09.26
블로그 이미지

서기리보이

,

1. ER (Entity & Attributes)


Entity(엔티티)

 ER 모델링의 기본 컨셉이다.

 엔티티는 mini world의 특정 사물이다 오브젝트를 나타낸다. (사람, 차, 집 등 물리적인 것이나, 회사, 직업, 강의 등 개념적인 것)


Attribute(속성)

 어트리뷰트는 엔티티의 특성을 나타낸다. 이름, 주민번호, 집주소, 성별 등을 어트리뷰트로 쓸 수 있다.


2. Attribute


Simple(Atomic) Attribute

 atomic한 하나의 value를 갖는 어트리뷰트다. 주민등록번호, 주민번호 등이 여기에 해당 할 수 있다.


Composite Attribute

 여러 어트리뷰트가 합쳐진 어트리뷰트다. 주소(아파트 동번호 + 아파트 호수 + 지역구 명 + 도시 명 + 국가 명), 이름(First name, Last name) 등이 있을 수 있다.


Multi-valued Attribute

 배열처럼 여러개의 값을 가지는 어트리뷰트다. 

 이전 학력(초등학교, 중학교, 고등학교, 대학교...) 등이 있을 수 있다.


 Composite + Multi-valued 어트리뷰트도 있을 수 있고, Composite, Multi-valued 어트리뷰트는 다양한 레벨에 존재 할 수 있다.(Composite 어트리뷰트를 여럿 가지는 Multi-valued 어트리뷰트, Multi-valued 어트리뷰트를 가지는 Composite 어트리뷰트 등)


2.1 Stored Attribute VS Derived Attribute


Stored Attribute

 값이 저장된 어트리뷰트.


Derived Attribute

 Stored Attribute로부터 도출될 수 있는 어트리뷰트.


 ex) 직원들 개개인의 정보만 저장된 DB에서, 직원의 나이는 Stored Attribute, 직원들의 숫자는 Derived Attribute.




3. Entity Type and Entity Set


Entity Type(intension)

 같은 어트리뷰트들을 가진 엔티티들의 집합. 스키마 같은 개념적인 것.


Entity Set(extension)

 어떤 엔티티 타입의 모든 엔티티들의 집합.


 이름 그대로 엔티티 타입은 타입, Set은 엔티티 인스턴스들의 집합이다.




4. Key Attribute(키 속성)


 어떤 엔티티 타입에서 각각의 엔티티가 unique한(서로다른 값을 가지는) 값을 가져야하는 어트리뷰트를 Key Attribute라고 부른다.



5. Value Sets(Domain)


 모든 Simple 어트리뷰트들은 특정 Value Set(Domain)과 연관된다.

 예를 들어 MM-DD-YYYY 형식의 Date라는 어트리뷰트의 M,D,Y는 모두 정수이고, 나이 어트리뷰트는 16~70 범위의 도메인을 가진다.

 

 Value Set은 수학적으로 다음과 같이 표현한다.

 

 P(V) : Power Set of V

 A(e) : 엔티티 e의 어트리뷰트 A 값

 

 이 정의는 싱글 밸류 어트리뷰트, 멀티 밸류 어트리뷰트에 모두 적용될 수 있다.


 컴포지트 어트리뷰트는 다음처럼 표현한다.



 V1,V2,...,Vn은 A의 Simple Component Attrubute의 Value Set이다.



6. ER 다이어그램


 다이어그램 구성요소



다이어그램 예시


7. Relationship


Relationship은 둘 이상의 엔티티를 연관시킨다.


ex)

 EMPLOYEE 홍길동 works on the SpaceX PROJECT

 EMPLOYEE 안철수 works for the H&R DEPRATMENT


 n개의 엔티티 E_1, E_2, E_3,... E_n 타입들 사이의 Relationship set R(관계집합)은 E_j(1 <= j <=n)에 속하는 엔티티 n개(e_1, e_2, ... , e_n)와 관계를 갖는 r_i의 집합이다.


7.1 Relation Type의 Degree

 왼쪽의 WORKS_ON Relationship은 두 가지 엔티티를 관계시키므로 Degree가 Binary고, 오른쪽의 SUPPLY 엔티티는 세가지 엔티티를 관계시키므로 Degree가 Ternary라고 한다.



7.2 Cardinality Ratio


 Cardinality Ratio는 한 엔티티가 Relationship 인스턴스에 참여할 수 있는 최대 숫자를 나타낸다.

 1:1, 1:N, N:1, M:N 이 있다.

 

1 : 1

N:1


 왼쪽 그림은 EMPLOYEE 하나당 DEPARTMENT 하나와 관계를 맺는 1:1관계, 오른쪽 그림은 DEPARTMENT 하나당 EMPLOYEE N개가 관계를 맺는 N:1 관계의 예시다.


7.3 Binary Relationship의 Structural Constraint


 Binary Relationship에는 다음과 같은 구조적 제약사항들이 존재한다.


Participation Constraint

 엔티티가 존재하려면 또다른 엔티티와 관계되어야한다. Total Participation이든 Partial Participation이든 말이다.



8. Weak Entity

 

 위크 엔티티 타입은 자기 자신을 위한 키 어트리뷰트를 가지지 않는 엔티티 타입을 말한다.

 자기 자체로는 존재 할 수 없고, 다른 엔티티와의 Partial Relationship 관계를 통해서만 존재할 수 있다.


 ER 다이어그램에서는 다음과 같이 표현한다.

블로그 이미지

서기리보이

,

REST API

기타 2019. 11. 15. 14:47

1. REST API(RESTFul API)란


 Representational State Transfer API.


 REST API에 대해서 간략히만 말하면, GET, POST, DELETE, PUT의 4가지 메소드를 제공하는 API 구조를 말한다.

 주로 웹 서버를 구현 할 때, 리소스 조회 - GET, 리소스 생성 - POST, 리소스 삭제 - DELETE, 리소스 수정 - PUT 메소드로 외부에서 리소스에 접근 가능하게 한다.


 이정도만 알고, 서버 구현용 언어(자바스크립트 등) 하나만 사용할 줄 알아도 기본적인 REST API 서버 기능 구현까지는 가능하다.


2. REST API 특징


1) 클라이언트-서버 구조

2) 인터페이스 일관성(Uniform interface)

3) 무상태성(Stateless)

4) 캐시 사용 가능

5) 계층형 구조(Layered System)

6) Code On Demand

7) 자체 표현구조(Self-describing)


1) REST API는 기본적으로 클라이언트와 서버가 분리된 클라이언트-서버 구조로 디자인된다.


2) 서버와 클라이언트가 일관된 인터페이스를 따르게 하여 클라이언트와 서버를 서로 떨어뜨려 놓는다. 이에 따라 서버와 클라이언트는 서로 독립적으로 발전 될 수 있다.


3) 세션, 쿠키 등 상태를 저장하는 방법을 사용하지 않는다. 상태가 없기 때문에 REST API 호출은 서로 독립적으로 수행되고, 각각의 호출에는 작업을 완수하기 위해 필요한 데이터가 모두 포함되어야한다.


4) 무상태성 때문에 Request의 크기가 커질 수 있기 때문에, 오버헤드 최소화를 위해 캐시를 사용할 것을 권장한다.


5) REST 서버는 다중 계층으로 구성 될 수 있다. 보안, 로드밸런싱, 암호화 계층을 추가하는 등 구조상의 유연성을 둘 수 있고, PROXY, 게이트웨이같은 네트워크 기반의 중간 메체를 사용할 수도 있는 것이다. 


6) Code On Demand. 필요에 따라 자바스크립트나 Applet 등 서버의 일부 코드가 클라이언트에게 제공 될 수 있다.


7) REST API는 메시지만 보고도 쉽게 이해할 수 있는 자체 표현적 구조를 가지고 있다.


 이 정도가 REST API의 특징들이다.

 사람들마다 6번이나 7번 특징은 제외시키는 경우도 있는데, REST API에 대해서 설명할 때는 이 7가지 정도만 알면 충분하다.



3. 디자인 가이드


1) URL은 정보의 자원을 표현해야한다.(리소스명은 동사보다는 명사를 사용)

2) 자원에 대한 행위를 HTTP 메소드(GET, POST, PUT, DELETE)로 표현한다.


1 ex)

GET http://192.168.0.63:1337/members/1

DELETE http://192.168.0.63:1337/members/1


2 ex)

회원 정보 조회 : GET members/1

회원 추가 : POST /members/2 (회원 정보는 request의 body 부분에 포함시킵니다.)

회원 삭제 : DELETE /members/1

회원 정보 업데이트 : DELETE /members/1 (수정 정보는 request의 body 부분에 포함시킵니다.)


 참고로 각각의 메소드를 섞어서 쓰는 것도 가능하긴 한데, 원래의 목적대로 사용하는 것이 올바른 디자인 방식이다.

 GET - 리소스 조회

 POST - 리소스 생성

 PUT - 리소스 수정

 DELETE - 리소스 삭제


 특히 GET, POST를 섞어서 쓰는 경우가 있는데, GET은 request의 body가 없기 때문에 URL로만 데이터를 표현한다. 그래서 전송가능한 데이터 크기에 제한이 있고, 기타 메소들마다 차이가 있으니 제역할에 맞게 사용하도록 하자.



4. REST의 3요소


- 리소스(URL)

- 메소드(GET, POST, PUT, DELETE)

- 메시지




5. 장점


- HTTP 프로토콜을 그대로 활용 할 수 있다.

- 유연하다.


 REST API 구조는 HTTP 프로토콜을 그대로 활용하기 때문에 HTTP 프로토콜을 기반으로 REST API 서버를 구현하기 위해서 추가적인 라이브러리나 소프트웨어를 설치할 필요가 없다.(GET, POST, PUT, DELETE 메소드 모두 HTTP 메소드의 일종이다.)


 REST API 구조를 이용하면 다양한 포멧의 데이터를 리턴할 수 있어 유연하고, 계층적 구조를 가지기 때문에 서버 구조 구현에도 좀 더 유연함을 가지고 있다.



6. 레퍼런스

https://www.mulesoft.com/resources/api/restful-api

https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html

https://ko.wikipedia.org/wiki/REST

https://ko.wikipedia.org/wiki/HTTP

https://meetup.toast.com/posts/92




블로그 이미지

서기리보이

,

1. 이터레이터 패턴이란

1.1 정의

 반복자를 사용하여 컨테이너를 가로지르며 컨테이너의 요소들에 접근하는 디자인 패턴


 이터레이터 패턴을 사용하면 집합체 내에서 어떤 식으로 일이 처리되는지 몰라도 그 안에 들어있는 항목들에 대해서 반복작업을 수행 할 수 있다.

 예를 들어, 집합체가 C++의 vector이든, list이든 상관 없이 같은 코드로 반복 작업을 수행할 수 있게 하는 것이다.



1.2 구조




 여기서 Client는 Aggregate라는 집합체 클래스에 대해 어떤 반복 작업을 수행하려고 한다.

 반복 작업은 Aggregate의 createIterator() 메소드로 Iterator를 생성해서수행한다.


 Iterator의 메소드들은 조금 다르게 구성되는 경우도 있다. 이 다이어그램에서 Iterator는 java.util.Iterator이고 C++의 Iterator의 경우 ++, -- 연산자를 사용할 수 있고, begin(), end() 등의 메소드를 포함한다.

 중요한 것은 어떤 구조이든지간에 집합체 내부 구조와 상관없이 반복 작업을 수행할 수 있다는 것이다.



2. 장점

- 집합체 클래스의 응집도를 높여준다.

- 집합체 내에서 어떤 식으로 일이 처리되는지 알 필요 없이, 집합체 안에 들어있는 모든 항목에 접근 할 수 있게 해준다.


 응집도는 클래스나 모듈이 특정 목적이나 역할을 얼마나 일관되게 지원하는지를 나타내는 척도다.

 이터레이터 패턴을 사용하면 원래 클래스의 역할(집합체 관리)에서 반복 작업이라는 다른 역할을 분리시켜 응집도를 높일 수 있고, 그 덕에 컬랙션 변경에 의한 클래스의 변경, 반복자 기능 변경에 의한 클래스 변경을 방지할 수 있다.


 이터페이터 패턴을 사용하면 집합체 내에서 어떤 식으로 일이 처리되는지 알 필요 없이 반복작업을 수행할 수 있다.

 집합체가 ArrayList로 이루어져있든, List로 이루어져있든 상관없이 똑같은 코드로 반복 작업을 수행 할 수 있는 것이다.


3. 레퍼런스

- Head First Design Pattern(O'REILLY media)

https://ko.wikipedia.org/wiki/%EB%B0%98%EB%B3%B5%EC%9E%90_%ED%8C%A8%ED%84%B4

https://www.geeksforgeeks.org/iterators-c-stl/ : C++ iterator example






블로그 이미지

서기리보이

,

0. 들어가기에 앞서


 클래스 다이어그램은 시스템 구조를 나타내고, 객체지향 모델링의 빌딩 블록으로 사용된다.

 여러 다이어그램들 중 객체지향 언어와 직접적인 연관을 가지는 유일한 다이어그램이고, 어플리케이션의 구조 디자인, 분석, 시스템의 역할 묘사, 그리고 Reverse Engineering(역공학)에 사용될 수 있다.


 개인적인 프로젝트 경험으로, 시스템이 어떤 요소들로 구성되는지 사람들에게 설명해주고, 시스템 유지 보수를 위해서 많이 사용했었다.


1. 클래스 다이어그램


 클래스 다이어그램은 클래스클래스들 사이의 관계를 나타내는 정적 모델이다.

 클래스 다이어그램은 클래스와 그들 사이의 Relationship(관계)로 구성된다.


1.1 클래스(Class)

- 시스템 내의 오브젝트들(사람, 장소, 물건 등등)

- 시스템 내의 정보를 저장/관리한다.

- Attribute(클래스의 특성), Operation(클래스의 동작)을 가진다.


예시

환자 클래스


 이는 진료 예약 시스템에서 환자(Patient)라는 클래스다.


 Patient 클래스는 amount(진료비), insurance carrier(보험회사 명)이라는 Attribute를 가지고, make appointment(진료 예약), calcuate last visit(최근 방문일 계산), change status(상태 변환), provides medical history(진료기록 제공)이라는 Operation을 가진다.



1.2 Relationship

- 클래스들 사이의 관계

- 클래스들 사이의 선으로 표현된다.


예시


 이것도 병원 진료 예약 시스템의 일부분이다.

 Patient는 Appoinment(예약)을 스케줄하는 관계를 가진다.

 Patient 1명이 여러번 진료 예약을 할 수 있으니, Patient는 n (0 <= n)개의 Appointment와 관계를 가진다.


클래스 다이어그램 예시 


 이 그림은 클래스 다이어그램의 한 예시다.



2. Relationship의 종류


 클래스들간의 관계를 나타내는 Relationship에는 다음과 같은 것들이 있다.

 


 

 Association

Generalization 

 

 

Aggregation 

Composition 


 Association은 클래스와 클래스 사이의 관계, 혹은 클래스 자신과의 관계를 나타낸다.

 단순한 줄로 표시하고, 연관된 클래스가 서로 어떤 관계를 나타내는지를 표시하고, Multiplicity Symbol이라는 것을 가진다. 이 예시의 경우 오른쪽 클래스 하나당 왼쪽 클래스가 0개이상 관계를 가지는 예시다.


 Generalizationa kind of 관계를 나타낸다.

 객체지향 언어에서 부모 클래스 상속, 인터페이스 구현을 이것으로 표현한다.


 Aggregation은 Association의 한 종류로, 논리적인 a part of 관계를 나타낸다. A class is a part of B class라고 하면 A는 논리적으로 B와 Aggregation 관계를 가진다고 표현 할 수 있다.


 Composition은 Association의 한 종류로, 물리적인 a part of 관계를 나타낸다. A class is a part of B class라고 하면 A는 논리적으로 B와 Composition관계를 가진다고 표현 할 수 있다.


Aggregation VS Composition

 Aggregation과 Composition은 모두 포함 관계를 나타내는데, 논리적/물리적인 관계를 나타낸다는 차이만 있다.


 이게 잘 헷갈리는 부분인데, A is a part of B일 때 이 관계가 Aggregation 관계면 B가 소멸되도 A는 소멸되지 않고, Composition 관계면 B가 소멸 되면 A도 함께 소멸된다고 보면 된다.

(그리고 두 경우 모두 A가 소멸되도 B는 소멸되지 않는다.)


 예를 들어, "학생 is a part of 동아리" 관계는 Aggregation 관계이고, "바퀴 is a part of 자동차" 관계는 Composition 관계다. 동아리가 소멸되어도 학생들은 소멸되지 않기 때문에 이는 논리적인 관계고, 자동차가 소멸 될 때는 바퀴도 함께 소멸되므로 물리적인 관계라고 볼 수 있다. (바퀴를 따로 떼서 파는 경우는 생각하지 말도록 하자.)


3.클래스 다이어그램 간소화


 클래스 다이어그램이 너무 복잡하면 이해하기가 어려울 수 있기 때문에, 클래스 다이어그램은 간소화 과정을 거칠 필요가 있다.
 클래스 다이어그램은 다음과 같은 방법으로 간소화 할 수 있다.

- Concrete Class만 묘사한다.

- view 메커니즘을 적용하여 필요한 클래스 몇가지만 골라서 묘사한다.

- 일부 클래스들을 패키지로 묶어서 취급한다.


 클래스에는 Concrete Class와 Abstract Class가 있다. 그 중 Concrete Class만 묘사하여 다이어그램을 간소화하는 방법인데, 이는 잘 고려해보고 써야한다.

 어떤 Concrete Class인 CClass가 Abstract Class인 AClass를 상속받고 있고, 다른 외부 클래스들이 주로 AClass와 관계를 가지는 경우, 이 방법을 쓰면 다이어그램을 이해하기 어려워지는 원인이 될 수 있기 때문이다.


 View 메커니즘은 원래 데이터베이스에 나오는 개념이다.

 데이터베이스에서 View는 필요한 데이터만을 원하는 형태로 골라서 본다는 개념인데, 이를 클래스 다이어그램에도 적용하여 상황에 따라 필요한 클래스들만 묘사하여 다이어그램을 간소화하는 방법이다.


 연관된 클래스들끼리 묶어 패키지로 만드는 방법이다. 패키지로 취급하면 다이어그램이 더 간단해질 수 있다.



4. 레퍼런스

System Analysis & Design 5th - WILEY

https://ko.wikipedia.org/wiki/%ED%81%B4%EB%9E%98%EC%8A%A4_%EB%8B%A4%EC%9D%B4%EC%96%B4%EA%B7%B8%EB%9E%A8 - 위키피디아 클래스 다이어그램

https://www.tutorialspoint.com/uml/uml_class_diagram.htm - Tutorial Point. Class Diagram

'IT 관련 > 소프트웨어 공학' 카테고리의 다른 글

Activity Diagram (액티비티 다이어그램)  (0) 2019.11.06
Use Case Diagram  (1) 2019.10.30
블로그 이미지

서기리보이

,

1. Activity Diagram이란?


 액티비티 다이어그램은 일련의 Activity들로 어떤 프로세스를 표현하는 다이어그램으로, 모든 종류의 프로세스를 표현하는데 사용 될 수 있다.



2. Acitvity Diagram의 구성

 

 

 


Action 

Activity 

 Object node

 

 


 

 Control flow

Object flow

 

 

 

 

Initial node 

Final Node

 

 

 

 

Decision node 

Merge node 

 

 

 

 

Fork node 

Join node 

 



 Action/Activity - 어떤 Action이나 Action의 집합. 동사 + 명사로 이름이 붙여짐.


 Object Node - 한 Activity에서 다른 Activity로 이어지는 flow of information을 나타내는 것.


 Control Flow - 실행 순서를 나타내는 화살표.


 Object Flow - Flow of Object를 나타내는 것.


 Initial Node - Activity Diagram의 시작점(Action 들의 시작점)


 Final Node - Activity Diagram 종료지점(Activity의 Flow들이 모두 끝나는 시점)


 Decision Node - 분기점.


 Merge Node - Decision Path들을 하나로 모으는 노드.(Decision Node로 나눠진 Control flow를 다시 합침)


 Fork Node - 평행적으로 수행되는 Flow를 나누는 노드


 Join Node - Fork Node로 나눠진 Control Flow를 다시 하나로 합치는 노드


 구성 요소들을 정리해놓고 보니 너무 많고 애매한 정의가 많아서 정의를 달달달 외우는 것 보다는 예시를 보면서 이해하고, 나중에 필요할 때는 예시와 정의를 같이 찾아보는게 좋겠다.


 컨트롤 노드

 Initial node, Final node, Decision node, Merge node, Forke node, Join node를 컨트롤 노드(Control Node)라고 부른다.


 예제

 다음 액티비티 다이어그램은 병원의 진료 예약 관리 기능에 대한 것이다.

 진료 예약 관리에서는 예약, 예약 취소, 예약 변경 기능을 제공한다.


 처음 이 액티비티가 시작되면 환자의 정보를 받는다.(Get Patient Onformation)

 이 때 예약정보(Appt Request Info) 오브젝트가 생성되어 이후 예약 할 지, 예약을 취소 할 지, 예약을 변경 할 지 결정할 때 사용된다.(기존 환자)

 또, 이 오브젝트는 신규 환자가 예약을 잡을 때도 사용된다.

 환자의 정보를 받은 이후에는 기존에 등록된 환자인지, 신규환자인지에 따라 다른 프로세스가 진행된다.

 

3. Swimlanes

 Swimlane은 오브젝트들간의 역할 분리를 나타낸다. 분리된 역할들이 서로다른 오브젝트에서 평행적으로 수행된다.

 Swimlane은 가로로 그려도 되고 세로로 그려도 된다.


 예제

 이 예제는 학교 점심 도시락을 만드는 Activity에 대한 액티비티 다이어그램이다.



 이 액티비티가 시작되면 바로 firstParent와 secondParent로 flow가 분할되어 평행적으로 진행된다.

 firstParent를 보면 내부에서 다시 GetJelly, GetPeanutButter, GetBread로 flow가 분할되어 평행적으로 수행되는데, 처음에 firstParent, secondParent로 나뉜것과는 달리 모든 flow가 오브젝트 내부에서 수행된다는 차이가 있다.



4. Activity Diagram 작성 가이드라인

 

1. 작성하는 Activity의 Scope를 정한다.

2. Activity들을 식별하고, flow로 각각을 잇는다.

3. 필요한 Decision들을 식별한다.

4. 프로세스 상에서 평행적으로 수행될수 있는 부분들을 식별한다.

5. 액티비티 다이어그램을 작성한다.


5. Activity Diagram과 Usecase의 관계

 

- 유즈케이스 디스크립션상에서 하나의 Flow가 액티비티 다이어그램의 하나의 액션/액티비티에 대응된다.

- 액티비티 다이어그램 상의 모든 오브젝트들은 유즈케이스 디스크립션에서 어급되는 것이어야한다.

- 유즈케이스 디스크립션 상의 흐름(Sequence)는 액티비티 다이어그램의 흐름과 맞아야한다.


6. 레퍼런스

System Analysis & Design 5th - WILEY








'IT 관련 > 소프트웨어 공학' 카테고리의 다른 글

Class Diagram  (0) 2019.11.11
Use Case Diagram  (1) 2019.10.30
블로그 이미지

서기리보이

,