[정의] 트랜잭션이 한 데이터 아이템을 접근하려 할 때, 그 트랜잭션의 타임스탬프와 접근하려는 데이터 아이템의 여러 버전의 타임스탬프를 비교하여, 현재 실행하고 있는 스케줄의 직렬가능성이 보장되는 적절한 버전을 선택하여 접근하도록 하는 기법

 

[특징]  판독 요청을 거절하지도, 대기하지도 않음.  트랜잭션간의 충돌문제는 대기가 아니라 복귀처리 함으로 연쇄 복귀초래 발생 가능성

 

 

 

 

 

 

[동작설명]
1) 데이터를 변경할 때마다 그 변경사항을 Undo 영역에 저장해 둔다
2) 트랜잭션 시작 시점 이후에 변경된(진행 중이거나 이미 커밋된) 값을 발견하면,
    Undo 영역에 저장된 정보를 이용, CR Copy 를 생성하여 그것을 읽는다. (SCN 이용)
3) 쿼리 도중에 배타적 Lock 이 걸린, 즉 변경이 진행 중인 레코드를 만나도 진행가능
※ SCN(System Change Number) : commit 발생시, 트랜잭션에 연속증가, 고유번호

※ CR Block : 읽기 일관성(Consistent Read) Block 아래 그림에서는 Data Block을 의미


 

 

 

 

 

 

 

 

 

'ITPE > DB' 카테고리의 다른 글

데이터 모델링  (0) 2021.03.06
ARIES (Algorithms for Recovery and Isolation Exploiting Semantics)  (0) 2021.03.06
Timestamp Ordering  (0) 2021.03.06
낙관적 검증(Validation)  (0) 2021.03.06
무결성  (0) 2018.03.03

 

 

 

 

 

 

[정의] 시스템에서 생성하는 고유 번호인 시간 스탬프를 트랜잭션에 부여하는 것으로 트랜잭션간의 순서를 미리 선택하는 방법

 

[종류] 시스템 시계, 논리적 계수기


[구성]
1) read_TS(X): 항목 X 의 읽기 타임스탬프(read timestamp)로서 항목 X 를 성공적으로 읽은 트랜잭션들의 타임스탬프 중 가장 큰 값. 즉, read_TS(X) = TS(T)이고 여기서 T 는 X 를 성공적으로 읽은 가장 최근의(youngest) 트랜잭션.
2) write_TS(X): 항목 X 의 쓰기 타임스탬프(write timestamp)로서 항목 X 를 성공적으로 기록한 트랜잭션들의 타임스탬프 중 가장 큰 값. 즉, write_TS(X) = TS(T)이고 여기서 T 는 X 를 성공적으로 기록한 가장 최근의 트랜잭션.

 

 

 

 

 

 

 


[기본적 타임스탬프 순서(Basic Timestamp Ordering)]
- 트랜잭션 T 가 write_item(X) 연산을 수행하려고 할경우:
1) read_TS(X) > TS(T) 또는 write_TS(X) > TS(T)이면 T 를 철회하고 복귀시키고 그 연산을 거부(reject)한다. => 해당 트랜잭션 순서가 이미 지남
2) a 의 조건이 발생하지 않으면 T 는 write_item(X) 연산을 수행하고 write_TS(X)를 TS(T)로 설정한다.
- 트랜잭션 T 가 read_item(X) 연산을 수행하려고 할 경우:
1) write_TS(X) > TS(T)이면 T 를 철회하고 복귀시키고 그 연산을 거부한다. => 해당 트랜잭션 순서가 이미 지나서 다른 값이 있을수도 있음.
2) write_TS(X) ≤ TS(T)이면 T 의 read_item(X) 연산을 수행하고 read_TS(X)를 TS(T)와 현재의 read_TS(X) 중 큰 값으로 설정한다. => read_TS(X)는 가장 큰값.
※ Cascade rollback이 발생할 수 있음. ==> Strict timestamp(해당 순번TS(T)까지 Read_TS, Write_TS가 올때까지 대기하는 방식)

 

 

 

 

 

 

 

 

'ITPE > DB' 카테고리의 다른 글

데이터 모델링  (0) 2021.03.06
ARIES (Algorithms for Recovery and Isolation Exploiting Semantics)  (0) 2021.03.06
MVCC (MultiVersion concurrency control)  (0) 2021.03.06
낙관적 검증(Validation)  (0) 2021.03.06
무결성  (0) 2018.03.03

 

[정의] 트랜잭션 수행중 어떠한 검증도 수행하지 않고, 트랜잭션 종료시 검증을 수행하여 데이터베이스에 반영하는 기법

 

[기법] 사용자들이 같은 데이터를 동시에 수정하지 않을 것이라고 가정하는 낙관적 동시성 제어 기법에 기반


[처리단계]  판독 → 확인 → 실행(기록/철회)
- 판독(Read phase, R) : 트랜잭션의 모든 갱신은 사본에 대해서만 수행, 실제 DB 수행하지 않음
- 확인(Validation phase, V) : 판독단계에서 사본에 반영된 트랜잭션의 실행결과를 DB반영전 직렬 가능성의 위반여부를 확인
- 기록(Write phase, W) : 확인 통과시 실행결과를 DB에 반영, 실패시 결과 취소후 트랙잭션 복귀


[확인 단계의 확인 검사 조건]
- 타임스탬프 :
  1) Start(Ti) : 판독 시작시간
  2) Validation(Ti) : 판독 끝나고 확인 시작한 시간
  3) Finish(Ti) : 최종 기록 단계를 완료한 시간
- 판독 및 기록 집합 :  확인 작업 위해 트랜잭션의 판독집합 (read set) 과 기록집합(write set)을 유지.
  1) 판독집합(read set): Ti가 판독한 데이터 아이템의 집합
  2) 기록집합(write set): Ti가 기록한 데이터 아이템의 집합

 

 

 


[직렬성 검사 조건]
① Finish(Ti) < Start(Tj)
② Start(Tj) < Finish(Ti) <Validation(Tj) 이고 Write-Set(Ti) ∩ Read-Set(Tj) = F
③ Validation(Ti) < Validation(Tj) 이고 Write-Set(Ti) ∩ Read-Set(Tj) = F 이며 Write-Set(Ti) ∩ Write-Set(Tj) = F
- TS(Ti)<TS(Tj)의 관계에 있는 모든 트랜잭션 Ti 에 대해 위 3가지 조건 중 하나만 만족하면 트랜잭션들 간에 간섭이 없는 것으로 보고 확인을 성공
- 하나라도 만족하지 못하면 트랜잭션 간의 간섭이 일어났을 가능성이 있기 때문에 실패

 

 

 

 

 

'ITPE > DB' 카테고리의 다른 글

