UML & ROSE

1. 내부세미나를 위한 UML & ROSE UML OVERVIEW PRESENTED BY DPKIM 2004. 2.

2. 객체지향 패러다임에 대한 소개 객체지향 패러다임에 대한 소개

3. 객체지향 패러다임 • 관심 분야 • 구조적 프로그래밍 : 데이터 중심 • 객체 지향 프로그래밍 : 데이터 및 행위(비즈니스 룰, 행위) 중심 • 객체지향 기본 개념 • 캡슐화/Encapsulation • 정보의 조각들과 그 정보에 대해 작용하는 특정 행위들을 조합하고 이들을 하나의 객체로 패키지화 • 애플리케이션을 기능적으로 연결된 작은 부분으로 분할하는 것 • 정보은폐 • 상속/Inheritance • 기존 객체로부터 새로운 객체를 만들 수 있게 해주는 메커니즘 • 다형성/Polymorphism • 서로 다른 형상이나 단계 혹은 형식의 발생 • 특정 기능이 여러가지 형태나 구현을 갖는 것을 의미

4. 비쥬얼 모델링 • 모델 • 시스템에 대한 청사진 • 시스템을 구축하기 전에 계획을 미리 수립할 수 있다. • 설계는 견고한지 • 요구사항은 모두 반영되었는지 • 추가 요구사항을 모두 수용할 수 있도록 계획되었는지 • 모델링 • 사용자들의 요구사항과 개발자들이 사용할 요구사항의 매핑 • 사용할 요구사항과 개발자 코드의 대응 • 그래픽 표기/Graphicla Notation • Booch 표기법 • OMT 표기법 • UML 표기법

5. Booch 표기법 • 창시자인 Rational Software사의 Grady Booch의 이름을 따서 붙여짐

6. OMT 표기법 • 객체관리 기법/Object Management Technology, OMT

7. UML 표기법 • Grady Booch와 James Rumbaugh, Ivar Jacobson, Rebecca Wirfs-Brock, Peter Yourdon 등 여러 사람들이 협력하여 만듦

8. UML Diagrams • 비즈니스 유스케이스 다이어그램 / Business Use Case Diagram • 유스케이스 다이어그램 / Use Case Diagram • 액티비티 다이어그램 / Activity Diagram • 시퀀스 다이어그램 / Sequence Diagram • 협력 다이어그램 / Collaboration Diagram • 클래스 다이어그램 / Class Diagram • 상태차트 다이어그램 / State Chart Diagram • 컴포넌트 다이어그램 / Component Diagram • 디플로이먼트 다이어그램 / Deployment Diagram

9. 비즈니스 유스케이스 다이어그램 • 조직으로부터 제공 받은 기능을 전체적으로 조망할 때 사용 • “비즈니스가 하는 일이 무엇인가?”와 “왜 시스템을 구축하는가?”에 대한 대답 • 조직적인 시각에서 그려진다. • 수동적인 처리절차와 자동적인 처리절차를 구분하지 않는다. • 업무적 유스케이스와 이를 수행하는 액터 간의 상호작용 • 업무적 유스케이스 : 업무가 수행하는 처리절차 • 비즈니스 액터 : 조직 외부에 있지만 조직과 상호작용하는 사람 혹은 사물 • 비즈니스 작업자 : 조직 내부 역할

10. 유스케이스 다이어그램 • 유스케이스와 액터 간의 상호작용(시스템의 요구사항) • 유스케이스 : 시스템의 기능, 사용자 관점에서 본 시스템의 요구사항 • 액터 : 시스템으로부터 정보를 제공하거나 받는 사람 또는 시스템 • 자동화된 프로세스에 초점을 맞춘다.

11. 액티비티 다이어그램 • 시스템 내에서 기능이 어떻게 흘러가는지를 보여준다. • 비즈니스 모델링에서 비즈니스 워크플로우를 보여주기 위해서 사용 • 요구사항 수집시 유스케이스를 통한 이벤트의 흐름을 보여주기 위해 사용 • 워크플로우가 어디서 시작하고 종료하는지를 정의 • 워크플로우가 흘러가는 동안 어떤 액티비티가 발생했는지, 발생한 순서는 어떻게 되는지 정의 • : 액티비티 • : 영향받는 객체 • : 흐름의 분기 • (Transition) : 액티비티 진행 • 수직적 분할구간 : 각 구간별 다른 역할

