POSA1 LAYERS

1. POSA1 LAYERS JAVAJIGI SW STUDY - 방수상

2. Layers Architecture Pattern • Layers 아키텍처 패턴은 애플리케이션을 구조화하기 위해 서브태스크들을 그룹으로 묶어 분해한다. • 네트워크 프로토콜 • 비트전송에서부터 상위레벨 애플리케이션 로직에 이르기짜기 다양한 추상 레벨에 해당하는 규약을 준수 • OSI 7 Layer Model

3. exmaple - OSI 7 layer model 응용(Application) 공통 동작을 위해 다양한 프로토콜을 제공한다. 프리젠테이션(Presentation) 정보를 구조화하고 의미를 추가한다. 세션(Session) 대화 제어와 동기화 기능을 제공한다. 전송(Transport) 메세지를 패킷으로 쪼개고 신뢰성있는 전송을 제공한다. 네트워크(Network) 송신자로부터 수신자까지의 경로를 선별한다. 데이터링크(Data Link) 비트 시퀀스에서 오류를 탐지해 정정한다. 물리(Physical) 비트코드,연결,전송속도 등으로 비트를 전송한다.

4. example - 모톨리식블록 • 단일 형태의 모놀리식 블록 • 단일 형태의 거대한 모델 • 시스템 호출에 통해 제공하는 거대한 객체에 비유 (모놀리식 커널) • 계층구조를 가지고 있지만 새로운 하드웨어 플랫폼에 대한 이식의 유연성이 적다.

5. example • 레이어 형태로 구현하는 방식 • 개념적으로 서로 다른 이슈를 따로 구현할 때에 더 많은 혜택을 얻음 • 팀을 이루어 각 레이어를 따로 개발할때 • 코드와 테스트를 점진적으로 추가시킬때 • 레이어 형태로 독립적인 부분들을 사용함으로써 변경하기가 용이 • 새로운 언어나 알고리즘처럼 더 나은 구현기술이 등장할 경우 코드의 일부분만 수정하고 통합하는게 가능 • TCP/IP 네트워크 프로토콜 • 개별 레이어들을 재사용 • TELNET, FTP 같은 다양한 분산 애플리케이션을 그대로 사용

6. context • 시스템의 규모가 커서 분해(decomposition)할 필요가 있다.

7. problem – lowlevel hightleve • 하위레벨과 상위레벨의 이슈 혼재 • 상위레벨 오퍼레이션(연산,동작)이 하위레벨 오퍼레이션에 의존 • 비트나 전자신호를 읽어서 하드웨어 트램, 센서 입력과 같은 하위레벨 이슈 처리 • 반대편 끝에는 MUD게임의 인터페이스와 같은 사용자 가시 기능이나 ㅈㄴ화 요금제와 같은 상위 레벨 정책 • 위와 같은 상황의 통신흐름 • 상위에서 하위로 이동하는 요청 • 하위에서 상위로 이동하는 요청에 대한 응답이나 이벤트

8. problem • 레이어들에 따라 수직적으로 기능이 나뉨 • 수평적 오퍼레이션들이 구조화됨 • 각 레이어들마다 여러 기능 수행 가능 • 시스템의 몇몇 외부 경계는 시스템이 연결해야 하는 기능적 인터페이스처럼 사전에 지정. • 플랫폼에서 제공 서비스 형태로 구현하는 것이 힘들기 때문에 상위 레벨 태스크들 매핑 작업이 어려움.

9. problem - force(영향력) • 소스코드 변경이 시스템 전체에 문제를 일으켜서는 안됨. 하나의 컴포넌트만 영향 • 인터페이스는 안정성을 가추며, 표준 구현부에 미리 지정 • 시스템의 각 부분들은 교환가능해야 함. 하위 플랫폼(운영체제,하드웨어 등)이 변경될 수 있음. • 현재 설계 시스템의 하위레벨 이슈로 인한 다른 시스템을 구축해야 할 필요성이 생길수 있음. • 인식성과 유지보수성을 위해 유사한 책임들을 모아 그룹으로 묶어두지만 각 컴포넌트는 이슈 하나만을 담당(그룹화와 일관성은 항상 상충) • 컴포넌트의 크기나 규모에 대해서는 표준을 정하지 않음. • 복잡한 컴포넌트일수록 분해해야할 필요성이 있음 • 컴포넌트 경계를 넘다들수록 성능하락. • ex : 많은 양의 데이타가 많은 컴포너틑 경계를 넘나들경우.

10. solution • 시스템을 적절한 개수의 레이어들로 구조화 하고 각 레이어들을 차곡차곡 쌓는다. Layer N Layer N Layer N-1 Layer N-1 .... .... Layer J+1 Layer J+1 Layer J Layer J .... .... Layer 1 Layer 1

