정보처리기사 필기 ) 1과목 소프트웨어 설계 정리

* 키워드 : UML, 린 개발 방법론 7원칙, UI, 인터페이스 요구사항 검증 항목, 결합도, 응집도, 요구사항, 소프트웨어 아키텍쳐, EAI, ESB, 플랫폼, 요구사항 개발 프로세스

​

1. UML ( Unified Modeling Language )

- 요구분석, 시스템 설계, 시스템 구현 등의 시스템 개발 과정에서 ​개발자 간의 의사소통을 원활하게 이루어지게 하기 위하여 표준화한 모델링 언어

- 특징 : 가시화, 구축, 명세화, 문서화 언어

- 가시화 언어 : UML의 특성 중 하나로 개념 모델 작성 시 오류가 적고 의사소통의 용어를 위한 특징

- UML 구성요소 : 사물, 관계, 다이어그램

>> 사물의 유형

- 구조 사물 : 시스템의 개념적, 물리적 요소를 표현 ( 클래스, 유스케이스, 컴포넌트가 속함 )

- 행동 사물 : 시간과 공간에 따른 요소들의 행위를 표현 ( 상호작용, 상태 머신이 속함 )

- 그룹 사물 : 요소들을 그룹으로 묶어서 표현 ( 패키지가 속함 )

- 주해 사물 : 부가적인 설명이나 제약조건을 표현 ( 노트가 속함 )

 

2. 린 개발 방법론 7원칙 ( 낭품지 확인사전 )

- 낭비의 제거, 품질 내재화, 지식 창출, 늦은 확정, 빠른 인도, 사람 존중, 전체 최적화

​

3. 사용자 인터페이스 ( UI; User Interface )

- 사용자와 시스템 간의 매개체 기능을 하는 모든 것

- UI 설계 원칙 ( 직유학유 )

: 직관성, 유효성, 학습성, 유연성

>> 직관성 ( Intuitiveness ) - 누구나 쉽게 이해하고, 쉽게 사용할 수 있어야 한다는 원칙

>> 유효성 ( Efficiency ) - 추가되어야 할 UI 설계원칙은 정확하고 완벽하게 사용자의 목표가 달성될 수 있도록 제작해야 한다는 원칙

>> 학습성 ( Learnability ) - 초보와 숙련자 모두가 쉽게 배우고 사용할 수 있게 제작해야 한다는 원칙

>> 유연성 ( Flexibility ) - 사용자의 인터랙션을 최대한 포용하고, 실수를 방지할 수 있도록 제작해야 한다는 원칙

​

- UI 표준 구성 요소 ( 액정 스패조 )

: 전체적인 UX 원칙, 정책 및 철학, UI 스타일 가이드, UI패턴 모델 정의, UI표준 수립을 위한 조직 구성

​

- UI 컨셉션 단계의 세부 수행 활동 ( 정와스 )

: 정보 구조 설계, 와이어 프레임 스케치, 스토리 보드 설계

​

- UI 설계 프로세스 ( 문사 작컴 인디 )

: 문제 정의 > 사용자 모델 정의 > 작업 분석 > 컴퓨터 오브젝트 및 기능 정의 > 사용자 인터페이스 정의 > 디자인 평가

​

- UI 흐름 설계 ( 기입유양 )

: 기능 작성 > 입력 요소 확인 > 유스케이스 설계 > 기능 및 양식 확인

​

4. 인터페이스 요구사항 검증 항목

- 완전성, 일관성, 명확성, 기능성, 검증 가능성, 수정 용이성, 추적 가능성, 개발 후 이용성

- 완전성 : 사용자의 모든 요구사항이 누락되지 않고 완전하게 반영되었는가?

- 일관성 : 요구사항이 모순되거나 충돌되는 점 없이 일관성을 갖고 있는가?

               공통 기능 간에 상호 충돌이 없도록 작성

- 명확성 : 모든 참여자가 요구사항을 명확히 이해할 수 있는가?

               해당 기능에 대해 일관되게 이해되고 한 가지로 해석될 수 있도록 작성해야하는 원칙

- 기능성 : 요구사항이 '어떻게'보다 '무엇을'에 중점을 두고 있는가?

- 검증 가능성 : 요구사항이 사용자의 요구를 모두 만족하고, 사용자의 요구 내용과 일치하는지를 검증할 수 있는가?

- 수정 용이성, 추적 가능성, 개발 후 이용성

​

5. 결합도와 응집도

- 결합도 : 상호의존의 정도, 결합도가 약해야 품질이 상승

[ 결합도가 약한 순서 -> 강한 순서 ]

data – stamp – control – external – common - content

자스(잤으)니까 합격제외 공부는 나(내)처럼

