Architecture Design

난1렙이요·2024년 12월 13일

소프트웨어 공학 학교 공부

소프트웨어 공학

목록 보기

8/12

Architectural Design

아키텍쳐 디자인은 소프트웨어 시스템이 어떻게 정리되고 구조적으로 어떻게 만들 것인지를 디자인한다.
요구 공학을 통해 얻은 여러가지 요구 사항들을 시스템에 적용하기 위해 디자인하는 과정이다.
구조적으로 어떻게 만들어져있는지, 어떻게 작동하는지, 각각의 요소의 연결이 어떠한지 등이 잘 나타져 있다.
이러한 점을 보면 System Modeling하고 공유하는 부분들이 있다.

Architectural Abstraction

Architecture in the large
- 다른 시스템을 포함하고, 여러 프로그램들이 한 프로그램의 요소가 되는 큰 프로그램을 개발할 때 사용한다. (the architecture of complex enterprise)
- 예를 들어 멀티 플레이 게임을 만들어 본다고 하자.
- 게임은 유저와 싸우거나, 소통하거나, 아이템을 거래하거나 할 수 있다.
- 각각은 독립적인 요소들이지만, 게임이라는 프로그램의 요소이다.
- 그러므로 요소들이 어떻게 연결되고 상호작용하는지를 잘 나타내면 게임을 개발할 때 편리해진다.
Architecture in the small
- 하나의 독립적인 프로그램을 개발할 때 사용한다.
- 독립적인 프로그램을 개발한다고 해서 Architecture Design을 하지 않으면 안된다.
- 예를 들어 카드 게임을 만든다고 하자. 카드를 내고, 카드가 시스템에 맞아들어가고, 카드를 지우고 등등... 여러가지 내부 기능들이 있다.
- 이런 내부 기능들과 요소들을 개별적인 요소로 나누고, 다시 연결하는 것을 잘 나타내면 독립적인 프로그램이어도 개발할 때 편리해진다.

Advantages of Architectural Design

Architectural Design은 다음과 같은 이점이 있다.

Stackholder communication : 시스템을 요구하는 고객의 검토를 상시 받아들이고 소통할 수 있다.
System analysis : 구현 가능한 NFR이 시스템과 관련되도록 분석할 수 있다.
Large-scale reuse : 시스템은 자신을 넘어서 다른 부분에서 재사용 가능하다. 이런 특성 때문에 Product-line이 만들어진다.

Architectural Models

Architectural Model의 종류는 크게 3가지가 있다.
Simple, informal block diagrams
- 각각의 요소들과 관계를 간단하게 보여준다.
- 간단하지만 알기 쉽기 때문에 제일 많이 사용한다.
Box and Line Diagrams
- 굉장히 추상적이며 요소들의 실제 연결 관계와 세부 시스템을 보여주지 않는다.
- 그러나 개발 용어나 과정을 잘 모르며 전체적인 이해가 필요한 고객, 사용자들에게 보여주고 소통하기에는 유용하다.
Extenstion of UML models
- 기존에 있는 UML 모델을 확장해서 사용한다.
- 잘 사용하지 않는데, 이미 System Modeling에서 어느 정도 수행한 부분을 다시 할 필요가 없기 때문이다.

Architecture and System Characteristics

