Architectural design
1. Vision system 어떤 건지 보고
2. object identification 어떤 것인지 나눈다 (유리인지 나무인지 등)
3. packing selection system 에서 2 에서 분류한것에 맞게 결정한다음 packing system 에서 Arm 과 gripper 을 통해서 패킹한다
4. conveyor controller 배송을 위해 옮겨지는것
명시적 아키텍쳐의 장점
stakeholder communication
이해 당사자관의 의사소통이 원활하게 된다.
system analysis (시스템 분석)
아키텍쳐를 만들며, 분석을 하며, non functional 요구사항에 대해서 만족할 수 있는 결과가 이루어진다.
large scale reuse
어떤 컴포넌트 들로 구성이 되어 있는지 보이기 때문에 넓게 보고 재사용 할 수 있는 것을 크게 잡아 낼 수 있다.
architectural design decisions
아키텍쳐 디자인은 창의적인 과정이므로 개발 시스템 유형에 따라 다를 수 있다. 즉 고정되어있는 해답은 없다.
그럼에도 불구하고 공통적으로 결정되어야 할 것들이 있는데,
1. 일반적인 application 아키텍쳐 참고할만한 자료들이 있나?
2. 구조화하기 위하여 결정될 기본적인 접근법
3. 시스템 구조를 이룰 컴포넌트들이 어떻게 서브 컨포넌트로 나뉠 수 있는지.
4. non functional req를 만족시키기 위해 가장 적합한 아키텍쳐가 무엇인지?
5. 시스템 아키텍쳐가 어떻게 문서화 되어야 하는가
6. 시스템 컴포넌트 동작을 제어하기 위한 전략
7. 어떤 아키텍쳐 패턴 이나 스타일이 사용될까?
8. 코어나 프로세스 (하드웨어)안에서 어느 식으로 분산되어 있는가?
시스템 특성에 따른 아키텍쳐 디자인들
Performence 중시:
퍼포먼스가 중요하다면, 컴포넌트들을 작게 만들지 않고 크게 만든다. 그를 통해 통신을 줄인다.
Security 중시:
중요한 정보의 계층을 만들어 아래쪽에 그것을 배치하게 된다 그래서 접근하기 위해 여러개의 인증을 거치게 만든다.
Safety 중시:
안전한 기능을 뽑아서 작은 subsystem 에 localize 한다.
Availability 중시:
중지되면 안되므로 redundant (중복 컴포넌트)를 만들어 중지에 대비한다.
Maintainability 중시(유지 보수성):
유지보수성이 중요한 컴포넌트를 작게 만들어서 이것들이 바뀌는 경우 빨리 적용 가능하게 한다 (use fine grain)
아키택쳐를 보는 관점 (4+1)
시점마다 중요한게 다르므로 여러개의 관점이 중시되어야 한다.
대표적으로 4가지로 제안되어있는데,
Logical view 논리적인 시점
어떤 object 와 어떤 클래스로 구성이 되어있는지
Development view 개발할때 시점
개발을 위해 어떻게 분해될 수 있는지, 어떤 모듈로 구성될 수 있는지
Process view 프로세스 시점
run time 일때 프로세스들이 어떻게 상호작용하는지 보여주는것
Physical view 시스템이 어떻게 물리적으로 분산되어 있는가
시스템 하드웨어와 소프트웨어 , 컴포넌트가 어떻게 분산될 수 있는지 보여주는 물리적 뷰
이와 관련된 use case 와 시나리오 뷰 (+1)
Architectural petterns
MVC pettern
model 컴포넌트: 시스템 데이터와 데이터에 대한 operation을 관리한다.
view 컴포넌트: 사용자에게 데이터가 어떻게 표현되는지 관리한다.
controller 컴포넌트: 사용자 상호작용을 관리하고 이를 view 와 model 에 전달하는것을 관리한다.
가장 대표적인 적합한 예로는, web base 애플리케이션에 적합하고,
데이터를 보여주는, 상호작용하는 방법이 여러가지 일 때 자주 사용되고, 추후 요구사항을 알 수 없을때도 자주 이용된다
장점: 데이터 표현과 무관하게, 데이터를 변경할 수 있게 해 준다. 즉 데이터 내용과 상관없이 model view 등에 맞게 복제할 수 있다.
단점: 아주 단순한 모델일때 굳이 이것을 사용하면 괜히 복잡하다.
Controller 가 사용자 동작을 model 에 매핑시키고 view 를 선택하며,
model 은 애플리케이션 상태를 변경을 알려줄 수 있다.
view 는 이 모델에서 변경된것을 표현이 된다. 그리고 사용자 action 을 controller 에 보여주기도 한다.
Layered architecture (계층구조 아키텍쳐)
설명:
시스템을 계층들로 구성하여 각계층별로 해당하는 일을 하고,
가 핵심 서비스를 나타내거나,OS 나 DB 같은 중요 데이터들이 아래계층에 나타난다.
예:
디지털 학습 시스템을 계층 모델로 보여 줄 수 있다 아래 그림 참고.
언제 주로 사용:
개발을 여러 팀으로 나누어서 할 때, 다중 보안 구조가 필요할 때 주로 사용된다.
장점:
인터페이스가 유지 되면 전체 계층이 대체가능하다.(=중복된 기능이 각 기능에 제공될 수 있다)
단점:
현실적으로 계층을 명확하게 구별하기가 어렵다. 상호작용이 칼같이 구별하기도 힘들수 있고
그로 인해 성능에 좋지 않을 수도 있다.
실제 계층 구조의 예
인터페이스
인터페이스 관리 (인증 등)
코어 비즈니스 로직
os, db
Repository architecture
설명:
저장소 위주로 데이터를 어떻게 공유하는지 적는 아키텍쳐로,
access 권한을 중앙저장소에 두고 서로 서로의 레퍼지토리끼리 상호작용하지 않게 둔다.
즉, 다이렉트로만 접근할 수 있게 한다는것
예시:ide 개발을 할때 많이 이용이 되며
언제 사용이 되냐:
장기간 저장되어있는 대량의 정보를 생성하고 저장할 필요가 있을 때 사용이 된다. 데이터 위주 시스템일때 자주 사용
장점:
각 컴포던트는 independent 즉 독립적이라 다른 컴포넌트들이 어떻게 생겼는지 알 필요가 없다.
그리고 중앙 데이터를 업데이트시키면 일괄적으로 변경된다.
단점:
중요한것을 한곳에 다 넣었기 때문에 중앙이 문제가 생기면 모두 문제가 생기고, 저장소를 분산하기 어렵다.
IDE 예시
Client-server pattern
설명:
시스템이 각 서비스에 독립적인 서버를 제공하는 시스템의 집합으로 정의가 된다.
예:
비디오/DVD 라이브러리 앱 (넷플릭스) 등에서 많이 사용된다
언제 사용되나:
공유 저장소에 있는데이터를 여러지역에서 사용할 때, 다양한 시스템, 부하가 클 때 자주 사용
장점:
굉장히 많은 사용자가 여러곳에서 동시에 사용가능 할 수 있게 된다.
단점:
중간에 저장소에 에러가 나면 모두가 사용할 수 없게된다. 해커들이 하나에만 공격하면 다 망가질 수 있다.
Pipe and filter architecture
설명:
시스템에서 데이터 처리 컴포넌트가 정의되어 있으며, 한 컴포넌트에서 다른 컴포넌트로 데이터가 이동하게 되는 것을 나타내는 패턴
예: 결제 시스템에
언제 사용되는가:
데이터 프로세싱, tracsaction base 시스템에서 자주 사용된다
장점:
입력 출력이 확연하기 때문에 이해하기 쉽고, 변환에 잘 적응이 된다.
단점:
입력 -> 출력 -> 약속된입력 이기 때문에 독립적이지 못하고 전에 입력한것에 맞게 되어야 한다.
application arcitectures
요구사항 충족과 관련있는 아키텍쳐
아키택쳐 디자인 스타트 포인트
디자인 체크리스트
개발 팀의 작업을 나눌 때 사용할 수 있고
각각의 컴포넌트 배정
재사용 평가에서도 쓸 수 있다.
Data processing applications
데이터 처리 애플리케이션은 처리중에 개입 없이 일괄 처리 하는것
tracsaction processing
유저 요청에 따라 시스템 데이터베이스 내용을 업데이트 하는 디비중심
DB 정보에 대한 사용자 요청을 처리하게 되는데 사용자 관점에 대한 것을 찾아주는 것
비 동기적 요청으로 처리를 할 때가 있는데 atm에서 돈을 뺄때 입출력은 기계로 하는것이고 잔액 등은 은행 데이터의 일부가 되는 것이다.
event processing
시스템 환경 이벤트 해석에 의존하는 것
language processing
자연어 , 컴퓨터 언어 등으로 하는데, 예를들어 컴파일러 들이 하는 컴퓨터 언어 - 기계어 번역과정들이 랭귀지 프로세싱이다.