자료-데이터 / 스탬프-자료구조 / 제어-다른 모듈에서 흐름 파악 / 외부-참조 / 공통-공유되는 / 내용-직접참조,다른모듈에서 사용

- 자료: 어떤 모듈이 다른 모듈을 호출하면서 매개 변수나 인수로 데이터를 넘겨주고, 호출 받은 모듈은 받은 데이터에 대한 처리 결과를 다시 돌려주는 방식

- 스탬프: 두 모듈이 동일한 자료 구조를 조회하는 경우

- 제어: 한 모듈이 다른 모듈의 상세한 처리 절차를 알고 있어 이를 통제하는 경우나 처리 기능이 두 모듈에 분리되어 설계된 경우, 다른 모듈에서 흐름을 제어

- 외부: 어떤 모듈에서 선언한 데이터를 외부의 다른 모듈에서 참조할 때

- 공통: 공유되는 공통 데이터 영역을 여러 모듈이 사용할 때

- 내용: 한 모듈이 다른 모듈의 내부 기능 및 그 내부 자료를 직접 참조하거나 수정할 때

( 다른 모듈에서 사용하는 경우 )

 

​

- 응집도 : 정보은닉 개념 확장, 응집도가 강할수록 품질이 좋음

[ 응집도가 강한 순서 -> 약한 순서]

functional – sequential – communication – procedural – temporal – logical – coincidental

기엽고 순진한 교회오빠는 절은 시러 노우

기능-단일 / 순차-나온것 입력으로 / 통신-동일한입출력 다른기능수행

절차-다수의 관련기능 순차수행 / 시간-특정시간 / 논리-유사한 성격 / 우연-서로 관련 없는 요소

- 기능적 : 모듈 내부의 모든 기능 요소들이 단일 문제와 연관되어 수행될 경우

- 순차적 : 모듈 내 하나의 활동으로부터 나온 출력 데이터를 그 다음활동의 입력 데이터로 사용할 경우

- 통신적(교환적) : 동일한 입출력을 사용하여 서로 다른 기능을 수행하는 구성 요소들이 모였을 경우

- 절차적 : 모듈이 다수의 관련 기능을 가질 때 모듈 안의 구성요소들이 그 기능을 순차적으로 수행할 경우

- 시간적 : 특정 시간에 처리되는 몇 개의 기능을 모아 하나의 모듈로 작성한 경우

- 논리적 : 유사한 성격을 갖거나 특정 형태로 분류되는 처리요소들이 하나의 모듈이 되는 경우

- 우연적 : 모듈 내부의 각 구성요소들이 서로 관련 없는 요소로만 구성된 경우

​

6. 소프트웨어 아키텍처

- 여러가지 소프트웨어 구성요소와 그 구성요소가 가진 특성 중에서 외부에 드러나는 특성

- 구성요소 간의 관계를 표현하는 시스템의 구조나 구조체

- 4+1뷰 ( 유논프구배 )

: 유스케이스 뷰, 논리 뷰, 프로세스 뷰, 구현 뷰, 배포 뷰

​

7. 아키텍처 비용 평가 모델

- 종류 ( S A C A A )

: SAAM, ATAM, CBAM, ADR, ARID

>> CBAM : 경제적 의사결정에 대한 요구를 충족하며 ATAM 바탕의 시스템 아키텍처 분석 중식의 경제적 모델링 방법 모델

​

8. 내/외부 인터페이스 관련 요구사항

- 식별 및 분류 방안 ( 식명기 )

: 요구사항 식별 > 명세서 및 현황 자료 준비 > 기능 요구사항 및 비기능 요구사항 분류

- 명세서 구체화 단계 ( 세이신정 )

: 요구사항 정의서 세분화 > 요구사항 내용의 이해 및 수정 > 요구사항 신규 정의 > 요구사항 정리

​

9. 요구사항 관리 절차 ( 협기변확 )

- 요구사항 협상 > 요구사항 기준선 > 요구사항 변경 관리 > 요구사항 확인 및 검증

​

10. EAI와 ESB

- EAI ( Enterprise Application Integration )

: 비즈니스 프로세스를 중심으로 기업 내 각종 애플리케이션 간의 상호 연동이 가능하도록 대상 시스템에 비표준 어댑터를 배포하여 통합하는 솔루션

포인트 투 포인트, 허브 앤 스포크, 메시지 버스, 하이브리드

​

- ESB ( Enterprise Service Bus )

: 애플리케이션 간의 통합 측면에서 EAI와 유사하지만 서비스 중심 ( coupling loosely )

개방형 표준인 웹 서비스를 이용하여, 메시징과 웹 서비스, 데이터 변형, 인텔리전트 라우팅을 결합하여 다양한 애플리케이션 간의 연결과 상호작용을 지원하는 표준 기반의 미들웨어 플랫폼

