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

샤워를 하다 문득 생각이 꼬리를 물듯하는 내용과 전개방식

계속 깊게 생각하게 된다.

읽기전

일단 집게되는 자극적인 내용

특별히 읽을 책을 정해놓지 않고, 서점이나 도서관을 돌아다니다보면

표지나 제목이 특이한 책들에 눈이가기 마련이다. 이 책이 그러하였다.

주변에서 많이 결혼하는 시기이기도 하고

그렇지 않더라도, 만나면 한번씩은 꼭 나오는 주제인 나이대로서 자연스레 집게되었다.

무엇인가 흐름에 쫓겨, 남들 다 하는대로 따라가기 보다는

한번쯤 생각을 정리할 필요가 있지 않을까? 하는 생각도 있었다.

읽으면서

결혼은 본능과 감정에 의한것이 아닌 이성적 제도인가

다들 결혼을 어떻게 하는지에 집중하고 있지만, 왜 해야하는지 근본적인 이유에 대해서는 고민하지 않는 것을 화두로 던진다.

 . 결혼 상대, 조건, 결혼 시기, 돈, 신혼 집, 미래 계획 등등

나 조차도 어렸을때부터 막연하게, 시기가 되었으니 자연스레 생각하게 되었지 근본적으로 고찰하진 않앗던 것 같다.

작가는 역사를 통해 결혼의 현재와 미래를 파악하려 했고, 그 흐름을 따라가보자.

태초부터 지금까지 인간의 유전자는 아직까지도 침팬지와 매우 유사했다.

침팬지와 모든 생물들, 심지어 우리 조상인 호모사피엔스 초창기에도 결혼이라는 정의는 없었다.

이것이 동물적인 본능은 아니라는 소리다.

우리는 인류라는 조상들에 비해 종으로서 진화한게 아니라, 기술과 제도적인 발전만 있었을뿐이다.

근본은 같다는 소리다.

그럼에도 결혼이라는 제도가 정착된 것은 본능의 영역보다는 제도적, 이성적인 필요에 의해 생겨난 것이 아닐까?

결혼의 시작

작가는 고대 수렵시절부터 얘기를 꺼낸다.

그 시기에는 군혼으로 집단 내에서 음식과 자식을 공유하는 정도였다.

기대수명이 15세정도로 짧기도 하였고, 필요성을 느끼지 못하였기 때문이다.

그러다 낯선 집단과의 협력 등의 이유로, 필요에 의해 이런 제도들이 생겨났다.

농경사회에 들어서면서, 잉여 생산물이라는 개념이 생겼고 좀 더 구체적으로 변화하였다.

계급, 빈부격차 등이 생겨나며 축적된 부를 '내' 자식에게 전달하고 싶었고,

이곳 저곳 떠돌아다니며 아버지가 누구인지 몰라 모계사회였던 수렵시대에서

부계사회, 가부장적 사회로 변경된 것도 이유가 있을 것이다.

이 아이가 나의 자식임을 믿을 수 있는 방법은, 여성에 대한 배타적 독점적 권리를 주장하는 것이고

현대와 유사한 일부일처제가 생기지 않았을까 한다.

부를 물려줄 수 있는 고위층에만 해당하는 내용은 아니었다.

평민들도 결혼은 기존의 노동력과 자원을 효율적으로 관리할 수 있는 훌륭한 제도였다.

자식이라는 노동력 확보에도 무시못할 투자였을 것이다.

결혼의 변화

13세기 클레오파트라가 정략 결혼을 했을때부터, 로미오와 줄리엣이 등장한 15세기 르네상스 시기까지도

결혼은 비지니스 수단이라는 틀에서 벗어나지 못했다.

도움없이 사랑만을 쫓아 결혼하기란 쉽지 않았기 때문이다. 돈이라는 장벽에 가로막혔다.

18세기 산업혁명 이후 부라는 것이 더이상 부모의 상속으로만 생기는 것이 아니게 되었다.

중산층이라는 개념이 생기고, 내 손으로 돈을 벌게되면서 자유 결혼에 대한 인식이 생기지 않았나 싶다

그렇지만 여전히 상류층에서는 커다란 부를 무시할 수 없어, 가문끼리의 결합 의미가 더 컸다.

현재 와서는 정략의 개념이 대부분 사라진 것 같다.

여성도 사회에 진출하며 지위가 높아졌고 더 이상 부모에 의한, 가부장적인 사회가 아니다.

돈과 가문만이 결혼 카드로 쓰이던 시기는 지났다.

대신 자유 연애시장이 되면서 서로가 다양한 면을 고려하게 되었고, 매력이라는 요소까지 추가되었다.

그렇다고 기존의 돈과 가문(부모)가 고려되지 않는 것도 아니다.

결혼이라는 것이, 기존보다 복잡해지고 어려워졌다는거에 모두가 동감할 것이다.

결혼의 종말?

작가는 빠른 시일내에 결혼이 없어지거나, 형태가 변화한다고 얘기한다.

변화의 속도가 달라, 지난 20년의 발전이 200년보다 빠르다는 이유도 있겠지만

결혼의 근본적 목적이 사라졌기 때문이라고 생각하는듯 하다.

역사를 알면 미래를 안다고 하였는가.

우리는 아직도 종의 진화는 이루어지지 않은 호모 사피엔스고

역사를 살펴보면 본능이 아닌 필요에 의해 생겨난 제도이다. (부의 증식,비지니스)

