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

ㅁ System의 Dynamic함을 표현. System/Method의 action flow를 보여준다

Activity와 Transition으로 이루어져있다.
. State가 아닌 action. ( 어떤일을 한다 )

Transition은 trigger,event가 없다. Activity가 끝나면 넘어간다.

Branching(Decision Point) : 마름모로 표시되며 조건에 따른 분기점

점선과 네모칸으로 오브젝트 수준에서 State도 표현할 수 있다.

Swimlanes : 선을 그어, Actitvity 수행 주체를 표현할 수 있다.

Statechart Diagram과 유사한데, State의 변화과정속에 action이 들어온 것인지 / action이 메인인지에 따라 다르다..

실습

ㅁ BP 참고해서 고려할점

1) 재고조회에서 재고가 소진되었을 시, 입고요청 후 종료하는 방법도 있으나

    입고가 완료되면 다시 분기점으로 돌아가 진행 가능

2) 카드와 재고 관련해서 분기되었던 것들이, 주문진행에서 합쳐지고 바로 다시 갈라졌다.

    쭉 병렬로 진행 하여 카드유효 -> 카드결제로, 재고있음 -> 상품배송으로 바로 이어져야 할듯.

3) 주문 취소나, 완료 후 고객에게 통보해주는걸 상담원에게 롤을 주었다.

    -> 실시간으로 상담원이 시스템에 접속하고, 고객과 소통하는 상황을 그림

    하지만, 상담원은 전화상담 정도만 진행하고 시스템에서 고객에게 직접 통보주는 그림도 고려

4) 각 분기별로 종료를 만들었는데, BP처럼 종료케이스가 한 점으로 모이는게 깔끔할듯

<BP>

FSM(Finitie State Machine)에 몇 가지 특성이 더해진 Diagram.

1) Composite State

2) Orthogonal State

3) History State

가 추가된 FSM을 state chart formularism 혹은 StateChart Diagram이라고 한다.

상태를 나타내는 State와 State 변화들이 수행되는 Transition으로 이루어져있다.

노드의 상태를 나타내는 State는

들어올 때의 Enrty, 현재상태에서 작업을 수행하는 Do, 다른 State로 전환될 때의 Exit 으로 구성되어있고

State 조건에 따라 Initial, Final, Terminate 등으로 표현될 수 있다.

Transition는 번호가 새겨진 event, 조건인 condition(guard), 수행문인 action으로 구성되어있다.

※ 예시

1) initial state를 따라 S1 state가 Active 되고

2) entry에 따라 x=4 값으로 결정된다

3) event가 발생하고 x==4 조건이 맞아 true 로 변경된다.

4) S1에서 나가면서 exit에 의해 x=5가 되고

5) transition 이 true이므로 action에 의해 x=10이 된다.

6) S2가 Active되고 entry에 의해 x=11이 된다.

1) Composite state ( → OR State )

다른 state를 내부적으로 포함할 수 있다. ( substate )

순간마다 substate를 포함하여, 하나의 State만 Active 될 수 있다.

2) Orthogonal state ( → AND State )

region 별로 state가 Active 될 수 있다.

※ Submachine State (SMS) : 다른 state machine diagram을 축약해서 참조형으로 표시

3) History State

마지막으로 active된 state를 기억해서 수헹.

. shallow state : 마지막 state와 동일 레벨에서 다시 수행. 보통 해당 레벨의 initial에서 수행된다.

. Deep history state : 마지막 state에서 다시 수행. ( 좀더 강력 )

※ H,H*에 선이 있는것은 last state가 없을 때의 진행방향을 위함

오브젝트는 클래스의 인스턴스들
개별 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) 설치 및 세팅 완료