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

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

UML 이란 ?

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

1장 : UML 소개

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

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

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

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

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

UML을 사용하는 프로세스는 Use Case Driven
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)

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

Use Case Model Use Case Actor 1..* Use case actor 1..* 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..*

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

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

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

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

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

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

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

Extend Relationship : Sample
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 확장유스케이스

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

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

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

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

II.UML Diagram Class Diagram

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

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

Class Diagram : More Sample
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)

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

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

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

Class Diagram : Multiplicity(다중성)
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)

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

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

Class Diagram : Inheritance
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” 관계를 가지도록 만들자. 만약 두 클래스가 이 관계로 맺어지지 않는다면, 차라리 다른 타입의 관계를 맺어주는 것이 더 낫다. 동물 양서류 포유류 파충류 말 Super Class Sub Class Root Class Leaf Class Root Class: Super Class를 가지지 않는 클래스 Leaf Class : Sub Class를 가지지 않는 클래스

Class Diagram : Abstract Class
II.UML Diagram Class Diagram : Abstract Class 어떤 Sub Class의 Super Class가 있을 때, 만약 이 Super Class의 구체적인 인스턴스(Instance)를 만들 필요가 없을 때에는 “추상 클래스”로 만들자. 즉, 클래스의 객체를 생성하지 않는 클래스를 “추상 클래스” 로 만든다. 표기 : 클래스명을 이탤릭으로 쓴다. 가드 슛() 선수 이름 키 몸무게 볼_드리블() 볼_패스() 리바운드() 슛() 포워드 슛() 센터 슛()

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

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

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

Class Diagram : Interface and Realization
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() <<Interface>> 타자기 PgUp() pgDown() 타자기 키보드 <<realization>>

Class Diagram : Visibility
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 : 대학 도서관 학생 및 교수: 임의의 시점에 대학 도서관을 이용할 수 있다. 도서를 대출하고자 하는 경우 학생증을 제시해야 하고, 반납일자를 명기해야 한다. 도서반납을 연체하는 경우에는 연체료를 지불해야 한다. 도서관 직원: 대출자가 대출을 원하는 경우, 대출자의 신분을 조회하고 현재 반납 연체인 도서가 있는지 확인한다. 대출자가 희망하는 도서가 대출가능한 상태인지를 먼저 확인한 후 문제가 없는 경우 반납일을 확인하고 도서를 대출해 준다. 도서대출관리 시스템은 대출자가 연체한 경우, 연체료를 자동으로 계산할 수 있다. 또한, 그 대출자와 관련된 정보와 지금까지의 도서 대출 리스트를 보여줄 수 있어야 한다.

Sequence Diagram II.UML Diagram registration form schedule available
courses Jon : Student 1:enter id 2:validate id 3:enter current semester 4:create new schedule 5:display 6:get course

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

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

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

Sequence Diagram : Sample
II.UML Diagram Sequence Diagram : Sample 예제) 자판기에서 “음료수 뽑기” 객체를 골라내면 프론트 : 음료수 자판기가 고객과 대화하는 유일한 인터페이스, 판매기 앞판에 있음. 금전 등록기 : 돈을 체크하고 등록함. 디스펜서 : 음료수를 따르고 내어줌. 처리과정을 써보면 다음과 같다. 1. 소비자가 자판기의 프론트 앞에 서서 투입구에 돈을 넣는다.(Insert) 2. 소비자가 마실 음료수를 고른다.(Select) 3. 돈이 금전등록기에 들어간다.(Send) 4. 등록기는 선택된 음료가 디스펜서에 들어 있는지를 체크한다. 5. 선택된 소다가 준비되어 있고, 등록기는 현금 잔고를 갱신한다. 6. 등록기는 디스펜서를 사용하여 소다를 자동 판매기의 프론트로 보낸다. 이 예는 “음료수 사기” 유스케이스에서 단지 한 개의 시나리오(즉, 하나의 인스턴스)에 대하여 그려지기 때문에, 이 다이어그램을 인스턴스 순차 다이어그램이라고 부른다.

