WAA: J2EE 설계 및 UML

WAA: J2EE 설계 및 UML 2008.봄학기 E-비즈니스학과 이영곤

UML 이란 ?

목 차 1장. UML 소개 2장. UML Diagram 3장. UML 적용사례

1장 : UML 소개

I.UML 소개 UML은 무엇인가? • UML모델링 언어의 통합을 위한 표준이다. • UML은 시스템의 모든 분야를 포함한다. • 데이터 모델링 (Entity Relationship Diagrams) • 비즈니스 모델링 (work flow) • 객체 모델링 • 컴포넌트 모델링 • UML은 소프트웨어를 시각화, 명세화, 표현. • UML은 소프트웨어의 전개발 과정에 걸쳐 모든 프로세스에서 사용.

I.UML 소개 모델링의 중요성 • Model • 모델은 현실을 단순화시킨 것. • 모델은 시스템의 청사진을 제공. • 프로젝트 구성원간 의사 소통. • Modeling • 모델을 만들어 나가는 작업(The work of making a model) • 전체 프로젝트를 통해 계속 업데이트되는 과정

I.UML 소개 모델을 만드는 이유 • 시스템에 대한 보다 나은 이해. • 모델링을 하는 4가지 목적 • 시스템을 현재 또는 원하는 모습으로 가시화. • 모델은 시스템의 구조와 행동을 명세화. • 모델은 시스템을 구축하는 틀을 제공. • 모델은 결정사항을 문서화.

Nov ‘97 97년 11월 OMG의 표준으로 승인 I.UML 소개 UML의 역사 현재 UML1.4 OMG : Object Management Group

I.UML 소개 UML과 프로세스 • 프로세스는 무엇을, 언제, 어떻게, 왜 수행해야 하는지를 설명. • UML을 사용하는 프로세스의 기본특성 • 유스케이스 위주(Use Case-driven) • 아키텍처 중심(Architecture Centric) • 반복적(Iterative)이고 점증적(incremental) 개발

유스케이스 요구사항 분석 설계 구현 테스트 I.UML 소개 UML을 사용하는 프로세스는 Use Case Driven • UML에서 유스케이스는 • 시스템의 기능적인 요구사항을 정의. • 요구사항분석 이후의 모든 단계에서의 개발을 유도한다. • 시스템의 필요한 모든 기능이 시스템에서 실현되는 것을 보장한다. • 분석단계 동안에 시스템의 필요기능을 정의하고, 검토하는데 사용.

2장. UML Diagram 쓰임새도(Use Case Diagram) 클래스도(Class Diagram) 객체도(Object Diagram) 순차도(Sequence Diagram) 협력도(Collaboration Diagram) 상태도(Statechart Diagram) 활동도(Activity Diagram) 컴포넌트도(Component Diagram) 배치도(Deploy Diagram)

수강 등록부 요청 교수 학생 스케줄관리 지불시스템 커리큘럼관리 등록자 II.UML Diagram Use Case Diagram • Use case다이어그램은 액터와 유스케이스(use case)의 관계를 도식화한다.

II.UML Diagram Use Case Model • Use Case • 사용자와 시스템간의 전형적 인터렉션 • User-visible function • 다양한 규모의 use case • Actor • 시스템에 대한 사용자의 역할(Role) • 직위나 한 개인에 종속된 것은 아님 • non-human actor도 가능 use case 1..* Use case actor 1..*

II.UML Diagram Use Case Modeling : What? • 목적 • 시스템과 사용자간의 인터렉션 식별 • 각각의 인터렉션(시스템을 사용하는 목적)이 유스케이스로 모델링 된다. • 각각의 인터렉션은 액터가 정의되어야 한다. • 유스케이스는 시스템이 제공하고자 하는 모습에 대한 Snapshot • 모든 유스케이스를 취합하면 시스템의 외향적 모습이 결정된다.

II.UML Diagram Use Case Modeling : Why? • 이유 • 고객이 이해하기 쉬운 형태 • 시스템 요구 사항을 모델링 • 현업 사람들의 참여 유도 • 소프트웨어 테스트 시나리오 작성의 기반

