12

UMLобеспечиваетподдержкувсехэтаповжизненногоциклаИСипредоставляетдляэтих целейрядграфическихсредств–диаграмм.

Наэтапесоздания концептуальноймодели дляописаниябизнес-деятельностииспользуются моделибизнес-прецедентов идиаграммывидовдеятельности, дляописаниябизнес-объектов– моделибизнес-объектов идиаграммыпоследовательностей.

НаэтапесозданиялогическоймоделиИСописаниетребованийксистемезадаетсяввиде моделиописаниясистемныхпрецедентов, апредварительноепроектирование осуществляетиспользованядиаграммемклассов, диаграммпоследовательностейи диаграммсостояний.

Наэтапесозданияфизическмойделидетальноепроектированиевыполняется использовандиаграммемклассов, диаграммкомпонентов, диаграммразвертывания.

Нижеприводятсяопределенияописываетсяназначениеперечисленныхдиаграммоделей применительнокзадачампроектированияИС( скобкахприведеныальтернативныеназвания диаграмм, использующиесявсовременнойлитературе).

Диаграммыпрецедентов(диаграммывариантовиспользования, use case diagrams)это – обобщеннаямодельфункционированиясистемывокружающейсреде.

Диаграммывидовдеятельности(диаграммыдеятельностей, activity diagrams)модельбизнес– - процессаилиповеденсистемыяврамкахпрецедента.

Диаграммывзаимодействия(interaction diagrams)модельпроцесса– обменасообщениями междуобъектами, представляетсявидедиаграммпоследовательностей(sequence diagrams) иликооперативныхдиаграмм(collaboration diagrams).

Диаграммысостояний(statechart diagrams)модельдинамическ– поведенгосистемыяее компонентовприпереходеизодногосостояниявдругое.

Диаграммыклассов(class diagrams)логическая– модельбазовойструктурысистемы, отражаетстатическуюструктурусистемысвязимеждуееэлементами.

Диаграммыбазыданных(database diagrams)модельструктуры— базыданных, отображает таблицы, столбцы, ограниченият.п.

Диаграммыкомпонентов(component diagrams)модельиерархии– подсистем, отражает физическоеразмещениебазданных, приложенинтерфейсовИС.

Диаграммыразвертыван(диаграммыяразмещения, deployment diagrams)модель– физическойархитектурысистемы, отображаппаратнуюетконфигурациюИС.

На рис. 12.1 показаныотношениямеждуразличнымивидамидиаграммUMLУказатели. стрелокможноинтерпретироватькакотношение"являетсяисточникомвходныхданных для..."например( , диаграммапрецедентовявляетсяисточникомданныхдлядиаграммвидов деятельностипоследовательности).Приведеннаясхемаявляетсянагляднойиллюстрацией итеративногохарактераразработкимоделейсиспользованиемUML.

Рис. 12.1. ВзаимосвязимеждудиаграммамиUML

НижеприводятсяописанияпоследовательныхэтаповпроектированияИСсиспользованием

UML.

Разработкамоделибизнес-прецедентов

Модельбизнес-прецедентов описываетбизнес-процессточкиызрениявнешнего пользователя, . . отражаетвзгляднадеятельнорганизациистьвне.

Проектированиесистемыначинаетсяизученимоделированиябизнес-деятельности организации. Наэтомэтапевводитсяотображаетсявмоделирядпонятий, свойственных объектно-ориентированномуподходу:

Исполнитель(Действующеелицо, Actor)личность– , организацияилисистема, взаимодействующаяИС;различаютвнешнегоисполнителя(которыйиспользуетили используетсясистемой, . . порождаетпрецедентыдеятельности) внутреннегоисполнителя (которыйобеспечиваетреализациюпрецедентовдеятельностивнутрисистемы).Надиаграмме исполнительпредставляетсястилизованнойфигуркойчеловека.

Прецедент–законченнаяпоследовательностьдейств,инициированй внешнимаяобъектом (личностьюилисистемой),котораявзаимодействуетИС получаетврезультатенекоторое сообщениеотИС. Надиаграммепредставляетсяоваломснадписью, отражающейсодержание действия.

Класс—описаниесовокупноднородныхстиобъектовсихатрибутами, операциями, отношениямисемантикой. Надиаграммепредставляетсяпрямоугольником, содержащим описанияатрибутовоперацийкласса.

Ассоциация–связьмеждудвумяэлементамимодели. Надиаграммепредставляетсялинией.

Обобщение–связьмеждудвумяэлементамимодели, когдаодинэлемент(подкласс)является частнымслучаемдругогоэлемента(суперкласса).Н диаграммепредставляетсястрелкой.

Агрегация–отношениемеждуэлементамимодели, когдаодинэлементявляетсячастью другогоэлемента(агрегата).Надиаграммепредставляетсястрелкойромбовиднымконцом.

