정리와 기록

UML의 구성 요소 : 사물(Things), 관계(Relationship), 다이어그램(Diagram)   #사관다

1) 사물(Things) : 구조 사물, 행동 사물, 그룹 사물, 주해 사물   #그구행주

2) 관계(Relationships)   #연일의실 집포

2-1) 연관(Association) 관계 : 기호 ㅡ로 표시하고 관련되어 있어

- 두 사물간의 구조적 관계. 한 사물 객체가 다른 사물 객체와 연결되어 있음 ('has-a')관계

2-2) 일반화(Generalization) 관계 : 기호 ㅡ▷로 표시하고 일반적인지 구체적인지

- 일반화된 사물과 좀 더 특수화된 사물 사이의 관계

- 일반적인 개념을 상위(부모), 구체적인 개념을 하위(자식)이라고 함 ('is-a')관계

2-3) 의존(Dependency) 관계 : 기호 -->로 표시하고 클래스가 다른 클래스 사용

- 한 사물의 명세가 바뀌면 다른 사물에 영향을 준다.

- 일반적으로 한 클래스가 다른 클래스를 오퍼레이션의 매개변수로 사용하는 경우에 나타나는 관계

2-4) 실체화(Realization) 관계 : 기호 --▷로 표시하고 기능으로 묶인 관계

- 한 객체가 다른 객체에게 오퍼레이션 수행하도록 지정하는 의미적 관계이다.

- 클래스나 인터페이스를 상속받아 자식클래스가 추상 메서드를 구현할 때 사용

2-5) 집합(Aggeregation) 관계 : 포함하지만 독립적 [부분-◇전체]   // 기호 ◇- -◇로 표시

2-6) 포함(Composition) 관계 : 포함하고 생명주기를 함께 해       // 기호 ◆- -◆로 표시

3) 다이어그램

3-1) 정적 다이어그램(Structural Diagram) => 구조적(Structural)   #클객컴복 패배

● 클래스 다이어그램(Class Diagram) : 클래스 간 관계를 표현

- 문제 해결을 위한 도메인 구조를 나타내어 보이지 않는 도메인 안의 개념과 같은 추상적인 개념을 기술하기 위해 나타낸 것이다. 또한 소프트웨어의 설계 혹은 완성된 소프트웨어의 구현 설명을 목적으로 사용할 수 있다. 이 다이어그램은 속성(attribute)과 메서드(method)를 포함한다.

- 구성요소 : 클래스 이름, 속성, 연산, 접근제어자, 관계

● 객체 다이어그램(Object Diagram) : 객체 간 관계 표현. 연관된 모든 인스턴스를 표현

● 컴포넌트 다이어그램(Component Diagram) : 컴포넌트 간 관계 표현

 - 구성요소 : 컴포넌트, 인터페이스, 의존 관계

● 복합체 구조 다이어그램(Composite Structure Diagram) : 복합 구조인 경우 내부구조를 표현

● 패키지 다이어그램(Package Diagram) : 패키지 간 관계 표현

- 구성요소 : 패키지, 의존관계

● 배치 다이어그램(Deployment Diagram) : 물리적 요소의 위치 표현

3-2) 동적 다이어그램(Behavioral Diagram) => 행위(Behavioral)   #유시커 상상활타

● 유스케이스 다이어그램(Use Case Diagram) : 사용자 관점에서 표현 (사용자의 요구를 추출하고 분석)

  - 구성요소 : 유스케이스, 액터, 시스템, 시나리오, 이벤트의 흐름

● 시퀀스(순차) 다이어그램(Sequence Diagram) : "시간적 개념" 중심으로 메시지 흐름 표현

 - 구성요소 : 객체, 생명선, 실행, 메시지

● 커뮤니케이션 다이어그램(Communication Diagram) : 객체들이 주고 받는 메시지와, 상호작용 표현

- 구성요소 : 상태, 시작상태, 종료상태, 전이, 이벤트, 전이조건

● 상태 다이어그램(State Diagram) : 객체의 상태와 상태 변화를 표현

  - 구성요소 : 상태, 시작상태, 종료상태, 전이, 이벤트, 전이조건

● 상호작용 개요 다이어그램(Interaction Overview Diagram) : 상호작용 다이어그램 간의 제어흐름 표현

● 활동 다이어그램 (Activity Diagram) : 시스템이 수행하는 활동을 표현

- 구성요소 : 시작점, 전이, 액션/액티비티, 종료점, 조건노드, 병합노드, 포크노드, 조인노드, 구획면

● 타이밍 다이어그램(Timing Diagram) : 객체의 상태 변화와 시간 제약을 표현

1) UX와 UI
- UX (User Experience) : 사람의 감정이나 경험을 나타내는 개념
- UI (User Interface) : 사용자 인터페이스. 예로는 CLI이 있다.

2) UI의 구분   #CGV NO
- CLI (Command Line Interface) : 텍스트 기반(명령어)
- GUI (Graphical User Interface) : 그래픽 기반(마우스, 펜). 마우스로 작업을 하는 그래픽 환경의 인터페이스
- NUI (Natural User Interface) : 신체 부위 이용(터치, 음성). 사용자의 말과 행동으로 기기 조작하는 인터페이스
   - 말이나 행동 그리고 감정과 같은 인간의 자연스러운 표현으로 컴퓨터나 장치를 제어할 수 있는 환경 
- VUI (Voice User Interface) : 사람의 음성으로 기기를 조작하는 인터페이스
- OUI (Organic User Interface) : 모든 사물과 사용자 간의 상호작용을 위한 인터페이스

3) UI의 기본 원칙   #직유학유
- 직관성 : 누구나 쉽게 이해하고 사용할 수 있어야 한다.
- 유효성 : 사용자의 목적을 정확하고 완벽하게 달성해야 한다.
- 학습성 : 누구나 쉽게 배우고 익힐 수 있어야 한다.
- 유연성 : 사용자의 요구사항을 최대한 수용하며, 오류를 최소화해야 한다.

4) UI 화면 설계 구분   #와스프
- 와이어프레임 : 이해관계자들과 화면 구성을 협의하거나 화면 단위의 레이아웃만 구성한 문서

- 스토리보드 : 와이어프레임 + DB연동, 정책 등 구축하는 서비스의 정보가 수록된 문서

- 프로토타입 : 와이어프레임, 스토리보드에 동적인 요소를 적용하여 만든 시뮬레이션 가능한 모형

1) LOC(Line Of Code) 기법
- 원시코드 라인수의 비관치 / 낙관치 / 기대치를 측정하여 예측치를 구하고 비용을 산정.
ex. 프로젝트의 총 라인이 30000 라인이고, 개발자가 5명, 그리고 인당 월평균 300라인의 개발이 가능할 때
소요되는 예상 기간은? 30000 / (5 * 300) = 20개월

2) Man-Month
- 한 사람이 1개월간 할 수 있는 일의 양을 기준으로 비용 산정
- Man-Month = LOC / 개발자의 월간 생산성
- 프로젝트 기간 = Mon-Month / 프로젝트 인력
- LoC가 50,000라인이고, 개발자가 10명이며, 개발자는 월평균 250라인을 개발할 경우 Man Month = 200

3) COCOMO(Constructive Cost Model) 모형
- 보헴이 제안한 프로그램 규모에 따른 비용산정 모형
- Man-Month 기반으로 규모에 따라 비용산정.
- 조직형 Organic : 5만 라인 이해 소프트웨어 개발(소규모)
- 반분리형 Semi-Detached : 30만 라인 이하 소프트웨어 개발(중규모)
- 내장형 Embedded : 30만 라인 이상의 소프트웨어 개발(대규모)

- 기본형 Basic COCOMO : 코드 라인 수, 개발 유형을 이용하여 비용 산정
- 중간형 Intermediate COCOMO : 기본형 COCOMO 기반, 15가지 요인에 의해 비용 산정
- 발전형 Detailed COCOMO : 중간형 COCOMO 보완. 개발 공정별로 명확하게 노력을 산출하여 비용 산정

4) Putnam 모형
- Rayleigh-Norden 곡선의 노력 분포도를 이용한 프로젝트 비용 산정기법
- 소프트웨어 개발주기의 단계별로 요구할 인력의 분포를 가정하는 방식
- 개발 기간이 늘어날수록 프로젝트 적용 인원의 노력 감소
*SLIM : Putnam 모형을 기초로 해서 만든 자동화 추정 도구

5) FP(Functional Point) 모형
- 알브레히트(Albrecht) 제안. 요구 기능을 증가시키는 요인별로 가중치 부여. 
요인별 가중치를 합산하여 총 기능점수 계산하여 비용 산정
*ESTIMACS : 다양한 프로젝트와 개인별 요소를 수용하도록 FP 모형을 기초로 개발된 자동화 추정 도구

1) 객체지향 용어

- 객체(Object) : (개념)실세계에 존재하거나 생각할 수 있는 것
- 클래스(Class) : (객체를 구현하기 위한 코드)유사한 객체들을 묶어서 하나의 공통된 특성을 표현한 것
- 인스턴스(Instance) : (메모리에 구현된 객체) 같은 클래스로부터 구현된 객체
- 메서드(Method) : 클래스로부터 생성된 객체를 사용하는 방법
- 메시지(Message) : 객체에게 어떤 행위를 하도록 지시하는 명령
- 상속(Inheritance) : 상위 클래스의 속성과 연산을 하위 클래스가 물려받는 것
- 추상화(Abstraction) : 전체적이고 포괄적인 개념을 설계한 후, 차례로 세분화하여 구체화 시키는 것
- 캡슐화(Encapsulation) : 데이터와 함수를 하나로 묶어 외부로부터 정보은닉한 것
- 다형성(Polymorphism) : 상속받은 하위 객체들이 다른 형태의 특성을 갖는 객체로 이용될 수 있다.
- 집단화(Aggregation) : 클래스들 사이의 전체, 또는 부분 같은 관계를 나타낸다(part)
- 일반화(Generalization) : 클래스가 다른 클래스를 포함하는 상위 개념이면 일반화 관계로 모델링

