애플리케이션 설계 - 절차, 아키텍처

정보처리기사 필기 준비하며 정리한 내용입니다.

📌설계 절차

요구사항 명세 → [1️⃣아키텍처 설계 → 2️⃣시스템 아키텍처 → 3️⃣데이터베이스 설계-명세] → 4️⃣서브시스템 설계-명세 → 5️⃣컴포넌트 설계-명세 → 6️⃣자료구조/알고리즘 설계

1️⃣아키텍처 설계

아키텍처 = 구조. 전체 구성도

• 아키텍처의 종류
  1. 시스템 아키텍처
  2. 소프트웨어 아키텍처

소프트웨어 아키텍처

• 전체적인 소프트웨어의 구조 (로그인 하는 모듈 등)
  • 아키텍처 = 전체적인 구조, 구성도
• 특징
  • 간략성 : 이해하고 추론할 수 있는
  • 추상화 : 시스템의 추상적인 표현을 사용 (공통 속성 사용)
  • 가시성 : 포함해야 하는 것들이 보여야 그릴 수 있다
  • 관점 모형 : 이해당사자들은 관점이 다 다르다. 각자의 관심사에 따른 모형을 제시해야 한다
  • 의사소통수단
• 품질속성 ⭐
  • 정확성 : 사용자 요구기능을 충족시키는가?
  • 신뢰성 : 기능이 오류 없이 동작하는가?
  • 효율성 : 기능을 수행하는데 적절한 자원을 소요하는가? (CPU, 메모리 등의 자원을)
  • 무결성 : 허용된 사용자만 변경할 수 있어야 한다
  • 사용 용이성 : 누구나 쉽게 배우고 사용할 수 있는가
  • 유지보수성 : 변경이 잘 되어야 한다
  • 시험 용이성 : 테스트가 용이한가
  • 유연성 : 뭔가(기능 등) 추가할 수 있는가
  • 이식성 : 다양한 플랫폼 및 하드웨어에서 동작하는가
  • 재사용성 : 개발된 기능을 다른 목적으로 사용하기 용이한가
    • 재사용성을 위해 모듈의 독립성이 높아야 한다.
      • 모듈의 독립성을 높이기 위해서 응집도를 높이고 결합도는 낮춰야 한다
  • 상호 운용성 : 다른 소프트웨어와의 상호 교류 용이
• 소프트웨어 뿐만 아니라 모든 곳에서 통용
• 소프트웨어 아키텍처 4+1 뷰 ⭐
  • 이해관계자들의 관점이 모두 다르기 때문에 그런 관점뷰들을 만들어둔다.
  • → 이것들을 아우를 수 있는 4+1뷰
  • 4+1 View Model과 구성요소
    1. 논리적 관점
       • 논리 뷰
       • 기획자
       • 기능적 요구사항
    2. 구현 관점
       • 구현 뷰
       • 개발자 관점
    3. 프로세스 관점
       • 프로세스 뷰
       • 전체적으로 어떻게 돌아가고 관리되는지
       • PM or 고객
    4. 배치 관점
       • 배치 뷰
       • 시스템 엔지니어
         • 서버를 구성한다 (하드웨어, 운영체제, 네트워크에 특화된 직군)
           • 개발자는 그들이 만들어놓은 서버 위에 개발해서 올린다.
       • 어떻게 매핑되는가
       • 비기능적 요구사항 고려 (가용성, 신뢰성, 성능, 확장성)
    ➕ 위의 4개의 뷰를 하나로 아우를 수 있는 ▼
    • 유스케이스 관점
      • +1 뷰
      • 유스케이스 뷰
      • 사용자 입장
      • 다른 뷰 검증
      • 유즈케이스 다이어그램 사용

소프트웨어 아키텍처 패턴 ⭐

1. 계층화 패턴트리 형태로 계층적으로 그리는 것
   • 하위층이 있다!
     • OSI 7계층, TCP/IP 4계층
2. = n-티어 아키텍처 패턴
3. 클라이언트-서버 패턴
   • 우리가 인터넷을 사용할 때의 패턴
   • 클라이언트&서버 둘 다 입력 처리 가능
4. 마스터-슬레이브 패턴
   • 슬레이브에서 자료를 입력 → 마스터에서 처리 → 그 처리된 결과를 다시 슬레이브에게 돌려준다
   • 클라이언트-서버와의 결정적인 차이
     • 여기있는 슬레이브는 생각을 못한다. (단순한 단말기 역할) 결과값만 보여주는 것이다.
   • ex. 컴퓨터와 주변장치 (연산은 CPU가 함)
5. 파이프-필터 패턴
   • 파이프로 연결되어 있어서 한 쪽 방향으로 순차적으로 일처리→넘기고→처리→넘기고
   • 데이터 스트림을 생성 처리
   • 오버헤드는 일처리라고 생각하면 된다!
   • ⭐서브시스템이 입력 데이터를 받아 처리하고 결과를 다음 서브시스템으로 넘겨주는 과정을 반복한다
6. 브로커 패턴
   • 브로커 컴포넌트가 컴포넌트간의 통신을 조절한다
   • 클라이언트와 서버 사이에 브로커가 있다!
7. 피어 투 피어 Peer to Peer 패턴
   • 컴퓨터와 컴퓨터가 연결되어 있는 것
     • 피어 = 컴퓨터!
     • ex. 토렌토 같은 것들 (P2P)
     • 피어 객체 하나가 클라, 서버 역할 모두 수행