Дляиллюстрацииэтаповразработкипроектаиспользовадаптированныематериалы проектаИСмедицинскогоцентра[ рис. 12.2 ].НазначениеИС–автоматизацияведения

использованклияническихзаписейопациентах. Внастоящеевремяэтаработапроизводится

вручнуюперсоналомцентра. На	рис. 12.2		представленаобщаямодельдеятельностицентрав
видедиаграммыпрецедентов. Прецедент"			Обслуживание пациента "реализуетсячерез
множестводругих, болееограниченныхпрецедентов(			рис. 12.3 ),отражающихдетализацию
представленияфункционировацениятра.

Рис. 12.2. Общаядиаграммадеятельностимедицинскогоцентрапообслуживаниюпациента

Рис. 12.3. Модельбизнес-прецедент, составляющихобслуживаниепациента

Длявключениядиаграммувыбранныепрецедентыдолжныудовлетворятьследующим критериям:

•	прецедент должен описывать, ЧТО нужноделать, не	КАК ;
•прецедентдолженописыватьдействияточкизрения		ИСПОЛНИТЕЛЯ ;
•	прецедент должен возвращатьисполнителюнекоторое	СООБЩЕНИЕ ;
•	последовательностьдействий внутри прецедентадолжна	представлятьсобой одну
	НЕДЕЛИМУЮ цепочку.

Исходяизцелисозданиясистемы, длядальнейшегоисследованиямоделирования отбираютолькосятебизнес-прецеденты, которыесвязаныиспользованиемклинических записей.

Выполнениепр цедентаописываетсяпомощьюдиаграммвидовдеятельности, которые отображаютисполнителейпоследовательностьвыполнениясоответствующихбизнеспроцессов( рис. 12.4 ).

Рис. 12.4. Диаграммавидовдеятельностидляпрецедента"Оказанием дицинскпомощий"

Несмотрянато, чтооказанием дицинскпомощийпредусматриваетмножество разнообразныхдействисполнителей, длянашейзадачисущественнымиявляютсятолько процессыобменаинформацимеждуйэтимисполнителями, именноониотображаютсяв создаваемыходелях. Поэтомунадиаграммеотраженпроцессоценкисостоянияпациента основанииимеющейсявцентреинформациинем.

Общееполедиаграммыдеятельностиделитсянанесколько"

плавательных дорожек ",каждая

изкоторыхсодержитописаниедействийодногоизисполнителей. Основнымиэлементами диаграммвидовдеятельностиявляютсяобозначениясостояния(" начало ", " конец "), действия(овал)имоментасинхронизациидействий(линейкасинхронизации, накоторой сходятсяилиразветвляютнесяколькострелок).

Диаграммаподходитдляописаниядействийкаквнешнего, такивнутреннегоспециалиста центра.

Этапзавершаетсяпослеразработкидиаграммвидовдеятельностидлявсехвыделенных моделибизнес-прецедентов . Естественно, напоследующихэтапаханализапроектирования будутвыявленыкакие-товажныеподробностивописаниидеятельностиобъекта автоматизации. Поэтомуразработанныенаданномэтапемоделибудутещенеоднократно корректироваться.

Разработкамоделибизнес-объектов

СледующимэтапомпроектированияИСявляетсяразработка					моделибизнес-объектов	, которая
показываетвыполненбизнес-процессоворганизацииеевнутреннисполнителями.
Основнымикомпонентами		моделейбизнес-объектов			являютсявнешнивнутренние
исполнители, атакжебизнес-сущности, отображающиевсе, чтоиспользуютвнутренние
исполнитедляреализацбиизнес-процессов. Пример					моделибизнес-объектов	для
прецедента"	Ответ на запрос "приведенна		рис. 12.5 .

Рис. 12.5. Модельбизнес-объектовпрецедента"Ответназапрос"

Вэтойдиаграммепоявилосьновоедействующеелицо–отправительзапроса. Насамомделес запрососостояниимпациентамогутобращатьвсистеямногиеуиздействующихлиц: юрист, страховаякомпания, техническийперсоналидажесампациент. Такимобразом, понятие" Отправитель запроса "служитдляобобщенногопредставлениявсехэтих

действующихлицприописаниипрецедента"

Ответ на запрос " (рис. 12.6 ). " Отправитель

запроса "становитсясуперкласспоотношениюмкобобщаемымпонятиям(подклассам).

Рис. 12.6. Обобщениеклассов

Длядетальногописаниявыполненбизнеся-процессовобычноиспользуютсядиаграммы последовательностей( рис. 12.7 ).

Рис. 12.7. Диаграммапоследовательностейдляпрецедента"Ответназапрос"

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

