[Engineer Information Processing] 1. 소프트웨어 설계

정보처리기사를 취득하기 위해 공부하는 과정에 작성한 ‘소프트웨어 설계’ 관련 정리이다.

소프트웨어 공학과 개발 방법론

소프트웨어 개념과 소프트웨어 공학

• 소프트웨어 : 프로그램, 자료구조, 개발 문서
  • 소프트웨어의 특징 : 상품성, 복잡성, 변경 가능성, 복제성, 순응성, 비가시성
  • 소프트웨어의 분류 : 시스템 소프트웨어, 응용 소프트웨어, 미들웨어 소프트웨어
• 시스템의 기본 요소 : 입력, 처리, 출력, 제어, 피드백
• 소프트웨어 공학 : 경제적으로 신뢰도 높은 소프트웨어를 만들기 위한 체계
  • 소프트웨어의 등장 배경 : 소프트웨어의 위기 (개발 비용 및 기간 증가, 개발 인력 부족, 성능 및 신뢰성 부족)
  • 소프트웨어 공학의 분류 : 개발 생명주기 모형, 프로세스 모형, 품질 관리, 유지보수
  • 소프트웨어 공학의 기본 원칙 : 최신 기술·언어, 높은 신뢰성·편리성·유지보수성·안정성·보안, 낮은 비용, 문서화
  • 소프트웨어 공학의 계층 구조 : 도구, 방법론, 프로세스
  • 소프트웨어 공학의 목표 : 최소 비용으로 단기간에 시스템에 적합한 소프트웨어 개발, 품질·생상성·신뢰성 향상

소프트웨어 재공학

• 재공학 : 소프트웨어 위기를 개발 생산성이 아닌 유지보수의 생상성으로 해결
  • 재공학의 장점 : 개발 시간·비용·실패 감소, 품질·생산성 향상, 개발 지식 공유 가능
  • 재공학의 과정 : 분석 → 재구성 → 역공학 → 이식
    1. 분석 : 기존 소프트웨어 명세서 확인 및 동작 이해를 통한 재공학 대상 선정
    2. 재구성 : 소프트웨어 구조를 향상시키기 위해 코드를 재구성
    3. 역공학 : 원시 코드를 분석해 소프트웨어 관계 파악 및 기존 시스템의 정보 재발견
    4. 이식 : 기존 소프트웨어 시스템을 새로운 기술 및 환경에 맞게 변환
• 재사용의 기본 기술 : 생성 중심 (모듈화), 합성 중심 (모델화)
• 리팩토링 : 소프트웨어를 보다 쉽게 이해할 수 있고, 적은 비용으로 수정할 수 있도록 동작 변환 없이 내부 구조 변경
• CASE : 소프트웨어 개발 과정에서 사용되는 요구 분석, 설계, 구현, 검사, 디버깅 과정을 자동화
  • CASE 기능 : 빠른 개발, 품질 향상, 생명 주기 통합·자동화, 문서화·명세화를 위한 그래픽, 자료 흐름도·개발 모형
  • CASE의 분류 : 상위 CASE (요구 분석·설계 지원), 하위 CASE (코드 작성 및 테스트 지원), 통합 CASE
  • 요구사항 분석과 CASE 도구 : SREM (RSL, REVS, PSL/PSA)
    • SADT : 구조적 요구 분석을 위한 블록 다이어그램 채택

소프트웨어 설계 방법론

• 소프트웨어 생명 주기 (SDLC) : 요구 분석 → 설계 → 구현 → 테스트 → 운용 및 유지보수
  • 폭포수 모형 : 소프트웨어 개발 과정의 각 단계가 순차적으로 진행되는 고전적 생명주기 모형
  • HIPO : 입력, 처리, 출력으로 구성되는 설계 및 문서화를 위한 구조적 분석 및 설계 방법론 기법
    (가시적 도표, 총체적 다이어그램, 세부적 다이어그램)
  • 나선형 모형 : 나선을 따라 돌면서 각 개발 순서를 반복하여 수행하는 점증적 생명주기 모형
    계획 수립 → 위험 분석 → 개발과 검증 → 고객 평가 및 다음 단계 수립
  • 프로토타입 모형 : 실제 개발될 시스템의 시제품을 미리 만들어 최종 결과물을 예측
  • 상향식 설계vs하향식 설계 : 쉬운 기능 추가 및 높은 모듈 독립성vs쉬운 통합 및 명확한 설계
  • V-Model : 폭포수 모형에 세부적인 시스템 검증과 테스트 작업을 강조
• 에자일 개발 방법론 : 소프트웨어 개발 중 설계 변경에 신속히 대응해 요구 사항 수용
  • 에자일의 목표 : 소프트웨어가 잘 실행되는 것을 가치를 두며, 소프트웨어 배포 시차를 최소화하고자 함
  • 에자일의 특징 : 짧은 릴리즈, 점증적 설계, 사용자 참여, 문서 최소화, 비공식적인 커뮤니케이션의 변화
  • 에자일의 종류 : XP, SCRUM, 린 (Lean), 동적 시스템 개발 방법론 (DSDM), 기능 중심 개발 (FDD), 크리스탈 (Crystal), 적응형 소프트웨어 개발 방법론 (ASD), 학습 에자일 배포 (DAD) 칸반 (Kanban)
  • 에자일 선언문 : 절차·도구 < 소통·피드백, 문서 < 소프트웨어, 계약 협상 < 고객과의 협업, 계획 < 변경 대응

