cjmyun.tripod.comcjmyun.tripod.com/knowledgebase/omt.doc · web view시스템설계(system...

Cho, Joonmyun 23-5-16

객체지향 시스템 개발 방법론

개요

객체지향 개발 방법론이란절차 및 산출물객체지향 개발 방법론의 특징 및 효과

분석

요구사항 수집요구사항 분석객체 모델링(OBJECT MODELING)모델 상세화 및 통합

시스템 설계

가이드라인(GUIDELINES)

1/20


개요

객체지향 개발 방법론이란 인간은 복잡하고 거대한 실 세계를 이해하기 위해 추상화를 이용

실 세계는 다양한 측면을 가지고 있는데 모든 면들을 한번에 완벽하게 이해할 수 는 없음

⇒ 추상화

객체 지향 모델링 기술(Object Modeling Technique)은 이러한 인간의 사고방식을 모방한 것

대상을 독립된 객체들의 집합으로 모델링하고, 목적하는 태스크(Task)를 이들 객체간의 상호 작용에 의해 수행되도록 설계

객체와 그들 간의 정적인 관계를 모델링 골격(Framework)하여 시간의 흐름에 따른 상호 작용 특성, 데이터의 프로세스 특성이 모델링 된다.

아래의 <그림>은 객체지향 개발 단계를 폭포수 모델에 비추어 정리한 것

Top-down 방식으로 계속 반복 과정을 통해 내용을 상세

각 단계를 수행하면서 작성된 산출물이 그대로 다음단계에서 사용되며, 유지보수 단계에서도 수정/정리 등의 별도 작업 없이 효과적으로 쓰임

<그림. °´Ã¼ÁöÇâ °³¹ß ´Ü°è>

절차 및 산출물

2/20


분석단계(Analysis) 분석 단계에서는 대상을 추상화(Abstraction) 시켜 인간(개발자)이 이해하고 사고할 수 있는 모델을 만드는 단계

세가지 측면에서 추상화 시켜 모델을 작성

① 객체모델(Object Model): 대상 시스템의 정적 구조(static structure)와 데이터 측면을 기술한다. 한 시스템 내의 객체와 객체들 간의 관계(relationship)들 이용하여 정적구조를 모델링하고, 그 객체들을 특성을 결정 지워 주는 속성(attributes)과 오퍼레이션(operations)들을 보임으로써 그 시스템의 데이터 측면을 기술하게 된다. 객체 모델은 동적 모델과 기능 모델을 작성하는 골격(framework)을 제공한다. 객체 모델은 정의된 표기법에 의해 작성되는 다이아그램과 객체 명세서와 같은 부가적인 도큐먼트로 구성된다.

② 동적모델(Dynamic Model): 시간에 관련된 시스템의 양상(aspect)을 나타내 주는 모델이다. 즉, 언제, 어떤 순서로 작업이 수행되는가 하는 측면을 모델링 한다. 동적모델링의 가장 중요한 개념은 사건(event)와 상태(state)이다. 사건은 외부적인 자극을 나타내며 상태는 객체들의 값들을 나타내는 것이라고 할 수 있다. 동적모델은 시스템의 컨트롤을 주요 모델링 대상으로 한다. 여기서 컨트롤(control)은 외부 자극에 대해 발생되는 연산들의 순서를 기술한 시스템 양상이다. 동적모델은 표기법에 의거해 작성되는 세 종류의 다이아그램(이벤트 흐름도, 이벤트 추적도, 상태 전이도)과 부가적인 도큐먼트로 구성된다.

③ 기능모델(Functional Model): “시스템이 무엇을 하는가? 정보(데이터)가 어떻게 가공되는가?”에 대한 모델이다. 즉, 입력값으로부터 프로세스를 거쳐 어떤 결과가 나타나는지를 보여준다. 그러나 이것이 어떻게(How to) 유도되었는지의 구현 방법은 고려하지 않는다. 함수모델은 다수의 데이터흐름도(Data Flow Diagram)와 DFD 명세서 같은 부가적인 도큐먼트로 구성된다.

※ 세 모델은 객체 모델을 골격으로 서로 보완적인 관계를 맺고 있음.

※ 분석이 진행되면서 객체모델을 중심으로 통합되어 최종 설계 산출물을 작성하게 됨.

시스템설계(System Design) 단계 대상 시스템을 서브시스템으로 나누어 구성

데이터 저장(Data Storage) 전략, 컨트롤 플로우 구현 전략, 프로세스간 통신 전략, 서브시스템에 태스크 할당, 경계 조건(Boundary Condition), Networking 등의 시스템 제반 사항을 결정

객체설계(Object Design) 단계 분석단계에서는 무엇(What)을 구현해야 하는지 정하고, 시스템 설계단계에서는 분석단계에서 결정한 무엇을 구현하는데 있어 어떻게(How) 공략할 것인가 하는 전략을 결정하였다.

이 단계에서부터 컴퓨터 영역으로 관점을 전환하여 실제 구현(implementation)시 필요한 수준으로 객체 클래스와 관계(Association)들을 완벽하게 정의

모든 속성과 메소드가 명세 되었으면 개발툴을 이용하여 실제 코딩(coding)하기 위한 수준의 모든 사항을 명세

예: 설계 시 제안된 객체를 개발툴/Library의 어떤 클래스를 이용하여 구현할 수 있는가?, 어떻게 상속 받을 것인가?, 관계는 어떻게 구현할 것인가?, 변수명, 변수의 데이터 타입, 메소드 인자, 리턴값, ...

새로운 산출물을 생성하거나 전 단계의 결과를 새로운 포맷으로 변형시킬 필요 없이 전 단계의 산출물 더 자세한 내용을 추가함

3/20


객체지향 개발 방법론의 특징 및 효과① 개발 비용의 많은 부분을 분석단계로 앞당김: 객체지향 개발 방법론은 분석/설계 단계에 많은 시간과 노력을 투입하도록 한다. 이렇게 앞 단계에서 많은 비용을 투입하는 것은, 결국 후 단계에서 적은 노력(비용)으로 안정적인 시스템을 빠르게 구현할 수 있도록 보장하며, 향후 유지/보수가 쉬운 장점이 있다.

② 기능(구조)보다 데이터(구조)를 강조함: 기능(Function)보다 데이터 구조에 초점을 둠으로써 시스템 개발 작업이 보다 안정적으로 진행된다. 즉 전체 개발 과정을 통해 객체라는 하나의 통합적인 개념을 중심으로 기능(functions), 관계(association), 사건(events) 등 필요 개념들이 조직됨으로써 변경, 에러 등의 외부 환경 변화에 영향을 적게 받고 안정적으로 시스템 개발을 할 수 있다. 이는 데이터 구조(Data Structure)와 그들 간의 관계(association)가 기능적 구조(Functional Structure)보다 요구사항의 변화에 더 안정적이라는 사실에 기인한다.

③ 개발 과정간의 단절이 없음: 시스템 개발 라이프 사이클의 앞 단계에서 이미 문제 지향적인 객체를 식별하고 다음단계에서는, 한 형식에서 다른 형식으로의 전환/변경/사상 등의 작업 없이 전 단계의 산출물을 더욱 자세한 수준으로 다듬고 새로운 정보를 추가하게 됨으로써 개발 라이프 사이클의 각 단계간의 단절이나 정보의 유실이 거의 없다. 분석 단계에서 사용했던 표기법(notation)이 그대로 마지막까지 사용된다.

④ 반복적 수행에 의한 재 작업이 용이함: 방법론 자체를 설명하는 매뉴얼에서는 어쩔 수 없이 순차적으로 방법론을 설명하게 되나 실제 적용 시에는 순차적이라기 보다는 반복적 작업이 된다. 전 단계의 산출물을 정정하거나 변경하는 것이 아니라 추가하고 더 자세한 레벨로 다듬는 작업이 필요하다. 이러한 특성이 방법론의 각 단계에서 추가, 재 작업, 반복 등을 용이하게 한다.

⑤ 효과적인 대화 도구로 활용 가능함: 각 단계의 산출물이 사용자 및 문제 영역 전문가와의 효과적인 대화 도구가 된다. 간단하면서도 잘 정의된 다이아그램 표기법을 이용해 각 산출물을 그림 형식으로 작성하게 되고, 사용자와의 대화를 통해 발견된 수정사항을 쉽게 추가, 변경할 수 있다.

4/20


분석시스템의 목표를 정확히 세우는 데는 많은 시간과 노력이 투자되어야 한다. 이러한 투자가 개발 단계에서 이루어져야 결과적으로 막대한 양의 시간과 노력을 절감할 수 있다.

요구사항 수집인터뷰 정보를 수집하기 위해 요구되는 가이드 라인은 다음과 같다.

누구(WHO) : 분석과정에 참여하는 사람이 누구인가? 시스템을 사용하는 사람이 누구인가? 등

무엇(WHAT) : 현재의 상태는 어떠한가? 만들어질 시스템은 어떤 모습이며 어떤 기능이 수행되어야 하는가?

언제(When) : 언제 새 시스템이 설치되어야 하는가? 언제 새 시스템에 대한 합격 검사가 이루어질 것인가?

어디(Where) : 기존 환경의 어디에 새 시스템이 이용될 것인가? 현재의 인원들은 새 시스템의 어디에 배치될 것인가?

왜(Why) : 왜 새로운 시스템이 개발되어야 하는가?무엇이 기존의 시스템에서 새로운 시스템 개발을 유발시켰는가?

어떻게(How to) : 새로운 시스템은 어떻게 기능을 수행할 것인가? 어떤 제약 조건하에서 기능을 수행할 것인가?

인터뷰 계획 때 준비할 사항은 다음과 같다.

인터뷰를 시작하기 전 분석가는 기본 지식을 가지고 들어가야 한다. 필요한 서적을 찾아보거나 필요한 용어를 숙지해 놓아야 한다.

인터뷰의 목적을 확립해 두어야 한다. 데이터의 형식, 품질, 결정 형태 등 수집해야 할 정보를 정해야 한다.

누구를 인터뷰할 것인가를 결정한다. 시스템과 관계된 다양한 계층의 고객과 인터뷰해야 한다.

인터뷰에 응하는 사람이 준비할 수 있도록 사전에 통보해 주어야 한다. 인터뷰할 내용을 생각해 볼 시간을 주는 것이 바람직하다.

인터뷰 이전에 질문의 유형과 구조를 준비해 두어야 한다.

인터뷰를 위한 질문의 유형으로는 세가지가 있다.

가. 열린 질문

질문에 대해 고정적으로 되어 있는 답을 말하는 것이 아니라 최선을 다하여 자신의 의사를 말하는 것이다.

예 : “현재 사용하고 있는 시스템에 대하여 어떻게 생각합니까?”

"이 조직에서 발생하는 일반적인 실수는 어떤 것이 있습니까?"

나. 닫힌 질문

지정되어 있는 몇 가지 답 중에서 고르도록 제약을 가하는 질문이다. 구체적으로 질문함으로써 시간을 절약할 수 있으며 반응 또한 구체적으로 맞추어져 있어 빠르게 인터뷰를 진행할 수 있다.

예 : "얼마나 많은 직원과 일합니까?”,“컴퓨터를 사용합니까?”

5/20


다. 추가 질문

“예를 하나 들어 주시겠습니까?”같이 답변에 대하여 명확히 알고자 할 때 사용하며, 추가질문은 분석가가 답변을 듣고 이해하고 있음을 상대방에게 전달할 수 있다.

※ 위의 세가지 질문유형으로 진행할 수 있는 인터뷰의 구조는 아래와 같다.

인터뷰의 구조 내 용

피라미드 구조

질문의 유형이 구체적인 예에서 일반적인 것으로 옮겨가도록 준비한다. 분석가는 구체적이며 닫힌 질문에서 시작하여, 열린 질문으로 유도하여 주제를 넓혀나가 일반화된 결과를 얻어낸다. 이 구조는 특히 인터뷰에 응하는 사람이 아이디어가 떠오를 수 있도록 하거나, 주제에 대해 논의하기를 꺼릴 때 바람직하다.

깔대기 구조

일반적이며 열린 질문으로 시작하여 점차 닫힌 질문으로 좁혀 나간다. 이 구조는 일반적으로 인터뷰를 시작할 때 쉽게 접근할 수 있게 하여 준다. 이 경우 열린 질문으로 시작하기 때문에, 인터뷰에 응하는 사람이 질문에 대하여 잘못된 답을 하지 않을까 하는 중압감을 덜 느끼게 된다. 인터뷰에 응하는 사람이 주제이 대하여 감정적이거나 자신의 감정을 표시하고자 할 때 도움을 줄 수 있다.

다이아몬드 구조

앞의 두 구조를 섞은 것이며 구체적인 질문으로 시작하여 일반적인 문제들이 다루어진 후, 마지막으로 구체적인 결론들이 유도되도록 인터뷰를 진행한다. 이 방법의 주요 장점은 다양한 질문을 통하여 인터뷰에 응하는 사람의 주위와 흥미를 끌 수 있게 할 수 있다는 것이다. 단점으로는 앞의 방법보다 시간이 많이 걸린다는 점이다.

설문지설문지를 사용하는 경우 분석가와 응답자 사이에 직접적인 교류가 없으므로 질문의 내용이 명확하고, 질문의 흐름이 논리적인 순서에 맞아야 하고, 응답자의 답을 예상할 수 있어야 한다. 질문들이 구체적인 방법으로 대답할 수 있도록 좁혀지는 것이 바람직하다.

예 : "시스템 인터페이스를 사용할 때 가장 많이 발생하는 문제 4가지만 나열해 주십시오.”

“ 아래의 소프트웨어 패키지 중 당신이 가장 많이 사용하는 것을 골라주십시오.”

요구사항 분석※ 요구사항 분석 단계는 다음과 같다.

① 프로세스 맵 작성

② 단위업무기술서 작성

③ 문제기술서 작성

④ 데이터사전 작성

⑤ Use case 모델 작성

시스템 개발에 있어 대상에 대한 정확한 이해가 필수적이다. 개발하려는 시스템이 어떤 일을 하는지, 어떻게 작동하게 되는지 사용자는 누구인지 등

6/20


⇒ 대상영역의 프로세스를 분석할 필요

프로세스 분석을 위해서 프로세스 맵을 작성하여 프로세스를 이루는 단위업무 들의 흐름을 파악하고, 각 단위 업무들을 수행하는 액터들을 명확히 해야 한다. 이 과정에서 정확한 문제 기술서, 데이터 사전 등이 작성된다.

※ 객체지향 분석은 객체와 그들 간의 관계를 식별하는 것에서 시작되는데, 이러한 객체, 관계의 식별을 위해 Use-case 모델을 이용한다.

※ 유즈케이스는 User와 시스템간의 상호작용에 대한 시나리오 역할을 한다. 따라서, 유즈케이스에서 모델링하게 될 객체를 찾아낼 수 있다.

※ 요구사항 분석의 산출물 중에서 문제기술서(Problem Statement)와 데이터 사전은, 소프트웨어 개발 단계의 최상위 문서로서 시스템 개발 전체과정에 걸쳐 기준이 되는 중요한 것이다. 프로젝트를 시작하여 만들어진 제품의 성능, 품질을 검사하는 기준과 표준으로 문제기술서를 활용해야 한다.

프로세스 맵

개발하여야 할 시스템을 이해하기 위해 업무 프로세스를 조사하고 이를 분석하여 프로세스 맵으로 작성

이 단계에서 개발 대상 시스템이 무엇을 해야 되는지, 왜 해야 되는지, 그 프로세스를 수행하기 위해 무엇이 필요한지 이해하게 된다.

프로세스 맵은 IDEF0 모델링 기법을 이용하며, 포함되는 내용은 다음과 같다.

■ 프로세스 맵의 예 :

단위업무기술서

7/20


작성된 프로세스 맵에 대해서는 해당 프로세스에 대한 개략적인 설명과 함께 프로세스를 구성하는 단위 업무에 대한 상세한 설명을 포함하고 각 단위 업무를 수행하는 액터를 명시한다.

■ 단위업무기술서 의 예 :

문제 기술서 프로세스 분석의 결과를 바탕으로 문제 기술서를 작성 사용자가 작성할 수도 있으나 대부분은 개발자가 사용자와 문제 영역 전문가와의 대화를 통해 작성 문제 기술서는 요구사항에 대한 기술서라고 말할 수 있는데 개발될 시스템이 무엇을 해야 하는지를 기술한다. 어떻게 해결해야 하는 지에 대한 기술서가 아니다. 즉, 해결책(solution)에 대한 제안이 아니라 요구사항(needs)에 대한 정리이다.

※ 다음과 같은 가이드라인(Guidelines)이 있다.

사용자는 어떤 사항이 기본이고 어떤 사항이 옵션인지 명확히 언급해야 한다.

사용자는 설계/구현시의 유연성을 보장하기 위해 시스템 내부적인 사항에 대해 지나치게 명세하는 것을 피해야 한다.

성능 명세(Performance specification), 외부와의 상호작용(Interaction) 프로토콜에 대한 요구사항도 포함된다.

모듈 구성, 시험성(testability), 향후의 확장성 등과 같은 소프트웨어 공학 측면에 대한 사항도 문제 기술서에 포함될 수 있다.

흔히 많은 문제 기술서에서 진정한 요구사항(pure requirements)과 설계 단계에서 결정되어야 할 사항들이 섞여 있다. 따라서 분석가는 비록 여러 가지 이유에서 설계 사양에 해당되는 사항이 초기 단계에서 명기 된다 해도, 문제 영역의 핵심적인 요구사항과 설계 사양을 면밀히 구분해야 한다.

문제 기술서는 시스템 개발의 출발점으로서 자세하지 않아도 되며 분석 단계에서 설계, 구현 단계로 발전하면서 여러 번의 추가, 수정을 하게 된다.

■ 문제 기술서(Problem Statement) 의 예 : Electronic Filing System

8/20


Electronic Filing System 개발을 목적으로 요구사항을 조사하여 정리하였다. 아래의 예는 초기 문제 기술서로서 개발이 진행되면서 문제 기술서 자체도 여러 차례 개정되게 된다.

데이터 사전 데이터 사전에서는 용어의 의미를 명확하게 정리한다.

개발 과정이 진행되면서 새로운 내용이 계속 추가되고 개정됨

데이터 사전의 예

9/20

Electronic Filing System(EFS)는 텍스트 도큐먼트를 저장(store)하고 리트리브(retrieve)하는데 사용된다. 워드 프로세서, 에티터를 이용해서 작성된 또는 다른 방법으로 작성된 어떤 도큐먼트도 EFS 내에 저장(store)되고 리트리브(retrieve)할수 있다. 도큐먼트는 키워드, 저자, 도큐먼트 설명문 또는 초록(abstract)에 의해 EFS 시스템 내에 파일된다. EFS 내에 파일된 도큐먼트는 삭제 가능하다.

EFS 내에 파일된 도큐먼트들은 빠른 검색을 위해 인덱스 된다. 도큐먼트는 통상적인 방법과는 달리 간편한 방법으로 리트리브할 수 있다. 예를 들어, 사용자는 도큐먼트의 내용(contents), 설명문(description), 저자, 사용자 정의 키워드 등으로 검색하고 리트리브 할 수 있다. 따라서 도큐먼트 설명문, 저자, 키워드, 실제 도큐먼트 자체도 검색이 가능하다.

사용자가 검색 조건을 명세할 수도 있다. 그 결과로 검색 조건에 일치하는 도큐먼트들이 표시되고 사용자는 다시 추가적인 검색 조건을 명세하고 더욱 상세한 검색을 할수 있고 몇번에 걸쳐 반복 검색하여 점차 원하는 도큐먼트를 검색하게 된다. 이렇게 검색된 도큐먼트는 보거나 프린트 할 수 있다.

사용자는 정크(junk) 단어를 정의할 수 있다. 정크 단어는 내용(contents)에 있어도 검색되거나 인덱스 되지 않는 단어이다. 예를 들어, ‘그리고’, ‘또는’, ‘아니다’, ‘그’, ‘만약’ 등의 단어는 검색시 영향을 미치지 못한다. 사용자는 또한 어떤 특정 문자를 인덱스하거나 검색가능하도록 할 수 있다.(filing character set) 따라서 검색이나 인덱스를 도큐먼트의 일부로 한정할 수 있다.

초록(Abstract) -도큐먼트의 핵심적인 내용을 간단히 기술한 것. 초록은 여러 개의 문장으로 작성되는데 도큐먼트의 전반적인 내용을 설명한다.

저자(Author) -도큐먼트를 작성한 사람의 이름. 한 도큐먼트에 여러 명의 저자가 있을 수 있다.

파일링 문자(Filing character) -EFS에 의해 인식되는 문자(alphanumeric character). 어떤 전자 파일링 응용시스템에서는 특정한 문자나 숫자만 인덱스되고 리트리벌(retrieval) 되기를 요구한다. 오직 파일링 문자만이 인덱스되고 리트리브된다.

인덱스(Index) -자료의 빠른 검색과 리트리브를 위해 각각의 도큐먼트는 인덱스 된다. 인덱싱 방법은 차후에 명세되어질 것임.

정크 단어(Junk or Noise word) -언어(language)에 있어 통상적인 단어로 리트리브 프로세스에 아무런 의미를 가지지 않는 단어. 따라서 정크 단어는 인덱스 되지 않는다. 예를 들어, ‘그리고’, ‘그’, ‘또는’, ‘만약’, ‘∼이다’ 등이 될 수 있다.

키워드(Keyword) -특정 도큐먼트를 찾는데 사용자에게 도움을 줄 수 있는 단어. 한 도큐먼트에 여러 개의 키워드가 관계될 수 있다.

줄(Line) -텍스트 도큐먼트는 줄로 이루어 진다. 도큐먼트는 적어도 하나의 줄을 가지고 있어야 한다. 도큐먼트 내의 줄은 단어가 없을 수도 있고, 여러개일 수도 있다.

쪽(Page) -비어 있는 도큐먼트가 아니라면 적어도 하나의 페이지 이상으로 구성된다. 각각의 쪽은 하나 이상의 줄로 구성된다.

도큐먼트(Document) -도큐먼트는 편집기(editor), 워드프로세서, DPT 등으로 작성된다. 도큐먼트는 쪽으로 구분된다. 한 도큐먼트는 적어도 하나 이상의 쪽으로 구성된다.

단어(Word) -언어의 단위로 몇 개의 문자로 구성되어 어떤 의미를 나타내거나 문자(alphanumeric character)를 말한다..


Use Case 다이아그램

Use Case에 의한 방법은 우선 시스템을 사용자의 관점에서 바라보아 시스템을 사용하는 사용자들이 볼 수 있는 기능만을 밝혀낸다. 이런 접근 방법을 사용하면 시스템의 분석이 사용자의 관점에서 이루어질 수 있다. 또한 사용자가 볼 수 있는 기능은 다른 기능보다 찾아내기 쉬우며 사용자들도 분석 과정에 참여하며 그 결과를 쉽게 이해할 수 있다는 장점을 가지고있다.

본격적으로 객체지향 분석을 위해 다음단계(객체모델링 단계)에서 Use-case 모델을 이용하여 객체와 객체간의 관계를 찾아내게 된다. 우선 액터는 객체의 후보가 되며, 시나리오상에 나타나는 명사들이 객체의 후보로 식별된다. 마찬가지로 시나리오상에 동사나 동사구로 표현되는 것이 관계의 후보가 된다. 또한 각종 Spec. 이나 문제기술서 등에 나타나는 명사, 명사구, 동사, 동사구 등도 객체와 관계의 후보로 식별될 수 있다.

※ 가장 일반적인 Use Case Diagram은 Jacobson 방법이다.

객체 모델링(Object Modeling)

절차 및 산출물① 객체들을 식별한다.

② 불필요하거나 옳지 않은 객체를 제거한다.

③ 객체들 간의 관계(Associations)를 식별한다.

④ 부적당하거나 옳지 않은 관계를 제거한다

⑤ 객체의 속성(Attributes)를 식별한다.

⑥ 부적당하거나 옳지 않은 속성을 제거한다.

⑦ 객체, 속성(Attributes) 그리고 관계(Associations) 들을 데이터사전(data dictionary)에 기술한다.

⑧ 특성계승(inheritance)을 사용하여 공통 부분을 식별하고 구조를 간단히 구성하여 문제영역 객체도(Domain Object Diagram)를 작성한다.

⑨ 접근경로(access path)를 이용하여 결함을 찾아내고 필요하면 상위의 단계를 반복한다.

※ 객체 모델은 문제 영역을 객체와 그들 간의 관계로 나타냄(정적, 영속적 구조)

※ 가장 중요한 요소는 추상화 된 수준에서의 객체와 그들 간의 관계(Relationship)임

※ 객체지향 시스템 개발의 핵심은 프로그래밍 언어로 표현된 최종상태의 표현이 아니라 문제영역에 포함된 정확한 개념을 찾아내고 조직하는 것이다. 즉 해결하고자 하는 문제영역을 정확하고 효과적으로 표현하는 모델을 만드는 것이다.

10/20


■ 예제) ATM 시스템 개발 -Problem Statement

