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

오브젝트는 클래스의 인스턴스들
개별 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 호출