소프트웨어 공학 (8), Architectural Design

Architectural Design

 

1. Architectural Design

앞서 정의한 시스템을 큰 틀에서 디자인 하는 것

---

0) 개요

- 성취하고자 하는 기능과 성능을 비롯해 보안, 신뢰성, 유지보수 가능성 등의 비기술적인 부분에 대한 뼈대를 결정하는 것

- 요구사항 엔지니어링의 다음 단계로 세부적인 사항을 디자인하기 이전 단계에 해당한다. 따라서 어떤 구성요소가 들어가는지, 구성요소들 간의 관계를 디자인하는 작업이 주 작업이 된다.

- 시스템을 구성하는 구성요소와 구성요소간 상호작용이 정형화된 문서나 포맷의 결과물로 도출되어야한다.

- 큰 틀을 디자인하는 것이기에 Agile 기법에서도 아키텍쳐에 대한 디자인은 중요하다.

- 아키텍쳐를 잘못 만들면 incremental이 어려울 수 있다. 이를 실패하면 소프트웨어를 전체적으로 개선해야할수도 있다. 이때 소프트웨어의 전체적인 구조를 바꾸는 리팩토링을 진행해야한다.

- 기능적, 비기능적인 부분도 모두 잘 정의해야함

 

1) 로봇 제어 시스템의 아키텍쳐 예시

- 카메라를 통해 인식하는 비전 시스템과 객체 판별 시스템이 필요하고 이를 통해 팔을 움직여 무언가를 잡는 제어 장치가 필요하다. 이후 패킹을 진행하고 이를 옮기는 것으로 시스템이 구성되어있다.

- 소프트웨어 엔지니어링 측면에서는 아키텍쳐 디자인에서 따라야할 엄격한 규칙은 없다고 생각할 수 있음

 

2) Archutectural abstraction

시스템의 규모에 따라 두 가지 형태로 디자인이 진행될 수 있음

---

(1) 시스템의 크기가 작은 경우

- 실행파일이 적은 개수가 될 것이기에 적은 개수의 구성요소가 이뤄질 수 있고, 이들의 상호관계를 정의하는 것이 고려대상

 

(2) 시스템의 크기가 큰 경우

- 회사 내에 있는 프로그램이나 시스템 간의 상호작용도 고려해야한다.

- 시스템은 네트워크로 연결되어있는 장치들에도 분산 배치되어야한다.

 

 

3) Architecture의 장점

(1) Stakeholder communication

- 이해관계자와의 커뮤니케이션

(2) System analysis

- 비기능적인 시스템 분석을 할 때 도움을 줄 수 있다.

ex) 물리적으로 떨어져있는 경우 통신에 따른 전송 속도 및 보안, 신뢰성 등에 대한 요구사항에 적합한지 검증할 수 있음

(3) Large-scale reuse

- 우리가 만들고자하는 소프트웨어가 이전에 존재한 소프트웨어와 유사한 경우에는 기 소프트웨어 아키텍쳐와 구성요소 및 요구사항 등을 재사용할 수 있다.

- 디자인에서도 코드의 재사용을 언급하기 시작한 것을 확인할 수 있다.

 

 

4) Architectural representations

- 간단하고 정형화되지 않은 블럭 도표를 통해 아키텍쳐를 표현할 수 있는데 합리적으로 모두가 동의할만한 부분에 대해서 정의하고 이를 디테일하게 정의할 필요는 없다.

- 그림을 매우 추상적으로 그리고 필요한 부분에 대해서만 본인이 충분하다고 생각이 들 정도로만 작성하면 된다.

- 개발을 본격적으로 진행하기 위한 프로젝트 플래닝이 본격적으로 진행된다. 즉 서브 시스템 개발에 대한 기간, 인터페이스 정의, 인력 배치, 재사용가능한 소프트웨어를 분석하고 가져오는 등의 과정을 아키텍쳐 디자인을 통해 진행된다.

 