II.UML Diagram Use Case Modeling : When? • 고객으로부터 요구 사항을 추출하는 초기 단계 동안 수행 • 프로젝트에 대한 개발 사항을 정의하는 과정에서 상위 수준의 유스케이스 모델을 작성. • 컴포넌트 설계 과정까지 유스케이스 정제과정을 통해 유스케이스를 상세하게 정의해 나감.

II.UML Diagram Use Case Scenario(or Flow of Events) 유스케이스는 시나리오에 따라 구성됨. • 시나리오에 대한 서술은 각 유스케이스 다이어그램의 페이지 전후에 텍스트로 이루어짐. • 작성지침 • 유스케이스 이름 • 유스케이스를 시작하는 행위자 • 유스케이스의 목표(Optional) • 유스케이스가 시작하는데 필요한 선행 조건(Optional) • 시나리오의 정상적 진행 단계(Main Success Scenario) • 시나리오의 대안적 진행 단계(Alternative Scenario-Optional) • 시나리오의 확장점 진행단계(Extensional Scenario -Optional) • 유스케이스가 끝나는데 필요한 종료 조건(Optional)

II.UML Diagram Use Case Relationship :Include - 포함(Include) – 유스케이스가 다른 유스케이스를 포함하는 관계 • 여러 유스케이스에서 공통으로 중복되는 시나리오가 있다면 이 시나리오를 따로 분리하여 새로운 유스케이스로 만듬. • 사용하려는 유스케이스가 사용되어지는 유스케이스를 필수적으로 포함해야 함. • 포함된 유스케이스는 절대로 단독으로 존재할 수 없으며, 전체 유스케이스의 부분으로만 존재. • 표현 • 포함 관계에 있는 유스케이스 사이를 쇄선으로 잇고, 포함되어지는 유스케이스 쪽에 화살표 머리를 둠. • 연결선 위에는 스테레오타입 <<include>> 를 붙여준다.

사용자 공급자 수금원 II.UML Diagram Include Relationship : Sample 예) 자판기 내용물 공급자와 수금원이 포함된 자판기 시스템의 유스케이스 다이어그램 “내용물 보충하기” 유스케이스와 “수금하기” 유스케이스의 시나리오에서 공통으로 중복된보안장치 해제나 보안장치 설정과 관련된 진행 단계들을 따로 떼어내서 새로운 유스케이스로 만들고 포함 시켰다. 자판기 시스템 음료수사기 보안장치 설정 <<include>> 내용물보충하기 <<include>> <<include>> 수금하기 보안장치 해제 <<include>>

II.UML Diagram Use Case Relationship : Extend • 확장 (Extend) – 유스케이스와 그 유스케이스를 확장한 확장 유스케이스의 관계 • 유스케이스의 시나리오에서, 어떤 조건에 따라 특정한 진행 단계의 행위(behavior)를 확장하고자, 다른 유스케이스를 참조 하는 것을 말함. • 즉, 특별한 조건에서만 수행되는 부 흐름부를 모형화 한 것으로, 어떤 조건이 부합되어야만 포함되는 유스케이스를 표현함(선택적). • 확장된 유스케이스는 절대로 단독으로 존재할 수 없다  단지, 기본 유스케이스에서 특정한 시나리오의 진행 단계의 확장이기 때문. • 표현 • 두 유스케이스 사이를 쇄선으로 잇고, 기본 유스케이스쪽에 화살표 머리를 둔다. • 연결선 위에는 스테레오타입 <<extend>>를 붙여준다.

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 확장유스케이스

II.UML Diagram Use Case Relationship : Generalization • 일반화 (Generalization) • 유스케이스를 상속하는 것을 의미. • 상속을 해주는 유스케이스를 “부모 유스케이스” 라 하고, 상속을 받는 쪽을 “자식 유스케이스” 라 한다. • 자식 유스케이스는 부모 유스케이스의 모든 행동과 의미를 물려 받으며, 여기에 자신만의 행동을 추가할 수 있다. • 부모 유스케이스가 등장하는 곳에 자식 유스케이스를 대신 놓을 수 있다. • 두 유스케이스 사이를 실 선으로 연결하고, 부모 유스케이스 쪽에 속이 빈 화살표 머리를 붙인다. • 일반화 관계는 행위자(Actor) 사이에도 적용할 수 있다.

