[정보처리기사 필기] 1과목 정리 - 설계

설계

"어떻게 실현할 것인가?"를 구체적으로 결정하는 활동

종류

	상위 설계	하위 설계
별칭	아키텍처 설계, 예비 설계	모듈 설계, 상세 설계
설계 대상	시스템 전체적인 구조	시스템의 내부 구조 및 행위
세부 목록	구조, DB, 인터페이스	컴포넌트, 자료 구조, 알고리즘

아키텍처 

• 시스템을 구성하는 컴포넌트와 컴포넌트 상호작용의 집합

서브 시스템

• 시스템의 복잡도를 줄이기 위하여 분할한 것

 

 

소프트웨어 아키텍처 설계 과정

• 1. 설계 목표 설정
  • 시스템 개발 방향을 명확히 하기 위해 설계에 영향을 주는 비즈니스 목표, 우선순위 등의 요구사항을 분석하여 전체 시스템의 설계 목표를 설정
• 2. 시스템 타입 결정
  • 시스템과 서브시스템의 타입을 결정
  • 설계 목표와 함께 고려하여 아키텍처 패턴을 선택
• 3. 아키텍처 패턴 적용
  • 아키텍처 패턴을 참조하여 시스템의 표준 아키텍처를 설계
• 4. 서브시스템 구체화
  • 서브시스템의 기능 및 서브시스템 간의 상호작용을 위한 동작과 인터페이스를 정의
• 5. 검토
  • 아키텍처가 설계 목표에 부합하는지, 요구사항이 잘 반영되었는지, 설계의 기본 원리를 만족하는지 등을 검토

 

미들웨어(Middleware) 아키텍처

• 소프트웨어 컴포넌트를 연결하기 위한 준비된 인프라 구조 제공
• 일반적이며 환경에 따라 바꿀 수 있는 융통성을 가짐
  • 애플리케이션의 여러 컴포넌트들을 연결 방법 제시
  • 여러 컴포넌트를 1대1, 1대다, 다대다 등 여러 가지 연결 형태로 연결
  • 사용자는 미들웨어를 인지하지 못하고 애플리케이션과 상호작용

• 종류

 

품질 

소프트웨어의 기능, 성능, 만족도 등 소프트웨어에 대한 요구사항이 얼마나 충족하는가를 나타내는 소프트웨어 특성의 총채

• 사용자의 요구사항을 충족 시킴으로써 확립

관련 표준

• ISO/IEC 9126 - 소프트웨어의 품질 특성과 평가를 위한 표준 지침
• ISO/IEC 25010 - 소프트웨어 제품에 대한 국제 표준
• ISO/IEC 12119 - ISO/IEC 9126을 준수한 품질 표준, 테스트 절차를 포함하여 규정
• ISO/IEC 14598 - 소프트웨어 품질의 측정과 평가에 필요한 절차를 규정, 개발자, 구매자, 평가자 별로 수행해야 할 제품 평가 활동을 규정함.

품질 속성 종류

품질 제약사항은 설계에 대한 목표가 될 수 있음

비기능적인 요구를 설계 목표로 구체적으로 명시

• 이를 만족시키기 위하여 설계 안을 만들고 그 중 최적 안을 골라내는 작업

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

• 소프트웨어 아키텍처가 이해 관계자들이 요구하는 수준의 품질을 유지 및 보장 할 수 있게 설계되었는지를 확인하기 위해 품질 평가 요소들을 시스템 측변, 비즈니스 측면, 아키텍처 측면으로 구분하여 구체화 시겨 놓은 것임
• 시스템 측면
  • 성능, 보안, 가용성, 기능성, 사용성, 변경 용이성, 확장성 등
• 비즈니스 측면
  • 시장 적시성, 비용과 혜택, 예상 시스템 수명 등
• 아키텍처 측면
  • 개념적 무결성, 정확성, 완결성, 구축 가능성 등

 

소프트웨어 아키텍처 설계의 기본 원리

단계적 분해(Stepwise Refinement)

• Niklaus Wirth에 의해 제안된 하양식 설계 전략
• 문제를 상위의 중요 개념으로부터 하위의 개념으로 구체화 시키는 분할 기법
• 단계
  • 1. 문제를 기본 단위로 나눔
  • 2. 독립된 문제로 구별
  • 3. 구분된 문제의 자세한 내용은 가능한 한 뒤로 미룸
  • 4. 구체화 작업이 계속 점증적으로 일어난다는 것을 보임

추상화(Abstraction)

• 문제의 전체적이고 포괄적인 개념을 설계한 후 차례로 세분화하여 구체화시켜 나가는 것
  • 대상에 대하여 특정한 목적에 관련된 정보에 집중, 나머지 정보는 무시하는 관점
