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

소프트웨어 생명 주기

• 폭포수 모형
• 프로토타입 모형
• 나선형 모형
• 애자일 모형

 

폭포수 모형

• 전통적인 소프트웨어 생명 주기 모형, 고전적 생명 주기 모형
• 개발 과정의 한 단계가 끝나야만 다음 단계로 넘어갈 수 있는 선형 순차적 모형
• 모형을 적용한 경험과 성공 사례 다수
• 매뉴얼을 작성해야 한다.
• 각 단계가 끝난 후 다음 단계를 수행하기 위한 결과물이 명확하게 산출되어야 한다.
• 두 개 이상의 과정이 병행하여 수행되지 않는다.
• 타당성 검토 -> 계획 -> 요구 분석 -> 설계 -> 구현(코딩) -> 시험(검사) -> 유지보수

 

프로토타입 모형

• 사용자의 요구사항을 정확히 파악하기 위해 실제 개발될 소프트웨어에 대한 견본(시제)품(Prototype)을 만들어 최종 결과물을 예측하는 모형
• 시제품은 의뢰자나 개발자 모두에게 공동의 참조모델
• 새로운 요구사항이 도출될 때마다 이를 반영한 프로토타입을 새롭게만든다
• 단기간 제작을 목적으로, 비효율적인 언어나 알고리즘 사용할 수 있다.
• 개발 과정에서 새롭게 도출된 요구사항을 반영할 수 있다.

 

나선형 모형 (Spiral Model, 점진적 모형)

• 보헴(Boehm)이 제안한 모형.
• 폭포수와 프로토타입의 장점에 위험 분석 기능을 추가한 모형
• 나선을 따라 돌듯이 여러 번의 소프트웨어 개발 과정을 거쳐 점진적으로 완벽한 최종 소프트웨어를 개발
• 개발하면서 발생할 수 있는 위험을 관리하고 최소화하는 목적
• 핵심 기술에 문제가 있거나 사용자의 요구사항이 이해하기 어려운 경우 적합
• 계획 -> 분석 -> 개발 -> 평가를 계속 반복

 

애자일 모형 (Agile Model)

• 고객의 요구사항에 유연하게 대응
• 주기마다 생성되는 결과물에 고객의 평가와 요구를 적극 수용
• 애자일 기반 소프트웨어 개발 모형 : 스크럼, XP(eXtreme Programming), 칸반, Lean, 크리스탈, ASD(Adaptive Software Development), 기능 중심 개발(FDD; Feature Driven Development), DSDM(Dynamic System Development Method), DAD(Disciplined Agile Delivery) 등 있다.

애자일 개발 4가지 핵심 가치

• 프로세스와 도구보다는 개인과 상호작용에 더 가치를 둔다.
• 방대한 문서보다는 실행되는 SW에 더 가치를 둔다.
• 계약 협상보다는 고객과 협업에 더 가치를 둔다.
• 계획을 따르기보다는 변화에 반응하는 것에 더 가치를 둔다.

 

익스트림 프로그래밍 (XP; eXtreme Programming)

• 소규모 개발 조직이 불확실하고 변경이 많은 요구를 접하였을 때 적절한 방법
• 익스트림 프로그래밍을 구동시키는 원리는 상식적인 원리와 경험을 최대한 끌어올리는 것
• 구체적인 실천방법을 정의하고 있으며, 개발 문서보다는 소스코드에 중점을 둔다.
• XP의 5가지 핵심 가치
  • 의사소통, 단순성, 용기, 존중, 피드백

 

• 구조적 방법론이 아닌 애자일 방법론 중 하나이다.

 

스크럼 (Scrum)

• 에자일 기법 중 하나
• 스크럼 마스터 (Scrum Master)는 스크럼 프로세스를 따르고, 팀이 스크럼을 효과적으로 활용할 수 있도록 보장하는 역할 등을 맡는다.
• 제품 백로그 (Product Backlog)는 스크럼 팀이 해결해야 하는 목록으로 소프트웨어 요구사항, 아키텍처 정의 등이 포함된다.
• 속도 (Velocity)는 한 번의 스프린트에서 한 팀이 어느 정도의 제품 백로그를 감당할 수 있는지에 대한 추정치로 볼 수 있다.
• 개발 과정 진행 순서
  • 스프린트 계획 회의 -> 스프린트 -> 일일 스크럼 회의 -> 스프린트 검토 회의 -> 스프린트 회고

 

스프린트 (Sprint)

• 실제 개발을 2~4주간 진행하는 과정
• 스프린트 백로그에 작성된 Task를 대상으로 작업 시간을 측정한 후 담당개발자에게 할당한다.
• Task는 할 일, 진행 중, 완료의 상태로 구성된다.

 

유스케이스 (Use Case)의 구성요소

• 연관 : 유스케이스와 액터 간의 상호작용이 있음을 표현한다.
• 포함 : 하나의 유스케이스가 다른 유스케이스의 실행을 전제로 할 때 형성되는 관계
• 확장 : 확장 기능 유스케이스와 확장 대상 유스케이스 사이에 형성되는 관계
• 일반화 : 유사한 유스케이스 또는 액터를 모아 추상화한 유스케이스 또는 액터와 연결시켜 그룹을 만들어 이해도를 높이기 위한 관계.

 

요구사항 분석

기능적 요구사항 vs 비기능적 요구사항

• 기능적 요구사항: 시스템이 실제로 어떻게 동작하는지에 관점을 둔 요구사항
• 비기능적 요구사항: 시스템 구축에 대한 성능, 보안, 품질, 안정 등에 대한 성능, 보안, 품질, 안정성 등으로 실제 수행에 보조적인 요구사항
• 요구사항 개발 프로세스
  • 도출 -> 분석 -> 명세 -> 확인 (도분명확)

 

• 사용자 요구의 타당성을 조사하고 비용과 일정에 대한 제약을 설정
• 사용자의 요구를 정확하게 추출하여 목표를 정하고, 어떤 방식으로 해결할 것인지 결정
• 사용자의 요구사항을 정확하고 일관성 있게 분석하여 문서화
• UML(Unified Modeling Language), 자료 흐름도(DFD), 자료 사전(DD), 소단위 명세서(Mini-Spec), 개체 관계도(ERD), 상태 전이도(STD) 제어 명세서 등의 도구를 활용

 

자료 흐름도(DFD)

• 요구사항 분석에서 자료의 흐름 및 변환 과정과 기능을 도형 중심으로 기술하는 방법.
• 자료 흐름 그래프, 버블 차트라 부름
• 시스템 안의 프로세스와 자료 저장소 사이에 자료의 흐름을 나타내는 그래프로 자료 흐름과 처리를 중심으로 하는 구조적 분서 기법
• DFD 요소별 표기 형태
  • 처리 (Process) : 원
  • 자료 흐름 (Data Flow) : 화살표
  • 자료 저장소 (Data Store) : 평행선
  • 단말 (Terminal) : 사각형

자료 사전(DD)

