Software Engineering – Architectural Design

• 시스템의 전체 골격을 세우는 단계
• 성취하고자 하는 기술적 기능과 Non-functional한(성능 등) 부분(회사 개발 체계, 보안, 신뢰성, 유지보수, scalable…)의 골격을 세운다.
• 다양한 관점에서 검토하며 소프트웨어를 디자인할 때 패턴화되어 있는 골격을 참조하여 설계한다.(경험 공유)

Architectural Design

• 소프트웨어 시스템 안에서 요소나 객체들이 어떻게 구성될 것인가에 대해 결정한다.
• requirement engineering과 디테일한 설계의 중간 단계이자 중요한 연결 단계
• 시스템 내에서 중요한 구조적 구성 요소와 그들 간의 관계를 정의한다.
• 시스템이 어떻게 조직되어 있고, 요소들이 어떻게 상호작용하는 지에 대한 모델이 결과물로 나온다.
• 초반에 큰 틀을 만드는 것은 중요하므로 agile, water-fall 방식 모두에서 주요하게 사용된다.
• 잘못된 설계 구조는 차후 전체적 구조를 다시 만드는 작업(refactoring)을 야기할 수 있으며, 이 작업은 시간과 비용이 매우 비싸며 많은 구성요소에 영향을 미친다.
  • refacotring시에는 성능 뿐만 아니라 확장, 보안성 등 non-functional한 부분까지 고려해야한다.

명확한 구조의 장점

• Stakeholder communication : 이해 당사자 간의 커뮤니케이션에 사용될 수 있다
• System Analysis :시스템 분석에 대한 중요한 자료가 되며 보안과 같은 non-functional에 대해서도 분석될 수 있다.
• Large scale reuse :요구사항이 유사하면 구조와 소프트웨어가 비슷하므로 큰 스케일로 재사용할 수 있다.

Architectural representations

• 단순하고 정형화되지 않은 다이어그램으로 관계와 객체를 나타내는 방법이 소프트웨어 구조를 설명하는 문서에 자주 사용된다. 너무 상세하게 설명하지 않는다.
  • 의미를 제대로 설명하지 못 할 수도 있으며, 객체 간의 관계를 설명하지 못하거나 객체의 특징을 뚜렷하게 나타내지 못할수도 있어 비판의 여지가 있다.

Box and line diagrams

• 매우 추상적으로 표현되며 관계나 특징을 뚜렷하게 설명하지 않는다
• 이해당사자 간의 커뮤니케이션에 유용하다

Architectural Design Decisions

• Architectural design은 세부적으로 디자인할 시스템에 대한 내용을 담고 있거나 기존 시스템을 설명하기 위해 사용될 수 있다.
• 기존 시스템에 대한 모델링은 새로운 시스템을 만들기 위한 현재 시스템의 파악 용도로 사용될 수 있따.
  
  

Architectural Design Decisions

• 완전히 같은 고민을 한 소프트웨어 구조는 없을지라도 많은 부분 이전의 경험들을 통해 도움을 받을 수 있다.
  (1) 우리가 만들 소프트웨어의 골격에 대해, 참조할 만한 template(기본/정형화된 양식)이 있는가?
  (2) 정형화된 골격 패턴이 존재할까? - 구조적 안정성, 실수 감소
  (3) 내가 참조할 만한 접근 방식은 존재할까?
  (4) 우리의 시스템의 서브 구성요소가 어떤 것이 있어야 하지?
  (5) Non-Functional을 어디서 어떻게 지원해야 할까?
  (6) 어떻게 결과물을 문서화할까? (회사의 정책상 구체적/형식적이야 한다면)
  (7) 정의된 구성요소들에 대한 기능과 제어는 어떻게 할 것인가?
  (8) 어떻게 시스템을 분산화 할 것인지?

Architecture reuse

• 코드 재사용 뿐만 아니라 큰 골격의 재사용도 중요하다.
• architecture를 재사용할 수 있다면 연계된 코드의 재사용도 가능하다.
• core 부분을 재사용하고 필요한 기능을 추가하는 것이 권장된다.

장점

• 설계 문서를 공유/재사용함으로써 설계 과정에서의 고민이 줄어들고 해결해야할 부분에 집중함으로써 생산성이 늘어난다.
• 미처 생각하지 못한 부분에 대한 정보를 얻을 수 있다.
• 신뢰성과 안정성이 늘어난다.

Architecture and system characteristics

Performance(요구사항을 초당 얼마나 처리할 수 있는가)

• 컴퓨터를 모아 통신 부화를 최소화하고, 처리하는 하드웨어를 높은 성능을 사용하는 것이 좋다.

Security

• Layer 구조를 쌓아, 안쪽 layer에 대한 접근을 차단할 수 있다.

Safety