11. structure 클라이언트 사용함 Layer N 클래스 Layer J 최상위 협력자 Layer J-1 Layer N-1 책임 Layer J+1에 의해 사용되는 서비스를 제공한다. Layer J-1에 서브태스크를 위임한다. Layer 1 최하위

12. structure Component 3.1 Component 3.1 Component 3.1 Layer 3 Component 2.1 Component 2.1 Component 2.1 사용함 Layer 2 Component 1.1 Component 1.1 Component 1.1 Layer 1

13. dynamic – 시나리오1 • 하향식 통신은 Layer J가 Layer J+1 • 로부터 받은 하나의 요청을 Layer J-1 • 에게 여러 개의 요청들로 분리될 수 • 있다. 클라이언트 Layer N 요청 Layer N-1 Layer J+1 Layer J Layer 1

14. dynamic – 시나리오2 • 상향식 통신 • 상향식정보및제어흐름은 통지(Notification)라고 칭함 • 여러 개의 상향식통지는 해당 구조의 상위 레이어에서 단 한 개의 통지로 모아지거나 1:1관계로 유지 Layer N Layer N-1 Layer 2 장치드라이버 Layer 1 입력

15. dynamic – 시나리오3 Layer N • N-1에서 해결가능 • N-1이 캐시역할 • 상태정보(state information)을 유지 Layer N-1 Layer 2 Layer 1

16. dynamic – 시나리오4 • Later N으로 끝까지 전달되지 않고 Layer 3에서 이벤트가 멈추는 경우. • 통신프로토콜의 겨우 서버에서 클라이언트 요청을 처리할때 똑같은 요청이 클라이언트로 부터 받을겨우 Layer 3에서 이것을 알아채고 어떤 처리도 일어나지 않도록 재전송요청을 중간에서 가로챔(intercept) 클라이언트 요청 Layer1 (서버) Layer 2 • intercept Layer 3 Layer N

17. dynamic – 시나리오5 Layer N Layer N Layer N-1 Layer N-1 Layer 1 Layer 1 • N개의 레이어로 이루어진 스택이 두 개로 이루어져 있으며 두 스택이 서로 통신할 수 있는 경우 • 프로토콜 스택

18. implementation • 레이어로 이루어진 아키텍처를 정의하기 위한 단계별 개선방식 서술 • 일반적으로 상향식방식이나 요요방식을 선호 • 어플리케이션의 종류에 따라 구현해야 할 단계들이 달라질 수 있다.

19. implementation – 1단계 • 태스크를 레이어로 묶는 추상기준정의 • 플랫폼으로부터의 개념적 거리로 삼는 경우가 많다. • 특정 도메인에 맞게 변형된정도 • 복잡한 정도에 따른 추상 패러다임 사용 • 비숍과 같은 체스게임의 기본요소 • 캐슬링과 같은 체스 말들의 기본이동 • 시칠리아식 방어와 같은 전술 • 게임전체전략 • 미식축구 : 라인배커,속공, 2분간공경, 전체게임계획

20. implementation – 1단계 • 실무에서는 추상기준을 혼합하여 사용 • 하드웨어로부터의 거리는 좀 더 하위레벨의 형태 묘사에 사용 • 기념적 복잡성은 좀 더 상위 레벨의 형태 묘사에 사용 • 혼합된 원칙에 따라 레이어 적용 • 사용자를 위한 시각적 요소 • 특수하게 지정된 애플리케이션 모듈 • 공통서비스레벨 • 운영체제 인터페이스 레벨 • 운영체제(그 자체가 레이어로 이루어진 시스템이거나 Microkernel 패턴을 적용해 구축한 시스템) • 하드웨어

21. implementation – 2단계 • 추상기준에 따라 얼마나 많은 추상 레벨로 나눌지 결정 • 각 추상 레벨은 Layer 패턴으로 구분한 레이어 하나에 해당 • 특정 측면을 두 레이어로 나눌 것인지 여러 측면을 한 레이어로 결합할 것인지 결정해야 하는 경우 트레이드오프 고려 • 트레이드오프 : 어느한쪽을 위해 다른쪽을 희생시키는것 • 너무 많은 레이어는 오버헤드를 발생시키고 너무 적은 레이어는 조작한 구조를 낳게 된다

22. implementation – 3단계 • 레이어마다 역할을 부여하고 각 레이어에 태스크를 할당 • 최상위 레이어의 태스크는 클라이언트에 의해 감지되는 전체 시스템 태스크에 해당 • 상위 레이어 입장에서 다른 레이어 태스크는 보조역할 • 상향식방식채택 • 하위 레이어는 상위 레이어에 대한 인프라제공 • 상위 레이어에서 잔달되는 요청이 정의되기전에 하위 레이어에 대한 추상을 정확히 파악해야 한다 • 해당 도메인에 대한 상당한 경험과 통찰력필요