• 자료 흐름도에 있는 자료를 더 자세히 정의하고 기록한 것
• 데이터를 설명하는 데이터를 데이터의 데이터, 메타 데이터 라고 한다.
• 기호
  • = : 자료의 정의 (~로 구성되어 있다.)
  • + : 자료의 연결 (그리고)
  • ( ) : 자료의 생략 (생략 가능한 자료)
  • [ | ] : 자료의 선택 (또는)
  • { } : 자료의 반복 ({ }ₙ - n번 이상 반복, { }ⁿ - 최대로 n번 반복, { } ₘ ⁿ - m이상 n이하 반복)
  • * * :자료의 설명 (주석)

 

 

UML 다이어그램

• 시스템 분석, 설계, 구현 등 시스템 개발 과정에서 시스템 개발자와 고객 또는 개발자 상호 간의 의사소통이 원활하게 이루어지도록 표준화한 대표적인 객체지향 모델링 언어
• Rumbaugh(OMT),, Booch, Jacobson 등의 객체지향 방법론의 장점을 통합
• 국제표준화기구인 OMG에서 표준으로 지정

 

순차 다이어그램

• 객체 간의 동적 상호작용을 시간 개념을 중심으로 모델링
• 일반적으로 다이어그램의 수직 방향이 시간의 흐름을 나타낸다
• 회귀 메시지(Self-Message), 제어블록(Statement block) 등으로 구성된다.

 

• 순차 다이어그램은 행위 다이어그램으로 동적이고, 순차적인 표현을 위한 다이어그램이다.

 

UML다이어그램 종류

구조, 행위 두 가지로 나누어진다.

구조 - 클객컴배복패 (클래스, 객체, 컴포넌트, 배치, 복합체, 패키지)

행위 - 유시커상활타상 (유스케이스, 시퀀스, 커뮤니케이션, 상태, 활동, 타이밍, 상호작용)

구조 (클래스, 객체, 컴포넌트, 배치, 복합체구조, 패키지) - 정적

• 클래스 다이어그램 (Class Diagram)
  • 클래스의 속성, 함수, 변수 타입들로 구성된 다이어그램  
  • 클래스와 클래스가 가지는 속성, 클래스 사이의 관계를 표현
  • 시스템의 구조를 파악하고 구조상의 문제점을 도출할 수 있다.
• 객체 다이어그램(Obejct Diagram)
  • 클래스의 인스턴스, 값이 매겨진 행동을 가지고 있는 독립된 객체정보를 표현하는 다이어그램  
  • 클래스에 속한 사물(객체)들, 즉 인스턴스를 특정 시점의 객체와 객체 사이의 관계로 표현
  • 럼바우 객체지향 분석 기법에서 객체 모델링에 활용
• 컴포넌트 다이어그램 (Component Diagram)
  • 컴포넌트끼리의 구조 관계를 표현한 다이어그램  
  • 컴포넌트 간의 인터페이스를 표현
  • 구현단계에서 사용
• 배치 다이어그램 (Deployment Diagram)
  • 소프트웨어, 하드웨어 등을 포함한 시스템의 물리적 구조를 나타내는 다이어그램
  • 구현 단계에서 사용
• 복합체 구조 다이어그램 (Composite Structure Diagram)
  • 클래스나 컴포넌트가 복합구조를 갖는 경우 그 내부구조를 표현
• 패키지 다이어그램 (Package Diagram)
  • 유스케이스나 클래스 등의 모델 요소들을 그룹화한 패키지들의 관계를 표현
  • UML의 다양한 모델요소를 그룹화 한 다이어그램

행위 (유스케이스, 순차, 커뮤니케이션, 상태, 활동, 상호작용, 타이밍) - 동적

• 유스케이스 다이어그램 (Use Case Diagram)
  • 사용자 관점에서 바라본 시스템을 표현한 다이어그램
  • 사용자의 요구를 분석하는 것으로 기능 모델링 작업에 사용
  • 사용자와 사용사례로 구성되며, 사용 사례 간에는 여러 형태의 관계로 이루어짐
• 순차 다이어그램 (Sequence Diagram)
  • 여러 대상 간의 상호작용을 시간 순서에 따라 표현한 다이어그램.
• 커뮤니케이션 다이어그램 (Communication Diagram)
  • 동작에 참여하는 객체들이 주고받는 메시지를 표현하고, 메시지뿐만 아니라 객체 간의 관계까지 표현하는 다이어그램
• 상태 다이어그램 (State Diagram)
  • 하나의 객체가 다른 객체와의 상호작용에 따라 어떻게 변화하는지 표현하는 다이어그램.
  • 이벤트에 의한 객체들의 상태 변화를 그림으로 표현
  • 럼바우 객체지향 분석 기법에서 동적 모델링에 활용
• 활동 다이어그램 (Activity Diagram)
  • 여러 활동들이 순차, 병행 방식 등을 수행하는 상황을 표현하는 다이어그램
  • 처리의 흐름을 순서에 따라 표현
  • 오퍼레이션이나 처리 과정이 수행되는 동안 일어나는 일들을 단계적으로 표현
• 상호작용 개요 다이어그램 (Interaction Overview Diagram)
  • 상호작용 다이어그램 간의 제어 흐름 표현
• 타이밍 다이어그램 (Timing Diagram)
  • 객체 상태 변화와 시간 제약을 명시적 표현

* 액터: 시스템과 상호작용하는 모든 것 (사람, 기계 시스템 등)

 

https://seulhee030.tistory.com/56

[UML]UML다이어그램 종류 및 특징(구조별, 행위별)

 

---

2장 화면 설계

사용자 인터페이스(UI, User Interface) 구분

• CLI(Command Line Interface): 텍스트 형태 인터페이스
• GUI(Graphical User Interface) : 마우스로 선택하여 작업하는 그래픽 환경 인터페이스
• NUI(Natural User Interface) : 사용자의 말이나 행동으로 기기 조작하는 인터페이스
• VUI(Voice User Interface) : 사람의 음성으로 기기 조작하는 인터페이스
• OUI(Organic User Interface) : 모든 사물과 사용자 간의 상호작용을 위한 인터페이스

 

UI  기본 원칙

• 직관성 (Intuitiveness) : 누구나 쉽게 이해하고, 쉽게 사용할 수 있어야 함
• 유효성 (Effectiveness) : 정확하고 완벽하게 사용자의 목표가 달성될 수 있도록 제작해야 함.
• 학습성 (Learnability) : 초보자와 숙련자 모두가 쉽게 배우고 사용할 수 있게 제작해야 함
• 유연성 (Flexibility) : 사용자의 인터렉션을 최대한 포용하고, 실수를 방지할 수 있도록 제작해야 함

UI 설계 지침

• 사용자 중심 : 사용자가 쉽게 이해하고 편리하게 사용해야 함
• 사용성: 사용자가 얼마나 빠르고 쉽게 이해할 수 있는가, 효율적인가
• 일관성 : 버튼이나 조작 방법 등을 일관되게 제공
• 단순성 : 조작 방법을 단순화시켜 인지적 부담을 감소시켜야 한다.
• 결과 예측 가능 : 작동시킬 기능만 보고도 결과를 미리 예측할 수 있게 설계해야 한다.
• 가시성 : 메인 화면에 주요 기능을 노출시켜 최대한 조작이 쉽도록 설계
• 심미성 : 디자인적으로 완성도 높게, 가독성 좋게
• 표준화 : 기능 구조와 디자인을 표준화하여 쉽게 사용할 수 있도록
• 접근성 : 다양한 계층이 사용할 수 있도록
• 오류발생 해결 : 오류가 발생하면 사용자가 쉽게 인지할 수 있도록 