11/20


12/20


13/20


단계별 가이드라인(Guideline)

■ 올바른 객체 클래스의 선택

※ 객체 모델링 단계에서는 대상 영역을 객체와 객체간의 관계로 모델링하기 위해, Use-case, 문제 기술서로부터 명사를 추출하여 후보 객체 클래스를 식별한다.

※ 후보 객체 클래스로 식별된 것들 중에서 적절한 클래스를 선별하여 초기 객체 모델을 작성하게 되는데 이때 다음과 같은 기준(Guideline)을 이용한다.

부가적인 객체 클래스(Redundant Object). 객체 클래스로 식별한 것들 중에 같은 정보를 나타내는 것은 더 설명적인(descriptive) 것을 선택한다. 예를 들어 항공여객 예약 서비스에서 ‘고객’이라는 객체 클래스보다는 ‘승객’이라는 객체 클래스가 더욱 설명적이다. 한편 개발하는 시스템이 여객 서비스가 목적이 아니라 항공사의 고객 관리가 목적이라면 ‘고객’이라는 객체 클래스가 더 적절하다.

관계 없는 클래스(Irrelevant Object). 후보로 식별된 객체 클래스 중에 해결하고자 하는 문제와 별 관련성이 없는 것은 제외한다. 이 문제는 상당히 문제 의존적이다. 즉 해결하고자 하는 관심의 대상이 무엇이냐에 따라 적절한 클래스이기도 하고, 부적절한 클래스가 되기도 한다.