II.UML Diagram Sequence Diagram : Sample :프론트 :금전등록기 :디스펜서 User Insert(input) Select(Selection) Send(input) Deliver(Selection) Deliver(Selection)

II.UML Diagram Sequence Diagram : Sample 예제) 자판기에서 “음료수 뽑기” 의 예에서 또 다른 시나리오를 가정. 선택된 음료수가 다 떨어진 경우 또는 소비자가 넣은 돈이 음료수 값과 맞지 않을 때. 다음은 ‘액수에 맞지 않는 경우’ 의 시나리오 이다. 1. 등록기는 소비자가 투입한 돈의 액수(input)가 음료수의 값(price)과 맞는지 체크한다. 2. 만일 액수가 음료수 값보다 많으면, 등록기는 차액을 계산하고 그 만큼의 현금 잔고가 있는 체크한다. 3. 만일 차액 만큼의 현금이 잔고(cash reserve)에 남아 있다면, 등록기는 거스름돈(change)을 내어주고 나머지 동작은 그전과 똑같이 진행한다. 4. 만일 차액 만큼의 현금이 잔고에 남아 있지 않으면, 등록기는 소비자가 투입한 돈을 그대로 돌려주고 “맞는 액수의 돈을 넣어 주세요”란 메시지를 표시한다. 5. 만일 소비자가 투입한 돈의 액수가 음료수 값보다 적으면, 등록기는 아무것도 하지 않고 돈이 더 들어올 때까지 대기한다. 조건문을 표현하기 위해서는 대괄호 [ ] 안에 조건을 써주고, 이것을 메시지 화살표 위에 놓으면 된다.

II.UML Diagram Sequence Diagram : Sample “액수가 맞지 않는 경우” 의 시나리오 :프론트 :금전등록기 :디스펜서 User Insert(돈) Select(선택) Send(돈) Deliver(선택) [돈 = 가격] [돈 > 가격] 잔돈이 있는지 체크 [잔돈이 있다면] 잔돈을 돌려줌 [잔돈이 있다면] [잔돈이 없다면] Return(돈)

Sequence Diagram : Object Creation & Loop
II.UML Diagram Sequence Diagram : Object Creation & Loop 순차 내에서 객체 생성 기존의 객체 표현 방법처럼, 이름이 붙은 사각형으로 표현. 보통의 객체처럼 시퀀스의 다이어그램의 위에 두지 않는다. 생성된 객체는 이것이 생성된 시간과 대응되는 위치에 놓는다. 이 객체를 생성한 메시지는 “create()”라는 레이블이 붙으며, 여기서 ()는 오퍼레이션을 의미한다. <<create>> 스테레오 타입을 사용할 수도 있다. “while” 문의 표현 조건의 표현인 [ ] 왼쪽에 ‘*’ 를 붙인다. 객체 1 객체 2 User Create() *[조건] 객체 3

Sequence Diagram : Recursion
II.UML Diagram Sequence Diagram : Recursion 재귀호출(recursion) 나타내기 객체가 자기 자신을 호출하는 구조의 오퍼레이션을 가지는 경우가 있는데, 이러한 오퍼레이션을 재귀호출(recursion)이라고 한다. 예제) 어떤 시스템에 계산기 객체가 포함되어 있다고 하자. 이 객체의 오퍼레이션 중 하나가 이자(interest)를 계산 하는 것이라고 가정하고, 지난 기간을 모두 종합한 복리(compound interest)를 계산하기 위해 이 계산기 객체의 오퍼레이션은 각 기간의 복리를 사용하여 계속 자신을 호출해야 한다. 이것을 Sequence Diagram으로 표현하면 다음과 같다. 표현 실행 사각형에다가 작은 사각형을 그리고, 오퍼레이션을 나타내는 메시지 화살표를 실행 사각형에서 작은 사각형 쪽으로 향하도록 한다. 객체 1

Collaboration Diagram
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