UI 설계 시 오류 메시니자 경고에 대한 3가지 지침

• 메시지는 이해하기 쉬워야 한다.
• 오류로부터 회복을 위한 구체적인 설명이 제공되어야 한다.
• 오류로 인해 발생될 수 있는 부정적인 내용을 적극적으로 사용자들에게 알려야 한다.

 

UI 설계 도구

• 와이어 프레임 : 초기 기획 단계 사용, (ppt 같은 거)
• 묵업 : 디자인, 사용방법설명, 평가 등을 위해 실제 화면과 유사하게 만든 정적인 형태의 모형. 시각적으로만 구성요소를 배치하는 것으로 일반적으로 실제로 구현되지는 않음. (임시 구현)
• 스토리보드 : 디자이너와 개발자가 최종적으로 참고하는 작업지침서. 상단이나 우측에 제목, 작성자 등을 입력하고 좌측에는 UI화면, 우측엔 설명을 작성한다. (기획팀에서 만들어주는 ppt 같은 거)
• 프로토타입 : 와이어프레임이나 스토리보드 등에 인터렉션을 적용함으로써 실제 구현된 것처럼 테스트가 가능한 동적인 형태의 모형
• 유스케이스 : 사용자 측면에서의 요구사항으로, 사용자가 원하는 목표를 달성하기 위해 수행할 내용을 기술

 

---

3장 애플리케이션 설계

 

소프트웨어 아키텍처

모듈화 (Modularity)

• 소프트웨어의 성능을 향상시키거나 시스템의 수정 및 재사용, 유지 관리 등이 용이하도록 시스템의 기능들을 모듈 단위로 나누는 것.
• 자주 사용되는 계산식이나 사용자 인증과 같은 기능들을 공통 모듈로 구성하여 프로젝트의 재사용성 향상
• 모듈화를 통해 기능의 분리가 가능하여 인터페이스가 단순해짐

추상화 (Abstraction)

• 문제의 전체적이고 포괄적인 개념을 설계한 후 차례로 세분화하여 구체화시켜 나가는 것.
• 추상화는 최소의 비용으로 실제 상황에 대처할 수 있고, 시스템의 구조 및 구성을 대략적으로 파악할 수 있게 해 준다.

추상화 유형

• 과정 추상화 : 자세한 수행과정을 정의하지 않고 전반적인 흐름만 파악할 수 있게 설계
• 데이터 추상화: 데이터의 세부적인 속성이나 용도를 정의하지 않고 데이터 구조를 대표할 수 있는 표현으로 대체하는 방법
• 제어 추상화 : 이벤트 발생의 정확한 절차나 방법을 정의하지 않고, 대표할 수 있는 표현으로 대체하는 방법

제어, 과정, 자료 '제과자'

 

단계적 분해 (Stepwise Refinement)

• Niklaus Wirth에 의해 제안된 하향실 설계 전략
• 추상화의 반복으로 세분화
• 소프트웨어의 기능에서부터 시작하여 점차적으로 구현하고, 알고리즘 자료구조 등 상세한 내역은 가능한 뒤로 미룬다.

정보 은닉 (Information Hiding)

• 은닉은 한 모듈 내부에 포함된 절차와 자료들의 정보가 감추어져 다른 모듈이 접근하거나 변경하지 못하도록 하는 기법
• 정보 은닉을 통해 모듈을 독립적으로 수행할 수 있고, 하나의 모듈이 변경되더라도 다른 모듈에 영향을 주지 않으므로 수정, 시험, 유지보수가 용이하다.
• 캡슐

소프트웨어 아키텍처의 품질 속성

시스템 측면

• 성능, 보안, 가용성, 기능성, 사용성, 변경 용이성, 확장성, 테스트 용이성, 배치성, 안정성 등

비즈니스 측면

• 시장 적시성, 비용과 혜택, 예상 시스템 수명, 목표 시장, 공개 일정, 기존 시스템과의 통합 등

아키텍처 측면

• 개념적 무결성, 정확성, 완결성, 구축 가능성, 변경성, 시험성, 적응성, 일치성, 대체성 등

 

 아키텍처 패턴

• 소프트웨어 시스템의 구조를 구성하기 위한 기본적인 윤곽을 제시
• 시행착오를 줄여 개발 시간 단축, 고품질의 소프트웨어 생산
• 검증된 구조로 개발하기 때문에 안정적인 개발
• 공통된 아키텍처를 공유하여 의사소통 원활
• 손쉬운 유지보수
• 레이어 패턴, 클라이언트-서버 패턴, 파이프-필터 패턴, MVC패턴 등

* 컴포넌트 : 컴포넌트는 독립적인 업무 또는 기능을 수행하는 실행코드 기반으로 작성된 모듈

레이어 패턴 (Layers pattern)

• 시스템을 계층(Layer)으로 구분하여 구성하는 고전적인 방법
• 각각의 서브시스템들이 계층 구조를 이루며, 하위 계층은 상위 계층에 대한 서비스 제고자가 되고, 상위계층은 하위계층의 클라이언트가 된다.
• 레이어 패턴은 서로 마주 보는 두 개의 계층 사이에서만 상호작용
• 특정 계층만을 교체해 시스템 개선 가능

클라이언트-서버 패턴(Client-Server Pattern)

• 하나의 서버 컴포넌트와 다수의 클라이언트 컴포넌트로 구성된 패턴
• 사용자는 클라이언트와만 의사소통, 사용자가 클라이언트를 통해 서버에 요청하고, 클라이언트가 응답을 받아 사용자에게 제공하는 방식
• 서버는 클라이언트의 요청에 대비해 항상 대기 상태 유지
• 클라이언트나 서버는 요청과 응답을 받기 위해 동기화되는 경우를 제외하고 서로 독립적

파이프-필터 패턴 (Pipe-Filter Pattern)

• 데이터 스트림 절차의 각 단계를 필터 컴포넌트로 캡슐화하여 파이프를 통해 데이터를 전송하는 패턴
• 필터는 재사용성이 좋고, 추가가 쉬워 확장 용이
• 필터들을 재배치하여 다양한 파이프라인을 구축하는 것이 가능
• 파이프-필터 패턴은 데이터 변환, 버퍼링, 동기화 등에 주로 사용
• 필터 간 데이터 이동 시 데이터 변환으로 인한 오버헤드 발생
• 대표적으로 UNIX의 쉘(Shell)

 

모델-뷰-컨트롤러 패턴 (Model-View-Controller Pattern; MVC)

• 모델 : 서브시스템의 핵심 기능과 데이터를 보관
• 뷰 : 사용자에게 정보를 표시
• 컨트롤러 : 사용자로부터 입력된 변경 요청을 처리하기 위해 모델에게 명령을 보냄
• 모델-뷰-컨트롤러의 각 부분은 별도의 컴포넌트로 분리되어 있으므로 서로 영향을 받지 않고 개발 작업 수행 가능
• 여러 개의 뷰를 만들 수 있으므로 한 개의 모델에 대해 여러개의 뷰를 필요로 하는 대화형 애플리케이션에 적합