모호한 클래스(Vague Object). 객체 클래스는 경계가 명확하게 정의 되어야 한다.

속성(Attributes). 식별된 후보 객체 중에 각각의 객체를 설명하는 것은 그 객체 클래스의 속성(Attribute)로 명세 되어야 한다. 예를 들어, 이름, 나이, 몸무게, 주소 등은 일반적으로 속성(Attribute)이다. 그러나 속성 자체가 독립적으로 존재하는 것이 중요하다면 이를 하나의 객체 클래스로 모델링 할 수도 있다.

오퍼레이션(Operations). 후보 객체로 식별된 것이 객체에 적용되는 오퍼레이션인 경우 그것은 객체 클래스가 아니다. 예를 들어, 전신전화 시스템을 만든다면 ‘전화걸기’는 발신자와 관계된 액션(action)이다. 즉 동적모델에서 표현된다. 그러나 개발하는 시스템에 따라 ‘전화걸기’가 별도의 의미를 갖는 경우 하나의 객체 클래스로 모델링 될 수도 있다. 예를 들어, 전화 요금 계산 시스템을 만들 때 ‘전화 걸기’는 날짜, 시간, 수신자 등의 속성을 갖는 하나의 구분되는 대상 객체 클래스가 될 수 있다.

역할(Roles). 객체 클래스의 이름은 그것이 나타내는 객체의 내제적인 본질을 나타내어야 한다. 즉 다른 객체와의 관계 속에서의 역할을 나타내서는 안 된다. 예를 들어, 자동차 회사의 데이터베이스에 고객에 대한 모델링 객체로서 ‘소유자’라는 이름은 적절치 못하다. ‘사람’ 또는 ‘고객’더욱 적절하다. 하나의 실제물(Physical Entity)은 관심의 대상에 따라 다양한 객체 클래스로 모델링 될 수 있다. 즉 시스템에 따라 같은 실제물을 나타낼 수도 있고 다른 실제물을 나타낼 수도 있다. 예를 들어, ‘사람’이라는 클래스와 ‘종업원’이라는 클래스는 회사의 데이터베이스라는 관점에서는 같은 것이 되고, 정부의 세금 데이터베이스라는 관점에서는 사람이 하나이상의 직업을 가지고 있으므로 다른 것이 된다. 따라서 될 수 있으면 내제적인 본질을 나타내는 것을 선택해야 한다.

