아무거나 시도해보는 개발일지

오브젝트는 클래스의 인스턴스들
개별 Attributes 값을 지니고 있지만, Operation 은 따로 표시 안함 ( 클래스별로 동일한 Operation을 갖고있기 떄문 )

ㅁ 표기법
+ : Public
- : Private ( 표시없으면 Default가 private )
# : Protected
~ : Package
/ : 내부적으로 계산해서 나오는 값
_ : Class variable,operation (인스턴스가 아닌 클래스단위로 공유)

Operation과 Method의 차이
Operation : Body가 없는 내부적 구현이 작성되지 않은 선언문
Method : 구현된 코드

OO 개념에서 attribute는 숨겨져있기 때문에 접근하기 위한 Getter,setter를 보통 사용한다
(기본적으로 갖고있고, 변수별로 생기기때문에 UML tool에서 숨김기능 대부분 제공 )

5 Type of Class Relationship

Dependency : 다른 오브젝트와 잠깐 일하고 다시는 연결될일 없는 관계 ( 주로 컴포넌트 다이어그램 )
Association(Default) : 일정시간동안 다른 오브젝트와 협업하는 관계
Shared Aggreation(강화버전1) : 다른 클래스의 오브젝트를 참조(공유)하는 관계
Composition(강화버전2) : 다른 클래스의 오브젝트를 포함하는 관계
Inheirtance: 다른 클래스의 상속일 경우

ㅁ Association 읽는법

1) 다대다 관리
2) 강의를 하고
3) lecturer 롤이 보인다. ( navigability ) 학생은 강사의 Public attribute,Opertation 접근 가능. 강사는 학생의 볼수있는게 없음
보통 실선은 양쪽화살표의 의미

※ Association class
클래스와 클래스 간의 관계에 대한 설명
. 어느쪽에 두기도 애매한 attribute에 대해 담아둠
. N:M 관계에서만 적용

Singletone class
인스턴스가 1개뿐인 클래스. 좋은 설계는 아님
singletone design pattern : 생성되는 순간을 관측하기위한 모니터링 시스템 필요

Active class
Thread가 되는 클래스 ( 메인 프로세스와 독립적으로 리소스를 갖고 움직임 )

Interface
다양한 방법으로 interface implementation 표현 가능. ( interface realization )
1) Socket + lollipop notation (주로 컴포넌트)
2) Depoendency line notation (주로 컴포넌트)
3) Interface implementation

Aggregation
클래스가 다른 클래스를 포함하는 경우. (참조냐 소유냐의 따른 type으로 나뉨)

1) Shared Aggregation (weak)
빈 마름모로 표현하며, 참조의 경우. 삭제해도 참조 오브젝트가 지워지지 않음
2) Composition (strong)
채운 마름모로 표현하며, 삭제 시 연관된 모든 오브젝트가 삭제됨

Inheirtance(Generalization)
Public한 특징들만 내려감. attribute/Operation 만 내려가는게 아니라, 다른 클래스들과의 관계도 모두 상속된다
. 자바에서는 다중상속이 불가하다. (C++ 에서는 가능)
※ abstract class : 본인은 new로 인스턴스를 만들지 않고, 상속받은 클래스가 오브젝트를 만들도록 하는 껍데기 클래스

실습

ㅁ BP와 비교해서 고민할 점

1) 추후 구체화 단계에서는 속성/오퍼레이션에 타입값 작성과 클래스간 관계 표시

2) 합성을 이용하여, 주문쪽에 결제의 인스턴스를 선언하고 처리하는 방식에 대해 고려

<BP>

Sequence Diagram

동적으로 객체간의 상호작용을 시간 흐름에 따른 메세지 구조로 표현

. 보통 단일 유스케이스 분석에 사용

Seqence 읽는법
0) doX로 들어오는 System operation
1) doA,B,C 를 호출/리턴 하고 이에 대한 Body는 Sale에 있다

구성요소

1) 오브젝트/수명주기

2) 메세지

