[정보처리기사] 소프트웨어 설계 - 1과목 정리

1. 요구사항 확인

1) 소프트웨어 생명 주기

소프트웨어 생명 주기는 소프트웨어의 운용 및 유지보수 과정을 각 단계별로 나눈 것입니다. 주로 개발 단계, 각 단계별 주요 활동, 산출물로 표현됩니다. 소프트웨어 생명 주기 모형은 이를 시각적으로 표현하는 형태로, 소프트웨어 프로세스 모형 또는 소프트웨어 공학 패러다임이라고도 불립니다.

2) 소프트웨어 공학

소프트웨어 공학은 소프트웨어 위기를 극복하기 위한 방안으로 연구된 학문입니다. 기본 원칙으로는 현대적 기술의 활용, 지속적인 검증, 기록 유지 등이 있습니다.

3) 폭포수 모형

폭포수 모형은 회귀 없이 선형 순차적으로 진행되는 고전적인 생명주기 모형입니다. 각 단계가 끝날 때마다 산출물이 나오며, 타당성 검토, 계획, 요구 분석, 설계, 구현(코딩), 시험(검사), 유지보수의 순서로 진행됩니다. 경험과 성공 사례가 많아 많이 사용되는 모형입니다.

4) 나선형 모형

나선형 모형은 폭포수 모형과 프로토타입의 장점에 위험 분석 기능을 추가한 형태입니다. 나선을 따라 여러 번의 소프트웨어 개발 과정을 반복하며, 계획, 위험 분석, 개발/검증, 고객 평가 단계를 거칩니다.

5) 애자일 모형

애자일 모형은 요구사항의 변동에 유연하게 대응하기 위해 일정 주기로 반복 개발을 수행하는 방식을 채택합니다. 고객 소통에 초점을 맞추며, 스크럼, XP, 칸반, Lean, 크리스탈, ASD, 기능 중심 개발(FDD) 등이 대표적인 예입니다.

4가지 핵심 가치

상호작용, 실행되는 소프트웨어, 고객 협업, 변화

• 개인과 상호작용보다 프로세스와 도구
• 실행되는 소프트웨어보다 문서
• 고객과의 협업보다 계약과 협상
• 변화에 대한 대응보다 계획

스크럼(Scrum)

스크럼은 팀 중심으로 개발 효율을 높이는 애자일 방법론입니다. 팀은 self-organizing이고 cross-functional하여 자율적으로 일합니다.

스크럼 팀 구성

• 제품 책임자(PO, Product Owner): 제품 이해도가 높고 의사 결정 권한을 가진 사람으로, 주로 개발 의뢰자나 사용자입니다.
• 스크럼 마스터(SM): 스크럼 팀을 조언하고 가이드하며, 일일 스크럼 회의를 주관합니다.
• 개발팀(DT): 개발자, 디자이너, 테스터 등으로 구성되며, 최대 7~8명으로 구성됩니다.

스크럼 개발 프로세스

1. 제품 백로그(Product Backlog): 요구사항을 우선순위에 따라 나열합니다.
2. 스프린트 계획 회의: 이번 스프린트에서 작업할 항목을 선정하고 단기 계획을 수립합니다.
3. 스프린트: 실제 개발이 이루어지며, 2~4주 간 진행됩니다.
4. 일일 스크럼 회의: 15분간 진행 상황을 점검하고 장애 요소를 처리합니다.
5. 스프린트 검토 회의: 완료된 작업을 사용자와 함께 테스트합니다.
6. 스프린트 회고: 스프린트 과정에서의 개선점을 논의합니다.

XP (eXtreme Programming)

XP는 고객 참여와 개발 과정의 반복을 극대화하여 요구사항에 유연하게 대처하는 방법론입니다. 짧고 반복적인 개발 주기, 단순한 설계, 고객의 적극적 참여를 통해 빠른 개발을 목표로 합니다.

XP의 주요 실천 방법

• 짝 프로그래밍
• 공동 코드 소유(Collective Ownership)
• 테스트 주도 개발(TDD): 테스트를 우선 작성하고 테스트 자동화 도구를 사용합니다.
• 지속적 통합(CI): 모듈을 개발하고 지속적으로 통합합니다.
• 리팩토링(Design Improving/Refactoring)
• 소규모 릴리즈(Small Release)

---

2. 화면 설계

1) 사용자 인터페이스의 특징

