[소프트웨어공학] 6장 Architectural Design

requirement engineering에 의해 요구사항이 정리되고 추가로 모델링 부분까지 설명함

모델링은 설계단계에서 역시 사용이 가능하다.

지금까지 사용자가 원하는 요구사항을 만들고 그것을 설계가 용이하도록 그림 화하는 작업까지 해봄

이번 장에서 실제로 설계에 들어감

앞에서 배운 구조 모델링이 여기서 많이 쓰인다.

 

주요의제

• Architectural design decisions – 설계를 위한 의사결정
• Architectural views – 다양한 관점
• Architectural patterns – 시스템의 형태를 골격화한 것
• Application architectures – 어플리케이션 예제에 대해서 구조화

 

>Architectural design(소프트웨어 시스템 내부)

- requirement engineering의 후속 단계, 세세한 설계를 하기 위한 중간과정

- 소프트웨어에 어떤 요소들이 필요하고 상호 어떤 관계를 맺는지를 봄

- 결과물은 시스템을 구성하고 있는 요소들, 요소들 사이의 상호작용이 나와야 함

 

Architecture(구조화 틀)는 에이자일 이건 폭포수 모델이건 모두 중요하다

에이자일에서도 incremental한 작업 전에 최초의 구조화를 잘 만들어 놔야 문제를 줄일 수 있다.

그렇지 않으면 소프트웨어의 전체적인 구조를 다시 바꾸게 되어 시간과 비용을 많이 소모하게 된다.

ex. 포장 과정 예제(page5)

우리가 필요한 요소들이 등장, 관계를 화살표로 그려준다.

정해진 구체적인 룰은 따로 없다

 

Architecture 추상화 2가지

>작은 규모 시스템 – 개인이 만드는 것, 적은 요소를 포함, 시스템이 작을 때

>큰 규모 시스템 – 여러 요소들이 존재, 각각의 네트워크로 분산된다.

>>각각에 맞춰 계획을 세워야 한다.

 

Architecture 표현의 이점

>이해당사자와의 대화 – 설명의 편의성

>시스템분석 - 물리적으로 떨어져 있는 것들을 연결할 때 고려해야하는 요소들을 생각해 볼 수 있음

>큰 규모 재사용 – 이전의 것들을 재사용하여 생기는 이점이 많다.

 

 

Architecture의 결과물

-정형화되지 않은 간단한 블록 다이어그램(단순기호)

-너무 심하게 상세한 내용을 담으려 노력하지 않음 -> 다음 단계 역할로 이전시킴

-매우 추상적이다

-개발에 대한 계획이 구체화될 수 있음

-각각의 요소들에 대한 설명을 만든다.

 

Use of architectural models

-앞쪽 모델링과 유사

 

>Architectural design decision

우리가 Architectural 설계를 할 때 어떤 결정을 내려야 하나?

-경험과 사례를 바탕으로 설계를 해야 한다.

 

총 8가지의 기본 질문

1) 웹 클라이언트/모델링에 정형화된 것이 있을까?

2) 기존에 사용되었던 Architectural 패턴이 존재하는가?

위에 2개는 미리 있는 것을 참조하여 실수를 줄일 수 있다.

3) 내가 만들 소프트웨어에 맞는 접근 방식은 존재하는 것인가?

위의 3가지는 접근 방법

4) 만들 시스템에 서브 요소들은 어떤 것들이 있는지 정의

5) non-functional한 기능에 대해서 어떻게 지원을 할 것인지

6) 어떻게 문서화시킬 것인지?

7) 요소들의 기능, 기능에 대한 제어를 어떻게 할 것인지

8) 하드웨어 코어, 프로세서들을 어떻게 분산시킬 것인지

>>기존에 만들어져 있는 것들을 참조하여 위와 같은 질문을 할 수 있다

 

Architecture 재사용

-기존의 유사한 형태의 시스템을 참조

 

Architectural한 설계를 통해 non-functional한 부분을 만족시키는지