II.UML Diagram Collaboration Diagram 협력 다이어그램이란? 객체 사이의 연관 관계 뿐만 아니라, 각 객체들이 주고 받는 메시지들을 공간에 따라 배열 한 것. 객체 다이어그램의 확장으로 볼 수 있다. 순차 다이어그램과의 유사점 및 차이점 유사점 : 순차 다이어그램처럼 객체들 사이의 교류를 보여준다.  따라서, 순차와 협력 다이어그램의 상호 변환이 쉽다. 차이점 : 순차 다이어그램: 객체간의 교류를 시간의 순서에 초점을 두어 표현. 협력 다이어그램 : 공간에 따라 배열시킴  교류를 수행하는 객체들의 전체적인 조직과 상황(Context)에 초점을 맞춤. 표현 두 객체 사이를 연관 선으로 연결. 연관선 위에 메시지가 전달되는 객체 쪽으로 화살표 방향을 가진 선을 긋는다. 메시지의 끝에 ‘()’ 붙임으로써 매개 변수를 넣을 수 있도록 함.

II.UML Diagram Collaboration Diagram 예제) 자판기에서 “음료수 뽑기” 순차 다이어그램을 협력 다이어그램으로 표현. 1. 소비자가 자판기의 프론트 앞에 서서 투입구에 돈을 넣는다.(Insert) 2. 소비자가 마실 음료수를 고른다.(Select) 3. 돈이 금전등록기에 들어간다.(Send) 4. 등록기는 선택된 음료가 디스펜서에 들어 있는지를 체크한다. 5. 가장 간단한 시나리오이기 때문에, 선택된 소다가 준비되어 있고, 등록기는 현금 잔고를 갱신한다. 6. 등록기는 디스펜서를 사용하여 소다를 자동 판매기의 프론트로 보낸다. User insert(input, selection) :프론트 1 : add(input, selection) 3 : deliver(selection) :디스펜서 :금전등록기 2 : deliver(selection)

II.UML Diagram Collaboration Diagram 예제) “음료수 뽑기” 예에서 “액수가 맞지 않는 경우”를 고려해 보자. 물론, 이전의 순차 다이어그램을 참고하면서 보도록 한다. 만들 협력 다이어그램은 다음의 조건을 처리해야 한다. 1. 사용자가 음료수 가격보다 많은 돈을 투입한 경우. 2. 음료수 자판기가 충분한 거스름 돈을 가진 경우. 3. 음료수 자판기가 충분한 거스름 돈을 가지지 않은 경우. User insert(input, selection) :프론트 1 : add(input, selection) 4 : deliver(selection) [잔돈이있다면] 3.2 : return(잔돈) :디스펜서 :금전등록기 [input > price] : 잔돈유무검사(input, price) [input = price] 2.1 : deliver(selection) [잔돈이있다면] 3.1 : deliver(selection) 각 단계의 소수점 숫자의 표현 : 동일한 단계에서 여러 시나리오가 중첩(nesting) 됨을 나타냄.

II.UML Diagram Collaboration Diagram while 문을 표현 : *[조건] 객체의 생성 : 객체를 생성하는 메시지 앞에 스테레오타입 <<create>> 붙인다. 여러 객체로 메시지 전송하기 메시지를 받는 객체 사각형을 사선 방향으로 쌓는다. 객체로 전송되는 메시지에는 ‘*’ 가 붙은 대괄호 조건문을 붙여준다. 만약, 메시지 전송의 순서가 필요하다면, 조건 문에 1… n 처럼 순서의 의미를 표시함. 예제) 은행원이 여러 창구에 늘어선 고객들을 순서대로 맞아 서비스를 한다. :은행원 *[순번 = 1...n] 1 : 서비스() :고객

II.UML Diagram Collaboration Diagram 반환된 결과 나타내기 메시지는 어떤 객체로 하여금 오퍼레이션을 수행하고 그 값을 반환하게 하는 요청일 수 있다. 표현 : “반환되는 값의 이름 := 오퍼레이션” 예제) 가정주부가 계산기 객체에게 지출 항목을 더하여 총 합계를 요구한다. :가정주부 1: 총지출합계 := 계산(지출항목) 수식의 우변( 계산(지출항목) )을 메시지-시그너쳐(message-signature) 라고 한다. :계산기