• 사용자 만족도에 가장 큰 영향을 미치며, 변경이 잦습니다.
• 유저 편리성, 가독성을 높여 작업 시간을 단축하고 업무 이해도를 향상시킵니다.
• 최소한의 노력으로 원하는 결과를 얻을 수 있게 설계됩니다.
• 사용자 중심 설계, 상호작용이 중요합니다.
• 오류를 줄이고, 정보 제공자와 공급자 간의 매개 역할을 수행합니다.
• 설계 시 소프트웨어 아키텍처를 숙지할 필요가 있습니다.

2) UI 구분

• CLI(Command Line Interface): 명령어를 입력하고 출력을 확인하는 방식.
• GUI(Graphical User Interface): 그래픽 요소를 활용한 인터페이스.
• NUI(Natural User Interface): 사용자의 자연스러운 말과 행동을 인식하는 인터페이스.
• VUI(Voice User Interface): 음성을 통한 인터페이스.
• OUI(Organic User Interface): IoT, VR, 증강현실 등 모든 사물과의 상호작용을 포함하는 인터페이스.

3) 기본 원칙

• 직관성: 사용자가 쉽게 이해하고 사용할 수 있어야 합니다.
• 유효성: 사용자의 목적을 효과적으로 달성할 수 있어야 합니다.
• 학습성: 러닝커브를 낮추어 사용자가 쉽게 배울 수 있어야 합니다.
• 유연성: 다양한 요구사항을 수용하고 실수를 최소화할 수 있어야 합니다.

4) 설계 지침

• 사용자 중심 설계: 사용자의 필요와 요구를 중심으로 설계합니다.
• 사용성 향상: 학습이 쉽고 효율적으로 사용할 수 있도록 설계합니다.
• 심미성 유지: 시각적으로 매력적이고 일관된 디자인을 유지합니다.
• 오류 발생 시 해결 용이성: 사용자가 오류를 쉽게 인지하고 해결할 수 있도록 지원합니다.

5) 기능

• 입력 검증: 사용자 입력의 정확성을 확인합니다.
• 에러 처리 및 메시지 표시: 오류 발생 시 사용자에게 명확한 메시지를 제공합니다.
• 도움/프롬프트 제공: 사용자가 필요할 때 도움말이나 지침을 제공합니다.

6) 설계 도구

와이어프레임

기획 초기의 개략적인 레이아웃을 손그림, PPT, 스케치, 일러스트, 포토샵 등을 이용해 작성합니다.

목업

와이어프레임보다 실제 화면에 가깝지만 정적인 모형으로, 파워 목업이나 발사믹 목업 등이 있습니다.

스토리보드

와이어프레임과 콘텐츠 설명, 페이지 간 이동 흐름을 포함한 설계 도구로, 디자이너와 개발자의 참고 자료로 사용됩니다.

프로토타입

인터랙션이 가능한 동적 모형으로, 사용성 테스트 및 서비스 이해를 위해 작성됩니다.

유스케이스

사용자 측면의 요구사항을 정의하며, 프로젝트 초기에 기능적 요구를 결정하고 문서화합니다.

7) 품질 요구 사항

사용자 요구사항을 충족시키는 품질 요구 사항은 ISO/IEC 9126, ISO/IEC 25010 등의 국제 표준을 참고합니다. 주요 요소로는 기능성, 신뢰성, 사용성, 효율성, 유지보수성, 이식성 등이 있습니다.

요소

• 기능성(Functionality): 요구사항을 만족시키는 정도.
• 신뢰성(Reliability): 오류 없이 일관적으로 기능을 수행하는 능력.
• 사용성(Usability): 사용자가 정확히 이해하고 사용하는지, 또한 사용하고 싶은지.
• 효율성(Efficiency): 빠르게 처리하는 능력.
• 유지보수성(Maintainability): 분석성, 변경성, 안정성, 시험성.
• 이식성(Portability): 다른 환경에서 적용 가능한지 여부.

8) UI 요소

• 체크박스(Checkbox): 다중 선택 가능.
• 라디오 버튼(Radio Button): 단일 선택 가능.
• 텍스트박스(Textbox)
• 콤보박스(Combobox): 지정된 목록과 새 입력 가능.
• 목록 상자(Listbox): 입력 불가, 선택만 가능.

---

3. 애플리케이션 설계

1) 상위 설계과 하위 설계

상위 설계 하위 설계

