Въведение в unified modeling language (uml) и интеграцията му в oracle ...

Въведение в Unified Modeling Language (UML) и

интеграцията му в ORACLE JDeveloper 9i

Александър Станев

БанкСервиз АД

БГПО Семинар “ORACLE 9i Development Suite”.

2

Съдържание

Използване на Модели UML Моделиране

Архитектурни изгледи Елементи Диаграми

Интеграция в JDeveloper


3

Прости конструкции - могат да бъдат изградени и от един човекИзискват• Минимално моделиране• Прост процес• Прости средства

Използване на модели

Сложни конструкции – Изграждат се от екипи от контрагентиИзискват• Инженерен модел• Координиран процес• Индустриални машини

Средни по сложност – Изграждат се по-ефективно от екип

Изискват• Моделиране• Ясно дефиниран процес• Автоматизирани средства


4

Предназначение на моделирането

Осигурява структура за решаване на проблемиПозволява експерименти за откриване на различни решенияДава ниво на абстрактност за управление на сложни взаимовръзкиНамалява времето за реализиранеПонижаване на цената за разработванеПозволява управление на риска от грешки в проектирането


5

Език за моделиране на софтуер

Какво е UML? UML е съкращение от Unified Modeling Language Стандартен език с набор от знаци за означаване

предназначен за визуализиране, специфициране конструиране и документиране на софтуерен дизайн

Използва концепции от Моделирането на данни (Entity Relationship Diagrams) Бизнес моделиране (work flow) Обектно моделиране Компонентно моделиране

Създатели Grady Booch, James Rumbaugh, and Ivar Jacobson


6

История на UML

OOPSLA ´95

Web - June ´96

OMG revision, Sep ‘97

OMG submission, Jan ´97

OMG Acceptance, Nov 1997

UML partners

Revision Task Force (RTF) report, Apr 1999

Booch method OMT

Unified Method 0.8

OOSE&

Other methods

UML 0.9

UML 1.1

UML 1.3

UML 1.0

Microsoft, Oracle,

IBM, HP, &other industry leaders

Othersubmissions

OMGFeedback


7

Участници в OMG

AonixColorado State UniversityComputer AssociatesConcept FiveData AccessEDSEnea DataHewlett-Packard IBMI-LogixInLine SoftwareIntellicorpKabira TechnologiesKlasse ObjectenLockheed Martin

MicrosoftObjecTime

OraclePtech OAO Technology SolutionsRational SoftwareReichSAPSofteamSterling SoftwareSunTaskonTelelogicUnisys…


8

Какво е UML и какво не е?

Стандартен език за моделиране на софтуерни системи

Дефинира значещ метамодел на системата

Независим е от процеса на разработване на системата

Език за програмиране Интерфейс към средство run-time модел Стандартен процес за

разработване на софтуерни системи

UML e: UML не е:


9

Deployment View

Implementation View

Архитектура

Process View

Design View

Use Case View

речникфункционалност

ПроизводителностСкалируемостПроизводство

поведение

Сглобяване на системата

Конфигурационен мениджмънт.

Топология на системата

разпределениедоставка

инсталиране

Архитектурата – комплекс от важни решения относно: Организацията на софтуерната система. Избор на структурни елементи и интерфейси от които е

съставена системата. Поведението и взаимодействието на елементите. Съединяването на структурните и поведенческите елементи. Стилът при изграждането на системата.


10

Use Case View

Use Case View Use Case Анализът е техника за описание на бизнес процес

от гледна точка на потребителя на системата. Обхваща поведението на системата както тя изглежда за

потребителите, аналитиците и тестерите. Специфицира въздействията, които оформят

архитектурата. Статичните аспекти се представят от use case диаграми. Динамичните аспекти се представят в interaction, statechart,

and activity диаграми.


11

Design View

Design View

Обхваща класовете, интерфейсите и взаимодействията, които дефинират “речника” на системата.

Поддържа функционалните изисквания на системата.