데이터 모델링  (0) 2021.03.06
ARIES (Algorithms for Recovery and Isolation Exploiting Semantics)  (0) 2021.03.06
MVCC (MultiVersion concurrency control)  (0) 2021.03.06
Timestamp Ordering  (0) 2021.03.06
무결성  (0) 2018.03.03

 

 

 

 

 - 최초 제안은 4개의 파트로 시작

 - 2013년 키워드 주도 테스팅이 독립파트로 구성 (2016.07 최종 국제표준안 완료)

 

 

 

 - ISO29119의 핵심은 part2 테스트 프로세스

 - part3 : 테스트 프로세스의 결과를 기술하는 문서

 - part4 : 테스트 프로세스에 따라 테스트 기법 결정

 

 

 

 

 

[각 파트별 주요 내용]

 

 

 

 

[키워드 주도 테스팅]

테스트 데이터와 예상 결과뿐만 아니라, 테스트 대상 어플리케이션과 관련된 키워드를 포함한, 데이터 파일을 사용하는 스크립트 기법. 제어 스크립트가 테스트하기 위한 목적으로 호출한 특별 지원 스크립트로 키워드를 해석.

 

 

 

 

 

※ 참고 : 소프트웨어 테스팅 국제표준 (임태형 / TTA SW시험인증연구소)

 

 

 

'ITPE > SE' 카테고리의 다른 글

CMMI  (0) 2018.04.12
TOC-Thinking Process  (0) 2018.04.06
단위 테스트 및 통합테스트  (0) 2018.02.22

 

 

 

 

[내용] 컴퓨팅 시스템을 구성하는 자원(프로세서, 메모리, I/O)을 필요한 만큼, 독립적으로 즉시 구성하여 사용하고자 하는 요구에서 도출된 개념으로 시스템을 유연하게 확대 및 축소할 수 있기 때문에 클라우드 컴퓨팅 환경에 적합한 엔터프라이즈 서버의 차세대 구조.

 

 

 

[참고사이트] 정리가 잘 되어있음.

 

https://www.slideshare.net/chosangwon7/definition-and-tendency-of-fabric-computing

 

 

 

끝.

 

 

 

'ITPE > DS' 카테고리의 다른 글

ITWorld 용어풀이 | 인터클라우드  (0) 2018.02.22

 

 

 

 

출처 : http://blog.naver.com/sealriel/10189298953

 

 

 

OLAP(online analytical processing) 개념

 

OLAP는 쉽게 다차원 분석으로 생각하면 된다. 정의를 내리자면, 최종사용자가 직접 다차원으로 이루어진 데이터로부터 통계적인 요약 정보를 분석하여 의사결정 에 활용하는 방식을 말한다.

 

OLAP 그림출처 : http://118k.tistory.com/66

OLAP 시스템은 데이터 웨어하우스나 데이터 마트와 같은 시스템과 상호 연

관되는 정보 시스템이다.

데이터 웨어하우스가 데이터를 저장하고 관리한다면 OLA P는 데이터 웨어하

우스의 데이터를 전략적인 정보로 변환시키는 역할을한다.

OLAP는 중간 매개체 없이 이용자들이 직접 컴퓨터를 이용하여 데이터에 접

근하는 데 있어 필수적인 시스템이라할수 있다.

 

올해 가장 매출이 저조한 대리점과 저조한 상품 품목은 ?

    서울지역에서 가장 매출이 높은 상품과 순이익이 가장 높은 상품은 ?

    지역별로 전월 대비 매출이 가장 높은 상품은 ?

출처 : http://i-bada.blogspot.kr/2014/01/olap-online-analytical-processing.html

 

 

 

 

OLAP 연산

- Roll-up : 분석할 항목에 대해 한 차원의 계층 구조를 따라 단계적으로 구체적인 내용의 상세 데이터로부터 요약된 형태의 데이터로 접근하는 기능

 

- Drill- down : 분석할 항목에 대해 한 차원의 계층 구조를 따라 단계적으로 요약된 형태의 데이터로부터 구체적인 내용의 상세 데이터로 접근하는 기능

 

 

- Pivoting : 보고서의 행,열,페이지 차원을 바꾸어 볼 수 있는 기능

 

- Slicing : 다차원 데이터 항목들을 다양한 각도에서 조회하고 자유롭게 비교하는 기능

-Dicing : 위와 동일하지만 slicing을 더 쪼개는 형태.

 

OLAP 종류

ROLAP(Relational-OLAP) : 관계형 데이터베이스와 관계형 질의어를 사용하여 다차원 데이터를 저장하고 분석함

MOLAP(Multi- dimension OLAP) : 다차원 데이터를 저장하기 위해 특수한 구조의 다차원 데이터베이스를 사용하고 데이터 검색 속도를 향상시키기 위해 큐브 캐시(Cube Cache )라고 하는 주기억장치 속에 데이터 큐브를 보관함

데이터 큐브는 데이터가 여러차원으로 모델링되는 것으로,차원(Dimension )과 사실(F a c t)로 정의된다. 차원은 한 조직이 그것에 대하여 기록하기를 원하는 시각이나 개체를 의미한다. 또한, 위 그림과 같은 데이터웨어하우스 스키마들을 사용 한다.

 

HOLAP(Hybird OLAP ) : ROLAP와 MOLAP의 특성을 모두 가지고 있으며,빠른 검색이 필요한 경우에는 요약을 메모리에 저장하고 기본 데이터나

다른 요약들은 관계형 데이터베이스에 저장함

그림출처 : http://apandre.wordpress.com/data/datacube/

 

OLAP Cubes

OLAP (online analytical processing) cube on one hand extends a 2-dimensional array (spreadsheet table or array of facts/measures and keys/pointers to dictionaries) to a multidimensional DataCube, a…

apandre.wordpress.com

 

 

 

 

 

 

네이버 쉽게 배우는 소프트웨어 공학

 

http://terms.naver.com/entry.nhn?docId=3533059&cid=58528&categoryId=58528

 

 

 

쉽게 배우는 소프트웨어 공학

CMMI 모델

 

1. CMMI 모델의 등장 배경과 개념

1984년 카네기멜론 대학에 소프트웨어 공학 전문 연구소인 SEI(software engineering institute)가 미 국방성의 지원을 받아 미국 소프트웨어 산업 능력을 향상시킬 목적으로 설립되었다. 미 국방성이 이 연구소에 요청한 것은 소프트웨어를 위한 성숙도 모델의 개발이다. 미 국방성은 수많은 업체로부터 소프트웨어 납품을 받는데 업체마다 품질이 달랐다.

그래서 업체의 개발 능력이 과연 어느 정도인지 객관적으로 측정하고, 요구하는 품질에 대한 기준을 제시해줄 목적으로 요청을 한 것이다. 그 결과 성숙도 모델인 SW-CMM(SW-Capability Maturity Model, 이하 CMM)이 만들어졌다. 이는 프로젝트 개발 조직에서 프로세스 성숙도가 높은 조직이 성숙도가 낮은 조직보다 높은 품질의 소프트웨어를 생산할 수 있다는 모델이다.

