[1과목 - 3장] 소프트웨어 설계 - 애플리케이션 설계

yvonne·2023년 1월 18일
0

정보처리기사📝

목록 보기
3/3
post-thumbnail

1. 소프트웨어 아키텍처

🔎 1) 소프트웨어 아키텍처의 설계

  • 소프트웨어 아키텍처: 소프트웨어의 골격이 되는 기본 구조, 소프트웨어 구성 요소 간의 관계를 표현하는 시스템 구조 또는 구조체
  • 소프트웨어 개발 시 적용되는 원칙과 지침이며 이해 관계자들의 의사소통 도구
  • 좋은 품질을 유지하며 사용자의 비기능적 요구사항으로 나타난 제약을 반영하고 기능적 요구사항을 구현하는 방법을 찾는 과정
  • 소프트웨어 아키텍처 설계의 기본 원리: 모듈화, 추상화, 단계적 분해, 정보 은닉
  • 애플리케이션 분할 방법과 분할된 모듈에 할당될 기능, 모듈 간 인터페이스를 결정


🔎 2) 모듈화(Modularity)

  • 모듈화: 소프트웨어 성능을 향상시키거나 시스템의 수정 및 재사용, 유지 관리 등이 용이하도록 시스템 기능을 모듈 단위로 나누는 것
  • 모듈: 모듈화를 통해 분리된 시스템의 각 기능 (서브루틴, 서브시스템, 소프트웨어 내 프로그램, 작업 단위 등)
  • 자주 사용되는 계산식이나 사용자 인증 같은 기능을 공통 모듈로 구성하여 재사용성을 향상
  • 너무 작게 나누면 모듈 간의 통합 비용이 많이 들고, 너무 크게 나누면 개수가 적어 모듈 하나의 개발 비용이 너무 많이 든다.
  • 기능의 분리가 가능하여 인터페이스가 단순해진다.
  • 프로그램의 효율적 관리가 가능, 오류의 파급 효과 최소화

🔎 3) 추상화(Abstraction)

  • 추상화: 문제의 전체적이고 포괄적인 개념을 설계한 후 세분화하여 구체화시키는 것
  • 완전한 시스템을 구축하기전에 유사한 모델을 만들어 여러 요인을 테스트
  • 최소의 비용으로 실제 상황에 대처 가능, 시스템 구조를 대략적으로 파악 가능
  • 추상화의 유형
    • 과정 추상화: 자세한 과정을 정의하지 않고 전반적인 흐름만 파악하는 설계 방법
    • 데이터(자료) 추상화: 데이터의 세부적 속성,용도를 정의하지 않고 구조를 대표할 수 있는 표현으로 대체
    • 제어 추상화: 이벤트 발생의 절차나 방법을 정의하지 않고 대표 표현으로 대체

🔎 4) 단계적 분해(Stepwise Refinement)

  • 하향식 설계 전략으로 상위 중요 개념부터 하위의 개념으로 구체화시키는 분할 기법
  • 추상화의 반복에 의해 세분화
  • 기능에서 시작하여 점차적으로 구체화하고 상세한 내역(알고리즘, 자료 구조 등)은 뒤로 미루어 진행

🔎 5) 정보 은닉(Information Hiding)

  • 한 모듈 내부에 포함된 절차와 자료들의 정보를 감춰 다른 모듈이 접근하거나 변경하지 못하도록 하는 기법
  • 정보 은닉된 모듈과 커뮤니케이션할 필요가 있을 때는 필요한 정보만 인터페이스를 통해 교환
  • 정보 은닉을 통해 모듈을 독립적으로 수행할 수 있고 수정, 시험, 유지보수가 용이함