23. implementation – 4단계 • 서비스를 상세히 정의 • Layers pattern 구현시 레이어들을 서로 엄밀히 구분해야 한다 • 모든 컴포넌트는 하나의 레이어 범위에서 벗어나지 않아야 한다 • Layer J가 제공하는 함수의 인수 타입, 반환 타입, 오류 타입은 프로그래밍 언어에 이미 정의되이 있는 타입이어야 한다 • 레이어들간의 공유모듈을 두는 것은 레이어 구분의 원칙을 완화시킨다 • 하위 레이어보다 상위 레이어에 서비스를 많이 둔다. • 개발자는 하위 레벨 프리미티브들을 익히지 않음 • 개발이 진행되는 동안 변경사항발생 • 기반 레이어는 가볍게유지, 상위레이어는 광범위한 적용성 확보 • 재사용의 역 피라미드구조

24. implementation – 5단계 • 레이어에 대한 정의를 개선 • 1단계부터 4단계까지의 과정을 반복 • 어떤 레이어들로 구성하고 어떤 서비스를 지정할 것인지 심사숙고해서 추상 기준을 정의해야 한다 • 레이어에 대한 정의가 자연스럽고 안정적으로 개선될때까지 1단계에서 4단계까지 여러차례수행해야 한다 • 요요개발 : 하향식과 상향식 단계를 번갈아 수행하는 작업

25. implementation – 6단계 • 각 레이어마다 인터페이스 하나씩을 정의 • Layer J가 Layer J+1에 대해 블랙박스 역할 • 모든 Layer J의 서비스를 제공하는 플랫 인터페이스를 설계 • 화이트박스 : Layer J+1이 Layer J의 내부를 볼 수 있도록 해준다 • 그레이박스 : 블랙박스와 화이트박스를 절충 • 가능하면 블랙박스 방식을 사용 • 시스템을 발전시켜 나가는 데 한결 유리함 • 다른 레이어의 내부에 액세스하는 경우 Reflection 패턴을 사용

26. implementation – 7단계 • 개별 레이어를 구조화 • 전통적으로 레이어들 간에 적합한 관계 안배에만 관심을 둠 • 특정 레이어가 너무 복잡할 경우 독립된 컴포너트들로 나누어야 함 • Bridge 패턴 적용시 특정 레이어가 제공하는 서비스를 다중으로 구현 가능 • Strategy 패턴을 적용하면 특정 레이어가 사용하는 알고리즘을 동적으로 교환

27. implementation – 8단계 • 인접한 레이어들 간의 통신 방식 정의 • 푸시 모델(push model) • 레이어 간 통신을 위해 가장 흔히 사용되는 매커니즘 • Layer J가 Layer J-1의 서비스를 호출할 때, 필요한 모든 정보를 서비스 호출(Lyaer J)의 일부분으로 넘기는 방식 • 풀 모델(pull model) • 하위 레이어가 스스로 필요에 따라 상위 레이어로부터 유효한 정보를 가져오는 방식 • 상위 레이어에 대한 하위 레이어의 종속성을 피하기 위해서는 콜백을 사용

28. implementation – 9단계 • 인접한 레이어들을 서로 분리 • 분리방법 : 하향식통신(단방향), 상향식통신 • 하향식통신 (단방향 결합) • Layer J에서 변경사항이 발생하면 Layer J+1의 존재와 신원을 판별하지 못함. • 반환값은 역방향으로 결과를 전송하기에 충분 • 상향식통신 • 콜백사용시 단방향 종속성 유지 • 하위 레이어로부터 상위 레이어로 전달되는 이벤트들이 확실히 정해져 있는 경우에만 효과발휘 • Reactor 패턴 : 이벤트 역다중화를 적용해 콜백을 사용하는 개체지향 구현방법 설명 • Command 패턴 : 볼백함수를 최상위 개체로 캡슐화하는 방법

29. implementation – 9단계 • 상향식통신 레지스트리 이벤트 콜백함수매핑정보 Layer J+1 호출된 함수정보 이벤트발생 Layer J

30. implementation – 10단계 • 오류 핸들링 전략을 설계 • 레이어로 이루어진 아키텍처에서 오류 핸들링을 구현하기 위해 더 많은 비용발생 • 상위 레이러로 오류를 넘기는 경우, 하위 레이어는 상위 레이어에서 이해할 수 있도록 오류서술로 변환

