Transcript 유비쿼터스, 혁명이 시작됐다.

WAA: J2EE 설계 및 UML
2008.봄학기
E-비즈니스학과 이영곤
1
UML 이란 ?
2
목 차
1장. UML 소개
2장. UML Diagram
3장. UML 적용사례
3
1장 : UML 소개
4
I.UML 소개
UML은 무엇인가?
• UML모델링 언어의 통합을 위한 표준이다.
• UML은 시스템의 모든 분야를 포함한다.
–
–
–
–
데이터 모델링 (Entity Relationship Diagrams)
비즈니스 모델링 (work flow)
객체 모델링
컴포넌트 모델링
• UML은 소프트웨어를 시각화, 명세화, 표현.
• UML은 소프트웨어의 전개발 과정에 걸쳐 모든 프로
세스에서 사용.
5
I.UML 소개
모델링의 중요성
•Model
–모델은 현실을 단순화시킨 것.
–모델은 시스템의 청사진을 제공.
–프로젝트 구성원간 의사 소통.
•Modeling
–모델을 만들어 나가는 작업(The work of making a model)
–전체 프로젝트를 통해 계속 업데이트되는 과정
6
I.UML 소개
모델을 만드는 이유
•
•
시스템에 대한 보다 나은 이해.
모델링을 하는 4가지 목적
–
–
–
–
시스템을 현재 또는 원하는 모습으로 가시화.
모델은 시스템의 구조와 행동을 명세화.
모델은 시스템을 구축하는 틀을 제공.
모델은 결정사항을 문서화.
7
I.UML 소개
UML의 역사
Nov ‘97
97년 11월 OMG의 표준으로 승인
현재 UML1.4
OMG : Object Management Group
8
I.UML 소개
UML과 프로세스
• 프로세스는 무엇을, 언제, 어떻게, 왜 수행해야 하는
지를 설명.
• UML을 사용하는 프로세스의 기본특성
– 유스케이스 위주(Use Case-driven)
– 아키텍처 중심(Architecture Centric)
– 반복적(Iterative)이고 점증적(incremental) 개발
9
I.UML 소개
UML을 사용하는 프로세스는 Use
Case Driven
• UML에서 유스케이스는
–
–
–
–
시스템의 기능적인 요구사항을 정의.
요구사항분석 이후의 모든 단계에서의 개발을 유도한다.
시스템의 필요한 모든 기능이 시스템에서 실현되는 것을 보장한다.
분석단계 동안에 시스템의 필요기능을 정의하고, 검토하는데 사용.
요구사항
유스케이스
분석
설계
구현
테스트
10
2장. UML Diagram
1.
2.
3.
4.
5.
6.
7.
8.
9.
쓰임새도(Use Case Diagram)
클래스도(Class Diagram)
객체도(Object Diagram)
순차도(Sequence Diagram)
협력도(Collaboration Diagram)
상태도(Statechart Diagram)
활동도(Activity Diagram)
컴포넌트도(Component Diagram)
배치도(Deploy Diagram)
11
II.UML Diagram
Use Case Diagram
• Use case다이어그램은 액터와 유스케이스
(use case)의 관계를 도식화한다.
수강 등록부 요청
교수
학생
스케줄관리
지불시스템
커리큘럼관리
등록자
12
II.UML Diagram
Use Case Model
• Use Case
use case
– 사용자와 시스템간의 전형적 인터렉션
– User-visible function
– 다양한 규모의 use case
• Actor
Use case
1..*
– 시스템에 대한 사용자의 역할(Role)
– 직위나 한 개인에 종속된 것은 아님
– non-human actor도 가능
actor
1..*
13
II.UML Diagram
Use Case Modeling : What?
• 목적
– 시스템과 사용자간의 인터렉션 식별
• 각각의 인터렉션(시스템을 사용하는 목적)이 유스케이
스로 모델링 된다.
• 각각의 인터렉션은 액터가 정의되어야 한다.
• 유스케이스는 시스템이 제공하고자 하는 모습에 대한
Snapshot
• 모든 유스케이스를 취합하면 시스템의 외향적 모습이
결정된다.
14
II.UML Diagram
Use Case Modeling : Why?
• 이유
–
–
–
–
고객이 이해하기 쉬운 형태
시스템 요구 사항을 모델링
현업 사람들의 참여 유도
소프트웨어 테스트 시나리오 작성의 기반
15
II.UML Diagram
Use Case Modeling : When?
• 고객으로부터 요구 사항을 추출하는 초기 단
계 동안 수행
– 프로젝트에 대한 개발 사항을 정의하는 과정에서
상위 수준의 유스케이스 모델을 작성.
– 컴포넌트 설계 과정까지 유스케이스 정제과정을
통해 유스케이스를 상세하게 정의해 나감.
16
II.UML Diagram
Use Case Scenario
(or Flow of Events)
유스케이스는 시나리오에 따라 구성됨.
– 시나리오에 대한 서술은 각 유스케이스 다이어그램의 페이지 전후에
텍스트로 이루어짐.
–작성지침
• 유스케이스 이름
• 유스케이스를 시작하는 행위자
• 유스케이스의 목표(Optional)
• 유스케이스가 시작하는데 필요한 선행 조건(Optional)
• 시나리오의 정상적 진행 단계(Main Success Scenario)
• 시나리오의 대안적 진행 단계(Alternative Scenario-Optional)
• 시나리오의 확장점 진행단계(Extensional Scenario -Optional)
• 유스케이스가 끝나는데 필요한 종료 조건(Optional)
17
II.UML Diagram
Use Case Relationship :
Include
- 포함(Include) – 유스케이스가 다른 유스케이스를 포함하
는 관계
• 여러 유스케이스에서 공통으로 중복되는 시나리오가 있
다면 이 시나리오를 따로 분리하여 새로운 유스케이스
로 만듬.
• 사용하려는 유스케이스가 사용되어지는 유스케이스를
필수적으로 포함해야 함.
• 포함된 유스케이스는 절대로 단독으로 존재할 수 없으
며, 전체 유스케이스의 부분으로만 존재.
• 표현
– 포함 관계에 있는 유스케이스 사이를 쇄선으로 잇고, 포
함되어지는 유스케이스 쪽에 화살표 머리를 둠.
– 연결선 위에는 스테레오타입 <<include>> 를 붙여준다.
18
II.UML Diagram
Include Relationship : Sample
예) 자판기 내용물 공급자와 수금원이 포함된 자판기 시스템의 유스케이스
다이어그램
“내용물 보충하기” 유스케이스와 “수금하기” 유스케이스의 시나리오에서 공통으로
중복된 보안장치 해제나 보안장치 설정과 관련된 진행 단계들을 따로 떼어내서 새
로운 유스케이스로 만들고 포함 시켰다.
자판기 시스템
음료수사기
보안장치 설정
사용자
<<include>>
내용물보충하기
<<include>>
공급자
<<include>>
수금하기
수금원
<<include>>
보안장치 해제
19
II.UML Diagram
Use Case Relationship : Extend
– 확장 (Extend) – 유스케이스와 그 유스케이스를 확장한 확장
유스케이스의 관계
• 유스케이스의 시나리오에서, 어떤 조건에 따라 특정한 진행 단
계의 행위(behavior)를 확장하고자, 다른 유스케이스를 참조 하
는 것을 말함.
• 즉, 특별한 조건에서만 수행되는 부 흐름부를 모형화 한 것으
로, 어떤 조건이 부합되어야만 포함되는 유스케이스를 표현함
(선택적).
• 확장된 유스케이스는 절대로 단독으로 존재할 수 없다  단지,
기본 유스케이스에서 특정한 시나리오의 진행 단계의 확장이
기 때문.
• 표현
– 두 유스케이스 사이를 쇄선으로 잇고, 기본 유스케이스쪽에 화살
표 머리를 둔다.
– 연결선 위에는 스테레오타입 <<extend>>를 붙여준다.
20
II.UML Diagram
Extend Relationship : Sample
•
예) 정상적인 흐름에서는 “Place Order” 기본 유스케이스가 실행되지
만 우선 순위(Set Priority)라는 확장점(Extension Point)의 조건을 만
족한다면 “Place Rush Order” 확장 유스케이스가 실행된다.
기본유스케이스
Place Order
Extension Point :
Set Priority
<<extend>>
(Set priority)
확장유스케이스
Place Rush Order
21
II.UML Diagram
Use Case Relationship :
Generalization
– 일반화 (Generalization)
• 유스케이스를 상속하는 것을 의미.
• 상속을 해주는 유스케이스를 “부모 유스케이스” 라 하
고, 상속을 받는 쪽을 “자식 유스케이스” 라 한다.
• 자식 유스케이스는 부모 유스케이스의 모든 행동과 의
미를 물려 받으며, 여기에 자신만의 행동을 추가할 수
있다.
• 부모 유스케이스가 등장하는 곳에 자식 유스케이스를
대신 놓을 수 있다.
• 두 유스케이스 사이를 실 선으로 연결하고, 부모 유스케
이스 쪽에 속이 빈 화살표 머리를 붙인다.
• 일반화 관계는 행위자(Actor) 사이에도 적용할 수 있다.
22
II.UML Diagram
Generalization Relationship :
Sample
Validate
User
Validate Member
Parent Use Case
Child Use Case
23
II.UML Diagram
Actor Generalization
Relationship
부모 행위자
회사원
자식 행위자
자식 행위자
임원
직원
24
유스케이스 작성사례
사례: RFID 리더기를 통해 들어온 데이터는
RFID 미들웨어를 거쳐 일차로 정제되고 저장
된다. 13.56 MHz 리더기에서 데이터가 들어올
경우는 세밀정제 과정을 거쳐야 한다. RFID
미들웨어는 ECSpec에 따라 RFID 클라이언트
에게 EPC 데이터를 전송해준다. RFID 클라이
언트는 ECSpec을 정의하여, RFID 미들웨어에
게 전송한다. ECSpec을 정의하기 위해서는
ECReport에 대한 스펙을 정의해야만 한다.
25
2장. UML Diagram
1.
2.
3.
4.
5.
6.
7.
8.
9.
쓰임새도(Use Case Diagram)
클래스도(Class Diagram)
객체도(Object Diagram)
순차도(Sequence Diagram)
협력도(Collaboration Diagram)
상태도(Statechart Diagram)
활동도(Activity Diagram)
컴포넌트도(Component Diagram)
배치도(Deploy Diagram)
26
II.UML Diagram
Class Diagram
27
II.UML Diagram
Class Diagram
•
•
클래스는 지식 도메인에 기반한 어휘와 용어로부터 만들어짐.
시스템 분석결과에서 명사와 동사에 주의. 명사는 클래스의 이름, 동
사는 모델링한 클래스의 Operation이 될 가능성이 높음.
의뢰인과의 대화중에서 명사
클래스명
속성1
속성2
…
오퍼레이션1
오퍼레이션2
…
책임
(responsibility)
의뢰인과의 대화중에서 명사
클래스 만들때 사용한 명사와 관
련된 명사
(생략가능)
의뢰인과의 대화중에서 동사
(생략가능)
클래스가 의뢰인의 업무에서 하
는 역할에 대한 설명
(생략가능)
28
II.UML Diagram
Class Diagram : Sample
• 예제) 세탁기 클래스
WashingMachine
모델번호 생성
방법은 회사문
서 [DT-100]
문서를 참고하
라.
<<id info>>
제조사명
모델번호
<<기계정보>>
용량
<<세탁물 관련>>
Add세탁물()
Remove세탁물()
Add세제()
• 노트(Note)
추가적인 정보를
덧붙을 때 사용.
대개 속성이나
오퍼레이션에 붙
인다.
입력으로 더러운 옷을 넣으면,
출력으로 세탁된 옷을 내어준다.
스테레오타입을 사용하여 속성 또는 오퍼
레이션 리스트를 구분 지을 수 있다.
• 스테레오타입
UML의 구성요소를 확장하여 새로운 UML
요소를 만들 수 있게 한다.
표기 :<<스테레오타입이름>>
{용량=5 or 8 or 10 Kg}
• 제약(Constraints)
클래스가 따라야 할 규칙을 붙여줄 때 사용.
표기 : { } 안에 자유 형식의 텍스트로 표현
한다.
예제는 세탁기에 수용할 수 있는 세탁물의
용량을 5, 8, 10 Kg으로만 제한함을 나타낸
다.
29
II.UML Diagram
Class Diagram : More
Sample
•
예제) 농구 게임을 클래스 모델링 하기
– 명사 : 볼, 바스켓, 팀, 선수, 가드, 포워드, 센터, 슛, 슛 시간, 3점라
인, 자유투, 파울, 자유투 라인, 코트, 게임시간
– 동사 : 슛하다, 드리블, 패스, 파울, 리바운드
– 이 외에도 개인의 상식을 동원해서 클래스 모델링에 사용할 수 있다.
– 다음은 이런 정보를 바탕으로 만든 Class Diagram이다. 이렇게 만
든 Class Diagram은 나중에 다시 농구팀 감독과 이야기할 때 충분
한 기본 자료로 사용하여 더 많은 정보를 얻어내는데 도움을 줄 것이
다.
볼
선수
지름
부피
이름
키
몸무게
드리블()
슛()
패스()
볼드리블()
볼슛()
볼패스()
리바운드()
가드
대부분 드리블과 패
스를 한다.
포워드
대부분 리바운드와
미들 슛을 한다.
30
II.UML Diagram
Class Diagram
• 앞의 예제에서 만든 Class Diagram에서는 “농구는 어떻다”라
는 기본을 제공하지만, ‘선수가 어떻게 공을 다루는지’, ‘선수
가 어떻게 팀을 이루는지’, ‘어떻게 게임이 이루어지는지’ 등에
대한 정보는 빠져있다.-> 클래스간 관계 필요
• 클래스간의 연결은 다음 8가지 정도로 정리할 수 있다.
–
–
–
–
–
–
–
–
연관(Association)
다중성(Multiplicity)
수식연관(Qualified Association)
반사연관(Reflexive Association)
상속과 일반화(Generalization)
의존관계(Dependency)
집합연관(Aggregation)
복합연관(Composition)
31
II.UML Diagram
Class Diagram : Association
•
연관(Association)
– 클래스가 개념적으로 서로 연결되어 있음을 말한다.
– 예) 선수와 농구팀의 관계
연관이름 및 관계의 방
향
운동한다 ▶
선수
고용인
팀
고용주
역할
선수
고용인
선수
고용인
역할
• 각각의 클래스 마다 역할을 표시할 수 있다.
• 하나의 클래스가 여러 클래스와 연관을
맺을수 있다.
• “▶” 또는 “◀”을 사용하여 관계의 방향을
나타낼 수 있다.
32
II.UML Diagram
Class Diagram : Association(연관)
운동한다 ▶
선수
팀
◀고용한다
은행원
서비스한다 ▶
{순서를 가진다}
선택한다 ▶
고등학교
학생
{or}
선택한다 ▶
고객
대학교
직장
• 클래스 사이에 두개의 연관이 나타날
수 있다.
• 연관에 제약(Constraints) 을 둘 수 있다.
그림에서는 “서비스한다”에 {순서를 가진
다} 라는 제약이 가해져서 고객의 순서대로
은행원이 서비스 한다.
• 또 한가지 제약 은 두개의 연관선 사이를
점선으로 잇고 이 위에 {or} 로 표기하는
{or} 관계이다. 그림은 고등 학생이 진로를
정하는 상황을 모델링 한 것이다.
33
II.UML Diagram
Class Diagram :
Association Class
선수
운동한다 ▶
계약
박찬호:선수
팀
협상된다 ▶
운동한다 ▶
매니저
• 연관클래스는 연관의 속성과
오퍼레이션을 모델링 할 때 사용한다.
연관 클래스는 연관선과 점선으로
연결되며, 다른 클래스와 연관을
가질 수도 있다.
LA 다저스:팀
• 객체가 클래스의 인스턴스인 것처럼, 연관도 자신의 인스턴스를 가질
수 있다. 어떤 특정한 선수가 특정한 팀에 소속되어 있는 관계를 생각
하면, 이때의 “운동하다” 연관 관계를 링크(link)라고 부른다. 링크는
두 객체를 선으로 이어서 나타내며, 객체에 밑줄 긋듯이 링크에도
밑줄을 긋는다.
34
II.UML Diagram
Class Diagram :
Multiplicity(다중성)
• 다중성
– 연관되어 있는 두 클래스 사이에서 한 클래스의 객체와 관계를 가
질수 있는 다른 클래스의 객체 개수. 이것을 다이어그램에서 나타
내면 해당 클래스 가까이(그리고 연관선 위)에 객체의 수를 써준
다.
– 예를 들면, 팀의 입장에서 보면 다섯명의 선수와 연관되어 있지만
선수의 입장에서 보면 한 팀과 연관되어 있다는 것이다.
선수