CMM은 소프트웨어 공급자의 강점과 약점을 평가하는 수단으로, 개발자가 프로세스의 능력을 스스로 평가하고 평가 결과에 따른 개선 방향을 설정하는 데도 사용되었다. 이 후 여러 모델이 추가 개발되고, 소프트웨어 사용 환경의 변화, 기존 모델 등과의 중복 문제 등을 해결하기 위하여 새로운 모델의 필요성이 대두되었다.

SEI는 소프트웨어 역량 성숙도 모델 CMM 2.0 버전과 SECM(System Engineering Capability Model) 그리고 통합제품개발(integrated product development)-CMM 모델을 통합하고 정리하여 ISO 15504(SPICE)와 호환이 가능한 CMMI라는 통합 모델을 2000년 8월 발표하게 되었다. CMM과 CMMI의 차이는 [표 9-12]와 같다.

표 9-12 CMM과 CMMI의 비교

표 9-12 CMM과 CMMI의 비교
단계 CMM CMMI
1 초기(initial) 초기(initial)
2 반복(repeatable) 관리(managed)
3 정의(defined) 정의(defined)
4 관리(managed) 정량적 관리(quantitatively managed)
5 최적화(optimizing) 최적화(optimizing)

CMMI(Capability Maturity Model Integration)는 프로세스 표준화의 기준과 방향을 제시하므로 조직 프로세스에 대한 측정뿐 아니라 평가 지표로도 활용할 수 있는데, 이때 능력을 평가하거나 성숙도를 평가할 수 있다. CMMI의 각 약자는 다음과 같은 의미를 지닌다.

■ C(능력, Capability)
일반적으로 능력이 있다, 없다는 뭔가를 할 수 있는 힘이 있느냐, 없느냐로 말할 수 있다. 소프트웨어 개발에서 능력이란 개발 목표(주어진 기간, 정해진 비용, 고품질 등)를 달성할 수 있는 힘이다. 능력이 있는 조직은 개발 목표를 달성할 수 있다. 그러나 능력이 없는 조직은 개발 기간이 연장된다거나 비용이 더 추가된다거나 품질이 떨어지는 소프트웨어를 개발함으로써 개발 목표를 달성하지 못한다.

■ M(성숙도, Maturity)
성숙의 사전적 의미는 '생물의 발육이 완전히 이루어짐', '몸과 마음이 자라서 어른스럽게 됨', '경험이나 습관을 쌓아 익숙해짐' 등으로, 다 자라서(완성되어) 책임감이 있는 느낌을 준다. 소프트웨어 개발에서 성숙도가 높은 조직이란 책임감이 있는 조직으로서 사용자가 만족하는 고품질의 소프트웨어를 개발하기 위해 개발 과정에서 객관적이고 정량적인 근거에 따라 프로세스가 측정되고 지속적인 개선이 이루어지는 조직을 말한다.

반면 성숙하지 못한 조직은 책임감이 떨어지는 서투른 조직으로, 개발 프로세스가 객관적인 근거에 의해 진행되지 않기 때문에 사용자가 만족하는 고품질의 소프트웨어가 만들어질 수 없다.

표 9-13 성숙도가 높은 조직과 낮은 조직의 특징

표 9-13 성숙도가 높은 조직과 낮은 조직의 특징
구분 특징
성숙도 높음 • 소프트웨어 개발/관리 프로세스가 조직 차원에서 이루어진다.
• 구성원들이 소프트웨어 프로세스를 잘 알고 있다.
• 프로세스를 따라 수행함으로써 역할과 책임이 명확하다.
• 제품 품질을 중요하게 여기고, 사용자의 만족도를 측정한다.
• 조직 차원의 표준 프로세스가 일관성 있게 준수되고 있다.
성숙도 낮음 • 조직 내에 정해진 프로세스가 없어 필요할 때마다 임시방편으로 만들어 사용하고 있다.
• 문제가 발생했을 때 근본적인 해결 방안을 찾기보다는 임시방편으로 해결하려고 한다.
• 객관적인 비용 산정과 근거에 의한 일정이 산출되지 않아 개발 기간과 비용이 초과하는 경우가 많다.
• 제품 품질에 대해 객관적으로 평가하지 못한다.
• 제품의 기능, 품질보다 납기일을 최우선으로 생각한다.

■ M(모델, Model)
여기서 모델은 일반적으로 알고 있는 모델의 의미와 약간 다르다. 여기서는 프로세스를 감사(audit)하는 의미로 사용한다. 즉 기준대로 하고 있는지, 그렇지 않은지를 검사하는 것이다. CMMI는 그 기준을 제시하고 있는데 그것이 '수행 지침(best practice)'이라는 모델이다. 조직이 프로세스 개선을 원한다면, CMMI는 그 조직이 무엇을 해야 하는지에 대해 '수행 지침'을 통해서 알려준다. 그러나 구체적으로 어떻게 할지는 조직의 역량에 맡겨둔다.

■ I(통합, Integration)
여러 가지 프로세스의 기준을 하나로 통합했다는 의미이다. 소프트웨어 개발 생명주기의 각 단계, 즉 계획부터 유지보수까지 모든 과정을 통합한 모델이라는 의미가 있다.

결국 CMMI는 조직의 프로세스에 대한 가이드이자 기준이며 '능력'과 '성숙도'로 조직의 프로세스를 측정하고 평가하는 모델의 통합 버전인 프로세스 개선 성숙도 모델이라 할 수 있다.

2. CMMI의 구성

CMMI는 개발 조직의 소프트웨어 프로세스 성숙도를 [표 9-14]처럼 5단계로 구분한 후, 각 단계별 목적을 달성하기 위해 [표 9-15]와 같이 4개의 범주로 구분된 22개의 프로세스 영역(PSProcess Area)으로 구성하고 있다.

표 9-14 CMMI 5단계(소프트웨어 프로세스 성숙도)

표 9-14 CMMI 5단계(소프트웨어 프로세스 성숙도)
단계 프로세스 내용
1. 초기(initial) 단계 프로세스 없음 예측/통제 불가능
2. 관리(managed) 단계 규칙화된 프로세스 기본적인 프로젝트 관리 체계 수립
3. 정의(defined) 단계 표준화된 프로세스 조직 차원의 표준 프로세스를 통한 프로젝트 지원
4. 정량적 관리(quantitatively managed) 단계 예측 가능한 프로세스 정량적으로 프로세스가 측정/통제됨
5. 최적화(optimizing) 단계 지속적 개선 프로세스 프로세스 개선 활동