31. Example resolved – TCP/IP • 가장 널리 사용되는 통신 프로토콜 • OSI 모델을 엄격하게 따르지 않음 FTP 프로토콜 FTP FTP TCP 프로토콜 TCP TCP IP 프로토콜 TIP TIP ETHERNET 프로토콜 Ethernet Ethernet 물리적 연결

32. Example resolved – TCP/IP • 가상 프로토콜을 사용해 피어투피어방식으로 통신 • 두 TCP 엔티티가 특정 포멧에 맞춰 서로에게 메시지를 전송 • 가상 프로토콜 : TCP 메시지는 실제로 왼쪽에 있는 IP 엔티티에 의해 우선처리 • 기능적 인터페이스를 표준화하는 작업이 중요하지 않음 • TCP/IP 구현물은 명확히 정의된 핵심 기능만 제시

33. VARIANT • 완화된 레이어 시스템 • 레이어들 간의 관계에 대한 제약을 느슨하게 완화 • 하위의 모든 레이어의 서비스를 사용 • 유지보수성을 포기하고 유연성과 성능을 확보 • 확보하는 이득에 비해 과다비용지불 • 충분한 심사숙고필요

34. VARIANT • 상속을 통한 레이어 구성 • 하위 레이어는 기본 클래스로 구현 • 기본클래스(하위레이어)의 서비스에 요청을 보낼 수 있음 • 상위 레이어가 필요에 따라 하위 레이어의 서비스를 수정가능

35. known use – 가상머신(VM) • 하위 레벨의 다양한 운영체제나 하드웨어로부터 상위 레벨을 격리시키는 역할 • 자바가상머신(JVM) • 바이너리 코드 포맷정의 • 자바로 작성된 코드는 바이트코드로 변환 • 변환된 바이너리코드는 JVM에 의해 해석 • JVM에 특정 플랫폼에 종속 • JVM으로 인해 플랫폼에 중립적인 소스코드가 가능

36. known use – API • Application programming interface • 사용 빈도가 높은 기능을 갖추 하위 레이어들을 캡슐화한 레이어 • 유닉스 시스템 호출처럼 함수 명세의 플랫 컬렉션 • 플랫(flat) : 파일시스템 액세스와 저장소 할당을 위한 호출은 분리되지 않는다. • open(), sbrk(), printf(), fopen()

37. known use – IS(information system) • 과거 비즈니스 소프트웨어 도메인에서 사용하는 IS는 2-레이어 아키텍처사용 • 메인프레임상호작용 • CS시스템 • 인터페이스와 데이타가 긴밀하게 결합되어 있어 서로 영향을 미침 클라이언트 프레젠테이션 애플리케이션로직 서버 도메인 레이어 데이터베이스 • 도메인 레이어를 두어 개념적 구조를 모델링 • 사용자인터페이스(프레젠테이션)과 애플리케이션로직을 분리

38. known use – 윈도우 NT • Microkernel 패턴을 적용 • NT 실행 컴포너트는 완화된 레이어 시스템에 해당 • 시스템 서비스 • 서비시스템가NT 실행 컴포너트 간의 인터페이스 레이어 • 리소스관리(resource management) 레이어 • 객체관리자, 보안참조모니터, 프로세스관리자, I/O관리자, 가상메모리 관리자, 로컬프로시저호출로 구성 • 커널 • 인터럽트 핸들린 등의 기본기능을 관할 • HAL(Hardware Abstraction Layer) • 머신들간에 하드웨어의 차이를 숨김 • 하드웨어

39. consequence - 장점 • 레이어를 재사용할 수 있다. • 잘정리된 레이어는 여러 상황에서 재사용 • 레이어를 새로 만들경우 비용이 많이 들수 있다 • 기존에 있던 레이어를 블랙박스 형태로 재사용할 경우 개발에 드는 노력과 결함이 줄어들 수 있다 • 표준을 지원한다 • 종속성을 국지적으로 최소화한다 • dependency 최소화 • 하드웨어,운영체제,윈도우시스템등이 변경될 경우 오직 레이어 하나에만 영향을 미치기 때문에 다른 레이어의 수정이 필요 없다. • 교환가능성이 확보된다 • 과다한 노력없이 의미적으로 동등한 구현물로 대체 • Adapter 패턴 : 오래된 구현물을 다른 인터페이스를 사용한 구현물로 대치 • Bridge 패턴 : 런타임에 포인터를 조작 • 하드웨어를 교환하거나 추가하는 상황

40. consequence - 단점 • 동작이 변경될 경우 단계별로 재작업이 필요하다 • 효율이 낮다 • 불필요한 작업이 수행될 수 있다 • 레이어의 적절한 개수나 규모를 결정하는 것이 어렵다

41. see also • Composite Message 패턴 • Microkernel 아키텍처 패턴 • Presentation-Abstraction-Control 아키텍처패턴