* 대화형 어플리케이션 : 온라인 쇼핑몰이나 스마트폰 앱과 같이 사용자의 요구가 발생하면 시스템이 이를 처리하고 반응하는 소프트웨어

 

기타 패턴

마스터 슬레이브 패턴 (Master-Slave Pattern)

• 마스터는 동일한 구조의 슬레이브로 작업을 분할한 후, 슬레이브에서 처리된 결과물을 다시 돌려받는 방식으로 작업을 수행
• 마스터는 모든 작업의 주체, 슬레이브는 마스터의 지시에 따라 수행하여 결과를 반환
• 장애 허용 시스템과 병렬 컴퓨팅 시스템에서 주로 사용

 브로커 패턴 (Broker Pattern)

• 사용자가 원하는 서비스와 특성을 브로커에 요청하면 브로커가 요청에 맞는 컴포넌트와 사용자를 연결
• 원격 서비스 호출에 응답하는 컴포넌트들이 여러 개 있을 때 적합
• 분산 환경 시스템에서 주로 사용

피어-투-피어 패턴 (Peer-To-Peer Pattern)

• 피어(Peer)를 하나의 컴포넌트로 간주, 각 피어는 서비스를 호출하는 클라이언트가 될 수도, 서비스를 제공하는 서버가 될 수도 있음
• P2P 방식이라 생각하면 되는 듯
• 멀티스레딩 방식을 사용

이벤트-버스 패턴 (Event-Bus Pattern)

• 소스가 특정 채널에 이벤트 메시지를 발행하면, 해당 채널을 구독한 리스너들이 메시지를 받아 이벤트를 처리하는 방식

블랙보드 패턴 (Blackboard Pattern)

• 모든 컴포넌트들이 공유 데이터 저장소와 블래보드 컴포넌트에 접근이 가능한 형태로, 컴포넌트들은 검색을 통해 블랙보드에서 원하는 데이터를 찾을 수 있다.
• 해결책이 명확하지 않은 문제를 처리할 때 사용
• 음성인식, 차량식별, 신호 해석 등

인터프리터 패턴 (Interpreter Pattern)

• 프로그램 코드의 각 라인을 수행하는 방법을 지정하고, 기호마다 클래스를 갖도록 구성된다.
• 특정 언어로 작성된 프로그램 코드를 해석하는 컴포넌트를 설계할 때 사용

 

 

객체지향

• 구조적 기법의 문제점으로 인한 소프트웨어 위기의 해결책으로 채택
• 재사용 및 확장이 용이하여 고품질의 소프트웨어를 빠르게 개발할 수 있고 유지보수가 쉬움
• 복잡한 구조를 단계적, 계층적으로 표현하고, 멀티미디어 데이터 및 병렬처리 지원
• 객체, 클래스, 캡슐화, 상속, 당형성, 연관성이 있음

* 구조적 기법의 문제점

• 유지보수는 고려하지 않고 개발공정에만 집중됨
• 개발이 시작된 후 추가적인 요구사항에 대응이 어려움
• 재사용이 어려워 이전에 개발한 것과 유사한 것을 다시 개발할 때도 시간과 인력이 동일하게 소모됨

객체 (Object)

• 데이터와 데이터를 처리하는 함수를 묵어놓은(캡슐화한) 하나의 소프트웨어 모듈
• 객체의 특성
  • 객체는 독립적으로 식별 가능한 이름을 갖는다.
  • 객체가 가질 수 있는 조건을 상태(State)라고 한다. 일반적으로 상태는 시간에 따라 변한다.
  • 객체와 객체는 상호 연관성에 의한 관계가 형성된다.
  • 객체가 반응할 수 있는 메시지의 집합을 행위라고 하며, 객체는 행위의 특징을 나타낼 수 있다.
  • 객체는 일정한 기억장소를 갖는다.
• 객체의 메소드는 다른 객체로부터 메시지를 받았을 때 정해진 기능을 수행한다.

클래스 (Class)

• 하나 이상의 유사한 객체를 묵어서 하나의 공통된 특성을 표현한 것.
• 객체지향 프로그램에서 데이터를 추상화하는 단위
• 클래스에 속한 각각의 객체를 인스턴스(Instance)라 한다.
• 클래스로부터 새로운 객체를 생성하는 것을 인스턴스화(Instantiation)
• 동일 클래스에 속한 각각의 객체(인스턴스)들은 공통된 속성과 행위를 가지고 있으며, 그 속성에 대한 정보가 서로 달라서 동일 기능을 하는 여러 가지 객체를 나타내게 된다
• 최상위 클래스는 상위 클래스를 갖지 않는 클래스를 의미한다.
• 슈퍼 클래스(Super Class)는 특정 클래스의 상위(부모) 클래스이고, 서브 클래스(Sub Class)는 특정 클래스의 하위(자식) 클래스이다.

 캡슐화 (Encapsulation)

• 서로 관련성이 많은 데이터들과 연산들을 묶는다.
• 캡슐화된 객체는 인터페이스를 제외한 세부 내용이 은폐되어 외부에서 접근이 제한적이기 때문에 외부 모듈의 변경으로 인한 파급효과가 적다.
• 캡슐화된 객체들은 재사용이 쉽다.
• 객체들 간의 메시지를 주고받을 때 상대 객체의 세부내용은 알 필요가 없으므로 인터페이스가 단순해지고, 객체 간의 결합도가 낮아진다.

상속(Inheritance)

• 이미 정의된 상위 클래스(부모 클래스)의 모든 속성과 연산을 하위 클래스(자식 클래스)가 물려받는 것.
• 하위 클래스는 상위 클래스로부터 상속받은 속성과 연산 외에 새로운 속성과 연산을 첨가하여 사용할 수 있다.
• 상위 클래스의 속성관 연산을 하위 클래스가 사용할 수 있기 때문에 객체와 클래스의 재사용을 높이는 중요한 개념
• 다중 상속(Multiple Inheritance) : 한 개의 클래스가 두 개 이상의 상위 클래스로부터 속성과 연산을 상속받는 것.

다형성 (Polymorphism)

• 다형성은 현재 코드를 변경하지 않고 새로운 클래스를 쉽게 추가할 수 있게 한다.
• 다형성이란 여러 가지 형태를 가지고 있다는 의미로, 여러 형태를 받아들일 수 있는 특징
• 메소드 오버라이딩(Overriding)은 상위 클래스에서 정의한 일반 메소드의 구현을 하위 클래스에서 무시하고 재정의할 수 있다.
• 메소드 오버라이딩(Overriding)은 상속관계에서만 발생, 슈퍼클래스의 메서드를 서브클래스에서도 동일한 메소드를 재정의 하는 것
• 메소드 오버라이딩(Overriding, 메소드 재정의) 기능의 경우 상위 클래스에서 정의한 메소드의 이름은 같지만 메소드 안의 실행 코드를 달리하여 자식 클래스에서 재정의해서 사용 가능
• 메소드 오버로딩(Overloading)은 같은 이름의 메소드를 중복하여 정의하는 것.

 

 

객체지향 분석기법

1. 동적 모델링

2. 상향