아키텍처 설계, 예비 설계	모듈 설계, 상세 설계
시스템의 전체적 구조	시스템 내부 구조, 행위
구조, DB, 인터페이스	컴포넌트, 자료구조, 알고리즘

2) 소프트웨어 아키텍처 설계

기본 원리

• 모듈화(Modularity): 성능 향상, 수정 및 재사용 용이.
• 추상화(Abstraction): 전체적 설계에서 세분화 및 구체화.
• 단계적 분해(Decomposition): 하향식 설계 전략.
• 정보 은닉(Information Hiding): 모듈 간의 접근 및 변경 제한.

품질 속성

품질 평가 요소는 시스템, 비즈니스, 아키텍처 측면으로 구체화됩니다.

• 시스템 측면: 성능, 보안, 가능성, 기능성, 사용성, 변경 용이성 등.
• 비즈니스 측면: 시장 적시성, 비용/혜택, 예상 시스템 수명.
• 아키텍처 측면: 개념적 무결성, 정확성, 완결성 등.

설계 과정

1. 설계 목표 설정
2. 시스템 타입 결정: 시스템/서브시스템 타입, 아키텍처 패턴 등.
3. 아키텍처 패턴 적용: 시스템 표준 아키텍처 설계.
4. 서브 시스템 구체화
5. 검토

3) 협약(Contract)에 의한 설계

컴포넌트 설계 시 클래스 간의 가정을 공유하기 위해 명세를 작성합니다.

• 선행조건(Precondition): 오퍼레이션 호출 전 참이어야 하는 조건.
• 결과조건(Postcondition): 오퍼레이션 수행 후 만족해야 하는 조건.
• 불변조건(Invariant): 오퍼레이션 실행 동안 항상 유지되어야 하는 조건.

4) 아키텍처 패턴

파이프 필터 패턴

데이터 스트림을 필터로 캡슐화하고 파이프를 통해 전송하는 패턴입니다. 필터의 재사용성과 확장성이 높으며, 데이터 변환, 버퍼링, 동기화에 유용합니다.

예시: UNIX Shell

Source --Pipe1--> Filter1 --Pipe2--> Filter2 --Pipe3--> Sink

MVC (Model-View-Controller)

서브 시스템을 모델, 뷰, 컨트롤러의 세 가지로 구조화하는 패턴입니다.

기타 패턴

• 마스터-슬레이브 패턴(Master-Slave Pattern): 마스터 컴포넌트가 슬레이브에게 작업을 분할하고 슬레이브가 작업을 수행한 후 결과를 반환.
• 브로커 패턴(Broker Pattern): 브로커가 요청에 맞는 컴포넌트를 찾아 사용자와 연결.
• 피어 투 피어 패턴(Peer-to-Peer Pattern): 피어가 클라이언트와 서버 역할을 동시에 수행.
• 이벤트-버스 패턴(Event-Bus Pattern): Publish-Subscribe 방식의 메시지 전달.
• 블랙보드 패턴(Blackboard Pattern): 모든 컴포넌트가 공유 데이터인 블랙보드에 접근 가능.
• 인터프리터 패턴(Interpreter Pattern): 각 기호마다 클래스를 갖도록 구성하여 언어의 문법을 정의.

5) 객체지향

객체

객체는 데이터와 함수를 하나로 묶은 소프트웨어 모듈입니다. 객체는 상태(state)와 행위(behavior)를 가집니다.

특성

• 독립적으로 식별 가능한 이름
• 상태의 변화
• 객체 간의 상호 연관성
• 행위의 집합
• 일정한 기억장소

클래스

클래스는 공통된 속성과 연산을 갖는 객체의 집합으로, 객체의 일반적인 타입을 정의합니다. 클래스는 객체지향 프로그래밍에서 데이터를 추상화하는 단위입니다.

캡슐화(Encapsulation)

데이터와 함수를 하나로 묶어 외부로부터 내부 구현을 숨기는 개념입니다. 이를 통해 정보 은닉과 외부 변경에 대한 파급 효과를 줄이고, 재사용성을 높일 수 있습니다.

상속(Inheritance)

부모 클래스의 모든 속성과 연산을 자식 클래스가 물려받는 개념입니다. 자식 클래스는 자신만의 속성과 연산을 추가할 수 있습니다.

다형성(Polymorphism)

동일한 메시지에 대해 객체가 각기 다른 방식으로 응답할 수 있는 능력입니다. 이는 객체가 동일한 메소드명을 사용하여 다양한 응답을 가능하게 합니다.

연관성(Relationship)