Статичните аспекти се представят от class and object диаграмите.

Динамичните аспекти се представят в interaction, statechart, and activity диаграми.


12

Process View

Process View Обхваща нишките и процесите дефиниращи

съгласуваност и синхронизираност. Адресиран към производителност, скалируемост и

производствени възможности на системата.


13

Implementation View

Implementation View Обхваща компонентите и файловете използвани за

сглобяване и пускане в експлоатация на реалната система.

Адресиран към конфигурационния мениджмънт. Статичните аспекти се представят от component

диаграми. Динамичните аспекти се представят в interaction,

statechart и activity диаграми.


14

Deployment View

Deployment View

Обхваща възлите, които формират хардуерната топология на системата.

Адресиран към разпространение, доставка и инсталиране.

Статичните аспекти се представят от deployment диаграми.

Динамичните аспекти се представят в interaction, statechart и activity диаграми.


15

Език

Език = синтаксис + семантика синтаксис = правила, чрез които

елементите на езика (напр.. думите) се сглобяват в изрази (напр. фрази, изречения)

семантика = правила, чрез които на синтактичните изрази им се придава смисъл

UML Notation Guide – дефинира графичният синтаксис на UML

UML Semantics – дефинира семантиката на UML


16

Изграждащи блокове Ясно дефинирани правила

Фундаментални идеи


17

Основните изграждащи блокове на UML са: Елементи на модела (classes, interfaces,

components, use cases, др.) релации (associations, generalization,

dependencies, др.) диаграми (class diagrams, use case diagrams,

interaction diagrams, др.) Простите изграждащи блокове се използват за

изграждането на големи, комплексни структури

Изграждащи блокове


18

Ясно дефинирани правила

Добре формирани: индицира, че модела или кой да е фрагмент от модела спазва всички семантични и синтактични правила.

UML задава правила за:

именоване област на действие видимост интегритет изпълнение

Все пак, по време на итеративното последователно нарастващо разработване може да се очаква, че модела може да бъде непълен или неконсистентен.


19

Ограничения (Constraints)позволяват означаване на произволни ограничения върху елементите на модела. Например: могат да се използват за ограничаване стойност на даден атрибут на клас.

Стереотипи (Stereotypes)позволяват разширяването на семантиката на UML с говорим език. Стереотипа е обикновено дума или кратка фраза, която описва какво е дадения елемент на диаграмата. Могат да се използват за разширяване на UML елементите и могат да се използват за класифициране, разширение на асоциации, класове, релации по наследяване (inheritance), класове или компоненти

Разширяемост на UML


20

Изграждащи блокове на UML

Елементи на модела Важните понятия в модела

Релации Връзките между отделните елементи на модела

Диаграми Групиране на взаимно свързаните групи от

елементи и релации


21

Структурнисъществителните в моделите описвани с

езика UML. Поведенчески

динамичните (глаголни) части от UML моделите.

Групиращи

организационните части от UML моделите.

Коментарни

пояснителните части от UML моделите.

Елементи


22

Съществителните на UML моделите.Концептуални или материални елементи.

Windoworiginsize

open( )close( )move( )

IWindow

Chain ofResponsibility

PlaceOrder

Event Mgrthreadtime

suspend( )flush( )stop( )

listbox

Class

Interface

Collaboration

Use Case

Active Class

Component

Node

WebServer

Структурни елементи


23

КласОписание на набор от обекти, които споделят едни и същи атрибути, операции, релации и семантика.Обикновено имплементират един или повече интерфейса.

Window

originsize

open()close()

име

атрибути

операции

ИнтерфейсНабор от операции, които определят услуга (сървиз) (за ресурс или действие) на клас или компонент. Описва видимото отвън поведение на този елемент.

<<interface>>IWindow

open()close()

име

операции



24

Chain ofResponsibility

Дефинира взаимодействието в мрежата от обекти.Дефинира общност от ролите и останалите елементи.Обезпечава поведението при взаимодействията.Извлича структурните и поведенческите измерения.