이 필요가 점점 사라지면서 다른 형태로의 변화를 생각한것이다.

고려되는 요소가 많아지고, 포기하는 사람들도 늘어난다고 한다.

여전히 소득에 따른 양극화는 유의미하게 기록되고 있으며,

결혼 대신 다양한 것들로부터 충족되기 때문에 선택의 영역으로 들어선 것이다.

결혼이라는 제도는 점차 사라질 것으로 예측한다.

사랑하는 사람과 지내는것은 동거로 바뀌고

제도적으로도 서로를 책임질 수 있게 팍스 제도등 사회가 변화하고있다.

 ※ 팍스 제도 :  결혼보다 간편하고 덜 부담스러운 동거 계약 형태로, 부동산, 세금, 상속, 건강보험, 자녀 교육 등 여러 사회적 권리를 부여받음

읽고나서

철학서가 아닌 사회 제도를 분석하는 책

일단 서론에서 작가님이 말했던 지금 '왜' 결혼을 해야하는가는 제대로 다뤄지지 않은 것 같다.

아니면 제목에서 알 수 있듯, 과거에는 목적이 있었으나 지금은 '왜'가 사라졌고 결혼 제도가 소멸할 것으로 주장한다고 볼 수 있다.

책 소제목에서 처럼 작가의 사유에 관한 내용이기에, 옳고 그름을 따지고 싶지는 않다.

눈앞에 존재하는 결혼이라는 제도에 대해, 과거와 미래를 보려는 인사이트를 얻었다는 것과

자신의 생각을 정리하기 위해, 분석했던 과정들이 흥미있었다.

그치만 결혼에 대해 철학적으로 생각할 거리를 던져준다기 보다는

제도 자체의 수명을 이야기하는, 트렌드를 다루는 책에 가깝게 느껴졌다.

부처의 이름에 속지 말 것

읽는 중에는 진리를 찾으려 하지 말고, 사유하는 과정에 집중하자

읽기전

부처의 내면을 지닌 자의 성장소설?

무슨 책을 고를지 살펴보다 추천 받은 책. 호기심이 생긴 이유는 단순했다.

제목부터 부처의 사항을 다룰 것이 예상되었는데, 저자는 저 먼 외국의 헤르만 헤세였다. 

먼저 서양의 작가가 동양의 철학을 다룬다는 것도 신기했고

우리에게 데미안으로 익숙한 헤르만 헤세라면

단순한 철학서가 아닌, 그의 사상을 지닌 소년의 성장스토리를 그려내지 않았을까 ? 라는 기대감을 들게 하였다.

읽으면서

이것은 위인전인가? 라는 의문

브라만의 아들로 태어난 싯다르타의 어렸을때로부터 이야기는 시작된다.

어렸을때부터 모든것을 갖추고, 어른들과 비교해도 뛰어난 식견을 지녔던 싯다르타.

그렇지만 누구보다 내면의 갈증을 느껴하며 고뇌하는 사람이다.

"리아, 노암, 핀" 등의 서구권에서 태어난 아이의 소설을 예측했던 나는, 당했다는 기분이 들었다.

이는 내가 아는 부처의 환경, 행보와 유사했기 때문이다. ( 귀족의 자식, 출가 등 )

내 뜻대로 흘러가는 책이 몇이나 있겠는가 하며 이내 받아들이며 보기로 했다.

부처의 행적이나 불교의 교리를 기반으로, 부처가 어떤 생각을 해왔으며

어떤 과정에서 열반에 이르는지에 대한 종교서적 쪽에 가깝다고 생각했다.

실제로 초반부까지 그러하였다.

자아를 버림으로써 아무것도 없을수도, 무엇이든 될수도 있는 경지를 추구하는 구도자.

부처의 삶을 상상하며 읽어도 위화감이 전혀 없었다.

그렇지만 고타마 라는 성인의 등장으로 머릿속에는 물음표로 가득하였다.

고타마도 부처로 알고있었는데?? 부처의 원래 이름인 고타마 싯다르타에서 따온것이란 것을 알 수 있었다.

그렇다면 내가 정답이라 생각했던, 부처의 삶은 싯다르타가 아니었나 하는 의문으로 계속 읽게 되었다.

그럴만 한 것이, 고타마라는 인물은 실제 부처의 상징인 보리수 밑에서 열반을 한 상황이었다.

반면 싯다르타는 무엇이 진리인줄 모르고, 깨닫는 방법조차 몰라서 찾고있는 사문에 가까운 상태였다.

고타마는 정답같은 존재. 즉 불교에서 말하는 진리를 의인화 한 것이고

싯다르타는 작가인 헤르만 헤세의 부처, 불교에대한 해석을 나타내는 인물이 아닐까? 라는 생각으로 읽게 되었다.

자신의 내면과의 싸움 기록

보통 소설의 기본은 발단 - 전개 - 위기 - 절정 단계로 알고있고, 대부분 인물간 혹은 환경적 요인으로 갈등이 심화된다.

하지만 이 책에서는 조금 다른점이 있다.

싯다르타의 내면적 갈등에 의해서 진행되고, 이것만이 조명된다.

작중에는 수많은 인물이 등장한다.

브라만인 아버지부터, 친구이자 추종자인 고빈다.

깨달음을 추구하는 사문들과, 성인 고타마.

기생 카밀라, 상인 카마스바미.

