★ 폭포수 모형
- 가장 오래되고 폭넓게 사용된 고전적 생명 주기 모형
- 한 단계가 끝나야만 다음 단계로 넘어가는 선형 순차적 모형
- 단계별 정의 및 산출물이 명확
- 개발 중간에 요구사항의 변경이 용이하지 않음
- 타당성 검토 -> 계획 -> 요구 분석 -> 설계 -> 구현 -> 테스트 -> 유지보수
(분설구테유)
★ 프로토타입 모형
- 견본품으로 최종 결과물 예측 모형
- 개발 중간에 요구사항 변경 용이
★ 나선형(Spiral) 모형
- 폭포수와 프로토타입 모형 장점에 위험 분석 기능을 추가한 모형
- 점진적 개발 과정 반복으로 요구사항 추가 가능
- 정밀하고 유지보수 과정 필요없음
- 계획 및 정의 -> 위험 분석 -> 공학적 개발 -> 고객 평가
(계위개고)
★★ 애자일 모형
- 민첩함. 기민함 의미
- 변화에 유연하게 대응
- 일정한 주기를 반복하며 개발과정 진행
- 고객과의 소통에 초점을 맞춤
- 기능중심 개발
ex) XP, 스크럼, 칸반, 크리스탈,
린: 낭비제거, 품질 내재화, 지식 창출, 늦은 확정, 빠른 인도, 사람 존중, 전체 최적화,
ASD(Adaptive Software Development), FDD(Feature Driven), DSDM(동적 소프트웨어 개발 방법), DAD(Disciplined Agile Delivery)
-> 엑스칸크린
★ 스크럼 기법
- 개발 작업에 관한 모든 것 스스로 해결
- 스프린트는 2-4주 정도의 기간
1) 제품 책임자(PO, Product Owner)
- 요구사항이 담긴 백로그를 작성하는 주체
- 백로그에 대한 우선순위 지정, 이해관계자들의 의견 종합
2) 스크럼 마스터
- 스크럼 회의 주관
- 팀원 통제 목표 아님
3) 개발팀
- 제품 책임자와 스크럼 마스터를 제외한 모든 팀원(최대 7-8명)
4) 스크럼 개발 프로세스
- 스프린트 계획 회의 -> 스프린트 -> 일일 스크럼 -> 스크럼 검토 -> 스프린트 회고(계스일검회)
★★ XP(eXtreme Programming)
1) 핵심 가치★
-> 용기, 단순성, 의사소통, 피드백, 존중(용단의피존)
2)기본 원리
- 전체 팀, 소규모 릴리즈, 테스트 주도 개발, 계속적 통합, 공동 소유권, 짝 프로그래밍, 디자인 개선 또는 리팩토링
(전소테 계공짝디)
★ 개발 기술 환경 파악
1) 운영체제
- 하드웨어가 아닌 소프트웨어
- 가용성, 성능, 기술 지원, 구축 비용, 주변 기기(가성기구주)
2) 미들웨어
- 운영체제와 응용 프로그램 사이에서 추가적인 서비스를 제공하는 소프트웨어
3) 데이터베이스 관리 시스템
- 사용자와 데이터베이스 사이에서 정보를 생성하고 DB를 관리하는 소프트웨어
- DB의 구성, 접근 방법, 유지관리에 대한 모든 책임을 짐
- JDBC(Java Database Connectivity), ODBC(Open Database Connectivity)
- Oracle, MySQL, SQLite, MongoDB, Redis 등
- 가용성, 성능, 기술 지원, 구축 비용, 상호호환성 ★-> 가성 기구후
4) 웹 어플리케이션 서버(WAS) ★
- 정적인 콘텐츠를 처리하는 웹서버와 반대됨
- 동적인 콘텐츠를 관리하기 위해 사용하는 미들웨어
- 데이터 접근, 세션 관리 ,트랜잭션 관리 등을 위한 라이브러리 제공
- Tomcat, JEUS, WebLogic, JBoss, Jetty, Resin 등등
- 가용성, 성능, 기술 지원, 구축 비용(가성기구)
5) 오픈소스
- 무료로 사용할 수 있게 공개한 것
- 라이선스 종류, 사용자 수, 지속 가능성(라사지)
★ 요구사항 정의
1) 기능 요구사항
- 기능, 입력, 출력, 저장, 수행 등
2) 비기능 요구사항
- 성능, 품질, 제약사항, 호환성, 보안 등
3) 요구사항 개발 프로세스★
- 도출/추출 -> 분석 -> 명세 -> 확인/검증
(도분명확, 추분명검)
4) 요구사항 분석 기법★
- 분류, 개념 모델링(UML), 요구사항 할당/협상, 정형 분석
(분개할협정)
5) 요구사항 확인 기법★★
- 검토, 프로토타이핑, 모델 검증, 인수 테스트(검프모인)
★★★ UML
1) 구성요소★: 사물, 관계, 다이어그램(사관다)
2) 사물: 구조, 행동, 그룹, 주해(사물) (구행그주)
3) 관계★★: 연관(ㅡ), 집합(◇), 포함(🔹), 일반화(ㅡ▷), 의존(-->), 실체화(--▷)
(연집포 일의실)
4)구조적, 정적 다이어그램★★
- 클래스, 객체, 컴포넌트, 배치, 복합체 구조, 패키지(클객컴 배복패)
+ 컴포넌트, 배치 다이어그램은 구현 단계에서 사용되는 다이어그램
5) 행위, 동적 다이어그램★★
- 유스케이스, 시퀀스, 커뮤니케이션, 상태, 활동, 상호작용 개요, 타이밍(유시커 상활호타)
★ UI
1)UI 구분★
- CLI(Command), GUI(Graphical), NUI(Natural), VUI(voice), OUI(Organic)
2) 기본 원칙★★
- 직관성(쉽게 이해 사용), 유효성(목적 정확 완벽), 학습성(쉽게), 유연성(요구사항 최대한 수용)(직유학연)
3) 웹의 3요소
- 웹 표준, 접근성, 호환성(표접호)
4) 설계 도구★
- 와이어프레임: 레이아웃 협의, 공유
- 스토리보드: 작업 지침서, 작업 산출물
- 프로토타입: 테스트 가능한 동적 모형
- 목업: 실제 화면과 유사한 정적 모형
- 유스케이스: 사용자 측면 요구사항을 다이어그램 형식으로 묘사
(와스프목유)
5) UI 프로토타입
- 장점: 설득하고 이해 쉬움, 개발 시간 줄일 수 있음. 사전 오류 발견 가능
- 단점: 반복적인 개선, 보완 작업으로 작업 시간 증가 및 자원 소모, 부분적인 프로토타이핑으로 인한 중요한 작업 생략 가능성
6) 시나리오 문서 요건
- 이해성, 완전성, 일관성, 가독성, 수정 용이성, 추적 용이성(이완일 가수추)
7) 기타
- HCI: 사람과 컴퓨터의 상호작용을 연구
- UX: 사용자가 시스템이나 서비스를 이용하면서 느끼고 생각하는 경험(주관성, 정황성, 총체성)
- 감성공학: 1류, 인간 감성, 2류, 심리적 기능 , 3류; 공학적 및 수학적 모델 객관적
★품질 요구사항
1) 국제 제품 품질 표준
- ISO/IEC 9126, 12119, 14598, 25000(SQuaRE로 불리며 품질 관리,모델,측정,오구,평가(관모측요평))
2) ISO/IEC 9126★★
- 기능성, 신뢰성, 사용성, 효율성, 유지 보수성, 이식성(기신사 효유이)
3) ISO/IEC 14598
- 반복성, 재현성, 공정성, 객관성(반재공객)
4) 국제 프로세스 품질 표준: 9001, 12207(기조지), 15504(SPICE불수관 확예최), CMMI(성숙도, 능력도 평가)
★소프트웨어 아키텍처
1) 모듈화: 모듈 단위로 나눠 성능, 재사용성 향상(크기 크면 개발 비용이 크고, 크기 작으면 통합 비용이 큼)
2) 추상화: 전체적이고 포괄적인 개념 설계 후 차례로 세분화 하여 구체화(과정, 데이터, 제어 추상화)
3) 단계적 분해: 추상화 반복에 의해 세분화
4) 정보 은닉: 정보가 감추어져 다른 모듈이 접근하거나 변경하지 못하는 기법, 모듈 변경 시 영향을 받지 않아 수정, 시험, 유지보수 용이
★아키텍처 패턴
1) 레이어 패턴(계층으로 구분)
2) 클라이언트-서버 패턴
- 하나의 서버와 다수 클라이언트 컴포넌트로 구성되는 패턴
- 컴포넌트: 독립적인 업무 또는 기능을 수행하는 실행코드 기반으로 작성된 모듈
3) 파이프-필터 패턴★
- 데이터 스트림 절차 각 단계를 필터 컴포넌트로 캡슐화하여 파이프를 통해 데이터를 전송하는 패턴
- 필터 컴포넌트는 재사용성이 좋고 추가가 쉬워 확장 용이
- 필터 컴포넌트들을 재배치하여 다양한 파이프라인 구축 가능(UNIX의 쉘)
4) 모델-뷰-컨트롤러 패턴 ★★
- 서브 시스템을 3개의 부분으로 구조화하는 패턴
- 모델: 서브 시스템의 핵심 기능과 데이터 보관
- 뷰: 사용자에게 정보 표시
- 컨틀롤러: 입력 처리, 뷰 제어, UI 담당
- 서로 영향 받지 않고 개발 작업 수행
- 한 개의 모델에 대해 여러 개의 뷰를 만들 수 있으므로 대화형 애플리케이션에 적합
5) 마스터-슬레이브 패턴
- 마스터에서 슬레이브 컴포넌트로 분할 후 슬레이브 컴포넌트에서 처리된 결과물을 다시 돌려받는 방식
# 장애 허용 시스템, 병렬 컴퓨팅 시스템★
6) 브로커 패턴: 컴포넌트와 사용자를 연결해주는 패턴(분산 환경 시스템)
7) 피어-투-피어 패턴
- 피어를 하나의 컴포넌트로 간주하며 각 피어는 클라이언트 혹은 서버가 될 수 있는 패턴(멀티스레딩 방식 사용)
8) 이벤트-버스 패턴
- 소스가 이벤트 메시지 발행 시 리스너들이 메시지 받아 이벤트 처리 방식
- 이벤트 생성하는 소스, 리스너, 통로 채널, 채널 관리 버스(소리채버)
9) 블랙보드 패턴: 해결책이 명확하지 않은 문제 처리하는데 유용(음성인식, 차량식별, 신호해석★)
10) 인터프리터 패턴: 프로그램 코드 해석하는 컴포넌트를 설계할 때 사용됨
★★객체지향
1) 객체
- 독립적으로 식별 가능한 이름을 가짐
- 객체가 가질 수 있는 조건 상태는 일반적으로 시간에 따라 변함.
- 객체와 객체는 상호 연관성에 의한 관계가 형성됨. 메시지 집합은 행위. 객체는 행위의 특징을 나타냄
- 객체는 일정 기억장소를 가짐
2) 클래스★★
- 하나 이상의 유사한 객체들을 묶어서 하나의 공통된 특성을 표현한 것
- 공통된 속성과 연산을 갖는 객체의 집합
- 객체지향 프로그램에서 데이터를 추상화하는 단위★
- 객체들이 갖는 속성과 연산을 정의하고 있는 틀
3) 인스턴스
- 클래스에 속한 각각의 객체
- 새로운 객체를 생성하는 것을 인스턴스화
4) 메소드
- 객체를 사용하는 방법, 함수 연산
5) 메시지
- 행위하도록 지시하기 위한 방법
6) 캡슐화★
- 데이터와 데이터를 처리하는 함수를 하나로 묶는 것
- 은폐되어 외부 접근 제한.
- 외부 모듈 변경으로 인한 파급 효과가 적음
- 재사용 용이, 인터페이스 단순
- 결합도 다운, 응집도 업
7) 상속
- 상위 클래스 모든 속성과 연산을 하위 클래스가 물려받는 것
8) 다중 상속
- 한 클래스가 두개 이상의 상위 클래스로부터 속성과 연산을 상속받는 것
9) 다형성
- 하나의 메시지에 대해 각각의 객체가 가지고 있는 고유한 방법으로 응답할 수 있는 능력
★★결합도
(내공외제스자 Bad -> Good)★★
1) 내용 결합도: 직접 참조하거나 수정할 때의 결합도
2) 공통 결합도: 공유되는 공통 데이터 영역을 여러 모듈이 사용할 때의 결합도
3) 외부 결합도: 외부의 다른 모듈에서 참조할 때의 결합도(순차적)
4) 제어 결합도: 제어 신호를 이용하여 제어 요소를 전달하는 결합도
5) 스탬프 결합도: 자료구조가 전달될 때의 결합도
6) 자료 결합도: 매개변수나 인수로 데이터를 넘겨주고 받은 데이터에 대한 처리 결과를 다시 돌려주는 결합도
★★응집도
(우논시절통순기 Bad -> Good)★★
1) 우연적 응집도: 서로 관련 없는 요소로만
2) 논리적 응집도: 특정 형태로 분류
3) 시간적 응집도: 특정 시간에 처리
4) 절차적 응집도: 순차적으로 수행
5) 통신적 응집도: 동일한 입력과 출력 사용
6) 순차적 응집도: 출력데이터를 다음 활동의 입력 데이터로 사용
7) 기능적 응집도: 모든 기능 요소들이 단일 문제와 연관되어 수행될 경우의 응집도
★공통모듈
# 정명완일추
정확성, 명확성(기능 일관 이해, 명확), 완전성(필요한 모든 것 서술), 일관성(충돌), 추적성(관계 파악), 재사용(함수와 객체, 컴포넌트, 애플리케이션)
★★코드
(식분배간 표연암오)
- 식별, 분류, 배열, 간소화, 표준화, 연상, 암호화, 오류 검출
1) 순차코드★: 일정 기준 따라 차례로 일련번호 부여
2) 블록코드★: 공통성 있는 것끼리 블록으로 구분. 블록 내에서 일련 번호를 부여
3) 10진코드★: 10진 분할하는 방법을 반복
4) 그룹 분류 코드: 대분류, 중분류, 소분류 등으로 구분
5) 연상코드: 관계 있는 숫자, 문자, 기호 이용해 코드 부여
6) 표의 숫자 코드★(유효숫자코드): 물리적 수치를 그대로 코드에 적용
7) 합성 코드: 2개 이상의 코드를 조합하여 만드는 방법
8) 코드 부여 체계: 이름만으로 코드 부여. 유일한 코드 부여
★★디자인 패턴
- 아키택처 패턴이 디자인 패턴보다 상위 수준 설계에 사용
- 컴포넌트와 그 관계를 설계하기 위한 참조 모델
1) 생성 패턴★
- 추상팩토리(추상적으로 표현)
- 빌더(객체 생성 과정과 표현 방법 분리)
- 팩토리 메소드: 서브클래스가 결정하도록 하는 것
- 프로토타입: 원본 객체를 복제하는 방법
- 싱글톤: 하나의 객체를 여러 프로세스가 동시에 참조할 수 있음
2) 구조 패턴★
- 어댑터: 호환성이 없는 클래스 인터페이스를 이용할 수 있도록 변환해주는 패턴
- 브리지: 구현부에서 추상층을 분리하여 독립적 확장 및 다양성을 가지는 패턴
- 컴포지트: 복합, 단일 객체를 구분 없이 다룰 때 사용하는 패턴
- 데코레이터: 객체의 기능을 동적으로 확정
- 퍼싸드: 서브 클래스의 기능을 간편하게 사용할 수 있도록 하는 패턴
- 플라이웨이트: 공유해서 사용함으로써 메모리를 절약하는 패턴
- 프록시: 접근이 어려운 객체를 연결해주는 인터페이스 역할을 수행하는 패턴
(어브컴데 퍼플프)
3) 행위패턴
- 책임 연쇄, 커맨드, 인터프리터, 반복자, 중재자, 메멘토(되돌려), 옵서버, 상태, 전략, 템플릿 메소드, 방문자
-> 생성패턴과 구조 패턴에 해당안하면 행위 패턴
★ 인터페이스 요구사항 검증
1) 요구사항 검증
- 인터페이스 요구사항 검토 계획 수립, 검토 및 오류 수정, 베이스라인 설정
2) 요구사항 검증 방법★★
- 동료 검토: 작서앚가 내용 직접 설명 동료들이 들으며 결함 발견
- 워크 스루: 검토 회의 전 요구사항 명세서를 미리 배포하여 사전 검토. 짧은 검토 회의
- 인스펙션: 전문가들이 확인
(동워인)
3) 인터페이스 요구사항 검증 주요 항목
- 기능성, 완전성, 일관성, 명확성, 검증 가능성, 추적 가능성, 변경 용이성(기완일 명검추변)
★ 인터페이스
1) 인터페이스 식별: 인터페이스 목록을 작성
2) 인터페이스 시스템 식별: 송신시스템과 수신 시스템으로 구분하여 작성
3) 표준 항목
- 시스템 공통부: 연동 시 필요한 공통 정보
- 거래 공통부: 데이터 처리할 때 필요한 정보
★★ 인터페이스 방법 명세화
1) 시스템 연계 기술★★
- 직접 연계 방식(링컨에제하)
> DB 링크, DB 커넥션(커넥션 풀), API/Open API(인터페이스 프로그램), JDBC
- 간접 연계 방식(소웹버)
> 소켓(포트 할당 클라이언트 통신 요청 시 연결),
> 웹서비스(WSDL_Web Services Description Language, UDDI_XML기반 규격, SOAP_객체 간의 통신 규약),
> ESB(Enterprise Service Bus): 다양한 애플리케이션 간 연결과 상호작용 지원하는 미들웨어 플랫폼
2) 인터페이스 통신 유형
- 단방향(거래 요청만 하고 응답은 없음)
- 양방향
> 동기: 거래요청 후 대기
> 비동기: 요청 후 다른 작업 수행하다 응답이 오면 처리하는 방식
3) 인터페이스 처리 유형
- 실시간 방식(바로 처리), 지연 처리 방식(매건 처리 단위 비용이 많이 발생 시), 배치 방식(대량의 데이터 처리)
4) 인터페이스 발생 주기: 매일, 수시, 주1회 등
★★ 미들웨어 솔루션 명세
- 운영체제가 제공하는 서비스 이외에 추가적인 서비스를 제공하는 소프트웨어
1) DB: DB와 연결 위한 미들웨어 # ODBC, IDAPI, Glue
2) RPC(Remote Procedure Call원격 프로시저 호출): 원격 프로시저를 로컬 프로시저처럼 호출하는 방식
3) MOM(Message oriented Middleware)★: 메시지 기반의 비동기형 메시지를 전달하는 방식 미들웨어
4) TP-Monitor(Transaction Processing Monitor)★: 트랜잭션 업무. 사용자 수가 증가해도 빠른 응답 속도 유지 업무
5) Legacyware: 기존 애플리케이션에 새로운 업데이트된 기능을 덧붙이고자 할 때 사용되는 미들웨어
6) ORB(Object Request Broker객체 요청 브로커)★: 객체 지향 미들웨어로 코바 표준 스펙을 구현한 미들웨어,
- 코바: 네트워크에서 분산 프로그램 객체를 생성, 배포, 관리하기 위한 규격 의미
7) WAS★(Web Application Server)
- 동적인 콘텐츠를 처리하기 위해 사용되는 미들웨어
- 웹 환경을 구현하기 위한 미들웨어
- 웹 서버 기능 뿐만 아니라 기업 업무까지 컴포넌트 기반으로 구현 가능
플랫폼의 유형
- 싱글사이드 플랫폼: 소비자와 공급자 연결
- 투 사이드 플랫폼: 두 그룹 중개해서 모두에게 개방
- 멀티 사이드 플랫폼: 그룹을 연결하여 중개
- 플랫폼 성능 특성 분석 기법
> 사용자 인터뷰, 성능 테스트, 산출물 점검
★★OSI 7계층
- 응용 계층: 사용자와 네트워크(HTTP, FTP, TELNET, SMTP/SNTP, DNS)
- 표현 계층: 데이터 형식 설정, 코드 변환, 암/복호화(JPEG, MPEG)
- 세션 계층: 연결 접속 유지, 동기점(SSH, TLS)
- 전송 계층: 종단간 신뢰성 있고 데이터 전송, 데이터 분할(TCP/UDP, RTCP -> 세그먼트)
- 네트워크 계층: 경로 제공, (IP, ECMP, IGMP, RIP, OSPF -> 패킷)
- 데이터 링크 계층: 인접 시스템 간 동기화, 오류제어, 흐름제어, 오류검출 및 재전송 (HDLC, PPP, LLC, Ethernet -> 프레임)
- 물리 계층: 전기적, 기능적, 절차적 기능 정의(Bit)
케이스 도구의 분류(CASE)
- 상위 케이스: 다이어그램으로 표현. 계획 수립, 요구분석, 기본설계 단계
- 중위케이스: 화면 출력 작성 지원, 상세 설계 작업
- 하위 케이스: 시스템 명세서, 소스코드 생성 지원
소프트웨어 아키텍처
- 유스케이스뷰, 논리뷰, 프로세스뷰, 구현뷰, 배포뷰
★★럼바우의 객체 지향 분석, 객체 모델링 기법(OMT)
- 객체 모델링: 객체 다이어그램
- 동적 모델링: 상태도
- 기능 모델링: 자료 흐름도
★★자료흐름도(DFD: Data Flow Diagram)
- 프로세스: 자료를 변환시키는 시스템의 한 부분을 나타내며 처리, 기능, 변환, 버블이라고도 함
- 자료 흐름: 자료의 이동을 나타냄
- 자료 저장소(Data Store): 시스템에서의 자료 저장소를 나타냄
- 단말(Terminator): 시스템과 교신하는 외부 개체로, 입력 데이터가 만들어지고 출력 데이터를 받음
★★ 자료 사전 기호
= : 자료의 정의
+ : 자료의 연결
() : 자료의 생략
[|] : 자료의 선택
{} : 자료의 반복
* * : 자료의 설명
=> 객체 지향 기법에서 클래스들 사이의 부분-전체 또는 부분의 관계로 설명되는 연관성을 나타내는 용어는?
: 집단화 - 서로 관련 있는 여러 개의 객체를 묶어 한 개의 상위 개체를 만드는 것.
=> HIPO: 하향식 소프트웨어 개발을 위한 문서화 도구
=> 객체 지향 분석 방법론
- Coad와 Yourdon 방법★: E-R다이어그램을 사용하여 객체 행위를 모델링
- Booch: 미시적, 거시적 개발 프로세스 모두 사용
- Jacobson: 유스케이스(사용사례)를 가종
- Wirfs-Brocks: 분석과 설계 간의 구분 없음
UML 시퀀스 다이어그램의 구성 항목: (생실메): 생명선, 실행, 메시지
★객체지향 설계 원칙
SRP(단일책임 원칙): 소프트웨어의 설계 부품은 단 하나의 책임만 가져야 함
OCP(개방-폐쇄 원칙): 기존 코드를 변경하지 않고 기능 수정 또는 추가할 수 있도록 설계 필요
LSP(리스코프치환 원칙): 서브타입은 자신 기반 타입으로 교체할 수 있어야 함
ISP(인터페이스 분리 원칙): 자신이 사용하지 않는 인터페이스는 구현하지 않아야 함
DIP(의존 역전 원칙): 의존 관계를 맺을 때 변화하기 어려운 것에 의존해야 한다는 원책
-> SOLID ***면접 질문
디자인 패턴 구성요소
- 패턴 이름과 구분, 문제 및 배경, 솔루션, 사례, 결과, 샘플 코드
DBC(계약/협약에 의한 설계 Design by Contract): 책임을 문서화 초점, 가져야하는 기능만큼만, 문서화하고 검증
CASE 도구: 자동화, 자동화 기능, 커뮤니케이션
'정처기' 카테고리의 다른 글
| 정보처리기사 실기 정리 (0) | 2021.07.07 |
|---|---|
| 정보시스템 구축 관리 (0) | 2021.05.14 |
| 프로그래밍 언어 활용 (0) | 2021.05.09 |
| 소프트웨어 개발 (0) | 2021.05.08 |
| 데이터베이스 구축 (0) | 2021.05.07 |