Колаборация

Place Order

Поредица от действие, които водят до забележим резултат за определено действащо лице (actor).Осигурява структура за поведенческите елементи.Осъществява се посредством колаборация (обикновено между набор от действащи лица и системата, която се изгражда).

Use Case



25

Специален клас, чиито обекти притежават един или повече процеса или нишки.

Може да инициира контролна дейност.

имеатрибутиоперации

Heavy border

Активен клас Event Manager

suspend()flush()

Threadtime

Orderform.java

Заменяема част от системата.Компонентите могат да бъдат пакетирани логически.Съобразен с набора от интерфейси.Обезпечава реализацията на интерфейс.

Компонент

WebServerЕлемент, който съществува в рънтайм.Представя изчислителен ресурс.Обикновено има памет и процесорна мощ.

Ноуд



26

Поведенчески елементи

Два основни типа поведенчески елементи:

Те са:Глаголите в UML моделите.Динамичните части от UML моделите: “поведението във времето и пространството”Обикновено свързани към структурните елементи на UML.

ИнтеракцияПоведението на набор от обекти, обхващащо набор от съобщения в рамките на даден контекст за постигането на специфична цел.

display

Машина на състоянието (State Machine)Поведението, което описва последователността на състоянията на обекта или взаимодействието в резултат от събития, случващо се през време на живота му, обединени с отговора на тези събития. WaitingIdle


27

Пакети – Основен тип групиране. Механизъм с общо предназначение за организирането на елементите в групи.Изцяло концептуален; съществува само по време на разработването.Съдържа структурни и поведенчески елементи.Могат да се влагат.Вариации на пакети са: Frameworks, модели и подсистеми.

Meeting Scheduler

Групиращи елементи


28

Коментарни елементи

flexible drop-out dates

Пояснителните части на UML моделитеБележки относно други UML елементи (обикновено се наричат украси в UML)

Бележка (Note) основен коментарен елемент в UML, изразява се чрез

формален или неформален текст.


29

Релации

4 типа: Зависимост (Dependency) Асоциация (Association) Обобщение (Generalization) Реализация (Realization)


30

Асоциация (Associations)Структурна релация, описваща набор от връзки, като връзка е отделното отношение между обектите.

Насочени етикети множественост & имена на роли

Зависимост (Dependency)

Семантичната връзка между два елемента, в която промяната в единия от елементите (независим елемент) може да въздейства върху семантиката на другия елемент (зависим).

Релации

Насочването и етиката са опционални.

0..1employer

*

employee

Агрегация (Aggregation) Специален тип асоциация. Представя структурното взаимодействие между цялото и неговите части.

Представя се чрез черен ромб.


31

Релации

Обобщение (Generalization)Отношение специализация/обобщение, което обектите на специализирания елемент (детето) са по-точно определени и специфични, отколкото обектите на обобщаващия елемент (родителя).

Реализация (Realization)Семантично взаимоотношение между два елемента, в което единия елемент гарантира, че осъществява това, което се очаква от другия.Напр. Между интерфейсите и класовете които ги реализират.


32

Диаграми

Class Диаграми; Object Диаграми

Use case Диаграми; Sequence Диаграми;

Collaboration Диаграми; Statechart Диаграми

Activity Диаграми; Component Диаграми

Deployment Диаграми

Графично представяне на група от елементи.Изобразяват се чрез свързан граф: Листата са елементите; Дъгите са поведенията.5 основни изгледа се изграждат от 9 типа диаграми.


33

Типове UML Диаграми

Структурни Диаграми (Structural Diagrams)

фокусът е върху статичните аспекти на софтуерната система

Class Диаграма Object Диаграма Component Диаграма Deployment Диаграма

Поведенчески диаграми (Behavioral Diagrams) фокусът е върху динамичните аспекти на софтуерната система Use-case Диаграма Interaction Диаграма State Chart Диаграма Activity Диаграма


34

Use Case Диаграми