현자 바수데바와 자신의 아들까지.

그치만 이들에 대한 비중이나 묘사는, 엑스트라 정도이다.

물론 책에는 주인공이 있고 조명이 향하는게 맞긴 하지만

이 책에서 이들의 비중은 그저 싯다르타의 행보상 존재했던 인물들 정도이다.

진리로 표현되는 고타마도 스쳐가는 인물 정도이고

현자로 여겨지는 뱃사공 바수데바도 깨달음을 주자마자 사라져 버린다.

그외의 수많은 페이지들은, 모두 싯다르타의 내면에서 발생하는 갈등과 생각들로 이루어진다.

의도적이라 표현할 만큼 독백과 사색에 대한 내용이 많다.

내면의 순수한 소리인 '옴'을 신성시 표현하는것도 그렇고,

외부에 실존하는 모든것들에 대해서는 수련에 방해되는것처럼 표현되기도 한다.

읽고나서

작가의 의도는..?

작가가 말하고자 하는바는 무엇일까. 제목도 그렇고 마치 부처의 생애를 기록한듯한 책이다.

그렇다면 자서전으로 읽어야할까? 마치 부처의 정보를 모아 생각과 행동을 재현했다고도 볼 수 있는 책이다.

아니면 작가의 의도를 전달하기위한 소설속 주인공 정도로 봐야할까?

난 읽을수록 후자로 생각하게 되었다.

데미안을 읽은 상태여서 그런가, 내면의 성장이나 철학에 대해 얘기하고자 하는 작가로 느껴졌기 때문이다.

중반부에 실제 부처로 대표되는 인물인 고타마가 등장하면서

불교 사상과 관련된 이야기를 하고자, 싯다르타라는 제목을 쓰지 않았을까 싶었다.

흥미를 유발하고 독자들로 하여금 몰입하기 위한 장치정도로 생각되었다.

그러면 작가가 전달하고자 하는 깨달음은 무엇이었을까.

마지막에 노인이 되어 나눈 고빈다와의 대화에서 찾을 수 있다고 생각한다.

작은 어린애들은 모두 내면에 이미 백발의 노인을 지니고 있으며,
죽어가는 사람도 모두 내면에 영원한 생명을 지니고 있지.

과거의 존재하였던, 현재 존재하고 있는, 미래에 존재할 모든 생명을 동시적인 것으로 볼 수 있어.
모든것이 선하고, 완전하고, 바라문이야.

모든것에는 부처가 있고, 이를 존중하게되면 돌멩이조차 사랑하게 된다.

돌멩이는 돌멩이지만, 짐승이기도 하며, 신이나 부처이기도 하다.

이를 인지하고 바라보면 구멍 하나하나와 빛깔, 단단함 그 모든것들이 저마다의 방식으로 옴을 발하고 있다.

불교에서 말하는 누구나 마음속에 부처가 있다라는 말이 아닐까?

후반부에 자주 등장하는, 싯다르타를 깨달음에 이르게 한 강에서도 느낄 수 있다.

싯다르타는 강에서 원하는 소리를 들으려 하지 않았다.

그저 강이 내는 소리를 묵묵히 듣고있었을 뿐이다.

강은 고요함의 소리도, 슬픔의 소리도, 격렬한 분노의 소리도 모두 담겨있었다.

자연은 그저 자체로 존재할뿐, 우리에게 어떠한 가르침을 주지 않았다.

싯다르타는 그저 받아들이고, 그 모든 존재의 가능성을 인지하였을 뿐이다.

마치면서

이 책의 재밌었던 점은, 읽기만 해도 싯다르타의 사유하는 경험을 나눠 받았기 때문이다.

생각하는 태도가 달라지면서 나도 모르게 깨달음을 얻을 듯한 느낌이 너무 좋았다.

그렇지만 이 책에서 말하는 모든것들이 진리일까? 라는 거에는 반대다.

어떠한 근거를 가지고 반대하는게 아니라, 작가도 원하지 않을것이라는 느낌이 들었다.

이 책에서 나온 얘기들은 싯다르타, 작가인 헤르만 헤세의 생각끝에 나온 주제들이다.

부처는 그저 몰입하기 위한 장치일뿐, 명성에 의해 진리처럼 받아들이기만 하기에는 아쉬운 책이다.

과정과 태도를 배워, 나만의 진리를 찾아낸다면

이 책을 더 알차게 읽었다고 할 수 있지 않을까? 하는 생각으로 마무리한다.

아키텍처란

요구사항에 맞춰 시스템이 어떻게 구성되고 동작하는지에 대한 표현

S/W 분야에서 아키텍처에 대해 딱 떨어지는 정의는 없는 것 같다.

각자만의 해석이 일부 들어간 개념과 느낌으로 의사소통 한다고 생각된다.

그렇기에 내가 생각하는 아키텍처에 대해 개념을 잡고 가려한다.

간단하게 말하면 시스템에 대한 구성도 정도로 표현할 수 있다.

하지만 단순하게 표현된 결과물보다는, 아키텍처가 도출되기 까지의 과정에도 충분한 의미가 있다고 생각한다.

과정을 대략적으로 살펴본다면

1) 이해 관계자들의 불편으로부터 해소를 위한 니즈가 생겨나고