3가지 메세지 타입 1) Sync : 리턴값을 받을때까지 대기 (쓰레드를 제외한 모든 프로세스) 2) Async : 리턴과 관계없이 진행 (쓰레드) 3) Ack(Response) : Request에 대한 응답 + Found : System operation (시작) + Lost : Output (끝) + Time-consuming : 기본적으로 메세지는 실시간. 시간이 필요한 메세지 표현 Creation(NEW), Destroy도 가능 생성자가 위에있고, 인스턴스가 아래에 있어야한다. 점선으로 표시하고, 인스턴스 정중앙을 향함

3) Gaurd (조건문)

4) Fragment (제어문 표현)

Robustness(ECB Pattern) Analysis

유스케이스로부터 3종류의 분석 클래스 추출

1) Boundary class : View에 해당하며, 시스템과 외부 액터의 상호작용

2) Control class : Controller에 해당하며, 비지니스/제어 로직 담당

3) Entity class : Model에 해당하며, 데이터관리를 담당

※ 지양되는 케이스

엑터가 뷰를 거치지 않고 컨트롤러나 엔티티 접근
뷰가 뷰를 호출하고, 엔티티 접근하는 케이스 ( 뷰는 in/out만 담당한다. )
모델과 모델간 직접적으로 데이터 변경

실습 

웹 사이트 로그인과정을 ECB Pattern 으로 그려보기.

ㅁ BP 참고하여 보완할 점.

1) 각 분석 클래스 네이밍 지정

2) Request 메세지에는 요청이라는 표현을 쓸 필요가 없을듯 ( Response 도 마찬가지 )

3) 1.5의 실행결과를 굳이 웹사이트 안거치고 한번에 보내도 이해가 가능할듯 

4) 요구사항에 휴면 계정인 경우 활성화 로직에 대한 내용이 있었으나,

    나는 고객에 활성화 요청을 보냈다. 의도만 파악해서 시스템에서 작업했어야 할 내용

<BP>

UML

시스템 전체 구조, 각 컴포넌트들의 관계를 시각적으로 표현 

다양한 뷰로 표현 가능한데, 이는 고객/개발자/아키/디자이너 등 다양한 관점에서 바라보기 위함

구현을 위한 코드레벨에서의 도구라기보다는, 다른 관점을 지닌 사람들과 의사소통을 위한 시각적 도구 정도로 인식

-> UML Fever : UML 사용 시 부작용에 대한 내용. 대표적으로는 상세하게 기술한 거대한 UML 모델

View

1) 3 View : Model(정적) / Component(Runtme,시스템 아키)

                  Allocation (실제 시스템이 배치되었을때 운영환경, 디플로이 등 )

2) 4+1 View : 

각 사용자 별로 시스템을 바라보는 관점 

Logical : 엔드 유저

Process : 시스템 통합

Physical : 시스템 엔지니어

Development : 프로그래머

1) Use Case Model

사용자와 시스템 간의 상호작용을 표현

시스템의 기능적 요구사항을 획득하는 과정.

단순히 구현 기능 리스트를 만들기 보다는, 시스템을 이해하는 과정으로써 집중

※ 지금 공부는 구현단계가 아닌, 아키텍쳐 입장에서 설계서 작성이 목적으로 하자. ( 품질속성과 연관있는 유스케이스 )

크게 사용자인 엑터, 시나리오인 유스케이스(시스템이 제공하는 기능) 항목으로 이루어져 있으며,

사용자와 시스템 간의 상호작용을 그려준다.

. 표기법

<<include>> 는 선행관계가 아님.

ex: 쇼핑몰 리뷰를 남길 때, 상품 구매가 선행되어야하지만 이는 include가 아닌 precondition.

      리뷰 과정에, 구매가 포함되어있지 않기 떄문. 

      대출심사 과정에는 , 심사에 필요한 서류 제출이 포함되어있기때문에 include 사용가능.

. 예시

실습

1) 특정 주제에 대해 엑터와 유스케이스 간단하게 작성하기

  + 도출된 유스케이스를 다이어그램으로 표현하기

2) 렌트카 예약 시스템 그려보기 + 유스케이스 1개 잡고 Description.

. 피드백

  사고 접수와, 보험사의 보험처리간 연계가 될 수 있는 유스케이스 추가 필요

  Description 에서 사후조건으로 고객은 예약메세지를 받는데, 외부시스템으로 sms/카카오톡 등의 연계가 있었으면