- 현 시스템의 상황을 분석하기 위해 이미 만들어진 시스템을 설명하기 위한 목적으로도 아키텍쳐 디자인이 만들어질 수 있다. 이는 모델링의 관점과 유사한 것을 알 수 있다.

 

---

 

2. Architectural Design Decisions

소프트웨어 시스템 내부에 있는 클래스 객체가 어떤 식으로 구성되는지에 대한 결정

---

소프트웨어의 큰 그림을 그릴 때 어떤 결정을 내려야하는가? 정형화된 규칙이 없기에 본인의 소프트웨어에 따라 달라질 수 있다. 다만 오랜 기간동안 소프트웨어를 개발해왔기 때문에 다양한 목적에 대한 소프트웨어 개발 방법 등에 대해 공유가 되어오고 있다. 이에 따라 대부분의 개발하고자하는 소프트웨어는 개발 경험이나 사례들을 참조할 수 있다.

 

1) 디자인을 결정하는 데에 도움을 주는 질문

 

왼쪽 상단과 오른쪽 상단에 있는 질문을 먼저 대답하는 것이 좋을 수 있다. 즉, 만들고자하는 소프트웨어와 관련해 어느 정도 정형화된 템플릿이나 모델링 기법이 있는지 확인하는 것이 선행되어야 한다. 또한 구매 시스템과 같은 과정은 어느 정도 정형화되어있기에 이에 대한 패턴이 있는지 확인해야한다. 따라서 개발하고자 하는 소프트웨어와 유사한 소프트웨어가 있는지 확인해서 이를 참고하는 것이 좋다. 기존에 개발된 소프트웨어를 참고하는 경우에는 구조적 안정성과 실수를 줄이고, 개발 시간도 단축시킬 수 있다.

 

- 확장성, 정형화된 문서가 도출되어야하는지 등에 대한 질문을 던져야한다. 즉, 기존에 소프트웨어를 개발한 경험을 토대로 이를 정해야한다.

 

- 디자인과 아키텍쳐, 소프트웨어를 재사용하는 것 등은 중요하다.

 

2) 아키텍쳐에서 정의되어야 하는 특징들

(1) Performance

- 처리하는 장치를 한 곳에 모으고, 낮은 성능을 가지는 컴퓨터를 여러대 사용하는 것보다 높은 성능을 가지는 컴퓨터를 사용하는 것이 더 좋다는 것을 고려해 사용한다.

 

(2) Security

- 만드는 시스템이 사용자에게 노출되었을 경우에는 보안의 문제가 있을 수 있기에 이를 고려해야한다.

 

(3) Safety

- 여러 구성요소를 제어한다면 위험에 노출될 수 있기에 중요한 시스템들의 숫자를 줄이는 것을 고려해야한다.

 

(4) Availability

- redundant를 제공하기 위해 컴퓨터를 더 설치할 수 있는 등 이를 고려해야한다.

* redundant: 컴퓨터 한대가 죽으면 다른 한대가 동작할 수 있도록 함 (액티브 앤 스탠바이, 액티브 앤 액티브)

 

(5) Maintainability

- 구성요소들이 유지 보수 및 지속가능하도록 고려해야한다.

 

 

---

3. Architectural Views

어느 관점에서 아키텍쳐를 만들 것인가

---

 

- 주 관심사에 의해 아키텍쳐 디자인이 달라질 수 있다.

- 필요한 관점을 취해서 이에 맞는 디자인을 하는 것이 중요하다.

- 여러가지 관점에 따른 디자인을 실행에 옮기는 것이 좋다.

 

1) Architectural Views

- use case나 시나리오를 사용하면 도움이 될 수 있다.

 

(1) Logical view

- 설계하는 관점에서 추상화된 객체나 클래스를 가지고 보는 관점

 

(2) Physical view

- 하드웨어와 소프트웨어 구성요소들의 분산 등에 대해 보는 관점

- 큰 시스템일 경우에는 필수로 들어가야할 수도 있다.

 

(3) Development view

- 개발 관점에서 아키텍쳐를 세우는 관점

 

(4) Process view