표 9-15 CMMI의 4가지 범주로 구분된 22개의 프로세스 영역

표 9-15 CMMI의 4가지 범주로 구분된 22개의 프로세스 영역
범주 프로세스 영역
프로젝트 관리 프로젝트 계획, 감시, 제어와 관련된 프로젝트 관리 행위들을 다루는 프로세스 영역들로 구성됨.

① 프로젝트 계획(PPproject planning-L2)
② 프로젝트 감시 및 통제(PMCProject Monitoring and Control-L2)
③ 협력 업체 관리(SAMSupplier Agreement Management-L2)
④ 통합된 프로젝트 관리(IPMIntegrated Project Management+IPPD-L3)
IPPDIntegrated Product and Process Development
⑤ 위험 관리(RSKMRisk Management-L3)
⑥ 정량적 프로젝트 관리(QPMQuantitative Project Management-L4)
공학 여러 공학 분야에 걸쳐서 공유되는 개발과 유지보수와 관련된 활동들을 다루는 프로세스 영역들로 구성됨.

⑦ 요구 사항 관리(REQMRequirements Management-L2)
⑧ 요구 사항 개발(RDRequirements Development-L3)
⑨ 기술적 솔루션(TSTechnical Solution-L3)
⑩ 제품 통합(PIProduct Integration-L3)
⑪ 확인(VERVerification-L3)
⑫ 검증(VAL : Validation-L3)
프로세스 관리 프로세스의 정의, 계획, 배치, 구현, 감시, 제어, 평가, 측정, 개선과 관련된 여러 프로젝트에 걸쳐진 활동들을 포함하는 프로세스 영역들로 구성됨.

⑬ 조직 차원의 프로세스 개선(OPFOrganizational Process Focus-L3)
⑭ 조직 차원의 프로세스 정의(OPDOrganizational Process Definition+IPPD-L3)
⑮ 조직 차원의 교육 훈련(OTOrganizational Training-L3)
⑯ 조직 차원의 프로세스 성과 관리(OPPOrganizational Process Performance-L4)
⑰ 조직 차원의 혁신 활동 전개(OIDOrganizational Innovation and Deployment-L5)
지원 제품 개발과 유지보수를 지원하는 활동들을 다루는 내용으로, 프로젝트를 목적으로 한 프로세스 영역과 조직에 적응하는 것을 목적으로 하는 프로세스 영역들로 구성됨.

⑱ 형상 관리(CMConfiguration Management-L2)
⑲ 프로세스/제품 품질 보증(PPQAProcess and Product Quality Assurance-L2)
⑳ 측정 및 분석(MAMeasurement and Analysis-L2)
㉑ 의사결정 분석 및 해결(DARDecision Analysis and Resolution-L3)
㉒ 근본 원인 분석 및 해결(CARCausal Analysis and Resolution-L5)

CMMI는 22개 각각의 프로세스 영역을 만족시키기 위해서 반드시 일반(공통) 목표(GGGeneric Goal)와 세부(구체) 목표(SGSpecific Goal)를 만족시켜야 한다.

■ 일반 목표와 수행 지침
• 목표 : 모든 프로세스 영역에 공통으로 적용되는 목표로서 하나의 프로세스 영역에서 일반적인 목표를 달성했다는 것은 해당 프로세스의 활동들이 조직에 내재화되어 자연스럽게 수행될 수 있음을 의미한다.

• 수행 지침 : 일반적인 목표를 만족시키기 위해 수행해야 하는 활동이 무엇인지를 설명한다.

■ 세부 목표와 수행 지침
• 목표 : 특정 프로세스 영역에만 적용되는 좁은 의미의 구체적인 목표로서 특정 프로세스 영역을 만족시키기 위해서는 반드시 세부적인 목표를 완전히 만족시켜야 한다.

• 수행 지침 : 세부적인 목표를 만족시키기 위해 수행해야 하는 활동이 무엇인지를 설명한다.

각 프로세스 영역의 구성 요소는 3가지 범주로 그룹화되는데, 22개의 프로세스 영역(PA)이 [그림 9-18]과 같은 구조를 따른다. 반드시 달성해야 할 필수 구성 요소에 일반 목표와 세부 목표가 있고, 수행할 것으로 기대되는 예상 구성 요소에는 일반 수행 지침과 세부 수행 지침이 있으며, 정보 제공 측면의 다양한 구성 요소가 있다.

 

 

 

■ 필수 구성 요소
조직이 프로세스 영역을 만족시키기 위해 무엇을 성취해야 하는지를 기술하는 구성 요소이다. 세부 목표와 일반 목표가 이에 해당한다. 목표를 만족시키는 것은 프로세스 영역이 만족되었는지를 결정하기 위한 기반으로 평가 시 사용된다.

■ 예상 구성 요소
조직이 필수 구성 요소를 성취하기 위해 전형적으로 무엇을 구현해야 하는지를 기술하는 구성 요소이다. 이 구성 요소들은 누가 평가를 수행하고 개선을 구현하는지를 가이드한다. 일반 수행 지침과 세부 수행 지침이 이에 해당된다.

■ 정보 제공 구성 요소
필수 구성 요소와 예상 구성 요소에 접근할 수 있도록 돕는 세부 내용을 제공한다. 예제 작업 산출물, 하위 지침, 일반 수행 지침의 정책, 입문 노트, 관련 프로세스 영역 등이 이에 해당된다.

 

 

3. CMMI의 평가 방법

CMMI 평가는 단계적 표현(staged representation) 방법의 성숙 단계(maturity level)와 연속적 표현(continuousrepresentation) 방법의 능력 단계(capability level)로 나누어 이루어진다.

 

4. 단계적 표현 방법의 성숙 단계

성숙 단계는 조직에서 해당 업무를 얼마나 체계적으로 수행하고 있는지를 나타내며, 지표로는 1에서 5까지 5단계로 구분하여 사용하고 있다.

CMMI 성숙 단계는 [표 9-16]과 같이 단계별로 충족되어야 하는 프로세스 영역이 정의되어 있고, [그림 9-21]처럼 계단형으로 구성되어 단계적 표현 방법이라고도 한다. 그리고 각 단계의 프로세스 영역을 모두 만족하면 다음 단계로 넘어간다. 예들 들어, 정의 단계는 관리 단계의 프로세스 영역을 모두 만족하고, 정의 단계의 프로세스 영역까지 모두 만족한다는 의미이다.

표 9-16 성숙도 단계별 프로세스 영역