2) 고객들도 자신의 진짜 필요한 것을, 요구사항이 뭔지 몰라 요구공학을 통해

   다양한 방법 (워크샵, 브레인 스토밍, 인터뷰, 설문조사, 시나리오 기법) 으로 시스템에 필요한 요구사항들을 도출한다.

※ Architectural Driver(AD) : 아키텍처를 디자인하기 위한 핵심 요구사항

2024.05.08 - [IT/Architect 공부] - Architect 공부 6일차 - 요구공학 및 품질속성

3) 기능적 요구사항과 비 기능적 요구사항이 나오고, 이를 다양한 UML로 표현하여

    이해관계자들이 동일한 시각을 갖는지, 올바르게 선정되었는지 확인한다.

기능적 요구사항 : 시스템이 제공해야하는 서비스와 기능에 대한 정의 ( 입력값과 출력값이 명확 )

비기능적 요구사항 : 시스템의 품질과 제약사항에 대한 정의 ( 입력, 출력에 영향을 줄 수 있는 요소들 )

4) 기능적 요구사항은 주로 유스케이스 모델로 표현하고, 비 기능적 요구사항은 품질 속성이 추출되어 이해관계자들에 의해 우선순위가 결정된다. 각 품질속성에 대해 시나리오를 작성해 보고, 이를 충족할 수 있는 잠재적 방법들을 탐색한다.

( Deisng Approach )

※ 품질속성과 관련된 ISO (국제 표준 기준)는 기능성,신뢰성,사용성,효율성,유지보수성,이식성 6가지의 특성이 정의된 ISO-9126과 이를 개정해 호환성과 보안성이 추가된 ISO-25010이 있다.

5) 품질속성은 결정된 우선순위에 따라 핵심 품질속성을 충족할 수 있는 디자인 후보들에 대한 비교 및 결정을 한다. 
( Architectural Decision )

6) 이렇게 아키텍처에 포함될 디자인이 결정되면 이를 설계하고, 주요 이해관계자들이 이해할 수 있는 다양한 시점의 View로 표현한다. ex: 4+1 View, 3 View

7) 최종적으로 요구사항이 잘 반영되었는지 평가를 통한 아키텍처를 검토한다.

※ 아키텍처 평가 방법

ㅁ SAAM (Software Architecture Analysis Model) 

. 시나리오 중심

. 현재 없는 기능에 대한 간접 시나리오를 개발하고, 이를 충족하기위해 변화해야하는 대안 아키텍처를 찾는다.

  직/간접 시나리오에 가중치를 두고, 투표 및 비교 평가 등으로 현재 아키텍처와 대안 아키텍처에서 시나리오를 얼마나 충    족하는지 판단한다.

. Modifiability와 Functionality에 집중

ㅁ ATAM(Architecture Tradeoff Analysis Method)

. SAAM을 발전 시킨것으로 아키텍처 별 Tradoff 를 분석하여 평가하는 방법

. 성능, 사용성, 가용성, 확장성, 보안성 등의 다양한 항목 기준

ㅁ CBAM(Cost Benefit Analysis Method) 

. 비용과 이익 등 경제적인 측면에서 아키텍처를 평가하는 기법

디자인에 정답은 없지만 앞서 말한 원칙들이 잘 지켜지는 Best Practice들은 존재한다. 

비슷한 문제에 이러한 BP들을 적용하여 쉽게 해결할 수 있으며,

복잡하게 디자인 구조를 설명할 필요 없이 패턴 이름만으로 의사소통과 설명이 가능하다.

State 패턴

- 한 객체가 상태에 따라 다르게 동작해야할 때 구현하는 패턴

예를들면 버튼 하나로 동작하는 선풍기가 있을 때 

정지상태에서 버튼을 누르면 바람이 나와야하고, 바람이 나오는 상태에서 버튼을 누르면 정지해야한다.

사용자는 버튼 누르기 하나만 선택했는데, 선풍기 객체는 if문으로 현재 상태에 따라 동작이 바뀐다.

그럼 미풍,약풍,강풍 기능이 도입된다면?? if문에 3가지 분기가 추가된다.

이는 OCP에 어긋나는 내용으로 기능이 추가된다면, 기존의 코드를 수정하지 않아야한다.

또한 각 바람의 세기를 조절하려면 전부 선풍기 객체에서 찾아 변경해야한다.

그렇다면 사용자는 버튼 하나만 누르도록 요청하고, 선풍기가 인터페이스로 각 상태별로 기능을 다르게 구현해야한다.

단 요구하는 기능이 많아질 수록, 클래스도 많아진다는 단점이 있다.

Bridge 패턴

추상화와 구현을 분리하여 확장성과 유지보수성을 높인 디자인 패턴.

대표적으로 삼각형, 사각형으로 이루어진 모양과, 모양에 색칠을 할 색깔로 나눌 수 있다.

추상화 부분에 모양을 두고, 구현부에는 색깔을 두어 각자의 책임을 분리하고 기능이 추가될 때 독립적으로 확장이 가능하다.

추상화 (모양) 을 상속한 삼각형과 사각형은 색깔 인터페이스를 참조하여, 색칠 된 도형을 그린다.

모양이 추가되거나, 색깔이 추가되어도 각자에게는 영향이 가지 않아 유지보수성이 높다.

Adpater 패턴

흔히 해외여행에서 110v 짜리 전압을 사용하는 국가에 갈때 챙기는 돼지코(어댑터)를 생각하면 될 것 같다.