Use case модела разделя системната функционалност на транзакции (‘use cases’) , които са значещи за участниците (‘actors’).

Use case е описание на сценарий, който приложението би или не би могло да управлява. Описва как участника взаимодейства със системата.

Use case е модел на поведението, което системата проявява.

Всеки use case е последователност от свързани транзакции, изпълнени от участниците (актьорите) и системата в диалог

Use case и use case диаграмата дават use case модел


35

Use Case Диаграми - Елементи

Потребител

Регистрира плащания

Платежна система

Use case диаграмите са създадени да визуализират връзките между участниците и use case

Use case елемента е модел на поведението, което системата проявява Регистриране

Участник (actor) е някой или нещо, на който се налага да взаимодейства със системата.

Регистратор


36

Use case

Описание: Всеки use case има описващо го име Описва какво системата прави, но не и как го прави. Use case имената трябва да са уникални в рамките

на даден пакет.

A Use Case


37

Какво е Use Case

Use case обхваща някаква видима от потребителя функционалност.

Гранулата на функционалността зависи от нивото на детайлност в модела.

Всеки use case реализира независим резултат за потребителя.

Use Case се създават чрез анализ на изискванията към системата.


38

Actor

Участниците (Actors) имат име. Участникът е набор от роли, които потребителите на

use case-а играят , когато взаимодействат със системата.

Те са външни за системата единици. Могат да бъдат и външни системи.

An Actor


39

Основни Елементи

Елемент Описание Синатксис

use case Последователност от действия, включително вариантите им, които системата може да изпълни, взаимодействайки с участниците в нея.

Участник (actor)

Съгласуван набор от роли, които потребителите на use casе играят, когато взаимодействат с тези use case

Граница на системата (system boundary)

Представя границата между материализираната система и участниците, които взаимодействат с нея.

UseCaseNam e

ActorNam e


40

Construct Description Syntax

Асициация (аssociation)

Участието на участник в use case, т.е., участник и use case комуникират помежду си.

разширение (extend)

Отношение на разширявана на use case спрямо базовия use case, специфициращо как поведението на разширения use case може да бъде вмъкнато в поведението дефинирано за базовия use case.

Обобщение (generalization)

Класификационно отношение между по-общ use case и по-детайлен use case.

Основни Релации

<<extend>>


41

Construct Description Syntax

включване (include)

Релация от базовия use case към включвания use case, специфицираща как поведението за включвания use case се включва в поведението, дефинирано за базовия use case.

Основни Релации

<<include>>


42

Релации между use case (пример)

Релацията употреба (uses) показва поведение, общо за един или повече use case.

Релацията разширяване (extends) показва опционално поведение.

Регистрация за курс

<<uses>>

Проверка за достъп<<uses>>

Поддръжка на програмата на курса

Регистрация за дистанционни курсове

<<extends>>


43

Документиране

Потокът от събития се описва в документация за всеки use case, като:

Написани от гледна точка на участник (actor) Детайлизира какво системата трябва да осигури на

участника, когато се изпълни use case-а. Типично съдържание

Как стартира и завършва use case Нормалния поток на събитията Алтернативния поток на събитията Потока на събитията при изключение (Exceptions)


44

Use Case Диаграма - пример

Actor - Person, Organization, orSystemUse Case

System

Interaction

Information Flow


45

Use Case – Полезни съвети

Да се осигури, че всеки use case описва значима част от използването на системата, която е разбираема и за програмистите и за експертите при потребителя.

Когато се дефинират use casе в текстова форма, да се използват съществителните и глаголите акуратно и съгласувано, за да се подпомогне извличането на обектите и съобщенията за interaction диаграмите.


46

Use Case – Полезни съвети

Една use case диаграма трябва: Да съдържа само набор от use case на едно

ниво на абстракция Да включва само участниците, необходимите

за осъществяването на представените в нея набор от use case.

По голям брой use case би следвало да се организират в пакети.


47

Interaction Диаграми