• Rumbaugh(럼바우) 방법
  • 모든 소프트웨어 구성요소를 그래픽 표기법을 이용하여 모델링하는 기법
  • 객체 모델링 기법 (Object Modeling Technique)이라고도 한다.
  • 분석 활동은 객체 모델링 -> 동적 모델링 -> 기능 모델링 순으로 이루어진다.

객 동 기 로 외운다.

'모델링' 이 들어갈 경우

객체 = 객체 (객2)

동적 = 상태 (동상)

기능 = 자료 (기자)

객체 모델링 : 정보 모델링, 시스템에서 요구

동적 모델링 : 제어, 흐름, 동작, 상태

기능 모델링 : DFD

• Booch (부치) 방법
  • 미시적 (Micro) 개발 프로세스와 거시적(Macro) 개발 프로세스를 모두 사용하는 분석 방법
  • 클래스와 객체들을 분석 및 식별하고 클래스의 속성과 연산을 정의한다.
• Jcobson 방법
  • Use Case를 강조하여 사용하는 분석 방법
• Coad와 Yourdon 방법
  • E-R 다이어그램을 사용하여 객체의 행위를 모델링
  • 객체 식별, 구조 식별, 주제 정의, 속성과 인스턴스 연결 정의, 연산과 메시지 연결 정의 등의 과정으로 구성하는 기법
• Wirfs-Brock 방법
  • 분석과 설계 간의 구분이 없고, 고객 명세서를 평가해서 설계 작업까지 연속적으로 수행하는 기법

객체지향 설계 원칙

• 단일책임 원칙 (SRP, Single Responsibility Principle)
  • 객체는 단 하나의 책임만 가져야 한다.
  • 응집도는 높고, 결합도는 낮게 설계
• 개방-폐쇄 원칙 (OCP, Open-Closed Principle)
  • 기존의 코드를 변경하지 않고 기능을 추가할 수 있도록 설계해야 한다.
  • 공통 인터페이스를 하나의 인터페이스로 묶어 캡슐화하는 방법이 대표적
• 리스코프 치환 원칙 (LSP, Liskov Substitution Principle)
  • 자식 클래스는 최소한 자신의 부모 클래스에서 가능한 행위는 수행할 수 있어야 한다.
  • 자식 클래스는 부모 클래스의 책임을 무시하거나 재정의하지 않고 확장만 수행해야 한다.
• 인터페이스 분리 원칙 (ISP, Interface Segregation Principle)
  • 자신이 사용하지 않는 인터페이스와 의존 관계를 맺거나 영향을 받지 않아야 한다.
  • 단인 책임 원칙이 객체가 갖는 하나의 책임이라면, 인터페이스 분리 원칙은 인터페이스가 갖는 하나의 책임이다
• 의존 역전 원칙 (DIP, Dependency Inversion Principle)
  • 각 객체들 간의 의존 관계가 성립될 때, 추상성이 낮은 클래스보다 추상성이 높은 클래스와 의존 관계를 맺어야 한다.
  • 일반적으로 인터페이스를 활용하면 이 원칙은 준수된다.. 

 

 

모듈

• 모듈은 모듈화를 통해 분리된 시스템의 각 기능들로, 서브루틴, 서브시스템, 소프트웨어 내의 프로그램, 작업 단위 등과 같은 의미로 사용
• 모듈은 단독으로 컴파일이 가능하며, 재사용할 수 있다
• 모듈의 기능적 독립성은 SW를 구성하는 각 모듈의 기능이 서로 독립됨을 의미, 모듈이 하나의 기능만을 수행하고 다른 모듈과의 과도한 상호작용을 배제함으로써 이루어진다.
• 독립성이 높은 모듈일수록 모듈은 수정하더라도 다른 모듈들에게 거의 영향을 미치지 않으며, 오류가 발생해도 쉽게 발견하고 해결할 수 있다.
• 독립성을 높이려면 결합도는 약하게, 응집도는 강하게, 모듈의 크기는 작게 만들어야 한다.

 

결합도 강함 -> 약함

내공은 외제를 쓰(스)자

응집도 강함 -> 약함

기-순-교-절-시-논-우

 

약함 -> 강함

(우)리 (논)산 (시)(절) 기억나?

(교)자랑 (순)대 (기)대했는데...

결합도 (Coupling)

• 결합도가 강하면 시스템 구현 및 유지보수 작업이 어렵다.
• 자료 결합도(Data Coupling)
  • 모듈 간의 인터페이스가 자료 요소로만 구성될 때의 결합도
  • 어떤 모듈이 다른 모듈을 호출하면서 매개변수나 인수로 데이터를 넘겨주고, 호출받은 모듈은 받은 데이터에 대한 처리 결과를 다시 돌려주는 방식
  • 모듈 간의 내용을 전혀 알 필요가 없는 상태로서 한 모듈의 내용을 변경하더라도 다른 모듈에는 전혀 영향을 미치지 않는 가장 바람직한 결합도.
• 스탬프(검인) 결합도(Stamp Coupling)
  • 모듈 간의 인터페이스로 배열이나 레코드 등의 자료구조가 전달될 때의 결합도
  • 두 모듈이 동일한 자료구조를 조회하는 경우의 결합도
  • 자료구조의 어떠한 변화, 즉 포맷이나 구조의 변화는 그것을 조회하는 모든 모듈 및 변화되는 필드를 실제로 조회하지 않는 모듈에까지도 영향을 미치게 된다.
• 제어 결합도 (Control Coupling)
  • 어떤 모듈이 다른 모듈 내부의 논리적인 흐름을 제어하기 위해 제어신호를 이용하여 통신하거나 제어 요소 (Function Code, Switch, Tag, Flag)를 전달하는 결합도
  • 한 모듈이 다른 모듈의 상세한 처리 절차를 알고 있어 이를 통제하는 경우나 처리기능이 두 모듈에 분리되어 설계된 경우 발생
  • 하위 모듈에서 상위 모듈로 제어 신호가 이동하여 하위 모듈이 상위 모듈에게 처리 명령을 내리는 권리 전도현상이 발생
• 외부 결합도 (External Coupling)
  • 어떤 모듈에서 선언한 데이터(변수)를 외부의 다른 모듈에서 참조할 때의 결합도
  • 참조되는 데이터의 범위를 긱 모듈에서 제한할 수 있다. 
• 공통(공유) 결합도 (Common Coupling)
  • 공유되는 공통 데이터 영역을 여러 모듈이 사용할 때의 결합도
  • 공통 데이터 영역의 내용을 조금만 변경하더라도 이를 사용하는 모든 모듈에 영향을 미치므로 모듈의 독립성을 약하게 만든다.
• 내용 결합도 (Content Coupling)
  • 한 모듈이 다른 모듈의 내부 기능 및 그 내부 자료를 직접 참조하거나 수정할 때의 결합도
  • 한 모듈에서 다른 모듈의 내부로 제어가이동하는 경우에도 내용 결합도에 해당

응집도(Cohesion)

• 기능적 응집도 (Functional Cohesion)
  • 모듈 내부의 모든 기능 요소들이 단일 문제와 연관되어 수행될 경우의 응집도
