* 이 글은 블로그 별랑님의 글을 참고로 작성했습니다.
blog.naver.com/srang_/222055609853
1. 요구사항 확인
1) 현행 시스템 파악
- 현재 개발하고자 하는 시스템의 개발 범위를 설정하기 위해 구성과 기능, 연계정보, 소프트웨어, 하드웨어, 네트워크의 구성을 파악하는 과정을 의미한다.
2) 현행 시스템 파악 절차
현행 시스템 구성 파악 |
현행 시스템 기능 파악 |
인터페이스 현황 평가 |
기간 업무, 지원 업무 |
제공하는 기능 파악, 계층형 표시 |
데이터 종류, 통신규약, 연계 유형 |
아키텍처 구성 파악 |
소프트웨어 구성 파악 |
업무 수행 기술 요소들이 사용되는지 최상위 수준에서 파악 |
소프트웨어 제품명, 용도, 라이선스 수, 적용 방식 명시 |
하드웨어 구성 파악 |
네트워크 구성 파악 |
서버의 주요 사양, 서버의 이중화, 수량 |
네트워크 구성 파악을 위해 네트워크 연결 방식을 구성도로 작성 |
3) 소프트웨어 아키텍처(서술형)
- 여러가지 소프트웨어 구성요소와 외부 특성, 구성요소 간의 관계를 표현하는 시스템 구조
- 구성요소 간의 관계를 표현하는 시스템의 구조나 구조체
4) 소프트웨어 아키텍처 프레임워크(서술형)
소프트웨어 집약적인 시스템에서 아키텍처가 표현해야 하는 내용 및 이들 간의 관계를 제공하는 아키텍처 표준 기술을 의미한다.
- 기본 구조, 소프트웨어의 베이스(개발 기반), 역할 : 품질유지, 원칙, 지침
- 동일한 아키텍쳐 = 기본 구조가 같은 여러 형태의 결과물
* 소프트웨어 프레임워크의 특징
- 모듈화(Modularity)
: 프레임워크는 인터페이스에 의한 캡슐화를 통해서 모듈화를 강화하고 설계와 구현의 변경에 따르는 영향을 극소화하여 소프트웨어의 품질을 향상시킨다.
- 재사용성(Reusability)
: 프레임워크가 제공하는 인터페이스는 반복적으로 사용할 수 있는 컴포넌트를 정의할 수 있게 하여 재사용성을 높여준다. 또는 재사용성은 소프트웨어의 품질을 향상시킬 뿐만 아니라 개발자의 생산성도 높여준다.
- 확장성(Extensibility)
: 프레임워크는 다형성을 통해 애플리케이션이 프레임워크의 인터페이스를 넓게 사용할 수 있게 한다. 또한 애플리케이션 서비스와 특성을 변경하고 프레임워크를 애플리케이션의 가변성으로부터 분리함으로써 재사용성의 이점을 얻게 한다.
- 제어의 역흐름(Inversion of control)
: 프레임워크 코드가 전체 애플리케이션의 처리 흐름을 제어하여 특정한 이벤트가 발생할 때 다형성을 통해 애플리케이션이 확장한 메소드를 호출함으로써 제어가 프레임워크로부터 애플리케이션으로 반대로 흐르게 한다.
5) 소프트웨어 아키텍처 4+1 뷰
* 정의 : 고객의 요구사항을 정리해둔 시나리오 4개의 관점으로 바라보는 소프트웨어적인 접근 방법
* 4+1뷰의 종류
- 유스케이스 뷰 : 아키텍처를 도축하고 설계하는 작업을 주도하는 뷰
- 논리 뷰 : 설계 모델의 추상화, 클래스 식별 -> 클래스 다이어그램
- 프로세스 뷰 : 런타임 시 스레드와 프로세스 사이의 상호 작용
- 배포 뷰 : 물리적인 노드의 구성 -> 배포 아이어그램
- 구현 뷰 : 정적인 소프트웨어 구현 -> 컴포넌트 뷰, 컴포넌트 다이어그램
* 런타임 : 컴퓨터 프로그램이 실행되고 있는 동안의 동작 상태
* 스레드 : 프로세스의 실행을 담당하는 실행의 기본 단위
* 프로세스 : 운영체제가 관리하는 실행 단위며 PCB를 가진 시스템
* 프레임워크 : 소프트웨어의 특정 부분을 설계 및 구현 시 재사용이 가능하도록 클래스 제공
6) 개발 기술 환경 정의
* 운영체제(서술형) : 사용자와 하드웨어의 인터페이스 역할을 하며 컴퓨터 시스템의 자원을 관리하는 소프트웨어
- 키워드 : 신뢰성, 성능, 기술 지원, 주변 기기, 구축 비용
* DBMS(서술형) : 사용자와 Database 사이에서 사용자의 요구에 따라 정보를 생성해주고 Database를 관리해주는 소프트웨어
- 데이터의 중복성과 종속성을 해결
- 키워드 : 가용성, 성능, 기술 지원, 상호 호환성, 구축비용
* JDBC : JAVA 언어를 이용하여 DB에 접근하여 관리할 수 있는 인터페이스
* ODBC : 응용프로그램에서 DB에 접근하여 데이터를 관리할 수 있는 표준 인터페이스
* 미들웨어 : 운영체제와 소프트웨어 Application 사이에서 원만한 통신이 이루어질 수 있도록 중개 및 제어 역할을 하는 소프트웨어
* 미들웨어의 종류
- DB(DataBase)
: 데이터베이스 벤더(Vendor)에서 제공하는 클라이언트에서 원격의 데이터베이스와 연결하기 위한 미들웨어
- RPC(Remote Procedure Call)
: 응용 프로그램의 프로시저를 사용하여 원격 프로시저를 마치 로컬 프로시저처럼 호출하는 방식의 미들웨어
- MOM(Message Oriented Middleware)
: 메시지 기반의 비동기형 메시지를 전달하는 방식의 미들웨어
- TP-Monitor(Transaction Processing Monitor)
: 항공기나 철도 예약 업무 등과 같은 온라인 트랜잭션 업무에서 트랜잭션을 처리 및 감시하는 미들웨어
- ORB(Object Request Broker)
: 객체 지향 미들웨어로 코바(CORBA) 표준 스펙을 구현한 미들웨어
- WAS(Web Application Server)
: 사용자의 동적인 콘텐츠를 처리하기 위해 사용되는 미들웨어
- 키워드 : 가용성, 성능, 기술 자원, 구축 비용
- WAS 종류 : Tomcat, JBoss, Jetty, JEUS
* 가비지 컬렉선 : 실제로 사용되지 않고 있지만 반환되지 않은 메모리 공간을 강제로 해제하여 사용할 수 있도록 하는 메모리 관리 기법
* 오픈소스 : 누구나 제한 없이 사용할 수 있는 소스코드를 공개한 라이선스를 만족하는 소프트웨어
- 키워드 : 라이선스 종류, 사용자의 수, 기술 지속 가능성 고려
* tpmC : 1분당 최대 처리 건수, 하드웨어 성능 지표로 사용
* OLTP/배치/데이터베이서 서버 -> tpmC
* WEB/WAS 서버 -> OPS(Operations per Second)
7) 요구사항
* 소프트웨어가 문제를 해결하기 위해 제공되는 서비스 설명과 제약조건을 나타낸다.
- 기능적 요구사항 : 시스템이 제공하는 기능, 서비스 (기능성, 완전성, 일관성)
- 비기능적 요구사항 : 기능외의 제약사항이나 보안적인 요소
- 사용자 요구사항 : 사용자 관점에서 시스템이 제공해야 할 기능 및 서비스
- 시스템 요구사항 : 개발자 관점
- 요구사항 개발 프로세스
도출 |
분석 |
명세 |
확인 |
- 요구사항 식별 |
- 요구사항 분류 |
- 문서화 |
- 요구사항 검토 |
* 개념 모델링 : 요구사항 분석의 핵심으로 요구사항을 단순화하여 개념적으로 표현한 것 * 요구사항 할당 : 아키텍처 구성요소 식별 * 정형 분석 : 구문과 의미를 갖는 정형화된 언어를 수학적 기호로 표현하여 분석 * 모델 검증 : 정적 분석 수행 * 인수테스트 : 사용자의 입장에서 테스트하는 방법으로 알파 테스트와 베타 테스트가 존재 * 프로토타이핑 : 새로운 요구사항을 도축하기 위한 수단 또는 요구사항에 대해 소프트웨어 엔지니어가 해석한 것으로 확인하기 위한 수단 |
[정보처리기사 필기/1과목 소프트웨어 설계] - 정보처리기사 필기 ) 1과목 소프트웨어 설계 정리
8) 비용 산정 모델
- 하향식 선정 방법 : 전문가 판단, 델파이 기법
- 상향식 선정 방법 : LOC, M/M(Man/Month), Putnam, COCOMO
* Putnam : 개발 주기의 단계별 요구, 인원 분포도 가정
* COCOMO : 보헴이 정의 / 프로그램 규모에 따라 비용 산정
* 상호 운용성 : 서로 다른 시스템 간의 데이터를 주고 받아 효율적으로 운용될 수 있는 특성
9) 분석 모델 검증
(1) 유스케이스 모델 검증 ( 액터, 유스케이스 )
(2) 개념 수준의 분석 클래스 검증
(3) 분석 클래스 검증
- 경계 : 외부 액터와 상호작용
- 엔티티 : 시스템이 유지해야 하는 정보를 관리
- 제어 : 시스템이 제공하는 기능의 로직, 제어 담당
- 기술적 타당성 검토
(1) 성능 및 용량 산정의 적정성
(2) 시스템 간 상호 운용성
(3) IT 시장 성숙도 및 트렌드 부합성
(4) 기술적 위험 분석
10) UML
* 정의 : 개발자들이 원활한 의사소통을 하기 위해 고안된 표준화 통합 모델링 언어
* 6개의 구조 다이어그램 + 7개의 행위 다이어그램
* 구성요소 : 사물, 관계, 다이어그램
- 사물 : 구조, 그룹, 행동, 주해
- 관계
- 연관관계 : 2개 이상 사물이 서로 연관
- 집합관계 : 하나의 사물이 다른 사물에 포함
- 포함관계 : 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계
- 일반화 : 상속 관계
- 의존 : 필요에 의해 짧은 기간 동안 관계 유지
- 실체화 : 서로를 그룹화할 수 있는 인터페이스
연관 Association |
집합 Aggregation |
포함 Composition |
일반화 Generalization |
의존 Dependency |
실체화 Realization |
|
정의 | 2개 이상 사물 서로 관련 | 하나의 사물, 다른 사물에 포함 | 포함되는 사물에게 영향 미침 | 사물끼리 일반적, 구체적 표현 | 연관은 있으나 영향줄 때만 연관을 유지 | 행위, 인터페이스로 서로 그룹화할 수 있는 관계 |
표기법 | ― * 다수, .. 또는 |
◇ | ◆ | 상위개념 실선 | 일시적, 점선 | 상위개념, 점선 |
예시 | 자동차-타이어 | 컴퓨터 ◇ 마우스 |
마우스 ◆ 마우스 리시버 |
토레타 포카리 - 이온음료 | 고객등급 --- 사은품 |
폰, 벽시계 --- 시간확인 |
- 다이어그램(6개의 구조 다이어그램 + 7개의 행위 다이어그램)
- 6개 구조 다이어그램 : 클래스, 객체, 컴포넌트, 배치
- 컴포넌트 다이어그램 : 컴포넌트와의 관계나 인터페이스를 표현
- 배치 다이어그램 : 물리적인 요소들의 위치 표현
- 7개 행위 다이어그램 : 유스케이스, 시퀀스, 커뮤니케이션, 상태
구조적 다이어그램 | 행위 다이어그램 | ||
종류 | 키워드 | 종류 | 키워드 |
클래스 | 구조 | 유스케이스 | 모델링 |
객체 | 관계 | 시퀀스 | 메시지 |
컴포넌트 | 구현, 인터페이스 | 커뮤니케이션 | 메시지 + 연관관계 |
배치 | 구현, 위치 | 상태 | 상태 변화 |
복합체 구조 | 내부 구조 | 활동 | 로직 흐름 |
패키지 | 그룹 | 상호작용 개요 | 제어 흐름 |
타이밍 | 시간제약 |
* 유스케이스 다이어그램 구성요소 : 액터, 유스케이스, 시스템, 관계
* 유스케이스 : 액터에게 제공하는 서비스, 기능을 표현
2020/09/23 - [정보처리기사 실기/실기 정리] - 정보처리기사 실기) 1장 요구사항 확인
2020/10/12 - [정보처리기사 실기/실기 정리] - 정보처리기사 실기) 2장 데이터 입출력 구현
2020/10/12 - [정보처리기사 실기/실기 정리] - 정보처리기사 실기) 3장 통합구현
2020/10/12 - [정보처리기사 실기/실기 정리] - 정보처리기사 실기) 4장 서버 프로그램 구현
2020/10/12 - [정보처리기사 실기/실기 정리] - 정보처리기사 실기) 5장 인터페이스 구현
2020/10/12 - [정보처리기사 실기/실기 정리] - 정보처리기사 실기) 6장 화면 설계
2020/10/12 - [정보처리기사 실기/실기 정리] - 정보처리기사 실기) 7장 애플리케이션 테스트 관리
2020/10/12 - [정보처리기사 실기/실기 정리] - 정보처리기사 실기) 8장 SQL 응용
2020/10/13 - [정보처리기사 실기/실기 정리] - 정보처리기사 실기) 9장 소프트웨어 개발 보안 구축
2020/10/13 - [정보처리기사 실기/실기 정리] - 정보처리기사 실기) 11장 응용 SW 기초 활용
2020/10/13 - [정보처리기사 실기/실기 정리] - 정보처리기사 실기) 12장 제품 소프트웨어 패키징
'정보처리기사 > 정보처리기사 실기 정리' 카테고리의 다른 글
정보처리기사 실기) 6장 화면 설계 (2) | 2020.10.12 |
---|---|
정보처리기사 실기) 5장 인터페이스 구현 (0) | 2020.10.12 |
정보처리기사 실기) 4장 서버 프로그램 구현 (2) | 2020.10.12 |
정보처리기사 실기) 3장 통합구현 (2) | 2020.10.12 |
정보처리기사 실기) 2장 데이터 입출력 구현 (0) | 2020.10.12 |
댓글