• 데이터나 절차적인 동작 관점으로 정의
  • ex. 클라이언트와 서버의 정보교환을 주고 받는 메시지의 추상화
• 유형
  • 과정 추상화
  • 데이터 추상화
  • 제어 추상화

정보 은닉(Information Hiding)

• 한 모듈 내부에 포함된 절차와 자료들의 정보가 감추어져 다른 모듈이 접근하거나 변경하지 못하도록 하는 기법
• 캡슐화(Encapsulation)
  • 추상화된 대상이 제공하는 서비스를 쉽게 접근하게 하는 개념
  • 서비스를 수행하는 핵심만을 노출
  • ex. 클래스의 접근 지정자(private, protected, public)

모듈화(Modularity)

• 소프트웨어의 성능을 향상 시키거나 시스템의 수정 및 재사용, 유지 관리 등이 용이하도록 시스템의 기능들을 모듈 단위로 나누는 것
  • 소프트웨어를 패키지 or 클래스로 나누는 것
• 설계 과정에 독립된 모듈들로 분할하기 위하여 모듈 선택에 사용하는 기준
  • 결합도(Coupling) - 모듈 간의 관계
    • 모듈 간의 결합도는 약하게
      • 불필요한 모듈간 관계 제거
      • 필수적인 모듈 관계를 줄임
    • 모듈간의 상호 의존하는 정도를 의미
    • 모듈은 하나의 블랙 박스로 다른 모듈과의 독립성이 높아야함
      • 다른 모듈과의 결합도가 약해야함
    • 의존성의 종류
      • 제어 의존성(Control Dependence)
      • 자료 의존성(Data Dependence)
    • 결합도가 약한 시스템은 유지보수가 용이함
      • 시스템에 대한 이해가 용이
      • 파급 효과(Ripple Effect) 예방
  • 응집도(Cohesion) - 모듈 내 기능/요소들이 갖는 관계
    • 모듈의 응집도는 강하게
      • 강할 수록 품질이 높고 약할 수록 품질이 낮음
    • 모듈 안의 구성 요소들이 공동의 목적을 달성하기 위하여 관련되어 있는 정도
    • 하나의 모듈은 전체 시스템이 갖는 여러 기능 중에 하나의 기능을 갖도록 설계
    • 모듈 내의 모든 요소는 하나의 목적을 가지고 있는 것이 바람직함

 

모듈 결합도 유형

 

모듈 응집도 유형

 

객체지향 설계원리(SOLID)

• 객체지향 설계 원칙은 시스템 변경이나 확장에 유연한 시스템을 설계하기 위해 지켜야 할 다섯 가지 원칙임

단일 책임의 원리(Single Responsibility Principle, SRP)

• 클래스의 역할과 책임을 단일화 하여 클래스를 변경해야 할 이유를 하나로 제한(객체는 하나의 책임만을 가짐)

개발 폐쇄의 원리(Open-Closed Principle, OCP)

• 기존의 코드를 변경하지 않고 기능을 추가할 수 있도록 설계해야 한다는 원칙
• SW개체(클래스, 모듈, 기능 등)
  • 확장을 위해서 열려 있어야 함
  • 수정을 위해서 닫혀 있어야 함
• 상속 - 다형성이 적용되어 서로 대체할 수 있는 인터페이스를 구현

리스코프 교체의 원리(Liskov Substitution Principle, LSP)

• 자식 클래스는 최소한 자신의 부모 클래스에 서 가능한 행위는 수행할 수 있어야 한다는 설계 원칙
  • 자식 클래스는 클라이언트의 관점에서 기능을 손상 시키지 않는 방식으로 상위 클래스 메소드를 대체

인터페이스 분리의 원리(Interface Segregation Principle, ISP)

• 자신이 사용하지 않는 인터페이스와 의존 관 계를 맺거나 영향을 받지 않아야 한다는 원칙
  • 비만 인터페이스(fat interface)
  • 오염된 인터페이스(polluted interface)

의존관계 역전의 원리(Dependency Inversion Principle, DIP)

• 각 객체들 간의 의존 관계가 성립될 때, 추상 성이 낮은 클래스보다 추상성이 높은 클래스 와 의존 관계를 맺어야 한다는 원칙
• 높은 수준의 모듈 - 복잡한 논리를 제공
  • 재사용 가능
  • 낮은 수준의 모듈 변경에 의해 쉽게 영향을 받지 않음
• 구체화 된 모듈이 추상화 된 모듈에게 의존이 역전되도록 설계