State Diagram II.UML Diagram 상태 다이어그램(State Diagram) 이란? 표현 상태정보
사건이나 시간에 따라 시스템 객체의 상태 변화를 표현한 그림. “단일 객체”의 상태를 나타냄. 시스템의 변화를 잡아내기 위하여 사용. 분석가, 설계자, 개발자 들이 시스템내의 객체 행동을 이해하는데 큰 도움을 줌. 표현 상태의 표현 : 모서리가 둥근 사각형으로 표현 상태 전이의 시작점 : 속을 칠한 원으로 표현. 상태 전이의 종료점 : 속을 칠한 원을 둘러싼 원으로 표현 상태 전이선 : 화살표 머리가 달린 실선 상태정보 시작점 종료점

State Diagram 상태 아이콘에 넣는 정보 II.UML Diagram
이름, 속성, 오퍼레이션 의 세 영역으로 나누어 상세한 정보 넣을 수 있다. 이름 – 상태 이름(필수) 속성 – 상태 변수(옵션). 타이머나 카운터처럼 상태 진행에 도움을 주는 데이터. 오퍼레이션 – 활동(Activity – 옵션). 사건(event)과 동작(action)으로 이루어짐. 동작(event[guard]/action) – 전이(transition)와 연관. 빨리 발생하는 프로세스로 간주되며 인터럽트를 받지 않는다. 활동(do/activity) – 상태(State)와 관련, 오래 지속될 수 있으며 사건(event)이 인터럽터를 일으킬 수도 있다. 상태 이름 상태 변수들 활동들 활동 자주 쓰이는 세가지 진입(entry) – 시스템이 상태로 들어갈 때 일어남 탈출(exit) – 시스템이 상태에서 빠져나올 때 일어남 활동(do) – 시스템이 상태 안에 있는 동안 일어남

State Diagram II.UML Diagram 예) 팩스 기계의 상태 정보의 표현과 전이 전송(Faxing)
대기(Idle) Date = 현재날짜 Time = 팩스 전송 시작 시간 Phone Number = 소유주 전화번호 Owner = 소유주 이름 Date = 현재날짜 Time = 현재 시간 Phone Number = 소유주 전화번호 Owner = 소유주 이름 Entry / 수신팩스번호 입력 Exit / 전송완료 Do / 날짜 붙이기 Do / 시간 붙이기 Do / 송신측 전화번호 붙이기 Do / 소유주 이름 붙이기 Do / 페이지 매기기 Entry / 전송완료 Exit / 전송 시작 Do / 날짜 보이기 Do / 시간 보이기

State Diagram 상태 전이 선에 추가 되는 정보 : 사건과 동작 II.UML Diagram
추가되는 정보 : 전이가 일어나는 원인을 제공하는 사건(촉발사건-trigger event)과 실제로 수행되어 상태변화를 일으키는 연산(동작-action). 사건과 동작은 상태 전이 선에 가깝게 붙여준다. ‘/’ 를 사용하여 사건[조건]/동작을 구분 시켜준다. 활동을 종료했기 때문에 일어나는 전이  촉발없는 전이(triggerless transition)라 함. 예) GUI의 상태 다이어그램 초기화 Do / 부팅 작동 종료 스위치 ON / 전원공급() 스위치 Off / 전원중단()

State Diagram 상태 전이 선에 추가되는 정보 : 전이 조건 II.UML Diagram
어떤 조건에 따라 상태가 전이 될 때. 조건에 따른 상태 전이의 분기가 일어날 때. ‘[ ]’ 를 사용하여 조건(Guard)을 명시함. 예) 앞의 GUI 예에서 어떤 조건을 만족하면 스크린세이버가 작동하는 상태로 됨 초기화 Do / 부팅 작동 종료 스위치 ON / 전원공급() 스위치 Off / 전원중단() 화면보호기 [시간초과 했다면] 키누르기 또는 마우스움직이기/