운동한다 ▶
1
팀
표기


5
UML은 “more” 와 “many”를 표현하는 기호로서 ‘*’ 를 사용한다.
예)



1..*  1또는 그이상 (one or more)
2..7  2이상 7까지 (2 through 7)
5,7  5 또는 7 (5 or 7)
35
II.UML Diagram
Class Diagram : Qualifier
• Qualifier 연관
– 일 대 다 (one-to-many)의 다중성을 가진 연관 관계에서 한 객체
가 특정한 객체를 가려내어야 하는 상황 (이것을 lookup 이라고
한다)이 발생한다.
– 하나의 클래스의 객체가 다른 클래스의 객체를 선택하기 위하여
특정한 속성의 식별자를 사용하는데, 이러한 식별 정보를
Qualifier라고 하여 작은 사각형으로 나타낸다.
– Qualifier는 일 대 다 (one-to-many) 다중성을 일 대 일 (one-toone) 다중성으로 줄이는데 효과적이다.
– 다음은 “호텔 객실 배당 사무원”의 “확인번호”를 통해예약을 찾는
예이다.
호텔 객실
배당 사무원
확인번호
1
찾는다 ▶
*
예약
Qualifier
36
II.UML Diagram
Class Diagram : Reflexive
•
Reflexive 연관
– 클래스는 자기 자신과 연관을 가질 수도 있다. 하나의 클래스가 여러가지
의 역할을 가질 때 “재귀연관”을 갖도록 한다.
– 예를 들면, 탑승자는 운전자도 될 수 있고 승객도 될 수 있다.
– 예) 운전자의 역할을 맡은 탑승자는 승객의 역할을 맡은 탑승자를 0명이
상 4명까지 실어 나를 수 있다.
1
운전자
운전한다 ▼
탑승자
0..4 승객
37
II.UML Diagram
Class Diagram : Inheritance
•
•
•
한 클래스는 다른 클래스로부터 속성과 오퍼레이션을 물려 받을 수 있다. 이것
을 객체지향 개념에서는 “상속” 이라 하고, UML에서는 “일반화” 라 한다.
상속 관계에서 상속을 받는 쪽을 Child Class 또는 Sub Class 라고 하고, 상속
을 해주는 쪽을 Parent Class 또는 Super Class 라고 한다.
Sub Class 에서 Super Class 쪽으로 속이 빈 화살표(
)를 연결한다. 이
러한 타입의 연결 관계를 “…의 일종(is a kind of)” 라고 부른다.
Root
Class
양서류
Leaf
Class
동물
포유류
말
Super
Class
파충류
Sub Class
• 상속 관계를 모델링 할 때에는, 반드시 서브
클래스가 수퍼 클래스에 대해 “is a kind of”
관계를 가지도록 만들자.
• 만약 두 클래스가 이 관계로 맺어지지 않는
다면, 차라리 다른 타입의 관계를 맺어주는
것이 더 낫다.
• Root Class: Super Class를 가지지 않는 클래스
• Leaf Class : Sub Class를 가지지 않는 클래스
38
II.UML Diagram
Class Diagram :
Abstract Class
•
•
어떤 Sub Class의 Super Class가 있을 때, 만약 이 Super Class의 구
체적인 인스턴스(Instance)를 만들 필요가 없을 때에는 “추상 클래스”
로 만들자. 즉, 클래스의 객체를 생성하지 않는 클래스를 “추상 클래
스” 로 만든다.
표기 : 클래스명을 이탤릭으로 쓴다.
선수
이름
키
몸무게
볼_드리블()
볼_패스()
리바운드()
슛()
가드
슛()
포워드
슛()
센터
슛()
39
II.UML Diagram
Class Diagram : Dependency
• 한 클래스가 다른 클래스를 사용하는 관계를 말한다. 특히 한
클래스의 Operation이 다른 클래스를 사용하는 시그너쳐를 보
일 때 이다.
• 예를 들면, “시스템” 클래스 와 “폼” 클래스가 있는데, “시스템”
클래스는 ‘폼_출력(form:폼)’ 이라는 Operation을 가지고 있다.
이 “시스템”이 화면에 표시해 주는 서식은 전적으로 사용자가
선택한 “폼” 클래스에 따라 달라진다. 이 상황을 UML로 표기
하려면 “의존 대상”이 되는 클래스를 향해 점선으로 긋고 화살
표 머리를 붙여주면 된다.
시스템
폼_출력(form:폼)
폼
40
II.UML Diagram
Class Diagram : Aggregation
•
집합연관 (Aggregation)
– 하나의 클래스가 여러 개의 컴포넌트 클래스로 구성되어 있는 경우가 있
다. 즉, 컴포넌트 클래스와 전체 클래스가 “부분-전체” 연관 관계를 가질
때 집합연관이 된다.
– 표기 : 컴포넌트 클래스와 전체 클래스를 선으로 잇고, 빈 마름모꼴을 전
체 클래스 쪽에 붙여서 나타낸다.
• 집합연관에 대한 제약
OR 관계를 모델링 하려면, 두개
의 집합 연관선 사이를 점선으로
이은 다음에 {or}을 써주면 된다.
컴퓨터
1
1
{or}
헤드셋
2
스피커
1
1
1
본체
모니터
키보드
1
마우스
41
II.UML Diagram
Class Diagram : Composition
•
복합연관 (Composition)
–
–
강한 집합 연관으로써 각 컴포넌트 클래스가 오직 하나의 전체 클래스에서만 의미
를 가질 때, 복합연관으로 표현한다.
표기 : 각각의 컴포넌트는 전체 클래스 쪽으로 향하여 안이 채워진 마름모 꼴의 화
살표를 연결한다.
커피테이블
1
1
테이블 판
4
다리
42
II.UML Diagram
Class Diagram :
Interface and Realization
•
•
•
어떤 클래스들이 동일한 Super Class와 관계를 가지지 않았는데, 같은
signature를 가진 Operation이 존재한다면 이것은 Operation의 재사용으로 간
주된다.
이런 재사용을 위한 Operation의 집합을 인터페이스(Interface)라고 한다. 인
터페이스는 클래스의 일정한 행동(behavior)을 나타내는 Operation의 집합으
로, 다른 클래스에서 사용될 수 있다.
자바에서 인터페이스는 method의 prototype만 선언되어 있고, 인터페이스를
구현 (Implementation)한 클래스에서 method를 정의한다. 이것을 UML에서
는 실체화(realization)이라 한다.
• 타자기 의 행동을 실체화한 키보드 클래스
키보드
Ctrl()
Alt()
PgUp()
PgDown()
<<realization>>
<<Interface>>
타자기
• 인터페이스를 실체화한 클래스를
나타내는 간단한 방법
타자기
키보드
PgUp()
pgDown()
43
II.UML Diagram
Class Diagram : Visibility
• 가시성 (visibility)
–
해당 클래스(혹은 인터페이스)의 속성과 오퍼레이션을 들여다 볼
수 있는 범위.
– 표기 : 자바 기준
• “+” – public : 모든 클래스에서 접근 가능
• “#” – protected : Package member Class 와 Sub Class
만 접근 가능
• “-” – private : member Operation만 접근 가능
• None - Package member Class 만 접근 가능
텔레비젼
- 제조사명
# 모델번호
+ 채널변경()
+ 음량변경()
- 화면출력()
44
II.UML Diagram
Class Diagram : 대학 도서관
• 학생 및 교수: 임의의 시점에 대학 도서관을 이용할 수 있다.
도서를 대출하고자 하는 경우 학생증을 제시해야 하고, 반납일
자를 명기해야 한다. 도서반납을 연체하는 경우에는 연체료를
지불해야 한다.
• 도서관 직원: 대출자가 대출을 원하는 경우, 대출자의 신분을
조회하고 현재 반납 연체인 도서가 있는지 확인한다. 대출자가
희망하는 도서가 대출가능한 상태인지를 먼저 확인한 후 문제
가 없는 경우 반납일을 확인하고 도서를 대출해 준다.
• 도서대출관리 시스템은 대출자가 연체한 경우, 연체료를 자동
으로 계산할 수 있다. 또한, 그 대출자와 관련된 정보와 지금까
지의 도서 대출 리스트를 보여줄 수 있어야 한다.
45
2장. UML Diagram
1.
2.
3.
4.
5.
6.
7.
8.
9.
쓰임새도(Use Case Diagram)
클래스도(Class Diagram)
객체도(Object Diagram)
순차도(Sequence Diagram)
협력도(Collaboration Diagram)
상태도(Statechart Diagram)
활동도(Activity Diagram)
컴포넌트도(Component Diagram)
배치도(Deploy Diagram)
46
II.UML Diagram
Sequence Diagram
registration
form
schedule
form
available
courses
Jon : Student
1:enter id
2:validate id
3:enter current semester
4:create new schedule
5:display
6:get course
47
II.UML Diagram
Sequence Diagram
•
순차 다이어그램이란?
–
–
상태 다이어그램이 촉발 사건에 따른 단일 객체의 상태 변화를 표현한 것이라면, 순
차 다이어그램은 여러 객체들이 시간 경과에 따라 객체 상호간 교류 과정을 표현한 것.
구성
•
•
•
–
객체(Object) : 사각형으로 나타내며 이름에 밑줄이 들어가 있다.
메시지(Message) : 실선 화살표로 그려진다.
시간 : 진행 상황을 나타내기 위하여 수직선으로 그린다.
객체
•
•
•
•
순차 다이어그램의 가장 위 부분에 위치, 왼쪽에서 오른쪽으로 배열.
배열순서 – 다이어그램을 간략하게 하는 방향으로 기준을 삼는다
각 객체로부터 아래로 뻗어 가는 점선은 객체의 생명선(lifeline)이라 불린다.
생명선을 따라 좁다란 사각형이 나타나는데, 이 부분은 실행(activation)이라 한다.즉, 객체
가 수행되고 있음을 나타낸다. 사각형의 길이는 오퍼레이션의 실행 소요 시간을 나타낸다.
객체1
객체2
객체3
객체의 생명선
오퍼레이션의 실행 소요 시간
객체의 생명선
48
II.UML Diagram
Sequence Diagram : Message
– 메시지
•
•
•
•
한 객체에서 다른 객체로 전송.
한 객체의 생명선에서 다른 객체의 생명선으로 이동하는 것으로 표현.
객체는 자기 자신에게 메시지를 보낼 수 있다.
종류
–
–
–
단순(simple)메시지 – 한 객체에서 다른 객체로 제어흐름이 이동하는 것.
동기(synchronous) 메시지 – 메시지 전송 후 수신 객체로 부터 그 메시지를 받았다는
답변이 와야 자신의 작업을 계속할 수 있음.
비동기(asynchronous) 메시지 – 메시지 전송 후 수신 객체로부터 답신을 기다리지 않
고 자신을 작업을 계속 함.
• 표기
Simple Message
Synchronous Message
Asynchronous Message
49
II.UML Diagram
Sequence Diagram :
Time Axes
• 시간을 수직 방향으로 표현
• 시간의 흐름은 위에서 아래로 흐른다.
• 객체 표기는 객체명:클래스파이어(Classfier)명으로 표기한다.
객체1
객체2
객체3
Actor
동기 메시지
비동기 메시지
자기 자신에
게 동기 메시
지 보냄
50
II.UML Diagram
Sequence Diagram : Sample
•
예제) 자판기에서 “음료수 뽑기”
– 객체를 골라내면
• 프론트 : 음료수 자판기가 고객과 대화하는 유일한 인터페이스, 판매기 앞판에
있음.
• 금전 등록기 : 돈을 체크하고 등록함.
• 디스펜서 : 음료수를 따르고 내어줌.
– 처리과정을 써보면 다음과 같다.
•
•
•
•
•
•
1.
2.
3.
4.
5.
6.
소비자가 자판기의 프론트 앞에 서서 투입구에 돈을 넣는다.(Insert)
소비자가 마실 음료수를 고른다.(Select)
돈이 금전등록기에 들어간다.(Send)
등록기는 선택된 음료가 디스펜서에 들어 있는지를 체크한다.
선택된 소다가 준비되어 있고, 등록기는 현금 잔고를 갱신한다.
등록기는 디스펜서를 사용하여 소다를 자동 판매기의 프론트로 보낸다.
– 이 예는 “음료수 사기” 유스케이스에서 단지 한 개의 시나리오(즉, 하나의
인스턴스)에 대하여 그려지기 때문에, 이 다이어그램을 인스턴스 순차 다
이어그램이라고 부른다.
51
II.UML Diagram
Sequence Diagram :
Sample
:프론트
:금전등록기
:디스펜서
Insert(input)
User
Select(Selection)
Send(input)
Deliver(Selection)
Deliver(Selection)
52
II.UML Diagram
Sequence Diagram : Sample
•
예제) 자판기에서 “음료수 뽑기” 의 예에서 또 다른 시나리오를 가정.
선택된 음료수가 다 떨어진 경우 또는 소비자가 넣은 돈이 음료수 값
과 맞지 않을 때. 다음은 ‘액수에 맞지 않는 경우’ 의 시나리오 이다.
– 1. 등록기는 소비자가 투입한 돈의 액수(input)가 음료수의 값(price)과 맞
는지 체크한다.
– 2. 만일 액수가 음료수 값보다 많으면, 등록기는 차액을 계산하고 그 만큼
의 현금 잔고가 있는 체크한다.
– 3. 만일 차액 만큼의 현금이 잔고(cash reserve)에 남아 있다면, 등록기는
거스름돈(change)을 내어주고 나머지 동작은 그전과 똑같이 진행한다.
– 4. 만일 차액 만큼의 현금이 잔고에 남아 있지 않으면, 등록기는 소비자가
투입한 돈을 그대로 돌려주고 “맞는 액수의 돈을 넣어 주세요”란 메시지
를 표시한다.
– 5. 만일 소비자가 투입한 돈의 액수가 음료수 값보다 적으면, 등록기는 아
무것도 하지 않고 돈이 더 들어올 때까지 대기한다.
– 조건문을 표현하기 위해서는 대괄호 [ ] 안에 조건을 써주고, 이것을 메시
지 화살표 위에 놓으면 된다.
53
II.UML Diagram
Sequence Diagram :
Sample
•
“액수가 맞지 않는 경우” 의 시나리오
:프론트
:금전등록기
:디스펜서
Insert(돈)
Select(선택)
Send(돈)
[돈 = 가격]
User
Deliver(선택)
[잔돈이 있다면]
잔돈을 돌려줌
[돈 > 가격]
잔돈이 있는지 체
크
[잔돈이 있다면]
[잔돈이 없다면]
Return(돈)
Deliver(선택)
54
II.UML Diagram
Sequence Diagram :
Object Creation & Loop
•
순차 내에서 객체 생성
–
–
–
–
•
기존의 객체 표현 방법처럼, 이름이 붙은 사각형으로 표현.
보통의 객체처럼 시퀀스의 다이어그램의 위에 두지 않는다.
생성된 객체는 이것이 생성된 시간과 대응되는 위치에 놓는다.
이 객체를 생성한 메시지는 “create()”라는 레이블이 붙으며, 여기서 ()는
오퍼레이션을 의미한다. <<create>> 스테레오 타입을 사용할 수도 있
다.
“while” 문의 표현
– 조건의 표현인 [ ] 왼쪽에 ‘*’ 를 붙인다.
객체 1
객체 2
User
Create()
*[조건]
객체 3
55
II.UML Diagram
Sequence Diagram :
Recursion
•
재귀호출(recursion) 나타내기
– 객체가 자기 자신을 호출하는 구조의 오퍼레이션을 가지는 경우가 있는데,
이러한 오퍼레이션을 재귀호출(recursion)이라고 한다.
– 예제) 어떤 시스템에 계산기 객체가 포함되어 있다고 하자. 이 객체의 오
퍼레이션 중 하나가 이자(interest)를 계산 하는 것이라고 가정하고, 지난
기간을 모두 종합한 복리(compound interest)를 계산하기 위해 이 계산기
객체의 오퍼레이션은 각 기간의 복리를 사용하여 계속 자신을 호출해야
한다. 이것을 Sequence Diagram으로 표현하면 다음과 같다.
– 표현
• 실행 사각형에다가 작은 사각형을 그리고, 오퍼레이션을 나타내는 메시지 화살
표를 실행 사각형에서 작은 사각형 쪽으로 향하도록 한다.
객체 1
56
2장. UML Diagram
1.
2.
3.
4.
5.
6.
7.
8.
9.
쓰임새도(Use Case Diagram)
클래스도(Class Diagram)
객체도(Object Diagram)
순차도(Sequence Diagram)
협력도(Collaboration Diagram)
상태도(Statechart Diagram)
활동도(Activity Diagram)
컴포넌트도(Component Diagram)
배치도(Deploy Diagram)
57
II.UML Diagram
Collaboration Diagram
2:validate id
1:enter id
3:enter current semester
registration
form
Jon : Student
5:display
available
courses
schedule
form
6:get course
58
II.UML Diagram
Collaboration Diagram
•
협력 다이어그램이란?
– 객체 사이의 연관 관계 뿐만 아니라, 각 객체들이 주고 받는 메시지들을
공간에 따라 배열 한 것.
– 객체 다이어그램의 확장으로 볼 수 있다.
•
순차 다이어그램과의 유사점 및 차이점
– 유사점 : 순차 다이어그램처럼 객체들 사이의 교류를 보여준다.  따라서,
순차와 협력 다이어그램의 상호 변환이 쉽다.
– 차이점 :
• 순차 다이어그램: 객체간의 교류를 시간의 순서에 초점을 두어 표현.
• 협력 다이어그램 : 공간에 따라 배열시킴  교류를 수행하는 객체들의 전체적
인 조직과 상황(Context)에 초점을 맞춤.
•
표현
– 두 객체 사이를 연관 선으로 연결.
– 연관선 위에 메시지가 전달되는 객체 쪽으로 화살표 방향을 가진 선을 긋
는다.
– 메시지의 끝에 ‘()’ 붙임으로써 매개 변수를 넣을 수 있도록 함.
59
II.UML Diagram
Collaboration Diagram
•
예제) 자판기에서 “음료수 뽑기” 순차 다이어그램을 협력 다이어그램으
로 표현.
•
•
•
•
•
1. 소비자가 자판기의 프론트 앞에 서서 투입구에 돈을 넣는다.(Insert)
2. 소비자가 마실 음료수를 고른다.(Select)
3. 돈이 금전등록기에 들어간다.(Send)
4. 등록기는 선택된 음료가 디스펜서에 들어 있는지를 체크한다.
5. 가장 간단한 시나리오이기 때문에, 선택된 소다가 준비되어 있고, 등록기는
현금 잔고를 갱신한다.
• 6. 등록기는 디스펜서를 사용하여 소다를 자동 판매기의 프론트로 보낸다.
insert(input, selection)
User
:프론트
1 : add(input, selection)
3 : deliver(selection)
:디스펜서
:금전등록기
2 : deliver(selection)
60
II.UML Diagram
Collaboration Diagram
•
예제) “음료수 뽑기” 예에서 “액수가 맞지 않는 경우”를 고려해 보자. 물론, 이
전의 순차 다이어그램을 참고하면서 보도록 한다. 만들 협력 다이어그램은 다
음의 조건을 처리해야 한다.
–
–
–
1. 사용자가 음료수 가격보다 많은 돈을 투입한 경우.
2. 음료수 자판기가 충분한 거스름 돈을 가진 경우.
3. 음료수 자판기가 충분한 거스름 돈을 가지지 않은 경우.
insert(input, selection)
User
4 : deliver(selection)
:디스펜서
:프론트
1 : add(input, selection)
[잔돈이있다면] 3.2 : return(잔돈)
:금전등록기
[input = price] 2.1 : deliver(selection)
[잔돈이있다면] 3.1 : deliver(selection)