• 순차적 응집도 (Sequential Cohesion)
  • 모듈 내 하나의 활동으로부터 나온 출력 데이터를 그다음 활동의 입력 데이터로 사용할 경우의 응집도
• 교환(통신)적 응집도 (Communication Cohesion)
  • 동일한 입력과 출력을 사용하여 서로 다른 기능을 수행하는 구성 요소들이 모였을 경우의 응집도
• 절차적 응집도 (Precedural Cohesion)
  • 모듈이 다수의 관련 기능을 가질 때 모듈 안의 구성 요소들이 그 기능을 순차적으로 수행할 경우의 응집도
• 시간적 응집도 (Temporal Cohesion)
  • 특정 시간에 처리되는 몇 개의 기능을 모아 하나의 모듈로 작성할 경우의 응집도
• 논리적 응집도 (Logical Cohesion)
  • 유사한 성격을 갖거나 특정 형태로 분류되는 처리 요소들로 하나의 모듈이 형성되는 경우의 응집도

• 우연적 응집도 (Coincidental Cohesion)
  • 모듈 내부의 각 구성요소들이 서로 관련 없는 요소로만 구성된 경우의 응집도

 

팬인(Fan-In) / 팬아웃(Fan-Out)

• 모듈에 들어오면 팬인
• 모듈에서 나가면 팬아웃
• 팬인과 팬아웃을 분석하여 시스템의 복잡도 알 수 있음
• 팬인이 높다는 것은 재사용 측면에서 설계가 잘되어 있음. 단일장애점이 발생할 수 있으므로 중점적인 관리 및 테스트 필요
• 팬아웃이 높은 경우 불필요하게 다른 모듈을 호출하고 있는지 검토하고, 단수화 여부 검토 필요
• 복잡도를 최적화하려면 팬인은 높게, 팬아웃은 낮게 설계

모듈	팬인	팬아웃
A	0	3
B	1	2
C	1	1
D	1	1
E	1	0
F	3	2
G	1	0
H	1	0

 

N-S 차트 (Nassi-Schneiderman Chart)

• 논리의 기술에 중점을 둔 도형을 이용한 표현방법으로 박스 다이어그램, Chapin 차트라고도함
• 연속, 선택 및 다중 선택, 반복 등의 제어 논리 구조를 표현
• GOTO나 화살표를 사용하지 않음
• 조건이 복합되어 있는 곳의 처리를 시각적으로 명확히 식별하는데 적합
• 선택과 반복 구조를 시각적 표현
• 이해하기 쉽고, 코드 변환 쉬움
• 읽기는 쉽지만 작성하기 어려우며, 임의로 제어를 전이하는 것이 불가능
• 총체적인 구조 표현과 인터페이스를 나타내기 어려움
• 단일 입구와 단일 출구로 표현

 

 

디자인 패턴

• 디자인 패턴은 문제 및 배경, 실제 적용된 사례, 재사용이 가능한 샘플 코드 등으로 구성
• 디자인 패턴은 한 패턴에 변형을 가하거나 특정 요구사항을 반영하면 유사한 형태의 다른 패턴으로 변화되는 특징
• GoF 패턴은 생성 패턴 5개, 구조 패턴 7개, 행위 패턴 11개로 총 23개

 

아키텍처 패턴 vs 디자인 패턴

• 아키텍처 패턴은 디자인 패턴보다 상위 수준의 설계에 사용
• 아키텍처 패턴은 전체 시스템의 구조를 설계하기 위한 참조 모델
• 디자인 패턴은 서브시스템에 속하는 컴포넌트들과 그 관계를 설계하기 위한 참조 모델
• 몇몇 디자인 패턴은 특정 아키텍처 패턴을 구현하는데 유용

 

디자인 패턴 장·단점

• 범용적인 코딩 스타일로 인해 구조 파악이 쉽다
• 객체지향 설계 및 구현의 생산성을 높이는데 적합
• 검증된 구조의 재사용을 통해 개발 시간과 비용 절약
• 초기 투자 비용이 부담될 수 있음
• 개발자 간 원활한 의사소통 가능
• 설계 변경 요청에 대한 유연한 대처 가능
• 객체지향 기반이기 때문에 다른 기반의 애플리케이션 개발에는 부적합  

   

GoF (Gang of Four) 디자인 패턴

생성 : 추상 팩토리, 빌더, 팩토리 메소드, 프로토타입, 싱글톤

구조 ; 어댑터, 브릿지, 컴포지트, 데코레이터, 퍼싸트. 플라이웨이트, 프록시

행위 : 역할 사슬, 커맨드, 인터프리터, 이터레이터, 미디에이터, 메멘토, 옵저버, 상태, 전략, 템플릿 메소드, 비지

생성 패턴

- 객체를 생성하는 것에 대한 패턴

- 생성 패턴은 객체의 생성과 참조 과정을 캡슐화하여 객체가 생성되거나 변경되어도 프로그램의 구조에 영향을 크게 받지 않도록 하여 프로그램에 유연성을 더해준다.

• 추상 팩토리 패턴(abstract factory)
  • 구체적인 클래스에 의존하지 않고, 인터페이스를 통해 서로 연관·의존하는 객체들의 그룹으로 생성하여 추상적으로 표현
  • 연관된 서브 클래스를 묶어 한 번에 교체 가능
  • 서로 다른 부품을 조립만 하는 조립 공장(Factory)
• 빌더 패턴(builder)
  • 작게 분리된 인스턴스를 건축하듯이 조합하여 객체를 생성
  • 객체의 생성 과정과 표현 방법을 분리하고 있어, 동일한 객체 생성에서도 서로 다른 결과를 만들어냄 
  • 건축가(Builder)가 블록을 조립하는 모습 
• 팩토리 메소드 패턴(factory method)
  • 객체 생성을 서브 클래스에서 처리하도록 분리하여 캡슐화 한 패턴
  • 상위 클래스에서 인터페이스만 정의하고 실제 생성은 서브 클래스가 담당
  • 가상 생성자(Virtual Constructor) 패턴이라고도 한다. 
  • 부품부터 완성품까지 통째로 찍어내는 공장(Factory)
• 프로토타입 패턴(prototype)
  • 원본 객체를 복제하는 방법으로 객체를 생성하는 패턴
  • 일반적인 방법으로 객체를 생성하며, 비용이 큰 경우 주로 이용
  • 원형(Prototype)을 두고 복제품을 만드는 것
• 싱글톤 패턴(singleton)
  • 하나의 객체를 생성하면 생성된 객체를 어디서든 참조할 수 있지만, 여러 프로세스가 동시에 참조할 수는 없다.
  • 클래스 내에서 인스턴스가 하나뿐임을 보장하며, 불필요한 메모리 낭비를 최소화할 수 있다. 
  • 식당에서 누구나 사용하는 하나뿐(Singleton)인 정수기

구조 패턴

- 구조를 통해 확장성을 꾀하는 패턴

- 구조 패턴은 구조가 복잡한 시스템을 개발하기 쉽게 도와준다.

• 어댑터(adapter)
  • 호환성이 없는 클래스들의 인터페이스를 다른 클래스가 이용할 수 있도록 변환해 주는 패턴
  • 기존의 클래스를 이용하고 싶지만 인터페이스가 일치하지 않을 때 이용
  • 전압을 맞춰주는 변압기(Adapter)