구현 요소(Implementation constructs). 실 세계와 동떨어진 관계없는 요소는 제거해야 된다. 그것들은 대부분 설계단계에서 필요한 것들이다. 예를 들어, CPU, 서브루틴(subroutine), 프로세스, 알고리즘, 인터럽트 등은 운영체제프로그램(Operating System)에서는 적절할지 몰라도 대부분의 응용시스템에서는 구현요소에 해당된다. 링크드리스트(linked lists), 트리(trees), 배열(arrays) 등은 거의 항상 구현요소 이다.

■ 올바른 관계(Associations)의 선택

※ Use-case, 문제기술서에서 동사 또는 동사구로 표현되는 관계(Association)를 식별하여 후보 관계로 선정하고 그 중에서 다음과 같은 지침(Guideline)을 적용하여 적절한 ‘관계’를 선정하게 된다.

삭제된 객체 간의 관계. 관계(Association)에 참여하고 있던 두 객체 중 하나가 삭제되었을 경우 관계(Association)도 삭제되어야 한다.

관계 없거나 구현에 관련된 관계(Irrelevant or implementation associations). 문제 영역 밖의 관계이거나 구현요소(implementation constructs)를 나타내는 관계는 삭제한다. 예를 들어 “시스템은 동시(concurrent)에 일어나는 접근(access)를 관리(handle)한다.”라는 관계는 구현요소에 해당된다. 실 세계의 객체는 본질적으로 동시적이다. 따라서 위의 관계는 동시 접근을 지원하는 알고리즘을 작성할 때 어떻게