• 중요한 서브 시스템 수를 줄일 수 있다.

Availability

• 일을 처리할 때, redundant를 사용한다.

Maintainability

• replaceable, fine-grain components를 사용한다.
• 기존의 코드 재사용, 검증된 코드를 재사용이 중요하다.

Architectural views

• 관점에 따라 디자인이 달라질 수 있다.
  

Logical views

• 객체지향 프로그래밍을 한다면, 추상화된 오브젝트와 오브젝트 class를 가지고 논리적 관점에서 Structural Architectural 디자인할 수 있다.

Process view

• 프로세스가 실제로 실행되는 런타임을 생각해, 구성요소들의 상호관계를 중심으로 디자인할 수 있다.

Development view

• Agile한다면 개발자 관점에서 뼈대를 세워도 좋다.

Physical view

필요한 하드웨어들이 분산되어 있다 이러한 관점에서 디자인할 수 있다.

모든 뷰에 대해서 의미를 더 주고 싶을 때(좀 더 구체적인 내용 전달을 위해) 특정 use case나 시나리오를 기반으로 디자인을 진행할 수 있습니다.

Architectural patterns

• 패턴은 이전에 사용해 본 사람들의 지식을 재사용하고 공유하는 것이다
• 구조적 패턴은 다양한 환경에서 시도되고 검증된 방식을 의미한다.
• 구조적 패턴을 사용함으로써 생각하지 못했던 사항도 고려됨으로써 시행 착오를 줄일 수 있고, 개발에 있어서도 시간과 비용을 줄일 수 있다.
• 패턴은 언제 사용하며 언제 사용하면 안되는지에 대한 정보를 담고 있어야한다.
• 패턴은 tabular와 graphical 설명 방식을 통해 표현된다.

MVC pattern

• MVC는 Model-View-Controller 3가지 구성요소로 소프트웨어를 구현한다는 철학
• 소프트웨어를 데이터, 데이터를 보여주는 것과 데이터를 사용(상호작용)하는 것, 3가지로 독립적으로 동작
• Model은 data(상태정보)를 관장(관리)하고, View는 데이터의 view를 관장한다. 사용자가 존재할 때 입력을 처리할(사용자가 다양한 상호작용) Controller가 있다.
• 이것이 현 웹 기반 어플리케이션의 기본 System Architecture이다.
• 데이터를 다양한 방법으로 보여주고자 할 때 사용되며, 미래의 요구사항이 발생하거나 알지못하는 데이터와 상호작용할 때 사용된다.
• 장점으로 각각이 독립적으로 동작하므로 Controller가 달라져도 Model과 view는 동일할 수 있다.
• 단점으로 복잡하다. 단순한 규모에 어울리지 않는다.
• 웹 어플리케이션에 적용해봤을 때, 모델은 데이터베이스, 뷰는 HTML과 같이 사용자가 볼 수 있게 한 것, Controller는 마우스 등의 입력에 따라 웹 클라이언트가 웹 서버에 요청하는 것들을 처리하는 것이라 할 수 있다.
  

Layered architecture

• 서버가 쌓여 통상 위-아래로 interface가 된다.
• 일반적으로 가장 하부에 하드웨어와 운영체제, 그 위에 데이터베이스를 쌓는다.
• 그 위에 업무 관련 core 기능 등 기능을 쌓으며, 인증 기능과 사용자 인터페이스를 쌓아 올려 만들 수 있다.
• 장점으로 중간의 layer가 바뀌어도 위와 아래 계층에 영향을 주지 않는다. 따라서 소프트웨어의 특정 layer만 수정 가능하다.
• 안드로이드 및 OSI 7 layered architecture가 있다.
  

Repository architecture

• 하나의 저장 공간을 다수의 사용자가 사용하는 것을 목적으로 한다.
• 알고리즘이 적용되지 않은 데이터베이스나 git과 같은 passive한 저장공간을 공유하는 형태를 가진다.
  

Client-server architecture

• 분산된 시스템의 서버가 클라이언트의 요청을 받은 결과를 돌려주는 형태
• 정보나 기능이 서버에 저장되어 있어 클라이언트는 서버에 원격으로 접속한다.
• 웹 기반으로 동작하는 웹브라우저들을 대부분 이 구조를 따른다.
• 장점 : 인터넷과 같은 원격작업이 가능하다
• 단점 : 굉장히 많은 서버가 투입되어 있으므로 전체적인 관리가 힘들다.
  

Pipe and filter architecture

• 프로세스에 방점을 찍어, 시스템이 어떠한 기능적인 절차를 진행하는지 입력과 출력의 관점에서 시스템을 architecting하는 것이다.
• 입력 > 처리 > 데이터의 형태와 유사하다.
• 입출력과 프로세스 간의 선후관계가 존재한다.