Interaction диаграмите описват как use case са реализирани като взаимодействие между общност от обекти, включвайки съобщенията, които могат да се изпращат между тях.

Създават се една или повече interaction диаграми за един use case.

Адресирани са към динамичния изглед на системата.

Представят последователността на взаимодействията.

Съставени са от обекти, връзки и съобщения.


48

Типове Interaction Диаграми

Sequence диаграми (Диаграми на последователността) Моделира начина на управление за организацията по

време. Наблягат на течащите съобщения във времето Показват прости повторения и разклонения

Collaboration диаграми (Диаграми на сътрудничеството) Моделира начина на управление за организацията Структурни релации между реализации при

изпълнение Показват сложни повторения и разклонения


49

Sequence Диаграми

Sequence диаграма (обектна диаграма или event trace диаграма) се използва за да се дефинира логиката за дефиниран use case сценарий.

Sequence диаграмата показва взаимодействията между обектите подредени по време.

Най-често се използват за да се провери use cases при преминаване през логиката на сценария.

Показва типовете обекти включени в use case-а, съобщенията които те си изпращат един на друг и всяка върната стойност, асоциирана със съобщението.

Правоъгълниците върху вертикалните линии са т.нар. “Кутии за изпълнение на методи” (method invocation boxes), които представят изпълнението на метод в обект.


50

Sequence Диаграма

По ордината са обектите Обекта инициатор на взаимодействието е

най-вляво Обектите надясно са в нарастваща по степен

подчиненост По абсцисата е времето

Изпратените и получените съобщения са подредени по време

Активацията (аctivation), изразявана с двойна линия, е изпълнението на процедура.


51

Sequence Диаграма (пример)Objects

Method Invocation

Messages


52

Collaboration Диаграми

С ударение върху: Организацията на обектите, които участват във

взаимодействие. Класифицира ролите Асоциацията между обектите Съобщенията, потока на движението им и

последователността


53

Collaboration Диаграми

Collaboration диаграмите визуализират взаимодействието между обектите, по начин, насочен към обектите и техните връзки един с друг

Показват движението на съобщенията между обектите. Правоъгълниците са различните обекти и ролите, които

те имат в приложението (системата). Линиите между обектите са релациите или асоциациите

между тях. Съобщенията са етикети, последвани от стрелка,

показваща посоката на движението на съобщението. Връщаните стойности са етикети последвани от кръг със

стрелка. Collaboration диаграмите се използват за получаването

на общата картина на системата, с включен поток на съобщенията за много use case сценарии.


54

Обменяни Съобщения

Send – изпраща сигнал (съобщение) на обекта Return – връща стойност на извикващия Call – извиква операция Стереотипи (stereotype)

<<create>> <<destroy>>

call

send

Return


55

: Registrar

course form : CourseForm

theManager : CurriculumManager

aCourse : Course

1: set course info2: process

3: add course

4: new course

Collaboration Diagram

Показват взаимодействията между обектите. В основата на диаграмите са обектите и техните насочени връзки един към друг.

Демонстрират структурната организация на обектите, които изпращат и получават съобщения.


56

Collaboration Диаграма (пример)Objects

Relationship

MessageReturn Value


57

Class Диаграми

Показва статичната структура на класовете в системата

Класовете представят нещата, които се манипулират в системата

Класовете могат да се съотнасят един към друг по следните начини: Подчинен – зависи от или използва друг клас Ограничен – ограничение на друг клас Пакетирани или групирани заедно като едно

цяло Един клас може да участва в няколко class диаграми


58


Class диаграмата показва съществуването на класовете и техните взаимодействия.

UML елементи в class диаграмите Класовете с техните структура и поведение Отношенията: Association, aggregation,

dependency и inheritance Имена на роли


59

Клас (Class)

Клас Класът сбор от обекти с общи поведение,

структура, релации и семантика Класът се изобразява като правоъгълник с

три отделения.

+print()

-name : string(idl)-age : int

PersonИме на класа