State Diagram 하위상태 : 상태 안에 상태가 있을 때, 안에 있는 상태를 말함. 순차적 하위 상태
II.UML Diagram State Diagram 하위상태 : 상태 안에 상태가 있을 때, 안에 있는 상태를 말함. 순차적 하위 상태 하위 상태의 전이가 순차적으로 이루어 짐. 예) 앞의 GUI 예제에서 [작동] 상태의 하위 상태 전이를 나타낸다. 즉, [작동] 상태인 동안 사용자의 입력을 화면에 표현 하는 하위 상태들의 전이 과정을 표현한 것이다. 작동 사용자 입력대기 입력을 등록 사용자 입력을 화면에 나타냄 입력

State Diagram 동시적 하위 상태 II.UML Diagram 하위 상태의 동시 진행성을 표현.
동시 진행 하는 순차적 하위 상태를 점선으로 구분 지음. 예) 앞의 GUI 예제에서 “사용자 입력을 화면에 표현”하는 하위 상태 전이 단계와 더불어 “시스템 내의 시간을 정해진 간격마다 화면에 표현” 하는 또 다른 하위 상태 전이가 일어나는 과정을 나타냄. 즉, 우리가 워드를 치는 동안 윈도우의 “시작 메뉴바” 오른쪽에 시계는 분 마다 바뀐 값을 표현하는 것을 말함. 작동 사용자 입력대기 사용자 입력을 등록 사용자 입력을 화면에 나타냄 /입력 [시간간격 초과] 시스템 Clock 체크 시간 화면 갱신

II.UML Diagram Activity Diagram 업무과정(Business Process)를 표현하거나 오퍼레이션(Operation)의 알고리즘을 효과적으로 나타내는데 유용하게 사용된다. Flowchart와 상당히 흡사하다. State Diagram의 확장으로 볼 수 있다. 해당 활동내의 처리가 끝나면 그 다음의 활동으로 자동적으로 옮겨진다.

II.UML Diagram Activity Diagram : 표기법 활동 시작 표기 활동 표기 분기 표기 종료 표기 진행 표기

Activity Diagram 동시경로 II.UML Diagram 활동 활동1 활동2
Fork Join 동시에 실행 되었다가 하나로 모이는 두개의 처리 경로로 활동 전이를 분리해야 할 경우 굵은 선을 긋고, 이 선을 기준으로 하여 처리 경로를 그려주면 된다.

Activity Diagram : Sample
II.UML Diagram Activity Diagram : Sample 예제1) 짜장면 집에서 주문하는 과정. 1. 손님이 메뉴에서 음식을 고른다. 2. 웨이터를 부르고, 주문한다. 3. 웨이터는 주방장에게 주문사항을 알린다. 4. 만약 주문한 음식의 재료가 떨어졌으면 주방장은 웨이터에게 알린다. 5. 웨이터는 손님에게 알린다. 6. 다시 1 번부터 반복한다.

Activity Diagram : Sample
II.UML Diagram Activity Diagram : Sample Activity Diagram 메뉴에서 음식 고르기 웨이터 호출 및 주문 손님에게 알림 주방장에게 알림 [음식의 재료가 떨어졌다] 웨이터에게 알림 [만들 수 있다]

Activity Diagram – Swimlane
II.UML Diagram Activity Diagram – Swimlane 활동 다이어그램에 역할(role)을 표시함으로써 처리 과정에 속해있는 각 활동의 책임이 누구에게 있는지를 나타낼 수 있다. 손님 웨이터 주방장 메뉴에서 음식 고르기 웨이터 호출 및 주문 주방장에게 알림 [만들 수 있다] [음식의 재료가 떨어졌다] 웨이터에게 알림 손님에게 알림

Component Diagram II.UML Diagram People.dll Course.dll Professor
Offering Student Professor Course.dll People.dll User Register.exe Billing.exe Billing System

