개발 환경 구축
- 개발 프로젝트를 이해하고 소프트웨어 및 하드웨어 장비를 구축하는 것
하드웨어 환경
- 클라이언트, 서버로 구성
- 클라이언트 종류 : 개인용 PC , 스마트폰 등
- 서버 종류 : 웹 서버, WAS, DB Server , File Server
소프트웨어 환경
- 시스템 소프트웨어와 개발 소프트웨어로 구성
- 시스템 소프트웨어 종류 : 운영체제, 웹 서버 및 WAS 운용을 위한 서버 프로그램 , DBMS 등
- 개발 소프트웨어 : 요구사항 관리 도구, 설계/모델링 도구, 빌드 도구, 테스트 도구, 형상 관리 도구 등
웹 서버(Web Server)의 기능
- HTTP/HTTPS 지원 : 브라우저로부터 요청을 받아 응답할 때 사용되는 프로토콜
- 통신 기록 : 처리한 요청들을 로그 파일로 기록하는 기능
- 정적 파일 관리 : HTML,CSS 이미지 등의 정적 파일들을 저장하고 관리하는 기능
- 대역폭 제한 : 네트워크 트래픽 포화 방지를 위한 응답 속도를 제한하는 기능
- 가상 호스팅 : 하나의 서버로 여러 개의 도메인 이름을 연결하는 기능
- 인증 : 사용자가 합법적인 사용자인지를 확인하는 기능
--> H통대정인가 ... (억지로라도 외워....)
개발 언어의 선정 기준
| 적절성 | 개발하려는 소프트웨어 목적에 적합해야 함 |
| 효율성 | 코드의 작성 및 구현이 효율적이어야 함 |
| 이식성 | 다양한 시스템 및 환경에 적용이 가능해야 함 |
| 친밀성 | 개발 언어에 대한 개발자들의 이해도와 활용도가 높아야 함 |
| 범용성 | 다른 개발 사례가 존재하고 여러 분야에서 활용되고 있어야 함 |
--> 이적친효범
소프트웨어 아키텍처
- 소프트웨어를 구성하는 요소들간의 관계를 표현하는 시스템의 구조 또는 구조체
모듈화
- 시스템의 기능들을 모듈 단위로 나누는 것
- 결합도의 최소화와 응집도의 최대화를 목표로
추상화
- 전체적이고 포괄적인 개념을 설계한 후 구체화 시켜 나가는 것
| 과정 추상화 | 자세한 수행 과정 정의 X, 전반적인 흐름만 파악할 수 있게 |
| 자료 추상화 | 데이터 세부적인 속성 용도 정의 X, 대표할 수 있는 표현으로 대체 |
| 제어 추상화 | 이벤트 발생의 정확한 절차나 방법을 정의 X , 대표할 수 있는 표현으로 대체 |
단계적 분해
- 상위의 중요 개념으로부터 하위의 개념으로 구체화시키는 분할 기법
- Niklaus Wirth에 의해 제안된 하향식 설계 전략
정보 은닉
- 한 모듈 내부에 포함된 절차와 자료들의 정보가 감추어져 다른 모듈이 접근하거나 변경하지 못하도록 하는 기법
- 모듈의 독립적 수행
- 수정, 시험, 유지보수가 용이
상위 설계와 하위 설계
| 상위 설계 | 하위 설계 | |
| 별칭 | 아키텍처 셜계, 예비 설계 | 모듈 설계, 상세 설계 |
| 설계 대상 | 시스템의 전반적인 구조 | 시스템의 내부 구조 및 행위 |
| 세부 목록 | 구조, DB, 인터페이스 | 컴포넌트, 자료 구조, 알고리즘 |
소프트웨어 아키텍처의 품질 속성
| 시스템 측면 | 성능, 보안, 가용성, 기능성, 사용성, 변경 용이성, 확장성 |
| 비즈니스 측면 | 시장 적시성, 비용과 혜택, 예상 시스템 수명, 목표 시장, 공개 일정 |
| 아키텍처 측면 | 개념적 무결성, 정확성, 완결성, 구축 가능성, 변경성, 시험성 |
협약에 의한 설계
- 클래스에 대한 여러 가정을 공유할 수 있도록 명세한 것
| 선행 조건 | 오퍼레이션이 호출되기 전 참이 되어야 할 조건 |
| 결과 조건 | 수행 된 후 만족되어야 할 조건 |
| 불변 조건 | 실행되는 동안 항상 만족해야 할 조건 |
아키텍처 패턴
- 아키텍처 설계할 때 참조할 수 있는 전형적인 해결 방식 또는 예제
- 레이어 패턴, 클라이언트-서버 패턴, 파이프-필터 패턴, 모델-뷰-컨트롤러 패턴 (모레클파)
레이어 패턴
- 시스템을 계층으로 구분하여 구성하는 패턴
- 하위는 상위에 대한 서비스 제공자, 상위는 하위의 클라이언트
- OSI 참조 모델
클라이언트-서버 패턴
- 하나의 서버 컴포넌트와 다수의 클라이언트 컴포넌트로 구성되는 패턴
파이프-필터 패턴
- 데이터 스트림 절차의 각 단계를 필터로 캡슐화하여 파이프를 통해 전송하는 패턴
- UNIX의 쉘
모델-뷰-컨트롤러 패턴
- 서브시스템을 모델, 뷰, 컨트롤러의 구조화하는 패턴
기타 패턴
| 마스터-슬레이브 | - 슬레이브 컴포넌트에서 처리된 결과물을 다시 돌려받는 방식으로 작업 수행하는 패턴 - ex) 병렬 컴퓨팅 스시템 |
| 브로커 패턴 | - 요청에 맞는 컴포넌트와 사용자를 연결해주는 패턴 - ex) 분산 환경 시스템 |
| 피어-투-피어 패턴 | - 하나의 컴포넌트가 클라이언트가 될수도, 서버가 될 수도 있는 패턴 - ex) 파일 공유 네트워크 |
| 이벤트 - 버스 패턴 | - 특정 채널에 이벤트 메시지 발행하면 구독한 리스너들이 메시지 받아 처리하는 패턴 - ex) 알림 서비스 |
| 블랙 보드 패턴 | - 모든 컴포넌트들이 공유 데이터 저장소와 블랙보드 컴포넌트에 접근 가능한 패턴 - ex) 음성 인식, 차량 식별, 신호 해석 |
| 인터프리터 패턴 | - 프로그램 코드의 각 라인을 수행하는 방법 지정, 기호마다 클래스 갖도록 구성된 패턴 - ex) 번역기, 컴파일러, 인터프리터 |
객체 지향
- 소프트웨어 각 요소들을 객체로 만든 후 객체들을 조립해서 소프트웨어를 개발하는 기법
- 구성 요소 : 객체 , 클래스, 메시지
- 특징 : 캡슐화, 상속, 다형성, 연관성
객체
- 데이터와 이를 처리하기 위한 함수를 묶어 놓은 소프트웨어 모듈
- 데이터 : 객체가 가지고 있는 정보, 속성이나 상태 , 분류 등
- 함수 : 객체가 수행하는 기능으로 객체가 갖는 데이터 처리 알고리즘, 객체 상태 참조하거나 변경 수단
클래스
- 공통된 속성과 연산을 갖는 객체의 집합
- 클래스에 속한 객체를 인스턴스라고 한다.
메시지
- 객체의 동작이나 연산을 일으키는 외부의 요구 사항
캡슐화
- 외부에서 접근을 제한하기 위해 인터페이스를 제외한 세부 내용을 은닉하는 것
- 변경으로 인한 파급효과 적음
- 인터페이스 단순해지고, 결합도가 낮아짐
상속
- 상위 클래스의 모든 속성과 연산을 하위 클래스가 물려받는 것
다형성
- 각각의 객체가 가지고 있는 고유한 방법으로 응답할 수 있는 능력
- 동일한 메소드 명을 사용하며 , 같은 의미의 응답을 한다.
연관성
- 두 개 이상의 객체들이 상호 참조하는 관계
| 종류 | 의미 | 특징 |
| is member of | 연관화 (Association) | 2개 이상의 객체가 상호 관련 |
| is instance of | 분류화 (Classification) | 동일한 형의 특성을 갖는 객체들을 모아 구성하는 것 |
| is part of | 집단화 (Aggregation) | 관련 있는 객체들을 묶어 하나의 상위 객체를 구성하는 것 |
| is a | 일반화 (Generalization) 특수화 (Specialization) |
- 공통적인 성질들로 추상화한 상위 객체 구성 - 상위 객체를 구체화 하여 하위 객체를 구성 |
객체지향 분석
- 객체지향 분석(OOA) 는 객체, 속성, 연산, 관계등을 정의하여 모델링하는 작업
- 객체와 속성, 클래스와 멤버, 전체와 부분등으로 나누어 분석
객체지향 분석의 방법론
| Rumbaugh (럼바우) | 분석 활동을 객체 모델, 동적 모델, 기능 모델로 나누어 수행 |
| Booch(부치) | 미시적, 거시적 개발 프로세스 모두 사용 |
| Jacobson | 유스케이스 (UseCase) |
| Coad 와 Yourdan | E-R 다이어그램 |
| Wirfs-Brock | 고객 명세서를 평가해 설계 작업까지 연속적으로 수행 |
럼바우 분석 기법
- 모든 소프트웨어 구성 요소를 그래픽 표기법으로 이용하여 모델링하는 기법
- 객체 모델링 기법 (OMT) 라고도 함
- 분석활동은 객체 모델링 -> 동적 모델링 -> 기능 모델링
- 객체 모델링 (Object) : 정보(Information) 모델링이라고도 함, 객체 다이어그램으로 표시하는 모델링
- 동적 모델링 (Dynamic) : 시간 흐름에 따른 객체 간 흐름 제어, 상호 작용, 동작 순서 등 동적 행위 표현하는 모델링
- 기능 모델링 (Functional) : 자료 흐름도 (DFD)를 이용해 프로세스들 간 자료 흐름 중심으로 처리 과정 표현한 모델링
객체지향 설계 원칙 (SOLID)
| 단일-책임 원칙(SRP) | 객체는 단 하나의 책임만 |
| 개방-폐쇄 원칙(OCP) | 기존 코드 변경 없이 기능 추가할 수 있도록 설계해야 함 |
| 리스코프 치환 원칙 (LSP) | 자식 클래스는 최소 부모 클래스의 기능은 수행할 수 있어야 함 |
| 인터페이스 분리 원칙 (ISP) | 사용하지 않는 인터페이스와 의존 관계 X |
| 의존 역전 원칙 (DIP) | 의존 관계 성립 시 추상성 높은 클래스와 의존 관계 맺어야 함 |
모듈
- 모듈화를 통해 분리된 시스템의 기능
- 명령어들의 집합, 독립적인 기능을 가짐
- 독립성 = 결합도(Coupling)와 응집도 (Cohesion)에 의해 측정
결합도 (Coupling)
- 모듈 간 상호 의존하는 정도
- 약할수록 품질이 좋고 ,강할수록 품질이 낮음
- 내용 , 공통, 외부, 제어, 스탬프, 자료 결합도 (내공외제스자 - 결합도 강 -> 약 순)
| 내용 결합도 | 한 모듈이 다른 모듈의 내부 자료를 직접 참조하거나 수정할 때 결합도 |
| 공통 결합도 | 공통 데이터 영역을 여러 모듈이 사용할 때 결합도 |
| 외부 결합도 | 외부의 다른 모듈에서 참조할 때 결합도 |
| 제어 결합도 | 논리적인 흐름을 제어하기 위해 제어 신호나 제어 요소를 전달하는 결합도 |
| 스탬프 결합도 | 배열이나 레코드 등의 자료 구조가 전달될 때 결합도 |
| 자료 결합도 | 자료 요소로만 구성될 때 결합도 |
응집도 (Cohesion)
- 모듈의 내부 요소들이 서로 관련되어 있는 정도
- 응집도 강할수록 품질 높고, 약할수록 낮음
- 기능적, 순차적, 교환적, 절차적, 시간적, 논리적, 우연적 응집도 (기순교절시논우)
| 기능적 응집도(Functional) | 모든 기능 요소들이 단일 문제와 연관되어 수행될 때 경우 응집도 |
| 순차적 응집도(Sequential) | 하나의 활동으로부터 나온 출력 데이터를 다음 활동의 입력 데이터로 사용 |
| 교환적 응집도(Communication) | 동일한 입력과 출력 사용하여 서로 다른 기능을 수행하는 구성 요소들이 모였을 때 응집도 |
| 절차적 응집도(Procedural) | 다수의 관련 기능을 가질 때 모듈 안의 구성 요소들이 기능을 순차적으로 수행할 경우 응집도 |
| 시간적 응집도(Temporal) | 특정 시간에 처리되는 몇 개의 기능을 모아 하나의 모듈로 작성할 경우 응집도 |
| 논리적 응집도(Logical) | 유사한 성격, 특정 형태로 분류되는 처리 요소들로 하나의 모듈이 형성되는 경우 응집도 |
| 우연적 응집도(Coincidental) | 모듈 내부 요소들이 서로 관련 없는 요소로만 구성된 응집도 |
팬인 / 팬 아웃
- 팬 인 : 어떤 모듈을 제어하는 모듈의 수 (들어오는 화살표)
- 팬 아웃 : 어떤 모듈에 의해 제어되는 모듈 (나가는 화살표)
A: 들어오는게 없음 (팬 인 : 0개) , 나가는 선 B,C 두개 (팬 아웃 : 2개)
N-S 차트
- 논리의 기술에 중점을 두고 도형을 이용해 표현하는 방법
- GOTO나 화살표 사용 X
- 연속 , 선택 및 다중 선택, 반복의 3가지 제어 논리 구조로 표현
단위 모듈
- 한 가지 동작을 수행하는 기능을 모듈로 구현한 것
- 단위 기능이라고 부름, 독립적 컴파일 가능
- 구현 과정 : 명세서 작성 -> 입출력 기능 구현 -> 알고리즘 구현
IPC
- 모듈 간 통신 방식을 구현하기 위해 사용되는 대표적인 프로그래밍 인터페이스 집합
- 대표 메소드 : 공유 메모리 , 소켓 , 세마포어, 파이프와 네임드 파이프, 메시지 큐잉
테스트 케이스
- 소프트웨어가 요구사항을 정확하게 준수했는지 확인하기 위한 테스트 항목에 대한 명세서
| 구성 요소 | 내용 |
| 출력 명세 | 테스트 케이스 수행 시 예상되는 출력 결과 |
| 입력 명세 | 테스트 데이터 또는 테스트 조건 |
| 의존성 기술 | 테스트 케이스 간의 의존성 |
| 특수 절차 요구 | 테스트 케이스 수행 시 특별히 요구되는 절차 |
| 식별자 | 항목 식별자, 일련번호 |
| 환경 설정 | 필요한 하드웨어나 소프트웨어 환경 |
| 테스트 항목 | 테스트 대상(모듈 또는 기능) |
공통 모듈 명세 기법 종류
- 공통 모듈은 여러 프로그램에서 공통으로 사용할 수 있는 모듈
- 정확성 (Correctioness) : 해당 기능이 필요하다는 것을 알 수 있도록 정확히 작성
- 명확성 (Clarity) : 중의적으로 해석되지 않도록 명확하게 작성
- 완전성(Completeness) : 구현에 필요한 모든 것을 기술
- 일관성(Consistency) : 공통 기능들 간 상호 충돌이 발생하지 않도록 작성
- 추적성(Traceability) : 기능에 대한 요구사항 출처, 관련 시스템 등 관계 파악할 수 있도록 작성
--> 일정명완추
재사용
- 이미 개발된 기능들을 새로운 시스템이나 기능 개발에 사용하기 적합하도록 최적화하는 작업
- 재사용 규모에 따른 분류
- 1) 함수와 객체 : 클래스나 메소드 단위 소스코드 재사용
- 2) 컴포넌트 : 컴포넌트 자체 수정 없이 인터페이스 통해 통신하는 방식 재사용
- 3) 애플리케이션 : 공통 기능을 제공하는 애플리케이션을 공유하는 방식으로 재사용
코드의 주요 기능
- 자료의 분류 조합 집계 추출을 용이하게 하기 위해 사용하는 기호
- 주요 기능
- 식별 기능 : 데이터 간 성격에 따라 구분 가능
- 분류 기능 : 특정 기준이나 동일한 유형에 해당하는 데이터를 그룹화
- 배열 기능 : 의미를 부여하여 나열 가능
- 표준화 기능 : 데이터를 기준에 맞추어 표현 가능
- 간소화 기능 : 복잡한 데이터를 간소화 가능
--> 분배간 표식
코드의 종류
- 순차 코드 : 최초 자료부터 차례로 일련번호 부여
- 블록 코드 : 공통성 있는것 블록으로 구분하고 블록 내에서 일련번호 부여
- 10진 코드(Decimal) : 0~9까지 10진 분할, 다시 그 각각에 대해 10진분할하는 방법
- 그룹 분류 코드 : 대분류 , 중분류, 소분류 등으로 구분하고 그룹 안에서 일련번호 부여
- 표의 숫자 코드(Significant Digit Code) : 성질, 길이, 넓이, 부피 ,지름 ,높이 등 물리적 수치를 코드에 적용시키는 방법 (유효 숫자 코드)
- 연상 코드(Mnemonic Code) : 명칭이나 약호와 관계있는 숫자나 문자 기호를 이용해 코드 부여하는 방법
- 합성 코드(Combined) : 2개 이상의 코드를 조합하여 만드는 방법
디자인 패턴
- 모듈 간 관계 및 인터페이스를 설계할 때 참조할 수 있는 전형적인 해결 방식 또는 예제
- 생성, 구조, 행위 패턴으로 구분
생성 패턴
| 추상 팩토리 (Abstract) | 구체 클래스 의존 X , 추상적으로 표현하는 패턴 |
| 빌더 (Builder) | 건축하듯 조합하여 객체를 생성하는 패턴 |
| 팩토리 메소드 (Factory Method) | 객체 생성을 서브 클래스에서 처리하도록 분리하여 캡슐화한 패턴 (= 가상 생성자 패턴) |
| 프로토타입 (Prototype) | 원본 객체 복제 방법, 객체를 생성하는 패턴 |
| 싱글톤 (Singleton) | 하나 객체 생성, 어디서든 참조가 가능하지만 여러 프로세스 동시에 참조 불가 |
--> 추빌 팩프싱
구조 패턴
| 어댑터(Adapter) | 호환성 없는 클래스들 이용할 수 있게 변환해주는 패턴 |
| 브리지(Bridge) | 구현부에서 추상층 분리하는 패턴 |
| 컴포지트(Composite) | 복합 객체와 단일 객체를 구분 없이 다루고자 할 때 사용하는 패턴 |
| 데코레이터 (Decorator) | 객체 간 결합을 통해 능동적으로 기능들을 확장할 수 있는 패턴 |
| 퍼싸드(Facade) | 서브 클래스들은 더 상위에 인터페이스를 구성, 서브 클래스들의 기능을 간편하게 사용할 수 있게 |
| 플라이웨이트(Flyweight) | 인스턴스 매번 생성 X , 가능한 한 공유해서 사용하여 메모리를 절약하는 패턴 |
| 프록시(Froxy) | 접근 어려운 객체와 연결하려는 객체 사이 인터페이스 역할을 수행하는 패턴 |
--> 퍼플 데브컴어프
행위 패턴
| 방문자 (Visitor) | 처리 기능을 분리하여 별도 클래스를 구성하는 패턴 |
| 템플릿 메소드 (Template Method) | 상위 클래스 골격 정의, 하위 클래스 세부 처리하는 패턴 |
| 전략(Strategy) | 동일 계열 알고리즘 개별 캡슐화하여 상호 교환할 수 있게 정의하는 패턴 |
| 상태(State) | 객체 상태에 따라 동일한 동작을 다르게 처리해야할 때 사용하는 패턴 |
| 옵서버(Observer) | 상태가 변화하면 객체에 상속되어 있는 다른 객체들에게 변화된 상태를 전달하는 패턴 |
| 중재자(Mediator) | 복잡한 상호작용을 캡슐화하여 객체로 정의하는 패턴 |
| 메멘토(Memento) | 객체 내부 상태를 객체화, 이후 요청에 따라 해당 시점으로 돌릴 수 있는 기능을 제공 |
| 인터프리터(Interpreter) | 언어에 문법 표현 정의하는 패턴, SQL이나 프로토콜 개발시 사용 |
| 책임 연쇄(Chain of Responsibility) | 한 객체가 처리하지 못하면 다음 객체로 넘어가는 패턴 |
| 커맨드 (Command) | 정보를 저장하거나 로그에 남기는 패턴 |
--> 방템전 상태옵중 메인책커
서버 개발 프레임워크
- 다양한 네트워크 설정, 요청 및 응답 처리, 아키텍처 모델 구현등을 손쉽게 처리할 수 있도록 클래스나 인터페이스를 제공하는 소프트웨어
- MVC 패턴 기반 개발
- Spring, Node.js , Django, Codeigniter , Ruby on Rails
서버 개발 프레임워크 종류
- Spring : Java 기반 , 전자정부 표준 프레임워크
- Node.js : JavaScript 기반 , 비동기 입출력 처리와 이벤트 위주
- Django : Python 기반, 컴포넌트 재사용 강조
- Codeigniter : PHP 기반, 서버 자원 적게 사용
- Ruby on Rails : Ruby 기반, 테스트를 위한 웹 서버를 지원
서버 개발 과정
- DTO/VO 구현 : 데이터 교환을 위해 사용할 객체 만드는 과정
- SQL 구현 :데이터 작업 수행할 SQL 문 생성 과정
- DAO 구현 : DB접근, SQL활용하여 데이터를 실제 조작하는 코드 구현 과정
- Service 구현 : 사용자 요청에 응답하기 위한 로직 구현 과정
- Controller 구현 : 요청에 따른 적절한 서비스를 호출하여 결과를 사용자에게 반환하는 과정 구현
API
- 라이브러리를 이용할 수 있도록 규칙 등을 정의해 놓은 인터페이스
- 효율적인 개발이 가능함
배치 프로그램
- 여러 작업들을 미리 정해진 일련의 순서에 따라 일괄적으로 처리하도록 만든 프로그램
- 필수 요소
| 대용량 데이터 | 대량 데이터 가져오거나, 전달, 계산하는 등 처리가 가능해야함 |
| 자동화 | 심각한 오류 상황 제외하고 사용자 개입없이 수행 |
| 견고성 | 데이터 중복 등으로 중단되는 상황 없어야 함 |
| 안정성/신뢰성 | 오류 발생하면 추적이 가능해야함 |
| 성능 | 다른 프로그램 수행 방해 X , 지정된 시간 내 처리 완료되야함 |
배치 스케줄러
- 일괄처리 작업이 설정된 주기에 맞춰 자동으로 수행되도록 지원해주는 도구
- 스프링 배치 : 로그 관리, 추적 ,트랜잭션 관리, 작업 재시작 등 다양한 기능 지원 (Spring Source 사 개발)
- Quartz : 스프링 프레임워크로 개발되는 응용 프로그램들의 일괄 처리를 위한 다양한 기능 제공 라이브러리
- Cron : 리눅스의 기본 스케줄러 도구 , crontab 명령어를 통해 작업을 예약
Crontab 명령어 작성
[분][시][일][월][요일][명령어]
ex) ***** / root / com_1.sh
--> 매월 매일 매시 매분마다 com_1.sh를 실행한다.
ex) 30 */3 *** /root /com_1.sh
--> 매월 매일 0:30분 부터 3시간 마다 com_1.sh 실행
ex) * 18-23 20 * * / root / com_1.sh
--> 매월 20일 18~23시 사이에 매분마다 com_1.sh 실행