220V 전압을 사용하는 기기에 돼지코를 연결해, 110V에서도 사용할 수 있게 해주는 것이다.

이처럼 호환되지 않는 인터페이스를 가진 클래스들이 동작할 수 있게 해준다. ( 인터페이스 변환)

클라이언트 코드가 변경되지 않고, 다른 인터페이스를 사용할 수 있다는 장점이 있다.

돼지코 예시를 들면, 클라이언트가 원하는 서비스를 실제로 제공하는 220V 기기 ( Adaptee)와

그를 110V로 변환해주는 Adapter, 클라이언트가 사용하는 인터페이스인 110V로 구성된다.

Command 패턴

요청하는 Client 객체와 실제 작업을 수행하는 Receiver 객체의 결합성을 낮추기 위한 패턴.

요청을 객체화 하여 전달한다. 요청을 큐에 저장하거나 실행 취소, 재실행 등의 기능을 구현할 수 있다.

실제 그림은 복잡해보이지만, Client가 요청하고 Receiver가 실제로 요청을 수행한다.

과정을 보면 Client는 요청을 객체화 하여 Invoker에게 전달한다.

Invoker는 사전에 정의된 Command 객체를 지니고 있고 command 인터페이스로 execute 메소드를 호출한다

command 인터페이스를 구현된 ConcreteCommand 객체는 실제로 작업을 수행할 Receiver 객체를 가지고 있고, 이를 호출한다.

Receiver가 실제로 요청을 수행한다.

Visitor 패턴

객체의 구조와 수행되는 연산을 분리할 수 있는 패턴. 데이터 구조를 변경하지 않고도 새로운 연산을 추가할 수 있다.

연산 관련하여 Visitor 인터페이스를 통해 접근한다.

Visitor를 구현한 ConcreteVisitor 클래스에서 실제 작업이 수행되고,

객체 구조 관련한 인터페이스는 Element 인터페이스와 그 구현체에서 수행된다.

사용자는 Element 구현체를 통해 accept 메소드를 호출하여 Visitor 구현채의 visit 메소드를 수행한다.

Visit 연산에 대한 확장에는 자유롭지만, 객체 구조와 관련된 Element 확장 시에는 Visitor 클래스의 변경이 필요하다.

Proxy 패턴

실제 객체에 대한 접근을 제어하고 관리할 수 있는 패턴이다.

직접 접근을 막고 프록시 객체를 제공함으로써 지연 초기화 및 캐싱 기능을 제공할 수 있으며 보안처리도 가능하다.

※ 지연 초기화 : 객체의 필드 초기화 시점을 그 값이 처음 필요할 때까지 미루는 기법.

                         메소드로 분리하여 진짜 필요할 때만 수행한다.

사용자는 인터페이스로 작업을 요청하고, 내부 로직으로 프록시 객체에 도달한다.

프록시 객체는 실제 객체에게 작업을 수행시킬지 판단한다.

 ex: 동일한 요청으로 캐싱값 가지고 있는 경우, 실제로 객체 초기화가 필요한지

프록시 객체는 실제 객체에게 작업을 요청하고 결과값을 반환받아 사용자에게 전달한다.

Decorator 패턴

객체에 추가적인 기능을 동적으로 추가할 수 있는 디자인 패턴이다.

기본적으로 데코레이터가 적용될 Componenet 객체가 존재하고, 이에 기능을 추가하는 Decorator로 나뉜다.

예를들어 크리스마스 트리를 꾸밀 때, 기본이 되는 실제 트리를 Component 객체라 할 수 있고

전구, 별 등의 장식품을 Decorator로 표현할 수 있다.

조합을 위해 수많은 자식 클래스가 생기지 않고, 동적으로 필요한 기능을 추가할 수 있다.

Coposite 패턴

객체를 트리 구조로 구성하여 개별/복합 개체를 동일하게 다룰 수 있는 패턴.

단일 객체인 Leaf와 단일,복합 개체를 포함하는 Compoiste 객체로 나뉜다.

단일/복합 객체를 구분할 필요가 없이 동일하게 취급하여 재귀적 구조를 쉽게 만드는 디자인 패턴이다.

윈도우의 파일 탐색기를 생각해보면 된다.

C드라이브 안에 폴더가 여러개 있고, 단일 수행파일이 있다. 폴더들은 또 트리형태로 폴더와 개별 파일들로 구성 되어있다.

Prototype 패턴

새로운 객체를 생성할 때 생성자가 아닌, 기존 객체의 복사본을 만들어 사용하는 패턴.

초기화 단계를 생략하고 현재 상태를 복사할 수 있다는 장점이 있지만, 객체마다 복사 시 예외처리들이 다 다르다는 단점.

COR ( Chain of Responsibility ) 패턴

요청을 보내는 클라이언트와 처리하는 객체(Handler) 사이의 결합도를 낮추는 패턴.

요청을 처리할 수 있는 여러 개의 Handler 객체를 생성하여 연결하고, Chain에 따라 순차적으로 처리한다.

Factory 패턴

객체의 생성과정을 캡슐화 하여, 클라이언트 코드와 분리하는 패턴.

클라이언트에서 New로 객체를 생성하지 않고, 팩토리 클래스에서 다양한 유형의 객체를 생성하여 리턴한다.

// Creator(팩토리) 인터페이스
interface Creator {
    Product factoryMethod();
}