Architectural Design은 창의적인 활동이기 때문에 시스템이 어떻게 개발될 것인지에 따라 모두 달라진다.
그러나 어느정도 공통적인 부분은 존재한다.
Performance : 중요한 계산을 정의하고 시스템들간의 소통을 최소화 하도록 디자인해야 한다. 이렇게 하여 시스템 안에서 대부분의 중요한 일을 해결하고 복잡성을 감소시키며 성능을 좋게 한다.
- 시스템들간의 소통을 최소화하는 것이 왜 좋은지 의아할 수 있다. 시스템 간 소통이 많아지면 공유하거나 요청하는 것이 많아진다는 뜻이며, 이렇게 많아진 소통은 한눈에 보기 어려워진다. 간단히 말해서 복잡해지고 쓸데 없는 코드가 늘어난다.
- 매개 변수가 100개 있는 변수를 생각해보자. 생각만 해도 오류가 날 것 같지 않은가? 함수의 동작이 좌우되는 매개 변수를 줄이는 것처럼 시스템들간의 소통을 줄임으로써 오류를 줄이고 성능을 늘릴 수 있다.
Security : 보안에 취약한 부분을 정의하고 보완하거나 대처 방법이 존재하도록 디자인해야 한다.
- 보안은 항상 중요하다. 그러나 특히 보안이 중요한 시스템들이 존재한다. 은행 시스템같은...
- 그러므로 보안 취약점을 알아내야하며, 이를 보완하도록 디자인하거나 일어날 수 있는 문제에 대한 대처 방법이라도 있어야한다.
Safety : 작은 시스템들부터 안전성이 보장되어야 한다.
- 싱글톤 디자인 패턴은 구현하기 쉬워서 작은 시스템에서 많이 사용한다.
- 그러나 큰 시스템으로 갈 수록 코드들간의 복잡성을 증가시키고, 종속성을 알기 어렵게 한다.
- 그러므로 안전성을 높일 수 있는 방법과 같이 사용하거나, 다른 방법을 선택해야 한다.
Avaliability : 실패하는 경우를 대비해서 충분한 해결방안을 가지고 있어야 한다.
Maintainability : 새로운 요소를 추가하거나 기존 요소를 바꿀 때, 큰 어려움 없이 추가하거나 변경 가능해야 한다.
- 만약 어떤 시스템을 다른 모든 시스템이 참조하고 있다고 생각해보자.
- 근데 어느날 중요한 이 시스템에 치명적인 오류가 일어났다!
- 이때 Maintainability가 확보되어 있지 않으면 빠르게 대처하지 못할 것이다.
- 그러므로 애초에 중요한 일을 한 시스템이 모두 맡지 않게 하거나, 시스템이 작동하지 않을 때 추가적인 방안이 있어야 한다.

Architecture Reuse

시스템들은 대부분 비슷한 구조를 가지고 있는 다른 시스템이 있다.
- 은행 시스템은 기업마다 확 다르지 않고 어느정도 비슷하다.
- 쇼핑몰은 디자인은 다르지만 시스템 전체적으로 볼 때 유사한 부분이 많다.
시스템을 만들 때 구조적인 패턴이나 스타일을 가져오거나 조립해서 만드는 것은 강한 이점이 있다.
- 기존에 존재했기 때문에 비용이 감소한다.
- 가져온 시스템의 작동됨이 보장된다.
- 가져온 시스템을 내 시스템에 적용할 때 부분적으로 바꾸면 되므로 처음부터 하는 것 보다 간단해진다.

Architectural Views

각각의 아키텍쳐 모델은 하나의 view만 보여준다.
- 게임을 만들 때 팀마다 중요시 하는 게 다르다.
- 아트 팀은 캐릭터 아트와 배경, 주변환경 요소 등에 신경을 쓰고 중점적으로 일할 것이다.
- 스토리 팀은 캐릭터 서사, 전체 스토리 등을 생각할 것이다.
- 개발 팀은 그딴거 다 필요없고 시스템이 효율적으로 잘 돌아가는지만 생각할 것이다.
- 기획은 여러가지 팀의 의견들을 수렴해서 제일 좋은 결과물을 내놓아야 한다. 시스템 또한 동일하다.
하나의 view는 다른 관점에 대해서 중요한 부분을 나타내지 못할 수 있다.
위의 이유 때문에 소프트웨어 디자인은 다양한 view가 필요하다.

4 + 1 View Model of Software Architecture