표 9-16 성숙도 단계별 프로세스 영역
단계 범주 프로세스 영역
1. 초기 단계 프로세스 없음
2. 관리 단계 프로젝트별로 프로세스 존재 • 요구 사항 관리
• 프로젝트 계획 수립
• 프로젝트 감시 및 통제
• 협력 업체 관리
• 측정 및 분석
• 프로세스/제품 품질 보증
• 형상 관리
3. 정의 단계 조직 차원의 프로세스 존재(프로세스 표준화) • 요구 사항 개발
• 기술적 솔루션
• 제품 통합
• 검증, 확인
• 조직 차원의 프로세스 개선
• 조직 차원의 프로세스 정의
• 조직 차원의 교육 훈련
• 통합된 프로젝트 관리
• 위험 관리
• 의사결정 분석 및 해결
4. 정량적 관리 단계 측정 가능한 정량적 프로세스 존재 • 조직 차원의 프로세스 성과 관리
• 정량적 프로젝트 관리
5. 최적화 단계 프로세스를 지속적으로 개선 • 조직 차원의 혁신 활동 전개
• 근본 원인 분석 및 해결
 
 

5. 연속적 표현 방법의 능력 단계

능력 단계에 대한 이해를 돕기 위해 성숙 단계와 같은 예를 사용해보자. 연속적 표현 방법의 능력 단계는 국어(80점), 수학(90점), 영어(70점), 과학(85점), 사회(78점)의 각 과목별 등급을 정하는 것이다. 즉 능력 단계는 프로세스 영역 능력 수준을 측정하는 연속적 표현 모델로, 해당 조직의 각 프로세스 영역에 대한 능력이 얼마나 되는지를 나타낸다.

능력 단계는 프로세스 영역별 능력 수준을 확인함으로써 어떤 영역이 잘되고, 어떤 영역의 능력이 떨어지는지를 살펴 보완할 부분을 파악하기도 한다.

이렇게 프로세스 영역별 능력 수준을 점검하면 어떤 프로세스 영역이 다른 프로세스 영역에 비해 떨어지는지 알 수 있으므로 그 영역만 집중적으로 관리할 수 있다. 또 중요하다고 생각하는 프로세스 영역에 대해서는 그 수준을 높이기 위해 더 많은 자원을 투입하여 능력 수준을 높일 수 있다. 앞에서 든 비유로 설명한다면, 과학 과목이 다른 과목보다 성적이 낮은 경우 과학 과목을 열심히 공부해서 점수를 올리고, 수학이 중요하다고 생각하면 다른 과목보다 수학을 집중적으로 공부하여 수학 실력을 향상시킬 수 있는 것과 같다.

[네이버 지식백과] CMMI 모델 (쉽게 배우는 소프트웨어 공학, 2015. 11. 30., 한빛아카데미(주))

 

 

 

'ITPE > SE' 카테고리의 다른 글

소프트웨어 테스팅 국제표준 - ISO 29119  (0) 2021.02.19
TOC-Thinking Process  (0) 2018.04.06
단위 테스트 및 통합테스트  (0) 2018.02.22

 

 

 

 

출처 : https://blog.naver.com/jhlee1026200/20139655031

 

 

* Thinking Process

 

1. 정의

기업의 의사결정에 있어서 부서,조직간의 복잡하게 얽힌 문제들로 인해서 대립이 생기고 결국 논의자체도 진행되지 못하는 상황을 개선시키위해 근본원인을 찾아 이를 극복할 수 있는 혁신적인 방안을 도출하고 하기와 같은 일련의 과정을 논리적으로 파악해 나감.

-. 무엇을 어떻게 바꿀것인가? (What to do change?) – 흐름을 막는 제약과 핵심문제를 찾음

-. 무엇으로 바꿀것인가? (What to change to?) – 전체 흐름량을 최대화

-. 어떻게 바꿀것인가? (How to cause the change?) – 핵심문제를 해결하고 제약흐름을 최대화

등과 같은 일련의 과정을 논리적으로 파악해 나감.

 

2. 6가지도구

-. CRT : Current Reality Tree (현재 상황나무)

-. Cloud (Core Conflict Cloud : 대립의 중심)

-. EC : Evaporating Cloud (갈등해소를 위한 해결책 주입)

-. FRT : Future Reality Tree (미래 상황나무)

-. PT : PreRequisite Tree (전제 조건나무)

-. TT : Transition Tree (실행 계획 나무)

* CRT (문제점 열거, 인과관계 파악, 문제점 도출) -> UDE : 바람직하지 않은 결과 (CRT에서의 문제점 들) -> Cloud (문제원인, 모순, 대립 해소하기 위한 수단) -> FRT (Cloud의 문제해결책의 검증) -> NB : 부정적 가지 (Cloud의 대립해소 아이디어 실행 시, 새롭게 발생하는 문제) -> PT (어떻게 바꿀것인가?에 대한 수단, 목표달성과정의 장애와 극복을 위한 중간목표 전개) -> TT (PT의 중간목표 달성을 위한 필요행동)

 

 

 

++ 참조자료 : Thinking Process Sample

 

 

 

 

'ITPE > SE' 카테고리의 다른 글

소프트웨어 테스팅 국제표준 - ISO 29119  (0) 2021.02.19
CMMI  (0) 2018.04.12
단위 테스트 및 통합테스트  (0) 2018.02.22

 

 

 

 

데이터베이스에서의 무결성..




데이터 무결성과 릴레이션 무결성으로 구분

 

[정의] 데이터를 인가되지 않은 방법으로 변경할 수 없도록 보호하는 성질. 

 

[분류] 데이터 무결성과 릴레이션 무결성으로 구분
1. 데이터 무결성
- 개체 무결성
- 참조 무결성 : [규칙] 입력규칙(자식): Dependant, Nullify, Default // 삭제규칙(부모): Restrict, Cascade, Nullify, Default
- 속성(도메인)무결성 : [규칙] Unique, Not null, check, 기본키, 외래키
- 사용자 정의 무결성
- 키 무결성

 

 

 


2. 릴레이션 무결성 : 릴레이션을 조작하는 과정에서 의미적 관계를 명세, 삽입/삭제/갱신과 같은 연산을 수행하기 전과 후에 대한 상태에 대한 정확성 보장
  - [제약유형]
   - 상태제약(parent.family_nm=child.family_nm) :데이터베이스가 일관성 있는 상태가 되기 위한 조건 명세.
   - 과도제약(emp.newsal > emp.oldsal) : 데이터베이스의 한 상태에서 다른 상태로 변환되는 과정에서 적용되는 규칙.
   - 집합제약(avg(emp.sal)>600) : 튜플집합 전체에 관련되어 적용되는 규칙
   - 튜플제약(updating emp.sal; sal>5000) : 처리되고 있는 튜플에만 적용되는 규칙
   - 즉시제약(updating emp.sex; sex='M' or sex='F') : 연산이 수행되는 즉시 적용되는 규칙
   - 지연제약(When commit : check((a+b) > 0)  : 트렌젝션완전히 수행후 적용되는 규칙


[릴레이션 무결성을 DB 구현하는 방법]
1) 무결성 제약조건 활용 : DBA가 DCL을 이용하여 무결성 제약조건을 명시적으로 기술
2) 트리거 활용 : 트리거는 DB가 특정 상태에 도달하면 자동으로 작동
3) 저장 프로시저 활용 : 저장 프로시저를 사용해 데이터에 대한 접근을 제어. (저장 프로시저는 SQL과 SPL 언어를 조합해 만든 프로시저)
4) 데이터베이스 응용프로그램 활용 : 데이터베이스의 응용프로그램 코드에 업무규칙을 강제로 시행.
5) DBMS기능 활용 : ACID 보장 위한 동시성 제어 기능, 회복/복구 기능, 보안기능 등.

 

 

 

 

 