​

>> 세부 토폴로지 : 허브 앤 스포크, 어댑터, 브로커, 메시지 큐

​

11. 플랫폼(Platform)

- 애플리케이션 구동 시 필요한 하드웨어, 소프트웨어 결합

- 동일 플랫폼 내에서는 상호 호환이 가능하도록 만들어진 결합체이자 구축 환경

- 성능 특성 분석 기법

- 사용자 인터뷰 : 현행 플랫폼 사용자 인터뷰를 통해 속도의 적정성 확인(인터뷰 결과서)

- 성능 테스트 : 현행 플랫폼을 대상으로 성능, 부하 테스트를 수행(성능 테스트 결과서, 부하 테스트 결과서)

- 산출물 점검 : 현재 플랫폼과 유사한 타사 제품의 성능 자료 등을 분석(벤치마킹 테스트 결과서)

​

12. 요구사항 개발 프로세스

- 요구사항 : 원하는 서비스에 대한 설명 및 운영에 필요한 제약 조건

- 도출 > 분석 > 명세 > 확인

​

- 도출(요구사항 수집 단계)

: 이해관계자 간의 의사소통 중요 ( 인터뷰, 브레인스토밍, 프로토타이핑, 유스케이스 )

​

- 분석(요구사항 분석 단계)

: 도출된 요구사항의 타당성 조사, 내용 정리 ( 중복 제거, 요구사항 통합 )

>> 요구사항 분류 : 특정한 기준으로 분류 ( 기능, 비기능 우선순위 )

- 개념 모델링 : 분류된 요구사항 단순화하여 개념적으로 표현, UML 사용

- 요구사항 할당 : 요구사항을 만족시키기 위한 요소들을 할당

- 요구사항 협상 : 충될되는 요구사항 해결

- 정형 분석 : 구문과 의미를 갖는 언어 이용, 수학적 기호

​

- 명세 (요구사항 문서화 단계)

: 승인을 위해 문서화 진행, 빠짐없이 명확하고 이해하기 쉽게 기록

​

- 확인(요구사항 검증 단계)

: 명세서 검증, 형상관리 수행

>> 요구사항 검토 : 가장 일반적, 훑어보기

>> 프로토타이핑 : 프로토타입을 만든 후 요구사항 반영하면서 지속적으로 프로토타입 재작성

>> 모델 검증 : 요구사항 분석 단계에서 개발된 모델이 요구사항을 충족시키는지 검증

>> 인수 테스트 : 사용자가 실제로 사용될 환경에서 요구사항들이 모두 충족되는지 사용자 입장에서 확인하는 과정

- 알파 테스트 : 선별된 사용자가 개발자와 함께 검사 ( 통제된 환경 )

- 베타 테스트 : 선별된 사용자가 여러 사용자를 통해 검사 ( 통제되지 않은 환경 )

​

* 테이블 정의서 : 논리 및 물리 모델링 과정에서 작성하는 설계 산출물로 테이블을 구성하는 컬럼들의 특성, 인덱스, 업무 규칙을 문서화한 것

* 개체 정의서 : 도출한 개체의 타입과 관련 속성, 식별자 등의 정보를 개괄적으로 명세한 정의서

​

* 코드의 종류

- 순차 코드 ( = 순서코드, 일련 번호 코드 )

: 자료의 발생 순서, 크기 순서 등 일정 기준에 따라서 최초의 자료부터 차례로 일련번호를 부여하는 방법

- 블록 코드 ( = 구분 코드 )

: 코드화 대상 항목 중에서 공통성이 있는 것끼리 블록으로 구분하고 각 블록내에서 일련번호를 부여하는 방법

- 10진 코드 ( = 도서 분류식 코드 )

: 코드화 대상 항목을 0~9까지 10진 분할하고, 다시 그 각각에 대하여 10진 분할 하는 방법을 필요한 만큼 반복하는 방법

- 그룹 분류 코드

: 코드화 대상 항목을 일정 기준에 따라 대분류, 중분류, 소분류 등으로 구분하고 각 그룹 안에서 일련번호를 부여하는 방법

- 연상 코드

: 코드화 대상 항목의 명칭이나 약호와 관계있는 숫자나 문자 기호를 이용하여 코드를 부여하는 방법

- 표의 숫자 코드 ( = 유효숫자 코드 )

: 코드화 대상 항목의 성질, 즉 길이, 넓이, 부피, 높이 등의 물리적 수치를 그대로 코드에 적용시키는 방법

- 합성 코드

: 2개 이상의 코드를 조합하여 만드는 방법

​

* 내.외부 송/수신 연계 기술

DB 링크, DB 연계 기술, Open API 활용, 하이퍼링크