🔎 6) 소프트웨어 아키텍처의 품질 속성

  • 소프트웨어 아키텍처가 이해 관계자들이 요구하는 수준의 품질을 유지, 보장할 수 있게 설계되었는지를 확인하기 위해 품질 평가 요소를 여러 측면에서 구체화 시킨 것
  • 시스템 측면
    • 성능: 이벤트가 발생했을 때 적절하고 빠르게 처리
    • 보안: 허용되지 않은 접근을 막고, 허용된 접근에는 적절한 서비스 제공
    • 가용성: 장애 없이 정상적으로 서비스 제공
    • 기능성: 요구한 기능을 만족스럽게 구현
    • 사용성: 소프트웨어를 명확하고 편리하게 구현
    • 변경 용이성: 소프트웨어가 다른 하드웨어나 플랫폼에서도 동작할 수 있도록 구현
    • 확장성: 용량, 처리능력을 확장했을 때 효과적으로 활용할 수 있도록 구현
    • 기타 속성: 테스트 용이성, 배치성, 안전성
  • 비즈니스 측면
    • 시장 적시성: 정해진 시간에 맞춰 프로그램 출시
    • 비용과 혜택: 개발 비용을 더 투자하여 유연성이 높은 아키텍처를 만들 것인지 결정
      (유연성이 떨어지는 경우 유지보수 비용이 높을 것을 고려해야함)
    • 예상 시스템 수명: 시스템을 얼마나 오랫동안 사용할 것인지 고려
      (수명이 길어야한다면 품질의 변경 용이성, 확장성을 중요하게 고려)
    • 기타 속성: 목표 시장, 공개 일정, 기존 시스템과의 통합 등
  • 아키텍처 측면
    • 개념적 무결성: 전체 시스템과 시스템 구성요소들 간의 일관성 유지
    • 정확성, 완결성: 요구사항과 요구사항 구현 시 발생하는 제약사항들을 모두 충족시키는 것
    • 구축 가능성: 시스템을 적절하게 분배하여 유연하게 일정을 변경할 수 있도록 하는 것
    • 기타 속성: 변경성, 시험성, 적응성, 일치성, 대체성 등

🔎 7) 소프트웨어 아키텍처의 설계 과정

  • ① 설계 목표 설정: 설계에 영향을 주는 비즈니스 목표, 우선순위 등 요구사항을 분석하여 목표 설정
    ② 시스템 타입 결정: 시스템과 서브시스템 타입을 결정하고 아키텍처 패턴을 선택
    ③ 아키텍처 패턴 적용: 아키텍처 패턴을 참조하여 시스템의 표준 아키텍처를 설계
    ④ 서브시스템 구체화: 서브시스템의 기능 및 서브시스템 간의 상호작용을 위한 동작과 인터페이스 정의
    ⑤ 검토: 아키텍처가 목표에 부합하는지, 요구사항이 잘 반영되었는지, 설계의 기본 원리를 만족하는지 검토

📌시스템 타입

  • 대화형 시스템: 사용자 요구가 발생하면 시스템이 이를 처리하고 반응하는 시스템
    • 온라인 쇼핑몰 같은 웹 애플리케이션
  • 이벤트 중심 시스템: 외부의 상태 변화에 따라 동작하는 시스템
    • 전화, 비상벨 등의 내장 소프트웨어
  • 변환형 시스템: 데이터가 입력되면 정해진 작업들을 수행하여 결과를 출력하는 시스템
    • 컴파일러, 네트워크 프로토콜
  • 객체 영속형 시스템: 데이터베이스를 사용하여 파일을 효과적으로 저장, 검색, 갱신할 수 있는 시스템
    • 서버 관리 소프트웨어

📌협약(Contract)에 의한 설계

  • 컴포넌트 설계 시 클래스에 대한 여러 가정을 공유할 수 있도록 명세한 것
  • 협약에 의한 설계시 명세에 포함될 조건
    • 선행 조건(Precondition): 오퍼레이션이 호출되기 전에 '참'이 되어야 할 조건
    • 결과 조건(Postcondition): 오퍼레이션 수행 후 만족되어야 할 조건
    • 불변 조건(Invariant): 오퍼레이션 실행 동안 항상 만족되어야 할 조건