- 구성요소들이 실행될 때 어떻게 상호 연관되는지에 대한 관점

 

- 상호 의미를 알 수 있는 정도로만 아키텍쳐 디자인을 만드는 것이 충분할 수 있기에 UML을 사용할 수 있고, 이보다 더 간단하게 구현할수도 있다. 다시 한번 더 언급하자면 정형화된 아키텍쳐 디자인 방법이 없기에 각 관점이나 만들고자하는 소프트웨어에 맞게 아키텍쳐를 디자인하는 것이 중요하다.

 

 

---

4. Architectural Patterns

소프트웨어의 골격을 만들기 위한 다양한 방법

---

1) 아키텍쳐럴 패턴

MVC 패턴

- 다른 소프트웨어의 아키텍쳐 디자인을 참조하기 위한 행위

- 기존의 소프트웨어를 만들 때 사용한 것을 재사용하는 것이 핵심이다.

- 미리 만들어진 아키텍쳐에 관한 패턴을 학습하여 시행착오를 줄일 수 있다.

- 각 패턴별로 언제 사용할지, 언제 사용하면 안되는 지에 대한 내용도 존재한다.

 

cf) 위키피디아 아키텍쳐럴 패턴

 

2) MVC 패턴

Model, View, controller 세개의 구성요소로 만드는 패턴

- Model: 데이터를 관장

- View: 데이터가 보여지는 것을 관리

- Controller: 데이터에 접근하는 사용자에 대한 내용을 관리

- Web based application에서의 기본적인 아키텍쳐이고 이를 기반으로 만든 모바일도 MVC 패턴을 사용한다.

- 데이터를 다양한 방법으로 보여주거나 요구사항의 변화에 따른 상호작용에 맞춰 대비하기 위해 사용한다.

- 데이터와 뷰, 컨트롤러가 독립적으로 존재하기에 어느 한 사항이 바뀌더라도 영향을 받지 않는다.

- 작은 프로그래밍을 만들 때 이를 짜는 것은 불필요하다.

- 웹어플리케이션에 적용한 예시이다.

- model은 데이터베이스가 되어서 웹과 관련된 내용을 저장할 것이다.

- View는 css/html으로 사람들이 볼 수 있는 영역이 될 것이다.

- controller는 사용자가 데이터를 요청하는 등에 대한 내용이 들어가야할 것이다.

 

cf) 장고 또한 MVC 패턴을 사용한다.

 

3) Layered architecture

계층이 존재하는 아키텍쳐

- 프로그램이 해야하는 주요한 기능, 사용자와 관련되어 (업무와 관련된 로직 등) 사용자 접근 범위에 대한 로직 등, 유저 인터페이스 등을 쌓아 올린다.

- 서브 시스템이 위 아래로 쌓이고 일반적으로 위 아래의 계층과만 통신을 한다.

- 중간에 낀 레이어가 바뀌었을 때 위 아래의 레이어에 영향을 주지 않는다는 장점이 있다.

- 안드로이드 같은 경우에는 맨 밑부분에 리눅스가 있고, 그 위에 웹과 관련된 내용과 데이터베이스, 미디어, 그래픽, 보안 등에 대한 부분이 올라간다. 그리고 어플리케이션이 쓸만한 내용에 대해서도 함께 쌓인다. 이후 앱을 만드는 사람들이 사용할 기능에 대한 것들을 쌓아올리고 이후 어플리케이션이 올라가있다. 

- 통신에서의 layer architecture인 OSI 7 layer 또한 이에 해당한다.

 

iLearn 서비스의 아키텍쳐

 

4) Repository architecture

저장공간이 패시브한 경우에 고려해볼 수 있는 아키텍쳐이다.

 

소스코드가 쌓여있는 레포지토리가 있어 이를 끌어와서 분석하거나 개발할 수 있도록 쉐어하는 형태이다. 대표적으로 패시브한 형태로 알고리즘이 돌아가지 않는 것이나 깃허브와 같은 형상관리시스템이 있다.

 

5) Client-server architecture

