ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 03.08.2024
Просмотров: 44
Скачиваний: 0
медицинской помощи ".Исходяизцелисозданиясистемы, в моделисистемныхпрецедентов
отраженытолькотедействисполнителейя, которыесвязаныпредоставлениемдоступаи обновлениемклиническихзаписей.
Рис. 12.9. Модельсистемныхпрецедентов
Описываемодельюыефункциихарактернытолькодляодноговидадеятельности–оказания медицинскпомощий, восновномнеиспользуютсявдругихвидахдеятельностиЦентра. Это позволяетобъединитьвыделенныефункциивнекуюединуюподсистемупроектируемойИС.
Внутреннийисполнитель" |
Персонал центра " см( . |
рис. 12.4 , рис. 12.7 )ивыполняемыйим |
||||
ручнойпроцесспреобразовансистемныйпрецедент" |
|
|
|
|
доступа к |
|
|
|
Предоставление |
||||
клиническим записям ". |
|
|
|
|
|
|
Внешнисполнители(например, " Производитель медицинского оборудования ")
непосредственновзаимодействуютпроектируемойсистемой, . . превращаются исполнителей.
Вмоделиотраженыдваспециальныхтипасвязимеждупрецедентами(на рис. 12.9 соответствующиепрецедентывыделенытенью):
•" включает " —одинпрецедентвпроцессесвоегоисполненияоб зательновыполняет некийблокдействий, составляющихдругойпрецедент;
•" расширяет " —когдапрецедентыподобнысвоимдействиям, ноодинесетнесколько большуюфункциональнуюнагрузку.
Прецедент" Проверка прав доступа "впервыепоявилсянадиаграммахреализуется средствамиразрабатываемойИС. Поэтомудлянегоприходитсяразрабатыватьдиаграмму
последовательностей, описывающуюегоисполнение( |
рис. 12.10 ).Врезультатев |
|||
проектируемойИСпоявляютсядвановыхобъекта–программныймодуль" |
|
|
Менеджер защиты " |
|
иинформационныйблок" |
Набор прав ". |
|
|
|
Рис. 12.10. Диаграммапоследовательностейдляпрецедента"Проверкаправ"
Такимобразом, результатомразработки моделисистемныхпрецедентов являетсянетолько исчерпывающийпереченьфункций, которыедолжныбытьреализованыпроектируемой системе, ноиподробноеописаниеобходимойреализацииэт хфункций.
Анализтребованийпредварительноепроектированиесистемы.
Основныезадачиэтапа:
• |
определитьпроект |
системы, который будет отвечать всем бизнестребованиям; |
• |
разработатьобщий |
предварительныйпроект для всех команд разработчиков |
|
(проектировщиковбазданных, разработчиковприложен, системныхйархитекторов |
|
|
пр.) |
|
Основныминструментомнаданномэтапеявляютсядиаграммыклассовсистемы, которые строятсянаосноверазработанной моделис стемныхпрецедентов . Одновременнонаэтом этапеуточняютсядиаграммыпоследовательностейвыполненияотдельныхпрецедентов, что приводиткизменениямвсоставеобъектовидиаграммахклассов. Этоестественноеотражение средствамиUMLитеративногопроцессазработкисистемы.
Диаграммыклассовсистемызаполняютсяобъектамииз |
моделисистемныхпрецедентов |
. Они |
содержатописаниеэтихобъектовидеклассовиописаниевзаимодействиямеждуклассами. |
|
|
Диаграммаклассов, описывающаяпроцедурызащитыдоступакданным, приведена |
рис. |
|
12.11. |
|
|
Рис. 12.11. Диаграммаклассов"Защитадоступа"
Такимобразом, врезультаэтогоеэтапапроектированияпоявляетсядостаточноподробное описаниесоставаифункцийпроектируемойсистемы, атакжеинформации, которую необходимоспользоватьбазеданныхивприложениях.
Посколькудиаграммыклассовстроятсянаосноверазработанныхранеебизнес-моделей, появляетсяуверенностьтом, чторазрабатываемаясистемабудетдействительно удовлетворятьисходнымтребованиямзаказчика.
Втожевремя, благодарясвоемусинтаксису, диаграммыклассоказываютсяхорошим средствомструктурированияпредставлениятребованийкфункциональности, интерфейсам даннымдляэлементовпроектируемойсистемы.
Разработкамоделейбазыданныхиприложений
Наэтомэтапеосуществляетсяотображениеэлементовполученныхранеемоделейклассов элементымоделейбазыданныхиприложений:
•классыотображаювтсяаблицы; |
|
|
|
|
|||
• |
атрибуты– в |
|
столбцы; |
|
|
|
|
• |
типы – в |
типы данных используемойСУБД; |
|
||||
• |
ассоциации– |
в |
связи между таблицами( ассоциации" многиеко - |
многим" преобразую |
|||
|
ассоциации"один-ко-многим"посредствозданиямдополнительныхтаблицсвязей); |
|
|||||
• |
приложения– |
в |
отдельные классы с |
окончательноопределенными |
связаннымис |
||
|
даннымивбаземетодамиатрибутами. |
|
|
|
|
||
Посколькумоделибазыданныхиприложенийстроятсянаосновеединойлогическоймодели, |
|
||||||
автоматическиобеспечиваетсясвязностьэтихпроектов( |
рис. 12.12 ). |
|
|||||
|
|
|
|
|
|
|
|
Рис. 12.12. Связьмеждупроектамибазыданныхиприложений |
|
|
Вмодельбазыданныхотображаютсятолькоперманентныеклассы, изкоторыхудаляются |
Общий объем продаж ", |
|
атрибуты, неотображаемыевстолбцах(например, атрибуттипа" |
||
которыйполучаетсясуммированиемсодержимогомн жестваполейбазыданных).Некоторые |
СТРАНА, ГОРОД, |
|
атрибуты(например, |
АДРЕС )могутотображатьсявмножестволбцов( |
|
УЛИЦА, ДОМ, ПОЧТОВЫЙ ИНДЕКС ).
Длякаждогопростогоклассавмоделибазыданныхформируетсяотдельнтаблицая, включающаястолбцы, соответствующатрибутамекласса.
Отображениеклассовподтиповтаблицыосуществляетсяоднимизстандартныхспособов:
• |
одна |
таблица |
на |
класс; |
• |
одна |
таблица |
на |
суперкласс; |
• |
одна |
таблица |
на |
иерархию. |
Впервомслучаедлякаждогоизклассовсоздаетсяотдельнтаблицая, междукоторымизатем устанавливаютсянеобходимыесвязи. Вовторомслучаесоздаетсятаблицадлясуперкласса, затемвкаждуютаблицуподклассоввключаютсястолбцыдлякаждогоизатрибутов суперкласса. Втретьем–создаетсяединаятаблица, содержащаяатрибутыкаксуперкласса, такивсехподклассов( рис. 12.13 ).Приэтомдлявыделенияисходныхтаблицподклассов результирующуютаблицудобавляетсяодинилиболеедополнительныхстолбцов(нарисунке показанкурсивом).
Рис. 12.13. Преобразованиеиерархиивтаблицу
Разработкапроектаб зыданныхосуществляетиспользованияспециальногомUMLпрофиля(Profile for DatabaseкоторыйDesign),включаетследующиеосновныекомпоненты диаграмм:
• |
таблица– набор |
записей |
базы |
данных |
по |
определенномуобъекту; |
|
|
|
|||||
•столбец–элементтаблицы, содержащийзначенияодногоизатрибутовтаблицы; |
|
|
|
|
|
|||||||||
• |
первичный ключ ( |
РК ) – |
атрибут, однозначноидентифицирующийстроку таблицы; |
|||||||||||
• |
внешний ключ (FK) –один |
|
или |
группа |
атрибутов одной |
таблицы, |
которые могут |
|||||||
|
использоватьсякакпервичныйключдругойтаблицы; |
|
|
|
|
|
|
|
||||||
• |
обязательнаясвязь – связь |
между |
двумя |
таблицами, |
при |
которой |
дочерняя таблица |
|||||||
|
существуеттольковместеродительской; |
|
|
|
|
|
|
|
|
|
||||
• |
необязательнаясвязь – связь |
между |
таблицами, при |
которой каждая из таблиц мож |
||||||||||
|
существоватьнезависимоотдругой; |
|
|
|
|
|
|
|
|
|
|
|||
• |
представление– виртуальнаятаблица, |
которая |
обладает всеми свойствами обычной |
|||||||||||
|
таблицы, нонехранитсяпостоянновбазеданных; |
|
|
|
|
|
|
|
||||||
• |
хранимая процедура– функция обработки данных, выполняемаяна сервере; |
|||||||||||||
•домен–множестводопустимыхзначенийдлястолбцаблицы. |
|
|
|
|
|
|
|
|||||||
На рис. 12.14 представленфрагментмоделибазыданных—дветаблицы, соответствующие |
|
|
|
|||||||||||
|
|
|
, рис. 12.6 |
)и " минимальный набор данных " (рис. 12.8 ).Связь |
||||||||||
классам" пациент " (рис. 12.3 |
||||||||||||||
|
|
|
|
|
|
|
|
|||||||
междунимиобязательная, поскольку" |
|
|
минимальный набор данных "неможетсуществовать |
|||||||||||
без" |
пациента ". |
|
|
|
|
|
|
|
|
|
|
|
|
|
Рис. 12.14. Фрагментмоделибазыданных
Надиаграммахуказываютсядополнительныехарактеристаблицикистолбцов:
• |
ограничения– определяютдопустимыезначения данных в столбце или операции над |
|
данными(ключ(PK,FK)ограничение– , определяющеетипключаиегостолбец; |
|
проверка(Check)ограничение– , определяющееправилок нтроляданных;уникальность |
|
(Unique)ограничение– , определяющее, чтовстолбцесодержатсянеповторяющиеся |
|
данные); |
• |
триггер– программа, выполняющаяпри определенныхусловиях предписанныедействия |
сбазойданных;
•тип данных и пр .
Результатомэтапаявляетсядетальноеописаниепроектаб зыданныхиприложенсистемый.
Проектированиефизическойреализацсистемыи
Наэтомэтапепроектированиямоделибазданныхиприложенийдополняютсяобозначениями
ихразмещенияатехническихсредствахразрабатываемойсистемы. На |
рис. 12.15 приведено |
|||
изображениеразделениятаблицы" |
пациент "натриэкстента( |
|
|
|
<<Tablespace>> )в |
|
|||
соответствиипервойбуквойфамилиипациента.
Рис. 12.15. Экстентаблицы"Пациент"
ОсновнымипонятиямиUML,которыеиспользуютсянаданномэтапе, являютсяследующие:
• |
компонент– самостоятельныйфизическиймодуль системы; |
|||
• |
зависимость– связь |
между |
двумя элементами, при которой изменения в одном элем |
|
|
вызываютизменениядругогоэлемента; |
|||
• |
устройство– |
узел , |
не обрабатывающийданные; |
|
• |
процессор– |
узел , |
выполняющийобработку данных; |
|
• |
соединение– |
связь |
между |
устройствамии процессорами. |
Диаграммыразвертыванияпозволяютотобразитьнаединойсхемеразличныекомпоненты системы(программныеиинформационные) ихраспределениепокомплексутехнических средств( рис. 12.16 ).
Рис. 12.16. ФрагментдиаграммыразвертыванияИС
Такимобразом, припроектированиисложнойИСонаразделяетсяначасти, каждаяизних затемисследуетсоздаетсяотдельно. Внастоящеевремяиспользуютсядваразличных способат когоразбиенияИСнаподсистемы:структурное(илифункциональное)разбиение объектная(компонентная)декомпозиция.
СпозицийпроектированияИСсутьфункциональногоразбиенияможетбытьвыражена известнойформулой: " Программа = Данные + Алгоритмы ".Прифункциональной декомпозициипрограммнойсистемыееструктураописываетсяблок-схемами, узлыкоторых представляютсобой"обрабатывающиецентры" (функции),асвязимеждуузламиописывают движениеданных.
Приобъектномразбиениивсистемевыделяются"активныесущности" –объекты(или компоненты),которыевзаимодействуютдругдругом, обмениваясьсообщениямивыполняя соответствующиефункции(методы)объекта.
ЕслиприпроектированииИСразбиваетсянаобъекты, тодляеевизуальногомоделирования следуетиспользоватьUMLЕсли. восновупроектированияположенафункциональная декомпозицияИС, тоUMLненужениследуетиспользоватьрассмотренныеран структурные нотации.
Втожевремя, привыбореподходакразработкеИСследуетучитывать, чтовизуальные