익스트림 프로그래밍 (XP), 스크럼 (SCRUM)

• XP : 요구에 맞는 양질의 소프트웨어를 신속히 제공하는 것을 목표 (예측성 < 적응성)
  • XP 핵심 가치 : 의사소통, 단순성, 피드백, 용기와 존중
  • XP 절차 : 사용자 절차, 릴리즈 계획 수립, 주가, 승인 검사, 소규모 릴리즈
    
  • XP의 12가지 프랙티스 : Pair Programming, Planning Game, Test-Driven Development, Whole Team, Continuous Process, Small Releases, Coding Standards, Collective Code Ownership, Simple Design, System Metaphor, Sustainable Pace
• SCRUM : 요구사항 변경에 신속히 대처할 수 있는 반복적이고 점진적인 팀 중심 소프트웨어 개발 방법론
  • SCRUM 5가지 가치 : 확약, 전념, 정직, 존중, 용기
  • SCRUM 역할 : 제품 책임자, 스크럼 마스터, 스크럼 팀
  • SCRUM 절차 : 제품 백로그, 스프린트, 스프린트 일일 미팅, 스프린트 플래닝 미팅, 스프린트 리뷰, 스프린트 회고
    
    • 스프린트 : 작은 단위의 개발 업무를 단기간에 개발, 2~4주마다 이해 관계자에 진척도 보고

현행 시스템 분석과 요구 분석

현행 시스템 분석

• 현행 시스템 분석 : 어떤 하위 시스템으로 구성되어 있는지 파악하는 절차
  • 현행 시스템 분석의 목적 : 개발 시스템의 개발 범위를 확인하고 이행하기 위한 방향성 설정
  • 시스템 아키텍처 : 상위 시스템과 하위 시스템이 어떤 관계로 상호 작용하는지 각 동작 원리와 구성을 표현한 것
  • 현행 시스템 파악 절차 : 시스템 및 인터페이스 → 소프트웨어 아키텍처 → 하드웨어 및 네트워크 구성
    • 시스템 구성 : 기간 업무, 지원 업무로 구분
    • 시스템 기능 : 주요 기능과 하부 기능으로 계층형으로 표시
    • 인터페이스 현황 : 단위 업무 시스템 및 시스템 간 통신하는 데이터를 명시
    • 소프트웨어 현황 : 소프트웨어 라이선스 적용 방식 (사이트, 서버, 프로세서, 코어, 사용자 수)
    • 하드웨어 현황 : 서버 사양, 서버 이중화 여부 파악
    • 네트워크 현황 : 시스템의 네트워크 구성 형태를 그림으로 표현
    • 개발 기술 환경 분석 : 플랫폼, OS, DBMS, 미들웨어 분석
• 플랫폼 : 응용 프로그램을 실행하기 위한 하드웨어와 소프트웨어의 결합
  • 플랫폼의 종류 : 운영체제, 어플리케이션, 클라우드, 데이터베이스, 개발, 모바일, IoT, 인터넷 서비스, 개발…
  • 플랫폼 성능 특성 분석 항목 : 경과 시간, 사용률, 응답 시간, 가용성
  • 플랫폼 성능 특성 분석 방법 : 성능 테스트, 사용자 인터뷰, 문서 점검
  • 플랫폼 사용할 때의 이점 : 개발·운영·유지보수 비용 감소, 안정성·보안성 향상, 여러 플랫폼·커뮤니티 지원
• OS : HW·SW 자원 관리 및 공통 서비스 제공, 사용자와의 인터페이스 제공
  • OS 분석 항목 : 종류, 버전, 패치 일자, 백업 주기 분석
  • OS 고려 사항 : 가용성, 성능, 기술 지원, 주변 기기, 구축 비용
  • OS 메모리 누수 : 실행 소프트웨어가 정상 종료되지 않고 남아있는 증상
• 오픈소스 라이선스 : GNU, GNU GPLv1, BSD, Apache 2.0, GNU Affero General Public License v3.0, Eclipse Public License 2.0, Mozilla Public License 2.0, Creative Commons
• DBMS : 응용 프로그램과 데이터의 중재자로서 모든 응용 프로그램들이 데이터베이스를 공유할 수 있도록 관리
  • DBMS 목적 : 종속성 및 중복성 문제를 해결하기 위해 제안
  • DBMS 종류 : Oracle, MSSQL, MySQL, SQLite, MongoDB, Redis
  • DBMS 분석 항목 : 가용성, 성능, 기술 지원, 상호 호환성, 구축 비용

요구사항 개발

• 요구공학 : 사용자 요구가 반영된 시스템 개발을 위해 사용자 요구를 추출, 분석, 명세, 검증, 관리
  • 요구사항 베이스라인 : 이해 당사자 간의 명시적 합의, 프로젝트 목표 달성 여부를 확인하는 기준
  • 요구사항 분류 : 기능 요구사항과 비기능 요구사항을 구분하고 우선순위 여부를 확인
    • 기술 내용에 따른 분류 : 기능 요구사항 (사용자가 원하는 기능)vs비기능 요구사항 (수행 환경, 제약 조건)
    • 기술 관점 및 대상에 따른 분류 : 시스템 요구사항vs사용자 요구사항