Component Diagram 컴포넌트 다이어그램(Component Diagram) 이란? 컴포넌트와 클래스 표현
II.UML Diagram Component Diagram 컴포넌트 다이어그램(Component Diagram) 이란? 컴포넌트는 물리적이고 교체 가능한 시스템의 한 부분이며. 정해진 인터페이스를 준수하고 실현한다. 컴포넌트는 일반적으로 클래스, 인터페이스, 그리고 협력과 같이 서로 다른 논리요소들을 물리적으로 패키지화 한 것이다. 컴포넌트와 클래스 클래스는 논리적으로 추상화한 것을 나타내며, 컴포넌트는 비트로된 세계에 있는 물리적인 것을 나타낸다. 컴포넌트는 노드에 존재할 수 있지만 클래스는 그렇지 않다 클래스는 속성과 오퍼레이션을 직접 가질 수 있지만, 컴포넌트는 자신의 인터페이스를 통해서만 접근할 수 있는 오퍼레이션들만 갖는다. 표현 컴포넌트는 탭이 달린 직사각형으로 표현한다. 이름 : 다른 컴포넌트와 구분된다. image.java

Component Diagram – 인터페이스
II.UML Diagram Component Diagram – 인터페이스 인터페이스 오퍼레이션의 모음으로 클래스나 컴포넌트의 서비스를 명세화하는데 사용된다. 컴포넌트 기반 분산객체시스템(COM+,EJB)은 컴포넌트를 함께 묶는 수단으로 인터페이스를 사용한다. 의존관계 인터페이스 실체화 image.java Component.java ImageObserver

Component 와 Interface표현
II.UML Diagram Component 와 Interface표현 생략된 모습(아이콘으로 인터페이스 표현) 확장형태 image.java Component.java ImageObserver ImageObserver 의존 인터페이스 실체화 <<interface>> ImageObserver Abort:int{final static} Error:int{final static} imageUpdate():Boolean image.java Component.java

Deploy Diagram 배치 다이어그램(Deploy Diagram) 이란? 표현
II.UML Diagram Deploy Diagram 배치 다이어그램(Deploy Diagram) 이란? 배치다이어그램은 객체지향 시스템의 물리적인 관점을 모델링하는데 사용된다. 실행처리 능력을 가지는 노드의 구성과 그 노드에 존재하는 컴포넌트들을 나타낸다. 배치다이어그램은 실행노드와 그 노드에 존재하는 컴포넌트의 구성을 나태내는 도해이다. 표현 노드를 입방체(Cube)로 표현한다. workstation

Deploy Diagram – 모델1 프로세서와 장치의 모델링 Client A Application Server
II.UML Diagram Deploy Diagram – 모델1 프로세서와 장치의 모델링 Client A <<TCP/IP>> Application Server Database Server <<Ethernet>> Client B <<TCP/IP>>

Deploy Diagram – 모델2 컴포넌트 분산의 모델링 Client PC Server BackupStation
II.UML Diagram Deploy Diagram – 모델2 컴포넌트 분산의 모델링 Server BackupStation <<TCP/IP>> <<RS-232-C>> Win98 AppClnt NetDrv AdPgm Client PC Admin PC

사례1:이력게시판 사례2:고객지원접수시스템
3. UML 적용사례 사례1:이력게시판 사례2:고객지원접수시스템

사례1:이력게시판 적용사례 UseCase명 Actor 설명 BoardList 게시판 목록보기 기능 BoardInsert
III. UML 적용사례 사례1:이력게시판 적용사례 UseCase명 Actor 설명 BoardList 사용자,교직원,관리자 게시판 목록보기 기능 BoardInsert 게시판 자료등록 기능 BoardUpdate 게시판 자료변경 기능 BoardDelete 게시판 자료삭제 기능 BoardReply 게시판 답변쓰기 기능 BoardRole 관리자 게시판 권한 체크 기능 BoardConfig 교직원,관리자 게시판 환경설정 기능

사례1: 이력게시판 Use Case Diagram
III. UML 적용사례 사례1: 이력게시판 Use Case Diagram 사용자 교직원 관리자

III. UML 적용사례 이력게시판 : Class Diagram