14/20


구현하는가 하는 구현 문제이다.

액션(Actions). 관계(Association)는 문제영역의 순간적인 이벤트가 아니라 정적이고 구조적(structural)인 성질을 표현해야 한다. 예를 들어, “ATM이 캐시 카드를 받아들인다.”라는 표현은 ATM과 캐시 카드 사이의 영속적인 관계를 나타내는 것이 아니라 ATM과 고객의 상호작용 중의 일부를 설명하고 있다.

어떤 경우는 액션으로 표현된 요구사항이 이면에 숨어있는 구조적 관계를 나타내기도 한다. 따라서 관계를 설명하도록 다시 표현하여야 한다. 예를 들어, “중앙 컴퓨터는 은행과의 트랜잭션(transaction)을 소거한다”라는 표현은 은행과 중앙 컴퓨터가 통신(communicate)한다는 관계를 나타낸다.

3차 관계(Ternary associations). 3개 또는 그 이상의 클래스 간의 관계는 대부분 2차 관계(Binary Association)나 제한관계(Qualified Association)로 분해할 수 있다. 예를 들어, “창구담당자는 계정을 관리하기 위해 데이터베이스에 들어간다.”라는 관계 표현은 “창구담당자가 데이터베이스에 들어간다.”와 “데이터베이스는 계정을 관리한다.”라는 관계로 분해할 수 있다.

