소프트웨어 공학 CH. 6 아키텍쳐 디자인

Alpha, Orderly·2023년 5월 3일
0

소프트웨어 공학

목록 보기
6/9

Architecture design

  • 소프트웨어 시스템이 어떻게 구성되고 전체적 구조가 어떻게 되는지

Architecture Abstraction

  • Architecture in small : 개별 프로그램의 Architecture, 개별 프로그램이 컴포넌트로 세분화된다.
  • Architecture in large : 다른 시스템, 프로그램, 프로그램 컴포넌트가 포함된 복잡한 기업용 시스템의 Architecture
    • 다른 기업에 의해 소유 혹은 관리될수 있다.
    • 여러 컴퓨터들에 배포된다.

직접적 구조의 장점

이해당사자와 커뮤니케이션

  • Architecture는 이해당사자와의 의논 과정에 포커스 포인트로 사용 가능하다.

시스템 분석

  • 시스템이 Non-functional 요구사항에 도달했는지 분석 가능하다

대규모 재사용

  • 여러 시스템에 재사용될수 있다.

아키텍쳐 표현

  • 간단하고 비격식적 블록 다이ㅏ어그램으로 엔티티와 관계를 표현
  • 매우 추상적이다.
  • 이해관계자 커뮤니케이션 혹은 프로젝트 계획에서 유용하다.
  • Sementic이 부족하다는 단접이 있다 ( 엔티티나 관계의 타입 혹은 속성 표기 어려움 )

아키텍쳐 모델의 사용

  • 시스템 디자인에 대한 토의때
  • 디자인 된 아키텍쳐를 문서화할때

아키텍쳐 디자인의 결정

  1. 웹 클라이언트/모델링에 정형화된 것이 있을까?
  2. 기존에 사용되었던 Architectural 패턴이 존재하는가?
    위에 2개는 미리 있는 것을 참조하여 실수를 줄일 수 있다.
  3. 내가 만들 소프트웨어에 맞는 접근 방식은 존재하는 것인가?
    위의 3가지는 접근 방법
  4. 만들 시스템에 서브 요소들은 어떤 것들이 있는지 정의
  5. non-functional한 기능에 대해서 어떻게 지원을 할 것인지
  6. 어떻게 문서화시킬 것인지?
  7. 요소들의 기능, 기능에 대한 제어를 어떻게 할 것인지
  8. 하드웨어 코어, 프로세서들을 어떻게 분산시킬 것인지

아키텍처 재사용

  • 동일한 도메인의 시스템들은 종종 도메인 개념을 반영하는 유사한 아키텍처를 가지고 있습니다.
  • 이런것을 아키텍쳐 패턴 혹은 스타일이라 부릅니다.

아키텍처 / 시스템 성질

성능

  • 작은 여러 개보단 큰 하나가 좋다

보안

  • 단계별로 쌓아서 막아 줄 수 있음

안전

  • 가능하면 숫자를 줄임

가용성

  • 죽지 않고 돌아가는 방법 -> 대체할 수 있는 것을 둔다.

유지보수성

  • 서로 독립적으로 작동하여 각각의 영향이 없도록 함. , 기존에 검증된 코드를 사용한다.

아키텍쳐 관점

  • 어느 관점에서 뼈대를 세울지 결정한다.
  • logical view(설계를 하는 관점에서 객체나 클래스의 관점)
  • process view(프로세스가 움직이는 관점, 상호작용 중심)
  • development view(개발적인 관점)
  • physical view(시스템이 동작할 때 하드웨어적, 큰 시스템에 많이 적용됨, 물리적 관점)
  • use cases or scenarios(좀 더 의미를 두고 싶으면 이용되는 것)
  • ADL이라는 도구가 있으나 정해진 형태가 있는것은 아니다.

패턴의 예시

MVC(Model-View-Controller) 패턴

  • Model, View, Controller라는 3가지 요소로 소프트웨어를 개발함
  • 3가지 요소를 분리해 놓은 것
  • 모델은 데이터를 관리함
  • 뷰는 데이터가 어떻게 보여질 지를 나타냄
  • 컨트롤러는 각각을 조정하는 것
  • 현재에 소프트웨어들이 대부분 이렇게 많이 짜여짐
  • 언제 쓰이는지? 데이터를 다양한 방법으로 보여줄 때 사용, 컨트롤러가 있어 변화가 있을 때 그에 맞춰서 발전하기 위한 것임
  • 각각은 스스로의 역할을 잘 수행하며 스스로 발전해 나아감
  • 단점 : 너무 작은 소프트웨어에서 사용하기에는 소요가 크다

Layered architecture

  • 시스템을 여러 레이어로 구성하는것
  • 상위 레이어와 하위 레이어가 존재하고, 인접한 레이어끼리 통신한다.
  • 반드시 인접한 레이어끼리만 통신이 가능하다.
  • 레이어 내부에선 자유롭게 소통이 가능하다.

Ex.


Repository architecture ( 저장소 아키텍쳐 )

  • 데이터 중심 아키텍처
  • 공유 데이터는 중앙 데이터베이스 또는 저장소에 보관되며 모든 하위 시스템에서 액세스할 수 있습니다.
  • 각 하위 시스템은 자체 데이터베이스를 유지 관리하고 다른 하위 시스템으로
    다른 하위 시스템에 명시적으로 전달합니다.

Client - Server architecture

  • 클라이언트가 요청하고, 서버가 응답하는 구조
  • 단일 컴퓨터에서 둘 다 구성 가능
  • 네트워크를 통해 서버에 접속할수 있다.


Pipe and Filter architecture

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


Application architecture

  • 공통적인 것을 추가하고 이후에 특정부분을 추가함
  • 아무것도 없이 할 때보다 시행착오를 줄일 수 있다.
  • 미처 생각하지 못한 부분에 대한 검증이 가능
  • 구현에 대한 계획을 만듦
  • 코드의 재사용
  • 대화의 도구가 될 수 있음

예시

  • Data processing applications – 데이터를 대규모 처리, 한번에 처리
    • ex. 머신러닝
  • Transaction processing applications – 요청에 따른 처리
    • ex. 웹 베이스, E-커머스 시스템
  • Event processing systems – 이벤트 처리
    • ex. 임베디드 시스템
  • Language processing systems – 전형적인 architecture 설계 형태
    • ex. 컴파일러

Transaction processing system

  • 데이터베이스에서 정보에 대한 사용자 요청을 처리하거나
    또는 데이터베이스 업데이트 요청을 처리

Information system architecture

  • 계층화된 아키텍처로 구성
  • Transaction processing system 에 포함

레이어

  1. 사용자 UI
  2. 사용자 커뮤니케이션
  3. 정보 검색
  4. 시스템 DB

profile
만능 컴덕후 겸 번지 팬

0개의 댓글