BP

절차지향 프로그래밍 

- 문제해결 흐름을 따라 ( 로직,알고리즘 ) 코드를 구성하고 구현. 대표적으로 C언어

OOP (Object Oriented Programming)

- 현실 세계에 존재하는 객체를 기반으로 객체 간의 관계를 통한 프로세스 진행

- 대표적으로 1. 캡슐화  2.상속  3.다형성의 특징을 지닌다.

1) 캡슐화

데이터와 연산과정을 내부에 숨기고, 필요한 인터페이스만 외부에 노출하여 사용하게 함

2) 상속

클래스의 상-하 관계 ( Is-a )

상속을 통해 속성과 기능이 자식에게 전달된다. 자식으로 갈수록 구체적이다.

-> 재활용이 가능하지만, 코드 재활용을 위한 상속은 X. 또한 구체 클래스의 상속도 X

-> Is-a 관계가 명확할때만 사용 

※ 상속보다는 합성(has-a)을 권장

합성 - 다른 클래스의 기능이 필요시, 내 클래스에 인스턴스 변수로 선언하고 기능을 사용하는 것.

3) 다형성

동일 요청에 대한 다른 반응

- 상속과 오버라이딩을 통한 구현

객체 모델링

객체를 구조화 하는 작업. 필요한 클래스들을 추상적으로 정의한다.

정적 모델 : 객체가 가질 수 있는 모든 상태와 행동을 시간 독립적으로 모델링

동적 모델 : 객체의 라이프 사이클 동안의 변화

추상화

실 세계의 모든것을 표현하기엔 어려우니, 특정 부분을 추출해서 표현

실습

객체 모델링 - 현실 세계에서 객체 선정, 속성과 기능 정의 ( 다형성 포함 )

다형성/상속/합성 관련 

주어진 클래스 다이어그램 참조하여 코드 구현

++ 추가로 공부할 것

List 자료구조 및 객체간 주고받는 상황 구현

json Library 

rest api 호출

이번 포스팅에서는 Git Push 트리거 발생 시, 자동 이관을 위한 Git 및 Jenkins 세팅이다.

1) Git 토큰 발급

ㅁ GitHub - Setting - Devleoper setting - Personal access tokens 에서 접속을 위한 토큰 생성을 한다.

ㅁ Token의 권한 설정

잘 모르면 Full로 주어, 기능 테스트를 하는게 맞으나

필요한 권한만 부여해보고 각 기능에 어떤 권한이 필요한지 확인해보자.

저장소에 접근하기 위한 repo 권한과

Push 발생 시, Web hooking을 위한 admin:repo_hook 권한을 주어봤다.

2. Jenkins 연동

시스템 설정 - Git Hub 추가 

Kind : Secret text - text 형식으로 토큰 값 입력하겠다.

Secret : Git hub에서 발급받은 토큰 입력

ID: 내부 식별용도

해당 정보로 연동 테스트

ㅁ Item 생성

Free style Project 생성 - Git Hub Projcet 생성 후 , 본인의 Git 주소 입력

소스 관리 - git 경로 입력 및 위에서 등록했던 Credentials 입력

* 에러발생

Couldn't find any revision to build

디렉토리 구조 없이 read.me 파일만 있어서 그런건가?

-> branch 설정 시, 기본 값인 */master를 사용하였으나

    GIt Hub에 들어가보면 main branch를 사용중이다.

빌드 성공

ㅁ Local 에서 빌드 연동 확인

CI 툴중 하나인 Jenkins 설치 및 학습을 진행하려 한다.

Docker를 사용하여 각 호스트를 분리하고, 구성하면서 흐름에 대해 알아보자.

예상되는 시나리오는

1) 개발서버 컨테이너에서 코드 작성후 Git Push

2) 해당 Push를 트리거로 Webhook을 통해 젠킨스 컨테이너로 가져옴

3) 해당 내용 운영서버 컨테이너에 반영

간단하게 도커, 깃헙, 젠킨스 연동하는 아키텍처를 구성해보았으며