• SWEBOK 기반 요구사항 개발 프로세스 : 도출 → 분석 → 명세 → 검증
  • 요구사항 도출 : 현재 상태를 파악하고 문제를 정의하고 목표를 도출
  • 요구사항 분석 : 소프트웨어가 어떻게 상호 작용하는지 이해하고, 요구사항 정의를 도출 및 문서화
    • 분석 기법 : 사용자 의견 청취, 사용자 인터뷰, 문서 및 모델 분석, 설문 조사
    • 분석 단계 : 문제 인식 → 전개 → 평가 및 종합 → 검토 → 문서화
  • 요구사항 명세 : 시스템 정의 및 요구사항, 소프트웨어 요구사항을 문서화
    • 명세 기법 : 정형 명세 (수학적 + 정확한 표현, 명세·구현의 일치)vs비정형 명세 (자연어 + 작성·이해 용이, 다양한 전달 방법)
  • 요구사항 확인 : 문서로 만들어진 내용을 확인 및 검증
  • 요구사항 관리 : 요구사항 명세서와 관련된 변경 사항을 추적 및 관리
• 요구사항 관리 도구의 필요성 : 프로세스 효율성 재고 및 관리·분석·추적·평가·의사소통 용이
• 요구사항 할당 : 요구사항을 만족시키기 위한 아키텍처 구성 요소를 식별

요구사항 확인 기법과 FTR

• 요구사항 확인 기법 : 인터뷰, 설문 조사, 시나리오, 스토리보드, 워크숍, 브레인스토밍, 분석 모델링
  • 프로토타이핑 : 도출된 요구사항을 토대로 시제품을 제작해 대상 시스템과 바교하여 추가 요구사항을 재작성
    • 프로토타이핑 절차 : 요구사항 분석 → 설계 → 개발 → 검토·피드백 → 프로토타입 정제 → 요구사항 검증
  • 모델 검증 : 분석 단계에서 개발된 모델의 품질을 검증
    • 정적 분석 : 객체 모델에서 객체 간에 존재하는 의사소통 경로를 검증하기 위해 명세의 일관성·정확성 확인
    • 동적 분석 : 모델을 검증하기 위해 소스 코드를 직접 실행해 메모리 누수 현황 및 스레드 결함 분석
  • 요구사항 검토 : 여러 검토자자가 에러, 잘못된 가정, 불명확성, 표준과의 차이를 탐색
  • 인수 테스트 : 소프트웨어가 요구사항을 만족하는지 확인하기 위한 테스트
    • 인수 테스트 종류 : 계약 인수 테스트, 규정 인수 테스트, α·β검사, 사용자 인수 테스트, 운영 인수 테스트
    • 인수 테스트 절차 : 계획 → 설계 → 구현 → 검토 → 수행 → 완료
  • 정형 기술 검토 : 소프트웨어 개발 산출물 대상 요구사항 일치 여부·표준 준수·결합 발생 여부를 검토하는 정적 분석
    • 정형 기술 검토 특징 : 구조화된 절차, 전문가의 참여 필요, 개발 초기 적용 가능, 문서화의 중요성
    • 정형 기술 검토 지침 : 의제 및 범위 유지, 참가자 수 제한, 체크리스트 및 일정 할당, 검토에 집중, 논쟁 제한, 명확한 문제 영역

UML과 럼바우 분석 기법

• 개념 모델링 : 요구사항을 이해하기 쉽도록 실 세계의 상황을 단순화하여 개념적으로 표현한 모델을 생성하는 과정
  • 개발 대상 도메인의 엔티티 및 관계와 종속성을 반영