• 브릿지(bridge)
  • 구현부에서 추상층을 분리하여, 서로가 독립적으로 확장할 수 있도록 구성한 패턴
  • 기능과 구현을 두 개의 별도 클래스로 구현
  • 두 섬을 연결하는 다리(Bridge) 
• 컴포지트(composite)
  • 여러 객체를 가진 복합 객체와 단일 객체를 구분 없이 다루고자 할 때 사용하는 패턴
  • 객체들을 트리 구조로 구성하여 디렉터리 안에 디렉터리가 있듯이 복합 객체 안에 복합 객체가 포함되는 구조를 구현할 수 있음
  • 폴더와 파일을 합성(Composite)
• 데코레이터(decorator)
  • 객체 간의 결합을 통해 능동적으로 기능들을 확장할 수 있는 패턴
  • 임의의 객체에 부가적인 기능을 추가하기 위해 다른 객체들을 덧붙이는 방식으로 구현
  • 장식(Decorator)
• 퍼싸트(facade)
  • 복잡한 서브 클래스들을 피해 더 상위에 인터페이스를 구성함으로써 서브 클래스들의 기능을 간편하게 사용할 수 있도록 하는 패턴
  • 서브 클래스들 사이의 통합 인터페이스를 제공하는 Wrapper 객체가 필요
  • 외부(Facade)의 리모컨 버튼 
• 플라이웨이트(flyweight)
  • 인스턴스가 필요할 때마다 매번 생성하는 것이 아닌 가능한 한 공유해서 사용함으로써 메모리를 절약하는 패턴
  • 다수의 유사 객체를 생성하거나 조작할 때 유용하게 사용
  • 부담을 가볍게(Flyweight)하기 위해 물품을 공유하는 것
• 프록시(proxy)
  • 접근이 어려운 객체와 여기에 연결하려는 객체 사이에서 인터페이스 역할을 수행하는 패턴
  • 네트워크 연결, 메모리와 대용량 객체로의 접근 등에 이용
  • 내가 하기 어려운 법률 업무를 대리(Proxy)해서 처리해 주는 변호사 

 

행위 패턴

- 행위의 변경, 수정 등을 위한 패턴

- 행위 패턴은 하나의 객체로 수행할 수 없는 작업을 여러 객체로 분배하면서 결합도를 최소화할 수 있도록 도와준다.

• 역할 사슬 패턴(책임 연쇄, chain of reposibillty)
  • 요청을 처리할 수 있는 객체가 둘 이상 존재하여 한 객체가 처리하지 못하면 다음 객체로 넘어가는 형태의 패턴
  • 요청을 처리할 수 있는 각 객체들이 고리(Chain)로 묶여 있어 요청이 해결될 때까지 고리를 따라 책임이 넘어간다.
  • 연속(Chain)해서 나눠 받는(Responsibility) 물레방아
• 커맨드 패턴(command)
  • 요청을 객체의 형태로 캡슐화하여 재이용하거나 취소할 수 있도록 요청에 필요한 정보를 저장하거나 로그에 남기는 패턴
  • 요청에 사용되는 각종 명령어들을 추상 클래스와 구체 클래스로 분리하여 단순화
  • 각종 명령어(Command)를 하나로 합쳐둔 것
• 인터프리터 패턴(interpreter)
  • 언어에 문법 표현을 정의하는 패턴
  • SQL이나 통신 프로토콜과 같은 것을 개발할 때 사용
  • 번역기(Interpreter)
• 이터레이터 패턴(반복자, iterator)
  • 자료구조와 같이 접근이 잦은 객체에 대해 동일한 인터페이스를 사용하도록 하는 패턴
  • 내부 표현 방법의 노출 없이 순차적인 접근 가능
• 미디에이터 패턴(중재자, mediator)
  • 수많은 객체들 간의 복잡한 상호작용(Interface)을 캡슐화하여 객체로 정의하는 패턴
  • 객체 사이의 의존성을 줄여 결합도를 감소시킬 수 있다.
  • 중재자는 객체 간의 통제와 지시의 역할을 수행
  • 중고나라, 당근마켓 등 중개해주는(Mediator) 사이트
• 메멘토 패턴(memento)
  • 특정 시점에서의 객체 내부 상태를 객체화함으로써 이후 요청에 따라 객체를 해당 시점의 상태로 돌릴 수 있는 기능을 제공하는 패턴
  • Ctrl+z 기능 
• 옵저버 패턴(observer)
  • 한 객체의 상태가 변화하면 객체에 상속되어 있는 다른 객체들에게 변화된 상태를 전달하는 패턴
  • 주로 분산된 시스템 간에 이벤트를 생성·발행(Publish)하고, 이를 수신(Subscribe)해야 할 때 이용
  • 변화를 지켜보고(Observer) 알려주는 것 
• 상태 패턴(state)
  • 객체의 상태에 따라 동일한 동작을 다르게 처리해야 할 때 사용하는 패턴
  • 객체 상태를 캡슐화하고 이를 참조하는 방식으로 처리
  • 환자의 상태(State)에 따라 치료방법이 다른 것 
• 전략 패턴(strategy)
  • 동일한 계열의 알고리즘들을 개별적으로 캡슐화하여 상호 교환할 수 있게 정의하는 패턴
  • 클라이언트는 독립적으로 원하는 알고리즘을 선택하여 사용, 클라이언트에 영향 없이 알고리즘의 변경 가능
  • A, B, C 등 여러 전략들을 정하고 필요할 때 원하는 전략(Strategy)을 선택하여 쓰는 것
• 템플릿 메소드 패턴(template method)
  • 상위 클래스에서 골격을 정의하고 하위 클래스에서 세부 처리를 구체화하는 구조의 패턴
  • 유사한 서브 클래스를 묶어 공통된 내용을 상위 클래스에서 정의하의 코드 양을 줄이고 유지보수 용이
  • 세모, 네모, 동그라미를 그리는 방법(Method)들을 도형이라는 하나의 큰 틀(Template)로 묶는 것
• 비지터 패턴(방문자, visitor)
  • 각 클래스들의 데이터 구조에서 처리 기능을 분리하여 별도의 클래스로 구성하는 패턴
  • 분리된 처리 기능은 각 클래스를 방문(Visit)하여 수행

 

---

4장 인터페이스 설계

인터페이스 요구사항 검증

요구사항 검증 방법

• 동료검토 (Peer Review) : 요구사항 명세서 작성자가 명세서 내용을 직접 설명하고 동료들이 이를 들으면서 결함을 발견하는 검토 방법
• 워크스루 (Walk Through) : 회의 전에 요구사항 명세서를 미리 배포하여 사전 검토한 후 짧은 검토회의를 통해 결함을 발견하는 방법
• 인스펙션 (Inspection) : 요구사항 명세서 작성자를 제외한 다른 검토 전문가들이 요구사항 명세서를 확인하면서 결함을 발견하는 방법

* 동료검토 - 개발자가 동료 개발자들과 코드를 검토

* 워크스루 - 개발자가 동료 개발자들에게 자신이 개발한 코드를 설명하면서 검토

* 인스펙션 - 개발자를 제외하고 전문가가 검토