추후 유닛, 품질테스트 및 Slack을 통한 Notification 단계까지 구현할 예정이다. + 분산 빌드 환경 구축

1. Docker 설치

ㅁ 참조

2021.06.30 - [IT/도커도커] - (1) Ubuntu에 도커 설치하기

※ WSL 에서는 systemctl 명령어로 수행 시, 에러 발생

/etc/init.d로 수행해 주어야한다.

sudo /etc/init.d/docker start
sudo /etc/init.d/docker status

2. Jenkins 를 실행시킬 jenkins_admin 서버 구동

docker run -it -d --name jenkins -p 8080:8080 jenkins

run : 이미지 pull 및 실행

it : 터미널의 입력을 docker로 전달

d : 백그라운드 수행

name : 컨테이너에 이름 부여

p : {port1}:{port2}. 부모 서버의 port1로 오는 요청을, 컨테이너 port2로 포워딩

ㅁ 에러발생

도커 데몬 수행을 위해 /var/run/docker.sock 에 접근했으나 실패한 것으로 보임.

1) Root로 수행하던가

2) 같은 그룹에 넣어주자.

sudo usermod -g docker stadm

ㅁ 에러발생2

이미지를 찾지 못한 것 같다. 

docker hub에 들어가, jenkins 공식 이미지를 찾아보니 링크가 걸려있었다.

jenkins/jenkins 로 이미지를 다운받자.

docker run -it -d --name jenkins -p 8080:8080 jenkins/jenkins

구동 확인

3. jenkins 설정

ㅁ 설치 확인 후, localhost 8080 포트로 들어가보자

도커를 구동할때 8080 포트 포워딩을 해놓아서, 컨테이너의 8080포트를 호출한다.

1) 초기 패스워드 설정

OS 에서 해당 위치의 초기패스워드를 확인해, 웹상에 입력해준다.

docker exec jenkins cat /var/jenkins_home/secrets/initialAdminPassword

2) 초기 플러그인 설치

3) 설치 완료 및 어드민 계정 생성

4) 설치 및 세팅 완료

- 계기 

인터넷을 돌아다니다 WEB 3.0에 대한 설명을 보게되었다.

기존 Front end - Back end - DB 로 대표되는 WEB 2.0 에서

변화된 아키텍처라 생각하고 들여다 봤지만, 많이 달랐다.

기존 구글, 페이스북 등 플랫폼을 제공하고

정보가 중앙으로 모이던 WEB 2.0과 비교하여

암호화 기반의, 개인화된 인터넷 환경을 제공하는

탈 중앙화, 블록체인, NFT 등의 개념적인 차이에 가까운 것 같다.

기술적으로도 많은 변화가 있지만

WEB 3.0에서 제시하는 키워드 들과 생각의 전환쪽에 더 꽂혔고

의식의 흐름을 따라가다보니 메타버스에 가장 관심이 가서 좀더 찾아보게 되었다.

기술적 부분이나, 다른 키워드 들에 대해서는 나중에 찾아보고

메타버스의 개념적인 부분에 대해 작성해보고자 한다.

각설하고, 내가 생각하는 메타버스의 충족요건은 가상 공간(온라인), 몰입성 + 추가적인 상호작용 이라고 생각된다.

대표적으로 언급되고 있는 메타버스 사례에 대해 살펴보자

이런 사례를 들었을 때, 흔히들 이렇게 말한다.

Zoom을 통한 화상회의 및 심즈 게임이랑 뭐가 다른데?

물론 맞는말이다. 위의 메타버스 사례들을 가지고 왔지만, 아직 온라인과 메타버스 경계에 있는수준으로 생각된다.

'나'를 대상으로 캐릭터화 하여, 이를 온라인에 구현시켜놓은 정도이다. 

ㅁ Meta(가상,초월) + Universe(세계,우주) = 메타버스

가상, 초월을 의미하는 메타(Meta)는 충족되었지만

아직 독립된 세계,우주(유니버스)로 인정을 받지는 못한 경우라고 보여진다.

이 경우에는 몰입성이 부족하다고 여겨진다.

그 캐릭터와 나를 일치화 하여 해당 세계에서 활동한다기 보다는