객체 간의 관계를 나타내며, 다음과 같은 종류가 있습니다.

• 연관화(Association): 객체 간의 상호 관련성.
• 집합화(Aggregation): 객체 모아 하나의 상위 객체를 구성.
• 포함(Composition): 집합의 특수한 형태로, 포함하는 객체의 변화가 포함된 객체에 영향을 미침.
• 일반화(Generalization): 상위 클래스와 하위 클래스 간의 관계.
• 의존(Dependency): 필요한 만큼만 연관 유지.

2) 객체지향 분석 및 설계

객체지향 분석의 방법론

• 럼바우(Rumbaugh): 객체, 동적, 기능 모델로 분석.
• 부치(Booth): 미시적, 거시적 개발 프로세스.
• 제이콥슨(Jacobson): 유스케이스 중심.
• Coad/Yourdon: ERD 중심.
• Wirfs/Brock: 분석과 설계를 구분하지 않고 명세서 중심.

럼바우의 분석 기법

• 객체 모델링(Object Modeling)
• 동적 모델링(Dynamic Modeling)
• 기능 모델링(Function Modeling)

객체지향 설계 원칙(SOLID)

1. 단일 책임 원칙(SRP, Single Responsibility Principle): 클래스는 단 하나의 책임만 가져야 합니다.
2. 개방 폐쇄 원칙(OCP, Open-Closed Principle): 클래스는 확장에 열려 있어야 하고, 수정에 닫혀 있어야 합니다.
3. 리스코프 치환 원칙(LSP, Liskov Substitution Principle): 자식 클래스는 부모 클래스의 기능을 대체할 수 있어야 합니다.
4. 인터페이스 분리 원칙(ISP, Interface Segregation Principle): 특정 클라이언트를 위한 인터페이스를 분리하여, 불필요한 의존을 줄입니다.
5. 의존 역전 원칙(DIP, Dependency Inversion Principle): 추상화에 의존하고, 구체화에 의존하지 않아야 합니다.

3) 모듈

결합도(Coupling)

모듈 간의 상호 의존 정도를 나타내며, 결합도가 낮을수록 품질이 높습니다. 결합도가 높을수록 구현과 유지보수성이 낮아집니다.

결합도의 종류 (약한 순)

1. 자료 결합도(Data Coupling): 인터페이스가 자료 요소로만 구성.
2. 스탬프 결합도(Stamp Coupling): 자료 구조 요소로만 구성.
3. 제어 결합도(Control Coupling): 제어 신호, 제어 요소를 통해 연결.
4. 외부 결합도(External Coupling): 한 모듈의 데이터를 다른 모듈에서 참조.
5. 공통 결합도(Common Coupling): 여러 모듈이 공통 데이터 영역을 사용.
6. 내용 결합도(Content Coupling): 한 모듈의 기능과 데이터를 직접 참조.

응집도(Cohesion)

모듈 내의 요소들이 얼마나 밀접하게 관련되어 있는지를 나타내며, 응집도가 높을수록 품질이 좋습니다.

응집도의 종류 (강한 순)

1. 기능적 응집도(Function Cohesion): 모든 기능이 단일 문제와 관련.
2. 순차적 응집도(Sequential Cohesion): A 모듈의 출력이 B 모듈의 입력.
3. 교환적 응집도(Communicational Cohesion): 동일한 입출력으로 서로 다른 기능.
4. 절차적 응집도(Procedural Cohesion): 모듈이 다수 기능을 순차적으로 수행.
5. 시간적 응집도(Temporal Cohesion): 특정 시간에 처리되는 여러 기능을 묶음.
6. 논리적 응집도(Logical Cohesion): 유사한 성격/형태의 요소로 모듈 구성.
7. 우연적 응집도(Temporal Cohesion): 관련 없는 요소를 우연히 한 모듈에 묶음.

팬인/팬아웃(Fan-in/Fan-out)

• 팬인(Fan-in): 한 모듈을 호출하는 모듈의 수.
• 팬아웃(Fan-out): 한 모듈이 호출하는 모듈의 수.

N-S 차트 (Nassi-Schneiderman Chart)

논리 기술을 도형으로 표현하는 차트로, 단일 입구와 단일 출구를 가집니다. 제어 논리 구조를 시각적으로 명확하게 표현할 수 있어 이해하기 쉽고 코드 변환이 용이하지만, 작성이 어렵고 총체적 구조나 인터페이스 표현이 난해할 수 있습니다.