동료검토, 워크스루 - 비공식 / 인스펙션 - 공식적인 검토방법

 

• 프로토타이핑 (Prototyping) : 사용자의 요구사항을 정확히 파악하기 위해 실제 개발될 소프트웨어에 대한 견본품(Prototype)을 만들어 최종 결과물을 예측
• 테스트 설계 : 요구사항은 테스트할 수 있도록 작성되어야 하며, 이를 위해 테스트 케이스를 생성하여 이후에 요구사항이 현실적으로 테스트 가능한지 검토
• CASE (Computer Aided Software Engineering) 도구 활용 : 일관성 분석(Consistency Analysis)을 통해 요구사항 변경사항의 추적 및 분석 관리하고, 표준 준수 여부를 확인

인터페이스 요구사항 검증의 주요 항목

• 완전성
• 일관성
• 명확성
• 기능성
• 검증 가능성
• 추적 가능성
• 변경 용이성

 

미들웨어 (Middleware)

• 클라이언트와 서버 간의 통신을 담당하는 시스템 소프트웨어
• 이기종 하드웨어, 소프트웨어, 네트워크, 프로토콜, PC환경, 운영체제 환경 등에서 시스템 간의 표준화된 연결을 도와주는 소프트웨어
• 표준화된 인터페이스를 통해 시스템 간의 데이터 교환에 있어 일관성을 제공한다.
• 운영체제와 애플리케이션 사이에서 중간 매게 역할을 하는 다목적 소프트웨어이다.

 

• 미들웨어 솔루션은 미들웨어의 서비스 이용을 위해 사용자가 정보교환 방법 등의 내부 동작을 확인 할 필요가 없다. (위치투명성)
• 사용자가 미들웨어의 정보 교환 방법 등의 내부 동작을 쉽게 확인할 수 있다면, 보안의 위협이 되므로 확인할 수 없도록 해야 한다.
• 종류 : DB, RPC, MOM, TP-Monitor, ORB, WAS

DB(DataBase)

• DB를 사용하여 시스템을 구축하는 경우 2-Tier 아키텍처라고 함
• MS의 ODBC, 볼랜드의 IDAPI, 오라클의 Glue 등

RPC (Remote Procedure Call)

• 원격 프로시져 호출
• 이큐브시스템스의 Entera, OSF의 ONC/RPC 등

메시지 지향 미들웨어 (Message-Oriented Middleware, MOM)

• 독립적인 애플리케이션을 하나의 통합된 시스템으로 묶기 위한 역할을 한다.
• 송신 측과 수신 측의 연결 시 메시지 큐를 활용하는 방법이 있다.
• 상이한 애플리케이션 간 통신을 비동기 방식으로 지원한다.

 

• 메시지 기반의 비동기형 메시지를 전달하는 방식의 미들웨어이다.
• 온라인 업무보다는 이기종 분산 데이터 시스템의 데이터 동기를 위해 많이 사용한다.
• MOM은 즉각적인 응답을 원하는 경우가 아니라 다소 느리고 안정적인 응답을 필요로 하는 경우에 많이 사용된다.

TP-Monitor (Transaction Processing Monitor)

• 트랜잭션 처리 모니터
• 항공기나 철도 예약 업무 등과 같은 온라인 트랜잭션 업무에서 트랜잭션을 처리 및 감시하는 미들웨어
• 사용자 수가 증가해도 빠른 응답 속도를 유지해야 하는 업무에 사용

ORB (Object Request Broker)

• 객체 요청 브로커
• 객체 지향미들웨어로 코바(CORBA) 표준 스펙을 구현
• 최근 TP-Monitor의 장점인 트랜잭션 처리와 모니터링 등을 추가로 구현

웹 애플리케이션 서버(WAS; Web Application Server)

• 데이터 접근, 세션 관리, 트랜잭션 관리 등을 위한 라이브러리 제공
• 주로 DB서버와 연동해서 사용
• Tomcat, GlassFish, JBoss, Jetty, JEUS, Resin, WebLogin, WebSphere 등이 있다.

 

 

인터페이스 (Interface)

• 서로 다른 두 시스템이나 소프트웨어 등을 서로 이어주는 부분 또는 접족 장치를 의미

 

컴포넌트 (Component)

• 프로그래밍에 있어 재사용이 가능한 각각의 독립된 모듈
• 특정 기능 수행을 위해 독립적으로 분리
• 인터페이스를 통해서만 접근 가능

 

소프트웨어 모델링

• 모델링 작업의 결과물은 다른 모델링 작업에 영향을 줄 수 있다.
• 구조적 방법론에서는 DFD(Data Flow Diagram), DD(Data Dictionary)등을 사용하여 요구사항의 결과를 표현
• 객체지향 방법론에서는 UML표기법을 사용
• 소프트웨어 모델을 사용할 경우 개발된 소프트웨어에 대한 이해도 및 당사자 간의 의사소통 향상에 도움이 됨.

 

하향식 통합 테스트 (Top Down Integration Test)

• 깊이 우선 통합법, 넓이 우선 통합법 사용
• 테스트 초기부터 사용자에게 시스템 구조 보여줄 수 있다.
• 상위 모듈에서는 tc를 사용하기 어렵다.
• 상위 모듈에서 하위 모듈 방향으로 통합하면서 테스트하는 기법
• 절차
  • 주요 제어 모듈은 작성된 프로그램을 사용하고, 주요 제어 모듈의 종속 모듈은 스텁(stub)으로 대체한다.
  • 깊이 우선 or 넓이 우선 등의 통합방식에 따라, 하위 모듈인 스텁들이 한 번에 하나씩 실제 모듈로 교체된다.
  • 모듈이 통합될 때마다 테스트 실시
  • 새로운 오류가 발생하지 않음을 보증하기 위해 회귀테스트 실시

 

상향식 통합 테스트 (Bottom Up Integration Test)

• 하위 모듈에서 상위 모듈 방향으로 통합하면서 테스트하는 방법
• 가장 하위 단계의 모듈부터 통합 및 테스트가 수행되므로 스텁은 필요하지 않음.
• 하나의 주요 제어 모듈과 관련된 종속 모듈의 그룹인 클러스터(cluster)는 필요
• 절차
  • 하위 모듈을 클러스터로 결합
  • 상위 모듈에서 데이터의 입출력을 확인하기 위해 모듈인 드라이버 작성
  • 통합된 클러스터 단위로 테스트
  • 테스트가 완료되면 클러스터는 프로그램 구조의 상위로 이동하여 결합하고, 드라이버는 실제 모듈로 대체.

 

연계 시스템 구성

• 송신 시스템 : 연계할 데이터를 DB와 어플리케이션으로부터 연계테이블 또는 파일 형태로 생성하여 송신
• 수신 시스템 : 수신한 연계테이블, 파일 데이터를 수신 시스템에서 관리하는 데이터 형식에 맞게 변환하여 DB에 저장하거나 애플리케이션에서 활용할 수 있도록 제공
• 중계 서버 : 송/수신 시스템 사이에서 데이터를 송수신하고, 연계데이터의 송수신 현황을 모니터링 함, 연계데이터의 보안강화 및 다중플랫폼 지원 등이 가능