8. 이벤트-버스 패턴
   • 이벤트 버스를 통해 특정 채널로 메시지를 발행
   • 리스너가 구독한 채널에 소스가 서비스를 제공하면 → 채널이 리스너에게 서비스 제공
     • 리스너 : 구독자 역할
     ex. 알림 서비스
9. 모델-뷰-컨트롤러 패턴
   • 가장 많이 사용하는 패턴
     1. View : 사용자가 보는 화면 ex. 로그인 화면
     2. 사용자가 로그인 정보를 넣으면 정보는 서버로 간다
     3. 이 작업은 컨트롤러가 처리한다.
     4. 그러나 컨트롤러에는 데이터가 없다
     5. 그래서 데이터베이스의 모델 형태로 데이터를 추출한다
   • 연관관계
     • 뷰 - 화면
       • 사용자에게 결과를 표시
     • 컨트롤러 -처리
       • 사용자에게 입력받아 연산 처리
     • 모델 - 데이터베이스
       • 도메인 기능&자료 저장 보관
     ex. 일반적인 웹 어플리케이션 설계 아키텍처
10. 블랙보드 패턴
    • 아직 명확히 알려지지 않은 문제에 대해 유용한 패턴
    • ex. 음석인식, 단백질 구조 식별
11. 인터프리터 패턴
    • 특정 언어로 작성된 프로그램을 해석하는 컴포넌트 설계 시 사용

2️⃣시스템 아키텍처

개념

• 컴퓨터는 어떻게 구성되어있는가

시스템이 서비스를 제공하기 위한 기반. 전체적인 시스템 구성도

요 아래 항목(시스템의 구조, 행위)을 그림으로 그려놓은 것 (개념적 모형)

1. L4장비가 로드를 밸런싱해준다 (접속하는 걸 분산해줌)
   • 웹서버가 한대면 필요가 없지만 두대부터는 필요해진다!
   • 웹서버1, 웹서버2 중 어디로 사용자를 접속하게 할지 정한다.
2. 웹서버 1, 2
   • 정적인 걸 보여준다
   • 형태만 보여주는 것!
3. WAS 1, 2
   • 동적인 역할 수행
   • 자바에서 많이 쓴다
   • ID, PW 검사는 여기에서 한다!
4. 파일 서버가 있을 수도 있다
   • 예를 들어 WAS1기에 첨부파일을 올렸는데, 다른 사람이 WAS4로 접속했다면?
     • 이 때 파일 서버로 마운트를 건다면 해결된다 (이미지, 파일 등) - 글자는 DB서버
       • = 파일 서버를 참조하게 하는 것!
5. 데이터베이스 서버
   • ID, PW 데이터 등 정보는 여기에 있다. 이걸 웹브라우저에 보여준다.

• 기본 요구사항
  • 시스템 구성 및 동작 원리를 나타내야
  • 외부 환경과의 관계도 묘사

시스템 아키텍처 구성요소

1. DNS Domain Name System
2. 도메인 이름에 대한 질의(우리가 엔터를 치면 일단 DNS 서버에 가서 이 주소값이 뭐니? 하고 물어보는 과정) → 해당 도메인이 등록되어 있다면 도메인 이름에 해당하는 IP 주소를 응답해주는 것
3. Web Server (Web server + WAS)
4. 정적인 것을 담고 있다
5. API Application Programming Interface

요청이 들어오면 약속한 방식에 맞춰 정제된 데이터로 응답한다

1. Load Balancer (L4장비)(보통 한 컴퓨터는 500명정도 동시접속하면 서버 과부하)
   • 분배 방식
     1. Random : 말그대로 랜덤
     2. Least loaded : 가장 적은 양의 작업 처리하는 서버한테 할당
     3. Round Robin : 순차적으로 돌아가면서 분배한다. (1→2→3→1→2 이런식)
2. 여러대를 구성하게 된다. 사용자를 어디로 배치할지 분배하는 역할.
3. CDN Content Delivery Network사용자와 물리적인 길이가 짧은 곳으로 (데이터 저장 서버는 한곳에만 있는 게 아니다!)
4. 영상 등의 용량 큰 컨텐츠 데이터를 분산처리하는 것
5. Database

데이터 저장해두는 공간

시스템 아키텍처 고려사항

1. 확장성 Scalability : 용이하게!
2. 성능 Perfomance : 빠르고 정확하게!
3. 응답시간 Latency : 더욱 빨리!
4. 처리량 Throughput : 더욱 많이!
5. 접근성(=가용성) Availability : 언제든지!
   • 고가용성 = HA 솔루션
6. 일관성 Consistency : 일관된 결과를 돌려주어야 한다.

3️⃣데이터베이스 설계-명세

• 데이터베이스 설계는 개발 전에 선행되어야 한다.

4️⃣서브시스템 설계-명세

• 큰 덩어리의 시스템
  • (회원쪽, 포인트쪽, 주문쪽)

5️⃣컴포넌트 설계-명세

• 서브시스템 내에서 수행되는 작은 단위

6️⃣자료구조와 알고리즘 설계 = 실제 개발 단계

• 알고리즘
  • = 문제를 푸는 방법
  • 정답이 없다