4) 공통 모듈

개념

자주 사용되는 계산식, 사용자 인증 등 공통 기능을 모듈로 설계하여 재사용성을 높입니다. 설계 과정에서 공통 부분을 식별하고 명세를 작성하는 것이 중요합니다.

명세 기법

• 정확성: 요구사항이 정확히 반영되어야 합니다.
• 명확성: 이해하기 쉽게 명세되어야 합니다.
• 완전성: 모든 요구사항이 포함되어야 합니다.
• 일관성: 명세 간에 모순이 없어야 합니다.
• 추적성: 요구사항과 명세가 연결되어야 합니다.

재사용

이미 개발된 기능을 새 시스템이나 기능 개발에 재구성하여 사용합니다.

• 사용법 공개: 누구나 쉽게 사용할 수 있도록 인터페이스를 공개합니다.
• 결합도 낮게, 응집도 높게: 재사용성을 높이기 위해 결합도는 낮게, 응집도는 높게 유지합니다.

규모에 따른 분류

• 함수, 객체: 간단한 재사용을 위해.
• 컴포넌트(Component): 독립적인 기능을 수행하는 코드 기반 모듈.
• 애플리케이션(Application): 공통 기능을 포함하는 애플리케이션 단위.

설계 방안

• 결합도 낮게, 응집도 높게 유지
• 모듈의 제어 영역 내에서 영향 영역 유지
• 복잡도와 중복성 최소화
• 일관성 유지
• 유지보수 용이성 확보
• 시스템 전반적인 기능/구조를 이해하기 쉬운 크기로 분리

5) 코드

개요

코드는 자료 처리 과정을 신속하고 명확하게 전달하기 위한 기호입니다. 예를 들어, 주민등록번호, 학번, 전화번호 등이 이에 해당합니다.

종류

• 순차코드(Sequential Code): auto_increment 방식.
• 블록코드(Block Code): 공통성 있는 블록으로 묶고 그 안에서 auto_increment.
• 10진 코드(Decimal Code): 도서관 등에서 사용.
• 그룹 분류 코드(Group Classification Code): 예: 1-01-001 (총무부).
• 연상코드(Associative Code): 예: TV-40.
• 합성코드(Composite Code): 예: Ke-711 (대한항공 711).

6) 디자인 패턴

개요

디자인 패턴은 설계 시 참조할 만한 전형적인 해결 방식을 제공합니다. 이를 통해 "Don't reinvent the wheel" 원칙을 실현하며, GoF의 디자인 패턴으로 생성, 구조, 행위 패턴 등이 있습니다.

장단점

• 장점
  • 범용성이 높고 구조 파악이 용이.
  • 객체지향 설계에 적합하며 생산력 증대.
  • 이미 검증된 패턴으로 개발 시간과 비용 단축.
  • 개발자 간 의사소통이 용이.
  • 설계 변경 요청에 유연하게 대처 가능.
• 단점
  • 초기 투자 비용이 높을 수 있음.
  • 객체지향 설계가 아닌 경우 적용이 어려움.

생성 패턴(Creational Pattern)

객체의 생성과 참조 과정을 캡슐화하여 프로그램의 유연성을 높입니다.

• 추상 팩토리(Abstract Factory): 구체적인 클래스가 아니라 인터페이스를 통해 연관 객체 그룹을 생성.
• 빌더(Builder): 객체의 생성과 표현을 분리.
• 팩토리 메소드(Factory Method): 객체 생성을 서브클래스로 분리하여 상위 클래스는 인터페이스만 정의.
• 프로토타입(Prototype): 원본 객체를 복제하여 사용.
• 싱글톤(Singleton): 단일 인스턴스를 보장하여 어디서든 참조 가능.

구조 패턴(Structural Pattern)

클래스를 조합하여 더 큰 구조를 만드는 패턴입니다.

• 어댑터(Adapter): 호환성이 없는 클래스의 인터페이스를 다른 클래스가 사용할 수 있게 변환.
• 브릿지(Bridge): 추상층을 분리하여 독립적으로 확장.
• 컴포지트(Composite): 복합 객체와 단일 객체를 구분 없이 다룸.
• 데코레이터(Decorator): 객체에 동적으로 부가 기능을 추가.
• 퍼사드(Facade): 복잡한 서브 시스템을 간단하게 사용할 수 있도록 통합 인터페이스 제공.
• 플라이웨이트(Flyweight): 인스턴스를 가능한 한 공유하여 메모리 절약.
• 프록시(Proxy): 접근 어려운 객체와 연결하려는 객체 간의 인터페이스 제공.