// ConcreteCreator(구체적인 팩토리) 클래스
class ConcreteCreatorA implements Creator {
    @Override
    public Product factoryMethod() {
        return new ConcreteProductA();
    }
}

// 다른 ConcreteCreator 클래스
class ConcreteCreatorB implements Creator {
    @Override
    public Product factoryMethod() {
        return new ConcreteProductB();
    }
}

// 클라이언트 코드
public class Main {
    public static void main(String[] args) {
        Creator creatorA = new ConcreteCreatorA();
        Product productA = creatorA.factoryMethod();

        Creator creatorB = new ConcreteCreatorB();
        Product productB = creatorB.factoryMethod();
    }
}

Abstract Factory 패턴

팩토리 패턴과 유사하나, 관련 객체들의 생성 들의 생성 시, 구상 클래스의 지정 없이 관련 객체들의 모음을 생성하는 패턴

유사한 객체들을 집단별로 찍어낼 수 있다는 점이 포인트다.

이를 위해 하나의 Factory에서 연관된 다양한 종류들의 객체를 찍어내야한다.

예를들어 의자, 소파, 커피테이블을 세트로 판매중이라면 생산시에 같은 디자인으로 만들어야 한다.

이를 위한 디자인 별로 추상 팩토리를 선언하고, 실제 의자, 테이블, 소파를 생산하는 팩토리를 구현한다.

※ 팩토리 패턴과의 비교

하나의 팩토리에서 단일/여러 종류의 객체를 생산하는 차이.

팩토리 패턴은 객체 생성과정만 추상화하지만, 추상 팩토리는 생성되는 객체의 관계들까지 추상화한다.

Builder Pattern

복잡한 객체를 생성하는 과정을 단계별로 캡슐화한 생성 패턴

Builder 객체를 통해 실제 객체 생성과정을 단계별로 구분하고,

Director 클래스에서는 순서를 정의하고, Builder 객체를 사용해 객체를 생성한다.

복잡한 생성과 파라미터가 존재하는 경우 유용하다.

예를들어 햄버거를 생성할 때 빵, 패티, 치즈, 양상추, 토마토, 베이컨, 피클 등의 다양한 재료들이 들어간다.

요청하는 사람마다, 제품의 종류마다 각 재료들은 다양하게 변경되며 빵은 맨 위와 아래에 한개씩 포함되어야한다.

이러한 복잡한 생성과정과 순서를 정의할 때 편리하고, 필요한 재료만 포함시킬 수 있다.

유연성과 가독성이 높아진다.

설계에 정답은 없으나 품질을 올리려는 시도들은 존재함.

아래 나열되는 몇가지 원칙들과 이를 잘 적용한 BP 사례들은 존재한다. 

- 최대한의 독립성으로 재사용성을 늘리고 유지보수를 쉽게 한다

. 높은 응집성 : 클래스에 연관성 있는 기능들만 모여있는지

. 낮은 연결성 : 객체간 의존성을 낮춤

DRY ( Don't Repeat Yourself ) : 같은 코드를 반복하지 말아라. 계속 사용된다면 모듈화를 고민해 볼 것

KISS ( Keep It Simple and Stupid ) : 코드를 단순하고 읽기 쉽게 만들어라

SOLID 원칙

ㅁ SRP ( Single Reponsibility Principle )

- 하나의 클래스에는 하나의 책임만 지도록 단일 기능으로 구현

여러개의 기능으로 이루어진 클래스는 책임의 수 만큼, 기능의 수 만큼 변경될 여지가 생겨버린다.

이를 해결하기 위해 Facade 패턴을 사용할 수 있다. 

Facade는 건물의 정면을 뜻하는 단어로, 클라이언트는 Facade 인터페이스 하나만 보고 접근한다.

내부의 기능은 어떻게 구현되어있는지 모르며, 각 기능별로 담당하는 클래스들이 내부에 따로 존재하는 패턴

뒷단의 복잡한 구조를 감추고, 깔끔한 Facade를 바라보게 하는 용도로 사용한다.

ㅁ OCP ( Open Close Principle )

- 확장에는 열려있고, 변경에는 닫혀있는 원칙

변경하는 대상과 불변 대상을 구분하여, 요구사항이 변경되어도

코드를 변경하지 않고 다른 클래스를 확장하여 해결 가능한 설계

간단하게 말하면 변경이 일어나는 부분에 대해서 인터페이스로 추상화 하고,

클라이언트는 불변하는 인터페이스를 참조 하면 된다.

전략 패턴을 예로 들어, 결제를 하려할 때

고객은 어떤 결제방식을 선택할지 전략을 지정하기만 하면 된다.

여기에 결제 방식이 추가된다면, 기존 코드는 건들지 않고 클래스를 하나 더 만들면 된다.

ㅁ LSP ( The Liskov Substitution Principle ) 

자식 타입의 클래스는 부모 클래스의 역할을 수행할 수 있어야한다.

상속과 관련된 내용으로, 상속관계 클래스간의 일관성과 유연성을 보장한다.

가장 대표적인 예로 직사각형의 하위 클래스인 정사각형을 생각하면 된다.

상속관계가 아니거나, 자식 클래스에서 잘못된 오버라이딩을 했거나...

ㅁ ISP ( Interface Segregation Principle )

SRP와 유사하게 , 다양한 기능을 가진 인터페이스를 선언하기 보다는 기능별로 인터페이스를 분리하자

인터페이스를 기능별로 잘게 나누어, 클래스는 사용하고자 하는 인터페이스만 구현하면 된다.

복합기의 예시를 들 수 있다. 복합기는 인쇄, 복사, 팩스 등 다양한 기능이 사용 가능하지만

이를 복합기라는 하나의 인터페이스로 제공하면 ISP를 위반한다.

모든 사용자가 기능을 다 쓰지는 않기때문에, 각 기능별로 인터페이스를 분리하여 사용자가 원하는 기능만 구현하게 하자.

ㅁ DIP ( Dependency Inversion Principle )

하위 모듈을 참조할 때 직접 참고하지 않고, 추상화된 상위 인터페이스를 참조하는 것.

하위 모듈의 변경에 영향을 받지 않는다.

요구 공학 ( Requirements Engineering )

- 시스템의 목적을 식별하기위해 요구사항을 파악하고 이를 검증 및 관리하는 일련의 활동들

- S/W 개발 프로세스와 생명주기가 맞춰가며 진행된다.

요구사항

- 요구 공학 프로세스로부터 생성된 시스템 서비스(기능)와 제약사항(비기능)에 대한 설명

요구공학 프로세스는 아래 순서대로 진행된다.

1) 타당성 분석

