[정보처리기사] 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 도구 활용: 일관성 분석을 통해 요구사항의 변경사항 추적, 분석, 관리, 표준 준수 여부 확인

 

 

참고 자료

---

https://powerdev.tistory.com/49?category=878088

https://1d1cblog.tistory.com/184?category=847034