'ITPE > DB' 카테고리의 다른 글

데이터 모델링  (0) 2021.03.06
ARIES (Algorithms for Recovery and Isolation Exploiting Semantics)  (0) 2021.03.06
MVCC (MultiVersion concurrency control)  (0) 2021.03.06
Timestamp Ordering  (0) 2021.03.06
낙관적 검증(Validation)  (0) 2021.03.06

 

 

출처 : http://www.hardcopyworld.com/gnuboard5/bbs/board.php?bo_table=lecture_rpi&wr_id=60

 

 

 

 

 

 

홈 오토메이션과 센서 네트웍 관련 자료들을 찾다보니 MQTT 프로토콜이 자주 등장하더군요. 좀 더 세부적으로 살펴보니 여러모로 유용한 것 같아 자료들을 정리해 봤습니다. 실제 테스트도 가능하도록 예제도 첨부했습니다.

MQTT(MQ Telemetry Transport)는 아두이노나 라즈베리파이 같은 임베디드 장치간 통신을 위한 가벼운 메시징 프로토콜입니다. TCP/IP 기반으로 대역폭이 작은 네트워크에서 동작할 수 있도록 설계된 프로토콜입니다. 쉽게 얘기해서 임베디드 장치들을 위한 트위터라고 볼 수 있습니다.

MQTT 자체는 메시지를 어떻게 보낼 것인지를 정의하는 규약일 뿐입니다. 따라서 실제 MQTT 트위터를 동작시키기 위해서는 서버 역할을 해주는 장치(프로그램)가 필요한데 이를 MQTT 브로커(Broker)라고 합니다. MQTT 브로커는 각종 장치들(MQTT Client)이 보내주는 메시지를 수집하고 이걸 다시 필요한 장치들에게 전송해주는 중계서버 역할을 합니다.

MQTT 클라이언트는 브로커에게 메시지를 전달하고 필요한 메시지를 받기만 하면 되고 MQTT 프로토콜의 구조도 간단하기 때문에 처리능력이 낮은 임베디드 장치에 잘 어울립니다. 메시지는 트위터처럼 140자 제한이 없으므로 긴 메시지나 JSON 포맷 또는 파일도 전송이 가능합니다. 이런 특징들 때문에 MQTT 프로토콜은 센서 네트웍을 구성하는데 유용한 도구로 관심을 받고 있습니다.

 

 

MQTT 동작 구조 (PUB/SUB)

 

트위터 서비스의 동작구조를 떠올려보세요. 트위터에서 사용자는 다른 사용자를 follow 할 수 있습니다. 그럼 다른 사용자가 생성하는 메시지(트윗)를 받아볼 수 있죠. 그리고 스스로 메시지를 생성할 수도 있습니다. 그럼 자신을 follow하는 사용자에게 메시지가 전달되죠.

MQTT도 거의 유사한 동작구조를 갖습니다. MQTT 시스템에 참여하는 MQTT 클라이언트는 메시지 발행(publish, 트윗에 해당), 메시지 구독(subscribe, follow에 해당) 두 가지 동작을 할 수 있습니다. MQTT 클라이언트가 메시지를 특정 채널(Topic, 토픽)에 발행하면 이 채널을 구독한 모든 클라이언트에게 메시지가 전달되는 겁니다. 중간에서 메시지를 수집, 재분해 하는 작업은 MQTT 브로커가 담당합니다.

 

0912embmqtt01

 

 

토픽

 

메시지를 발행/구독(pub/sub) 하는 행위는 채널 단위로 일어납니다. 이를 MQTT에서는 토픽(Topic)이라고 합니다. 토픽은 슬래시(/)로 구분된 계층구조를 갖습니다.

topic_basics

메시지를 구독/발행 할 때 여러개의 토픽을 한번에 지정할 수 있도록 wild card 문자를 지원합니다. [+] 문자는 단 1개의(1 레벨) 토픽을 임의의 토픽으로 대체하는 와일드카드 문자입니다.

topic_wildcard_plus