• UML : 객체지향 소프트웨어 개발 과정의 모델링 기술 및 방법론을 통합한 범용 모델링 언어
  • UML 특성 : 시각화, 문서화, 명세화, 구축, 확장성, 표준화된 언어
  • UML 관점 : 기능적 (유스케이스 다이어그램), 정적 (클래스 다이어그램), 동적 (시퀀스·상태 다이어그램)
  • UML 구성 : 사물 (객체 간의 관계 형성 대상), 관계 (객체 간의 연관성 표현), 다이어그램 (격체의 관계 도식화)
    • 스테레오타입 : UML 구성 외에 추가적인 확장 요소를 표현 (<<>>으로 포현)
    • UML 접근 제어자 : public (+), private (-), protected (#), package (~)
    • UML 표현 : 1 (1 객체 연결), * 또는 0..* (0이거나 0 이상 객체 연결), 1..* (1이거나 1 이상 객체 연결), 0..1 (0이거나 1 객체 연결), 1, 3, 5 (1이거나 3이거나 6 객체 연결), n (n개 객체 연결), m..* (m이거나 m개 이상 객체 연결)
• 럼바우 객체지향 분석 (= 객체 모델링 기법) : 소프트에어 구성 요소를 그래픽으로 모형화
  • 럼바우 객체지향 분석 절차 : 객체 모델링 (객체 다이어그램) → 동적 모델링 (상태도) → 기능 모델링 (자료 흐름도)
    • 객체 모델링 : 시스템에서 요구되는 객체를 찾아 속성, 연산, 관계를 규정하여 객체를 다이어그램으로 표시
    • 동적 모델링 : 제어 흐름, 상호 작용, 동작 순서 등의 상태를 시간 흐름에 따라 상태 다이어그램으로 표시
    • 기능 모델링 : 여러 프로세스 간 자료 흐름 표시 (어떤 데이터를 입력해 어떤 결과를 가져올 수 있을지 표현)

UML 다이어그램

• 구조 다이어그램 : 시스템 구조와 구성 요소 간의 관계를 시각적으로 표현
  • 클래스 다이어그램 : 시스템 내 클래스·인터페이스 및 그 관계를 시각적 표현, 클래스 속성·메소드로 구현 정보 제공
  • 객체 다이어그램 : 특정 시점의 객체 간의 관계 및 상태 표현, 클래스들이 어떻게 실제로 인스턴스화되는지 표현
  • 복합체 구조 다이어그램 : 시스템의 복잡한 구조를 모델링하기 위해 객체의 내부 구조 및 상호 작용을 표현
  • 배치 다이어그램 : 시스템의 물리적 배치 및 구성, 하드웨어와 소프트웨어 간의 관계를 표현
  • 컴포넌트 다이어그램 : 소프트웨어 시스템의 컴포넌트의 구조 및 관계 표현, 어떤 기능을 수행하는지 나타내 모듈화 및 재사용에 유용
  • 패키지 다이어그램 : 시스템을 구성하는 여러 개체를 그룹화하여 표현하여 모듈화나 구조화를 표현
• 행위 다이어그램 : 시스템 내 상호작용, 메시지 흐름, 객체 간의 상호 작용와 같은 시스템의 동작을 그래픽으로 표현
  • 유스케이스 다이어그램 : 시스템 및 시스템과 사용자 간의 상호 작용을 시각적으로 표현
  • 액티비티 다이어그램 : 시스템 내부 프로세스나 작업 흐름을 시각적으로 표현
  • 상태 머신 다이어그램 : 객체의 생명주기와 상태 변화를 상태, 이벤트, 전이로 구성하여 표현
  • 협력 다이어그램 : 객체들이 서로 메시지를 주고받는 과정을 객체, 메시지로 표현
  • 상호 작용 다이어그램 : 유스케이스를 수행하기 위해 객체들이 어떻게 상호 작용하는지 객체 간 메시지를 통해 표현
    • 순차 다이어그램 : 시스템 구성 요소들이 어떻게 상호 작용하는지 객체, 생명선, 실행, 메시지, 시간으로 표현
    • 통신 다이어그램 : 시스템에서 객체 간의 통신을 객체 간의 관계 및 역할, 메시지 흐름, 시간 흐름으로 표현
• 클래스 다이어그램 : 시스템을 구성하는 객체 간의 관계를 추상화한 모델을 논리적 구조로 표현
  
• 유스케이스 다이어그램 : 사용자 요구를 기능적 측면에서 기술하기 위해 액터와 유스케이스로 구성하여 표현
  
  • 유스케이스 다이어그램 요소 : 시스템 경계, 액터, 유스케이스, 관계 (연관, 포함, 확장, 일반화)
  • 유스케이스 다이어그램 작성 단계 : 액터 식별 → 유스케이스 식별 → 관계 정의 → 유스케이스 구조화
  • 유스케이스 다이어그램 관계 표현 : UML 관계를 통해 표현
    
    • UML 연관 관계 : 한 사물의 객체가 다른 사물의 객체와 연결된 것을 표현 (연관 관계명, 역할명)
    • UML 의존 관계 : 연관 관계와 동일하나, 메소드드를 사용할 때처럼 짧은 시간만을 유지
    • UML 일반화 관계 : 객체지향의 상속 관계를 표현 (하위 클래스와 상위 클래스 간의 관계를 표현)
    • UML 집합 관계 : 전체 객체와 부분 객체 간의 관계를 표현
    • UML 포함 관계 : 부분 객체가 전체 객체에 속하는 강한 집합 연관의 관계를 표현
    • UML 실체화 관계 : 인터페이스와 실제 구현된 일반 클래스 간의 관계로 존재하는 행동에 대한 구현을 표현

UI 설계

UI 환경 분석

• UI 표준을 위한 환경 분석
  • 사용자 경향 분석 : 기존 UI 경향을 숙지해 현재 UI의 단점 작성
  • 기능 및 설계 분석 : 기능 조작성, 오류 방지, 최소한의 조작으로 업무 처리가 가능한지, UI의 정보 전달이 어떤지
• UI 요구사항 요소 : 데이터 요구, 기능 요구, 제품 및 서비스 품질, 제약 사항
• 정황 시나리오 : 개발 서비스의 초기 모양 상상 (사용자 관점에서 높은 수준·낙관적 상황을 가정해 기초 시나리오 작성)

UI 표준과 지침

• UI : 인간, 디지털 기기, 소프트웨어 간에 의사소통이 가능하도록 만든 매개체
  • UI 분야 : 표현, 정보 제공 및 전달, 기능
    → 웹 디자인, 모바일 앱 디자인, 게임 디자인, 산업 디자인, 기계 학습 인터페이스
  • UI 개발 시스템이 가져야할 기능 : 사용자의 입력 검증, 에러 및 에러 메시지 처리, 도움과 프롬프트 제공
• UI 설계 원칙 : 직관성, 유효성, 학습성, 유연성
• UI 설계 지침 : 사용자 중심, 일관성, 단순성, 가시성, 표준화, 접근성, 결과 예측 가능, 명확성, 오류 발생 해결
• UI 구현 표준 : 화면 구성, 화면 이동과 같이 화면에서 공통적으로 갖춰어야 할 최소의 UI 요소 및 배치 규칙
  • UI 설계 시 오류 지침 : 명확하고 이해하기 쉬운 메시지, 문제 해결 방법 제공, 시각적 강조 및 사용자 경험 고려
  • UI 표준 구성 : 전체 UX 원칙, 정책·철학, UI 스타일 가이드, UI 패턴 모델 정의, UI 표준 수립 조직 구성
• UX : 제품을 대상으로 직·간접적으로 사용하면서 느끼고 생각하는 지각·반응·행동과 같은 모든 경험

UI 설계

• UI 설계 단계 : 문제 정의 → 사용자 모델 정의 → 작업 분석 → 컴퓨터 오브젝트·기능 정의 → UI 정의 → 디자인 평가
  • UI 메뉴 구조 설계, 내부 및 외부 화면과 폼 설계, UI 검토 수행
  • UI 요구사항 정의 : 시스템 구조, 사이트맵, 프로세스 정의, 화면 설계
• UI의 종류 : CLI, GUI, NUI, OUI, TUI, WUI, Touch UI
• UI 설계 도구
  • 와이어 프레임 : 화면 단위로 레이아웃을 설계
  • 목업 : 실물 크기의 정적 모형을 시각적으로 구현
  • 스토리보드 : 사용자, 작업, 인터페이스 간의 상호 작용을 시각화
• UI의 요소 : 라디오 버튼, 체크박스, 토글 버튼, 드롭다운 리스트
• UI 프로토타입 : 시제품을 제작해 대상 시스템과 비교하면서 개발 중에 도출되는 추가 요구사항을 지속적으로 재작성
• 감성 공학 : 인간이 가진 소망으로서의 이미지나 감성 구체화 (HCI 설계에 정량 측정 및 평가, 여러 학문 융합)

SW 설계

SW 설계 모델링

• SW 설계 모델링 : 요구사항에 만족하는 SW의 내부 구조 및 동적 행위를 모델링하여 표현
  • SW 설계 모델링 주의사항 : 요구사항 분석의 정확성, 모델링의 명확성, 모듈화의 적절성, 일관성 유지, 변화 대응
  • SW 설계 원리 : 분할과 정복, 추상화, 단계적 분해, 모듈화, 정보 은닉
  • SW 설계 분류 : 상위 설계 (아키텍처, 데이터, 인터페이스) / 하위 설계 (모듈, 자료구조, 알고리즘)
• SW 공학에서의 모델링 : 모델과 ing의 결합으로 모델을 만드는 일을 의미
  • SW 설계 대상 : 구조 모델링, 행위 모델링
  • SW 설계 방법 : 구조적 설계, 자료 중심 설계, 객체지향 설계
• SW 구조도 : 모듈과 모듈 간의 관계를 상자와 선으로 표시하는 구조적 설계 방법
  • SW 구조도 용어 : Fan-in, Fan-out, Depth, Width, Super Ordinate, Subordinate

구조적 분석 도구

• 자료 흐름도 : 시스템 내 모든 자료를 처리, 자료 흐름, 자료 저장소, 단말로 기술하여 분석
  • 자료 흐름도 특징 : 시스템·프로그램 간 총체적 데이터 흐름 표시 가능, 다차원적·그림 중심·하향식 분할 원리
  • 자료 흐름도 원칙 : 자료 보존, 최소 자료 입력, 독립성, 지속성, 순차 처리, 영구성
  • 자료 흐름도의 구성 요소 및 표기법 : 화살표·원·사각형·직선으로 표시
    
• 소단윈 명세서 : 세분화된 자료 흐름도에서 최하위 단계 프로세스의 처리 절차를 설명
• 구조적 언어 : 자연어의 일부분으로 한정된 단어, 문형와 같은 제한된 구조로 명세서 작성
• 의사 결정 나무 : 현재 상황과 목표와의 상호 관련을 나무 가지로 표현
• 의사 결졍표 : 복잡한 의사결정 논리를 기술하여 자료 처리 분야에 활용
• 자료 사전 : 시스템과 관련된 모든 자료 명세 및 속성을 파악하기 위해 조직화된 도구
  

모듈

• 모듈 : 전체 프로그램에서 어떤 기능을 수행할 수 있는 실행 코드
  • 모듈화를 통해 얻을 수 있는 것 : 유지보수 용이성, 재사용성, 테스트 용이성, 확장성, 독립성
  • 결합도 : 서로 다른 모듈 간의 기능적인 연관 정도 (결합도를 낮게 하면 독립성이 향상)
    
  • 응집도 : 같은 모듈 내 요소들이 서로 관련된 정도 (응집도가 높으면 필요한 요소들로 구성됨을 의미)
  • 모듈 설계 방법 : 출입구 하나, 유지보수 쉽게, 모듈 크기 작게·예측 가능하게, 계층적 자료 조직, 복잡도·중복 최소
  • 모듈 (실질적인 구현 단위)vs컴포넌트 (실제 동작하는 엔티티 단위)
    
  • 모듈 분할의 특징 : 추상화, 모듈화, 정보 은닉, 복잡도, 시스템 구조

재사용

• 재사용 : 검증된 기능을 파악하여 재구성 (라이브러리, 프레임워크, 컴포넌트, 마이크로서비스)
  • 재사용 규모에 따른 구분 : 함수와 객체, 어플리케이션, 컴포넌트
• 공통 모듈 : 각 서브 시스템에서 공통으로 사용하는 기능을 묶어 하나의 공통된 모듈로 개발
  • 공통 모듈 명세 기법 : 정확성, 명확성, 완전성, 일관성, 추적성
  • 공통 모듈 테스트 : 화이트박스 테스트, 메소드 기반 테스트, 화면 기반 테스트
• 모듈 명세화 도구 : 흐름도, 의사결정도, PDL, 상태 전이도, 행위도
  • N-S 도표 : 구조적 프로그램의 순차-선택-반복의 구조를 사각형으로 도식화
  • 의사 코드 : 사람이 이해하기 쉽도록 약속된 형식으로 작성된 코드
  • 의사 결정표 : 모듈의 동작을 결정하는 조건과 결과를 표로 나타낸 문서

소프트웨어 아키텍처

• 소프트웨어 아키텍처 : 요구사항을 기반으로 개발 대상 소프트웨어의 기본 틀을 만드는 것
  • 소프트웨어 아키텍처 시스템 품질 속성 : 가용성, 변경 용이성, 성능, 보안성, 사용 편의성, 시험 용이성
  • 소프트웨어 아키텍처 특징 : 간략성, 추상화, 가시성
  • 소프트웨어 아키텍처 복잡도 관리 종류 : 과정 추상화, 데이터 추상화, 제어 추상화
  • 아키텍처 프레임워크 : 복잡한 소프트웨어 문제의 해결 및 서술에 필요한 기본 구조를 제공하여 재사용 용이하게 함
    
  • 소프트웨어 아키텍처 설계 원리 : 단순성, 효율성, 분할 및 계층화, 추상화, 모듈화
  • 소프트웨어 설계 과정 : 설계 목표의 설정 → 시스템 타입 결정 → 스타일 적용 및 커스텀마이즈 → 서브 시스템 기능·인터페이스 동작 작성 → 아키텍처 설계 검토
• 소프트웨어 아키텍처 평가 방법론 : 예측 평가, 실무 평가, 사례 평가, 정량적 평가
  • 소프트웨어 아키텍처 평가 방법론 종류 : SAAM, ATAM, CBAM, ARID, ADR
• 소프트웨어 아키텍처 4+1 View Model : 다양하고 동시적인 뷰를 기반으로 소프트웨어 위주 시스템 아키텍처 묘사
  • 소프트웨어 아키텍처 4+1 View Model 구성 요소 : 유스케이스 뷰, 논리 뷰, 프로세스 뷰, 구현 뷰, 배포 뷰

소프트웨어 아키텍처 패턴

• 소프트웨어 아키텍처 패턴 : 소프트웨어 아키텍처를 설계하는 데 발생하는 문제점을 해결하기 위한 재사용 가능한 솔루션
  • 계층 구조 패턴 : 소프트웨어를 계층 단위로 나눔 (프레젠테이션, 어플리케이션, 데이터의 3-tier 아키텍처 패턴)
• MVC : UI와 비즈니스 로직을 분리해 모델, 뷰, 컨트롤러로 구성된 패턴
• 클라이언트-서버 패턴 : 하나의 서버와 다수의 클라이언트로 구성하여 서버에 서비스를 요청하면 통신하는 구조
• 파이프 필터 패턴 : 데이터 스트림을 생성 및 처리하기 위해 필터, 파이프로 구성된 패턴
• Peer to Peer 패턴 : 클라이언트-서버에 대칭적 특징 추가, 한 컴포넌트에 대응되는 Peer로 클라이언트, 서버 수행
• 브로커 패턴 : 컴포넌트가 컴퓨터와 사용자를 연결해주는 중앙 집중식 서버인 브로커 역할을 하며 분산 시스템에 사용
• 블랙보드 패턴 : 결정적 해결 전략이 없는 문제의 해결을 위해 블랙보드의 데이터를 컴포넌트에서 검색
• 이벤트 버스 패턴 : 소스 이벤트가 메시지를 발행하면 해당 채널 구독자가 메시지 수신 후 해당 이벤트 처리
• 인터프리터 패턴 : 표현식으로 특정 언어로 작성된 프로그램을 해석하는 컴포넌트 설계에 사용

코드 설계

• 코드 설계 : 데이터의 사용 목적에 따라 식별·분류·배열하기 위해 사용하는 숫자·문자·기호
  • 코드 설계 순서 : 코드 대상 선정 → 코드화 목적 명확화 → 코드 부여 대상 수 확인 → 사용 범위 결정 → 사용 기간 결정 → 코드화 대상 특성 분석 → 코드 부여 방식 결정 → 코드 문서화
  • 코드 설계 목적 : 고유성, 분류 편리성, 배열 효율성, 간결성, 유지보수 편리성, 코드 독립성, 코드 편의성
  • 코드 설계 고려 사항 : 기계 처리 적합성, 사용 편리성, 코드 공통성, 코드 쳬계셩, 코드 유연성
• 코드 기능 : 표준화, 간소화 + 분류, 식별, 배열 + 연상, 암호화, 오류 검출
• 코드 분류 : 식별 코드, 분류 코드, 순차 코드, 블록 코드, 그룹 분류식 코드, 10진 분류 코드, 표의 숫자 코드, 연상 코드
• 코드 오류 종류 : 필사 오류, 전위 오류, 이중 오류, 생략 오류, 추가 오류, 임의 오류

객체지향 설계와 디자인 패턴

소프트웨어 설계 기법과 객체지향 프로그래밍

• 구조적 프로그래밍 : 한개의 입력과 한개의 출력 구조를 갖게 하여 프로그램 이해 및 디버깅 작업이 쉬움
• 절차적 프로그래밍 : 순서대로 일련의 명령어를 나열하는 함수 기반 프로그래밍
• 객체지향 프로그래밍 : 컴퓨터 소프트웨어를 객체 단위로 구분하고, 객체 간의 모음으로 설계하는 것
  • 객체지향 : 개체 (Entity)를 속성과 메소드로 결합해 객체로 표현
  • 객채지향 프로그래밍 구성 요소 : 클래스 (Class), 객체 (Object), 속성 (Attribute), 메소드 (Method), 메시지 (Message)
  • 객체지향 특징 : 캡슐화, 정보은닉, 추상화, 상속성, 다형성
  • 객체지향에서의 관계성 : (is member of) 연관성, (is instance of) 분류화, (is part of) 집단화, (is a) 일반화·특수화
  • 오버로딩 : 한 클래스 내에서 같은 이름의 메소드를 사용하는 것 (매개 변수의 유형 및 개수가 달라지게 함)
  • 오버라이딩 : 상속 관계의 두 클래스의 상위 클래스에서 정의한 메소드를 하위 클래스에서 재정의하는 것

객체지향 설계 원칙

• 객체지향 설계 원칙 : SOLID
  • 단일 책임의 원칙 (SRP) : 객체가 단 하나의 책임만을 가져야 함
    • 객체는 단 하나의 기능만을 수행하고, 이 기능에 대한 변경 사항이 있으면 해댱 객체만 수정되어야 함
  • 개방-폐쇄의 원칙 (OCP) : 소프트웨어 구성 요소는 확장에 대해선 개방적, 수정에 대해선 폐쇄적이여야 함
    • 기능이 추가되면 기존 코드를 수정하지 않고, 기존 코드를 확장하도록 설계해야 함
  • 리스코프 치환 원칙 (LSP) : 부모 클래스가 들어갈 자리를 자식 클래스로 대체해도 계획대로 작동되어야 함
    • 어떤 클래스가 상속 관계에 있을 때, 자식 클래스는 부모 클래스의 역할을 수행할 수 있어야 함
  • 인터페이스 분리 원칙 (ISP) : 클라이언트는 자신이 사용하지 않는 메소드와 의존 관계를 맺으면 안됨
    • 클라이언트가 사용하지 않는 인터페이스에 영향받지 않게 해, 불필요한 의존성을 줄이고 코드 유연성을 높임
  • 의존 역전 원칙 (DIP) : 구현이 아닌 추상화에 의존해야 함 (상위 모듈은 하위 모듈에 의존하면 안됨)
    • 추상화된 인터페이스나 추상 클래스에 의존해야 하며, 의존성 주입을 통해 런타임 시 의존 관계 설정 가능
• 객체지향 개발 방법론 종류 : Booch (다이어그램 기반), OOSE (유스케이스 활용), OMT (모델링 기반)
  • Coad & Yourdon : E-R 다이어그램으로 객체의 행위를 데이터 모델링 (→ UML)
• 클래스 설계 : 분석 단계 중 아직 확정되지 않은 클래스 내부 부분 중에 구현에 필요한 중요 사항을 결정
  • 클래스 인터페이스 : 클래스 구현, 클래스 사용, 클래스 확장
  • 협업에 의한 설계 : 선행 조건, 결과 조건, 불변 조건

디자인 패턴

• 디자인 패턴 : 자주 사용하는 설계 형태를 정형화하여, 유형별로 설계 템플릿을 만들고 소프트웨어 개발 중의 과제 해결
  • 디자인 패턴 장점 : 검증된 해결책 → 높은 생산성, 시간·비용 절감, 구조 파악 쉬움, 원활한 의사소통
  • 디자인 패턴 단점 : 객체지향 위조, 초기 비용 부담, 패턴 이해 선행, 코드 복잡성 증가
  • 디자인 패턴 구성 : 문제, 해결책, 결과, 이름, 컨텍스트, 구성 요소, 상호 작용, 문서화, 유연성, 일반성, 적용 예시, 품질 향상, 적용 가능성, 개발 방법론, 팀원 협업 + 알려진 사례, 샘플 코드
• 디자인 패턴 활용 : 새로운 소프트웨어 개발, 기존 소프트웨어 리펙토링 및 기능 추가

GOF 패턴

• GoF 패턴 : 객체 지향 설계 단계 중에 재사용에 유용한 설계들을 디자인 패턴으로 분류
  • 생성 패턴 : 객체 생성 패턴 (객체 생성·변경이 시스템에 미치는 영향 최소화, 객체 생성·참조 과정 추상화)
    • 팩토리 메소드 : 상위 클래스에서 객체를 생성하는 인터페이스를 정의하고, 하위 클래스에서 인스턴스 생성
    • 싱글톤 : 전역 변수를 사용하지 않고, 객체를 하나만 생성하여 생성된 객체를 어디에서든 참조하도록 함
    • 프로토타입 : 프로토타입을 먼저 생성하고 인스턴스를 복제하여 사용
    • 빌더 : 객체를 생성하는 방식을 분리하여, 복잡한 객체를 생성하기 위해 다양한 객체들을 조합
    • 추상 팩토리 : 구체적인 클래스에 의존하지 않고 서로 연관된 객체들의 조합을 인터페이스로 제공
  • 구조 패턴 : 클래스·객체 조합 패턴 (복잡한 구조를 개발하기 쉽게, 새로운 기능의 복합 객체 생성에 효과적)
    • Adapter : 클래스 인터페이스를 다른 인터페이스롤 변환하여 다른 클래스가 이용 가능하게 함
    • Bridge : 구현부에서 추상층을 분리해 각자 독립적으로 확장
    • Composite : 객체들의 관계를 트리 구조로 작성해 복합 객체와 단일 객체를 구분 없이 다름
    • Decorator : 주어진 상황·용도에 맞게 어떤 객체에 다른 객체를 덧붙임
    • Facade : 서브 시스템의 인터페이스 집합에 대해 통합된 인터페이스 Wrapper 제공
    • Flyweight : 크기가 작은 여러 객체를 매번 생성하는 대신 가능한 한 공유하여 메모리 절약
    • Proxy : 접근이 어려운 객체에 접근 가능한 프록시 객체 및 그에 대한 인터페이스 제공
  • 행위 패턴 : 객체 상호 작용 패턴 (클래스·객체들이 상호 작용하는 방법 및 책임 분산, 메시지 교환과 관련)
    • 책임 연쇄 : 요청을 처리할 객체가 둘 이상 존재하여, 한 객체가 처리 못하면 다음 객체롤 넘어가도록 함
    • Iterator : 접근이 잦은 객체는 동일한 인터페이스를 활용하도록 함
    • Command : 명렁어를 캡슐화하여 재사용 및 취소할 수 있도록 필요한 정보를 로그에 남김
    • Interpreter : 언어에 문법 표현을 정의
    • Memento : 특정 시점의 객체 내부 상태를 객체화해, 이후 요청에 따른 객체를 해당 시점으로 롤백 가능
    • Memento : 이벤트 발행·구독, 객체 상태 변화 및 전달에 따라, 객체에 상속된 객체들에 변화 상태 전달
    • State : 객체 상태에 따라 이벤트를 다르게 처리하도록 함
    • Strategy : 동일 계열 알고리즘을 개별적으로 캡슐화하여, 상호 교환 및 독립적으로 원하는 알고리즘 사용
    • Visitor : 처리 기능을 별도의 클래스로 구성하고, 분리된 처리 기능은 각 클래스를 방문하여 수행
    • Template : 상위에서 인터페이스를 정의하고, 하위에서 이를 구체화
    • Mediator : 상호 작용을 캡슙화하여 결합도를 낮추도록 함

시스템 인터페이스 설계

시스템 인터페이스 요구사항 확인

• 시스템 인터페이스 내·외부 요구사항 : 개발 대상 조직 내·외부 시스템 연동을 통하여 상호 작용을 하기 위한 접속 방법
• 시스템 인터페이스 요구사항 : 요구사항 구성, 내·외부 인터페이스의 이름, 연계 대상 시스템, 연계 범위·내용·방식, 송신 데이터, 인터페이스 주기
• 시스템 인터페이스 요구사항 분류 : 기능적 요구사항, 비기능적 요구사항
• 시스템 인터페이스 요구사항 분석 절차 : 명세 작성 → 자료 준비 → 기능·비기능 요구사항 구분 → 비교 분석 → 문서 공유
• 시스템 인터페이스 요구사항 검증 : 인터페이스 설계·구현 이전에 사용자 요구사항을 명세하고, 개발 범위를 설정
  • 시스템 인터페이스 요구사항 검증 절차 : 검토 계획 수립 → 검토 및 오류 수정 → 베이스라인 설정
  • 시스템 인터페이스 요구사항 검증 방법 : 프로토타이핑, 테스트 설계, CASE, 동료 검토, Walk Through, Inspection

시스템 인터페이스 대상 식별

• 시스템 인터페이스 대상 식별 : 개발 대상 시스템과 연계 시스템 사이의 인터페이스를 식별
  • 시스템 인터페이스 구성 : 송신 시스템, 수신 시스템, 중계 시스템
  • 시스템 인터페이스 데이터 표준 : 시스템 간에 상호 교환되는 데이터의 표준 형식을 정의해 사용
• 시스템 인터페이스 상세 설계 : 직접 연계vs간접 연계
• 시스템 인터페이스 연계 기술 : DB Link, DB Connection, API/OpenAPI, JDBC, HyperLink, Socket, WebService
• 시스템 인터페이스 송·수신 통신 유형 : 단방향, 동기·비동기 + 자연어 처리, 배치 처리, 실시간 처리
• 시스템 인터페이스 데이터 명세화 : 개체 정의서, 테이블 정의서, 코드 정의서
• 시스템 인터페이스 설계 : 시스템 구조와 서브 시스템 사이의 관계 표현
  • 시스템 인터페이스 설계 단계 : 요구사항 분석 → 인터페이스 디자인 → 인터페이스 구현 → 인터페이스 테스트 및 유지보수

미들웨어 솔루션

• 미들웨어 솔루션 : 클라이언트·서버 간 통신을 담당하는 시스템 소프트웨어 (표준화된 인터페이스로 일관성 제공)
  • DB 미들웨어 : DB 벤더에서 제공하는 소프트웨어 (클라이언트에서 원격 DB와 연결)
  • 통신 미들웨어 : 분산 시스템에서 서로 다른 어플리케이션 간의 통신을 가능하게 함
    • RPC : 분산 처리 시스템에서 응용 프로그램의 프로시저를 통해 원격 프로시저를 로컬 프로시저처럼 호출
    • MOM : 메시지 기반 비동기식 메시지 전달 미들웨어, 이기종 분산 DB 데이터 동기화에 사용
    • ORB : 로컬·원격지의 객체 간의 통신을 담당하는 객체지향 미들웨어 (IDL 사용)
    • TP-Monitor : 여러 소프트웨어 상호 간 혼합된 환경에서 세션, 시스템, DB 간 트랜잭션 감시
    • WAS : 서버 단에서 어플리케이션을 동작 가능하게 하여 동적 서버 컨텐츠 수행에 활용