Атрибути

Оператори


60

Какво е добър клас?

Трябва да осигурява ясна абстракция на нещо от областите на задачата или решението.

Да въплъщава малък, добре дефиниран набор от отговорности и да ги изпълнява добре.

Осигурява ясно и точно изолиране между абстракция, спецификация и изпълнение.

Да е разбираем и прост и в същото време разширяем и пригодим.


61

Документиране

Класовете се документират, като се описва какво извършват.

Методите се документират като се описва тяхната логика.

Атрибутите се документират, като се описва какво съдържат, техния тип и указание за обхвата на стойностите им.

Релациите между класовете се документират, като се описва тяхното предназначение, това колко обекта са въвлечени в релацията и дали или не един обект трябва да участва в релацията


62

Class Диаграма (пример)

Class

Attribute

Methods

Relationship


63

State Transition Диаграми

Диаграми на състоянията (State diagrams)

използват се да описват как работят обектите

Показват: Историята на живота на даден клас Събитията (events), които причиняват

преминаването от едно състояние в друго Действията в резултат от промяната на

състоянието.


64

Елементи

Правоъгълниците са състоянията, които са етапи в поведението на обект

Състоянията се представят чрез стойностите на аргумент на обект.

Стрелките представят преходите – напредването от едно състояние в друго.

Началното състояние се представя от плътен кръг.

Крайното състояние се представя с очертан кръг.


65

InitializationOpen

entry: Register studentexit: Increment count

Closed

Canceled

do: Initialize course

do: Finalize course

do: Notify registered students

Add Student / Set count = 0

Add student[ count < 10 ]

[ count = 10 ]

Cancel

Cancel

Cancel

State Transition Диаграми

Събитията, причиняващи преминаването от едно състояние в друго. Действията в резултат на промяна в състоянието.


66

State Transition Диаграми(пример)

State

Final State

Initial StateTransition


67

Activity Diagram - description

Диаграмите за Дейностите (Activity diagrams ) позволяват визуалното представяне на процесите и това как те се синхронизират.

Описват многонишково поведение Activity диаграмата е вариация на машината на

състоянието(State Mashine), в която състоянията са Дейности (Activities)


68

Дейност (Activity)

Представят вътрешни действия (чакане, контролиране и т.н.), изпълнявани, когато обекта е в определено състояние

Изискват време за изпълнение и могат да бъдат прекъсвани


69

Activity Diagrams•Показват движението от дейност към дейност.

BodySwimlanesМеханизъм за групиране и организиране на състоянията на дейностите (activity states)

Prepare for speech

Decompress

Synch Mouth Stream Audio

Cleanup

Gesture

Mind


70

Implementation Диаграми

Диаграми за реализацията Показват аспекти на осъществяването на

модела, включвайки структурата на сорс и структурата на системата в експлоатация.

Типове: Компонентна (component) диаграми Внедрителна (deployment) диаграми


71

Показва организацията и връзките между набора от софтуерни компоненти.

Компонентите включват: Компонентите на сорс кода Компоненти на бинарния код Изпълними компоненти

Component Диаграма


72

Component Диаграма

Component диаграмите показват софтуерните компоненти съставящи софтуерни елементи, позволяващи многократно ползване и техните взаимовръзки.

Кутиите представят компонентите. Пунктираните линии показват зависимостите между

компонентите. Целта е да се раздели системата на компоненти ,

имащи стабилни интерфейси, изграждайки ядро, което няма нужда от промяна в отговор на промени на ниво подсистема.


73

Component Diagram

Components Dependencies


74


Deployment диаграмите показват конфигурацията на експлоатационните изчислителни единици, включвайки хардуера и софтуера, който се изпълнява в тях.

Deployment диаграмите могат да бъдат използвани да показват кой компонент на кой ноуд се изпълнява

Ползват подобни означения се, като при component диаграмите.

Deployment диаграмите показват как хардуерните и софтуерни единици, ще бъдат конфигурирани и внедрени.