만약 3차관계 속의 하나의 객체가 부가 설명적이고 자체의 형태를 가지고 있지 않은 경우 그것은 링크 속성이거나 2차관계의 속성이 된다. “회사는 사원에게 급여를 지급한다.”라는 관계는 “회사는 급여액이라는 특성을 가지고 사원을 채용한다”라는 2차 관계로 전환할 수 있다.

드물게 일반적인 3차관계가 필요한 경우가 있다. “모 교수는 몇 호실에서 어떤 강의를 한다”라는 관계는 정보의 유실 없이 2차관계로 분해할 수 없다. 그러나 4차이상의 관계는 아직 없는 것으로 알려져 있다.

파생관계(Derived associations). 다른 관계로부터 정의할 수 있는 관계는 버린다. 예를 들어, 조부모 관계는 두개의 부모관계로부터 정의할 수 있다. 마찬가지고 객체 클래스의 속성의 상태에 의해 정의되는 관계는 버린다. 예를 들어, ‘더 젊다’라는 관계는 두 ‘사람’ 클래스의 ‘생일’ 속성의 상태로부터 표현된다.

가능한 한 객체모델의 객체, 속성, 관계는 독립적인 정보를 나타내야 한다. 객체 사이에 복수의 패스(path ;traversal path를 말함)가 존재한다는 것은 기본 관계(primitive association)의 조합으로 이루어진 파생 관계가 존재한다는 것을 말한다. “컨소시엄(Consortium)이 ATM을 공유한다.”라는 관계는 “컨소시엄이 중앙컴퓨터를 소유한다.”, “중앙컴퓨터는 ATM과 통신(communication)한다.”라는 기본 관계의 조합이다.

복수의 패스가 존재한다는 것이 반드시 여분의 관계가 있다는 것을 의미하지만은 않는다는 것에 주목하라. 어떤 경우에는 몇 개의 기본 관계로부터 파생될 수도 있으나 multiplicity의 경우 해당되지 않는 경우도 있다. Multiplicity가 중요한 제약조건으로 작용한다면 여분의 관계를 포함시켜라.

잘못된 이름의 관계(Misnamed associations). ‘왜 또는 어떻게 이 상황이 왔는가?’라고 표현하지 말고 ‘그것이 무엇인가?’라고 표현하라. 이름은 이해하는데 매우 중요하다. 신중히 선택해야 한다. “은행 컴퓨터는 계정을 관리한다”는 액션에 대한 표현이다. “은행은 계정을 가지고 있다(hold)”라고 재 표현하라.

역할 이름(Role names). 적당한 곳에 역할 이름을 첨가하라. 역할이름은 관계 속에서 한 객체의 역할을 다른 객체의 관점에서 표현한다. 예를 들어, '일하다(works-for)' 관계에서 회사는 고용인의 역할을 하고 사람은 고용된 자의 역할을 한다. 만약 한 쌍의 객체 사이에 단지 하나의 관계만 있을 경우, 객체 자체의 이름이 역할을 잘 설명할 경우 역할이름을 생략할 수도 있다. 같은 객체 클래스의 인스턴스 사이의 관계(reflexive association) 표현에서는 인스턴스 각각의 역할을 구분하기 위해 역할이름이 필요하다. 예를 들어, “사람은 사람을 관리한다”라는 관계에는 보스(boss)와 근로자(worker)라는 역할이 있다.

제한관계(Qualified associations). 보통 특정 배경(context) 내에서 이름은 객체를 제한해 준다. :대부분의 이름은 전세계에서 유일하지는 않다. 배경과 이름이 조합되어 하나의 객체를 유일하게 식별하게 된다. 예를 들어, 한 지역에서 회사 이름은 유일할 수 있으나 다른 지역까지 고려할 때 유일하지 않을 수 있다. 따라서 지역과 회사이름이 조합되어 유일하게 하나의 회사를 식별하게 된다.

제한자(qualifier)는 관계의 많은 측면 중에 객체들을 제한한다. 예를 들어, 은행코드 제한자는 은행 컨소시엄에서 서로 다른 은행을 식별한다. 각각의 캐시카드는 발행은행을 식별하기 위해 은행코드가 필요하다.

Multiplicity. multiplicity를 명세하라 그러나 올바른 multiplicity를 모델링 하기 위해 너무 많은 노력을 낭비하지는 말라. 분석과정을 거치면서 자주 변하게 된다. “many” multiplicity 의 경우 제한자(qualifier)가 필요한지 검토하라. 마찬가지로 어떤 방법으로 순서를 정하는 것이 필요한지 생각해 봐라.

■ 올바른 속성의 선택

15/20


※ Use-case, 문제 기술서로부터 객체 클래스와 그들 간의 관계를 선정하였다. 명사로 표현되는 것을 객체 클래스의 후보로, 동사로 표현되는 것을 관계의 후보로 선정하고 각각의 지침(Guideline)에 따라 적절한 것들을 선정하였다.

※ 개발 단계가 설계, 구현 단계로 진행되면서 속성들은 더욱 자세히 정의 되지만 초기 분석 단계에서도 명확한 속성에 대해서는 객체 모델에 명기한다. 즉 초기 분석 단계에서는 모든 속성을 정의하지 않고 이 단계에서 명확한 속성만을 객체모델에 추가하게 된다.

※ 문제 기술서로부터 후보 속성을 찾아내고 아래의 Guideline을 적용하여 적절한 속성을 선정한다.