II.UML Diagram Generalization Relationship : Sample Validate User Parent Use Case Validate Member Child Use Case

부모 행위자 회사원 자식 행위자 자식 행위자 임원 직원 II.UML Diagram Actor Generalization Relationship

유스케이스 작성사례 사례: RFID 리더기를 통해 들어온 데이터는 RFID 미들웨어를 거쳐 일차로 정제되고 저장된다. 13.56 MHz 리더기에서 데이터가 들어올 경우는 세밀정제 과정을 거쳐야 한다. RFID 미들웨어는 ECSpec에 따라 RFID 클라이언트에게 EPC 데이터를 전송해준다. RFID 클라이언트는 ECSpec을 정의하여, RFID 미들웨어에게 전송한다. ECSpec을 정의하기 위해서는 ECReport에 대한 스펙을 정의해야만 한다.

II.UML Diagram Class Diagram

II.UML Diagram Class Diagram • 클래스는 지식 도메인에 기반한 어휘와 용어로부터 만들어짐. • 시스템 분석결과에서 명사와 동사에 주의. 명사는 클래스의 이름, 동사는 모델링한 클래스의 Operation이 될 가능성이 높음. 의뢰인과의 대화중에서 명사 의뢰인과의 대화중에서 명사 클래스 만들때 사용한 명사와 관련된 명사 (생략가능) 의뢰인과의 대화중에서 동사 (생략가능) 클래스가 의뢰인의 업무에서 하는 역할에 대한 설명 (생략가능)

II.UML Diagram Class Diagram : Sample • 스테레오타입을 사용하여 속성 또는 오퍼레이션 리스트를 구분 지을 수 있다. • 스테레오타입 • UML의 구성요소를 확장하여 새로운 UML 요소를 만들 수 있게 한다. • 표기:<<스테레오타입이름>> • 예제) 세탁기 클래스 모델번호 생성 방법은 회사문서 [DT-100] 문서를 참고하라. {용량=5 or 8 or 10 Kg} • 제약(Constraints) • 클래스가 따라야 할 규칙을 붙여줄 때 사용. • 표기 : { } 안에 자유 형식의 텍스트로 표현한다. • 예제는 세탁기에 수용할 수 있는 세탁물의 용량을 5, 8, 10 Kg으로만 제한함을 나타낸다. • 노트(Note) • 추가적인 정보를 덧붙을 때 사용. • 대개 속성이나 오퍼레이션에 붙인다.

II.UML Diagram Class Diagram : More Sample • 예제) 농구 게임을 클래스 모델링 하기 • 명사: 볼, 바스켓, 팀, 선수, 가드, 포워드, 센터, 슛, 슛 시간, 3점라인, 자유투, 파울, 자유투 라인, 코트, 게임시간 • 동사: 슛하다, 드리블, 패스, 파울, 리바운드 • 이 외에도 개인의 상식을 동원해서 클래스 모델링에 사용할 수 있다. • 다음은 이런 정보를 바탕으로 만든 Class Diagram이다. 이렇게 만든 Class Diagram은 나중에 다시 농구팀 감독과 이야기할 때 충분한 기본 자료로 사용하여 더 많은 정보를 얻어내는데 도움을 줄 것이다.

II.UML Diagram Class Diagram • 앞의 예제에서 만든 Class Diagram에서는 “농구는 어떻다”라는 기본을 제공하지만, ‘선수가 어떻게 공을 다루는지’, ‘선수가 어떻게 팀을 이루는지’, ‘어떻게 게임이 이루어지는지’ 등에 대한 정보는 빠져있다.-> 클래스간 관계 필요 • 클래스간의 연결은 다음 8가지 정도로 정리할 수 있다. • 연관(Association) • 다중성(Multiplicity) • 수식연관(Qualified Association) • 반사연관(Reflexive Association) • 상속과 일반화(Generalization) • 의존관계(Dependency) • 집합연관(Aggregation) • 복합연관(Composition)