제 3자의 시선으로 밖에서 관찰하고 움직일 뿐이다.

내 실체와 가상공간의 행동 사이에 연결해주는 매개체의 부재?

- 가상융합기술(XR) 및 디바이스 (오큘러스) 등 기술적 한계

- 실제 현실과 연결되는 통로

- 사람들의 인식이 이를 받아들이기에 너무 빠른 시기일수도 있다.

=> 해결된다면... 레디 플레이어 원?

그 캐릭터는 내가 아닌데, 어떻게 존재를 인정해?

부캐 문화를 말하고 싶다.

놀면뭐하니의 유재석은 부캐 '유산슬'을 통해 4억이 넘는 수익을 창출했다.

엄밀하게 말하면 유산슬은 존재하지 않는다.

하지만 우리는 캐릭터의 존재를 인정하고 가치를 지불하였다.

이것을 온라인으로 옮겨 유튜브만 보더라도

버츄얼 유튜버로 가치를 증명하는 사람들도 많다.

연예인, 방송인에 대해서 국한되는 얘기는 아니다.

메타버스에서 생성된 내 캐릭터는 존재나 가치가 없을까?

현실속 나와 다른점을 활용해

충분히 가치를 창출할 수 있다고 생각한다.

나를 온라인에 그대로 가져다 놓은게 아닌, 또 다른 나의 탄생이다.

가상 세계도 인정하고, 내 캐릭터 존재도 인정하는데... 그 이후엔?

가상 세계라는 공간과, 그 안에서 활동하는 캐릭터를 인정한다면 가치는 기하급수적으로 올라간다.

물리적 제약없이 나라는 캐릭터가 몇 십, 몇 백개로 늘어나며 발생하는 거대한 상호작용과

다양한 특징을 가진 캐릭터 사이에서 발생하는 가치 창출은 예측하기 힘들 정도이다.

인터넷을 넘어 새로운 연결형태를 제공하고, 볼수없던 커뮤니티 구축 방식은

온라인 세계에서의 현실 구현이 아닌 또다른 세계의 창조라고 볼 수 있다. 

ex) 현실세계와 메타버스 - 로블록스에서 나이키 신발 출시

     메타버스 내에서 상호작용 - VR 채팅 캐릭터들끼리 모여 아이돌 구성 및 음반 발매

    -> 아직 메타버스가 정착되었다고 보긴 어렵고,
        앞으로 이런 종류의 상호작용까지 일어날 수 있겟구나~ 정도로 볼 것

코로나 특수로 오프라인의 제약이 생겨, 메타버스가 생각보다 빠른 관심을 받았다고 생각한다.

다만 메타버스는, 몰입성 있는 온라인 '플랫폼' 이상의 가치가 있다고 생각한다.

또 하나의 독립된 세계라는 점과

그 안에서만 일어날 수 있는 특수한 상호작용의 가치를 인정하는 순간

메타버스는 가속화 될 것이다.

오프라인에서 충족해주지 못하는 물리적 한계를 깨며, 온라인이 가치를 인정받았다면

메타버스는 그 안에서만 발생하는 커뮤니케이션과 가치창출을 통해 존재 이유를 말해야 할 것이다.

그리고 사실 이 글에서 말하고자 하고, 내가 인사이트를 얻은 부분은

메타버스를 인정 하니, 마니에 대한 얘기는 아니다.

과거 가상화폐만 하더라도, 튤립 사태를 비교하며 부정적인 시각이 대부분이었다.

더 과거로 돌아가면, 게임 아이템에 몇 십, 몇 백만원씩 지르는걸 욕하던 사람들도 많았다.

1과 0으로 이루어진 데이터 쪼가리로 보는 시각에서, 가치의 가능성을 보는 사람들이 점점 늘어나고 있다.

그 기술의 옳고 그름에 대한 판단보다, 시대의 인식 변화를 느끼고 열린 마인드로 보려고 노력중이다.

더 이상 가치가 실물에만 치중된 세상이 아니고

보이지 않는 이념이나 의미있는 것에 대한, 부가가치를 바라보는쪽으로 흘러가고 있다고 생각된다.