객체 클래스. 만약 한 실물(entity)의 독립적인 존재가 그것의 값(value)보다 중요하다면 그것은 객체이다. 예를 들어, ‘보스(boss)’는 객체이나, ‘급여’는 속성이다. 그러나 그 구별은 응용영역에 의존적이다. 예를 들어, 우편 주소록에서 ‘도시’는 속성이나 호구조사에서는 ‘도시’가 하나의 객체이다. 즉 해결하고자 하는 문제 영역에서 한 실물(entity)이 고유의 실체를 가지고 있는 경우 객체 클래스로 모델링 된다.

제한자(Qualifiers). 만약 한 속성의 값이 특정 배경(context)에 의존적이라면 그 속성을 제한자로 모델링 하라. 예를 들어, ‘사번’은 두개의 직업을 가지고 있는 ‘사람’ 객체에게는 유일한 속성이 아니다. 즉 특정 배경에 의존적이다. 따라서 ‘사번’은 “회사는 사람을 고용한다”라는 관계를 제한 시킨다.

이름(Names). 이름(name)은 객체 클래스의 속성으로 모델링 하는 것보다 제한자로 모델링 하는 것이 좋다. 반대로 이름이 배경(context)에 의존적이지 않고, 특히 유일할 필요가 없다면 객체 클래스의 속성으로 모델링 하는 것이 좋다. 예를 들어, 사람의 이름은 회사명과 달리 중복되어도 되며 따라서 객체 클래스의 속성이다.

식별자(Identifiers). 객체지향 언어는 명확하게 참조(referencing) 가능한 객체 식별자의 개념이 바탕을 이루고 있다. 그러나 객체모델에서는 식별자 자체가 객체 클래스 내에 내제적으로 포함됨으로 식별자를 나열하지 마라. 단지 문제 영역 내에서 존재하는 속성만을 나열하면 된다.

관계 속성(Link attributes). 만약 성질이 관계에 의존적이라면 그 성질은 관계된 객체의 속성이 아니라 링크의 속성이다. 링크 속성은 일반적으로 ‘다대다’ 관계에서 명확한데; 그들의 multiplicity 때문에 관계 속성을 양쪽 어느 객체에도 속성으로 붙일 수 없다. ‘일대다’관계에서는 다소 모호한데 이는 속성을 '다‘쪽의 객체에 정보의 손실 없이 속성으로 포함시킬 수 있기 때문이다. 마찬가지고 '일대일’ 관계에서도 링크 속성의 구분이 모호할 수 있다.

내부 값(Internal values). 어떤 속성이 해당 객체의 내부적 상태를 나타내고, 객체 외부로는 노출되지 않는다면, 분석 단계에서는 삭제한다.

부조화 속성(Discordant attributes). 서로 상반되게 보이거나 서로 관계가 없어 보이는 속성이 있다면 이는 그 객체 클래스가 두개로 나누어 져야 함을 암시하는 것일 수 있다. 객체 클래스는 단순하고 일관되어야 한다. 초점이 없는 객체 클래스는 대게 분석 단계에서 구현 단계의 결정들을 고려하는 실수에서부터 발생한다.

모델 상세화 및 통합접근경로 테스트※ 객체모델을 작성한 후 문제기술서의 내용을 충분히 구현할 수 있는지를 초기 검사

※ Use-case/시나리오를 객체모델의 객체 클래스, 속성, 오퍼레이션, 관계를 이용해서 수행하고, 원하는 결과를 얻을 수 있는지를 테스트

※ 원하는 결과를 얻을 수 있는 경로(접근 경로)가 제공되는지를 의사코드(Pseudocode)를 이용하여 테스트

16/20


※ 접근 경로가 제공되지 않으면, 발견되지 않은 클래스, 오퍼레이션, 속성, 관계 등이 있다는 것으로 적절하게 모델을 수정해야 함

세 모델의 통합

※ 분석과정에서 작성되는 세 모델 중 객체모델이 골격(Framwork) 역할을 함

※ 최종 설계단계가 끝나고 개발자(프로그래머)에게는 객체모델이 넘겨지게 됨. 즉 객체지향 개발 방법론의 궁극적인 목적은 소프트웨어로 바로 구현 가능한 수준의 자세한 객체모델을 빨리, 안정적으로 만들어 내는 것이라 할 수 있음.

※ 분석, 설계 과정을 거치면서 여러 번의 반복(Iteration)을 거치고, 차츰차츰 객체모델을 중심으로 상세화해 나감

세 모델 간의 관계 동적모델의 사건(event)은 객체모델의 오퍼레이션에 대응할 수 있다. 즉 한 객체에 보내어 지는 사건(event)은 그 객체의 오퍼레이션(Member Function)으로 구현된다.

동적모델의 액션(Action)과 액티비티(Activity)가 중요한 기능을 가지고 있는 경우 객체모델의 오퍼레션으로 정의 된다.

기능모델의 기능/프로세스(Function/Process)는 객체 모델의 오퍼레이션에 대응한다. 즉, 기능모델의 기본단위 펑션(Functional Primitives)은 객체 모델의 기본 객체(Basic Object)의 메소드에 대응한다. 한편 기능모델의 상위 레벨 기능은 객체 모델의 복합객체(Aggregated Object)와 같은 상위 레벨 객체의 오퍼레이션에 대응한다.

기능모델의 데이터 흐름(Data Flow)는 객체 모델에서의 값을 나타내거나 표준 객체를 나타낸다. 한 프로세스에 입력되는 데이터 흐름은 그 프로세스의 목표(Target) 객체일 수 있다. 또는 단순한 입력 파라메터일 수도 있다.

기능 모델의 데이터스토어(Data Store)는 객체 모델의 객체 또는 객체의 속성값에 대응한다. 데이터스토어에 입력/출력되는 데이터 흐름은 데이터스토어 객체의 오퍼레이션에 대응한다.

기능모델을 이용한 오퍼레이션 추가 및 상세화

※ 기능모델 작성(DFD 작성)에 의해 프로세스의 계층구조(Process Hierarchy)를 정리할 수 있음

※ 각 프로세스를 객체모델의 특정 객체의 오퍼레이션으로 할당

※ 기능모델의 프로세스를 오퍼레이션으로 가지는 즉, 오퍼레이션이 할당되는 목표 클래스를 결정하는 지침