Результатомэтогоэтапаявляютсясогласованныезаказчикомдостаточноподробные описаниядействийспециалистоворганизации, внедряющейИС, необходимыедляобеспечения исполненияеефункций.

Разработкаконцептуальноймоделиданных

Затемнаосновеинформации, выявленнойаэтапахбизнес-моделирования, выполняется

разработка концептуальноймоделиданных				, которыебудутиспользоваться
разрабатываемойсистеме. На	рис. 12.8 представленавидедиаграммыклассовмодель
данныхдляобъекта"
	Клинические записи ".

Рис. 12.8. Концептуальнаямодельданных

Модельпоказывает, чтоклиническиезаписивключают(агрегируют)рядблоков. Приэтом"

минимальный набор данных "и " план лечения "могутбытьвключеныкаждуюклиническую записьвединственномэкземпляре, аблоки" результаты анализов ", " предписания врача ", " ход лечения "могутповторятьсянеограниченноечислораз.

Архивсостоитзмножестваклиническихзаписей(агрегируетклиническиезаписи),номожет

бытьипустым.

Посколькупациентможетпредварительнопроходитьлечениевдругихучрежден,ияхли несколькоразпроходитьлечениевцентре, появляютсядополнительныеразновидности (подклассы)клиническихзаписей:внешние, старыевнутренние, новыевнутренние.

Этотэтапзавершаетпроцедурыбизнес-моделированияпозволяетпредставитькоманде проектировщиковединомформатуеинформацию, котораябудетнеобходимадлясоздания системы. Разработанныедиаграммыявляютсяотправнточкойвпроцессахпроектирования базданныхиприложенсистемый, обеспечиваютсогласованностьдействийбизнесаналитиковразработчиковпроцесседальнейшейработынадсистемой. Этидиаграммы, конечноже, будутпретерпеватьизменениявпроцессепоследующегопроектирования, однако этиизменениябудутфиксироватьсяформате, ужепривычномдлявсейкоманды разработчиков, будутавтоматическиотражатьсявпоследующихмоделях.

Разработребованийкаксистеме

Наэтапеформированиятребований, преждевсего, необходимоопределитьобластьдействия разрабатываемойсистемыполучитьточноепредставлениеожелаемыхвозможностях системы.

Основойразработкиребованийявляется	модельсистемныхпрецедентов		, отражающая
выполнениеконкретныхобязанностейвнутреннивнешнимиисполнителями
использованиемИС.
Источникомданныхдлясоздания	моделисистемныхпрецедентов	являютсяразработанныена
предыдущемэтапебизнес-модели. Однакоприсозданиимоделиполезнопредварительно
составитьдетальныеописанияпрецедент, совдержащиеопределенияиспользуемыхданныхи
точнуюпоследовательностьихвыполнения. Описаниеосуществляетсясоответствии
принятымворганизациишаблоном, которыйобычновключаетследующиеразделы:
• заголовок( название прецедента, ответственныйза исполнение, дата			создания шаблона/
внесенизмененийя);

•краткое описание прецедента;

•ограничения;

• предусловия( необходимоесостояние системы или условия, при которых должен выполнятьсяпрецедент);

•постусловия(возможныесостояниясистемыпослевыполненияпрецедента);

•предположения;

•основная последовательностьдействий;

• альтернативныепоследовательностидействий и

условия,

их инициирующие;

• точки

расширенияи включения прецедентов.

Впроцессесоздания

моделисистемныхпрецедентов

осуществляетсяпреобразование

переноскомпонентовбизнес-моделейнановыедиаграммы. Типовыепреобразованияпо

технологииRational Unified приведеныProcess

таблиц12.1а

.

Таблица12.1.

Элементыбизнес-модели

Элементы моделис стемных

прецедентов

Бизнес-прецеденты

Подсистемы

Внешнисполнители

Исполнители

Внутренниеисполнители

Исполнителипрецеденты

Процессы, в полняемыевнутренними

Прецеденты

исполнителями

На рис. 12.9

представлена модельсистемныхпрецедентов

длябизнес-прецедента"

Оказание

медицинской помощи ".Исходяизцелисозданиясистемы, в моделисистемныхпрецедентов

отраженытолькотедействисполнителейя, которыесвязаныпредоставлениемдоступаи обновлениемклиническихзаписей.

Рис. 12.9. Модельсистемныхпрецедентов

Описываемодельюыефункциихарактернытолькодляодноговидадеятельности–оказания медицинскпомощий, восновномнеиспользуютсявдругихвидахдеятельностиЦентра. Это позволяетобъединитьвыделенныефункциивнекуюединуюподсистемупроектируемойИС.

Внутреннийисполнитель"	Персонал центра " см( .	рис. 12.4 , рис. 12.7 )ивыполняемыйим
ручнойпроцесспреобразовансистемныйпрецедент"						доступа к
				Предоставление
клиническим записям ".