2) 객체지향 설계 원칙 : SOLID

- 단일책임 원칙(Single Responsibility) : 객체는 단 하나의 책임만 가져야 한다.
- 개방폐쇄 원칙(Open-Closed) : 확장에는 열려있어야 하고, 수정에 대해서는 닫혀있어야 한다.
- 리스코프 치환 원칙(Liskov Substitution) : 상속받은 하위 클래스는 언제나 상위클래스로 교체 가능하다.
- 인터페이스 분리 원칙(Interface Segregation) : 클라이언트는 미사용 메서드와 의존관계를 맺으면 안된다.
- 의존역전 원칙(Dependency Inversion Principle) : 의존 관계를 맺을 때, 변화하기 어려운 것에 의존한다.

3) 럼바우의 객체지향 분석 기법 : 객동기

- 객체 모델링 : 정보 모델링. 객체와 객체들 간의 관계를 정의 ex. ERD

- 동적 모델링 : 시간에 따라 객체들 사이의 제어 흐름, 동작 순서 등의 동적인 행위를 표현. ex. 상태다이어그램

- 기능 모델링 : 프로세스의 자료흐름을 중심으로 처리과정 표현. ex. DFD(데이터 흐름도)

1) 생성패턴 : 객체 인스턴스 생성에 관여

#추빌팩프싱 

- 추상팩토리 패턴 : 연관성이 있는 객체들을 묶어 추상화하고, 구체적인 상황에 객체 군을 구현화 하는 생성 패턴.
관련 객체의 집합을 생성하는 인터페이스 제공.

- 빌더 패턴 : 생성과 구현을 분리하여 복잡한 객체를 조립하여 생성.
동일한 생성 공정이 서로 다른 구현을 만들어 냄.

- 팩토리 메서드 패턴 : 상위클래스에서 인터페이스 정의하고 서브클래스가 실제 생성한다.
인스턴스 생성을 하위 클래스에 위임.

- 프로토타입 패턴 : 프로토타입을 먼저 생성하고 이를 복제하여 객체를 생성한다.

- 싱글톤 패턴 : 객체의 인스턴스는 오직 하나만 가진다. 하나의 객체를 생성해 공유하나 동시참조는 불가능하다.

2) 구조패턴 : 여러 객체를 모아 구조화시키는 패턴

#어브컴데퍼플프

- 어댑터 패턴 : 기존 클래스를 재사용할 수 있도록 중간에서 맞춰준다.
호환성 없는 클래스의 인터페이스를 이용할 수 있게 변환.

- 브리지 패턴 : 기능과 구현을 분리하여 결합도를 낮춘 패턴.

- 컴포지트 패턴 : 객체들의 관계를 트리 구조로 구성. 복합 객체와 단일 객체를 동일하게 취급.
그릇과 실제 내용물을 동일시 함.

- 데코레이터 패턴 : 객체 결합을 통해 상속을 사용하지 않고도 객체의 기능을 동적으로 확장.
장식자와 실제 내용물을 동일시 함.

- 퍼싸드 패턴 : 복잡한 시스템에 단순한 인터페이스를 제공해 접근성을 높인 패턴

- 플라이웨이트 패턴 : 객체를 공유하여 메모리를 절약하는 패턴

- 프록시 패턴 : 접근이 어려운 객체를 연결해주는 인터페이스 역할을 수행하는 패턴

3) 행위패턴 : 클래스나 객체들의 상호작용 패턴화

#책방커반 메옵템 상전인중

- 책임 연쇄 패턴 : 처리하지 못한 요청을 다음 객체로 넘기는 패턴. 한 요청을 2개 이상의 객체에서 처리

- 방문자 패턴 : 필요한 기능은 해당 클래스를 방문하여 처리하는 패턴.
객체 구조는 변경하지 않고 기능만 따로 추가하거나 확장할 때 사용

- 커맨드 패턴 : 요청을 객체로 캡슐화하여, 그에 맞는 서브 클래스 실행

- 반복자 패턴 : 접근이 잦은 객체는 동일한 인터페이스를 사용하록 하는 패턴.
내부구조를 노출하지 않고, 복합 객체의 원소를 순차적으로 접근가능케 하는 행위 패턴

- 메멘토 패턴 : 객체를 해당 시점의 상태로 되돌리는 기능을 제공하는 패턴

- 옵저버 패턴 : 관찰대상의 변화를 탐지하는 패턴

- 템플릿 메서드 패턴 : 상위 클래스에서 기능 골격을 정의하고, 하위 클래스에서 세부 처리 방법을 구체화하는 패턴.
구체적인 처리를 하위 클래스에 위임.

- 상태 패턴 :  객체의 상태를 캡슐화하고, 이를 참조해 동작을 다르게 처리하는 패턴

- 전략 패턴 : 클라이언트에 영향을 받지 않는 독립적인 알고리즘을 선택하는 패턴.
여러 정책들을 추가/교체 가능하도록 구현.

- 인터프리터 패턴 : 여러 언어 구문을 해석할 수 있게 해주는 패턴

- 중재자 패턴 : 객체 사이에 중재자를 두어 의존성을 줄이는 패턴