행위 패턴(Behavioral Pattern)

객체 간의 상호작용과 책임 분배 방법을 정의하는 패턴입니다.

• 책임 연쇄(Chain of Responsibility): 요청 처리 객체가 여러 개일 때, 하나가 처리 못하면 다음 객체로 요청 전달.
• 커맨드(Command): 요청을 객체로 캡슐화하여 재이용 및 취소 가능.
• 인터프리터(Interpreter): 언어의 문법을 정의하여 해석.
• 반복자(Iterator): 자료구조에 대한 순차적 접근을 동일한 인터페이스로 제공.
• 중재자(Mediator): 객체 간의 복잡한 상호작용을 캡슐화.
• 메멘토(Memento): 특정 시점의 객체 상태를 저장하고 복원.
• 옵서버(Observer): 객체 간의 Publish-Subscribe 관계를 통해 상태 변화 통보.
• 상태(State): 객체의 상태에 따라 동작을 변경.
• 전략(Strategy): 유사 알고리즘을 개별적으로 캡슐화하여 상호 교환 가능.
• 템플릿 메소드(Template Method): 상위 클래스에서 알고리즘의 골격을 정의하고, 하위 클래스에서 구체화를 수행.
• 방문자(Visitor): 데이터 구조에서 처리 기능을 분리하여 별도의 클래스에서 수행.

---

4. 인터페이스 설계

1) 시스템 인터페이스 요구사항

검증 방법

• 요구사항 검토(Requirements Review): 명세서의 오류와 결함을 동료나 전문가들이 수작업으로 분석.
  • 동료 검토: 작성자가 발표하고 동료가 청취하며 결함을 찾음.
  • 워크스루(Workthrough): 명세서를 배포하고 검토 회의를 통해 분석.
  • 인스펙션(Inspection): 검토 전문가들이 명세서를 체계적으로 확인.
• 프로토타이핑(Prototyping): 견본품을 만들어 최종 결과물을 예측하고 수정.
• 테스트 설계(Test Design): 테스트 케이스를 생성하여 요구사항을 검증.
• CASE 도구 활용: 일관성 분석을 통해 요구사항의 정확성을 확인.

2) 시스템 연계 기술

• DB Link: 데이터베이스 간의 링크 객체를 이용하여 데이터 교환.
• API/Open API: 애플리케이션 프로그래밍 인터페이스를 통해 데이터 제공.
• 연계 솔루션(EAI): EAI 서버와 송수신 시스템의 클라이언트를 이용하여 시스템 간 연계.
• Socket: 네트워크를 통해 서버와 클라이언트가 소켓을 생성하고 포트를 할당하여 통신.
• Web Service: WSDL, UDDI, SOAP 프로토콜을 사용하는 웹 서비스로 시스템 간 연계.

3) 연계 매커니즘 구성 요소

• 송신 시스템: 연계 프로그램에서 받은 데이터를 형식에 맞게 변환하여 인터페이스 테이블이나 파일 등으로 송신.
• 수신 시스템: 송신 시스템에서 전송된 인터페이스 테이블이나 파일을 연계 프로그램에서 처리할 수 있는 형식으로 변환.
• 연계 서버: 송신 시스템과 수신 시스템 간의 현황을 모니터링하는 역할.

4) 미들웨어

운영체제와 응용 프로그램, 서버와 클라이언트 사이에서 다양한 서비스를 제공하는 소프트웨어입니다.

• DB 미들웨어: DB 클라이언트와 원격 DB를 연결하는 역할.
  • 2-Tier 아키텍처: DB를 사용하여 시스템 구축.
• RPC(Remote Procedure Call): 원격 프로시저를 로컬처럼 호출할 수 있게 하는 기술.
• MOM(Message Oriented Middleware): 비동기형 메시지 전달 방식을 제공하며, 이기종 분산 데이터 시스템의 데이터 동기화를 위해 사용.
• TP-Monitor(Transaction Processing Monitor): 온라인 트랜잭션 업무에서 트랜잭션 처리와 감시를 담당.
• ORB(Object Request Broker): 객체 지향 환경에서 객체 간의 요청을 중개하는 역할.
• WAS(Web Application Server): 동적인 콘텐츠 처리를 위한 미들웨어로, 웹 환경 구현을 지원.