해당 시스템이 개발할 가치가 있는지, 가능한지에 대한 사전 논의

- 기술적, 경제적 관점, 일정, 운영 측면에서 검토한다.

2-1) 요구사항 도출

- 시스템을 통해 해결하고자 하는 문제를 찾아내는 것.

고객들도 자신의 진짜 요구사항이 뭔지 모르기 때문에 이를 찾아내는 여러 방법들이 존재한다. 

( 브레인 스토밍, 롤플레잉, 인터뷰, 워크샵 등등 )

ex)

. 브레인 스토밍을 통해 각 이해관계자들의 다양한 요구사항들이 1차적으로 생성되고

. 이 중에 일부를 채택하여 요구사항을 명세화한다.

. 해당 요구사항에 대해 다양한 이해관계자들이 어떻게 생각하는지

  논의하고 합의점을 찾아, 모두가 납득할만한 요구사항으로 수정

2-2) 요구사항 분석

- 요구사항 모델을 통해 이해 관계자들의 이해를 돕는다. 

모델링 방법

. 구조 분석

ㅁ DFD ( Data Flow Diagram )

ㅁ STD ( State Transition Diagram )

ㅁ ERD ( Entity-Relation Diagram )

. 유즈 케이스 분석

ㅁ UC ( Use Case Modeling )

. 비용 기준 접근 : ROI

. 계층화 분석법(AHP) : 여러 대안들을 계층으로 나누어 다방면에서 판단하기 위한 분석법

3) 요구사항 명세

요구사항들을 문서화 하는 작업.

요구사항은 크게 기능 , 비기능 요구사항으로 나뉜다.

. 기능적 요구사항 : 시스템이 어떻게 동작해야하는지에 대한 설명. 제공하는 기능

. 비기능적 요구사항 : 시스템에 부과되는 제약 조건(품질 속성). 시스템의 품질에 대한 판단

※ 도메인 요구사항 : 시스템의 도메인으로부터 오는 요구사항. 기능 비기능 둘 다 가능

QAS : Quality Attribute Senario

- 품질 속성을 만족하는지 확인하기위한 시나리오.

구체적인 상황과 수치로 표현되어 요구사항 충족 여부를 확인할 수 있어야한다.

QAW : Quality Attribute Workshop

- 초기부터 이해관계자가 참석하여 품질 속성에 대해 의논하는 것.

- QAS로 문서화 되고 우선순위가 부여된 QA를 얻을 수 있다. 

. 순서

ㅁ 각 요구사항 들에 대해 이해 관계자 별로 우선순위 부여

ㅁ 요구사항의 품질 속성 정의 ex : 보안성, 가용성, 신뢰성, 안정성, 유지보수성 등등

ㅁ 그에 맞는 시나리오 부여

ex:

4) 요구사항 확인 및 검증

5) 요구사항 변경 관리

앞전에 OOAD를 통해 분석/설계 방법을 배웠다면, 이제는 설계의 품질을 올리는 과정이다.

좋은 설계의 정답은 없으나, Best Practive는 존재한다.

ㅁ 좋은 객체지향 설계를 위한 원칙들

1) DRY 원칙

Don't Repeat Yourself

- 같은 코드를 가리키는 이름은 오직 하나여야 한다.

2) KISS 원칙

Keep It Simple and Stupid

- 코드를 단순하고 인간이 읽기 쉽게

-- 보통의 메소드를 보면 10줄이 넘어가지 않는다.

3) Solid 원칙

SOLID

SRP : 단일 클래스가 하나의 책임과 역할만. 여러개의 responsibilite가 있으면 쪼개라

OCP : 변경이 최소화되어야한다.

LSP : 상속된클래스는 부모클래스를 대체할 수 있어야한다.

DIP : 높은 수준의 모듈은 낮은 수준의 모듈에 디펜던시를 가져서는 안된다. 
       디펜던시 뿐만아니라 onwership도 포함.사용하는 패키지로 오너십

ISP : 인터페이스가 커지면, 사용자들은 사용하지 않더라도 인터페이스에 종속됨. -> 여러개로 나눌 필요성

※postPayment() operation이 변경될때, Roaster Application은 사용하지 않음에도, 종속관계라 Recompile 필요. 