선수 고용인 선수 선수 고용인 고용인 II.UML Diagram Class Diagram : Association • 연관(Association) • 클래스가 개념적으로 서로 연결되어 있음을 말한다. • 예) 선수와 농구팀의 관계 연관이름 및 관계의 방향 운동한다 ▶ 팀 고용주 역할 • 각각의 클래스 마다 역할을 표시할 수 있다. • 하나의 클래스가 여러 클래스와 연관을 • 맺을수 있다. • “▶” 또는 “◀”을 사용하여 관계의 방향을 • 나타낼 수 있다. 역할

II.UML Diagram Class Diagram : Association(연관) 운동한다 ▶ • 클래스 사이에 두개의 연관이 나타날 • 수 있다. 선수 팀 ◀고용한다 • 연관에 제약(Constraints)을 둘 수 있다. • 그림에서는 “서비스한다”에 {순서를 가진 • 다} 라는 제약이 가해져서 고객의 순서대로 • 은행원이 서비스 한다. {순서를 가진다} 서비스한다 ▶ 은행원 고객 선택한다 ▶ • 또 한가지 제약 은 두개의 연관선 사이를 • 점선으로 잇고 이 위에 {or} 로 표기하는 • {or} 관계이다. 그림은 고등 학생이 진로를 • 정하는 상황을 모델링 한 것이다. 대학교 고등학교 학생 {or} 선택한다 ▶ 직장

II.UML Diagram Class Diagram : Association Class 운동한다 ▶ • 연관클래스는 연관의 속성과 • 오퍼레이션을 모델링 할 때 사용한다. • 연관 클래스는 연관선과 점선으로 • 연결되며, 다른 클래스와 연관을 • 가질 수도 있다. 선수 팀 협상된다 ▶ 계약 매니저 운동한다▶ 박찬호:선수 LA 다저스:팀 • 객체가 클래스의 인스턴스인 것처럼, 연관도 자신의 인스턴스를 가질 • 수 있다. 어떤 특정한 선수가 특정한 팀에 소속되어 있는 관계를 생각 • 하면, 이때의 “운동하다” 연관 관계를 링크(link)라고 부른다. 링크는 • 두 객체를 선으로 이어서 나타내며, 객체에 밑줄 긋듯이 링크에도 • 밑줄을 긋는다.

II.UML Diagram Class Diagram : Multiplicity(다중성) • 다중성 • 연관되어 있는 두 클래스 사이에서 한 클래스의 객체와 관계를 가질수 있는 다른 클래스의 객체 개수. 이것을 다이어그램에서 나타내면 해당 클래스 가까이(그리고 연관선 위)에 객체의 수를 써준다. • 예를 들면, 팀의 입장에서 보면 다섯명의 선수와 연관되어 있지만 선수의 입장에서 보면 한 팀과 연관되어 있다는 것이다. 운동한다 ▶ 선수 5 1 팀 • 표기 • UML은 “more”와 “many”를 표현하는 기호로서 ‘*’ 를 사용한다. • 예) • 1..*  1또는 그이상 (one or more) • 2..7  2이상 7까지 (2 through 7) • 5,7  5 또는 7 (5 or 7)

II.UML Diagram Class Diagram : Qualifier • Qualifier 연관 • 일 대 다 (one-to-many)의 다중성을 가진 연관 관계에서 한 객체가 특정한 객체를 가려내어야 하는 상황 (이것을 lookup 이라고 한다)이 발생한다. • 하나의 클래스의 객체가 다른 클래스의 객체를 선택하기 위하여 특정한 속성의 식별자를 사용하는데, 이러한 식별 정보를 Qualifier라고 하여 작은 사각형으로 나타낸다. • Qualifier는 일 대 다 (one-to-many) 다중성을 일 대 일 (one-to-one) 다중성으로 줄이는데 효과적이다. • 다음은 “호텔 객실 배당 사무원”의 “확인번호”를 통해예약을 찾는 예이다. 호텔 객실 배당 사무원 찾는다 ▶ 예약 1 * 확인번호 Qualifier