Внешнисполнители(например, " Производитель медицинского оборудования ")

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

Вмоделиотраженыдваспециальныхтипасвязимеждупрецедентами(на рис. 12.9 соответствующиепрецедентывыделенытенью):

•" включает " —одинпрецедентвпроцессесвоегоисполненияоб зательновыполняет некийблокдействий, составляющихдругойпрецедент;

•" расширяет " —когдапрецедентыподобнысвоимдействиям, ноодинесетнесколько большуюфункциональнуюнагрузку.

Прецедент" Проверка прав доступа "впервыепоявилсянадиаграммахреализуется средствамиразрабатываемойИС. Поэтомудлянегоприходитсяразрабатыватьдиаграмму

последовательностей, описывающуюегоисполнение(		рис. 12.10 ).Врезультатев
проектируемойИСпоявляютсядвановыхобъекта–программныймодуль"				Менеджер защиты "
иинформационныйблок"	Набор прав ".

Рис. 12.10. Диаграммапоследовательностейдляпрецедента"Проверкаправ"

Такимобразом, результатомразработки моделисистемныхпрецедентов являетсянетолько исчерпывающийпереченьфункций, которыедолжныбытьреализованыпроектируемой системе, ноиподробноеописаниеобходимойреализацииэт хфункций.

Анализтребованийпредварительноепроектированиесистемы.

Основныезадачиэтапа:

•	определитьпроект	системы, который будет отвечать всем бизнестребованиям;
•	разработатьобщий	предварительныйпроект для всех команд разработчиков
	(проектировщиковбазданных, разработчиковприложен, системныхйархитекторов
	пр.)

Основныминструментомнаданномэтапеявляютсядиаграммыклассовсистемы, которые строятсянаосноверазработанной моделис стемныхпрецедентов . Одновременнонаэтом этапеуточняютсядиаграммыпоследовательностейвыполненияотдельныхпрецедентов, что приводиткизменениямвсоставеобъектовидиаграммахклассов. Этоестественноеотражение средствамиUMLитеративногопроцессазработкисистемы.

Диаграммыклассовсистемызаполняютсяобъектамииз	моделисистемныхпрецедентов	. Они
содержатописаниеэтихобъектовидеклассовиописаниевзаимодействиямеждуклассами.
Диаграммаклассов, описывающаяпроцедурызащитыдоступакданным, приведена		рис.
12.11.

Рис. 12.11. Диаграммаклассов"Защитадоступа"

Такимобразом, врезультаэтогоеэтапапроектированияпоявляетсядостаточноподробное описаниесоставаифункцийпроектируемойсистемы, атакжеинформации, которую необходимоспользоватьбазеданныхивприложениях.

Посколькудиаграммыклассовстроятсянаосноверазработанныхранеебизнес-моделей, появляетсяуверенностьтом, чторазрабатываемаясистемабудетдействительно удовлетворятьисходнымтребованиямзаказчика.

Втожевремя, благодарясвоемусинтаксису, диаграммыклассоказываютсяхорошим средствомструктурированияпредставлениятребованийкфункциональности, интерфейсам даннымдляэлементовпроектируемойсистемы.

Разработкамоделейбазыданныхиприложений

Наэтомэтапеосуществляетсяотображениеэлементовполученныхранеемоделейклассов элементымоделейбазыданныхиприложений:

•классыотображаювтсяаблицы;
•	атрибуты– в		столбцы;
•	типы – в	типы данных используемойСУБД;
•	ассоциации–	в	связи между таблицами( ассоциации" многиеко -				многим" преобразую
	ассоциации"один-ко-многим"посредствозданиямдополнительныхтаблицсвязей);
•	приложения–	в	отдельные классы с	окончательноопределенными			связаннымис
	даннымивбаземетодамиатрибутами.
Посколькумоделибазыданныхиприложенийстроятсянаосновеединойлогическоймодели,
автоматическиобеспечиваетсясвязностьэтихпроектов(				рис. 12.12 ).

Рис. 12.12. Связьмеждупроектамибазыданныхиприложений
Вмодельбазыданныхотображаютсятолькоперманентныеклассы, изкоторыхудаляются		Общий объем продаж ",
атрибуты, неотображаемыевстолбцах(например, атрибуттипа"
которыйполучаетсясуммированиемсодержимогомн жестваполейбазыданных).Некоторые		СТРАНА, ГОРОД,
атрибуты(например,	АДРЕС )могутотображатьсявмножестволбцов(

УЛИЦА, ДОМ, ПОЧТОВЫЙ ИНДЕКС ).

Длякаждогопростогоклассавмоделибазыданныхформируетсяотдельнтаблицая, включающаястолбцы, соответствующатрибутамекласса.

Отображениеклассовподтиповтаблицыосуществляетсяоднимизстандартныхспособов: