![[정보처리기사 필기] 1과목 소프트웨어 설계](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdna%2Fbpr5zK%2FbtrysCERvKk%2FAAAAAAAAAAAAAAAAAAAAAG8tkf3MvfoiL9sz9pdK3dQWEPey6R-sgjHErNT0NcyN%2Fimg.png%3Fcredential%3DyqXZFxpELC7KVnFOS48ylbz2pIh7yKj8%26expires%3D1753973999%26allow_ip%3D%26allow_referer%3D%26signature%3Dln1kxuLkdv3QOAhFJ%252F2R1DlUC1U%253D)
◆ 1과목 소프트웨어 설계
∎1장 요구사항 확인
∙소프트웨어 생명 주기
: 소프트웨어 개발 방법론의 바탕이 되는 것으로, 소프트웨어를 개발하기 위해 정의하고 운용, 유지보수 등의 과정을 각 단계별로 나눈 것이다.
- 개발 단계와 각 단계별 주요 활동, 그리고 활동의 결과에 대한 산출물로 표현
- 개발 대상을 추상화하고 기호나 그림 등으로 시각적으로 표현하여 소프트웨어의 이해도를 향상시킬 수 있다
- 모델을 통해 이해 당사자 간의 의사소통이 향상된다
- 모델을 통해 개발될 시스템의 유추가 가능하다
- 주기를 표현하는 형태 : 소프트웨어 생명 주기 모형 = 소프트웨어 프로세스 모형 = 소프트웨어 공학 패러다임
- 모형의 종류 : 폭포수 모형, 프로토타입 모형, 나선형 모형, 애자일 모형
1. 폭포수 모형(Waterfall Model)
: 폭포에서 한 번 떨어진 물은 거슬러 올라갈 수 없듯이 개발도 이전 단계로 돌아갈 수 없다는 전제하에
각 단계를 확실히 매듭짓고 그 결과를 철저하게 검토하여 승인 과정을 거친 후 다음 단계를 진행하는 개발 방법론
- 가장 오래되고 폭넓게 사용된 전통적인 소프트웨어 생명 주기 모형으로, 고전적 생명 주기 모형
- 소프트웨어 개발 과정의 한 단계가 끝나야만 다음 단계로 넘어갈 수 있는 선형 순차적 모형
(각 단계가 끝난 후에는 다음 단계를 수행하기 위한 결과물이 명확하게 산출되어야 한다)
- 모형을 적용한 경험과 성공 사례가 많다
- 제품의 일부가 될 매뉴얼(프로그램들의 사용과 운영에 대한 내용 기술 문서)을 작성해야 한다
- 두 개 이상의 과정이 병행하여 수행되지 않는다
(타당성 검토 → 계획 → 요구 분석 → 설계 → 구현(코딩) → 시험(검사) → 유지보수)
2. 프로토타입 모형(Prototype Model, 원형 모형)
: 사용자의 요구사항을 정확히 파악하기 위해 실제 개발될 소프트웨어에 대한 시제품을 만들어 최종 결과물을 예측
하는 모형
- 시제품은 사용자와 시스템 사이의 인터페이스에 중점을 두어 개발한다
- 시스템의 일부 혹은 시스템의 모형을 만드는 과정으로서 요구되는 소프트웨어를 구현하는데, 이는 추후 구현 단계
에서 사용될 골격 코드가 된다
- 소프트웨어의 개발이 완료된 시점에서 오류가 발견되는 폭포수 모형의 단점을 보완하기 위한 모형
- 요구 수집 → 빠른 설계 → 프로토타입 구축 → 고객 평가 → 프로토타입 조정 → 구현
3. 나선형 모형(Spiral Model, 점진적 모형)
: 보헴이 제안한 것으로, 폭포수 모형과 프로토타입 모형의 장점에 위헌 분석 기능을 추가한 모형
- 나선을 따라 돌 듯이 여러 번의 소프트웨어 개발 과정을 거쳐 점진적으로 완벽한 최종 소프트웨어를 개발하는 것
으로, 점진적 모형이라고도 한다
- 소프트웨어를 개발하면서 발생할 수 있는 위험을 관리하고 최소화하는 것을 목적으로 한다
- 점진적으로 개발 과정이 반복되므로 누락되거나 추가된 요구사항을 첨가할 수 있고, 정밀하며, 유지보수 과정이
필요 없다
- 요구사항이나 아키텍처를 이해하기 어렵다거나 중심이 되는 기술에 문제가 있는 경우 적합한 모델이다
- 계획 → 분석 → 개발 → 평가 의 과정을 여러 번 반복한다
4. 애자일 모형(Agile Model)
: ‘민첩한’, ‘기민한’이라는 의미로, 고객의 요구사항 변화에 유연하게 대응할 수 있도록
일정한 주기를 반복하면서 개발과정을 진행한다.
- 어느 특정 개발 방법론이 아니라 좋은 것을 빠르고 낭비 없게 만들기 위해 고객과의 소통에 초점을 맞춘 방법론
- 기업 활동 전반에 걸쳐 사용된다
- 스프린트(Sprint) 또는 이터레이션(Iteration)이라고 불리는 짧은 개발 주기를 반복하며, 반복되는 주기마다
만들어지는 결과물에 대한 고객의 평가와 요구를 적극 수용한다
- 각 개발주기에서는 고객이 요구사항에 우선순위를 부여하여 개발 작업을 진행한다.
- 소규모 프로젝트, 고도로 숙달된 개발자, 급변하는 요구사항에 적합하다
- 종류 : 스크럼(Scrum), XP(eXtreme Programming), 칸반(Kanban), Lean, 크리스탈(Crystal),
ASD(Adaptive Software Development), 기능 중심 개발(FDD; Feature Driven Development),
DSDM(Dynamic System Development Method), DAD(Disciplined Agile Delivery) 등
∙스크럼(Scrum) 기법
: 럭비 경기에서 양 팀이 서로 대치해 있는 대형을 일컫는 것으로 팀이 중심이 되어 개발의 효율성을 높인다는
의미가 내포된 용어이다
- 스스로가 팀을 구성(self-organizing)하고, 개발에 관한 모든걸 스스로 해결(cross-functional)할 수 있어야 한다
1. 스크럼 팀의 구성
- 제품 책임자(PO; Product Owner)
ㄱ. 이해관계자 중 개발 제품의 이해도가 높고, 요구사항을 책임지고 의사 결정할 사람 (주로 개발 의뢰자나 사용자)
ㄴ. 이해관계자들의 의견을 종합하여 제품에 대한 요구사항을 작성하는 주체
ㄷ. 요구사항이 담긴 백로그(Backlog)를 작성하고 백로그에 대한 우선순위를 지정
ㄹ. 팀원들이 백로그에 스토리를 추가할 수는 있지만 우선순위를 지정할 수는 없다
ㅁ. 제품에 대한 테스트를 수행하면서 주기적으로 요구사항의 우선순위를 갱신한다
- 스크럼 마스터(SM; Scrum Master)
ㄱ. 팀이 스크럼을 잘 수행할 수 있도록 객관적인 시각에서 조언을 해주는 가이드 역할을 수행한다. (통제는 X)
ㄴ. 일일 스크럼 회의를 주관하여 진행 사항을 점검하고, 개발 과정에서 발생된 장애 요소를 공론화하여 처리한다
- 개발팀(DT, Development Team)
ㄱ. PO와 SM을 제외한 모든 팀원으로, 개발자 외에도 디자이너, 테스터 등 제품 개발에 참여하는 모든 사람이 대상
ㄴ. 보통 최대 인원은 7~8명이 적당하다
2. 스크럼 개발 프로세스
- 제품 백로그(Product Backlog)
ㄱ. 제품 개발에 필요한 모든 요구사항(User Story)을 우선순위에 따라 나열한 목록이다
ㄴ. 개발 과정에서 새롭게 도출되는 요구사항으로 인해 지속적으로 업데이트된다
ㄷ. 제품 백로그에 작성된 사용자 스토리를 기반으로 전체 일정 계획인 릴리즈 계획(Release Plan)을 수립한다
ㄹ. 스크럼 팀이 해결해야 하는 목록으로 소프트웨어 요구사항, 아키텍처 정의 등이 포함될 수 있다
- 스프린트 계획 회의(Sprint Planning Meeting)
ㄱ. 제품 백로그 중 이번 스프린트에서 수행할 작업을 대상으로 단기 일정을 수립하는 것이다
ㄴ. 스프린트에서 처리할 요구사항(User Story)을 개발자들이 나눠서 작업할 수 있도록 태스크(Task)라는 작업
단위로 분할한 후 개발자별로 수행할 작업 목록인 스프린트 백로그(Sprint Backlog)를 작성한다
- 스프린트(Sprint)
ㄱ. 실제 개발 작업을 진행하는 과정으로, 보통 2~4주 정도의 기간 내에서 진행한다
ㄴ. 스프린트 백로그에 작성된 태스크를 대상으로 작업 시간(양)을 추정한 후 개발담당자에게 할당한다
ㄷ. 태스크를 할당할 때는 개발자가 원하는 태스크를 직접 선별하여 담당할 수 있도록 하는 것이 좋다
ㄹ. 개발 담당자에게 할당된 태스크는 보통 할 일(To Do), 진행 중(In Progress), 완료(Done)의 상태를 갖는다
+ 속도(Velocity)
: 한 번의 스프린트에서 한 팀이 어느 정도의 제품 백로그를 감당할 수 있는지에 대한 추정치로 볼 수 있다
- 일일 스크럼 회의(Daily Scrum Meeting)
ㄱ. 모든 팀원이 매일 약속된 시간에 약 15분 정도의 짧은 시간동안 진행 상황을 점검한다
ㄴ. 회의는 보통 서서 진행하며, 남은 작업 시간은 소멸 차트(Burn-down Chart)에 표시한다
ㄷ. 스크럼 마스터는 발견된 장애 요소를 해결할 수 있도록 도와준다
- 스프린트 검토 회의(Sprint Review)
ㄱ. 부분 또는 전체 완성 제품이 요구사항에 잘 부합되는지 사용자가 포함된 참석자 앞에서 테스팅을 수행한다
ㄴ. 스프린트의 한 주당 한 시간 내에서 진행한다
ㄷ. 제품 책임자는 개선할 사항에 대한 피드백을 정리한 후 다음 스프린트에 반영할 수 있도록 제품 백로그를
업데이트한다
- 스프린트 회고(Sprint Retrospective)
ㄱ. 스프린트 주기를 되돌아보며 정해놓은 규칙을 잘 준수했는지, 개선할 점은 없는지 등을 확인하고 기록한다
ㄴ. 해당 스프린트가 끝난 시점에서 수행하거나 일정 주기로 수행한다
∙XP(eXtreme programming) 기법
: 수시로 발생하는 고객의 요구사항에 유연하게 대응하기 위해 고객의 참여와 개발 과정의 반복을 극대화하여
개발 생산성을 향상시키는 기존의 방법론에 비해 실용성을 강조한 방법
- 짧고 반복적인 개발 주기, 단순한 설계, 고객의 적극적인 참여를 통해 소프트웨어를 빠르게 개발하는 것이 목적
- 릴리즈의 기간을 짧게 반복하면서 고객의 요구사항 반영(사용자 스토리)에 대한 가시성을 높인다
- 릴리즈 테스트마다 고객을 직접 참여시킴으로써 요구한 기능이 제대로 작동하는지 고객이 직접 확인할 수 있다
- 비교적 소규모 인원의 개발 프로젝트에 효과적이다
- 5가지 핵심가치 : 의사소통(Commucation), 단순성(Simplicity), 용기(Courage), 존중(Respect), 피드백(Feedback)
1. XP 개발 프로세스
- 사용자 스토리(User Story)
ㄱ. 고객의 요구사항을 간단한 시나리오로 표현한 것이다
ㄴ. 내용은 기능 단위로 구성하며, 필요한 경우 간단한 테스트 사항(Test Case)도 기재한다
- 릴리즈 계획 수립(Release Planning)
ㄱ. 몇 개의 스토리가 적용되어 부분적으로 기능이 완료된 제품을 제공하는 것을 릴리즈라고 한다
ㄴ. 부분 혹은 전체 개발 완료 시점에 대한 일정을 수립한다
- 스파이크(Spike)
ㄱ. 요구사항의 신뢰성을 높이고 기술 문제에 대한 위험을 감소시키기 위해 별도로 만드는 간단한 프로그램이다
ㄴ. 처리할 문제 외의 다른 조건은 모두 무시하고 작성한다
- 이터레이션(Iteration)
ㄱ. 하나의 릴리즈를 더 세분화 한 단위를 이터레이션(Iteration)이라고 한다
ㄴ. 일반적으로 1~3주 정도의 기간으로 진행된다
ㄷ. 이 기간 중에 새로운 스토리가 작성될 수 있으며, 작성된 스토리는 진행 중인 이터레이션 혹은
다음 이터레이션에 포함될 수 있다
- 승인 검사(Acceptance Test, 인수 테스트)
ㄱ. 하나의 이터레이션 안에서 계획된 릴리즈 단위의 부분 완료 제품이 구현되면 수행하는 테스트이다
ㄴ. 사용자 스토리 작성 시 함께 기재한 테스트 사항에 대해 고객이 직접 수행한다
ㄷ. 테스트 과정에서 발견한 오류 사항은 다음 이터레이션에 포함한다
ㄹ. 테스트 이후 새로운 요구사항이 작성되거나 요구사항의 상대적 우선순위가 변경될 수 있다
ㅁ. 테스트가 완료되면 다음 이터레이션을 진행한다
- 소규모 릴리즈(Small Release)
ㄱ. 릴리즈를 소규모로 하게 되면, 고객의 반응을 기능별로 확인할 수 있어, 고객의 요구사항에 좀 더 유연하게
대응할 수 있다
ㄴ. 계획된 릴리즈 기간 동안 진행된 이터레이션이 모두 완료되면 고객에 의한 최종 테스트를 수행한 후 릴리즈,
즉 최종 결과물을 고객에게 전달한다
ㄷ. 릴리즈가 최종 완제품이 아닌 경우 다음 릴리즈 일정에 맞게 개발을 계속 진행한다
+ XP의 주요 실천 방법(Practice) , 기본원리
∙현행 시스템 파악
: 새로 개발하려는 시스템의 개발 범위를 명확히 설정하기 위해 현행 시스템의 구성과 제공 기능, 시스템 간의
전달 정보, 사용되는 기술 요소, 소프트웨어, 하드웨어, 그리고 네트워크의 구성 등을 파악한다
∙요구사항 정의
: 소프트웨어가 어떤 문제를 해결하기 위해 제공하는 서비스에 대한 설명과 정상적으로 운영되는데 필요한
제약조건 등을 나타낸다
- 소프트웨어 개발이나 유지 보수 과정에서 필요한 기준과 근거를 제공한다
- 개발하려는 소프트웨어의 전반적인 내용을 확인할 수 있게 하므로 개발에 참여하는 이해관계자들 간의
의사소통을 원활하게 하는데 도움을 준다
- 제대로 정의되어야만 이를 토대로 이후 과정의 목표와 계획을 수립할 수 있다
1. 요구사항의 유형
2. 요구사항 개발 프로세스
: 개발 대상에 대한 요구사항을 체계적으로 도출하고 이를 분석한 후 분석 결과를 명세서에 정리한 다음 마지막으로
이를 확인 및 검증하는 일련의 구조화된 활동
- 개발 프로세스가 비즈니스 목적에 부합하는지, 예산은 적정한지 등에 대한 정보를 수집, 평가한 보고서를 토대로
타당성 조사가 선행되어야 한다
- 요구사항 개발은 요구공학의 한 요소이다
+ 소프트웨어 요구사항 명세서(SRS; Software Requirement Specification)
: 업계 표준 용어로 소프트웨어가 반드시 제공해야 하는 기능, 특징, 제약조건 등을 명시한다
- 시스템의 모든 동작뿐만 아니라 성능, 보안, 사용성과 같은 품질도 기술되어야 한다
- 프로젝트 유형에 맞게 양식을 만들어 사용한다
- 소프트웨어 요구사항 명세서에 포함되는 시스템 기능, 데이터, 외부 인터페이스, 품질 요구사항은 요구사항
단위별로 개별 요구사항 명세서를 작성한다
∙요구사항 분석
: 소프트웨어 개발의 실제적인 첫 단계로 개발 대상에 대한 사용자의 요구사항을 이해하고 문서화(명세화)하는 활동
- 사용자 요구의 타당성을 조사하고 비용과 일정에 대한 제약을 설정
- 사용자의 요구를 정확하게 추출하여 목표를 정하고, 어떤 방식으로 해결할 것인지를 결정
- 요구사항 분석을 통한 결과는 소프트웨어 설계 단계에서 필요한 기본적인 자료가 되므로 사용자의 요구사항을 정확하고
일관성 있게 분석하여 문서화해야 한다
- 분석 결과의 문서화를 통해 향후 유지보수에 유용하게 활용할 수 있다
- 소프트웨어 분석가에 의해 요구사항 분석이 수행되며, 이 작업 단계를 요구사항 분석 단계라고 한다
1. 구조적 분석 기법
: 자료의 흐름과 처리를 중심으로 하는 요구사항 분석 방법
- 도형 중심의 분석용 도구와 분석 절차를 이용하여 사용자의 요구사항을 파악하고 문서화한다
- 도형 중심의 도구를 사용하므로 분석가와 사용자 간의 대화가 용이하다
- 하향식 방법을 사용하여 시스템을 세분화할 수 있고, 분석의 중복을 배제할 수 있다
- 사용자의 요구사항을 논리적으로 표현하여 전체 시스템을 일관성 있게 이해할 수 있다
- 시스템 분석의 질이 향상되고, 시스템 개발의 모든 단계에서 필요한 명세서 작성이 가능하다
- 도구의 종류 : 자료 흐름도(DFD), 자료 사전(DD), 소단위 명세서(Mini-Spec), 개체 관계도(E-RD),
상태 전이도(STD), 제어 명세서, UML Diagram 등의 도구를 이용하여 모델링한다
2. 자료 흐름도(DFD; Data Flow Diagram, =자료 흐름 그래프, =버블 차트)
: 요구사항 분석에서 자료의 흐름 및 변환 과정과 기능을 도형 중심으로 기술하는 방법
- 시스템 안의 프로세스와 자료 저장소 사이에 자료의 흐름을 나타내는 그래프로 자료 흐름과 처리를 중심으로 하는
구조적 분석 기법에 이용한다
- 자료 흐름도는 자료 흐름과 기능을 자세히 표현하기 위해 단계적으로 세분화된다
- 자료는 처리를 거쳐 변환될 때마다 새로운 이름이 부여되며, 처리는 입력 자료가 발생하면 기능을 수행한 후
출력 자료를 산출한다
- 자료 흐름도에서는 자료의 흐름과 기능을 프로세스(원), 자료 흐름(화살표), 자료 저장소(평행선), 단말(사각형)의
네 가지 기본 기호로 표시한다
3. 자료 사전(DD; Data Dictionary)
: 자료 흐름도에 있는 자료를 더 자세히 정의하고 기록한 것이며, 이처럼 데이터를 설명하는 데이터를
데이터의 데이터 또는 메타 데이터(Meta Data)라고 한다
- 자료 흐름도에 시각적으로 표시된 자료에 대한 정보를 체계적이고 조직적으로 모아 개발자나 사용자가 편리하게
사용할 수 있다
- 자료 사전에서 사용되는 표기 기호는 다음과 같다
4. 정형 분석(Fomal Analysis)
: 구문(Syntax)과 의미(Semantics)를 갖는 정형화된 언어를 이용해 요구사항을 수학적 기호로 표현한 후 이를 분석하는
과정
- 요구사항을 수학적 기호로 표현하여 분석한다
- 요구사항 분석의 마지막 단계에서 이루어진다
∙요구사항 분석 CASE와 HIPO
1. 요구사항 분석을 위한 CASE(자동화 도구)
- 요구사항을 자동으로 분석하고, 요구사항 분석 명세서를 기술하도록 개발된 도구를 의미한다
- 요구사항 분석을 위한 자동화 도구 사용의 이점은 다음과 같다
ㄱ. 표준화와 보고를 통한 문서화 품질 개선
ㄴ. 데이터베이스가 모두에게 이용 가능하다는 점에서 분석자들 간의 적절한 조정
ㄷ. 교차 참조도와 보고서를 통한 결함, 생략, 불일치 등의 발견 용이성
ㄹ. 변경이 주는 영향 추적의 용이성
ㅁ. 명세에 대한 유지보수 비용의 축소
- SADT(Structured Analysis and Design Technique)
ㄱ. SoftTech 사에서 개발한 것으로 시스템 정의, 소프트웨어 요구사항 분석, 시스템/소프트웨어 설계를 위해 널리
이용되어 온 구조적 분석 및 설계 도구이다
ㄴ. 구조적 요구 분석을 하기 위해 블록 다이어그램을 채택한 자동화 도구이다
- SREM(Software Requirements Engineering Methodology) = RSL/REVS
ㄱ. TRW 사가 우주 국방 시스템 그룹에 의해 실시간 처리 소프트웨어 시스템에서 요구사항을 명확히 기술하도록
할 목적으로 개발한 것으로, RSL과 REVS를 사용하는 자동화 도구이다
ㄴ. RSL(Requirement Statement Language) : 요소, 속성, 관계, 구조들을 기술하는 요구사항 기술 언어
| 요소 | 요구사항 명세를 개발하기 위해 사용되는 개체와 개념 |
| 속성 | 요소를 수정하거나 수식하기 위한 것 |
| 관계 | 개체들 간의 관계 |
| 구조 | 정보 흐름을 묘사하기 위한 것 |
ㄷ. REVS(Requirement Engineering and Validation System) : RSL로 기술된 요구사항들을 자동으로 분석하여
요구사항 분석 명세서를 출력하는 요구사항 분석기
- PSL/PSA
ㄱ. 미시간 대학에서 개발한 것으로 PSL과 PSA를 사용하는 자동화 도구이다
ㄴ. PSL(Problem Statement Language) : 문제(요구사항) 기술 언어
ㄷ. PSA(Problem Statement Analyzer) : PSL로 기술한 요구사항을 자동으로 분석하여 다양한 보고서를
출력하는 문제 분석기
- TAGS(Technology for Automated Generation of Systems)
ㄱ. 시스템 공학 방법 응용에 대한 자동 접근 방법으로, 개발 주기의 전 과정에 이용할 수 있는 통합 자동화
도구이다
ㄴ. 구성 : IORL, 요구사항 분석과 IORL 처리를 위한 도구, 기초적인 TAGS 방법론
ㄷ. IORL : 요구사항 명세 언어
2. HIPO(Hierarchy Input Process Output)
: 시스템의 분석 및 설계나 문서화할 때 사용되는 기법으로, 시스템 실행 과정인 입력, 처리, 출력의 기능을
나타낸다
- 기본 시스템 모델은 입력, 처리, 출력으로 구성되며, 하향식 소프트웨어 개발을 위한 문서화 도구
- 체계적인 문서 관리가 가능하다
- 기호, 도표 등을 사용하므로 보기 쉽고 이해하기도 쉽다
- 기능과 자료의 의존 관계를 동시에 표현할 수 있다
- 변경, 유지보수가 용이하다
- 시스템의 기능을 여러 개의 고유 모듈들로 분할하여 이들 간의 인터페이스를 계층 구조로 표현한 것을 HIPO
Chart라고 한다
- 종류
ㄱ. 가시적 도표(Visual Table of Contents, 도식 목차) : 시스템의 전체적인 기능과 흐름을 보여주는 계층(Tree)
구조도
ㄴ. 총체적 도표(Overview Diagrma, 총괄도표, 개요 도표) : 프로그램을 구성하는 기능을 기술한 것으로 입력,
처리, 출력에 대한 전반적인 정보를 제공하는 도표
ㄷ. 세부적 도표(Detail Diagram, 상세 도표) : 총체적 도표에 표시된 기능을 구성하는 기본 요소들을 상세히
기술하는 도표
∙UML(Unified Modeling Language)
: 시스템 분석, 설계, 구현 등 시스템 개발 과정에서 시스템 개발자와 고객 또는 개발자 상호간의 의사소통이
원활하게 이루어지도록 표준화한 대표적인 객체지향 모델링 언어이다
- Rumbaugh(OMT), Booch, Jacobson 등의 객체지향 방법론의 장점을 통합하였으며, 객체 기술에 관한
국제표준화기구인 OMG(Object Management Group)에서 표준으로 지정하였다
- UML을 이용하여 시스템 구조를 표현하는 6개의 구조 다이어그램과 시스템의 동작을 표현하는 7개의 행위
다이어그램을 작성할 수 있다
- 각각의 다이어그램은 사물과 사물 간의 관계를 용도에 맞게 표현한다
- 구성 요소 : 사물(Things), 관계(Relationships), 다이어그램(Diagram) 등이 있다
1. 사물(Things)
: 사물은 모델을 구성하는 가장 중요한 기본 요소로, 다이어그램 안에서 관계가 형성될 수 있는 대상들을 말한다
2. 관계(Relationships)
: 사물과 사물 사이의 연관성을 표현하는 것으로 연관 관계, 집합 관계, 포함 관계, 일반화 관계, 의존 관계, 실체화
관계 등이 있다
- 연관(Association) 관계
: 2개 이상의 사물이 서로 관련되어 있음을 표현
ㄱ. 사물 사이를 실선으로 연결하여 표현하며, 방향성은 화살표로 표현한다
ㄴ. 서로에게 영향을 주는 양방향 관계의 경우 화살표를 생략하고 실선으로만 연결한다
ㄷ. 연관에 참여하는 객체의 개수를 의미하는 다중도(Multiplicity)를 선 위에 표기한다
- 집합(Aggregation) 관계
: 하나의 사물이 다른 사물에 포함되어 있는 관계를 표현
ㄱ. 포함하는 쪽(전체, Whole)과 포함되는 쪽(부분, Part)은 서로 독립적이다
ㄴ. 포함되는 쪽(부분, Part)에서 포함하는 쪽(전체, Whole)으로 속이 빈 마름모를 연결하여 표현한다
- 포함(Composition) 관계
: 집합 관계의 특수한 형태로, 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계를 표현
ㄱ. 포함하는 쪽(전체, Whole)과 포함되는 쪽(부분, Part)은 서로 독립될 수 없고 생명주기를 함께한다
ㄴ. 포함되는 쪽(부분, Part)에서 포함하는 쪽(전체, Whole)으로 속이 채워진 마름모를 연결하여 표현한다
- 일반화(Generalization) 관계
: 하나의 사물이 다른 사물에 비해 더 일반적인지 구체적인지를 표현
ㄱ. 예를 들어 사람은 여자와 남자보다 일반적인 개념이고 반대로 여자와 남자는 사람보다 구체적인 개념이다
ㄴ. 보다 일반적인 개념을 상위(부모), 보다 구체적인 개념을 하위(자식)라고 부른다
ㄷ. 구체적(하위)인 사물에서 일반적(상위)인 사물쪽으로 속이 빈 화살표를 연결하여 표현한다
- 의존(Dependency) 관계
: 연관 관계와 같이 사물 사이에 서로 연관은 있으나 필요에 의해 서로에게 영향을 주는 짧은 시간 동안만 연관을
유지하는 관계를 표현
ㄱ. 하나의 사물과 다른 사물이 소유 관계는 아니지만 사물의 변화가 다른 사물에도 영향을 미치는 관계
ㄴ. 일반적으로 한 클래스가 다른 클래스를 오퍼레이션의 매개 변수로 사용하는 경우에 나타나는 관계이다
ㄷ. 영향을 주는 사물(이용자)이 영향을 받는 사물(제공자) 쪽으로 점선 화살표를 연결하여 표현한다
- 실체화(Realization) 관계
: 사물이 할 수 있거나 해야 하는 기능(오퍼레이션, 인터페이스)으로 서로를 그룹화 할 수 있는 관계를 표현
ㄱ. 한 사물이 다른 사물에게 오퍼레이션을 수행하도록 지정하는 의미적 관계이다
ㄴ. 사물에서 기능 쪽으로 속이 빈 점선 화살표를 연결하여 표현한다
3. 다이어그램(Diagram)
- 여러 관점에서 시스템을 가시화한 뷰를 제공함으로써 의사소통에 도움을 준다
- 정적 모델링은 주로 구조적 다이어그램을 사용하며 객체, 속성, 연관관계, 오퍼레이션의 시스템 구조를 나타낸다
- 동적 모델링은 주로 행위 다이어그램을 사용하며 시스템의 내부 동작을 말한다
- 기능적 모델링은 사용자 측면에서 본 시스템 기능이며, UML에서는 Usecase Diagram을 사용한다
- 구조적(Structural) 다이어그램의 종류
- 행위(Behavioral) 다이어그램의 종류
+ 단계 다이어그램(Phase Diagram)은 물리, 화학 등에서 사용하는 다이어그램으로 요구사항 모델링과 관계 없다
- 스테레오 타입
: UML에서 표현하는 기본 기능 외에 추가적인 기능을 표현하기 위해 사용
ㄱ. 길러멧이라고 부르는 겹화살괄호(<<>>) 사이에 표현할 형태를 기술한다
∙주요 UML 다이어그램
1. 유스케이스(UseCase) 다이어그램
: 개발될 시스템과 관련된 외부 요소들, 즉 사용자와 다른 외부 시스템들이 개발될 시스템을 이용해 수행할 수 있는
기능을 사용자의 관점에서 표현
- 외부 요소와 시스템 간의 상호 작용을 확인할 수 있다
- 사용자의 요구사항을 추출하고 분석하기 위한 도구로 사용된다
- 시스템의 범위를 파악할 수 있다
+ 유스케이스 다이어그램의 구성 요소
2. 클래스(Class) 다이어그램
: 시스템을 구성하는 클래스, 클래스의 특성인 속성과 오퍼레이션, 속성과 오퍼레이션에 대한 제약조건, 클래스
사이의 관계를 표현
- 시스템을 구성하는 요소에 대해 이해할 수 있는 구조적 다이어그램이다
- 시스템 구성 요소를 문서화하는 데 사용된다
- 코딩에 필요한 객체의 속성, 함수 등의 정보를 잘 표현하고 있어 시스템을 모델링하는 데 자주 사용된다
+ 클래스 다이어그램의 구성 요소
+ 접근제어자 (속성과 오퍼레이션에 동일하게 적용)
3. 시퀀스(Sequence) 다이어그램
: 시스템이나 객체들이 메시지를 주고 받으며 시간의 흐름에 따라 상호작용하는 과정을 액터, 객체, 메시지 등의
요소를 사용하여 그림으로 표현한 것이다
- 시스템이나 객체들의 상호 작용 과정에서 주고받는 메시지를 표현한다
- 각 동작에 참여하는 시스템이나 객체들의 수행 기간을 확인할 수 있다
- 클래스 내부에 있는 객체들을 기본 단위로 하여 그들의 상호작용을 표현한다
- 기능 모델링에서 작성한 유스케이스 명세서를 하나의 표현 범위로 하지만, 하나의 클래스에 포함된 오퍼레이션을
하나의 범위로 표현하기도 한다
+ 시퀀스 다이어그램의 구성 요소
∎2장 화면 설계
∙사용자 인터페이스
: 사용자와 시스템 간의 상호작용이 원활하게 이뤄지도록 도와주는 장치나 소프트웨어를 의미한다
- 초기의 사용자 인터페이스는 단순히 사용자와 컴퓨터 간의 상호작용에만 국한되었지만 점차 사용자가 수행할
작업을 구체화시키는 기능 위주로 변경되었고, 최근에는 정보 내용을 전달하기 위한 표현 방법으로 변경되었다
- 사용자 인터페이스의 세 가지 분야
ㄱ. 정보 제공과 전달을 위한 물리적 제어에 관한 분야
ㄴ. 콘텐츠의 상세적인 표현과 전체적인 구성에 관한 분야
ㄷ. 모든 사용자가 편리하고 간편하게 사용하도록 하는 기능에 관한 분야
1. 특징
- 사용자의 만족도에 가장 큰 영향을 미치는 중요한 요소로, 소프트웨어 영역 중 변경이 가장 많이 발생한다
- 사용자의 편리성과 가독성을 높임으로써 작업 시간을 단축시키고 업무에 대한 이해도를 높여준다
- 최소한의 노력으로 원하는 결과를 얻을 수 있게 한다
- 사용자 중심으로 설계되어 사용자 중심의 상호 작용이 되도록 한다
- 수행 결과의 오류를 줄이고 발생하는 오류를 쉽게 수정할 수 있어야 한다
- 사용자의 막연한 작업 기능에 대해 구체적인 방법을 제시해 준다
- 정보 제공자와 공급자 간의 매개 역할을 수행한다
- 사용자 인터페이스를 설계하기 위해서는 소프트웨어 아키텍처를 반드시 숙지해야 한다
2. 구분
- CLI(Command Line Interface) : 명령과 출력이 텍스트 형태로 이뤄지는 인터페이스
- GUI(Graphical User Interface) : 아이콘이나 매뉴를 마우스로 선택해 작업을 수행하는 그래픽 환경 인터페이스
- NUI(Natural User Interface) : 사용자의 말이나 행동으로 기기를 조작하는 인터페이스
3. 사용자 인터페이스의 기본 원칙
4. 사용자 인터페이스의 설계 지침
5. 사용자 인터페이스 개발 시스템의 기능
- 사용자의 입력을 검증할 수 있어야 한다
- 에러 처리와 그와 관련된 에러 메시지를 표시할 수 있어야 한다
- 도움과 프롬프트(Prompt)를 제공해야 한다
∙UI 설계 도구
: 사용자의 요구사항에 맞게 UI의 화면 구조나 화면 배치 등을 설계할 때 사용하는 도구로, 종류에는 와이어프레임,
목업, 스토리보드, 프로토타입, 유스케이스 등이 있다
- UI 설계 도구로 작성된 결과물은 사용자의 요구사항이 실제 구현되었을 때 화면은 어떻게 구성되는지, 어떤 방식으로
수행되는지 등을 기획단계에서 미리 보여주기 위한 용도로 사용된다
1. 와이어프레임(Wireframe)
: 기획 단계의 초기에 제작하는 것으로, 페이지에 대한 개략적인 레이아웃이나 UI 요소 등에 대한 뼈대를 설계하는
단계이다
- 와이어프레임을 제작할 때는 각 페이지의 영역 구분, 콘텐츠, 텍스트 배치 등을 화면 단위로 설계한다
- 개발자나 디자이너 등이 레이아웃을 협의하거나 현재 진행 상태 등을 공유하기 위해 와이어프레임을 사용한다
- ex) 손그림, 파워포인트, 키노트, 스케치, 일러스트, 포토샵 등
2. 목업(Mockup)
: 디자인, 사용 방법 설명, 평가 등을 위해 와이어프레임보다 좀 더 실제 화면과 유사하게 만든 정적인 형태의 모형
- 시각적으로만 구성 요소를 배치하는 것으로 실제로 구현되지는 않는다
- ex) 파워 목업, 발사믹 목업 등
3. 스토리보드(Story Board)
: 와이어프레임에 콘텐츠에 대한 설명, 페이지 간 이동 흐름 등을 추가한 문서
- 디자이너와 개발자가 최종적으로 참고하는 작업 지침서로, 정책, 프로세스, 콘텐츠 구성, 와이어프레임, 기능 정의
등 서비스 구축을 위한 모든 정보가 들어 있다
- 스토리보드는 상단이나 우측에는 제목, 작성자 등을 입력하고, 좌측에는 UI화면, 우측에는 디스크립션
(Description)을 기입한다
- 디스크립션(Description)은 화면에 대한 설명, 전반적인 로직, 분기처리, 예외처리 등을 작성하는 부분으로,
명확하고 세부적으로 작성해야 한다
- ex) 파워포인트, 키노트, 스케치, Axure 등
4. 프로토타입(Prototype)
: 와이어프레임이나 스토리보드 등에 인터랙션을 적용함으로써 실제 구현된 것처럼 테스트가 가능한 동적인 형태의
모형이다
- 프로토타입은 사용성 테스트나 작업자 간 서비스 이해를 위해 작성하는 샘플이다
- 프로토타입은 작성 방법에 따라 페이퍼 프로토타입과 디지털 프로토타입으로 나뉜다
- ex) HTML/CSS, Axure, Flinto, 네이버 프로토나우, 카카오 오븐 등
5. 유스케이스(Use Case)
: 사용자 측면에서의 요구사항으로, 사용자가 원하는 목표를 달성하기 위해 수행할 내용을 기술한다
- 사용자의 요구사항을 빠르게 파악함으로써 프로젝트의 초기에 시스템의 기능적인 요구를 결정하고
그 결과를 문서화할 수 있다
- 유스케이스는 자연어로 작성된 사용자의 요구사항을 구조적으로 표현한 것으로, 일반적으로 다이어그램 형식으로
묘사된다
- 유스케이스 다이어그램이 완성되면, 각각의 유스케이스에 대해 유스케이스 명세서를 작성한다
∙품질 요구사항
: 소프트웨어의 품질은 소프트웨어의 기능, 성능, 만족도 등 소프트웨어에 대한 요구사항이 얼마나 충족하는가를
나타내는 소프트웨어 특성의 총체이다
- 사용자의 요구사항을 충족시킴으로써 확립된다
1. 기능성(Functionality)
: 소프트웨어가 사용자의 요구사항을 정확하게 만족하는 기능을 제공하는지 여부를 나타낸다
2. 신뢰성(Reliability)
: 소프트웨어가 요구된 기능을 정확하고 일관되게 오류 없이 수행할 수 있는 정도를 나타낸다
3. 사용성(Usability)
: 사용자와 컴퓨터 사이에 발생하는 어떠한 행위에 대하여 사용자가 쉽게 배우고 사용할 수 있으며, 향후 다시
사용하고 싶은 정도를 나타낸다
4. 효율성(Efficiency)
: 사용자가 요구하는 기능을 할당된 시간 동안 한정된 자원으로 얼마나 빨리 처리할 수 있는지 정도를 나타낸다
5. 유지 보수성(Maintainability)
: 환경의 변화 또는 새로운 요구사항이 발생했을 때 소프트웨어를 개선하거나 확장할 수 있는 정도를 나타낸다
6. 이식성(Portability)
: 소프트웨어가 다른 환경에서도 얼마나 쉽게 적용할 수 있는지 정도를 나타낸다
+ 소프트웨어 품질 측정을 위해 개발자 관점에서 고려해야 할 항목
- 정확성, 신뢰성, 효율성, 무결성, 유연성, 이식성, 사용성, 상호운용성
∎3장 애플리케이션 설계
∙소프트웨어 아키텍처
: 소프트웨어의 골격이 되는 기본 구조이자, 소프트웨어를 구성하는 요소들 간의 관계를 표현하는 시스템의 구조
또는 구조체이다.
- 소프트웨어 개발 시 적용되는 원칙과 지침이며, 이해 관계자들의 의사소통 도구로 활용하고 품질 요구사항을
반영하여 품질 속성을 결정한다
- 소프트웨어 아키텍처의 설계는 기본적으로 좋은 품질을 유지하면서 사용자의 비기능적 요구사항으로 나타난 제약을
반영하고, 기능적 요구사항을 구현하는 방법을 찾는 해결 과정이다
- 데이터 중심 아키텍처는 공유 데이터저장소를 통해 접근자 간의 통신이 이루어지므로 각 접근자의 수정과 확장이
용이하다
- 애플리케이션의 분할 방법과 분할된 모듈에 할당될 기능, 모듈 간의 인터페이스 등을 결정한다
- 소프트웨어 아키텍처 설계의 기본 원리로는 모듈화, 추상화, 단계적 분해, 정보은닉이 있다
*상위 설계와 하위 설계
| 상위 설계 | 하위 설계 | |
| 별칭 | 아키텍처 설계, 예비 설계 | 모듈 설계, 상세 설계 |
| 설계 대상 | 시스템의 전체적인 구조 | 시스템의 내부 구조 및 행위 |
| 세부 목록 | 구조, DB, 인터페이스 | 컴포넌트, 자료 구조, 알고리즘 |
+ 아키텍처 설계과정
㉮ 설계 목표 설정
㉯ 시스템 타입 결정
㉰ 스타일 적용 및 커스터마이즈
㉱ 서브시스템의 기능, 인터페이스 동작 작성
㉲ 아키텍처 설계 검토
1. 모듈화(Modularity)
: 소프트웨어의 성능을 향상시키거나 시스템의 수정 및 재사용, 유지 관리 등이 용이하도록 시스템의 기능들을 모듈
단위로 나누는 것을 의미한다
- 자주 사용되는 계산식이나 사용자 인증과 같은 기능들을 공통 모듈로 구성하여 프로젝트의 재사용성을
향상시킬 수 있다
- 모듈의 크기를 너무 작게 나누면 개수가 많아져 모듈 간의 통합 비용이 많이 들고, 너무 크게 나누면 개수가 적어
통합 비용은 적게 들지만 모듈 하나의 개발 비용이 많이 든다
- 소프트웨어의 모듈은 프로그래밍 언어에서 Subroutine, Function 등으로 표현될 수 있다
- 모듈의 수가 증가하면 상대적으로 각 모듈의 크기가 작아지며, 감소하면 상대적으로 각 모듈의 크기가 커진다
- 시스템을 지능적으로 관리할 수 있도록 해주며, 복잡도 문제를 해결하는데 도움을 준다
2. 추상화(Abstraction)
: 문제의 전체적이고 포괄적인 개념을 설계한 후 차례로 세분화하여 구체화시켜 나가는 것이다
- 인간이 복잡한 문제를 다룰 때 가장 기본적으로 사용하는 방법으로, 완전한 시스템을 구축하기 전에 그 시스템과
유사한 모델을 만들어서 여러 가지 요인들을 테스트할 수 있다
- 추상화는 최소의 비용으로 실제 상황에 대처할 수 있고, 시스템의 구조 및 구성을 대략적으로 파악할 수 있게
해준다
3. 단계적 분해(Stepwise Refinement)
: Niklaus Wirth에 의해 제안된 하향식 설계 전략으로, 문제를 상위의 중요 개념으로부터 하위의 개념으로
구체화시키는 분할 기법이다
- 추상화의 반복에 의해 세분화된다
- 소프트웨어의 기능에서부터 시작하여 점차적으로 구체화하고, 알고리즘, 자료 구조 등 상세한 내역은 가능한
한 뒤로 미루어 진행한다
4. 정보 은닉(Information Hiding)
: 한 모듈 내부에 포함된 절차와 자료들의 정보가 감추어져 다른 모듈이 접근하거나 변경하지 못하도록 하는
기법이다
- 어떤 모듈이 소프트웨어 기능을 수행하는데 반드시 필요한 기능이 있어 정보 은닉된 모듈과 커뮤니케이션 할
필요가 있을 때 필요한 정보만 인터페이스를 통해 주고 받는다
- 정보 은닉을 통해 모듈을 독립적으로 수행할 수 있고, 하나의 모듈이 변경되더라도 다른 모듈에 영향을 주지
않으므로 수정, 시험, 유지보수가 용이하다
5. 소프트웨어 아키텍처의 품질 속성
: 소프트웨어 아키텍처가 이해 관계자들이 요구하는 수준의 품질을 유지 및 보장할 수 있게 설계되었는지를
확인하기 위해 품질 평가 요소들을 시스템 측면, 비즈니스 측면, 아키텍처 측면으로 구분하여 구체화시켜 놓은
것이다
- 시스템 측면
- 비즈니스 측면
- 아키텍처 측면
6. 소프트웨어 아키텍처의 설계 과정
- 설계 목표 설정 : 시스템의 개발 방향을 명확히 하기 위해 설계에 영향을 주는 비즈니스 목표, 우선순위 등의
요구사항을 분석하여 전체 시스템의 설계 목표를 설정한다
- 시스템 타입 결정 : 시스템과 서브시스템의 타입을 결정하고, 설계 목표와 함께 고려하여 아키텍처 패턴을
선택한다
- 아키텍처 패턴 적용 : 아키텍처 패턴을 참조하여 시스템의 표준 아키텍처를 설계한다
- 서브시스템 구체화 : 서브시스템의 기능 및 서브시스템 간의 상호작용을 위한 동작과 인터페이스를 정의한다
- 검토 : 아키텍처가 설계 목표에 부합하는지, 요구사항이 잘 반영되었는지, 설계의 기본 원리를 만족하는지 등을
검토한다
| *협약에 의한 설계 : 컴포넌트를 설계할 때 클래스에 대한 여러 가정을 공유할 수 있도록 명세한 것으로, 소프트웨어 컴포넌트에 대한 정확한 인터페이스를 명세한다 - 선행 조건(Precondition) : 오퍼레이션이 호출되기 전에 참이 되어야 할 조건 - 결과 조건(Postcondition) : 오퍼레이션이 수행된 후 만족되어야 할 조건 - 불변 조건(Invariant) : 오퍼레이션이 실행되는 동안 항상 만족되어야 할 조건 |
∙아키텍처 패턴(=아키텍처 스타일, =표준 아키텍처)
: 아키텍처를 설계할 때 참조할 수 있는 전형적인 해결 방식 또는 예제를 의미한다
- 소프트웨어 시스템의 구조를 구성하기 위한 기본적인 윤곽을 제시한다
- 아키텍처 패턴에는 서브시스템들과 그 역할이 정의되어 있으며, 서브시스템 사이의 관계와 여러 규칙·지침 등이
포함되어 있다
1. 장점
ㄱ. 시행착오를 줄여 개발 시간을 단축시키고, 고품질의 소프트웨어를 생산할 수 있다
ㄴ. 검증된 구조로 개발하기 때문에 안정적인 개발이 가능하다
ㄷ. 이해관계자들이 공통된 아키텍처를 공유할 수 있어 의사소통이 간편해진다
ㄹ. 시스템의 구조를 이해하는 것이 쉬워 개발에 참여하지 않은 사람도 손쉽게 유지보수를 수행할 수 있다
ㅁ. 시스템의 특성을 개발 전에 예측하는 것이 가능해진다
2. 레이어 패턴(Layers Pattern)
: 시스템을 계층(Layer)으로 구분하여 구성하는 고전적인 방법 중의 하나다
- 각각의 서브시스템들이 계층 구조를 이루며, 상위 계층은 하위 계층에 대한 서비스 제공자가 되고, 하위 계층은
상위 계층의 클라이언트가 된다
- 서로 마주보는 두 개의 계층 사이에서만 상호작용이 이루어지며, 변경 사항을 적용할 때도 서로 마주보는
두 개의 계층에만 영향을 미치므로 변경 작업이 용이하다
- 특정 계층만을 교체해 시스템을 개선하는 것이 가능하다
- 대표적으로 OSI 참조 모델이 있다
3. 클라이언트-서버 패턴(Client-Server Pattern)
: 하나의 서버 컴포넌트와 다수의 클라이언트 컴포넌트로 구성되는 패턴이다
- 클라이언트-서버 패턴엥서 사용자는 클라이언트와만 의사소통을 한다. 즉 사용자가 클라이언트를 통해 서버에
요청하고 클라이언트가 응답을 받아 사용자에게 제공하는 방식으로 서비스를 제공한다
- 서버는 클라이언트의 요청에 대비해 항상 대기 상태를 유지해야 한다
- 클라이언트나 서버는 요청과 응답을 받기 위해 동기화되는 경우를 제외하고는 서로 독립적이다
4. 파이프-필터 패턴(Pipe-Filter Pattern)
: 서브시스템이 입력 데이터를 받아 처리하고 결과를 다른 시스템(다른 서브시스템)에 보내는 작업이 반복되며,
데이터 스트림 절차의 각 단계를 필터(Filter) 컴포넌트로 캡슐화하여 파이프(Pipe)를 통해 단방향으로 데이터를
전송하는 패턴이다
- 필터 컴포넌트는 재사용성이 좋고, 추가가 쉬워 확장이 용이하다
- 필터 컴포넌트들을 재배치하여 다양한 파이프라인을 구축하는 것이 가능하다
- 파이프-필터 패턴은 데이터 변환, 버퍼링, 동기화 등에 주로 사용된다
- 필터 간 데이터 이동 시 데이터 변환으로 인한 오버헤드가 발생한다
- 대표적으로 UNIX의 쉘(Shell)이 있다
5. 모델-뷰-컨트롤러 패턴(Model-View-Controller Pattern)
: 서브시스템을 3개의 부분으로 구조화하는 패턴이며, 각 부분의 역할은 다음과 같다
- 각 부분은 별도의 컴포넌트로 분리되어 있으므로 서로 영향을 받지 않고 개발 작업을 수행할 수 있다
- 여러 개의 뷰를 만들 수 있으므로 한 개의 모델에 대해 여러 개의 뷰를 필요로 하는 대화형 애플리케이션에
적합하다
6. 기타 패턴
∙객체지향(Object-Oriented)
: 현실 세계의 개체(Entity)를 기계의 부품처럼 하나의 객체(Object)로 만들어, 기계적인 부품들을 조립하여
제품을 만들 듯이 소프트웨어를 개발할 때에도 객체들을 조립해서 작성할 수 있는 기법을 말한다
- 구조적 기법의 문제점으로 인한 소프트웨어 위기의 해결책으로 채택되어 사용되고 있다
- 소프트웨어의 재사용 및 확장이 용이하여 고품질의 소프트웨어를 빠르게 개발할 수 있고 유지보수가 쉽다
- 복잡한 구조를 단계적·계층적으로 표현하고, 멀티미디어 데이터 및 병렬 처리를 지원한다
- 현실 세계를 모형화하므로 사용자와 개발자가 쉽게 이해할 수 있다
- 주요 구성 요소와 개념 : 객체(Object), 클래스(Class), 캡슐화(Encapsulation), 상속(Inheritance),
다형성(Polymorphism), 연관성(Relationship)
1. 객체 (Object)
: 데이터와 데이터를 처리하는 함수를 묶어 놓은(캡슐화한) 하나의 소프트웨어 모듈이다
- 객체의 메소드는 다른 객체로부터 메시지를 받았을 때 정해진 기능을 수행한다
- 객체의 특성
ㄱ. 독립적으로 식별 가능한 이름을 가지고 있다
ㄴ. 객체가 가질 수 있는 조건을 상태(State)라고 하는데, 일반적으로 상태는 시간에 따라 변한다
ㄷ. 객체와 객체는 상호 연관성에 의한 관계가 형성된다
ㄹ. 객체가 반응할 수 있는 메시지의 집합을 행위라고 하며, 객체는 행위의 특징을 나타낼 수 있다
ㅁ. 일정한 기억장소를 가지고 있다
2. 클래스 (Class)
: 공통된 속성과 연산(행위)을 갖는 객체의 집합으로, 객체의 일반적인 타입(Type)을 의미한다
- 클래스는 각각의 객체들이 갖는 속성과 연산을 정의하고 있는 틀이다
- 객체지향 프로그램에서 데이터를 추상화하는 단위이다
- 클래스에 속한 각각의 객체를 인스턴스(Instance)라 하며, 클래스로부터 새로운 객체를 생성하는 것을
인스턴스화(Instantiation)라고 한다
- 동일 클래스에 속한 각각의 객체(인스턴스)들은 공통된 속성과 행위를 가지고 있으면서,
그 속성에 대한 정보가 서로 달라서 동일 기능을 하는 여러 가지 객체를 나타내게 된다
- 최상위 클래스는 상위 클래스를 갖지 않는 클래스를 의미한다
- 슈퍼 클래스(Super Class)는 특정 클래스의 상위(부모) 클래스이고, 서브 클래스(Sub Class)는 특정 클래스의
하위(자식) 클래스를 의미한다
3. 캡슐화 (Encapsulation)
: 데이터(속성)와 데이터를 처리하는 함수를 하나로 묶어 외부와 경계를 만들고 필요한 인터페이스만을 밖으로
드러내는 것을 의미한다
- 캡슐화된 객체는 인터페이스를 제외한 세부 내용이 은폐(정보 은닉)되어 외부에서의 접근이 제한적이기 때문에
외부 모듈의 변경으로 인한 파급 효과가 적다
- 캡슐화된 객체들은 재사용이 용이하다
- 객체들 간의 메시지를 주고받을 때 상대 객체의 세부 내용은 알 필요가 없으므로 인터페이스가 단순해지고,
객체 간의 결합도가 낮아진다
4. 상속 (Inheritance)
: 이미 정의된 상위 클래스(부모 클래스)의 모든 속성과 연산을 하위 클래스(자식 클래스)가 물려받는 것이다
- 상속을 이용하면 하위 클래스는 상위 클래스의 모든 속성과 연산을 자신의 클래스 내에서 다시 정의하지 않고서도
즉시 자신의 속성으로 사용할 수 있다
- 하위 클래스는 상위 클래스로부터 상속받은 속성과 연산 외에 새로운 속성과 연산을 첨가하여 사용할 수 있다
- 상위 클래스의 속성과 연산을 하위 클래스가 사용할 수 있기 때문에 객체와 클래스의 재사용,
즉 소프트웨어의 재사용(Reuse)을 높이는 중요한 개념이다
- 다중 상속 : 한 개의 클래스가 두 개 이상의 상위 클래스로부터 속성과 연산을 상속받는 것이다
5. 다형성 (Polymorphism)
: 메시지에 의해 객체(클래스)가 연산을 수행하게 될 때 하나의 메시지에 대해 각각의 객체(클래스)가 가지고 있는
고유한 방법(특성)으로 응답할 수 있는 능력을 의미한다
- 객체(클래스)들은 동일한 메소드명을 사용하며 같은 의미의 응답을 한다
- 응용 프로그램 상에서 하나의 함수나 연산자가 두 개 이상의 서로 다른 클래스의 인스턴스들을 같은 클래스에
속한 인스턴스처럼 수행할 수 있도록 하는 것이다
6. 연관성 (Relationship)
: 두 개 이상의 객체(클래스)들이 상호 참조하는 관계를 말하며 종류는 다음과 같다
∙객체지향 분석(OOA; Object Oriented Analysis) 및 설계
: 사용자의 요구사항을 분석하여 요구된 문제와 관련된 모든 클래스(객체), 이와 연관된 속성과 연산, 그들 간의 관계
등을 정의하여 모델링하는 작업이다
- 소프트웨어를 개발하기 위한 비즈니스(업무)를 객체와 속성, 클래스와 멤버, 전체와 부분 등으로 나누어 분석한다
- 분석가에게 주요한 모델링 구성 요소인 클래스, 객체, 속성, 연산들을 표현해서 문제를 모형화할 수 있게 해준다
- 객체는 클래스로부터 인스턴스화되고, 이 클래스를 식별하는 것이 객체지향 분석의 주요한 목적이다
- 데이터와 행위를 하나로 묶어 객체를 정의내리고 추상화시키는 작업이라 할 수 있다
- 코드 재사용에 의한 프로그램 생산성 향상 및 요구에 따른 시스템의 쉬운 변경이 가능하다
- 하향식 및 상향식 방식 모두 사용할 수 있다
1. 객체지향 분석의 방법론
2. 럼바우(Rumbaugh)의 분석 기법
: 모든 소프트웨어 구성 요소를 그래픽 표기법을 이용하여 모델링하는 기법으로, 객체 모델링 기법
(OMT, Object-Modeling Technique)이라고도 한다
3. 객체지향 설계 원칙
: 시스템 변경이나 확장에 유연한 시스템을 설계하기 위해 지켜야 할 다섯 가지 원칙으로,
다섯 가지 원칙의 앞 글자를 따 SOLID 원칙이라고도 불린다
∙모듈
: 모듈화를 통해 분리된 시스템의 각 기능들로, 서브루틴, 서브시스템, 소프트웨어 내의 프로그램, 작업 단위 등과
같은 의미로 사용된다
- 단독으로 컴파일이 가능하며, 재사용 할 수 있다
- 소프트웨어 구조를 이루며, 다른 것들과 구별될 수 있는 독립적인 기능을 갖는 단위이다
- 하나 또는 몇 개의 논리적인 기능을 수행하기 위한 명령어들의 집합이라고도 할 수 있다
- 서로 모여 하나의 완전한 프로그램으로 만들어질 수 있다
- 모듈의 기능적 독립성은 소프트웨어를 구성하는 각 모듈의 기능이 서로 독립됨을 의미하는 것으로, 모듈이 하나의
기능만을 수행하고 다른 모듈과의 과도한 상호작용을 배제함으로써 이루어진다
- 독립성이 높은 모듈일수록 모듈을 수정하더라도 다른 모듈들에게는 거의 영향을 미치지 않으며, 오류가 발생해도
쉽게 발견하고 해결할 수 있다
- 유일한 이름을 가져야 하지만 다른 모듈에서 접근이 불가능해선 안된다
- 모듈의 독립성은 결합도(Coupling)와 응집도(Cohesion)에 의해 측정되며, 독립성을 높이려면 모듈의 결합도는
약하게, 응집도는 강하게, 모듈의 크기는 작게 만들어야 한다
1. 결합도(Coupling)
: 모듈 간에 상호 의존하는 정도 또는 두 모듈 사이의 연관 관계를 의미한다
- 다양한 결합으로 모듈을 구성할 수 있으나 결합도가 약할수록 품질이 높고, 강할수록 품질이 낮다
- 결합도가 강하면 시스템 구현 및 유지보수 작업이 어렵다
- 오류가 발생했을 때 전파되어 다른 오류의 원인이 되는 파문 효과(Ripple Effect)를 최소화해야 한다
- 인터페이스가 정확히 설정되어 있지 않을 경우 불필요한 인터페이스가 나타나 모듈 사이의 의존도는 높아지고 결합도가 증가
- 모듈들이 변수를 공유하여 사용하게 하거나 제어 정보를 교류하게 함으로써 결합도를 높아지게 해야 한다
- 다른 모듈과 데이터 교류가 필요한 경우 전역변수(Global Variable)보다는 매개변수(Parameter)를 사용하는 것이 결합도를
낮추는데 도움이 된다
2. 응집도(Cohesion)
: 정보 은닉 개념을 확장한 것으로, 명령이나 호출문 등 모듈의 내부 요소들의 서로 관련되어 있는 정도, 즉 모듈이
독립적인 기능으로 정의되어 있는 정도를 의미한다
- 다양한 기준으로 모듈을 구성할 수 있으나 응집도가 강할수록 품질이 높고, 약할수록 품질이 낮다
3. 팬인(Fan-In) / 팬아웃(Fan-Out)
- 팬인은 어떤 모듈을 제어(호출)하는 모듈의 수를 나타낸다
- 팬아웃은 어떤 모듈에 의해 제어(호출)되는 모듈의 수를 나타낸다
- 팬인과 팬아웃을 분석하여 시스템의 복잡도를 알 수 있다
- 팬인이 높다는 것은 재사용 측면에서 설계가 잘 되어있다고 볼 수 있으나, 단일 장애점이 발생할 수 있으므로
중점적인 관리 및 테스트가 필요하다
- 팬아웃이 높은 경우 불필요하게 다른 모듈을 호출하고 있는지 검토하고, 단순화시킬 수 있는지 여부에 대한
검토가 필요하다
- 시스템의 복잡도를 최소화하려면 팬인은 높게, 팬아웃은 낮게 설계해야 한다
∙공통 모듈
: 여러 프로그램에서 공통적으로 사용할 수 있는 모듈을 의미한다
- 자주 사용되는 계산식이나 매번 필요한 사용자 인증과 같은 기능들이 공통 모듈로 구성될 수 있다
- 모듈의 재사용성 확보와 중복 개발 회피를 위해 설계 과정에서 공통 부분을 식별하고 명세를 작성할 필요가 있다
- 공통 모듈을 구현할 때는 다른 개발자들이 해당 기능을 명확히 이해할 수 있도록 다음의 명세 기법을 준수해야한다
1. 재사용(Reuse)
: 비용과 개발 시간을 절약하기 위해 이미 개발된 기능들을 파악하고 재구성하여 새로운 시스템 또는 기능 개발에
사용하기 적합하도록 최적화 시키는 작업이다
- 재사용을 위해서는 누구나 이해할 수 있고 사용이 가능하도록 사용법을 공개해야 한다
- 재사용되는 대상은 외부 모듈과의 결합도는 낮고, 응집도는 높아야 한다
- 재사용 규모에 따른 분류
2. 효과적인 모듈 설계 방안
- 결합도는 줄이고 응집도는 높여서 모듈의 독립성과 재사용성을 높인다
- 모듈의 제어 영역 안에서 그 모듈의 영향 영역을 유지시킨다
- 모듈 간의 접속 관계를 분석하여 복잡도와 중복성을 줄이고 일관성을 유지시킨다
- 모듈의 기능은 예측이 가능해야 하며 지나치게 제한적이어서는 안 된다
- 유지보수가 용이해야 한다
- 모듈 크기는 시스템의 전반적인 기능과 구조를 이해하기 쉬운 크기로 분해하고 적당한 모듈의 크기를 유지한다
- 하나의 입구와 하나의 출구를 갖도록 해야 한다
- 인덱스 번호나 기능 코드들이 전반적인 처리 논리 구조에 예기치 못한 영향을 끼치지 않도록 모듈 인터페이스를
설계해야 한다
- 효과적인 제어를 위해 모듈 간의 계층적 관계를 정의하는 자료가 제시되어야 한다
- 모듈의 기능을 예측할 수 있도록 정의한다
∙코드
: 컴퓨터를 이용하여 자료를 처리하는 과정에서 분류·조합 및 집계를 용이하게 하고, 특정 자료의 추출을 쉽게
하기 위해서 사용하는 기호이다
- 정보를 신속·정확·명료하게 전달할 수 있게 한다
- 일정한 규칙에 따라 작성되며, 정보 처리의 효율과 처리된 정보의 가치에 많은 영향을 미친다
- 일반적인 코드의 예로 주민등록번호, 학번, 전화번호 등이 있다
- 코드의 주요 기능
1. 코드의 종류
2. 코드 부여 체계
: 이름만으로 개체의 용도와 적용 범위를 알 수 있도록 코드를 부여하는 방식을 말한다
- 각 개체에 유일한 코드를 부여하여 개체들의 식별 및 추출을 용이하게 한다
- 코드를 부여하기 전에 각 단위 시스템의 고유한 코드와 개체를 나타내는 코드 등이 정의되어야 한다
- 코드 부여 체계를 담당하는 자는 코드의 자릿수와 구분자, 구조 등을 상세하게 명시해야 한다
∙디자인 패턴
: 각 모듈의 세분화된 역할이나 모듈들 간의 인터페이스와 같은 코드를 작성하는 수준의 세부적인 구현 방안을
설계할 때 자주 발생하는 문제에 대한 일반적이고 반복적인 해결 방법
- 디자인 패턴은 문제 및 배경, 실제 적용된 사례, 재사용이 가능한 샘플 코드 등으로 구성되어 있다
- 한 패턴에 변형을 가하거나 특정 요구사항을 반영하면 유사한 형태의 다른 패턴으로 변화되는 특징이 있다
- 1995년 GoF(Gang of Four)가 처음으로 구체화 및 체계화 하였다
- GoF의 디자인 패턴은 목적으로 구분할 때 생성 패턴 5개, 구조 패턴 7개, 행위 패턴 11개로 구성
1. 디자인 패턴 사용의 장, 단점
- 범용적인 코딩 스타일로 인해 구조 파악이 용이하다
- 객체지향 설계 및 구현의 생산성을 높이는데 적합하다
- 검증된 구조의 재사용을 통해 개발 시간과 비용이 절약되고 코드의 품질을 향상시킬 수 있다
- 초기 투자 비용이 부담될 수 있다
- 개발자 간의 원활한 의사소통이 가능하다
- 설계 변경 요청에 대한 유연한 대처가 가능하다
- 객체지향을 기반으로 한 설계와 구현을 다루므로 다른 기반(절차지향)의 애플리케이션 개발에는 적합하지 않다
2. 생성 패턴(Creational Pattern)
: 객체의 생성과 참조 과정을 캡슐화하여 객체가 생성되거나 변경되어도 프로그램의 구조에 영향을 크제 받지
않도록 하여 프로그램에 유연성을 더해준다
3. 구조 패턴(Structural Pattern)
: 클래스나 객체들을 조합하여 더 큰 구조로 만들 수 있게 해주는 패턴으로 구조가 복잡한 시스템을 개발하기
쉽게 도와준다
4. 행위 패턴(Behavioral Pattern)
: 클래스나 객체들이 서로 상호작용하는 방법이나 책임 분배 방법을 정의하는 패턴으로 하나의 객체로 수행할 수
없는 작업을 여러 객체로 분배하면서 결합도를 최소화 할 수 있도록 도와준다
∎4장 인터페이스 설계
∙인터페이스 요구사항 검증
: 인터페이스의 설계 및 구현 전에 사용자들의 요구사항이 요구사항 명세서에 정확하고 완전하게 기술되었는지
검토하고 개발 범위의 기준인 베이스라인을 설정하는 것이다
- 인터페이스의 설계 및 구현 중에 요구사항 명세서의 오류가 발견되어 이를 수정할 경우 많은 비용이 소모되므로
프로젝트에서 요구사항 검증은 매우 중요하다
- 순서 : 요구사항 검토 계획 수립 → 검토 및 오류 수정 → 베이스라인 설정
1. 인터페이스 요구사항 검토 계획 수립
: 프로젝트 이해관계자들이 프로젝트 품질 관리 계획을 참조하여 다음과 같이 인터페이스 요구사항 검토 계획을
수립한다
- 검토 계획이 수립되면 인터페이스 요구사항 검토 참여자들에게 검토 관련 자료와 일정 등을 전달한다
2. 인터페이스 요구사항 검토 및 오류 수정
: 인터페이스 요구사항 검토는 검토 체크리스트의 항목에 따라 인터페이스 요구사항 명세서를 검토하는 것이다
- 요구사항 검토 시 오류가 발견되면 오류를 수정할 수 있도록 오류 목록과 시정 조치서를 작성한다
- 오류 수정과 요구사항 승인 절차를 진행할 수 있도록 요구사항 검토 결과를 검토 관련자들에게 전달한다
- 시정 조치서를 작성한 경우 시정 조치가 완료되었는지 확인하여 시정 조치가 완료되면 인터페이스 요구사항
검토 작업을 완료한다
3. 인터페이스 요구사항 베이스라인 설정
: 인터페이스 요구사항 검토를 통해 검증된 인터페이스 요구사항은 프로젝트 관리자와 주요 의사 결정자에게
공식적으로 승인 받는다
4. 요구사항 검증 방법
- 요구사항 검토(Requirements Review)
: 요구사항 명세서의 오류 확인 및 표준 준수 여부 등의 결함 여부를 검토 담당자들이 수작업으로 분석하는 방법
- 정형 기술 검토(FTR)
+ 정형 기술 검토의 지침
ㄱ. 제품 검토의 집중성 : 오류 검출에 초점을 두고 해결책을 나중으로 미룸
ㄴ. 사전 준비성 : 검토를 우한 자료를 사전에 배포하여 검토하도록 한다
ㄷ. 의제의 제한성 : 의견을 제한하되 충분히 받아들인다
ㄹ. 안건 고수성 : 안건을 세우면 고수한다
ㅁ. 논쟁 반박의 제한성 : 논쟁과 반박을 제한한다
ㅂ. 문제 공개성 : 문제 영역을 공개한다
ㅅ. 참가 인원의 제한성 : 참가자의 수를 제한한다
ㅇ. 문서성 : 발견된 오류는 문서화한다
- 프로토타이핑(Prototyping)
: 사용자의 요구사항을 정확히 파악하기 위해 실제 개발될 소프트웨어에 대한 견본품(Prototype)을 만들어 최종
결과물을 예측한다
- 테스트 설계
: 요구사항은 테스트할 수 있도록 작성되어야 하며, 이를 위해 테스트 케이스(Test Case)를 생성하여 이후에
요구사항이 현실적으로 테스트 가능한지를 검토한다
- CASE(Computer Aided Software Engineering) 도구 활용
: 일관성 분석(Consistency Analysis)을 통해 요구사항 변경사항의 추적 및 분석, 관리하고, 표준 준수 여부를
확인한다
5. 인터페이스 요구사항 검증의 주요 항목
∙인터페이스 방법 명세화
: 내·외부 시스템이 연계하여 작동할 때 인터페이스별 송·수신 방법, 송·수신 데이터, 오류 식별 및 처리 방안에 대한
내용을 문서로 명확하게 정리하는 것이다
- 인터페이스별로 송·수신 방법을 명세화하기 위해서는 시스템 연계 기술, 인터페이스 통신 유형, 처리 유형,
발생 주기 등에 대한 정보가 필요하다
1. 시스템 연계 기술
: 개발할 시스템과 내·외부 시스템을 연계할 때 사용되는 기술을 의미한다
2. 인터페이스 통신 유형
: 개발할 시스템과 내·외부 시스템 간 데이터를 송·수신하는 형태를 의미한다
- 단방향 : 시스템에서 거래를 요청만하고 응답이 없는 방식이다
- 동기 : 시스템에서 거래를 요청하고 응답이 올 때까지 대기(Request-Reply)하는 방식이다
- 비동기 : 시스템에서 거래를 요청하고 다른 작업을 수행하다 응답이 오면 처리하는 방식
(Send-Receive, Send-Receive-Acknowledge, Publish-Subscribe)이다.
3. 인터페이스 처리 유형
: 송·수신 데이터를 어떤 형태로 처리할 것인지에 대한 방식을 의미한다
- 실시간 방식 : 사용자가 요청한 내용을 바로 처리해야 할 때 사용하는 방식이다
- 지연 처리 방식 : 데이터를 매건 단위로 처리할 경우 비용이 많이 발생할 때 사용하는 방식이다
- 배치 방식 : 대량의 데이터를 처리할 때 사용하는 방식이다
4. 인터페이스 발생 주기
: 개발할 시스템과 내·외부 시스템 간 송·수신 데이터가 전송되어 인터페이스가 사용되는 주기를 의미한다
- 인터페이스 발생 주기는 업무의 성격과 송·수신 데이터 전송량을 고려하여 매일, 수시, 주 1회 등으로 구분한다
5. 송·수신 방법 명세화
: 내·외부 인터페이스 목록에 있는 각각의 인터페이스에 대해 연계 방식, 통신 및 처리 유형, 발생 주기 등의
송·수신 방법을 정의하고 명세를 작성하는 것이다
- 연계 방식, 통신 유형, 연계 처리 형태는 시스템 인터페이스 설계 시 작성한 아키텍처 정의서를 기반으로 하여
업무 및 데이터의 성격, 연계 데이터 발생 건수, 연계 시스템의 기술 구조, 시스템 간의 성능 등을 고려하여
작성한다
6. 송·수신 데이터 명세화
: 내·외부 인터페이스 목록에 있는 각각의 인터페이스에 대해 인터페이스 시 필요한 송·수신 데이터에 대한 명세를
작성하는 것이다
- 인터페이스별로 테이블 정의서와 파일 레이아웃에서 연계하고자 하는 테이블 또는 파일 단위로 송·수신 데이터에
대한 명세를 작성한다
7. 오류 식별 및 처리 방안 명세화
: 내·외부 인터페이스 목록에 있는 각각의 인터페이스에 대해 인터페이스 시 발생할 수 있는 오류를 식별하고
오류 처리 방안에 대한 명세서를 작성하는 것이다
- 시스템 및 전송 오류, 연계 프로그램 등에서 정의한 예외 상황 등 대·내외 시스템 연계 시 발생할 수 있는 다양한
오류 상황을 식별하고 분류한다
- 오류 상황에 대해 오류 코드, 오류 메시지, 오류 설명, 해결 방법 등을 명세화한다
+ 연계 메커니즘 구성요소
ㄱ. 송신 시스템 : 연계 프로그램으로부터 생성된 데이터를 전송 형식에 맞게 연계 테이블 또는 파일 형태로
생성하여 송신한다
ㄴ. 수신 시스템 : 수신한 연계 테이블이나 파일을 연계 프로그램에서 처리할 수 있는 형식으로 변환한 후 연계
프로그램에 반영하는 시스템
ㄷ. 연계 서버 : 송·수신 시스템 사이에 위치하여 데이터의 송·수신 현황을 모니터링하는 역할
∙미들웨어(Middle + Sofawar) 솔루션 명세
- 분산 컴퓨팅 환경에서 서로 다른 기종 간의 하드웨어나 프로토콜, 통신 환경 등을 연결하여 운영체제와 응용 프로그램,
또는 서버와 클라이언트 사이에서 원만한 통신이 이루어지도록 다양한 서비스를 제공한다
- 표준화된 인터페이스를 제공함으로써 시스템 간의 데이터 교환에 일관성을 보장한다
- 여러 환경 간의 분산 시스템에서 다양한 부분을 관리하고 통신하며 데이터를 교환하게 해주는 소프트웨어이다.
- 위치 투명성(Location Transparency)을 제공한다
- 종류 : DB, RPC, MOM, TP-Monitor, ORB, WAS 등
1. DB(DataBase)
: 데이터베이스 벤더에서 제공하는 클라이언트에서 원격의 데이터베이스와 연결하기 위한 미들웨어이다
- DB를 사용하여 시스템을 구축하는 경우 보통 2-Tier 아키텍처라고 한다
- 대표적인 DB의 종류에는 마이크로소프트의 ODBC, 볼랜드의 IDAPI, 오라클의 Glue 등이 있다
2. RPC(Remote Procedure Call)
: RPC(원격 프로시저 호출)는 응용 프로그램의 프로시저를 사용하여 원격 프로시저를 마치 로컬 프로시저처럼
호출하는 방식의 미들웨어이다
- 종류 : 이큐브시스템스의 Entera, OSF의 ONC/RPC 등이 있다
3. MOM(Message Oriented Middleware)
: MOM(메시지 지향 미들웨어)은 메시지 기반의 비동기형 메시지를 전달하는 방식의 미들웨어이다
- 온라인 업무보다는 이기종 분산 데이터 시스템의 데이터 동기를 위해 많이 사용된다
- 종류 : IBM의 MQ, 오라클의 Message Q, JCP의 JMS 등이 있다
4. TP-Monitor(Transaction Processing Monitor)
: TP-Monitor(트랜잭션 처리 모니터)는 항공기나 철도 예약 업무 등과 같은 온라인 트랜잭션 업무에서 트랜잭션을
처리 및 감시하는 미들웨어이다
- 사용자 수가 증가해도 빠른 응답 속도를 유지해야 하는 업무에 주로 사용된다
- 종류 : 오라클의 tuxedo, 티맥스소프트의 tmax 등이 있다
5. ORB(Object Request Broker)
: ORB(객체 요청 브로커)는 객체 지향 미들웨어로 코바(CORBA) 표준 스펙을 구현한 미들웨어이다
- 최근에는 TP-Monitor의 장점인 트랜잭션 처리와 모니터링 등을 추가로 구현한 제품도 있다
- 종류 : Micro Focus의 Orbix, OMG의 CORBA 등이 있다
6. WAS(Web Application Server)
: WAS(웹 어플리케이션 서버)는 정적인 콘텐츠를 처리하는 웹 서버와 달리 사용자의 요구에 따라 변하는 동적인
콘텐츠를 처리하기 위해 사용되는 미들웨어이다
- 클라이언트/서버 환경보다는 웹 환경을 구현하기 위한 미들웨어이다
- HTTP 세션 처리를 위한 웹 서버 기능뿐만 아니라 미션-크리티컬한 기업 업무까지 JAVA, EJB 컴포넌트 기반으로
구현이 가능하다
- 요구사항 식별 시 고려사항 : 가용성, 성능, 기술 지원, 구축 비용
- 종류 : 오라클의 WebLogic, IBM의 WebSphere, JEUS, Tomcat 등이 있다
7. 미들웨어 솔루션 식별
: 개발 및 운영 환경에 사용될 미들웨어 솔루션을 확인하고 목록을 작성하는 것이다
- 소프트웨어 아키텍처에서 정의한 아키텍처 구성 정보와 프로젝트에서 구매가 진행 중이거나 구매 에정인
소프트웨어 내역을 확인하여 개발 및 운영 환경에서 사용될 미들웨어 솔루션을 식별한다
- 식별한 미들웨어 솔루션들에 대해 솔루션의 시스템, 구분, 솔루션명, 버전, 제조사 등의 정보를 정리한 미들웨어
솔루션 목록을 작성한다
- 작성된 미들웨어 솔루션 목록은 이해관계자 등에게 전달하여 오류 및 누락을 확인하고 수정한다
8. 미들웨어 솔루션 명세서 작성
: 미들웨어 솔루션 목록의 미들웨어 솔루션별로 관련 정보들을 상세하게 기술하는 것이다
- 미들웨어 솔루션 제품 명칭 및 버전, 제품 사용 목적 등을 솔루션에 대한 제품안내서 및 설명 자료 등을 통해
검토한다
- 미들웨어 솔루션 제품에 대한 사용 환경과 특징 등을 솔루션 설명 자료나 관련 담당자를 통해 검토한다
- 미들웨어 솔루션이 지원하는 시스템 범위와 정상적인 서비스 제공을 위한 환경 구성, 제공 기능 등에 대한
제약사항이 존재하는지 제품안내서 및 기술 지원 담당자를 통해 검토한다
- 미들웨어 솔루션에 대한 상세 정보 및 제공 기능, 특징, 시스템 구성 환경 등에 대한 제약사항을 정리하여
솔루션에 대한 명세서를 작성한다
∎ 기타
'📃 Certification > 정보처리기사' 카테고리의 다른 글
| [정보처리기사 필기] 합격수기 (0) | 2022.04.25 |
|---|---|
| [정보처리기사 필기] 5과목 정보시스템 구축 관리 (0) | 2022.04.17 |
| [정보처리기사 필기] 4과목 프로그래밍 언어 활용 (0) | 2022.04.10 |
| [정보처리기사 필기] 3과목 데이터베이스 구축 (0) | 2022.04.08 |
| [정보처리기사 필기] 2과목 소프트웨어 개발 (0) | 2022.04.06 |