클라이언트가 요청한 일을 인터넷을 통해 서버가 돌려주는 아키텍쳐이다.

 

- 클라이언트와 서버의 컴퓨터는 분산되어있고 많이 사용하는 아키텍쳐이다.

- 정보나 기능이 서버에 존재하고, 이에 접근하기 위해 서버에 접속한다.

- 주요한 점은 서버는 네트워크를 통해 분산되어있다는 점이다.

- 인터넷과 같은 통신을 기반으로 해서 원격으로 서버에 접근한다는 장점이 있지만 현재 우리가 사용하는 것들은 대부분 클라이언트 서버 아키텍쳐를 사용하는데 이를 굉장히 많이 사용하기에 관리하기가 복잡하다.

- 웹기반으로 동작하는 경우에는 대부분 클라이언트 서버 아키텍쳐이고 스마트폰으로 사용하는 소프트웨어들의 대부분이 클라이언트 서버 아키텍쳐이다.

- 하나의 사이트를 보더라도 정적이미지, 글자, 동적 내용 등이 존재하기에 이를 관리하는 것이 복잡하고 이는 디자인의 측면이다.

 

 

6) Pipe and filter architecture

우리가 만들 소프트웨어가 입력과 출력을 기준으로 어떤 기능을 구현해야하는 지에 대한 아키텍쳐

- 순차적인 모델로 입력, 출력, 프로세스와 선후관계가 있는 아키텍쳐이다.

- 통신 상황에서 어떤 정보를 받았을 때 암호해제 -> 인증 -> 중복메세지 체크 등을 처리하는 과정을 파이프라이닝이라 한다. 이 또한 pipe and filter architecture를 사용한 아키텍쳐로 볼 수 있다.

 

---

5. Application Architectures

 

1) Application Architectures란

- 소프트웨어를 개발할 때 재생산되는 경우가 많아서 검증된 아키텍쳐를 사용하는 것이 효율적이다. 이를 활용하여 common한 부분은 끌고 오면 놓친 부분도 확인할 수 있다.

- 개발자에게 업무를 나누고, 일정을 잡는 등의 과정을 진행할 수 있게된다.

- 새로 작성하지 않는 부분은 코드의 재활용을 할 수 있다.

- 다른 사람과의 대화를 하기 위한 참조자료가 될 수 있다.
- 소프트웨어들은 통상 데이터를 대규모로 처리하는 경우, 트랜젝션 프로세싱, 실시간 이벤트 프로세싱, 컴파일러와 같은 언어 프로세싱 시스템 등은 아키텍쳐를 사용할 수 있다.

 

transaction 예시

 

ATM 프로세스 단위에서의 처리, 인풋, 역할 등을 그림

정보 시스템(웹 베이스)

mental care system  예시

 

- information system이 웹 베이스 시스템으로 많이 구현된다.

- 스마트폰과 컴퓨터가 클라이언트가 되어서 위와 같이 구현한다.

- 서버 베이스드에 대한 개발 방법론이 많이 등장하고 있는데 이는 클라이언트 서버 아키텍쳐를 대부분 준용한다.

 

2) Language processing system

- 컴퓨터 언어를 처리하는 시스템도 전형적이며 전통적인 분야이기에 많이 재활용되고 있다. 

 

- 이를 컴파일러 측면에서 조금 더 자세히 들어가면 많은 정보를 확보하고 여러 작업을 진행한다. 소스코드에서 기계어로 번역할 때 레포지토리가 존재해 이를 참고해 사용한다. 

 

- 파이썬이나 C++은 위의 개별 프로그램이 모두 들어가있고, 이는 위와 같이 레포지토리 아키텍쳐로 표현할 수 있다.

 

- 또한 pipe and filter 아키텍쳐로도 프로그래밍 언어의 아키텍쳐를 표현할 수 있다. 즉 필요하다면 두 개 이상의 아키텍쳐를 사용할 수 있다.

- common한 것을 가져오고 특정한 부분만 개발하여 사용하는 것을 패턴이라고 한다.