프로세스가 입력 플로우에서 값을 취한다면 입력 플로우가 목표가 된다.

프로세스가 같은 타입의 입력플로우와 출력플로우를 가지고 있고 출력값이 본질적으로 입력 플로우의 업데이트 버전이라면 입력/출력 플로우가 목표가 된다.

프로세스가 여러 개의 입력 플로우로부터 출력을 만들어 낸다면 출력 객체의 생성자 오퍼레이션이다.

프로세스가 액터나 데이터스토어로부터 입력 또는 출력을 갖는다면 액터나 데이터스토어가 목표 객체가 된다.(경우에 따라 프로세스가 액터를 위한 오퍼레이션과 데이터스토어를 위한 오퍼레이션으로 나뉘어야 될 수도 있음.)

※ 이 단계 오퍼레이션뿐만 아니라 필요한 새로운 객체가 발견된다. 즉 오퍼레이션이 올바르게 작동하기 위해 현실세계에서는 발견되지 않았던 객체가 추가되기도 한다.

17/20


동적모델을 이용한 오퍼레이션 추가 및 상세화

※ 동적모델을 검토하여 이벤트(Event), 액션(Action), 액티비티(Activity)를 찾아내어 객체의 오퍼레이션으로 할당

※ 액션(Action), 액티비티(Activity)의 경우 중요한 기능(계산기능)을 가진 것을 오퍼레이션으로 할당

※ 이벤트를 오퍼레이션으로 할당할 때, 대상 객체는 그 이벤트를 받는 객체이다.

※ 동적모델로부터 오퍼레이션을 추가할 때 분석단계에서는 중요한 의미를 갖는 것에 주목한다. 자세한 메소드 정의는 설계단계에서 이루어 진다. 이는 분석 단계에서 모든 오퍼레이션을 명세하는 것은 개발자가 문제를 이해하고 건전한 구조의 모델을 만들어 가는데 도움이 되지 않기 때문이다.

시스템 설계

가이드라인(Guidelines)

현존하는 시스템에서 몇 개의 공통적인 골격(Framework)을 찾을 수 있다. 기존에 개발된 시스템을 참고하여 개발하고자 하는 시스템을 설계한다면 많은 노력을 절감할 수 있다. 예를 들어, 본 매뉴얼에서 다루고 있는 Electronic Filing 시스템의 경우 GUI 서브 시스템에 의해 사용자의 컨트롤 flow가 관리되고 사용자의 인터랙션(interaction)에 의해 시스템이 동작되는 Interactive 시스템이다. Interactive 시스템은 특성상 동적모델이 큰 비중을 차지한다. Interactive 시스템 영역 내의 상용 시스템 중 우수한 제품들을 살펴보면 사용자의 Interaction을 담당하는 응용영역(User Interface) 서브시스템을 분리하여 하나의 Layer로 구현하여 문제 영역에 대응하는 부분과 구별하고 있는 것을 볼 수 있다. 물론 문제영역 서브시스템은 제공하는 서비스, 추상화 수준 등에 따라 다시 여러 개의 서브 시스템으로 나누어진다. 따라서 본 매뉴얼의 Electronic Filing System의 경우도 GUI 부분을 별도의 서브시스템(or Layer)로 분리하여 설계하고 이 Layer는 상용 GUI 구현 툴(Library)를 이용하여 구현하는 것이 바람직 하다. 또한 나머지 문제 영역에 대응하는 부분은 Filing 서브시스템, Query 서브시스템과 같이 비슷한 서비스를 제공하는 객체들의 집합으로 나누어 서브시스템을 구성할 수 있다.

다음은 시스템을 특성에 따라 분류한 것이다.

Batch transformation System: 입력된 데이터 셋(set)에 대해 한번의 변환 작업(transformation)만 실행되는 시스템

Continuous transformation System: 입력의 변화에 따라 데이터 변환이 연속적으로 이루어지는 시스템

Interactive interface System: 외부의 인터랙션에 의해 작동하는 시스템

Dynamic simulation System: 실세계의 객체가 변화하는 것을 시뮬레이션 하는 시스템

Real-time System: 정밀한 시간 제약조건이 있는 시스템

Transaction manager System: 데이터의 저장, 개정 등이 주 임무인 시스템

■ Common Architecture Frameworks -Interactive Interface

※ 시스템과 외부 에이전트(유저, 디바이스, 타 프로그램 등)사이의 인터랙션에의해 작동되는 시스템

18/20


※ 시스템의 컴퓨테이셔널한 부분과 분리하여 생각할 수 있으며, 시스템의 컴퓨테이셔널한 부분과 인터랙티브 인터페이스 부분과는 한정된 통로를 통해 상호 작동할 수 있다

※ 주요 관심 대상은 다음과 같은 것들이 있다

외부 에이전트와 시스템과의 통신 프로토콜

인터랙션의 신택스

결과의 출력 형태 및 방법

컨트록의 흐름, 제어

※ 인터랙티브 인터페이스 시스템은 동적모델이 지배적이다. 동적모델은 특정 이벤트에 의해 어떤 펑션이 실행되는지를 보여준다.

※ 인터랙티브 인터페이스 시스템의 디자인은 대략 다음과 같은 절차로 이루어진다.

① 인터페이스를 담당하는 객체를 가려내고 고립화 시킨다.

② 이미 사용 가능한 객체를 이용한다. 예를 들어, X-Windows 시스템

③ 동적모델을 이용하여 프로그램의 스트럭쳐을 결정한다.

④ 논리적인 이벤트를 식별한다. 즉 실제적인 이벤트를 묶어 논리적 이벤트를 식별하고 논리적 이벤트에 응용 펑션을 대응 시킨다.

⑤ 응용 펑션을 자세하게 명세한다.

시스템 설계 단계의 산출물은 여러 가지 도큐먼트가 된다. 서브시스템 간의 데이터 흐름을 보여주는 Information Flow Diagram 이나 각 서브시스템을 구성하는 객체 클래스를 보여주는 서브시스템 클래스 구성도, Client-Server Process Diagram 등의 도큐먼트가 산출물이 될 수 있다.

■ 예제

19/20


<산출물. 8-1>EFS 서브시스템 구성도

20/20

cjmyun.tripod.comcjmyun.tripod.com/knowledgebase/omt.doc · web view시스템설계(system...

Documents