반면 [#] 문자는 여러 레벨의 토픽을 대체할 수 있습니다. [myhome/#] 처럼 사용하면 myhome 의 하위 토픽들 모두를 지칭하게 됩니다. [#] 문자는 토픽 문자열 끝에만 사용할 수 있으며 하위 토픽 모두를 지칭합니다. (2단계 이상 하위 토픽도 포함)

topic_wildcard_hash

[$] 문자로 시작하는 토픽은 시스템에 의해 사용되는 특수한 토픽을 의미합니다. 이 토픽들은 [#] 문자열로 지정해도 포함되지 않는 토픽이 됩니다. 주로 [$SYS/] 로 시작하는 토픽들이 브로커의 내부 메시지를 위해 사용됩니다. (이에 대한 명확한 표준은 없는 상태인듯)

토픽 구조를 구성할 때 몇 가지 주의할 점이 있습니다.

  • 최상위 토픽이 [/] 문자로 시작하지 않도록 합니다. [/home/sensor/humid] 이렇게 사용할 수는 있지만 최상위 토픽이 이름이 없는 토픽이 되므로 사용하지 않는 것을 권장합니다.
  • 토픽 이름에 공백을 사용하지 않습니다.
  • 토픽 이름은 ASCII 문자만 사용합니다. (임베디드 장치와의 호환성을 위해 주의)
  • [#] 를 이용해서 토픽 전체를 구독하지 않도록 합니다. 오버헤드가 심할 경우 브로커/클라이언트 프로세스가 중단될 수 있습니다.

 

 

QOS (QUALITY OF SERVICE)

 

MQTT는 시스템에 참여하는 장치들의 처리 능력, 네트워크 대역폭, 메시지 오버헤드 등 주변상황에 맞게 시스템이 동작할 수 있도록 3단계 QoS(Quality of Service) 를 제공합니다.

  • 0 : 메시지는 한번만 전달하며, 전달여부를 확인하지 않는다. Fire and Forget 타입이다.
  • 1 : 메시지는 반드시 한번 이상 전달된다. 하지만 메시지의 핸드셰이킹 과정을 엄밀하게 추적하지 않기 때문에, 중복전송될 수도 있다.
  • 2 : 메시지는 한번만 전달된다. 메시지의 핸드셰이킹 과정을 추적한다. 높은 품질을 보장하지만 성능의 희생이 따른다.

0에 가까울수록 메시지 처리에 대한 부하가 적은 대신 메시지 손실 위험이 높아집니다. 2에 가까울수록 메시지 손실 위험은 줄어들지만 메시지 처리 부하가 급격히 늘어납니다.

(보통 0~1 정도의 QoS를 사용하면서 메시지 손실등의 위험은 상위 어플리케이션 차원에서 관리하도록 하는듯 합니다.)

 

 

MQTT 브로커

 

MQTT 시스템의 핵심 서버 역할을 하며,  여기에 메시지가 수집되고 다시 재분배 됩니다. 다양한 MQTT 브로커 프로그램들이 개발되어 있는데 ActiveMQ, Apollo, IBM Message SightJoramMQMosquittoRabbitMQSolace Message Routers 등이 자주 사용됩니다. 아래 링크에 MQTT 브로커의 특징을 비교한 자료가 있습니다.

여기서는 Mosquitto 브로커를 사용할 것입니다. Mosquitto는 MQTT의 기본 기능을 충실히 지원하는 가벼운 MQTT 브로커 프로그램입니다. Mosquitto 클라이언트 프로그램도 있으므로 여러대의 PC를 이용해서 테스트를 할 수 있습니다.

mosquitto

 

 

MQTT 동작 테스트

 

홈 오토메이션이나 센서 네트워크를 구성하기에는 라즈베리파이같은 손바닥 PC가 제격입니다. 여기서는 MQTT 동작 테스트를 위해 PC와 라즈베리파이에 Mosquitto MQTT 클라이언트, 브로커를 설치할 것입니다.

라즈베리파이에 Mosquitto 브로커를 설치하는 작업부터 시작합니다. Mosquitto 는 apt-get 명령어를 통해 간단히 설치할 수도 있지만 업데이트가 되지 않는 문제점이 보고되고 있습니다. 아래 순서로 설치하길 권장합니다. (최신 소스코드를 다운로드 받아 설치하실땐 링크를 참고하세요.)

  • wget http://repo.mosquitto.org/debian/mosquitto-repo.gpg.key
  • sudo apt-key add mosquitto-repo.gpg.key
  • cd /etc/apt/sources.list.d/
  • sudo wget http://repo.mosquitto.org/debian/mosquitto-wheezy.list
  • sudo apt-get install mosquitto

설치가 완료되면 브로커는 1883 포트를 사용하게 됩니다.

 

이제 PC와 모바일 폰에 MQTT 클라이언트를 설치해서 연동을 해보겠습니다. PC(Windows, Linux, OS X)에서는 MQTT.fx 클라이언트를 설치하면 됩니다. 아래 링크에서 프로그램을 받을 수 있습니다.

MQTT.fx 클라이언트는 윈도우 64비트만 지원합니다. 이 문제 때문에 설치가 안된다면 크롬 브라우저의 확장 앱으로 설치해서 사용하는 방법도 있습니다. 크롬 브라우저에서 아래 링크를 통해 설치할 수 있습니다.

모바일 폰에서는 앱 스토어에서 MQTT로 검색하시면 됩니다. 다양한 클라이언트가 등록되어 있는데 대부분 비슷하므로 아무거나 사용하셔도 됩니다. 유명한 MQTT 클라이언트들은 링크에서 확인하실 수 있습니다.

 

설정 방법은 간단합니다. 아래 항목들만 정확히 설정해 주면 됩니다.

  • MQTT 브로커 URL : MQTT 브로커를 설치한 서버의 URL 입니다.
  • Port : 앞서 설치한 Mosquitto 브로커는 기본 1883 포트를 사용합니다.
  • Username / Password : 지금은 설정하지 않아도 됩니다.

테스트를 위해 클라이언트에서 subscribe 버튼을 누르고 토픽에 messagebox를 입력합니다. 그럼 messagebox 토픽이 생성되고 구독이 됩니다. PC, 모바일 등 모든 장치에서 같은 작업을 해줍니다.

이제 PC, 모바일에서 publish 를 합니다. 이때 토픽은 messagebox로 선택합니다. 그럼 입력한 메시지가 브로커로 전달되고 messagebox 토픽을 구독하는 다른 장치들에도 전달되어야 합니다. 제대로 동작하는지 확인해보세요.

 

MQTT 브로커를 설치한 라즈베리파이에 MQTT 클라이언트를 설치해서 확인할 수도 있습니다.

  • apt-get install mosquitto-clients

아래 명령으로 메시지 발행(pub)을 할 수 있습니다. 다른 기기에도 메시지가 보여야겠죠.

  • mosquitto_pub -d -t messagebox -m "sent from RPi server"

특정 토픽을 구독(sub) 할 수 있습니다. 이 경우 특정 토픽에 메시지가 도착 할 때마다 표시됩니다. Ctrl+c 를 눌러 멈추기 전까지는 메시지 표시하는 상태로 유지됩니다.

  • mosquitto_sub -d -t messagebox

 

 

MQTT - IOT 장치 만들기

 

앞선 MQTT 테스트는 단순한 메시지를 공유하는 일종의 채팅 예제였습니다. 여기서 메시지 내용만 원하는대로 바꿔서 사용하면 센서 네트웍, 홈 오토메이션에도 MQTT가 메시지 전송 프로토콜로 활용될 수 있음을 알 수 있습니다. 여기서는 IoT 장치를 직접 만들기 위해서 마이크로 컨트롤러에 MQTT를 이식하고 메시지를 전달하는 예제를 만들어 보겠습니다.

예제 장치를 만들기 위해 아래와 같은 모듈들이 필요합니다.

  • ESP8266 - NodeMCU (ESP12E 기반) 보드
  • DHT22 (온습도 측정용 센서)
  • I2C 128x64 OLED (옵션, 현재 상태와 송수신 메시지 표시용, 반드시 SSD1306 드라이버 칩을 사용한 모듈 필요)

esp8266_title

ESP8266 - NodeMCU (ESP12E 기반) 보드

가성비와 활용성 면에서 최고의 평가를 받는 ESP8266 WiFi 모듈을 마이크로 컨트롤러로 사용합니다. 여기서는 모듈에 올라갈 펌웨어 작성을 위해서 Sming 개발환경을 사용할 예정인데, ESP8266 Arduino IDE로 작성하는 것도 가능합니다.

먼저 모듈들을 연결을 해줘야겠죠. ESP8266과 DHT22은 아래 순서로 연결합니다.

  • ESP8266 --> DHT22
  • 3V --> VCC
  • GND --> GND
  • D5(GPIO14) --> DAT

ESP8266 에 OLED 디스플레이도 연결합니다.

  • ESP8266 --> OLED
  • 3V --> VCC
  • GND --> GND
  • D3(GPIO0) --> SCL
  • D4(GPIO2) --> SDA

 

모듈 연결이 끝나면 ESP8266에 올라갈 펌웨어를 만들어야 합니다. Eclipse 기반 Sming 개발환경을 구축하면 MQTT client 예제 파일도 같이 설치됩니다. 이걸 수정해서 DHT22 센서로 온습도를 측정하고 MQTT broker로 전송하도록 만들었습니다. 아래 링크에서 소스코드를 구하실 수 있습니다.

소스에서 몇 가지를 수정해줘야 합니다. 공유기 ID(SSID)와 PASSWORD, 센서값을 전송할 간격, 토픽의 이름(여기서는 messagebox  토픽 사용) 입니다.

...... #ifndef WIFI_SSID 	#define WIFI_SSID "your_ssid" // Put you SSID and Password here 	#define WIFI_PWD "your_password" #endif ...... MqttClient mqtt("your_mqtt_server.com", 1883, onMessageReceived); ...... 	mqtt.publish("your_topic", message); // or publishWithQoS ...... 	mqtt.subscribe("your_topic"); ......

 

소스가 수정되면 컴파일을 하고, 생성된 펌웨어를 MSP8266 모듈에 올려 구동하면 정해진 시간 간격마다 MQTT 메시지를 전송합니다. PC, Mobile 폰에서 messagebox 토픽에 해당 메시지가 들어오는지 확인하면 되겠죠.

그리고 반대로 PC, Mobile 폰에서 messagebox 토픽에 메시지를 생성(publish)하면 ESP8266 모듈의 디스플레이에 표시되어야 합니다.

mqtt_exam

메시지가 정상적으로 표시된다면 기본적인 수준의 IoT 장치가 완성된 것입니다!! 이걸 응용하면 IoT 장치를 인터넷 서비스와 연동하는데 사용할 수 있습니다.

 

 

 

 

HOME-ASSISTANT 홈 오토메이션 서버와 연동

 

MQTT 프로토콜은 단순히 메시지/데이터를 전송하는데 사용되는 규약일 뿐입니다. 대신 MQTT broker/client, 라이브러리를 통해 송수신된 데이터를 처리하는 도구를 풍부하게 제공합니다. MQTT로 전송하는 메시지가 무엇인가는 전혀 관여하지 않습니다. 전송되는 데이터 자체를 어떻게 처리할 것인가는 서비스 개발자의 몫입니다.

따라서 센서 네트웍, 홈 오토메이션에 MQTT 를 사용하더라도 전달되는 데이터를 어떤 형식으로 보낼 것인지는 직접 정의해야 합니다. 이런 작업을 직접 다 하기에는 고려해야 할 점도 많고 구현도 힘들기 때문에 오픈소스로 표준화/공개된 솔루션을 사용할 수 있습니다. 여기서는 Home-assistant 라는 홈 오토메이션 솔루션을 이용해 우리가 만든 IoT 장치를 연동해 보도록 하겠습니다.

홈 어시스턴트 서버를 설치하고 설정하는 방법은 아래 링크에서 다루고 있습니다.

 

앞서 ESP8266 보드로 만든 장치를 다시 이용하도록 하겠습니다. 대신 소스코드에 약간의 수정이 필요합니다.

void publishMessage() { 	...... 	// Make JSON data 	String message = "{\"temp\":"; 	message += th.temp; 	message += ", \"humi\":"; 	message += th.humid; 	message += "}";  	// publish message 	Serial.println("Let's publish message now!"); 	mqtt.publish("home/thirdroom/temp_humi", message, true); // retained message 	...... }

앞서와 다른 점은 데이터를 보낼 때 JSON 형식으로 보낸다는 겁니다. 예를 들어 온도 23.11', 습도 68.35%를 보낼 때 아래처럼 보냅니다.

{"temp": 23.11, "humi": 68.35}

그리고 이 데이터는 [home/thirdroom/temp_humi] 토픽으로 전송합니다. 마지막에 true 파라미터가 붙은건 마지막 데이터를 저장했다가 새로 구독(subscribe)하는 기기가 있으면 보내주기 위한 retained message 기능입니다.

홈 어시스턴트 서버에서는 [home/thirdroom/temp_humi] 토픽을 구독하면서 새로운 업데이트가 생겼을 때 JSON 데이터를 파싱하면 됩니다. 홈 어시스턴트 설정파일인 [configuration.yaml] 파일에서 아래와 같이 설정해주면 됩니다.

sensor 3:   platform: mqtt   state_topic: "home/thirdroom/temp_humi"   name: "Thirdroom Humidity"   qos: 0   unit_of_measurement: "%"   value_template: '{{ value_json.humi }}'  sensor 4:   platform: mqtt   state_topic: "home/thirdroom/temp_humi"   name: "Thirdroom Temperature"   qos: 0   unit_of_measurement: "°C"   value_template: '{{ value_json.temp }}'

[home/thirdroom/temp_humi] 토픽을 구독하면서 데이터가 도착하면 humi, temp 변수를 찾아 그 안에 할당된 값을 추출합니다. 정상적으로 동작하면 홈 어시스턴트 웹 페이지에서 아래처럼 보이게 됩니다.

ha_mqtt_device

 

 

OPENHAB 홈 오토메이션 서버와 연동

 

openHAB 도 홈 어시스턴트와 같은 컨셉을 가진 홈 오토메이션 서버입니다. 아래에 설명하는 과정은 openHAB 홈 오토메이션 서버에 MQTT 브로커를 연동해서 센서값을 보여주는 방법입니다. 여기서는 이미 openHAB이 설치된 리눅스 서버가 있다는 가정하에 진행하겠습니다. 라즈베리파이에 openHAB 서버 설치는 링크의 내용을 참고하세요.

 

openHAB 서버가 MQTT 브로커와 연결되기 위해서는 전용 add-on 을 설치해야 합니다.

  • sudo apt-get install openhab-addon-binding-mqtt
  • sudo chown -R openhab:openhab /usr/share/openhab

openHAB 설정 파일을 수정해줍니다.

  • sudo nano /usr/share/openhab/configurations/openhab.cfg

아래 내용을 추가

mqtt:broker.url=tcp://localhost:1883 mqtt:broker.clientId=openhab

openHAB 재실행

  • sudo service openhab restart

 

MQTT 로 들어온 메시지가 연결될 Number item 추가 작업

(이하 내용 작성 중...)

참고 링크

 

 

 

 

참고자료

아두이노와 Ethernet 모듈을 이용한 센서 장치 만들기

 

 

 

'ITPE > NW' 카테고리의 다른 글

NDN  (0) 2018.02.26

+ Recent posts