1. 개발 환경 구축
개발 환경 구축
•
응용 소프트웨어 개발을 위해 개발 프로젝트를 이해하고 소프트웨어 및 하드웨어 장비를 구축하는 것
•
개발 환경은 응용 소프트웨어가 운영될 환경과 유사한 구조로 구축한다.
•
분석 단계의 산출물을 바탕으로 개발에 필요한 하드웨어와 소프트웨어를 선정한다.
•
하드웨어와 소프트웨어의 성능, 편의성, 라이센스 등의 비즈니스 환경에 적합한 제품들을 최종적으로 결정하여 구축한다.
하드웨어 환경
•
사용자의 인터페이스 역할을 하는 클라이언트(Client), 그리고 클라이언트와 통신하여 서비스를 제공하는 서버(Server)로 구서오딘다.
•
클라이언트의 종류 : 개인 PC, 스마트폰 등
•
서버의 종류
◦
웹 서버
▪
클라이언트로부터 직접 요청을 받아 처리함
▪
저용량의 정적 파일들을 제공함
◦
웹 애플리케이션 서버 (WAS)
▪
동적 서비스를 제공하거나, 웹 서버와 데이터베이스 서버 또는 웹 서버와 파일 서버 사이에서 인터페이스 역할을 수행함
◦
데이터베이스 서버 (DB Server)
▪
데이터베이스와 이를 관리하는 DBMS를 운영함
◦
파일 서버
▪
데이터베이스에 저장하기에는 비효율적이거나, 서비스 제공을 목적으로 유지하는 파일들을 저장함
소프트웨어 환경
•
클라이언트 서버 운영을 위한 시스템 소프트웨어와 개발에 사용되는 개발 소프트웨어로 구성된다.
•
시스템 소프트웨어의 종류 : OS, 웹서버 및 WAS 운용을 위한 서버 프로그램, DBMS 등
•
개발 소프트웨어의 종류
웹 서버(Web Server)의 기능
HTTP/HTTPS 지원
•
브라우저로부터 요청을 받아 응답할 때 사용되는 프로토콜
통신 기록 (Communication Log)
•
처리한 요청들을 로그 파일로 기록하는 기능
정적 파일 관리 (Managing Static Files)
•
HTML, CSS, 이미지 등의 정적 파일들을 저장하고 관리하는 기능
대역폭 제한 (Bandwidth Throttling)
•
네트워크 트래픽의 포화를 방지하기 위해 응답 속도를 제한하는 기능
가상 호스팅 (Virtual Hosting)
•
하나의 서버로 여러 개의 도메인 이름을 연결하는 기능
인증 (Authentication)
•
사용자가 합법적인 사용자인지를 확인하는 기능
개발 언어의 선정 기준
2. 소프트웨어 아키텍쳐
소프트웨어 아키텍처
•
소프트웨어를 구성하는 요소들 간의 관계를 표현하는 시스템의 구조 또는 구조체
•
애플리케이션의 분할 방법과 분할된 모듈에 할당될 기능, 모듈 간의 인터페이스 등을 결정한다
•
소프트웨어 아키텍처 설계의 기본 원리는 모듈화, 추상화, 단계적 분해, 정보 은닉이 있다.
모듈화 (Modularity)
•
소프트웨어의 성능 향상, 시스템의 수정 및 재사용, 유지 관리 등이 용이하도록 시스템의 기능들을 모듈 단위로 나누는 것
•
모듈의 크기를 너무 작게 나누면, 개수가 많아져 모듈 간의 통합 비용이 많이 든다.
•
모듈의 크기를 너무 크게 나누면, 개수가 적어 통합 비용은 적게 들지만, 모듈 하나의 개발 비용이 많이 든다.
추상화 (Abstraction)
•
문제의 전체적이고 포괄적인 개념을 설계한 후, 차례로 세분화하여 구체화시켜 나가는 것
•
완전한 시스템을 구축하기 전에 그 시스템과 유사한 모델을 만들어서 여러가지 요인들을 테스트 할 수 있다.
•
추상화의 유형
◦
과정 추상화
◦
데이터 추상화
◦
제어 추상화
단계적 분해 (Stepwise Refinement)
•
문제를 상위의 중요 개념으로부터 하위의 개념으로 구체화시키는 분할 기법
•
Niklaus Wirth에 의해 제얀된 하샹식 설계 전략
•
소프트웨어의 포괄적인 기능에서부터 시작하여 점차적으로 구체화하고, 알고리즘, 자료구조 등 상세한 내역은 가능한 한 뒤로 미루어 진행한다.
정보 은닉 (Information Hiding)
•
한 모듈 내부에 포함된 절차와 자료들의 정보가 감추어져 다른 모듈이 접근하거나 변경하지 못하도록 하는 기법
•
정보 은닉을 통해 모듈을 독립적으로 수행할 수 있다.
•
하나의 모듈이 변경되더라도 다른 모듈에 영향을 주지 않으므로 수정, 시험, 유지보수가 용이하다.
상위 설계와 하위 설계
소프트웨어 아키텍처의 품질 속성
•
소프트웨어 아키텍처가 이해관계자들이 요구하는 수준의 품질을 유지 및 보장할 수 있게 설계되었는지 확인하기 위해 품질 평가 요소들을 구체화 시켜 놓은 것
•
품질 평가 요소의 종류
소프트웨어 아키텍처의 설계 과정
협약(Contract)에 의한 설계
•
컴포넌트를 설계할 때 클래스에 대한 여러 과정을 공유할 수 있도록 명세한 것
•
컴포넌트에 대한 정확한 인터페이스를 명세한다.
•
명세에 포함될 조건
3. 아키텍처 패턴
아키텍처 패턴 (Patterns)
•
아키텍처를 설계할 때 참조할 수 있는 전형적인 해결 방식 또는 예제
•
소프트웨어 시스템의 구조를 구성하기 위한 기본적인 윤곽을 제시한다.
•
아키텍처 패턴에는 서브 시스템들과 그 역할이 정의되어 있다.
•
서브 시스템 사이의 관계와 여러 규칙, 지침 등이 포함되어 있다.
•
주요 아키텍처 패턴의 종류
◦
레이어 패턴
◦
클라이언트-서버 패턴
◦
파이프-필터 패턴
◦
모델-뷰-컨트롤러 패턴
레이어 패턴 (Layers Pattern)
•
시스템을 계층으로 구분하여 구성하는 고전적인 방법의 패턴
•
상위 계층은 하위 계층에 대한 서비스 제공자가 되고, 하위 계층은 상위 계층의 클라이언트가 된다.
•
서로 마주보는 2개의 계층 사이에서만 상호작용이 이루어진다.
•
대표적으로 OSI 참조 모델이 있다.
클라이언트-서버 패턴 (Client-Server Pattern)
•
하나의 서버 컴포넌트와 다수의 클라이언트 컴포넌트로 구성되는 패턴
•
사용자 클라이언트를 통해 서버에 요청하면 클라이언트가 응답을 받아 사용자에게 제공하는 방식
파이프-필터 패턴 (Pipe-Filter Pattern)
•
데이터 스트림 절차의 각 단계를 필터로 캡슐화하여 파이프를 통해 전송하는 패턴
•
앞 시스템의 처리 결과물을 파이프를 통해 전달받아 처리한 후, 그 결과물을 다시 파이프를 통해 당므 시스템으로 넘겨주는 패턴을 반복한다.
•
데이터 변환, 버퍼링, 동기화 등에 주로 사용한다.
•
대표적으로 UNIX의 쉘(Shell)이 있다.
모델-뷰-컨트롤러 (Model-View-Controller Pattern)
•
서브 시스템을 모델, 뷰, 컨트롤러로 구조화하는 패턴
•
컨트롤러가 사용자의 요청을 받으면, 핵심 기능과 데이터를 보관하는 모델을 이용하여, 뷰에 정보를 출력하는 구조
•
여러 개의 뷰를 만들 수 있다.
•
한 개의 모델에 대해 여러 개의 뷰를 필요로 하는 대화형 애플리케이션에 적합하다.
기타 패턴
4. 객체지향 (Object-Oriented)
객체지향
•
소프트웨어의 각 요소들을 객체(Object)로 만든 후, 객체들을 조립해서 소프트웨어를 개발하는 기법
•
구조적 기법의 문제점으로 인한 소프트웨어 위기의 해결책으로 채택되어 사용되고 있다.
•
소프트웨어의 재사용 및 확장이 용이하여 고품질의 소프트웨어를 빠르게 개발할 수 있고, 유지보수가 쉽다.
•
객체지향의 구성요소
◦
객체 (Object)
◦
클래스 (Class)
◦
메시지 (Message)
•
객체지향의 특징
◦
캡슐화 (Encapsulation)
◦
상속 (Inheritance)
◦
다형성 (Polymorphism)
◦
연관성 (Relationship)
객체 (Object)
•
데이터와 이를 처리하기 위한 함수를 묶어 놓은 소프트웨어 모듈
•
데이터
◦
객체가 가지고 있는 정보로, 속성이나 상태, 분류 등
•
함수
◦
객체가 수행하는 기능으로 객체가 갖는 데이터를 처리하는 알고리즘
◦
객체의 상태를 참조하거나 변경하는 수단
클래스
•
공통된 속성과 연산을 갖는 객체의 집합
•
각각의 객체들이 갖는 속성과 연산을 정의하고 있는 툴
•
클래스에 속한 각각의 객체를 인스턴스(Instance)라고 한다.
메시지
•
객체들 간의 상호작용에 사용되는 수단으로, 객체의 동작이나 연산을 일으키는 외부의 요구사항
•
메시지를 받은 객체는 대응하는 연산을 수행하여 예상된 결과를 반환한다.
캡슐화 (Encapsulation)
•
외부에서 접근을 제한하기 위해 인터페이스를 제외한 세부 내용을 은닉하는 것
•
캡슐화된 객체는 외부 모듈의 변경으로 인한 파급 효과가 적다
•
객체들 간에 메시지를 주고 받을 때, 상대 객체의 세부 내용은 알 필요가 없으므로, 인터페이스가 단순해지고, 객체간의 결합도가 낮아진다.
상속 (Inheritance)
•
상위 클래스의 모든 속성과 연산을 하위 클래스가 물려받는 것
•
하위 클래스는 물려받은 속성과 연산을 다시 정의하지 않아도 즉시 자신의 속성으로 사용할 수 있다.
•
하위클래스는 상속받은 속성과 연산 외에 새로운 속성과 연산을 첨가하여 사용할 수 있다.
다형성 (Polymorphism)
•
하나의 메시지에 대해 각각의 객체가 가지고 있는 고유한 방법으로 응답할 수 있는 능력
•
객체들은 동일한 메소드명을 사용하며, 같은 의미의 응답을 한다.
•
ex) ‘+’ 연산자의 경우, 숫자 클래스에서는 덧셈, 문자 클래스에서는 문자열의 연결 기능으로 사용된다.
연관성 (Relationship)
•
두개 이상의 객체들이 상호 참조하는 관계
•
연관성의 종류
5. 객체 지향 분석 및 설계
객체 지향 분석 (OOA, Object Oriented Analysis)
•
사용자의 요구사항과 관련된 객체, 속성, 연산, 관계 등을 정의하여 모델링하는 작업
•
개발을 위한 업무를 객체와 속성, 클래스와 멤버, 전체와 부분 등으로 나누어서 분석한다.
•
클래스를 식별하는 것이 객체 지향 분석의 주요 목적이다.
객체 지향 분석의 방법론
Rumbaugh(럼바우) 방법
•
분석 활동을 객체 모델, 동적 모델, 기능 모델로 나누어 수행함
Booch(부치) 방법
•
미시적(Micro) 개발 프로세스와 거시적(Macro) 개발 프로세스를 모두 사용함
•
클래스와 객체들을 분석 및 식별하고 클래스의 속성과 연산을 정의함
Jacobson 방법
•
유스케이스를 강조하여 사용함
Coad와 Yourdon 방법
•
ER 다이어그램을 사용하여 객체의 행위를 모델링함
•
객체 식별, 구조 식별, 주제 정의, 속성과 인스턴스 연결 정의, 연산과 메시지 연결 정의 등의 과정으로 구성함
Wirfs-Brock 방법
•
분석과 설계 간의 구분이 없고, 고객 명세서를 평가해서 설계 작업까지 연속적으로 수행함
럼바우 (Rumbaugh) 분석 기법
•
모든 소프트웨어 구성요소를 그래픽 표기법을 이용하여 모델링하는 기법
•
객체 모델링 기법(OMT, Object-Modeling Technique)이라고도 한다.
•
분석 활동은 ‘객체 모델링 → 동적 모델링 → 기능 모델링’ 순으로 이루어진다.
객체 모델링 (Object Modeling)
•
정보 모델링이라고도 하며, 시스템에서 요구되는 객체를 찾아내어 속성과 연신 식별 및 객체들 간의 관계를 규정하여 객체 다이어그램으로 표시하는 것
동적 모델링 (Dynamic Modeling)
•
상태 다이어그램을 이용하여 시간의 흐름에 따른 객체들 간의 제어 흐름, 상호 작용, 동작 순서 등의 동적인 행위를 표현하는 모델링
기능 모델링 (Functional Modeling)
•
자료흐름도(DFD)를 이용하여 다수의 프로세스들 간의 자료 흐름을 중심으로 처리 과정을 표현한 모델링
객체 지향 설계 원칙
•
변경이나 확장에 유연한 시스템을 설계하기 위해 지켜야 할 원칙
•
SRP, OCP, LSP, ISP, DIP의 다섯가지 원칙의 앞 글자를 따 SOLID 원칙이라고 부른다.
단일 책임 원칙 (SRP)
•
객체는 단 하나의 책임만 가져야 한다는 원칙
개방-폐쇄 원칙 (OCP)
•
기존의 코드를 변경하지 않고, 기능을 추가할 수 있도록 설계해야 한다는 원칙
리스코프 치환 원칙 (LSP)
•
자식 클래스는 최소한 부모 클래스의 기능은 수행할 수 있어야 한다는 원칙
인터페이스 분리 원칙 (ISP)
•
자신이 사용하지 않는 인터페이스와 의존 관계를 맺거나 영향을 받지 않아야 한다는 원칙
의존 역전 원칙 (DIP)
•
의존 관계 성립 시, 추상성이 높은 클래스와 의존 관계를 맺어야 한다는 원칙
6. 모듈
모듈 (Module)
•
모듈화를 통해 분리된 시스템을 각 기능으로, 서브루틴, 서브 시스템, 소프트웨어 내의 프로그램, 작업 단위 등을 의미한다.
•
모듈의 기능적 독립성은 소프트웨어를 구성하는 각 모듈의 기능이 서로 독립적임을 의미한다.
•
모듈의 독립성은 결합도(Coupling)와 응집도(Cohesion)에 의해 측정된다.
모듈의 독립성
•
모듈의 독립성은 모듈이 다른 모듈과의 과도한 상호작용을 배제하고, 하나의 기능만을 수행함으로써 이루어진다.
•
독립성을 높이려면 모듈의 결합도는 약하게, 응집도는 강하게, 모듈의 크기는 작게 만들어야 한다.
결합도 (Coupling)
•
모듈 간에 상호 의존하는 정도 또는 두 모듈 사이의 연관 관계
•
결합도가 약할수록 품질이 높고, 강할수록 품질이 낮다.
자스제외공내
응집도 (Cohesion)
•
모듈의 내부 요소들이 서로 연관되어 있는 정도
•
응집도가 강할수록 품질이 높고, 약할수록 품질이 낮다.
기순교절시논우
팬인 / 팬아웃
•
팬인 : 어떤 모듈을 제어하는 모듈의 수
•
팬아웃 : 어떤 모듈에 의해 제어되는 모듈의 수
•
팬인이 높다는 것은 재사용 측면에서 설계가 잘 되어 있다고 볼 수 있다.
•
팬인이 높은 경우, 단일 장애점이 발생할 수 있으므로, 중점적인 관리 및 테스트가 필요하다.
N-S 차트
•
논리의 기술에 중점을 두고, 도형을 이용해 표현하는 방법
•
GOTO나 화살표를 사용하지 않는다.
•
연속, 선택 및 다중 선택, 반복의 3가지 제어 논리 구조로 표현한다.
•
조건이 복합되어 있는 곳의 처리를 시각적으로 명확히 식별하는 데 적합하다.
7. 단위 모듈
단위 모듈 (Unit Module)
•
소프트웨어 구현에 필요한 여러 동작 중, 한 가지 동작을 수행하는 기능을 모듈로 구현한 것
•
단위 모듈로 구현되는 하나의 기능을 단위 기능이라고 부른다.
•
독립적인 컴파일이 가능하며, 다른 모듈에 호출되거나 삽입되기도 한다.
•
단위 모듈의 구현 과정
IPC (Inter-Process Communication)
•
모듈 간 통신 방식을 구현하기 위해 사용되는 대표적인 프로그래밍 인터페이스 집합
•
복수의 프로세스를 수행하며 이뤄지는 프로세스 간 통신까지 규현이 가능하다.
•
IPC 대표 메소드 5가지
1.
Shared Memory
•
공유 가능한 메모리를 구성하여 다수의 프로세스가 통신하는 방식
2.
Socket
•
네트워크 소켓을 이용하여 네트워크를 경유하는 프로세스 간에 통신하는 방식
3.
Semaphores
•
공유 자원에 대한 접근 제어를 통해 통신하는 방식
4.
Pipes & Named Pipes
•
‘Pipe’ 라고 불리는 선입선출 형태로 구성된 메모리를 여러 프로세스가 공유하여 통신하는 방식
•
Pipe는 하나의 프로세스가 이용 중이라면 다른 프로세스는 접근할 수 없음
5.
Message Queueing
•
메시지가 발생하면 이를 전달하는 방식으로 통신하는 방식
단위 모듈 테스트
•
프로그램의 단위 기능으로 구현된 모듈이 정해진 기능을 정확히 수행하는지 검증하는 것
•
단위 테스트(Unit Test)라고도 불린다.
•
단위 모듈 테스트의 기준은 단위 모듈에 대한 코드이므로, 시스템 수준의 오류는 잡아낼 수 없다.
테스트 케이스
•
구현된 소프트웨어가 사용자의 요구사항을 정확하게 준수했는지를 확인하기 위한 테스트 항목에 대한 명세서
•
테스트 케이스를 이용하지 않은 테스트는 특정 요소에 대한 검증이 누락되거나 불필요한 검증의 반복으로 인해 인력과 시간을 낭비할 수 있다.
•
ISO/IEC/IEEE 29119-3 표준에 따른 테스트 케이스의 구성요소
8. 공통 모듈
공통 모듈
•
여러 프로그램에서 공통으로 사용할 수 있는 모듈
•
자주 사용되는 계산식이나 매번 필요한 사용자 인증과 같은 기능들이 공통 모듈로 구성될 수 있다.
•
공통 모듈을 구현할 때는 해당 기능을 명확히 이해할 수 있도록 명세 기법을 준수해야 한다.
재사용 (Reuse)
•
이미 개발된 기능들을 새로운 시스템이나 기능 개발에 사용하기 적합하도록 최적화하는 작업
•
새로 개발하는데 필요한 비용과 시간을 절약할 수 있다.
•
누구나 이해할 수 있고, 사용이 가능하도록 사용법을 공개해야 한다.
•
재사용 규모에 따른 분류
효과적인 모듈 설계 방안
•
결합도는 줄이고, 응집도는 높여서 모듈의 독립성과 재사용을 높인다.
•
복잡도와 중복성을 줄이고, 일관성을 유지시킨다.
•
모듈의 기능은 예측이 가능해야 하며, 지나치게 제한적이어서는 안된다.
•
모듈 크기는 시스템의 전반적인 기능과 구조를 이해하기 쉬운 크기로 분해한다.
•
효과적인 제어를 위해 모듈 간의 계층적 관계를 정의하는 자료가 제시되어야 한다.