>Performance(기능성) - 작은 여러 개보단 큰 하나가 좋다

>Security(보안) - 단계별로 쌓아서 막아 줄 수 있음

>Safety(안전성) - 가능하면 숫자를 줄임

>Availability(가용성) - 죽지 않고 돌아가는 방법 -> 대체할 수 있는 것을 둔다.

>Maintainability(유지보수성) - 서로 독립적으로 작동하여 각각의 영향이 없도록 함. , 기존에 검증된 코드를 사용한다.

 

 

>Architectural views(관점)

>>어느 관점에서 뼈대를 새울 것인지

>>각각의 관점에서 필요한 것만을 취해서 적용하면 됨

 

관점의 종류

-logical view(설계를 하는 관점에서 객체나 클래스의 관점)

-process view(프로세스가 움직이는 관점, 상호작용 중심)

-development view(개발적인 관점)

-physical view(시스템이 동작할 때 하드웨어적, 큰 시스템에 많이 적용됨, 물리적 관점)

 

-use cases or scenarios(좀 더 의미를 두고 싶으면 이용되는 것)

 

ADL이라는 특정 도구가 있기는 하지만 꼭 정해진 형태가 있는 것은 아님

 

>>다양한 방법들이 있는데 회사에서 정해둔 것이 있으며 그 방법을 사용하고 그렇지 않다면 과거의 경험들을 토대로 만들어 보는 것이 좋음

 

 

>Architectural patterns - 소프트웨어 설계에서는 경험했던 것들을 정형화하여 재사용하는 방법론, 여러 경험들을 참조하는 행위

>>미리 만들어본 경험에 대한 지식들을 참조하는 것

>>시행착오를 줄일 수 있다.

>>언제 사용하면 안 되는지에 대해서도 언급되어 있다.

>>개발자들이 미리 경험한 것들을 공부하는 것이 좋음

>>패턴은 테이블 또는 그림으로 표현이 된다.

 

패턴의 예시

MVC(Model-View-Controller) 패턴

>Model, View, Controller라는 3가지 요소로 소프트웨어를 개발함

>3가지 요소를 분리해 놓은 것

>모델은 데이터를 관리함

>뷰는 데이터가 어떻게 보여질 지를 나타냄

>컨트롤러는 각각을 조정하는 것

>현재에 소프트웨어들이 대부분 이렇게 많이 짜여짐

>언제 쓰이는지? 데이터를 다양한 방법으로 보여줄 때 사용, 컨트롤러가 있어 변화가 있을 때 그에 맞춰서 발전하기 위한 것임

>각각은 스스로의 역할을 잘 수행하며 스스로 발전해 나아감

>단점 : 너무 작은 소프트웨어에서 사용하기에는 소요가 크다

 

 

ex. 웹

모델 : 데이터베이스가 되어 Mysql, 오라클을 통한 저장

뷰 : HTML, CSS를 통해 사용자가 볼 수 있게 하는 것 담당

컨트롤러 : I/O장치가 작동할 때 서버 쪽으로 요청을 전송하는 등의 일을 담당

>>장고와 같은 예시가 있다

 

>Layered architecture(계층이 있다)

-인접해 있는 계층 간 에만 이동을 한다.

-위아래 또는 왼쪽에서 오른쪽으로 계층이 생긴다.

-한 계층이 바뀌었을 때 다른 계층에 영향을 주지 않는다.

ex. 계층구조 예시

<위>

User interface(사용자와의 상호작용)

User interface management Authentication and authorization(사용자의 권한 관리)

core business logic/application functionality System utilities(프로그램이 해야 될 가장 중요한 기술들, 업무와 관련된 로직)

System support(OS, 데이터베이스 등)

<아래>

>>컴퓨터를 네트워크에서 많이 사용된다.

ex. iLearn 시스템

계층기반 구조화

 

 

Configuration services - Application services이 직접 노출되지 않고 여기서 그룹화 되어 보여 진다.

Application services – 사용자가 사용할 수 있는 서비스