Logical view : 논리적인 관점에서 각각의 요소와 클래스들이 소통 가능하며 알맞게 연결되는지를 본다.
- 예를 들어, 99레벨을 달성하면 업적이 해금된다.
- 그러나 모든 몬스터가 주는 경험치를 합쳐도 99레벨을 달성할 수 없다!
- 이렇게 만들게 되면 업적은 사실상 없는 것과 똑같다.
- 이처럼 어떤 요소에 대한 접근이 가능한지와 연결이 잘 되어있는지를 중요하게 생각하는 관점이다.
Process view : 시스템이 어떻게 상호작용하고, 실행하는 시간이나 과정을 집중적으로 본다.
- 아이템 검색 시스템을 선형 탐색으로 구현했다.
- 문제는 아이템이 매우 많다는 것이다. 검색할 때 마다 겁나게 오래 걸린다...
- 성능을 올리기 위해서 아이템에 고유한 index를 부여하고, 이분 탐색에 따라 정렬된 정보를 찾아 검색 결과를 내보낸다. 이러니까 성능이 올라갔다.
- 이처럼 성능이나 과정을 중요하게 생각하는 관점이다.
Development view : 소프트웨어가 어떻게 분리되고 개발되는지를 집중적으로 본다.
- 게임은 여러가지 요소로 분리될 수 있다. UI/UX, 전투, 레벨 시스템 등등...
- 이런 각각의 요소들이 어떻게 분리되며, 어떻게 개발되어야 하는지를 중요하게 보는 관점이다.
Physical view : 하드웨어와 소프트웨어 간의 연결관계를 중심으로 본다.
- 게임을 키보드/마우스 유저 상대로 제작했다고 하자.
- 만약 게임이 너무 잘 팔려서 콘솔 시장에도 진출하고 모바일 시장에도 발매 할 것이다.
- 근데 게임을 이미 키보드/마우스 매핑해놓아서 고칠려면 굉장히 많은 노력이 필요할 것이다.
- 이처럼 하드웨어와 소프트웨어 간에 데이터를 주고 받는 방식이나 작동방식을 중요하게 보는 관점이다.
Use-Case Scenario : use-case를 통한 테스트와 이들이 잘 작동하는지를 중심으로 본다.
- 사용자가 캐릭터 이름을 적으라는데 자꾸 특수문자를 적는다.
- 특수문자 중 몇개는 오류를 일으킬 수 있다.
- 그러므로 특수문자 입력을 막거나 예외 처리를 해줘야 한다.
- 이처럼 일어날 수 있는 모든 일들을 적은 use-case와 테스트가 잘 일어나는지를 중심으로 본다.
View 4개와 Use-Case Scenario를 합쳐서 4+1 View Model이라고 부른다.

Representing Architectural Views

UML(Unified Modeling Language)은 아키텍쳐에 대한 설명을 하기에 너무 좋은 도구이다.
그러나 위에서 말한 것 처럼 UML은 많이 사용되지 않는다. 왜일까?
- 사실 UML은 개발자들이 알아듣기 좋은 방식으로 아키텍쳐를 설명하는 방법이라고 할 수 있다. Architecture Design은 고객, 사용자, 개발자가 아닌 다른 팀에서도 보고 이해할 수 있도록 만들어야 한다.
- 그러므로 UML보다 더 high-level을 포현할 수 있는 방법이 사용된다.
아키텍쳐를 표현하기 위한 전용 언어인 ADLs(Architectural description langauges)도 있으나 사실 많이 쓰이지는 않는다.
그럼 무엇을 많이 사용하나면, 그냥 구조를 간단하게 나타낼 수 있는 특별함 없는 diagram을 제일 많이 사용한다.

Describing Software Architectures

AD(architecture descriptions)는 requirement들을 specific 해 놓은 것이다.
AD는 직접적으로 디자인 하기 전에, 사용자가 원하는 요구사항들이 실제 시스템에서 어떻게 만족이 되는지를 보여주기 위해 만든다.
- 게임에서 공격하면 데미지를 받는 시스템이 있어야 한다.
- UML로 나타내면, 공격하는 객체 클래스, 공격 받는 클래스, 중간 시스템, 여러가지 추가 클래스, 데이터베이스 등등... 구조를 짜기는 좋지만, 일반인이 알아듣기에는 어렵다.
- 그러므로 그냥 공격자, 피격자, 중간 시스템 등으로 간단하게 나타내면서도, 어떻게 작동하는지를 알려줘서 사용자들이 이해할 수 있도록 한다.

Architectural Pattern / Style

Architectural Pattern/Style은 아키텍쳐를 만드는 규격화된 디자인이다.
시스템은 구조적 유사함이 존재하기 때문에 기존에 있는 패턴을 이용해서 아키텍쳐를 만드는 것(reuse)은 강한 이점을 가진다.
아키텍쳐 패턴은 대표적으로 5개가 있다.
- MVC(Model-View-Controller)
- Layered
- Repository
- Client-Server
- Pipe & Fliter

Application Architecture

어플리케이션(앱)을 만드는 것은 기존 시스템을 만드는 것과는 다른 특징이 있다.
또한 특정한 기능을 수행가는 소프트웨어를 만들 때도 다른 소프트웨어와는 다른 특징들이 있다.
이러한 특징들을 잘 나타나게 하는 것은 기존의 방식으로 어렵지만, Application Architecture를 이용하면 더욱 잘 나타낼 수 있다.
대표적인 4가지가 있다.
- Data processing applications
- Transaction processing applications
- Event processing systems
- Language processing systems