2. 아키텍처 패턴

🔎 1)아키텍처 패턴

  • 아키텍처를 설계할 때 참조할 수 있는 전형적 해결 방식 또는 예제
  • 시스템의 구조를 구성하기 위한 기본적인 윤곽
  • 아키텍처 패턴에는 서브시스템과 역할이 정의되어 있고, 관계와 규칙, 지침 등이 포함되어 있다.
  • 아키텍처 패턴의 장점
    • 개발 시간을 단축시키고, 고품질의 소프트웨어 생산
    • 검증된 구조로 개발하기 때문에 안정적 개발 가능
    • 이해관계자들이 아키텍처를 공유하여 의사소통 간편
    • 시스템 구조 이해가 쉬워 손쉽게 유지보수 가능
    • 시스템 특성을 개발 전에 예측하는 것이 가능

🔎 2) 아키텍처 패턴의 종류

  • 레이어 패턴(Layers Pattern): 시스템을 계층(Layer)으로 구분하여 구성하는 고전적 방법

    • 각각의 서브시스템들이 계층 구조를 이루며, 하위 계층 → 서비스 제공자 / 상위 계층 → 클라이언트가 된다.

    • 서로 마주보는 두 계층 사이에서만 상호작용하므로 변경 작업이 용이함

    • 특정 계층만을 교체해 시스템 개선하는 것 가능

    • 대표적으로 OSI 참조 모델이 있다.

      📌OSI 참조모델: 네트워크 프로토콜을 계층별로 구분한 모델
      - 물리 계층 / 데이터 링크 계층 / 네트워크 계층 / 전송 계층 / 세션 계층 / 표현 계층 / 응용 계층 

  • 클라이언트-서버 패턴(Client-Server pattern): 하나의 서버 컴포넌트와 다수의 클라이언트 컴포넌트로 구성

    • 사용자는 클라이언트와만 의사소통을 함

    • 사용자가 클라이언트를 통해 서버에 요청하고 클라이언트가 응답을 받아 사용자에게 제공

    • 서버는 클라이언트 요청에 대비해 항상 대기

    • 클라이언트와 서버는 요청과 응답을 받기 위해 동기화되는 경우를 제외하고 서로 독립적

      	*컴포넌트(Component): 독립적인 업무 또는 기능을 수행하는 실행코드 기반으로 작성된 모듈

  • 파이프-필터 패턴(Pipe-Filter Pattern): 데이터 스트림 절차의 각 단계를 필터 컴포넌트로 캡슐화하여 파이프를 통해 데이터를 전송하는 패턴

    • 필터 컴포넌트는 재사용성이 좋고, 추가가 쉬워 확장이 용이

    • 필터 컴포넌트를 재배치하여 다양한 파이프라인 구축 가능

    • 데이터 변환, 버퍼링, 동기화 등에 주로 사용

    • 필터 간 데이터 이동 시 데이터 변환으로 인한 오버헤드 발생

    • 대표적으로 UNIX의 쉘(Shell)이 있다.

      	*데이터 스트림: 데이터가 송,수신되거나 처리되는 일련의 연속적인 흐름
      	*파이프라인: 필터와 파이프를 통해 처리되는 일련의 처리 과정
                      

  • 모델-뷰-컨트롤러 패턴(Model-View-Controller Pattern): 서브시스템을 3개의 부분으로 구조화하는 패턴

    ① 모델(Model): 서브시스템의 핵심 기능과 데이터 보관
    ② 뷰(View): 사용자에게 정보 표시
    ③ 컨트롤러(Controller) - 제어: 사용자로부터 입력된 변경 요청을 처리하기 위해 모델에게 명령을 보냄

    • 각 부분은 별도의 컴포넌트로 분리되어 서로 영향을 받지 않고 개발 작업 수행
    • 여러 개의 뷰를 만들 수 있으므로 대화형 애플리케이션에 적합



  • 기타 패턴