4) GRASP

GRASP: General Principles in Assigning Responsibilities

OOAD 과정에서 클래스에 responsibility를 부여하는 설계원칙.

Modularity : 좋은 설계란, 시스템을 모듈로 나누고 그에 맞는 Reponsibility가 부여되어있는것

측정 방법으로는 1) Coupling(결합성) 과 2) Cohesion(응집성) 측정

1) Coupling : 디펜던시가 낮으수록 좋다 → 변경의 자유로움과 영향도가 적음 ( loosely coupled )

2) Cohesion : 모듈 하나에 대해 평가, 얼마나 연관성 있게 모여있는지 (이해가 쉽고, 재사용이 용이함 )

GRASP 9가지 원칙

1) Information Expert : responsiblity 부여에 대한 근거 중 Information을 갖고 있는 오브젝트가 타당할 확률이 높다.

2) Creator : 특정 인스턴스 생성의 responsiblity를 누가 가질 것인가?

                   아래 조건을 충족할수록 타당함

3) Controller : UI Layer에서 넘어온 request를 누가 먼저 받을지에 대한 것

3-1) 시스템 전체를 대표하는 Entity를 두어서 전부 처리하던가

3-2) 유즈케이스, 세션 담당 객체를 만들어서 받던가

4) Low Coupling : 굳이 불필요한 Coupling 을 낮추는 방향으로. ( 변경 영향도 ↓ )
                             Global Object는 커플링 상관이 적음

5) High Cohension : 높은 응집률을 가지도록 부여

6) Pure Fabrication : 기존 오브젝트(도메인 단계에서 나온 오브젝트)에 responsiblity를 부여하기보다는, 디자인단계에서 새로 만들어서 부여

7) Polymorphsim : 특정 타입마다 다른 Behavior. 클래스가 많아지고 직관적 이해가 어려워질수는 있음

8) Indirection : 중재할 수 있는 객체를 두어, 커플링을 회피

9) Protected Variations(PV) : stable한 interface를 만들어서 resoponsibility를 부여

아키텍트의 역할 : 핵심 고객/관계자의 의도를 파악해 다른 관계자들에게 잘 전파하는 것.

소프트웨어는 생각이고, 언어는 생각을 정의한다. ( 자주 쓰는 단어들이 그 사람의 의도를 보여준다 )

어떤 품사냐에 따라 다양한 방법론들이 등장

1) 동사 : 절차적(구조적) 개발 방법론

2) 명사 : 객체지향 개발론

3) 부사 : 비기능(?)

고객이 Concern이 생기고, 이를 분석단계에서 나눠준다.

나눠줄때는 MECE에 따라 나눠주어 서로 영향을 끼치지 않도록 한다.

모호성이 제거되어 고객의 Requirement가 결정되고 이는 기능/비기능적 요구사항으로 나뉠 수 있다.

기능  : 동사로 설명 가능. 입력값 대비 출력값의 변화이며 한번에 테스트로 된다/안된다가 정해진다.

비기능 : 부사로 설명가능. 입력 대비 출력의 변화를 제약하는 요소들 (Quality)

              신경쓰기 어려우나, 비기능이 떨어지면 시장이 외면

Quality Attribute Senraio 작성

고객의 비기능적 요소를 얼마나 잘 충족할 수 있는지에 대한 내용으로

성능/사용성/신뢰성 등의 항목들로 표현 가능. 난이도/중요도를 작성하여 우선순위를 정하고 어디에 집중할지 결정 가능

작성 요령

1. 특정한 상황을 가정하라.
2. 수치로 작성하라.
3. 순서를 정하라.

MECE에 따라 나누기를 성공했다면 이것들을 적절히 붙여야한다.

1) Call & Return(Client Server)

2) Event Bus ( Send Receive )

3) Data-shared

4) Pipe&filters

개발의 독립적인 단위. Port를 지니고 내부구조를 볼 수 있다. ( OOAD 보다는 구현단계인 OOI 쯤에 등장한다.)

Kruchten의 4+1 view model에서 Development view에 해당한다.

Interface를 통해 접근한다.
Required - Input / Provided - Output 으로 보면 된다.

Interface 표현 방법
1) Ball(롤리팝) and socket symbols
롤리팝은 Provider , socket은 Required 로 표현

2) Stereotype notation
Depedency : 컴포넌트가 일을 하려면 특정 컴포넌트의 데이터가 필요하다. 이를 디펜던시가 있다고 표현
Realization : 필요한 데이터를 컴포넌트가 interface realization 하여 제공한다.

3) Text listing

Component realizaion
컴포넌트 내부의 클래스를 realzation . 오브젝트 인스턴스 및 Association 까지 표현 가능 ( 오브젝트 다이어그램 까지 )

컴포넌트 밖에서 외부 오브젝트와의 연결은 Requred/Provided Interface를 통해 표현할 수 있지만
컴포넌트 내부의 연결은 Assembly connector , 내부/외부를 연결하는 Delegation connector로 표현 가능

ㅁ BP 참고하여 고려할 점

1) 유스케이스처럼 그린점. 시스템의 바운더리를 명확하게 하지 않은점 수정 필요

2) MVC 패턴처럼 레이어를 나눈것은 동일하였으나, 인터페이스 연결관계만 표시했어야함.

3) 컴포넌트 다이어그램 이해가 부족하여 복습 필요

<BP>