1장 - 소프트웨어 설계of 꼭 주의!!gof 주의!

1. 생명주기 **
생명주기란 개발 방법론의 바탕으로, 운용 유지보수등의 관계를
단계별로 나눈 것. 
폭포수,프로토타입, 나선형, 에자일 모형이 있다. 
 폭포수모형 -> 다시는 돌아갈 수 없다. 각 단계를 확실히 매듭짓고 승인 후 다음단계 
-> 타당성 검토, 계획, 요구분석, 설계, 구현, 시험 , 유지보수 
(고전모델)
 
프로토타입 -> prototype(시제품을 만들어, 최종 결과물 예측 . 
요구시집 ->빠른 설계- > 프로토타입 -> 평가 -> 조정 -> 구현 반복 
 
나선형 모델 -> 둘을 합친 것  (요구사항이 이해하기 어려울떄)
유지봇 과정 x 
계획 수립 -> 위험분석->개발검증->평가. 안정성을 위해 위험을 최소화 . (이를 반복) 
 
에자일 모형 -> 민첩한 모형. 
민첩하고 기민하게 . 전반에 걸쳐 사용 .
짧은 개발주기로 계속 반복해서 평가, 요구 수용 
 
에자일 모형은 폭포수에 비교하여 요구사항이 반영되고, 의사소통이 지속적이고, 잦은 테스트, 고객중심의 개발이다.
 
2. 스크럼 (럭비에서 공을 두고 팀끼리 모이는 상태)
제품 책임자, 스크럼마스터(통제x)<조언 가이드> , 개발팀. 
개발과정 - >
제품 백로그 (요구사항 나열, 지속적인 update) -> 스프린트 계획 회의 -> 단기 일정 수립 -> 스프린트 (실제 개발은 짧게 한달정도 안에 (틀린건아님 더걸려도)) -> 일일 스크럼 회의 (중간중간 진행 과정, 매일매일 ) -> 스프린트 검토 회의 (요구사항이 맞는지) -> 회고 (최종 확인) 
 
3.Xp 기법(extreme programing) -> 계속 바꾸는거라 용기있게 모여서 빡빡 얘끼하면서 나가야됨
짧고 반복적으로 개발, 짧게 짧게 요구사항 부분만족시킴. 인원이 적을때 유리하다. 
의사소통,단수성,용기,존중, 피드백이 필요하다. 
대표적인 에자일 개발 방법론. (not 구조적 론) -> 개발 문서보다 소스코드가 중점
 
사용자 스토리(요구사항) -> 릴리즈 계획 수립(부분적 기능 완료) -> 스파이크 (간단하게 문제만을 해결) <떄려서 막아버려>-> 이터레이션 (릴리즈를 더 세분화)/중간에 스토리 추가 가능. -> 승인 검사 .부분 완성 -> 소규모 릴리즈 .
 
4. 시스템 분석- >시스템,아키택쳐,소프트웨어 등을 분석한다( 인적자원 이딴건 아니다 ) 
아키텍처 구성은 어떤 기술요소가 사용되었나 확인하는것. 데이터 종류등은 시스템 인터페이스 파악시 기술. 
 
5. 개발 기술 환경
운영체제란 컴퓨터 시스템의 자원을 효율적 관리 하게 돕는 소프트웨어
linux,windows 등등 
web application server was 는 tomcat,jbos 등등. jvm은 가상머신이지 서버가 아니다. 
 
6.요구사항 정의 
요구사항을 통해, 개발과 유지보수의 기준과 근거 제공. 이해관계자들 간 의사소통에 장점이 생긴다. 
기능요구사항, 비기능 요구사항이 있고, 데이터 , 성능 등은 비기능이고 실제로 시스템(시스템 관련은 다, 보안같은거 말고 )이 무엇을 하는지가 기능 요구사항이다. /+ 사용자 요구사항 , 시스템 요구사항도 있다 (개발자 관점의 시스템)
성능 ,보안 , 품질, "몇초안에"이런 조건은 다 비기능이다. 어떻게 수행되는지만 기능이다.
 
개발 프로세스는
도출 (시스템 개발된 사람들이 서로 요구사항이 어딨고 그걸 어떻게 식별할 것인가)-> 분석(그 결과 요구사항이 무엇인가) -> 명세 (모델 작성, 문서화) -> 확인(명세서 확인)이다. 
 
7. 요구사항 분석 
요구사항을 분석하고 명세화 하는 활동 
 
구조적 분석기법 -> DFD(DATA FLOW DIAGRAM)
자료의 흐름과 변환과정을 도형중심 기술 .
PROCESS는 O,흐름이 ->, 저장소가  =가운데에 글자넣기 , 단말이 공장이다. 

프로세스 , 자료 흐름, 자료 저장소, 단말(terminator)
 
DATA DICTIONARY -> 자료 흐름도의 자료를 자세히 정의 기록, 이렇게 데이터를 설명하는 데이터를 META DATA 
정의 =, 연결 +, 생략 (), 선택 [|], 반복 {}, 주석 *  *
반드시 출력이 있을 필요는 당연히 없다. 저장만 할수도 잇잖아. 
 
8. CASE는 요구사항 자동 분석 도구. HIPO는 시스템 분석, 문서화때 사용되는 실행과정을 나타냄. 
HIPO는 하향식 소프트웨어를 위한 도구 (HIGH IN PROCESS OUT ) 
SACASE -> SADT(구조적 분석도구 ) . SREM -> 명확히 기술 . PSL -> 미시간 자돟와도구 . TAGS->개발 전 과정 도구
 
9. UML ** 
-> 시스템 분석, 설계 , 구형등 개발 과정에서 고객과 개발자들간의 의사소통이 웧날하기 위한 객체지향모델링 언어. 
things,realationships,diagram. 

<<>>가 스트레오 타입 객체이다 
다중도 로써 relationships를 표현하는데, 1,n,1.* ->A1.* B 여기서 몇개가 연결되어 있는지 이다.
- 시 상호관계, ->시 일방적 관계이다. 집합 관계는 A <>-- B (B가 A의 부분집합이다) -> 컴퓨터와 모니터
색칠한 A<>--B 는 집합 중에서도 A가 B에 영향을 끼칠 수 있는 관계이다 ( 거의 몸에 달린 수준) -> 문과 KEY 
일반화 관계 -> 사람이 더 일반적인 개념, 여자 남자가 구체적인 개념. 일반 개념이 상위 혹은 부모이다 
하위에서 부모쪽으로 화살표를 잇는다. 

액터, 객체, 파이프라인, 메세지, 활성 상자 등이 있다. 
 
의존 관계 점선 화살표 . 짧은 시간만 영향을 끼친다. 영향력이 큰애가 A - - - - > B(영향을 받는애) A가 등급 B가 할인
실체화 관계. 의존 + 일반화관계 . 그룹을 만들때 사용된다. 
 
**DB랑 똑같이 화살표 받는애가 작은 개념이다. (실체화 , 일반화 뺴고 ) 
 
다이어 그램 . 
사물과 관계를 도형으로 표현했다. 
구조적 다이어그램 -> 클래스 다이어그램, 객체 다이어그램(인스턴스), 컴포넌트 다이어그램 (실제 모델) 배치 다이어그램(물리적 위치). 복합체구조 다이어그램 (복합 구조의 내부) , 패키지 다이어그램( 모델 요소들 패키지 관계). 
-> 자바 구조체들. 
 
행위 다이어그램 -> 유스케이스 다이어그램(사용자의 요구),순차다이어그램(상호작용SEQUENTAIL) -> 커뮤니케이션 다이어그램(메세지), 상태 다이어그램 (하나의 객채의 상태 변화에 따라 전개된다. ) (EVENT에 의해 객체가 전이된다)  , 활동 당이어그램 ( 시스템의 기능 수행 순서) , 상호작용 개요 다이어그램 (제어 흐름)
 
IOT는 THINGS가 아니라 기술이다. 
 
무엇을 하는가에 따른 비교. 
 
<<>> -> UML외의 추가기능 
 
10. UML중 중요부
유스케이스 다이어그램 -> 사용자 관점에서 사용자의 요구에 따른 표현 
시스템 (내, 외부 분리) . 
액터 -> 시스템과 상효작용 하는 모든 외부 요소. 유스케이스 -> 시스템이 엑터에게 제공하는 서비스
부엑터가 외부 컴퓨터, 주엑터가 실제 사람 
관계-> 연관,포함,확장, 일반화 (특별할떄만 적용되는 관게를 확장이라고함. , 포함은 두개에 포함되는 2개의 경우)
즉 특정 조건에 따라 확장되는 extends , 포함은 둘을 포함해서 새로운걸 만들때 include 
연동은 상호 동작이 영향을 끼치게 구성하는 것. 
 
클래스 다이어그램 (구조적)
클래스. 제약조건, 관게
class는 속성,오퍼레이션,이름(db처럼)
public + private -  protected # 
CLASS는 즉, 객체의 TYPE 일 뿐이다. 
 
순차 다이어그램 -> sequential로, 상호작용간의 적용
상호 작용하는 과정을 표현한다 
액터,객체, 생명선, 실행상자, 메세지, 회귀 메세지, 제어불록 .
동적임을 반드시 기억. 
 
11 사용자 인터페이스 UI *
시스템과 사용자 간의 원활한 상호작용 + 소프트웨어 간 연결 (자바를 생각해보라)
정보제공전달을 위한 제어, 콘텐츠의 상세적 표현, 모든사용자의 사용하게끔 기능
UI가 만족도에 가장 큰 영향을 미친다. 최소한의 노력으로 결과를 얻게끔 한다. 
 
구분 cli,gui,nui(NATURAL USER INTERFACE= 말이나 행동을 모두 포함한다,tap,drag,flick,press,pinch(넓히고 좁히기) 등등),VUI(음성),OUI(사물과 사용자 간의 상호작용)
직관성,유혀성,학습성,유연성(최대한 수용)
설계 지침시 사용자 중심적으로,사용성(사용하기 쉽게).최우선,일관성,단순성,결과예측가능, 가시성(주요기능 노출),심미성,표준화,접근성,명확성 등 
 
12 UI설계도구 
설계할떄 사용하는 도구 
 
뼈대를 설계하는 것은 와이어프레임
조금더 현실성 있는것은 mockup(mock=따라하다)/ 하지만 실제 기능이 구현되지는 않고, 화면만 유사하게 만든다.
스토리보드 이동까지 
프로토타입 = 실제 test 가능
Usecase -> 사용자의 요구사항을 파악.
 
13 품질 요구 사항
ISO/IEC 9126 표준을 따른다. 기능신뢰사용효율유지보수이식
 
25010 표준은
기능 적합성 성능효율성 호환성 사용성 신뢰성 보안성 유지보수성 이식성. 
 
-> 테스트 절차를 포함하여 12119등장
-> 나중 버전인만큼 개발자 구매자 평가자별 수행해야할 활동 규정한 14598 등장
 
 
 
 
 
 
 
1.기능성 -> 적절,적합성. 정밀성, 상호 운용성,  보안성(보안은 ERROR가아니다), 준수성
2. 신뢰성 -> 성숙성 , 고장허용성 ,회복성(ERROR)
3. 사용성 -> 이해성,학습성,운용성,친밀성. (나중에 다시 쓰고 싶은 정도)
4. 효유럿ㅇ -> 시간, 자원 5. 유지보수성 -> 분석변경안정시험 6->이식성 적용,설치,대체 ,공존
 
14 UI 상세설계 -> 기능이 아닌 사용자 테스크 주의 .
UI설계서를 바탕으로 자세한 설계. TREE나 FLOWCHART로 시나리오를 작성. -> 인터랙션 디자이너
키위치,기능,공통UI,스크린 레이아웃,인터렉션규칙,케이스문서 등.
시나리오 문서는, 상세하게 기술하는 완전성, 일관적인 일관성, 이해하기 쉬운 이해성, 읽기 쉬운 가독성, 수정추적 유이성이 필요하다. 
RADIO BUTTON -> 한개만  선택한다. CHECKBOX -> 여러개중 1개 이상 . TEXTBOX, COMBOBOX -> 저장된것중 1개 . LISTBOX -> 추가할수없는 저장된 것중 한개 .
기본적인 레이아웃을 Template라고 한다. 
 
15. HCI는 사람이 시스템을 편리하게 쓰게. UX는 그 경험(EXPERIENCE)
 
16 . 소프트웨어 아키텍처 ***
 
소프트웨어의 골격이 되는 기본구조  . ARCHITECTURE? 설계도 
아키텍처 설계, 예비 설계 . 모둘 설계, 상세 설계 .
모듈화 -> 모듈단위로 시스템의 기능을 나누어, 관리와 재사용이 용이하게
추상화 -> 전체의 포괄적인 개념을 설계하고, 상세 개념 설계 (과정데이터,제어 추상화가 있다)
단계적 분해 -> 하향식으로 상위 개념부터 하위 개념으로
정보 은닉 -> 정보를 접근하지 못하게 
품질 속성 -> 관리자가 요구하기 쉽게 시스템측면( 성능 변경 사 기 가 ),비지니스측명,아키텍처 측면으로 분할. 
 
아키텍처 설계과정
1. 설계 목표 설정 2. 시스템 타입 설정 3.아키텍처 패턴 적용 4. 서브 시스템 구체화 5. 검토
 
다른 사람들과 협약에 의해 설계 할때 , 선행 조건, 결과 조건, 불변 조건으로 나누어 명세해야한다. 
 
17. 아키텍처 패턴 
ARCHITECTURE를 설계할때 참조할 수 있는 예제나 해결 방식을 의미한다.
기본적인 구조 구성의 윤곽을 제시. -> 시간을 단축시킬 수 있고, 개발전 예측이 가능.
1. LAYER PATERN -> 각 시스템을 계층으로 구분하여 구성하는 고전 방식 (OSI참조)
2. CLINET-SERVER . 
3. PIPE - FILTER -> 데이터 송수신 절차인 데이터 스트림을 필터를 거르고 전송하게끔. 확장이 용이
(허나 필터를 건널때 오버헤드가 발생하곤 한다)
서브시스템이 데이터를 받아 처리하고 이를 다른 시스템에 보내는 것을 반복하는 것이다.
4. MODEL-VIEW CONTROLLER
MODEL-> 핵심 기능, VIEW ->정보 표현(MODELANDVIEW기억) , CONTROLLER -> 모델에게 명령 
 
MASTER-SLAVE 패턴, 브로커패턴,피어투피어,이벤트 - 버스 , 블랙보드, 인터프리터 등도 있다. 
 
18. 객체 지향 ***
현실세계의 객체를 부품처럼 하나의 객체로 만들어 , 각 객체를 조립해서 개발하자. 
 
객체 (OBJECT)란, 데이터와 함수를 묶어 놓은 소프트 웨어 
객체의 이름은 독립 식별적, 상태(STATE 변경) 객체간 연관성 형성 
객체가 할수있는 MESSAGE는 행위이다. 
 
CLass는 객체의 type을 의미한다고 볼 수 있따. 
각 객체의 속성과 연산을 정의(즉 객체들을 묶어 데이터 추상화한것)
 
캡술화
인터페이스를 제외한 세부내용 은폐 , 재사용도 용이
 
상속 -> 물려받기 / 다중 상속은 1개 class가 여러가지 한테 받기 (java는 안댐)
INHERITEANCE 
 
다형성 -> 오버로딩으로 다르게 , 오버라이딩으로 조상님 올라탑니다 . 
 
연관성 -> 두개 이상 class들이 상호 참조 
 
is member of (상호 연관), is instance of (동일한 특성) is part of (상위 객체 구성) is a -> 일반화 ,공통화 
 
19 객체 지향 분석 + 설계 **
 
1. 객체 지향 분석이란, 요구사항을 분석하여 객체와 연산들을 모델링하는것 
(ooa,object oriented analysis)
 
2. 럼바우 방법 -> 객체,동적, 기능으로 수행(각각 객체,sequential,dfd 사용)
(당연하게 객체부터, 그 이후 할일을, 그 이후 어떤 자료 흐름에 따른지)
booch -> 미시적과 거시적으로 
jacbson -> usecase 강조
coad, yourdon -> e-r을 사용
wirfs-brock -> 고객 명세서에서 설계까지 한번에 
 
럼바우 . 객체 모델링 , 동적 모델링, 기능 모델링 
객체를 찾아내어 속성과 연결, 상태 다이어그램을 사용해서 동적인 행위 모델링 dfd를 사용해서 자료 흐름 모델링 
 
객체 지향 원칙
1. 단일 책임 원칙 . 객체는 단 하나의 책임(역할)
2. 개방 폐쇄 원칙. 기존 코드를 변경하지 않고 기능을 추가할 수 있도록 설계 
3. 리스코프 치환 원칙 -> 자식은 부모가 하는일은 할줄 알아야 한다. (자식은 부모기능 + @)
**특히 리스코프가 헷갈림**
4. 인터페이스 분리 원칙 -> 인터페이스를 쓰지 않는애와 연관 x 
5. 의존 역전 원칙 -> 추상성이 높으애와 의존을 맺어야
 
20. 모듈 . 모듈화를 기억하지? 
모듈은 단독으로 컴파일이 가능하다. 결합도약하고 응집도는 강해야 좋은 모듈이다 
독립적인 기능의 단위
 
모듈이란, 모듈화를 통해 분리된 기능으로써, 작업단위, 서브루틴등으로 사용된다. 
컴포넌트란 기능의 최소단위
모듈이 패키지고, 컴포넌트가 CLASS가 되겠네. 
 
결합도 -> 모듈간의 연관관계 (Coupling)****
결합도 level
자료(Data) 결합도(모듈간 INTERFACE가 자료구조만 있을때, 그리고 이 INTERFACE를 쓸때) ->
스탬프결합도(모듈간이 매개변수로 자료 구조 전송, 동일한 자료구조 조회 )  ->
제어 결합도 (모듈이 내부 논리적 흐름 제어 . 모듈 a가 다른 모듈 b의 처리 절차를 알고있어 이를 통제)->
외부 결합도(모듈 선언 데이터의 변수를 다른 모델이 직접 참조) ->
공유 결합도(common) (공유되는 공통 데이터 영역을 여러모듈 사용) ->
내용 결합도(content)(내부 기능및 자료,내용을 직접 수정까지 가능)
<자료 결합도가 젤 좋은거임 ( 의존성주입 정도) >
 
쟈스 제외 공(혁준) 내외 
 
20 + 응집도 ****(Cohesion)
내부가 서로 관련되어 있는 정도
높을수록 좋다. 
정보은닉개념의 확장이다. 얼마나 독립적인가
 
우연적 응집도 (모델 내부가 관련 x)//거의 우연히 만난애들이 모듈안에 있네 ->
논리적 (유사 성격 ,형태) ->
시간적(temporal) (특정 시간에 처리 기능되는들을 모은 모듈) ->
절차적 응집도 (모듈안의 구성요소들이 기능을 순차적 수행(순서가 있다) ->
교환적 응집도(동일 기능)->
순차적(sequential) 응집도 (출력데이터를 그대로 사용)->(그래서 순차임). 
기능적 응집도(모듈 내부 기능 요소들이 다 한기능을 위하여) (Functional)
 
우(승민)논(넌)시(x) 절교 순(순히) 기(다려라)
<기능적 응집도가 젤 좋음>
 
Fan in -> (젤 위 class라서, 다른애들 생성때 호출된다  A->B시 b가 FANin ((일로와))직접 되는애만 샌다))
fanout-> 호출 받는수(화살표의 A->B시 , a가 FANOUT(호출됨))
fan in은 높게 , fanout은 적을수록 복잡도가 적다 
 
NS차트 . 연속, 반복등. 화살표표도 쓰지 않는 , 선택과 반복을 표현한다.
(논리의 기술에 중점)
<다시 복습하고 문제 풀자> 
 
21. 공통 모듈 
많은 프로그램에서 사용되는것
정확성. 명확성, 완전성, 일관성, 추적성
재사용 : 이미 개발된 기능 다시 사용
적용 단위 : 함수,객체.
컴포넌트 <실행 코드 기반 모듈, 인터페이스를 통해 통신한다> , 애플리케이션<공통 기능 애플리케이션>
 
3. 효과적인 모듈을 위해선 
결합도는 줄이고 응집도는 높인다 . 제어영역안에서 영향영역을 유지. 중복성,복잡도 줄인다. 
 
22. 코드 ****
컴퓨터를 이용해서 자료의 추출을 쉽게 
식별,분류,배열,표준화,간소화 등 <주민등럭번호, 학번등이 예ㅣㅅ다 >
 
코드의 종류순차코드 1234 . 블록코드 1000~11 (영업부) 1011, 10진코드 0~9까지 10진 분할 , 그룹 분류 코드 - 일정 기준에 따라 분류 , 연상 코드 TV-40. 표의 숫자 코드 120-720-1500(특징을 그대로), 합성코드 ke(대한항공)-711
 
코드 부여 체게는 상세구조 AAA-MOD-000 . 각 개체에 유일한 코드를 부여한다. PJC-COM-003처럼
 
23. 디자인 패턴
각 모듈의 세분화된 역할이나 코드 작성 수준 구현 방안 설계시 참조할 수 있는 해결 방식
 
아키택처 패턴은 디자인패턴보다 상위 수준의 설계 (전체 시스템의 구조) 
해당 방식은 구조파악에 도좋고, 생산성도 많이 오른다. 개발 시간과 비용이 절약된다. 
하지만 초기 투자 비용이 증가한다 .
 
생성 패턴은 5가지가 있다
1. 추상 팩토리 . 구체적인 CLASS에만 의존하는 것이 아니라, INTERFACE를 통해 서로 연관 의존 객체를 그룹으로 생성
(INTERFACE가추상이니까)
2. 빌더 - 작게 분리된 인스턴스를 건축하듯이 조합 . 
3. 팩토리 메소드 - 객체 생성을 서브 클래스에서 처리하게 캡슐화. (가상 생성자)
4. 프로토타입 - 원본복제 (프로토타입 제품처럼)
5. 싱글톤 - 하나의 객체를 어디서든 참조 가능. 
 
구조 패턴
어댑터 - 호환성 없는 INTERFACE를 이용할 수 있게 (아댑터), 인터페이스를 연동
브릿지 - 구현에서 추상층을 분리하여, 독립 확장 구현 
컴포지트 - 여러 객체를 가진 복합 객체로 단일 객체 구분 없이 다룬다 .(결합)
데코레이터- 능동적 기능 확장
퍼싸드 - 상위 인터페이스
플라이웨이트 - 메모리 아끼기
프록시 - 접근이 어려운 객체와 연결 객체 사이 인터페이스 역할
 
행위 패턴
OBSERVER
책임연쇄 = 요청 처리 객체가 2개 이상 , 다음 객체로 요청이 넘어감커맨드 - 요청 필요 정보를 저장하거나 로그에 남긴다. 인터프리터 - 언어에 표현 정의중재자 - 수많은 객체간의 상호작용캡슐화 . 의존성 감소 . 메멘토 - 특정 시점 내부 객체화 옵서버 - 상태 변화시 객체 상속된 다른 객체 변화 상태 전달상태 -상태에 따라 동일한 동작 다르게 전략 - 개별적 캡슐화 탬플릿 메소드 - 상위 클래스에서는 알고리즘을 , 나머진 하위에서 . 방문자 - 데이터 구조에서 처리만을 별도로 . 
 
<후에 복습하자>< 생성, 구조, 행위를 분리하자><아 이거 어디패턴에 뭐인지가 진짜 헷갈린다>
 
24. 시스템 인터페이스 요구사항요구사항,고유번호,명칭,상세설명,산출정보,관련요구사항,출처 요구사항 선별,자료준비 , 분류, 분석 , 명세서 공유 
 
25.인터페이스 요구사항 검증
실제 설계 전에 요구사항이 잘 기술되었는지 검토. 
 
검토 계획은 -> 검토 기준 및 방법, 참여자 , 체크리스트, 관련자료, 일정. 
요구사항 베이스라인 설정 . 
요구사항 검증한다. 그 방식은
1. 동료가 해주는 동료검토 2. 명세서를 이미 배포한 후 회의 워크스루. 3. 인스펙션 (검토전문가들에게 요청)
주요 항목 - 완전성,일관성,명확성,기능성,검증가능성,추적 가능성 등.
 
인터페이스 방법 명세화 )확실하게 문서화)시스템 연계기술 API,OEPN API. 연계 솔루션, SOCKET 할당 ,WEB SERVICE. 인터페이스 통신 . 단방향,동기,비동기 처리 유형. 실시간 ,지연처리 ,배치 방식. 송 - 수신 방법 명세화 . 송 - 수신 데이터 명세화 . 오류 식별, 처리방안 명세화 배치는 대량 데이터인거 알지?
 
27 미들웨어 솔루션 명세
미들웨어란 미들 소프트웨어
서버, 클라이언트 사이에서 원만한 통신이 이루어지게 서비스 제공
 
1. db client -db -dbms
2. RPC - 원격 프로시저 호출 (작업을 정의한 절차) 
3. MOM - 메세지 기반 미들웨어 - 느리고 안정적 응답(NOT MESSAGe)
4. TP - MONITOR (트랜잭션 처리)
5. ORB - 객체 요청 브로커.
6. WAS - 동적 컨텐츠 처리 . (즉시 각각 요구에 따라 처리한다)
 
미들웨어 솔루션 식별 - 미들웨어 솔루션을 확인하고, 목록을 작성.
 
이들로 명세서를 작성한다. 
동기는 동시에, 비동기는 동시에는 사용되지 X

GOF-> 생성 구조 행위  
싱글톤 ㅡ 하나의 객체 생성시 어디서든 쓰일수잇지만 동시는 안됨

 

SOLID

SINGLE RESPONSIBILITY,

OCP (OPEN CLOSED)LSP (리스코프 치환) -> W자식은 부모를 다 할줄 알아야된다.

ISP (인터페이스 분리)