Нещата които трябва да се вземат предвид за всеки компонент, са подходящите техническите изисквания като скоростта на мрежата, времето за отговор, размера на данните и т.н.


75

Deployment Диаграма

Components

Node


76

Регистрация База данни

Библиотека

Представителство

Централно Управление


Deployment диаграмите визуализират и разпределението на компонентите из административната организация (предприятието).


77

Накратко за UML

Показва границите на системата и нейните главни функции, използвайки use cases и actors

Илюстрира use case реализациите с interaction диаграми

Представя статичната структура на системата, използвайки class диаграми

Моделира поведението на обектите чрез state transition диаграми

Показва материалното осъществяване на архитектурата с component и deployment диаграми

Разширяване на функционалността със stereotypes


78

Последователност

Последователност при UML моделирането


79

UML Моделиране


80

Препоръки за използването

Избягвайте модели, които са: Съкратени — някой елементи са скрити за

опростяване. Непълни — определени елементи може би

липсват. Противоречиви — няма гаранция за

интегритет.


81

Процес по използване

Как да използваме UML като система за означаване, за да изградим добър модел? Воден от Use case

use case са първичния продукт за дефиниране поведението на системата.

Архитектурата е в центъра Системната архитектура е първият продукт за

концептуализиране, конструиране, управление и развитие на системата.

Итеративен и нарастващУправлението на поток от изпълними реализации с

включени нарастващи части на архитектурата на системата.


82

Свойства:

Непрекъсната интеграция – Не се извършва наведнъж около датата на внедряване

Чести изпълними версии – Някои вътрешни, някои внедрявани

Атакува риска чрез демонстрируем напредък – Напредъкът, измерен в продукти, а не в документация или инженерни оценки

Итеративно моделиране

Ползи: Създаването на работещи варианти на регулярна база за

проверка на модела са и начин за приключване на работата по разработване за дадения цикъл на итерация. Не е възможен феномена “90% са направени, остават още 90%”

Останалите участници в проекта – екипите за тестване, за писане на документация и т.н., могат по-добре да планират своята работа.


83

JDeveloper UML

Моделиране на Java Класове Моделиране на Business Components Моделиране на Enterprise JavaBeans Моделиране на Activities Моделиране на Activities for E-Business Integration Моделиране на Web Services


84

UML в JDeveloper

Class Диаграми Activity Диаграми Интеграция с Oracle 9iAS Integration


85


Class диаграмите в Jdeveloper, могат дасе използват за създаване на модели, съдържащи следнното:

Java класове, от които може да бъде генериран Java сорс код

Java класове, получени чрез ревърс инженеринг на съществуващ Java сорс код

UML класове импортирани от XMI файлове, като моделирани Java класове

Бизнес компоненти, от които могат да се генерират обекти на базата данни

Бизнес компоненти, получени чрез ревърс инженеринг на съществуващи таблици

Enterprise JavaBeans Enterprise JavaBeans, получени чрез ревърс инженеринг

на tables web services


86



87

Activity Диаграми

Activity диаграмите могат да бъдат използвани за създаването на модели, съдържащи следното:

дейности, потоци и състояния за илюстриране на процес

дейности от които може да се генерира e-business integration код.


88

Activity Диаграми


89

Internet UML Ресурси

Oracle Technology Network http://otn.oracle.com

UML Revision Task Force uml.shl.com

Object Management Group www.omg.org

Rational Software Corp.'s UML Resource Center http://www.rational.com/uml/index.jtmpl

Lockheed Martin Advanced Concepts Center http://www.lmco.com/acc/

Software Development Magazine http://www.sdmagazine.com/uml/

UML resource page http://home.pacbell.net/ckobryn/uml.htm

Въведение в unified modeling language (uml) и интеграцията му в oracle ...

Documents

case diagrams

actoruse case

meeting scheduler uml

uml jdeveloper

stereotypes uml

interaction interaction

uml windoworiginsizeopen

runtime uml e