728x90
필기1과목 -소프트웨어 설계
1. 소프트웨어 생명 주기
1) 폭포수 모형(Waterfall Model) ★
- 가장 오래되고 가장 폭넓게 사용된 고전적 생명 주기 모형
- 한 단계가 끝나야만 다음 단계로 넘어가는 선형 순차적 모형
- 단계별 정의 및 산출물이 명확
- 개발 중간에 요구사항의 변경이 용이하지 않음
- 타당성검토 → 계획 → 요구 분석 → 설계 → 구현(코딩) → 테스트(검사) → 유지보수
#분설구테유
2) 프로토타입 모형(Prototype Model, 원형 모형) ★
- 견본(시제)품을 만들어 최종 결과물을 예측하는 모형
- 인터페이스 중점을 두어 개발
- 개발 중간에 요구사항의 변경이 용이
3) 나선형 모형(Spiral Model, 점진적 모형) ★ __ 20년 1, 2, 3회 기출문제
- 폭포수 모형과 프로토타입 모형의 장점에 위험 분석 기능을 추가한 모형
- 점진적 개발 과정 반복으로 요구사항 추가 가능
- 정밀하고 유지보수 과정 필요 없음
- 계획 및 정의 → 위험 분석 → 공학적 개발 → 고객 평가
#계위개고
4) 애자일 모형(Agile Model) ★★ __ 20년 1, 2, 3, 4회 기출문제
- 애자일은 민첩함, 기민함 의미
- 변화에 유연하게 대응
- 일정한 주기(Iteration, Sprint)를 반복하면서 개발과정 진행
- 절차와 도구보다 고객(개인)과의 소통 에 초점을 맞춤
ex) XP(eXtreme Programming), 스크럼(Scrum), 칸반(Kanban), 크리스탈(Crystal), 린(LEAN)
#엑스칸크린
- 기능중심 개발
2. 스크럼(Scrum) 기법 ★
- 팀원 스스로가 스크럼 팀 구성
- 개발 작업에 관한 모든 것을 스스로 해결해야 함
- 스프린트는 2 ~ 4주 정도의 기간 으로 진행
1) 제품 책임자(PO; Product Owner) ★
- 요구사항이 담긴
- 백로그(Backlog)를 작성하는 주체
- 백로그에 대한 우선순위를 지정, 이해관계자들의 의견을 종합
2) 스크럼 마스터(SM; Scrum Master)
- 일일 스크럼 회의 주관
- 팀원들을 통제하는 것이 목표가 아님
3) 개발팀(DT; Development Team)
- 제품 책임자와 스크럼 마스터를 제외한 모든 팀원
- 최대 인원 7~8명
4) 스크럼 개발 프로세스
- 스프린트 계획 회의 → 스프린트 → 일일 스크럼 → 스크럼 검토 회의 → 스프린트 회고
#계스일검회
3. XP 기법 ★★
1) XP(eXtreme Programming)의 핵심 가치 ★
- 용기(Courage), 단순성(Simplicity), 의사소통(Communication), 피드백(Feedback), 존중(Respect)
#용단의피존
2) XP의 기본원리 __ 20년 4회 기출문제
- Whole Team(전체 팀), Small Releases(소규모 릴리즈)
Test-Driven Development(테스트 주도 개발), Continuous Integration(계속적인 통합)
Collective Ownership(공동 소유권), Pair Programming(짝 프로그래밍)
Design Improvement(디자인 개선) 또는Refactoring(리팩토링)
#전소테 계공짝디
4.개발 기술 환경 파악 ★
1) 운영체제(OS; Operating System)
- 하드웨어가 아닌 소프트웨어 # Windows, UNIX, Linux, Mac OS | iOS, Android 등등
- 가용성, 성능 | 기술 지원, 구축 비용, 주변 기기 (고려사항)
#가성기구주
2) 미들웨어(Middleware)
- 운영체제와 응용 프로그램 사이에서 추가적인 서비스를 제공하는 소프트웨어
3) 데이터베이스 관리 시스템(DBMS; Database Management System)
- 사용자와 데이터베이스(DB) 사이에서 정보를 생성하고 DB를 관리하는 소프트웨어
- 데이터베이스(DB)의 구성, 접근 방법, 유지관리에 대한 모든 책임을 짐
- JDBC(Java Database Connectivity, 자바), ODBC(Open Database Connectivity, 응용 프로그램)
- Oracle, MySQL, SQLite, MongoDB, Redis 등등
- 가용성, 성능 | 기술 지원, 구축 비용, 상호 호환성 (고려사항) ★ __ 1, 2회 기출문제
#가성기구호
4) 웹 어플리케이션 서버(WAS; Web Application Server) ★
- 정적인 콘텐츠를 처리하는 웹 서버(Web Server)와 반대됨
- 동적인 콘텐츠를 처리하기 위해 사용되는 미들웨어(=소프트웨어)
- 데이터 접근, 세션 관리, 트랜잭션 관리 등을 위한 라이브러리를 제공
- Tomcat, JEUS, WebLogic, JBoss, Jetty, Resin 등등
- 가용성, 성능 | 기술 지원, 구축 비용 (고려사항)
#가성기구
5) 오픈 소스(Open Source)
- 누구나 별다른 제한 없이 사용할 수 있도록 소스 코드를 무료로 사용할 수 있게 공개한 것
- 라이선스의 종류, 사용자 수, 기술의 지속 가능성 (고려사항)
#라사지
5. 요구사항 정의 ★
1) 기능 요구사항
- 기능, 입력, 출력, 저장, 수행 등등
2) 비기능 요구사항
- 성능, 품질, 제약사항, 호환성, 보안 등등
3) 요구사항 개발 프로세스 ★ __ 5-5
- 도출(Elicitation)/추출 → 분석(Analysis) → 명세(Specification) → 확인(Validation)/검증(Valification)
#도분명확 #추분명검
4) 요구사항 분석 기법 ★
- 요구사항 분류, 개념 모델링(UML), 요구사항 할당, 요구사항 협상, 정형 분석
#분개할협정
5) 요구사항 확인 기법 ★★ __ 20년 1, 2, 3회 기출문제
- 요구사항 검토, 프로토타이핑, 모델 검증, 인수 테스트(알파 테스트, 베타 테스트)
#검프모인
6. UML ★★★
1) UML(Unified Modeling Language)의 구성 요소 ★
- 사물, 관계, 다이어그램
#사관다
2) 사물(Things)
- 구조, 행동, 그룹, 주해 {사물}
#구행그주
3) 관계(Relationships) ★★ __ 20년 3회 기출문제
- 연관(ㅡ), 집합(◇), 포함(◆), 일반화(ㅡ▷), 의존(-->), 실체화(--▷) {관계}
#연집포 일의실
4) 구조적, 정적 다이어그램(Diagram) ★★ __ 20년 1, 2, 3회 기출문제
- 클래스(Class), 객체(Object), 컴포넌트(Component), 배치(Deployment),
복합체 구조(Composite Structure), 패키지(Package) {다이어그램(Diagram)}
- 컴포넌트, 배치 다이어그램은 구현 단계에서 사용되는 다이어그램임 ★
#클객컴 배복패
5) 행위, 동적 다이어그램(Diagram) ★★ __ 20년 1, 2, 3회 기출문제
- 유스케이스(Use Case, 사용사례), 시퀀스(Sequence, 순차),
커뮤니케이션(Communication, 협업), 상태(State), 활동(Activity),
상호작용 개요(Interaction Overview), 타이밍(Timing) {다이어그램(Diagram)}
#유시커 상활호타
7. 사용자 인터페이스(UI; User Interface) ★
1) UI의 구분 ★
- CLI(Command Line Interface): 텍스트 형태로 이뤄진 인터페이스
- GUI(Graphical User Interface): 마우스로 선택해 작업을 하는 그래픽 환경의 인터페이스
- NUI(Natural User Interface): 사용자의 말이나 행동으로 기기를 조작하는 인터페이스
- VUI(Voice User Interface): 사람의 음성으로 기기를 조작하는 인터페이스
- OUI(Organic User Interface): 모든 사물과 사용자 간의 상호작용을 위한 인터페이스
2) UI의 기본 원칙 ★★ __ 20년 1, 2회 기출문제
- 직관성: 누구나 쉽게 이해하고 사용 할 수 있어야함
- 유효성: 사용자의 목적을 정확하고 완벽하게 달성해야 함
- 학습성: 누구나 쉽게 배우고 익힐 수 있어야함
- 유연성: 사용자의 요구사항을 최대한 수용하고 실수를 최소화해야 함
#직유학연
3) 웹의 3요소
- 웹 표준(Web Standards), 웹 접근성(Web Accessibility), 웹 호환성(Cross Browsing)
#표접호
4) UI 설계 도구 ★
- 와이어프레임(Wireframe): 레이아웃을 협의하거나 공유하기 위해 사용
- 스토리보드(Story Board): 최종적으로 참고하는 작업 지침서, 작업 산출물(디스크립션)
- 프로토타입(Prototype): 인터랙션을 적용해 실제 구현된 것처럼 테스트가 가능한 동적인 모형
- 목업(Mockup): 실제 화면과 유사한 정적인 모형
- 유스케이스(Use Case): 사용자 측면 요구사항을 다이어그램 형식으로 묘사 (유스케이스 명세서)
#와스프목유
5) UI 프로토타입
▶ 장점: 사용자를 설득하고 이해시키기 쉬움 | 개발 시간을 줄일 수 있음 | 사전 오류 발견 가능
▶ 단점: 반복적인 개선 및 보완 작업으로 인한 작업 시간 증가 및 자원 소모 | 부분적인 프로토타이핑으로 인한 중요한 작업 생략 가능성
페이퍼 프로토타입, 디지털 프로토타입, HTML/CSS
6) UI 시나리오 문서 요건
- 이해성(Understandable): 누가나 쉽게 이해할 수 있도록 설명
- 완전성(Complete): 최대한 상세하게 기술
- 일관성(Consistent): 일관성 유지
- 가독성(Readable): 표준화된 템플릿 등을 활용하여 문서를 쉽게 읽을 수 있도록 해야함
- 수정 용이성(Modifiable): 수정 및 개선이 쉬워야 함
- 추적 용이성(Traceable): 변경사항에 대해서 쉽게 추적할 수 있어야 함
#이완일 가수추
7) 기타
- HCI(Human Cumputer Interaction or Interface): {사람}과 {컴퓨터}의 {상호작용}을 연구해서 사람이 컴퓨터를 편리하게 사용하도록 만드는 학문
- UX(User Experience): 사용자가 시스템이나 서비스를 이용하면서 느끼고 생각하는 총체적인 경험
- 주관성(Subjecctivity), 정황성(Contextuality), 총체성(Holistic)
- 감성공학: 1류; 인간의 감성 / 2류; 심리적 기능/ 3류;공학적 및 수학적 모델, 객관적
8. 품질 요구사항 ★
1) 국제 제품 품질 표준 (수제비) ★
- ISO/IEC 9126
- ISO/IEC 12119
- ISO/IEC 14598
- ISO/IEC 25000: SW 품질 평가 통합 모델, SQuaRE 로도 불리며 위 3개 표준을 통합 품질 관리(2500n), 품질 모델(2501n), 품질 측정(2502n), 품질 요구(2503n), 품질 평가(2504n) #관모측요평
2) ISO/IEC 9126 ★★ __ 20년 1, 2, 3회 기출문제
- 기능성(Functionality): 요구사항을 정확하게 만족하는 기능을 제공하는가?
적절성(적합성), 정확성, 상호 운용성, 보안성, 호환성
- 신뢰성(Reliability): 요구된 기능을 정확하고 일관되게 오류 없이 수행하는가?
성숙성, 결함 허용성, 회복성
- 사용성(Usability): 사용자가 정확하게 이해하고 사용하는가?
이해성, 학습성, 운용성, 친밀성
- 효율성(Efficiency): 할당된 시간 동안 한정된 자원으로 얼마나 빨리 처리하는가?
시간 효율성, 자원 효율성
- 유지 보수성(Maintainability): 환경의 변화에 소프트웨어를 쉽게 개선, 확장, 수정할 수 있는가?
분석성, 변경성, 안정성, 시험성
- 이식성(Portability): 소프트웨어를 다른 환경에서도 쉽게 적용할 수 있는가?
적용성, 설치성, 대체성, 공존성
#기신사 효유이
3) ISO/IEC 14598 (수제비)
- 반복성(Repeatability), 재현성(Reproducibility), 공정성(Impartiality), 객관성(Objectivity)
#반재공객
4) 국제 프로세스 품질 표준
- ISO/IEC 9001
- ISO/IEC 12207: 기본 프로세스, 조직 프로세스, 지원 프로세스 #기조지
- ISO/IEC 15504(SPICE): 불완전 → 수행 → 관리 → 확립 → 예측 → 최적화 #불수관 확예최
- CMMI(Capability Maturity Model Integration): 조직차원의 성숙도를 평가하는 단계별 표현과 프로세스 영역별 능력도를 평가하는 연속적 표현이 있음
- 사용자의 비기능적 요구사항으로 나타난 제약 반영
- 기능적 요구사항을 구현하는 방법을 찾는 해결 과정
- 시스템 기능들을 모듈 단위로 나눠 소프트웨어의 성능 및 재사용성을 향상시키는 것
- 모듈의 크기 多: 모듈 개수 적음 | 모듈 간 통합 비용 적음 | 모듈 하나의 개발 비용 큼
- 모듈의 크기 小: 모듈 개수 많음 | 모듈 간 통합 비용 큼
- 전체적이고 포괄적인 개념을 설계한 후 차례로 세분화하여 구체화 시키는 것
- 과정 추상화: 자세한 수행 과정을 정의하지 않고, 전반적인 흐름만 파악
- 데이터 추상화: 데이터의 세부적인 속성이나 용도를 정의하지 않고, 데이터구조를 대표하는 표현으로 대체
- 제어 추상화: 이벤트 발생의 정확한 절차나 방법을 정의하지 않고, 대표하는 표현으로 대체
- Niklaus Wirth에 의해 제안된 하향식 설계 전략
- 추상화의 반복에 의해 세분화
- 소프트웨어 기능에서부터 시작해 절차적으로 구체화
- 상세한 내역은 가능한 한 뒤로 미루어 진행
- 한 모듈 내부에 포함된 절차와 자료들의 정보가 감추어져 다른 모듈이 접근하거나 변경하지 못하도록 하는 기법
- 정보 은닉을 통한 독립적 모듈 수행 가능
- 모듈 변경 시 영향을 받지 않아수정, 시험, 유지보수 용이
10. 아키텍처 패턴 ★
1) 레이어 패턴(Layers Pattern)- 시스템을 계층(Layer)으로 구분하여 구성하는 고전적 방법 # OSI 참조 모델 ★
- 하나의 서버 컴포넌트와 다수 클라이언트 컴포넌트로 구성되는 패턴
- 클라이언트나 서버는 요청과 응답을 받기 위해 동기화 되는 경우를 제외하고는 서로 독립적
- 데이터 스트림 절차의 각 단계를 필터 컴포넌트로 캡슐화해 파이프를 통해 데이터를 전송하는 패턴
- 필터 컴포넌트는 재사용성이 좋고, 추가가 쉬워 확장 용이
- 필터 컴포넌트들을 재배치하여 다양한 파이프라인 구축 가능
UNIX의 쉘(Shell)
4) 모델-뷰-컨트롤러 패턴(Model-View-Controller Pattern) ★★- 서브시스템을 3개의 부분으로 구조화하는 패턴
- 모델(Model): 서브시스템의 핵심 기능과 데이터를 보관
- 뷰(View): 사용자에게 정보를 표시
- 컨트롤러(Controller): 사용자로부터 받은 입력 처리 / 뷰 제어 / UI 담당
- 각 부분은 별도의 컴포넌트로 분리되어 있으므로 서로 영향을 받지 않고 개발 작업 수행
- 한 개의 모델에 대해 여러 개의 뷰를 만들 수 있으므로 대화형 애플리케이션에 적합
- 마스터 컴포넌트에서 슬레이브 컴포넌트로 분할한 후, 슬레이브 컴포넌트에서 처리된 결과물을 다시 돌려받는 방식으로 작업을 수행하는 패턴
장애 허용 시스템(Fault Tolerance System), 병렬 컴퓨팅 시스템 ★
6) 브로커 패턴(Broker Pattern)- 컴포넌트와 사용자를 연결해주는 패턴
분산 환경 시스템
7) 피어-투-피어 패턴(Peer-To-Peer Pattern)- 피어를 하나의 컴포넌트로 간주하며, 각 피어는 서비스를 호출하는 클라이언트가 될 수도 , 서비스를 제공하는 서버가 될 수도 있는 패턴
멀티스레딩(Multi Threading) 방식 사용
8) 이벤트-버스 패턴(Event-Bus Pattern)- 소스가 특정 채널에 이벤트 메시지를 발행하면, 해당 채널을 구독한 리스너들이 메시지를 받아 이벤트를 처리하는 방식
- 이벤트를 생성하는 소스(Source), 이벤트를 수행하는 리스너(Listener), 이벤트의 통로인 채널(Channel), 채널들을 관리하는 버스(Bus)
- 해결책이 명확하지 않은 문제를 처리 하는데 유용한 패턴
음성인식, 차량 식별, 신호 해석 ★
10) 인터프리터 패턴(Interpreter Pattern)- 특정 언어로 작성된 프로그램 코드를 하는 컴포넌트를 설계할 때 사용됨1) 객체(Object)
- 독립적으로 식별 가능한 이름을 갖고 있음
- 객체가 가질 수 있는 조건인 상태(State)는 일반적으로 시간에 따라 변함
- 객체와 객체는 상호 연관성에 의한 관계가 형성됨
- 객체가 반응할 수 있는 메시지의 집합을 행위(연산, Method)라고 하며, 객체는 행위의 특징을 나타냄
- 객체는 일정한 기억장소를 갖고 있음
- 하나 이상의 유사한 객체들을 묶어서 하나의 공통된 특성을 표현한 것★
- 공통된 속성과 연산(행위)를 갖는 객체의 집합
- 객체지향 프로그램에서 데이터를 추상화하는 단위★
- 각각의 하고 있는 틀 객체들이 갖는 속성과 연산(Method)을 정의
- 슈퍼 클래스(Super Class)는 특정 클래스의 상위(부모) 클래스
- 서브 클래스(Sub Class)는 특정 클래스의 하위(자식) 클래스
- 클래스에 속한 각각의 객체
- 클래스로부터 새로운 객체를 생성하는 것을 인스턴스화(Instantiation)라고 함
- 클래스로부터 생성된 객체를 사용하는 방법
- 전통적 시스템의 함수(Function) 또는 프로시저(Procedure)에 해당하는 연산
- 객체에게 어떤 행위를 하도록 지시하기 위한 방법
- 데이터(속성)와 데이터를 처리하는 함수를 하나로 묶는 것
- 인터페이스를 제외한 세부 내용이 은폐(정보 은닉)되어 외부 접근이 제한됨
- 정보 은닉 측면과 가장 밀접한 관계가 있음
- 외부 모듈의 변경으로 인한 파급 효과가 적음
- , 재사용 용이 , 인터페이스 단순해짐
- 결합도 Down / 응집도 Up
- 이미 정의된 상위(부모) 클래스의 모든 속성과 연산을 하위(자식) 클래스가 물려받는 것
- 소프트웨어의 재사용(Reuse)을 높이는 중요한 개념
- 한 개의 클래스가 두 개 이상의 상위(부모) 클래스로부터 속성과 연산을 상속받는 것
- 하나의 메시지에 대해 각각의 객체(클래스)가 가지고 있는 고유한 방법(특성)으로 응답할 수 있는 능력
- 모듈간 에 상호 의존하는 정도 또는 두 모듈 사이의 연관 관계를 의미
- 결합도는 낮을수록(↓) Good = 독립적인 모듈듈
- 한 모듈이 다른 모듈의 내부 기능 및 그 내부 자료를 직접 참조하거나 수정할 때의 결합도
- 공유되는 공통 데이터 영역을 여러 모듈이 사용할 때의 결합도 (전역 변수)
- 어떤 모듈에서 선언한 데이터(변수)를 외부의 다른 모듈에서 참조할 때의 결합도 (순차적)
- 어떤 모듈이 다른 모듈 내부의 논리적인 흐름을 제어하기 위해 제어신호를 이용하여 통신하거나 제어요소를 전달하는 결합도
- 모듈 간의 인터페이스로 배열이나 레코드 등의 자료 구조가 전달될 때의 결합도
- 어떤 모듈이 다른 모듈을 호출하면서 매개 변수(파라미터)나 인수로 데이터를 넘겨주고, 호출 받은 모듈은 받은 데이터에 대한 처리 결과를 다시 돌려주는 결합도
- 1) 내용 결합도(Content Coupling)
- 12. 결합도(Coupling) ★★
- 6) 캡슐화(encapsulation) __ 20년 3회 기출문제
- 11. 객체지향(Object-Oriented) ★★
- 9) 블랙보드 패턴(Blackboard Pattern)
- 3) 파이프-필터 패턴(Pipe-Filter Pattern) ★
- 3) 단계적 분해(Stepwise Refinement)
- 1) 모듈화(Modularity)
- 9. 소프트웨어 아키텍처 ★
728x90
댓글