[input > price]
2.2 : 잔돈유무검사(input, price)
각 단계의 소수점 숫자의 표현 : 동일한 단계에서 여러 시나리오가 중첩(nesting) 됨을 나타냄.
61
II.UML Diagram
Collaboration Diagram
•
•
•
while 문을 표현 : *[조건]
객체의 생성 : 객체를 생성하는 메시지 앞에 스테레오타입
<<create>> 붙인다.
여러 객체로 메시지 전송하기
– 메시지를 받는 객체 사각형을 사선 방향으로 쌓는다.
– 객체로 전송되는 메시지에는 ‘*’ 가 붙은 대괄호 조건문을 붙여준다.
– 만약, 메시지 전송의 순서가 필요하다면, 조건 문에 1… n 처럼 순서의 의
미를 표시함.
– 예제) 은행원이 여러 창구에 늘어선 고객들을 순서대로 맞아 서비스를 한
다.
:은행원
*[순번 = 1...n] 1 : 서비스()
:고객
62
II.UML Diagram
Collaboration Diagram
•
반환된 결과 나타내기
– 메시지는 어떤 객체로 하여금 오퍼레이션을 수행하고 그 값을 반환하게
하는 요청일 수 있다.
– 표현 : “반환되는 값의 이름 := 오퍼레이션”
– 예제) 가정주부가 계산기 객체에게 지출 항목을 더하여 총 합계를 요구한
다.
:가정주부
1: 총지출합계 := 계산(지출항목)
수식의 우변( 계산(지출항목) )을 메시지-시그너쳐
(message-signature) 라고 한다.
:계산기
63
2장. UML Diagram
1.
2.
3.
4.
5.
6.
7.
8.
9.
쓰임새도(Use Case Diagram)
클래스도(Class Diagram)
객체도(Object Diagram)
순차도(Sequence Diagram)
협력도(Collaboration Diagram)
상태도(Statechart Diagram)
활동도(Activity Diagram)
컴포넌트도(Component Diagram)
배치도(Deploy Diagram)
64
II.UML Diagram
State Diagram
•
상태 다이어그램(State Diagram) 이란?
–
–
–
–
•
사건이나 시간에 따라 시스템 객체의 상태 변화를 표현한 그림.
“단일 객체”의 상태를 나타냄.
시스템의 변화를 잡아내기 위하여 사용.
분석가, 설계자, 개발자 들이 시스템내의 객체 행동을 이해하는데 큰 도움을 줌.
표현
–
–
–
–
상태의 표현
상태 전이의
상태 전이의
상태 전이선
: 모서리가 둥근 사각형으로 표현
시작점 : 속을 칠한 원으로 표현.
종료점 : 속을 칠한 원을 둘러싼 원으로 표현
: 화살표 머리가 달린 실선
상태정보
시작점
종료점
65
II.UML Diagram
State Diagram
•
상태 아이콘에 넣는 정보
– 이름, 속성, 오퍼레이션 의 세 영역으로 나누어 상세한 정보 넣을 수 있다.
•
•
•
•
이름 – 상태 이름(필수)
속성 – 상태 변수(옵션). 타이머나 카운터처럼 상태 진행에 도움을 주는 데이터.
오퍼레이션 – 활동(Activity – 옵션). 사건(event)과 동작(action)으로 이루어짐.
동작(event[guard]/action) – 전이(transition)와 연관. 빨리 발생하는 프로세스
로 간주되며 인터럽트를 받지 않는다.
• 활동(do/activity) – 상태(State)와 관련, 오래 지속될 수 있으며 사건(event)이
인터럽터를 일으킬 수도 있다.
상태 이름
활동
상태 변수들
자주 쓰이는 세가지
진입(entry) – 시스템이 상태로 들어갈 때 일어남
탈출(exit) – 시스템이 상태에서 빠져나올 때 일어남
활동들
활동(do) – 시스템이 상태 안에 있는 동안 일어남
66
II.UML Diagram
State Diagram
•
예) 팩스 기계의 상태 정보의 표현과 전이
전송
(Faxing)
대기(Idle)
Date = 현재날짜
Date = 현재날짜
Time = 팩스 전송 시작 시간
Time = 현재 시간
Phone Number = 소유주 전화번호
Phone Number = 소유주 전화번호
Owner = 소유주 이름
Owner = 소유주 이름
Entry / 수신팩스번호 입력
Entry / 전송완료
Exit / 전송완료
Exit / 전송 시작
Do / 날짜 붙이기
Do / 날짜 보이기
Do / 시간 붙이기
Do / 시간 보이기
Do / 송신측 전화번호 붙이기
Do / 소유주 이름 붙이기
Do / 페이지 매기기
67
II.UML Diagram
State Diagram
•
상태 전이 선에 추가 되는 정보 : 사건과 동작
– 추가되는 정보 : 전이가 일어나는 원인을 제공하는 사건(촉발사건-trigger
event)과 실제로 수행되어 상태변화를 일으키는 연산(동작-action).
– 사건과 동작은 상태 전이 선에 가깝게 붙여준다.
– ‘/’ 를 사용하여 사건[조건]/동작을 구분 시켜준다.
– 활동을 종료했기 때문에 일어나는 전이  촉발없는 전이(triggerless
transition)라 함.
– 예) GUI의 상태 다이어그램
스위치 ON
초기화
/ 전원공급()
작동
스위치 Off
종료
/ 전원중단()
Do / 부팅
68
II.UML Diagram
State Diagram
•
상태 전이 선에 추가되는 정보 : 전이 조건
–
–
–
–
어떤 조건에 따라 상태가 전이 될 때.
조건에 따른 상태 전이의 분기가 일어날 때.
‘[ ]’ 를 사용하여 조건(Guard)을 명시함.
예) 앞의 GUI 예에서 어떤 조건을 만족하면 스크린세이버가 작동하는 상
태로 됨
스위치 ON
초기화
스위치 Off
작동
/ 전원공급()
종료
/ 전원중단()
Do / 부팅
[시간초과 했다면]
키누르기 또는 마우스움직이기/
화면보호기
작동
69
II.UML Diagram
State Diagram
•
•
하위상태 : 상태 안에 상태가 있을 때, 안에 있는 상태를 말함.
순차적 하위 상태
– 하위 상태의 전이가 순차적으로 이루어 짐.
– 예) 앞의 GUI 예제에서 [작동] 상태의 하위 상태 전이를 나타낸다. 즉,
[작동] 상태인 동안 사용자의 입력을 화면에 표현 하는 하위 상태들의 전
이 과정을 표현한 것이다.
작동
사용자
입력대기
입력
사용자
사용자 입력을
입력을 등록
화면에 나타냄
70
II.UML Diagram
State Diagram
•
동시적 하위 상태
– 하위 상태의 동시 진행성을 표현.
– 동시 진행 하는 순차적 하위 상태를 점선으로 구분 지음.
– 예) 앞의 GUI 예제에서 “사용자 입력을 화면에 표현”하는 하위 상태 전이
단계와 더불어 “시스템 내의 시간을 정해진 간격마다 화면에 표현” 하는
또 다른 하위 상태 전이가 일어나는 과정을 나타냄. 즉, 우리가 워드를 치
는 동안 윈도우의 “시작 메뉴바” 오른쪽에 시계는 분 마다 바뀐 값을 표현
하는 것을 말함.
작동
사용자
입력대기
/입
력
시스템
Clock 체크
사용자
사용자 입력을
입력을 등록
화면에 나타냄
[시간간격 초과]
시간 화면 갱신
71
2장. UML Diagram
1.
2.
3.
4.
5.
6.
7.
8.
9.
쓰임새도(Use Case Diagram)
클래스도(Class Diagram)
객체도(Object Diagram)
순차도(Sequence Diagram)
협력도(Collaboration Diagram)
상태도(Statechart Diagram)
활동도(Activity Diagram)
컴포넌트도(Component Diagram)
배치도(Deploy Diagram)
72
II.UML Diagram
Activity Diagram
• 업무과정(Business Process)를 표현하거나 오퍼레
이션(Operation)의 알고리즘을 효과적으로 나타내
는데 유용하게 사용된다.
• Flowchart와 상당히 흡사하다.
• State Diagram의 확장으로 볼 수 있다.
• 해당 활동내의 처리가 끝나면 그 다음의 활동으로
자동적으로 옮겨진다.
73
II.UML Diagram
Activity Diagram : 표기법
시작 표기
활동
활동 표기
진행 표기
분기 표기
활동
활동
종료 표기
74
II.UML Diagram
Activity Diagram
•
동시경로
활동
Fork
활동1
활동2
동시에 실행 되었
다가 하나로 모이
는 두개의 처리 경
로로 활동 전이를
분리해야 할 경우
굵은 선을 긋고, 이
선을 기준으로 하
여 처리 경로를 그
려주면 된다.
Join
75
II.UML Diagram
Activity Diagram : Sample
•
예제1) 짜장면 집에서 주문하는 과정.
1.
2.
3.
4.
5.
6.
손님이 메뉴에서 음식을 고른다.
웨이터를 부르고, 주문한다.
웨이터는 주방장에게 주문사항을 알린다.
만약 주문한 음식의 재료가 떨어졌으면 주방장은 웨이터에게 알린다.
웨이터는 손님에게 알린다.
다시 1 번부터 반복한다.
76
II.UML Diagram
Activity Diagram : Sample
• Activity Diagram
메뉴에서 음식 고르기
웨이터 호출 및 주문
손님에게 알림
주방장에게 알림
[음식의 재료가 떨어졌다]
웨이터에게 알림
[만들 수 있다]
77
II.UML Diagram
Activity Diagram – Swimlane
•
활동 다이어그램에 역할(role)을 표시함으로써 처리 과정에 속해있는
각 활동의 책임이 누구에게 있는지를 나타낼 수 있다.
손님
웨이터
주방장
메뉴에서 음식 고르기
웨이터 호출 및 주문
주방장에게 알림
[만들 수 있다]
[음식의 재료가 떨어졌다]
웨이터에게 알림
손님에게 알림
78
2장. UML Diagram
1.
2.
3.
4.
5.
6.
7.
8.
9.
쓰임새도(Use Case Diagram)
클래스도(Class Diagram)
객체도(Object Diagram)
순차도(Sequence Diagram)
협력도(Collaboration Diagram)
상태도(Statechart Diagram)
활동도(Activity Diagram)
컴포넌트도(Component Diagram)
배치도(Deploy Diagram)
79
II.UML Diagram
Component Diagram
Register.exe
Billing.exe
Billing
System
People.dll
User
Course.dll
Course
Student
Course
Professor
Course
Offering
80
II.UML Diagram
Component Diagram
• 컴포넌트 다이어그램(Component Diagram) 이란?
– 컴포넌트는 물리적이고 교체 가능한 시스템의 한 부분이며. 정해
진 인터페이스를 준수하고 실현한다.
– 컴포넌트는 일반적으로 클래스, 인터페이스, 그리고 협력과 같이
서로 다른 논리요소들을 물리적으로 패키지화 한 것이다.
• 컴포넌트와 클래스
– 클래스는 논리적으로 추상화한 것을 나타내며, 컴포넌트는
비트로된 세계에 있는 물리적인 것을 나타낸다.
– 컴포넌트는 노드에 존재할 수 있지만 클래스는 그렇지 않다
– 클래스는 속성과 오퍼레이션을 직접 가질 수 있지만, 컴포
넌트는 자신의 인터페이스를 통해서만 접근할 수 있는 오퍼
레이션들만 갖는다.
• 표현
– 컴포넌트는 탭이 달린 직사각형으로 표현한다.
– 이름 : 다른 컴포넌트와 구분된다.
image.java
81
II.UML Diagram
Component Diagram – 인터페이스
• 인터페이스
– 오퍼레이션의 모음으로 클래스나 컴포넌트의 서
비스를 명세화하는데 사용된다.
– 컴포넌트 기반 분산객체시스템(COM+,EJB)은 컴
포넌트를 함께 묶는 수단으로 인터페이스를 사용
한다.
의존관계
인터페이스 실체화
image.java
Component.java
ImageObserver
82
II.UML Diagram
Component 와 Interface표현
• 생략된 모습(아이콘으로 인터페이스 표현)
image.java
Component.java
ImageObserver
ImageObserver
• 확장형태
의존
인터페이스 실체화
<<interface>>
ImageObserver
image.java
Abort:int{final static}
Error:int{final static}
Component.java
imageUpdate():Boolean
83
2장. UML Diagram
1.
2.
3.
4.
5.
6.
7.
8.
9.
쓰임새도(Use Case Diagram)
클래스도(Class Diagram)
객체도(Object Diagram)
순차도(Sequence Diagram)
협력도(Collaboration Diagram)
상태도(Statechart Diagram)
활동도(Activity Diagram)
컴포넌트도(Component Diagram)
배치도(Deploy Diagram)
84
II.UML Diagram
Deploy Diagram
• 배치 다이어그램(Deploy Diagram) 이란?
– 배치다이어그램은 객체지향 시스템의 물리적인 관점을 모
델링하는데 사용된다.
– 실행처리 능력을 가지는 노드의 구성과 그 노드에 존재하는
컴포넌트들을 나타낸다.
– 배치다이어그램은 실행노드와 그 노드에 존재하는 컴포넌
트의 구성을 나태내는 도해이다.
• 표현
– 노드를 입방체(Cube)로 표현한다.
workstation
85
II.UML Diagram
Deploy Diagram – 모델1
• 프로세서와 장치의 모델링
Client A
<<TCP/IP>>
Application
Server
<<Ethernet>>
Database
Server
<<TCP/IP>>
Client B
86
II.UML Diagram
Deploy Diagram – 모델2
• 컴포넌트 분산의 모델링
Client PC
NetDrv
<<TCP/IP>>
Server
AppClnt
Win98
Admin PC
<<RS-232-C>>
BackupStation
AdPgm
87
3. UML 적용사례
•사례1:이력게시판
•사례2:고객지원접수시스템
88
III. UML 적용사례
사례1:이력게시판 적용사례
UseCase명
Actor
설명
BoardList
사용자,교직원,관리
자
게시판 목록보기 기능
BoardInsert
사용자,교직원,관리
자
게시판 자료등록 기능
BoardUpdate
사용자,교직원,관리
자
게시판 자료변경 기능
BoardDelete
사용자,교직원,관리
자
게시판 자료삭제 기능
BoardReply
사용자,교직원,관리
자
게시판 답변쓰기 기능
BoardRole
관리자
게시판 권한 체크 기능
BoardConfig
교직원,관리자
게시판 환경설정 기능
89
III. UML 적용사례
사례1: 이력게시판
Use Case Diagram
이력게시판
사용자
BoardList
BoardInsert
<<include>>
<<include>>
사용자
교직원
BoardUpdate
<<include>>
BoardRoll
<<include>>
BoardDelete
관리자
BoardReply
BoardConfig
관리자
교직원
90
III. UML 적용사례
이력게시판 : Class Diagram
91
III. UML 적용사례
이력게시판:Sequence
Diagram
cambo-insert :
InsertCambo
cambosb :
CamboSB
camboeb :
CamboEB
contentsb :
CamboContentSB
contenteb :
CamboContentEB
filesb :
AttachFileSB
fieleb :
AttachFileEB
CamboEB( )
자료등록
CamboSB(servlet, req, res)
insertCamboContent(board)
getNextBoardID(pid)
CamboContentEB( )
CamboContentSB(servlet, req, res)
insertCamboContent(contents)
insertFileInfo(pid, bid, files)
AttachFileSB(servlet, req, res)
AttachFileEB( )
insertAttachFile(attachfile)
92
III. UML 적용사례
사례2: 고객지원접수시스템
고객지원접수 Use Case Diagram
고객접수등록
담당자등록
고객접수수정
담당자삭제
관리자
고객접수리스트
고객
사이트수정
담당자리스트
사이트등록
담당자
고객접수담당자지정
고객접수 처리완료
93
III. UML 적용사례
고객접수등록 Use Case 명세서
고객접수등록
Use Case 개요
고객은 자신이 담당하고 있는 기관의 고객지원접수를 등록한다.
관련 Actor
고객
Event Flow
3.1 Precondition
고객은 로그인 된 상태임
3.2 Main Flow
3.2.1 고객이 고객지원접수버튼을 클릭하면 use case가 시작된다.
3.2.2 시스템은 고객의 의뢰자이름, email을 출력한다.
3.2.3 고객은 의뢰내용을 입력하고 파일첨부를 한 후 등록버튼을 클릭하면 DB에 저장되고 고
객지원
리스트로 이동한다.
해당 접수건이 DB에 저장되면 해당 접수는 상태는 접수중이되고 관리자에게 메일이
발송된다.
3.3 Alternative Flow
3.4 Exception Flow
[O001] 고객지원접수 등록중에 오류가 발생하면 실패 메시지를 alert창으로 출력하고
[해당 화 면]으로 이동한다.
94
3.5 MMI
III. UML 적용사례
고객접수등록 Sequence
Diagram
: 담당자
: CsrMng
:
CsrInsertAction
: CsrListAction
CsrBeans
: DBHelper
: csrlist.jsp
doGet()
csrinsert(string csr_id,string csr_conent,string csr_file)
Execute
string mode CI
string mi
string csr_id
string csr_content
string csr_file
dispatch
CsrList를 호출해서 리
스트를 뿌렬준다.
95
III. UML 적용사례
고객지원접수 Class Diagram
96
J2EE 설계 특징
• UML, OOP 기준
– GoF 디자인 패턴 활용
– Together, JBuilder 툴 사용
• 비기능적 요구사항 반영
– 성능, 신뢰도, 확장성, 유지보수성 등
– 프로그래밍 언어, 운영체제, 미들웨어, 컴포넌트
모델, 애플리케이션 서버
• Java 기반: Write Once, Run Anyway
• EJB 컴포넌트 통한 분산 시스템 구축 아키텍
쳐 제공
97
논리적 시스템 구조와 설계
• Presentation Layer: 사용자로부터의 입력과 시스템
의 결과를 사용자에게 출력
– JSP, Servlet
– ASP, .NET 페이지
• Business Logic Layer: 시스템이 제공하는 기능 제
공
– 세션 빈
– COM+ 클래스
• Data Access Layer: 시스템이 관리하는 영속성 있
는 데이터에 대한 접근 및 제어 전담
– 엔티티빈, JDBC API
– ADO .NET을 이용하는 COM+ 클래스
98
설계 준비
• Together: J2EE 플랫폼상에서 시스템을 개
발하기 위한 충분한 환경 제공
– 소스코드 자동생성, 수정, Java 소스 컴파일/빌드
/디플로이 가능
– Design -> Java 언어로 전환
• Together에서 Design 프로젝트에서 Java 소
스 코드 프로젝트로 전환
– 프로젝트에서 Tools|Generate Source Code for
Design Project 선택
– 해당되는 값 입력
99
설계 준비
100
Presentation Logic 설계
101
Presentation Logic 설계
102
<<JSP>> 설계요소의 속성
• <<text>> 스테레오 타입
– HTML의 <input type=“text” name=“txtName” value=“이
영곤”>를 의미
• <<textarea>> 스테레오 타입
– HTML의 <textarea name=“txtDesc”>전산학</textarea>를
의미
• <<password>> 스테레오 타입
– HTML의 <input type=“password” name=“txtPassword”>
를 의미
• <<hidden>> 스테레오 타입
– HTML의 <input type=“hidden” name=“hdnAction”
value=“Open”>를 의미
• <<radio>> 스테레오 타입
– HTML의 <input type=“radio” name=“opt”>를 의미
103
<<JSP>> 설계요소의 속성
• <<select>> 스테레오 타입
– HTML의 <select name=“Age”>
<option value=“1”> …를 의미
• <<submit>> 스테레오 타입
– HTML의 <input type=“submit” value=“로그인”>
를 의미
• <<reset>> 스테레오 타입
– HTML의 <input type=“reset” value=“취소”>를
의미
• <<button>> 스테레오 타입
– HTML의 <input type=“button” value=“등록”
value=“Open”>를 의미
104
<<JSP>> 설계요소의 연산
• Form_onSubmit(): submit 버튼이 눌렸을 때 수행되
는 기능
– <input type=“submit” value=“login” onSubmit=‘return
validate()’>
• Form_onReset(): reset 버튼이 눌렸을 때 수행되는
기능
105
LoginProc 설계 요소
•
<<submit>> 버튼 눌렀을 때 로그인에 대한 처리를 담당하는 JSP 페
이지
1) 사용자가 폼의 입력 요소에 입력한 값을 추출
String userId = request.getParameter("txtId");
String password = request.getParameter("txtPassword");
2) 비즈니스 로직의 처리
아이디와 암호의 정확성을 판단한다.
boolean success = um.verify(userId, password);
if ( success ) {
//세션에 사용자 아이디를 기억시킨다.
session.setAttribute("userId",userId);
3) 비즈니스 로직의 수행결과에 따른 다른 화면으로 전환
response.sendRedirect("MainFrame.jsp") ;
106
LoginProc 설계 요소
if ( success ) {
//세션에 사용자 아이디를 기억시킨다.
session.setAttribute("userId",userId);
// MainFrame 화면으로 전환한다.
response.sendRedirect("MainFrame.jsp") ;
}
else {
%>
<SCRIPT LANGUAGE="javascript">
<!-// 사용자에게 메시지를 보여주고 다른 화면으로 전화할 때는
다음과 같이 한다.
alert("사용자 아이디 또는 암호가 부정확합니다.") ;
// 로그인 화면으로 전환한다.
window.location.href='Login.jsp';
//-->
</SCRIPT>
107
Menu 설계요소
<%
String userId = (String)session.getAttribute("userId");
InitialContext ic = new InitialContext() ;
Object refum = ic.lookup("UserManagement");
UserManagementHome homeum = (UserManagementHome)
PortableRemoteObject.narrow(refum,UserManagementHome
.class);
UserManagement um = homeum.create();
String userName = um.getName(userId) ;
String userType = um.getUserType(userId) ;
%>
108
Menu 설계 요소
<%
if ( userType.compareToIgnoreCase("Student") == 0 ) {
%>
<TR><TD align="center"> <A HREF="LectureTakingMain.jsp" TARGET="body"> 수강 신청</A></TD></TR>
<TD align="center"> <A HREF="ReportCardRetrievalMain.jsp" TARGET="body"> 성적 조회</A></TD>
</TR>
<%
} else if ( userType.compareToIgnoreCase("Professor") == 0 ) {
%>
<TR><TD align="center"><A href="GradeSubmissionMain.jsp" target="body"> 성적 등록</A></TD></TR>
<TR><TD align="center"><A href="RollBookRetrievalMain.jsp" target="body"> 출석부 조회</A></TD></TR>
<%
}
else if ( userType.compareToIgnoreCase("Sugang") == 0 ) {
%>
<TR><TD ALIGN="center"><A HREF="CourseManagementMain.jsp" TARGET="body"> 강좌 관리</A> </TD></TR>
<TR><TD ALIGN="center"><A HREF="LectureManagementMain.jsp" TARGET="body"> 강의 관리</A></TD></TR>
<%
}
else if ( userType.compareToIgnoreCase("Haksa") == 0 ) {
%>
<TR><TD ALIGN="center"><A HREF="ProfessorManagementMain.jsp" TARGET="body"> 교수 관리</A></TD></TR>
<TR><TD ALIGN="center"><A HREF="StudentManagementMain.jsp" TARGET="body"> 학생 관리</A></TD></TR>
109