여태까지 구성된 아키텍쳐를 다시 살펴보자.

1) 유저가 WEB 서버 (Public IP)로 리퀘스트를 요청하면

2) 인터넷 게이트웨이가 이를 받아, 네트워크 주소 변환을 하여 VPC 내의 라우터로 전달한다.

- ex) 유저가 3.14.14.14 (Public IP)로 요청하면

      인터넷 게이트웨이가 이를 받아 10.0.0.82 (VPC 內 private IP)로 변환하여 라우터 전달

3) 라우터는 라우팅 테이블을 참조하여, VPC 안에서 목적지를 찾는다.

4) 10.0.0.82는 Public 서브넷 대역으로, 해당 망에서 목적지와 연결한다.

5) Nginx가 (10.0.0.82:80) 수신하고, Reverse Proxy 설정에 따라 10.0.0.190:82로 리퀘스트를 전달한다.

6) 라우터는 테이블을 참조하여, Python API Server로 연결한다.

7) 리퀘스트에는 IP:Port 말고 뒤에 /api/1234 라는 리퀘스트 Path 및 파라미터가 있었다.

   /api 로 수신하는 파이썬 서버가 이를 받아들인다.

   내부 로직에 따라 DB에 접속해서, Key 값이 1234인 데이터를 뽑아온다.

8) Name 값으로 kim을 받아 그대로 회신한다.

ㅁ WEB - WAS 연결 테스트

위의 Pyhton 코드는 Private Subnet에서 올라가있어, 직접 테스트가 불가능하다.

Public Subnet에 떠있는 Web서버를 통해 서비스 테스트를 해보자.

- WEB서버 Nginx port forwarding 설정

/etc/nginx/conf.d/default.conf 

server {
 listen 80; // 80포트로 리슨하고
 
 location /api/ { //api 리퀘스트 요청이 온다면
 proxy_pass http://10.0.0.190:82; // private WAS서버로 포워딩
 }
}

nginx 재시작

sudo service nginx restart 

ㅁ 연결테스트

- Nginx로 80 RestApi 호출 - 404 Error

- Nginx에는 Access Log 확인됌

Python에는 로그가 발견되지 않아

Nginx의 포트 포워딩 기능에 문제가 있다고 예상됌

에러로그에는 따로 남지않아, 포워딩 기능 재확인 필요.

- Default 링크 제거

스택 오버플로우를 참조하여 , /etc/nginx/site-enabled 의 default 링크 삭제.

포트포워딩 기능 정상 확인.

ㅁ WAS - DB 연결테스트

- Python <-> Postgresql 연동 라이브러리 설치  ( psycopg2 )

sudo pip3 install psycopg2

- 에러 발생

Error: pg_config executable not found.
=> Postgresql 관련 라이브러리가 설치되어 있지 않아서 그렇다고함.

libpq라는 Postgresql 프로그래밍 인터페이스 라이브러리 설치

sudo apt-get install libpq-dev

- Python 코드 수정

기존 Restapi 코드에서, 데이터를 Postgresql에 붙어서 가져오도록 수정

import psycopg2

user_db = psycopg2.connect (
  host='10.0.0.198',
  dbname='USER',
  user='test',
  password='a123456789',
  port=5432
)

@api.route('/api/users/<int:id>')
class HelloWorld(Resource):
 def get(self,id):
    cursor = user_db.cursor()
    sql = " select * from user_info where id= " + str(id)
    cursor.execute(sql)
    data=cursor.fetchall()
    return {"id": data[0][0],
              "name": data[0][1]}

- Key 값으로 1234 주었을 때

- Key 값으로 123 주었을 때

※ 비용 관리

원하는 아키텍쳐를 구성해보았으니, 할당받은 자원에 대해 정리도 중요하다

콘솔에서 현재까지 청구 금액을 살펴보자

현재까지 6$ 가량 나왔고, 대부분이 NAT Gateway라는것을 알 수 있다.

서버 구성이 완료되어, Private WAS / DB 에서는 외부 인터넷 연결이 필요없다.

학습도 완료하였으니 추가적인 과금을 방지하기 위해 NAT 게이트웨이를 삭제하도록 하자.