종류특징
마스터-슬레이브 패턴
(Master-Slave Pattern)
· 마스터 컴포넌트는 동일 구조의 슬레이브 컴포넌트로 작업을 분할 후 슬레이브에서 처리한 결과물을 다시 돌려받는 방식으로 작업 수행
· 마스터 컴포넌트 - 모든 작업의 주체 / 슬레이브 컴포넌트 - 지시에 따라 작업 수행 후 결과 반환
· 장애 허용 시스템과 병렬 컴퓨팅 시스템에서 주로 사용
브로커 패턴
(Broker Pattern)
· 사용자가 원하는 서비스와 특성을 요청하면 브로커 컴포넌트가 요청에 맞는 컴포넌트와 사용자를 연결해줌
· 원격 서비스 호출에 응답하는 컴포넌트들이 여러 개 있을 때 사용
· 분산 환경 시스템에서 주로 활용
피어-투-피어 패턴
(Peer-To-Peer Pattern)
· 피어(Peer)를 하나의 컴포넌트로 간주하며 각 피어는 서비스를 호출하는 클라이언트 또는 서비스를 제공하는 서버 둘 다 될 수 있다.
· 클라이언트와 서버는 멀티스레딩 방식을 사용
이벤트-버스 패턴
(Event-Bus Pattern)
· 소스가 특정 채널에 이벤트 메시지를 발행하면, 해당 채널 구독한 리스너들이 메시지를 받아 이벤트를 처리하는 방식
· 4가지 주요 컴포넌트: ① 소스(Source): 이벤트 생성 ② 리스너(Listener): 이벤트 수행 ③ 채널(Channel): 이벤트의 통로 ④ 버스(Bus): 채널 관리
블랙보드 패턴
(Blackboard Pattern)
· 모든 컴포넌트들이 공유 데이터 저장소와 블랙보드 컴포넌트에 접근이 가능한 형태
· 컴포넌트들은 검색을 통해 블랙보드에서 원하는 데이터 탐색 가능
· 해결책이 명확하지 않은 문제 처리 시 활용
· 음성 인식, 차량 식별, 신호 해석 등에 주로 활용
인터프리터 패턴
(Interpreter Pattern)
· 프로그램 코드의 각 라인을 수행하는 방법을 지정하고, 기호마다 클래스를 갖도록 구성
· 특정 언어로 작성된 프로그램 코드를 해석하는 컴포넌트를 설계할 때 사용

  • 장애 허용 시스템(Fault Tolerancec System): 시스템 일부가 결함, 고장으로 기능이 정지되어도 해당 부분의 기능을 제외한 전체 시스템은 정상적으로 수행 가능한 시스템
  • 멀티스레딩(Multi Threading): 프로세스를 두 개 이상의 실행 단위로 구분하여 자원을 공유하며 병렬로 수행하는 기능
  • 메시지(Message): 객체들 간에 상호작용을 하는 데 사용되는 수단으로, 객체에게 행위를 지시하는 명령 또는 요구사항





3. 객체지향(Object-Oriented)

🔎 1) 객체지향: 현실 세계의 개체(Entity)를 하나의 객체(Object)로 만들어, 부품을 조립하여 제품을 만들 듯 객체들을 조립하여 소프트웨어를 개발하는 기법

  • 구조적 기법의 문제점으로 인한 소프트웨어 위기의 해결책

  • 소프트웨어 재사용 및 확장이 용이하여 고품질 소프트웨어를 빠르게 개발 가능하며 유지 보수가 쉽다.

  • 복잡한 구조를 단계적·계층적으로 표현하고, 멀티미디어 데이터 및 병렬 처리 지원 가능

  • 사용자와 개발자가 쉽게 이해할 수 있다.

    *구조적 기법의 문제점 	
     ① 개발공정에만 너무 집중하여 유지보수를 고려하지 않음
     ② 개발 시작 후 추가 요구사항에 대응하기 어려움
     ③ 재사용이 어려워 이전과 유사한 소프트웨어 개발에도 시간과 인력이 동일하게 소모
     
       

