수제비 2023 정보처리기사 필기 vol.1 교재 참고
Ⅰ. 소프트웨어 설계
- 실제 사례보다는 이론적인 지식을 중심으로 학습
- 핵심 개념: 요구사항 분석, 애자일, 객체 지향, 디자인 패턴, 소프트웨어 아키텍처, 인터페이스
✅ 요구사항 분석
: 도출된 요구사항 간 상충을 해결하고 소프트웨어의 범위를 파악하여 외부 환경과 상호작용하는 것을 분석하는 과정
✅ 소프트웨어 아키텍처
: 시스템에 대한 기본 조직체계로 시스템을 이루는 구성요소와 구성요소들 사이의 관계, 구성요소와 주변 환경들과의 관계 및 시스템의 진화와 설계를 지배하는 원칙
✅ 객체 지향
: 프로그램을 '객체'라는 기본 단위로 나누고 이 객체들의 상호작용으로 서술하는 프로그램 설계방법론
✅ 객체
: 하나의 역할을 수행하는 '메서드(함수)와 변수(데이터)'의 묶음
✅ 디자인 패턴
: 객체 지향 프로그래밍 설계를 할 때 자주 발생하는 문제들을 피하기 위해 사용되는 패턴
✅ 인터페이스
: 서로 다른 두 시스템, 장치, 소프트웨어를 서로 이어주는 접속 및 중계 시스템
01. 요구사항 확인
1. 현행 시스템 분석
(1) 플랫폼 기능 분석
(2) 플랫폼 성능 특성 분석
- 플랫폼 성능 특성 분석 기법
| 기법 | 설명 | 산출물 |
| 사용자 인터뷰 | 사용자 인터뷰를 통해 속도의 적정성 확인 | 인터뷰 결과서 |
| 성능 테스트 | 현행 플랫폼 대상으로 성능, 부하 테스트 | 성능 테스트, 부하 테스트 결과서 |
| 산출물 점검 | 현행 플랫폼과 유사한 타사 제품의 성능 자료 등을 분석 | 벤치마킹 테스트 결과서 |
- 플랫폼 성능 특성 측정 항목
| 측정항목 | 설명 |
| 경과시간 | 애플리케이션에 작업을 요구 ~ 처리 완료 까지 걸린 시간 |
| 사용률 | 애플리케이션이 작업을 처리하는 동안 CPU, 메모리 등의 자원 사용률 |
| 응답시간 | 애플리케이션에 요청 전달 ~ 응답 도착 까지 걸린 시간 |
| 가용성 | 서버와 네트워크, 프로그램 등의 정보 시스템이 정상적으로 사용 가능한 정도 |
(3) 운영체제 분석
(4) 네트워크 분석
(5) DBMS 분석
- DBMS 현행 시스템 분석 시 고려사항
- 성능 측면: 가용성, 성능, 상호호환성
* 가용성 -> 장애 발생 가능성, DBMS 이중화 및 복제 지원
* 상호 호환성 -> 설치 가능한 운영체제의 종류(windows, unix, linux, android, ios)
- 지원측면: 기술 지원, 구축 비용
(6) 비즈니스 융합 분석
- 비즈니스 융합 유형
1. 고객 가치(Why)
2. 시장 유통(Whom): 신시장 개척, 미래시장 선점
3. 가치 제안(What)
4. 공급 역량(Who): 신기술, 신규역량을 활용한 상품생산 및 판매
5. 생산 방식(How)
2. 요구사항 확인
(1) 요구분석 기법
- 요구사항 분석 기술: 청취, 인터뷰와 질문, 분석, 중재, 관찰, 작성, 조직, 모델 작성 기술
- 요구사항 분석에 사용되는 기능 모델링 기법
1. 데이터 흐름도(DFD; Data Flow Diagram)
2. 자료 사전
(2) UML(Unified Modeling Language)
: 산출물을 명세화, 시각화, 문서화할 때 필요한 표준화된 모델링 언어
- UML의 특징
| 특징 | 설명 |
| 가시화 언어 | 오류 적고 의사소통 용이 |
| 구축 언어 | 다양한 프로그래밍 언어로 예측 가능, UML -> 소스코드 변환, 역변환 가능 |
| 명세화 언어 | 정확한, 완벽한 모델 |
| 문서화 언어 | 시스템에 대한 평가, 의사소통의 문서 |
- UML의 구성요소: 사물, 관계, 다이어그램
- UML 다이어그램
1. 구조적/정적 다이어그램
| 다이어그램 | 설명 |
| 클래스 (Class) |
클래스의 정적 구조 표현 속성, 동작으로 구성 클래스-클래스, 클래스 속성 사이의 관계를 표현 |
| 객체 (Object) |
인스턴스를 객체 사이의 관계로 표현 + 여기서 객체를 클래스 개념으로 생각! |
| 컴포넌트 (Component) |
코드 컴포넌트 기반의 물리적 구조 표현 |
| 배치 (Deployment) |
컴포넌트 사이의 종속성 표현 |
| 복합체 구조 (Composite Structure) |
클래스, 컴포넌트가 복합 구조를 갖는 경우, 내부 구조 표현 |
| 패키지 (Package) |
모델 요소 그룹화 |
2. 행위적/동적 다이어그램
| 다이어그램 | 설명 |
| 유스케이스 (Usecase) |
사용자 관점에서 시스템 활동 표현 시스템의 기능적 요구 정의에 활용 |
| 시퀀스 (Sequence) |
객체 간 상호작용을 메시지 흐름으로 표현 메시지를 보내는 시간도 표현 교류 다이어그램의 한 종류 |
| 커뮤니케이션 (Communication) |
메시지뿐만 아니라 객체 간의 연관까지 표현 |
| 상태 (State) |
클래스의 상태 변화 표현 진입 조건, 탈출 조건, 상태 전이 등 기술 |
| 활동 (Activity) |
객체의 처리 로직, 처리의 흐름을 순서대로 표현 |
| 타이밍 (Timing) |
객체의 상태 변화와 시간 제약을 명시적으로 표현 |
- UML 상세
1. 클래스 다이어그램
-> 클래스 이름, 속성, 연산, 접근 제어자
- 접근 제어자: 클래스에 접근할 수 있는 정도를 표현
| - (private) | 클래스 내부접근만 허용 |
| + (public) | 클래스 외부접근을 허용 |
| # (protected) | 동일 패키지, 파생 클래스에서 접근 가능 |
| ~ (default) | 동일 패키지 클래스에서 접근 가능 |
2. 유스케이스 다이어그램
-> 유스케이스, 액터, 시스템
- 유스케이스 다이어그램 구성요소 간의 관계
| 연관 관계 (Association) |
유스케이스와 액터 간의 상호작용이 있음 | 유스케이스와 액터를 실선으로 연결 |
| 포함 관계 (Include) |
하나의 유스케이스가 다른 유스케이스의 실행을 전제로 할 때 | 화살표를 점선으로 연결하고 <<include>>라고 표기 |
| 확장 관계 (Extend) |
특정 조건에 따라 확장 기능 유스케이스를 수행 | 화살표를 점섬으로 연결하고 <<exclude>>라고 표기 |
| 일반화 관계 (Generalization) |
유사한 것끼리 그룹을 만들어 이해도 높임 | 속이 빈 화살표로 연결 |
3. 시퀀스 다이어그램
-> 객체, 생명선, 실행, 메시지, 회귀 메시지
- UML의 관계 (표현 형태도 따로 알아두기!)
| 연관 관계 | 서로 관련된 상태 - 화살표로 표현 |
| 의존 관계 | 짧은 시간 동안만 연관을 유지하는 관계 한 클래스가 다른 클래스를 오퍼레이션의 매개변수로 사용하는 경우 - 점선 화살표로 표현 |
| 일반화 관계 | 일반적인 개념 -> 부모(상위) 구체적인 개념 -> 자식(하위) - 속이 빈 화살표로 표현 |
| 실체화 관계 | 한 객체가 다른 객체에 오퍼레이션 수행 - 속이 빈 점선 화살표로 표현 |
| 포함 관계 | 포함하는 사물의 변화가 포함되는 사물에 영향을 미치는 관계 **변화가 영향을 미치는지 여부에 따라 일반화, 포함 관계를 구분 - 속이 채워진 마름모를 연결하여 표현 |
| 집합 관계 | 하나의 사물이 다른 사물에 포함된 관계 - 속이 빈 마름모를 연결하여 표현 |
- UML 확장 모델의 스테레오 타입
: UML의 기본적인 요소 이외에 새로운 요소를 만들어 내기 위한 확장 메커니즘
<<include>> <<extend>> <<interface>> <<entity>> <<boundary>> <<control>>
| <<interface>> | 모든 메서드가 추상 메서드 추상 메서드와 상수만으로 구성 |
| <<entity>> | 정보 또는 오래 지속되는 연관된 행위를 형상화 (ex. 내장패키지에 내장된 모듈이나 함수들) 기억 장치에 저장되어야 할 정보를 표현 |
*추상화: 클래스 간의 공통점을 찾아내서 공통의 부모를 설계하는 작업
*추상 클래스
1. 부모클래스에서 공통부분을 구현과 설계 -> 자식 클래스에서 상속받아 기능 확장
2. 자식 클래스에서 추상메서드를 반드시 구현하도록 강요 -> 프로그램의 표준화 정도를 높인다.
3. 공통 사항이 한곳에서 관리되어 개발 및 유지보수에 용이
(3) 애자일(Agile)
: 개발과 함께 즉시 피드백을 받아서 유동적으로 개발하는 방법
- 애자일 선언문
| 공정과 도구보다 개인과 상호 작용 | 계획을 따르기보다 변화에 대응하기 |
| 포괄적인 문서보다 동작하는 소프트웨어 | 계약 협상보다 고객과의 협력 |
- 애자일 방법론 유형
1. XP(eXtreme Programming)
: 의사소통 개선, 즉각적 피드백으로 소프트웨어 품질을 높이기 위한 방법론
- 실용성 강조
- 1~3주의 반복 개발 주기
- 5가지 가치: 용기, 단순성, 의사소통, 피드백, 존중
- 12가지 기본원리
2. 스크럼(SCRUM)
: 매일 정해진 시간, 장소에서 짧은 시간의 개발을 하는 팀을 위한 관리 중심 방법론
- 주요 용어
: 제품 책임자, 제품 백로그, 스프린트, 스크럼 미팅, 스크럼 마스터, 스프린트 회고, 번 다운 차트
3. 린(Lean)
: 낭비 요소를 제거하여 품질을 향상한 방법론
- JIT(Just In Time), 칸반(Kanban) 보드를 사용
4. 크리스탈(Crystal)
5. ASD(Adaptive Software Development)
6. FDD(Feature Driven Development)
3. 분석 모델 확인
(1) 모델링 기법
- 모델
: 개발 대상을 추상화하고 시각적으로 표현
- 소프트웨어에 대한 이해도 향상 및 의사소통 향상
- 문제 발생 상황에 대한 이해를 높이고 해결책 설명
- 문제 도메인의 엔티티(entity)들과 관계 및 종속성을 반영
- 모델링
- 모델링 작업의 결과물은 다른 모델링 작업에 영향
- 구조적 방법론에서는 DFD(Data Flow Diagram), DD(Data Dictionary) 사용
- 객체 지향 방법론에서는 UML 표기법 사용
- 실세계 문제에 대한 모델링이 핵심
(2) 분석 자동화 도구
- 분석 자동화 도구
: 요구사항 분석을 위한 자동화 도구(CASE)
*CASE(Computer Aided Software Engineering): 소프트웨어 생명주기의 전체 단계를 연결, 자동화해주는 통합된 도구
-> 소프트웨어, 하드웨어, 데이터베이스, 테스트 등을 통합하여 소프트웨어 개발 환경 조성
- 품질 개선이 가능
- 변경으로 인한 영향에 대한 추적이 쉬움
- 유지보수 비용의 축소
- 자동화된 기법을 통해 소프트웨어 품질 향상
- 구조적 기법, 프로토타이핑 기술, 자동프로그래밍 기술, 정보 저장소 기술, 분산 처리 기술을 사용
- 분석 자동화 도구의 분류
| 상위 CASE | 계획수립, 요구분석, 기본설계 단계를 다이어그램으로 표현 오류 검증, 일관성 검증 지원 자료흐름도 프로토타이핑 작성 및 UI 설계 지원 |
| 하위 CASE | 정적, 동적 테스트 지원 시스템 명세서 및 소스 코드 생성 지원 |
- 분석 자동화 도구 주요 기능(CASE 도구)
-> 그래픽 지원, 소프트웨어 생명 주기의 전 단계를 연결, 소프트웨어 개발 모형 지원, 표준화된 개발 환경 구축 및 문서 자동화 기능을 제공, 작업자 간의 커뮤니케이션 증대
(3) 요구사항 관리 도구
- 요구사항 관리 도구의 필요성: 비용 편익, 변경 추적, 영향 평가
여기까지 [소프트웨어설계] 01 요구사항 확인 파트를 마치겠습니다.
다음 포스팅은 '[소프트웨어설계] 02 화면설계' 입니다:)