II.UML Diagram Class Diagram : Reflexive • Reflexive 연관 • 클래스는 자기 자신과 연관을 가질 수도 있다. 하나의 클래스가 여러가지의 역할을 가질 때 “재귀연관”을 갖도록 한다. • 예를 들면, 탑승자는 운전자도 될 수 있고 승객도 될 수 있다. • 예) 운전자의 역할을 맡은 탑승자는 승객의 역할을 맡은 탑승자를 0명이상 4명까지 실어 나를 수 있다. 탑승자 1 운전자 운전한다 ▼ 0..4 승객

동물 Super Class Root Class 양서류 포유류 파충류 말 Sub Class Leaf Class II.UML Diagram Class Diagram : Inheritance • 한 클래스는 다른 클래스로부터 속성과 오퍼레이션을 물려 받을 수 있다. 이것을 객체지향 개념에서는 “상속” 이라 하고, UML에서는 “일반화” 라 한다. • 상속 관계에서 상속을 받는 쪽을 Child Class 또는 Sub Class 라고 하고, 상속을 해주는 쪽을 Parent Class 또는 Super Class 라고 한다. • Sub Class 에서 Super Class 쪽으로 속이 빈 화살표( )를 연결한다. 이러한 타입의 연결 관계를 “…의 일종(is a kind of)” 라고 부른다. • 상속 관계를 모델링 할 때에는, 반드시 서브 클래스가 수퍼 클래스에 대해 “is a kind of”관계를 가지도록 만들자. • 만약 두 클래스가 이 관계로 맺어지지 않는다면, 차라리 다른 타입의 관계를 맺어주는 것이 더 낫다. • Root Class: Super Class를 가지지 않는 클래스 • Leaf Class : Sub Class를 가지지 않는 클래스

II.UML Diagram Class Diagram : Abstract Class • 어떤 Sub Class의 Super Class가 있을 때, 만약 이 Super Class의 구체적인 인스턴스(Instance)를 만들 필요가 없을 때에는 “추상 클래스”로 만들자. 즉, 클래스의 객체를 생성하지 않는 클래스를 “추상 클래스” 로 만든다. • 표기: 클래스명을 이탤릭으로 쓴다.

II.UML Diagram Class Diagram : Dependency • 한 클래스가 다른 클래스를 사용하는 관계를 말한다. 특히 한 클래스의 Operation이 다른 클래스를 사용하는 시그너쳐를 보일 때 이다. • 예를 들면, “시스템” 클래스 와 “폼” 클래스가 있는데, “시스템” 클래스는 ‘폼_출력(form:폼)’ 이라는 Operation을 가지고 있다. 이 “시스템”이 화면에 표시해 주는 서식은 전적으로 사용자가 선택한 “폼” 클래스에 따라 달라진다. 이 상황을 UML로 표기하려면 “의존 대상”이 되는 클래스를 향해 점선으로 긋고 화살표 머리를 붙여주면 된다.

II.UML Diagram Class Diagram : Aggregation • 집합연관 (Aggregation) • 하나의 클래스가 여러 개의 컴포넌트 클래스로 구성되어 있는 경우가 있다. 즉, 컴포넌트 클래스와 전체 클래스가 “부분-전체” 연관 관계를 가질 때 집합연관이 된다. • 표기: 컴포넌트 클래스와 전체 클래스를 선으로 잇고, 빈 마름모꼴을 전체 클래스 쪽에 붙여서 나타낸다. 컴퓨터 • 집합연관에 대한 제약 • OR 관계를 모델링 하려면, 두개의 집합 연관선 사이를 점선으로 이은 다음에 {or}을 써주면 된다. 1 1 {or} 2 1 1 1 1 헤드셋 스피커 본체 모니터 키보드 마우스

커피테이블 1 1 4 테이블 판 다리 II.UML Diagram Class Diagram : Composition • 복합연관 (Composition) • 강한 집합 연관으로써 각 컴포넌트 클래스가 오직 하나의 전체 클래스에서만 의미를 가질 때, 복합연관으로 표현한다. • 표기: 각각의 컴포넌트는 전체 클래스 쪽으로 향하여 안이 채워진 마름모 꼴의 화살표를 연결한다.