🔎 2) 객체(Object): 데이터와 데이터를 처리하는 함수를 묶어 놓은(캡슐화한) 하나의 소프트웨어 모듈

  • 데이터: 객체가 가지고 있는 정보 - 속성(Attribute), 상태, 변수, 상수, 자료 구조

  • 함수: 객체가 수행하는 기능, 객체가 갖는 데이터를 처리하는 알고리즘
    객체의 상태를 참조하거나 변경하는 수단 - 메소드(Method), 행위, 서비스, 동작(Operation), 연산

  • 객체의 특성

    • 객체는 독립적으로 식별 가능한 이름을 가지고 있다.
    • 객체가 가질 수 있는 조건인 상태(State)는 시간에 따라 변한다.
    • 객체와 객체는 상호 연관성에 의한 관계가 형성된다.
    • 객체가 반응할 수 있는 메시지의 집합을 행위라고 하며, 객체는 행위의 특징을 나타낼 수 있다.
    • 객체는 일정한 기억장소를 가지고 있다.
    • 메소드는 다른 객체로부터 메시지를 받아 정해진 기능을 수행한다.

🔎 3) 클래스(Class): 공통된 속성과 연산을 갖는 객체의 집합으로 객체의 일반적인 타입(Type)을 의미

  • 각 객체들이 갖는 속성과 연산을 정의하는 틀

  • 객체지향 프로그램에서 데이터를 추상화하는 단위

  • 클래스에 속한 각각의 객체를 인스턴스(Instance)라고 하며, 클래스로부터 새로운 객체를 생성하는 것을 인스턴스화(Instantiation)라고 함

  • 인스턴스(객체)는 공통 속성과 행위를 가지고 있으며, 속성에 대한 정보가 서로 달라서 동일 기능을 하는 여러 객체를 나타낸다.

  • 최상위 클래스: 상위 클래스를 갖지 않는 클래스

  • 슈퍼 클래스(Super Class): 특정 클래스의 상위(부모) 클래스

  • 서브 클래스(Sub Class): 특정 클래스의 하위(자식) 클래스


🔎 4) 캡슐화(Encapsulation): 데이터(속성)와 데이터를 처리하는 함수를 하나로 묶는 것

  • 인터페이스를 제외한 세부 내용이 은닉되어 외부 접근이 제한적이기 때문에 외부 모듈 변경으로 인한 파급 효과가 적다.

  • 캡슐화된 객체들은 재사용이 용이하다.

  • 자신을 제외한 상대 객체의 세부 내용은 알 필요가 없기 때문에 인터페이스가 단순해지고 객체 간 결합도가 낮아진다.


🔎 5) 상속(Inheritance): 이미 정의된 상의(부모) 클래스의 모든 속성과 연산을 하위(자식) 클래스가 물려받는 것

  • 하위 클래스는 따로 정의하지 않아도 상위 클래스의 모든 속성과 연산을 즉시 자신의 속성으로 사용할 수 있다.

  • 하위 클래스는 상속받은 속성과 연산 외에 새로운 속성과 연산을 첨가하여 사용할 수 있다.

  • 객체와 클래스의 재사용, 소프트웨어의 재사용(Reuse)을 높이는 중요한 개념

  • 다중 상속(Multiple Inheritance): 한 클래스가 두 개 이상의 상위 클래스로부터 속성과 연산을 다중으로 상속받는 것 (클래스 계층을 복잡하게 만들기 때문에 허용하지 않는 프로그래밍 언어도 있다.)


