[정보처리기사] 1과목 - 소프트웨어 설계(2)
애플리케이션 설계
소프트웨어 아키텍처
- SW의 골격이 되는 기본 구조, SW를 구성하는 요소들 간의 관계를 표현하는 시스템 구조
- 기본 원리: 모듈화, 추상화, 단계적 분해, 정보은닉
모듈화(Modularity)
- SW 성능 향상, 시스템의 수정 및 재사용, 유지 관리 등이 용이하도록 시스템의 기능들을 모듈단위로 분할
- 모듈의 크기가 너무 작으면 개수가 많아져 통합 비용 증가
- 모듈 크기가 너무 크면 하나의 개발 비용이 많이 소비
추상화(Abstraction)
- 문제의 전체적이고 포괄적인 개념 설계 후 차례로 세분화 해 구체화
- 유형: 과정 추상화, 데이터 추상화, 제어 추상화
단계적 분해(Stepwise Refinement)
- 문제를 상위 중요 개념으로부터 하위 개념으로 구체화하는 분할 기법
- 추상화의 반복으로 세분화
정보은닉(Information Hiding)
- 한 모듈 내부에 포함된 절차와 자료들의 정보가 감추어져 다른 모듈이 접근하거나 변경하지 못하도록 함
- 모듈을 독립적으로 수행할 수 있어 수정, 시험, 유지 보수 등이 용이
아키텍처 패턴
- 아키텍처 설계 시 참조할 수 있는 전형적인 해결 방식
- 종류: 레이어 패턴, 클라이언트-서버 패턴, 파이프-필터 패턴, 모델-뷰-컨트롤러 패턴 등
객체지향(Object-Oriented)
- 현실 세계의 개체를 기계 부품처럼 하나의 객체로 만들어 객체들을 조립해 SW 개발
- 특징: SW 재사용 및 확장 용이, 쉬운 유지보수, 복잡한 구조를 단계적이고 계층적으로 표현
- 구성요소: 객체, 클래스, 캡슐화, 상속, 다형성
객체(Object)
- 데이터와 데이터를 처리하는 함수를 묶어 캡슐화한 하나의 SW 모듈
- 특성: 독립적으로 식별 가능한 이름 소유, 객체 간 상호연관성에 의해 관계 형성
- 데이터: 객체가 가지고 있는 정보 (속성/상태/변수/상수/자료구조)
- 함수: 객체가 수행하는 기능 (메소드, 서비스, 동작, 행위)
- 상태(State): 객체가 가질 수 있는 조건
클래스(Class)
- 공통된 속성과 연산을 갖는 객체의 집합으로 객체의 일반적인 타입을 의미
- 각각의 객체들이 갖는 속성과 연산을 정의하고 있는 틀
- 인스턴스(Instance): 클래스에 속한 각각의 객체
캡슐화(Encapsulation)
- 데이터와 함수를 하나로 묶은 것
- 인터페이스를 제외한 세부 내용이 은폐되어 외부에서 접근이 제한적
상속(Inheritance)
- 상위 클래스의 모든 속성과 연산을 하위 클래스가 물려받는 것
- 다중 상속: 한 개의 클래스가 두 개 이상의 상위 클래스로부터 상속받는 것
다형성(Polymorphism)
- 하나의 메시지에 대해 각 클래스가 가지고 있는 고유한 특성으로 응답할 수 있는 능력
- 객체지향의 오버로딩 개념
모듈
- 모듈화를 통해 분리된 시스템의 각 기능들
- 서브루틴, 서브시스템, SW 내의 프로그램, 작업 단위 등과 같은 의미로 사용
- 단독으로 컴파일 가능하며 재사용 가능
- 독립성을 높이기 위해서는 결합도는 약하게, 응집도는 강하게 해야함
- 독립성이 높을수록 모듈을 수정해도 다른 모듈에 영향이 없어 요류 해결이 용이
결합도(Coupling)
- 모듈 간 상호 의존도 또는 모듈 사이 연관 관계
- 결합도가 약할수록 품질이 높고, 강할수록 품질이 낮음
- 내용 결합도 > 공통 결합도 > 외부 결합도 > 제어 결합도 > 스탬프 결합도 > 자료 결합도
응집도(Cohesion)
- 정보 은닉 개념을 확장한 것으로 내부 요소들의 서로 연관 정도
- 독립적 기능 정의 정도
- 응집도와 품질은 비례관계
- 기능적 응집도 > 순차적 응집도 > 통신적 응집도 > 절차적 응집도 > 시간적 응집도 > 논리적 응집도
팬인(Fan-In)/팬아웃(Fan-Out)
- 팬인: 호출하는 모듈 수
- 팬아웃: 호출되는 모듈 수
- 팬인이 높다? 재사용 측면 설계가 잘 되었지만, 단일 장애점 중점 관리 및 테스트 필요
- 팬아웃이 높다? 불필요한 호출 검토, 단순화 기능 여부 검토
- 시스템 복잡도 최적화: 팬 인을 높게, 팬아웃을 낮게
공통 모듈
- 여러 프로그램에서 공통적으로 사용할 수 있는 모듈
- 명세 기법: 정확성, 명확성, 완전성, 일관성, 추적성
재사용(Reuse)
- 비용과 시간을 절약하기 위해 이미 개발된 기능들을 파악하고 재구성하여 새로운 시스템 개발에 사용하기 적합하도록 최적화 시키는 작업
- 외부 모듈과 결합도는 낮고 응집도는 높아야 함
인터페이스 설계
시스템 인터페이스 요구사항 분석 절차
1. 요구사항 선별
2. 요구사항 관련 자료 준비
3. 요구사항 분류
4. 요구사항 분석 및 명세서 구체화
5. 요구사항 명세서 공유
요구사항 검증
- 인터페이스 설계 및 구현 전 요구사항에 명시되어 있는 사용자의 요구사항들이 실제로 실현 가능한지 확인
- 요구사항 검토 계획 수립 -> 검토 빛 오류 수정 -> 베이스라인 설정
- 검증 항목: 완전성, 일관성, 명확성, 기능성, 검증 가능성, 추적 가능성, 변경 용이성
검증 방법
- 요구사항 검토: 담당자들이 수작업으로 분석
=> 동료 검토: 명세서 작성자의 설명을 들으며 동료들이 검토
=> 워크 스루: 검토 회의 전 미리 명세서를 배포하고 사전 검토 후 짧은 회의를 통해 결함을 발견
=> 인스펙션: 명세서 작성자를 제외한 전문가가 명세서를 검토
- 프로토 타이핑: 실제 개발품의 견본품을 만들어 예측
- 테스트설계: 테스트 케이스를 생성해 테스트
- CASE 도구 활용: 일관성 분석을 통해 요구사항의 변경사항 추적, 분석, 관리, 표준 준수 여부 확인