II.UML Diagram Class Diagram : Interface and Realization • 어떤 클래스들이 동일한 Super Class와 관계를 가지지 않았는데, 같은 signature를 가진 Operation이 존재한다면 이것은 Operation의 재사용으로 간주된다. • 이런 재사용을 위한 Operation의 집합을 인터페이스(Interface)라고 한다. 인터페이스는 클래스의 일정한 행동(behavior)을 나타내는 Operation의 집합으로, 다른 클래스에서 사용될 수 있다. • 자바에서 인터페이스는 method의 prototype만 선언되어 있고, 인터페이스를 구현 (Implementation)한 클래스에서 method를 정의한다. 이것을 UML에서는 실체화(realization)이라 한다. • 타자기 의 행동을 실체화한 키보드 클래스 • 인터페이스를 실체화한 클래스를 • 나타내는 간단한 방법 타자기 키보드 <<realization>>

II.UML Diagram Class Diagram : Visibility • 가시성 (visibility) • 해당 클래스(혹은 인터페이스)의 속성과 오퍼레이션을 들여다 볼 수 있는 범위. • 표기: 자바 기준 • “+” – public : 모든 클래스에서 접근 가능 • “#” – protected : Package member Class 와 Sub Class 만 접근 가능 • “-” – private : member Operation만 접근 가능 • None - Package member Class 만 접근 가능

II.UML Diagram Class 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 II.UML Diagram Sequence Diagram

II.UML Diagram Sequence Diagram • 순차 다이어그램이란? • 상태 다이어그램이 촉발 사건에 따른 단일 객체의 상태 변화를 표현한 것이라면, 순차 다이어그램은 여러 객체들이 시간 경과에 따라 객체 상호간 교류 과정을 표현한 것. • 구성 • 객체(Object) : 사각형으로 나타내며 이름에 밑줄이 들어가 있다. • 메시지(Message) : 실선 화살표로 그려진다. • 시간 : 진행 상황을 나타내기 위하여 수직선으로 그린다. • 객체 • 순차 다이어그램의 가장 위 부분에 위치, 왼쪽에서 오른쪽으로 배열. • 배열순서 – 다이어그램을 간략하게 하는 방향으로 기준을 삼는다 • 각 객체로부터 아래로 뻗어 가는 점선은 객체의 생명선(lifeline)이라 불린다. • 생명선을 따라 좁다란 사각형이 나타나는데, 이 부분은 실행(activation)이라 한다.즉, 객체가 수행되고 있음을 나타낸다. 사각형의 길이는 오퍼레이션의 실행 소요 시간을 나타낸다. 객체1 객체2 객체3 객체의 생명선 오퍼레이션의 실행 소요 시간 객체의 생명선

II.UML Diagram Sequence Diagram : Message • 메시지 • 한 객체에서 다른 객체로 전송. • 한 객체의 생명선에서 다른 객체의 생명선으로 이동하는 것으로 표현. • 객체는 자기 자신에게 메시지를 보낼 수 있다. • 종류 • 단순(simple)메시지 – 한 객체에서 다른 객체로 제어흐름이 이동하는 것. • 동기(synchronous) 메시지 – 메시지 전송 후 수신 객체로 부터 그 메시지를 받았다는 답변이 와야 자신의 작업을 계속할 수 있음. • 비동기(asynchronous) 메시지 – 메시지 전송 후 수신 객체로부터 답신을 기다리지 않고 자신을 작업을 계속 함. • 표기 Simple Message Synchronous Message Asynchronous Message

Actor II.UML Diagram Sequence Diagram : Time Axes • 시간을 수직 방향으로 표현 • 시간의 흐름은 위에서 아래로 흐른다. • 객체 표기는 객체명:클래스파이어(Classfier)명으로 표기한다. 객체1 객체2 객체3 동기 메시지 비동기 메시지 자기 자신에게 동기 메시지 보냄

WAA: J2EE 설계 및 UML