이력게시판:Sequence Diagram
III. UML 적용사례 이력게시판:Sequence Diagram

사례2: 고객지원접수시스템 고객지원접수 Use Case Diagram
III. UML 적용사례 사례2: 고객지원접수시스템 고객지원접수 Use Case Diagram

고객접수등록 Use Case 명세서 III. UML 적용사례 고객접수등록 Use Case 개요
고객은 자신이 담당하고 있는 기관의 고객지원접수를 등록한다. 관련 Actor 고객 Event Flow 3.1 Precondition 고객은 로그인 된 상태임 3.2 Main Flow 고객이 고객지원접수버튼을 클릭하면 use case가 시작된다. 시스템은 고객의 의뢰자이름, 을 출력한다. 고객은 의뢰내용을 입력하고 파일첨부를 한 후 등록버튼을 클릭하면 DB에 저장되고 고객지원 리스트로 이동한다. 해당 접수건이 DB에 저장되면 해당 접수는 상태는 접수중이되고 관리자에게 메일이 발송된다. 3.3 Alternative Flow 3.4 Exception Flow [O001] 고객지원접수 등록중에 오류가 발생하면 실패 메시지를 alert창으로 출력하고 [해당 화 면]으로 이동한다. 3.5 MMI

고객접수등록 Sequence Diagram
III. UML 적용사례 고객접수등록 Sequence Diagram

III. UML 적용사례 고객지원접수 Class Diagram

J2EE 설계 특징 UML, OOP 기준 비기능적 요구사항 반영 Java 기반: Write Once, Run Anyway
GoF 디자인 패턴 활용 Together, JBuilder 툴 사용 비기능적 요구사항 반영 성능, 신뢰도, 확장성, 유지보수성 등 프로그래밍 언어, 운영체제, 미들웨어, 컴포넌트 모델, 애플리케이션 서버 Java 기반: Write Once, Run Anyway EJB 컴포넌트 통한 분산 시스템 구축 아키텍쳐 제공

논리적 시스템 구조와 설계 Presentation Layer: 사용자로부터의 입력과 시스템의 결과를 사용자에게 출력
JSP, Servlet ASP, .NET 페이지 Business Logic Layer: 시스템이 제공하는 기능 제공 세션 빈 COM+ 클래스 Data Access Layer: 시스템이 관리하는 영속성 있는 데이터에 대한 접근 및 제어 전담 엔티티빈, JDBC API ADO .NET을 이용하는 COM+ 클래스

설계 준비 Together: J2EE 플랫폼상에서 시스템을 개발하기 위한 충분한 환경 제공
소스코드 자동생성, 수정, Java 소스 컴파일/빌드/디플로이 가능 Design -> Java 언어로 전환 Together에서 Design 프로젝트에서 Java 소스 코드 프로젝트로 전환 프로젝트에서 Tools|Generate Source Code for Design Project 선택 해당되는 값 입력

설계 준비

Presentation Logic 설계

<<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”>를 의미

<<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”>를 의미

<<JSP>> 설계요소의 연산
Form_onSubmit(): submit 버튼이 눌렸을 때 수행되는 기능 <input type=“submit” value=“login” onSubmit=‘return validate()’> Form_onReset(): reset 버튼이 눌렸을 때 수행되는 기능

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") ;

LoginProc 설계 요소 if ( success ) { //세션에 사용자 아이디를 기억시킨다.
session.setAttribute("userId",userId); // MainFrame 화면으로 전환한다. response.sendRedirect("MainFrame.jsp") ; } else { %> <SCRIPT LANGUAGE="javascript">  </SCRIPT>

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) ; %>

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>

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

Similar presentations

Presentation on theme: "WAA: J2EE 설계 및 UML 2008.봄학기 E-비즈니스학과 이영곤."— Presentation transcript:

Similar presentations

About project

지원

로그인

Auth with social network:

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

Similar presentations

Presentation on theme: "WAA: J2EE 설계 및 UML 2008.봄학기 E-비즈니스학과 이영곤."— Presentation transcript:

Similar presentations

About project

지원