Utility services – 반드시 사용되어야할 서비스

 

>Repository architecture(저장소 구조)

>>컴퓨터의 주요 목적 데이터를 서로 공유하기 위함

>>데이터가 페시브(동작하여 바뀌지 않음) 되어있음

그림설명

 

>Client-server architecture

>>Client(요청하는 곳), server(처리하는 곳)로 분리되어 있음

>>각각의 분산되어 있는 서버에서 요청에 맞는 수행이 이루어진다.

>>서버들이 네트워크를 통해 분산되어 있음, 굉장히 많은 서버가 필요함

>>많이 사용됨(대부분의 웹서버)

>Pipe and filter architecture

>>프로세스에 중점을 둔 것

>>우리가 만든 프로그램이 어떠한 과정으로 입력과 출력이 이루어지는지 구조화

>>시퀀셜 모델 – 선으로 연결되어 있고 흐림이 존재함

그림 예시

>>선후 관계가 있음

 

>Application architectures(Application 예제)

>>다양한 패턴들이 존재함

>>어떤 식의 패턴들로 이루어져 있는지

>>공통적인 것을 추가하고 이후에 특정부분을 추가함

 

Application architectures의 사용

-아무것도 없이 할 때보다 시행착오를 줄일 수 있다.

-미처 생각하지 못한 부분에 대한 검증이 가능

-구현에 대한 계획을 만듦

-코드의 재사용

-대화의 도구가 될 수 있음

 

Application 예시

>Data processing applications – 데이터를 대규모 처리, 한번에 처리

ex. 머신러닝

>Transaction processing applications – 요청에 따른 처리

ex. 웹 베이스, E-커머스 시스템

>Event processing systems – 이벤트 처리

ex. 임베디드 시스템

>Language processing systems – 전형적인 architecture 설계 형태

ex. 컴파일러

 

>Transaction processing system

>>요청에 대한 처리를 해줌

 

>Information systems architecture

>>대부분의 웹베이스 시스템, 이커머스 시스템

>>서버가 중요하다

 

>Language processing systems

>>Translator, Interpreter 과정을 포함

>>컴파일러

>>최종적 실행가능 한 코드(기계어), 이미 저장소에 저장되어 있는 동작

>>pipe and filter compiler - 순차적 진행

 

 

6장 요약(상위레벨에서 이야기함)

-소프트웨어 아키텍처(software architecture)는 소프트웨어 시스템의 구성방식에 대한 설명입니다.

- 아키텍처 설계 결정사항(Architectural design decisions)에는 애플리케이션 유형, 시스템 배포, 사용할 아키텍처 스타일에 대한 결정이 포함됩니다.

- 건축물(Architectures)은 개념관점, 논리관점, 프로세스관점, 개발관점(conceptual view, a

logical view, a process view, and a development view.) 등 여러 가지 관점 또는 관점(different perspectives or views)에서 문서화할 수 있습니다.

- 아키텍처 패턴(Architectural patterns)은 일반 시스템 아키텍처에 대한 지식을 재사용하는 수단입니다. 그들은 구조를 설명하고, 언제 그것이 사용될 수 있는지 설명하고, 그것의 장점과 단점을 설명한다.

- 애플리케이션 시스템 아키텍처 모델(Models of application systems architectures)을 통해 애플리케이션을 이해하고 비교하며, 애플리케이션 시스템 설계를 검증하고, 대규모 구성 요소를 평가하여 재사용할 수 있습니다.

-거래처리 시스템(Transaction processing systems)은 데이터베이스에 있는 정보를 다수의 사용자가 원격으로 액세스하고 수정할 수 있는 대화형 시스템입니다.

- 언어 처리 시스템(Language processing systems)은 한 언어에서 다른 언어로 텍스트를 번역하고 입력 언어에 지정된 지침을 수행하는 데 사용됩니다. 여기에는 생성된 언어를 실행하는 번역기와 추상 기계(translator and an abstract machine)가 포함됩니다.