🔎 6) 다형성(Polymorphism): 메시지에 의해 객체(클래스)가 연산을 수행할 때, 하나의 메시지에 대해 각 객체가 가진 고유한 방법(특성)으로 응답할 수 있는 능력

  • 객체(클래스)들은 동일한 메소드명을 사용하며 같은 의미의 응답을 한다.

  • 하나의 함수나 연산자가 두 개 이상의 서로 다른 클래스의 인스턴스들을 같은 클래스에 속한 인스턴스처럼 수행할 수 있도록 하는 것

  • + 연산자: 숫자 클래스에서는 덧셈, 문자 클래스에서는 문자열의 연결 기능

  • 오버로딩(Overloading): 메소드 이름은 같지만 매개변수의 데이터 타입과 개수에 따라 여러 기능을 정의할 수 있다.

  • 오버라이딩(Overriding), 메소드 재정의 : 상위 클래스에서 정의한 메소드와 이름은 같지만 메소드 안의 실행 코드를 달리하여 자식 클래스에서 재정의 후 사용


🔎 7) 연관성(Relationship): 두 개 이상의 객체(클래스)들이 상호 참조하는 관계

종류의미특징
is member of연관화(Association)2개 이상의 객체가 상호 관련되어있음을 의미
is instance of분류화(Classfication)동일한 형의 특성을 갖는 객체를 모아 구성하는 것
is part of집단화(Aggregation)관련있는 객체들을 묶어 하나의 상위 객체 구성하는 것
is a일반화(Generalization)공통 성질들로 추상화한 상위 객체를 구성하는 것
is a특수화/상세화(Specialization)상위 객체를 구체화하여 하위 객체를 구성하는 것





4. 객체지향 분석 및 설계

🔎 1) 객체지향 분석의 개념

  • 객체지향 분석(OOA; Object Oriented Analysis): 사용자의 요구사항을 분석하여 이와 관련된 모든 클래스(객체), 속성, 연산, 관계 등을 정의하여 모델링하는 작업
  • 소프트웨어 개발을 위해 업무를 객체와 속성, 클래스와 멤버, 전체와 부분 등으로 나누어 분석하는 기법
  • 객체, 속성, 클래스, 연산을 표현해서 문제를 모형화 할 수 있게 해준다.
  • 객체는 클래스로부터 인스턴스화되고, 이 클래스를 식별하는 것이 목적이다.
     * 인스턴스: 어떤 클래스로부터 만들어진 객체
      * 인스턴스화: 클래스로부터 인스턴스를 생성하는 것

🔎 2) 객체지향 분석의 방법론

럼바우(Rumbaugh) 방법: 가장 일반적으로 사용되는 방법. 분석 활동을 객체 모델, 동적 모델, 기능 모델로 나누어 수행

부치(Booch) 방법: 미시적(Micro) 개발 프로세스와 거시적(Macro) 개발 프로세스를 모두 사용하는 방법. 클래스와 객체를 분석 및 식별하고 클래스의 속성과 연산 정의

Jacobson 방법: Use Case(사용 사례)를 강조하여 사용하는 분석 방법

Coad와 Yourdon 방법: E-R 다이어그램으로 객체의 행위를 모델링하는 방법. 객체 식별, 구조 식별, 주제 정의, 속성과 인스턴스 연결 정의, 연산과 메시지 연결 정의 등으로 구성

Wirfs-Brock 방법: 분석과 설계 간의 구분이 없고, 고객 명세서를 평가하여 설계 작업까지 연속적으로 수행하는 기법

	*Use Case: 사용자, 외부 시스템, 다른 요소들이 시스템과 상호 작용하는 방법을 기술한 설명

🔎 3) 럼바우(Rumbaugh) 분석 기법: 모든 소프트웨어 구성 요소를 그래픽 표기법으로 모델링하는 기법 (객체 모델링 기법 - OMT; Object-Modeling Technique)

  • 객체 모델링 → 동적 모델링 → 기능 모델링 순서로 분석 활동이 이루어짐
profile
개발 연습장

0개의 댓글