12. 시퀀스 다이어그램 • 유스케이스를 실행하는 기능의 흐름 • 분석가 : 처리의 흐름 파악 • 개발자 : 객체의 operation 파악 • QAO : 자세한 처리 절차를 통해 테스트 항목을 결정

13. 협력 다이어그램 • 시퀀스 다이어그램과 완전히 같은 정보를 표현 • 시간에 대한 참조 없이 객체와 액터의 상호 작용을 표현 • QAO, System Designer : 객체 간에 처리 과정이 어떻게 분산되어 있는지 파악

14. 클래스 다이어그램 • 시스템 내에 있는 클래스 간의 상호작용을 표시 • 클래스는 정보와 정보에 작용하는 행위를 갖는다. • 클래스의 구조 : 클래스 명, 속성(클래스와 관련된 정보의 조각), 오퍼레이션 • 클래스를 연결하는 선 : 각 클래스 간의 통신 관계 • 개발자 : 클래스를 개발하기 위해 이용 • 분석가 : 시스템의 상세한 내용을 살펴보기 위해 이용 • 시스템 설계자 : 시스템의 설계를 보기 위해 이용

15. 상태차트 다이어그램 • 객체가 존재할 수 있는 다양한 상태를 모델링하기 위한 방법을 제공 • 상태차트는 좀 더 동적인 행위를 정보 제공 • 이벤트 : 한 상태에서 다른 상태로 이동하도록 만듦 • 액션 : 객체가 특정 상태에 있을 때 발생하는 프로세스들 • 복잡한 클래스들에 대해서 작성

16. 컴포넌트 다이어그램 • 시스템 내의 소프트웨어 컴포넌트와 그들 간의 관계, 모델의 물리적인 모습 • 컴포넌트 종류 : 실행 컴포넌트, 코드 라이브러리 • 컴포넌트 간의 종속성 표시 –컴파일 시 종속성과 런타임 시 종속성 파악 • 컴파일 순서 파악

17. 디플로이먼트 다이어그램 • 네트워크의 물리적 배치형태, 다양한 컴포넌트들의 위치 • 프로젝트 관리자와 사용자, 시스템 설계자, 배포 담당자들이 이용.

18. 비주얼 모델링과 소프트웨어 개발 프로세스 • 소프트웨어 개발 프로세스 • 폭포수 모델 • 분석, 설계, 개발, 테스트, 배포 • RUP(Rational Unified Process) • 초기 분석 단계(Inception) • 이런 시스템이 있다면 훨씬 더 좋아지지 않을까? -> 면밀한 조사 • 경영진은 소용시간, 비용, 개발 가능 여부를 확인하려고 한다. • 비즈니스 유스케이스 모델 구축(액티비티 다이어그램 작성 가능) • 반복 계획 – 유스케이스 별로 종속성을 고려하여 반복 계획 • 상세 분석 단계(Elaboration) • 일부 계획안과 분석, 아키텍처 설계 포함 • 개념에 대한 코딩 검증, 테스트 항목의 결정, 설계 시의 의사 결정 등이 포함 • 프로젝트 아키텍처적인 기초 설정에 초점 • 유스케이스를 상세화 • 시퀀스 다이어그램, 협력 다이어그램, 상태 차트 다이어그램이 포함 • 소프트웨어 요구사항 기술서(SRS, Software Requirement Specification)에 수록

19. 비주얼 모델링과 소프트웨어 개발 프로세스 • 구축 단계(Construction) • 상세 분석 단계에서 얻은 아키텍처를 기초로 하여 시스템의 나머지 부분을 구축 • 아직 남아 있는 요구사항에 대한 결정, 소프트웨어 개발 및 테스트가 포함 • 초기 시점에 컴포넌트와 컴포넌트 다이어그램을 작성(종속성 파악) • 코드 생성 • 개발 시 추가된 부분을 모델에 반영 • 컴포넌트 다이어그램, 디플로이먼트 다이어그램 • 전이 단계(Transition) • 완성된 소프트웨어 제품이 사용자 그룹에게 양도되는 시점. • 최종적으로 소프트웨어 제품을 완성하고, 마지막 테스트 수행, 사용자문서작업 완료 • 컴포넌트 다이어그램, 디플로이먼트 다이어그램, 각종 모델의 수정

20. Q / A