- DB 링크

  : 테이블명@DBLink명

- DB 연결 기술

  : 수신 시스템의 WAS에서 송신 시스템 DB로 연결하는 DB 커넥션 풀을 생성하고 연계 프로그램에서 해당 DB 커넥션 풀명을 이용하는 방식

  : 송신 시스템의 Data Source = DB Connection Pool 이름

- Open API 활용

- 하이퍼링크

​

* 객체지향 설계 원칙 ( 5대 원칙, SOLID )

- 단일 책임의 원칙 ( SRP/Single Response Principle )

: 하나의 클래스는 하나의 목적을 위해서 생성되며, 클래스가 제공하는 모든 서비스는 하나의 책임을 수행하는데 집중되어 있어야 한다는 원칙

- 개방 폐쇄 원칙 ( OCP/Open Closed Principle )

: 소프트웨어의 구성요소(컴포넌트, 클래스, 모듈, 함수)는 확장에는 열려있고, 변경에는 닫혀있어야 한다는 원칙

- 리드코프 치환의 원칙 ( LSP/Liskov Substitution Principle )

: 자식 클래스(서브 타입)는 언제나 자신의 부모 클래스(기반 타입)를 대체하는다는 원칙

- 인터페이스 분리의 원칙 ( ISP/Interface Segregation Principle )

: 한 클래스는 자신이 사용하지 않는 인터페이스는 구현하지 말아야 한다는 원칙

- 의존성 역전의 원칙 ( DIP/Dependancy Inversion Priciple )

: 실제 사용 관계는 바뀌지 않으며, 추상을 매개로 메시지를 주고받음으로써 관계를 최대한 느슨하게 만드는 원칙

​

* CASE

- 소프트웨어 개발 과정에서 사용되는 요구 분석, 설계, 구현, 검사 및 디버깅 과정

- 전체 또는 일부를 컴퓨터와 전용 소프트웨어 도구를 사용하여 자동화 하는 것

- 상위 CASE : 전반부에서 사용, 요구 분석과 설계 단계

- 하위 CASE : 하반부에서 사용, 코드의 작성과 테스트, 문서화 과정

- 통합 CASE : 전체 과정을 지원

 

* 웹 콘텐츠 접근성(사용성) 지침

- 인식의 용이성을 위한 지침

- 운용의 용이성을 위한 지침

  : 키보드 접근성 제공, 충분한 시간의 제공 필요, 쉬운 내비게이션 제공

- 이해의 용이성을 위한 지침

  : 가독성 확보, 예측 가능성 확보, 콘텐츠의 논리성 제공, 입력 오류 방지 및 정정 가능 제공

- 견고성을 위한 지침

  : 웹 콘텐츠는 마크업 언어 문법 준수, 웹 애플리케이션 접근성 제공

 

* 소프트웨어 설계 유형

- 자료구조 설계

  : 요구분석 단계에서 생성된 정보를 바탕으로 소프트웨어를 구현하는데 필요한 자료구조로 변환하는 과정

- 플랫폼 설계

- 인터페이스 설계

  : 소프트웨어와 상호 작용하는 컴퓨터 시스템, 사용자 등이 어떻게 통신하는지를 기술

- 프로시저 설계

  : 프로그램 아키텍처의 컴포넌트를 소프트웨어 컴포넌트의 프로시저 서술로 변환하는 과정

​

​

​

* 이 게시물은 수제비 카페 - 페코페코 예상문제 OX 게시글을 참고로 작성되었습니다.

https://cafe.naver.com/soojebi

 

* 과목별 정리

2020/08/13 - [정보처리기사/1과목 소프트웨어 설계] - 정보처리기사 필기 ) 1과목 소프트웨어 설계 정리

2020/08/13 - [정보처리기사/2과목 소프트웨어 개발] - 정보처리기사 필기 ) 2과목 소프트웨어 개발 정리

2020/08/14 - [정보처리기사/4과목 프로그래밍언어 활용] - 정보처리기사 필기 ) 4과목 프로그래밍 언어 활용 정리

2020/08/14 - [정보처리기사/5과목 정보시스템 구축관리] - 정보처리기사 필기 ) 5과목 정보시스템 구축 관리 정리 1

2020/08/14 - [정보처리기사/5과목 정보시스템 구축관리] - 정보처리기사 필기 ) 5과목 정보시스템 구축 관리 정리 2

2020/08/14 - [정보처리기사/1과목 소프트웨어 설계] - 정보처리기사 필기) 수제비 모의고사 정리 - 1과목 소프트웨어 설계

2020/08/18 - [정보처리기사/1과목 소프트웨어 설계] - 정보처리기사 필기) 시나공 모의고사 정리 - 1과목 소프트웨어 설계