Разработка программной системы

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

Нотация — важная составляющая любой модели, своего рода связующее звено между процессами. Унифицированный язык моделирования (UML — Unified Model Language) предлагает достаточно полную нотацию, которая расширяется при переходе от анализа к проектированию.

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

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

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

Рассмотрим разработку модели информационной системы средствами языка UML на примере разработки информационно-справочной системы «Аптека».

Объектом исследования является информационно-справочная система «Аптека».

Предмет данной курсовой работы — автоматизация аптечного бизнеса.

Цели и задачи работы — обработка информации, исходящей от аптек. Создание модели системы «Аптека» средствами языка моделирования UML, с дальнейшей её реализацией в Delphi.

1. Описание предметной области системы «Аптека»

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

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

При разработке словаря системы необходимо определить имена сущностей («лекарства», «фармацевт»). При этом термин сущность понимается нами как компонент модели предметной области, то есть как уже выделенный на концептуальном уровне объект. Выделяемые в предметной области объекты превращаются аналитиком в сущности.

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

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

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

Итак, ставится задача разработать информационно-справочной систему «Аптека», которая позволяла бы вести автоматизированный учёт данных о лекарствах, обеспечивала гибкие возможности при решении запланированных и незапланированных специфических задач обработки учетных данных.

В рамках решения задачи разработки информационно-справочной системы «Аптека» выделим следующие сущности:

фармацевт — фармацевт аптеки;

врач — врач поликлиники;

лекарства — происходит поиск лекарств, а также, учет данных фармацевтом;

врач выписывает рецепты пациенту, следовательно ещё одной сущностью будет рецепт.

Веденные сущности имеют ряд атрибутов, которые мы определим в дальнейшем.

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

С учетом введенных терминов разрабатываемая система должна обеспечивать:

— организацию полного и достоверного учета всех лекарств;

— организацию выписки рецепта;

— автоматизированный расчет потребности в товарах на основе анализа скоростей продаж;

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

— информационную поддержку принимаемых управленческих решений, формирование полной и достоверной информации о лекарствах;

— сокращение трудозатрат на подготовку первичных документов и отчетов;

— устранение дублирования при вводе информации и, возникающих при этом механических ошибок;

— удобный интерфейс пользователю;

— разграничение полномочий рядовых пользователей и администратора.

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

2. Разработка модели программной системы «Аптека» средствами UML

Язык UML является языком специфицирования и визуализации, основными единицами его являются диаграммы.

Диаграмма в UML — это графическое представление набора элементов, изображаемое чаще всего в виде связанного графа с вершинами (сущностями) и ребрами (отношениями). Диаграммы характеризуют систему с разных точек зрения. Диаграмма — в некотором смысле одна из проекций системы. Как правило, диаграммы дают свернутое представление элементов, из которых составлена система. Один и тот же элемент может присутствовать во всех диаграммах, или только в нескольких (самый распространенный вариант), или не присутствовать ни в одной (очень редко). Теоретически диаграммы могут содержать любые комбинации сущностей и отношений. На практике, однако, применяется сравнительно небольшое количество типовых комбинаций, соответствующих пяти наиболее употребительным видам, которые составляют архитектуру программной системы. Таким образом, в UML выделяют девять типов диаграмм:

— диаграммы классов

— диаграммы объектов;

— диаграммы прецедентов;

— диаграммы последовательностей;

— диаграммы кооперации;

— диаграммы состояний;

— диаграммы действий (деятельности);

— диаграммы компонентов;

— диаграммы развертывания.

Концептуальная модель UML

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

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

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

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

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

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

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

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

Здесь приведен неполный список диаграмм, применяемых в UML. Инструментальные средства позволяют генерировать и другие диаграммы, например, такие как диаграммы профиля баз данных, диаграммы WEB-приложений и т. д.

Разработка вида с точки зрения прецедентов

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

Прецедент (Use case) — это описание последовательности выполняемых системой действий, которая производит наблюдаемый результат, значимый для какого-то определенного актера (Actor). Прецедент применяется для структурирования поведенческих сущностей модели. Прецедент только декларирует описание какого-либо действия системы, отвечая на вопрос «что делать?», но не указывает какими средствами. Конкретная реализация специфицируемого прецедентом поведения обеспечивается классом, кооперацией классов или компонентом.

Актер представляет собой связное множество ролей, которые пользователи прецедентов исполняют во время взаимодействия с ними. Обычно актер представляет роль, которую в данной системе играет человек, аппаратное устройство или даже другая система. В разрабатываемой системе «Аптека» актерами являются фармацевт и врач.

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

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

Возвращаясь к моделированию информационно-справочной системы «Аптека», выделим прецеденты:

Редактирование данных,

Поиск лекарства,

Учет заказов,

Формирование отчетов,

Выдача рецепта,

Авторизация.

Элементы диаграммы прецедентов (прецеденты и актеры) должны быть связаны отношениями.

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

Кроме того, между прецедентами в языке UML определены две специфические зависимости — отношение включения и отношение расширения.

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

Отношения включения изображаются в виде зависимостей со стереотипом «include». Чтобы специфицировать место в потоке событий, где базовый прецедент включает поведение другого, вы просто пишете слово include, за которым следует имя включаемого прецедента.

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

Отношение расширения изображают в виде зависимости со стереотипом «extend». Точки расширения базового сценария перечисляются в дополнительном разделе. Они являются просто метками, которые могут появляться в потоке базового прецедента.

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

В нашем случае, прецедент редактирование данных включает в себя прецеденты: ввод данных, удаление данных, изменение данных.

Диаграмма прецедентов информационно-справочной системы «Аптека» показана на рис. 1.

Прецедент поиск лекарства предполагает поиск по группе и поиск по названию.

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

Рис. 1. Диаграмма прецедентов информационно-справочной системы «Аптека»

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

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

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

Основной поток событий. Прецедент начинается, когда система запрашивает у пользователя его входное имя (Login) и пароль (Password). Пользователь может ввести его с клавиатуры. Завершается ввод нажатием клавиши Enter. После этого система проверяет введенные Login и пароль, и если они соответствуют администратору, подтверждает полномочия администратора. На этом прецедент заканчивается.

Исключительный поток событий. Клиент может прекратить транзакцию в любой момент, нажав клавишу Cancel. Это действие начинает прецедент заново. Ввод в систему не производится.

Рис. 2. Авторизация пользователя. Диаграмма деятельности

Исключительный поток событий. Клиент может в любой момент до нажатия клавиши Enter стереть свои Login и пароль.

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

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

Диаграмма алгоритма должна содержать начальную и конечную вершины, причем, только одну начальную, и одну конечную. Диаграмма содержит исполняемые вершины — деятельности (обозначаются скругленными прямоугольниками), условные вершины (decision — выбор, распознавание, обозначаются ромбиками) и связи.

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

Разработка вида с точки зрения проектирования

Вид с точки зрения проектирования является основным этапом концептуальной проработки модели. На данном этапе вводятся основные абстракции, определяются классы, и интерфейсы посредством которых реализуется решение поставленных задач. Если прецеденты только декларируют поведение системы, то на этапе разработки вида с точки зрения проектирования определяется какими средствами данные прецеденты будут реализованы. Статические аспекты данного вида разрабатываются посредством диаграммы классов, динамические — посредством диаграмм взаимодействий и состояний (автомат).

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

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

— является четко очерченной абстракцией некоторого понятия из словаря проблемной области или области решения;

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

— поддерживает четкое разделение спецификаций абстракции и ее реализации;

— понятен и прост, но в то же время допускает расширение и адаптацию к новым задачам.

В рамках разработки модели «Аптека» определим классы: врач, фармацевт, лекарства, рецепт. Очевидно, что первые из них имеют много общих атрибутов, поэтому введем абстрактный класс персона, который будет инкапсулировать все свойства, относящиеся к человеку в контексте разрабатываемой системы (фамилия, имя, отчество, телефон, адрес). В данном случае персона будет суперклассом, и связываться отношением обобщения с классами врач, фармацевт.

Атрибут адрес имеет собственную структуру, чтобы отразить ее можно ввести дополнительный класс, назовем его Т_Адрес (как принято во многих системах программирования названия классов начинать с буквы T). Следует иметь ввиду что, атрибут адрес класса персона является экземпляром класса Т_Адрес, то есть между этими классами устанавливается отношение зависимости (отображается пунктирной стрелкой с открытым наконечником, стрелка направлена от зависимого элемента к независимому). В нашем случае изменение структуры класса Т_Адрес влечет за собой изменение класса персона через структуру соответствующего атрибута (адрес).

При моделировании класса Т_Адрес атрибут индекс зададим посредством примитивного типа T_POSTIDX, определяемого как шестизначное десятичное число. Примитивные типы моделируются стереотипом «type», диапазон значений указывается через ограничения, заключенные в фигурные скобки.

В классе лекарства выделим специфические атрибуты, относящиеся только к лекарству: дата поступления, цена (лекарства), единицы измерения, имеющееся количество, срок годности. Атрибут единицы измерения лучше определить специализированным типом через перечисление. Перечисления моделируются классом со стереотипом «enum» (enumeration — перечисление), допустимые значения записываются как атрибуты, метки, определяющие видимость атрибутов при этом подавляются. В рассматриваемом примере через перечисление введем специализированный класс Т_ЕдИзм, определяющий возможные единицы измерения через перечисления. В данном случае, как и везде в подобных случаях при создании классов, специфицирующих атрибуты основного класса, устанавливаются отношения зависимости.

Учитывая, что и лекарства и рецепт имеют общие атрибуты можно ввести дополнительный абстрактный класс, например, медикаменты, являющийся суперклассом для классов лекарства и рецепт, что позволит несколько сократить число связей. Класс медикаменты имеет атрибуты: наименование, группа. Атрибут группа посредством введенного через перечисление специализированного типа Т_Группа определяет к какой группе относится лекарство: к жаропонижающим, желчегонным, против гриппа или антибиотикам.

Для класса рецепт вводится специфический атрибут дата, поликлиника (номер поликлиники), срок хранения рецепта, режим приёма (лекарства).

Класс фармацевт имеет атрибут квалификация. Класс врач имеет атрибут специальность.

При визуализации структуры классов следует обращать внимание на видимость атрибутов. Все рассмотренные атрибуты должны быть доступны и иметь видимость Public (обозначается знаком «+» или пиктограммой без замка). В рассмотренных классах мы делали упор на структуру, а не на поведение (операции не описывались и не предполагается их описывать), поэтому для облегчения восприятия диаграммы желательно изображение операций подавить.

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

Множественность отношения фармацевт — лекарства «многие к одному». Каждое лекарство относится к определенному фармацевту, в свою очередь определенному фармацевту может соответствовать несколько лекарств, поэтому ассоциация фармацевт — лекарства имеет тип множественности «многие к одному». На данной ассоциации со стороны фармацевта можно указать роль: учёт данных (т.е. формирование отчётов, редактирование данных и т. д.).

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

Аналогично введём ассоциацию между врачом и лекарством: тип множественности ассоциации «многие к одному».

Диаграмма классов приводится на рис. 3.

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

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

Перейдем к определению интерфейсов. Классы взаимодействуют с внешним миром через интерфейсы.

Интерфейс (Interface) — это совокупность операций, которые определяют сервис (набор услуг), предоставляемый классом или компонентом. Таким образом, интерфейс описывает видимое извне поведение элемента. Интерфейс может представлять поведение класса или компонента полностью или частично; он определяет только спецификации операций (сигнатуры), но никогда — их реализации. Графически интерфейс изображается в виде круга, под которым пишется его имя. Интерфейс редко существует сам по себе — обычно он присоединяется к реализующему его классу или компоненту. Интерфейс всегда предполагает наличие некоторого «контракта» между стороной, которая декларирует выполнение ряда операций и стороной, которая эти операции реализует.

Рис. 4. Упрощенная диаграмма классов Поместим на диаграмму класс электронная таблица, в котором инкапсулированы все свойства и операции электронной таблицы, позволяющей редактировать данные. Структуру данного класса раскрывать ввиду большой сложности не будем. Так в современных средствах разработки приложений пользователь пользуется готовыми классами и шаблонами, наследуя их возможности, например библиотека VCL (Delphi) содержит класс TTable, инкапсулирующий возможности электронной таблицы. Потомки класса электронная таблица являются конкретными электронными таблицами, содержащие конкретные данные по лекарствам, рецепту (выписанному рецепту), фармацевту, врачу. Делая соответствующие классы потомками класса электронная таблица, мы декларируем для этих классов все свойства и операции, присущие электронным таблицам (регистрацию в системе, вставку, удаление, редактирование данных, сортировку и т. д.).

Для класса электронная таблица, а соответственно и для всех его потомков определим интерфейс редактирование, подразумевая все возможные операции редактирования данных (вставку, удаление, изменение данных). Также для этого класса определим интерфейс менеджер отчётов, содержащий операции: формирование отчетов за день, учет заказов и т. д. При этом предполагается, что в классе электронная таблица данные возможности реализованы.

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

Отобразим интерфейс поиск лекарства с указанием списка операций. Отношение реализации отображается пунктирной стрелкой с закрытым наконечником.

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

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

Для управления правами доступа и авторизацией пользователя введем класс менеджер доступа. Менеджер доступа имеет атрибут закрытого типа доступа таблица паролей, который является экземпляром класса КодирТабл (Кодированная таблица), содержащей пароли (password) и входные имена (login) пользователей-администраторов. Предполагается, что возможности служебного класса КодирТабл не позволяют постороннему пользователю считывать пароли пользователей. На данном этапе проектирования мы просто декларируем такие возможности, не останавливаясь на механизме их реализации, но предполагая, что таковые инкапсулированы в класс КодирТабл.

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

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

Итоговая диаграмма приводится на рис. 5.

Итак, разработка модели системы «Аптека» средствами диаграммы классов UML на данном этапе можно считать законченной. Естественно, возможны возвращения к ней и пересмотр некоторых элементов в ходе проектирования системы, при корректировке задач, при уточнении отдельных деталей. Процесс проектирования информационных систем является итеративным. Необходимо отметить, что разработанная диаграмма классов содержит элементы явно или скрыто реализующие все прецеденты использования диаграммы прецедентов. Каждому прецеденту диаграммы прецедентов должен соответствовать либо интерфейс, либо операция интерфейса (реализация предполагается в соответствующих интерфейсу классах), либо открытая операция класса, либо набор открытых операций (в данном случае прецедент реализуется непосредственно соответствующим классом или набором классов).

Рассмотрим процесс создания новой записи о лекарстве средствами диаграммы последовательности.

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

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

Ведем объекты: форма ввода, менеджер записей, запись о лекарстве Ampilicilin (как конкретный пример записи о лекарстве), менеджер транзакций. Данный набор объектов является типовым при модификации записи в таблице базы данных.

Форма ввода — элемент пользовательского интерфейса, представляет собой типовую форму ввода данных о лекарстве (название, группа, дата поступления и т. д.). В нашем случае представляет собой несколько доопределенную конкретную реализацию стандартного интерфейса редактирование класса электронная таблица. Поскольку специально интерфейс редактирование данных о лекарстве нами не вводился на диаграмме классов, поэтому явно указывать класс для объекта форма ввода не будем.

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

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

Менеджер транзакций — объект, обеспечивающий выполнение законченной операции над базой данных, в данном случае создание новой записи о лекарстве Ampilicilin. На данный объект возлагается выполнение также ряда системных функций, сопровождающих транзакцию. Примером менеджеров транзакций являются, например, BDE (используются для доступа из приложений Delphi к базам данных Paradox, Dbase и др.), ADO (используется для доступа к базам MS Access из различных приложений).

Диаграмма последовательности ввода новой записи о лекарстве в системе «Аптека» представлена на рис. 6.

На диаграмме последовательности определим передачу сообщений между объектами: создать новую запись (транслируется от объекта к объекту до конца цепочки как сообщение сохранить запись); открыть форму (к форме ввода); ввести название, группу, дату поступления. (ввод данных по лекарству), далее эти данные транслируются сообщениями сохранить название, группу, дату поступления… От менеджера транзакций передается сообщение собрать информацию о лекарстве, обеспечивающее обратную связь с базой данных, и наконец, рефлексивное сообщение менеджера транзакций поименованное как сохранить запись в БД, обеспечивает окончание транзакции.

Рис. 6. Ввод данных о лекарстве. Диаграмма последовательности информационный программный аптека При желании можно данное взаимодействие представить диаграммой кооперации, иллюстрирующей, прежде всего структурный аспект взаимодействия (рис. 7). Данную диаграмму можно построить из предыдущей в автоматическом режиме (в Rational Rose нажатием клавиши F5).

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

Рис. 7. Ввод данных о лекарстве. Диаграмма кооперации

Разработка профиля реляционной базы данных

В том случае если для реализации системы используется объектно-ориентированная СУБД (ООСУБД) построенная в предыдущем разделе диаграмма объектов является окончательной моделью и прямым руководством к реализации информационной системы. В том же случае, когда в качестве информационного ядра информационной системы предполагается использовать реляционную базу данных (РБД), необходимо разработать еще одну диаграмму, диаграмму профиля реляционной базы данных.

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

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

На профиле баз данных UML определяются следующие сущности:

Таблица (Table) — набор записей в базе данных по определенному объекту, состоит из столбцов.

Столбец (Column) — компонент таблицы, содержащий один из атрибутов таблицы (поле таблицы).

Первичный ключ (Primary key) — возможный ключ, выбранный для идентификации строк таблицы.

Внешний ключ (Foreign key) — один или несколько столбцов одной таблицы, являющиеся первичными ключами другой таблицы.

Представление (View) — виртуальная таблица, которая ведет себя с точки зрения пользователя точно также, как обычная таблица, но не существует самостоятельно.

Хранимая процедура (Stored procedure) — независимая процедурная функция, выполняемая на сервере.

Домены (Domains) — допустимый набор значений для атрибута или столбца.

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

На основе диаграммы классов модно создать профиль базы данных (диаграмма реляционных таблиц системы). При этом следует иметь ввиду, что объектно-ориентированная модель системы и профиль баз данных далеко не одно и то же. Реляционная модель не поддерживает наследования, имеет типы данных, соответствующие используемой СУБД, для обеспечения связей между таблицами используются специальные кодовые поля.

Остановимся на основных моментах в преобразовании объектно-ориентированной модели в реляционную:

1) основные классы, содержащие данные, предназначенные для хранения, преобразуются в таблицы;

2) при наличии ассоциаций типа «один к одному» хотя бы с одной стороны нужно добавить дополнительное кодовое поле, где указать код (ключ) второй записи для обеспечения связи данных;

2) при наличии ассоциаций типа «один ко многим» со стороны подчиненных записей (со стороны «многие») необходимо ввести дополнительное поле, где указать код (ключ) записи, которой они подчиняются (со стороны «один»);

3) при наличии ассоциаций типа «многие ко многим» необходимо ввести дополнительную таблицу связей, содержащую минимум два поля: код одного участника и код второго участника, таким образом ассоциация типа «многие ко многим» преобразуется в две ассоциации типа «один ко многим» через таблицу связи;

4) при наличии класса-ассоциации класс-ассоциация вводится как таблица связи, имеющая дополнительные атрибуты.

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

Если реляционная модель была построена на базе хорошо продуманной объектно-ориентрованной модели, полученная реляционная модель обычно не содержит аномалий обновления и удаления информации и удовлетворяет условиям нормализации. Однако полезно проверить полученную реляционную модель на соответствие нормальным формам.

На рис. 8. приводится диаграмма профиля данных для разрабатываемой информационной системы «Аптека». Структура базы данных соответствует третьей нормальной форме.

В соответствии разработанной объектно-ориентированной моделью определим таблицы на базе классов, соответствующих основным концептуальным сущностям информационной системы. Каждой соответствующей таблице дадим имя, начинающиеся на букву «Т» и включающие имя соответствующего класса, например, Т_Лекарства. Таблицы UML являются стереотипными классами со стереотипом «Table», вид пиктограммы может регулироваться опцией Stereotype Display.

Структура классов содержит классы с иерархическими связями наследования: персона, фармацевт, врач. В соответствии с рекомендациями разработки реляционного профиля при наличии наследования базовых классов необходимо либо транслировать все атрибуты предков в таблицы, соответствующие листовым классам иерархии наследования; либо вводить таблицы, соответствующие всем классам иерархии наследования с обеспечением связей между таблицами от потомка к предку. Мы изберем компромиссный вариант: класс медикаменты в отдельную таблицу преобразовывать не будем, соответствующие атрибуты транслируем в таблицы, соответствующие классам рецепт (Т_Рецепт) и лекарства (Т_Лекарства). Такой подход позволяет сэкономить внешнюю память, не прибегая к большому увеличению связей.

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

Для выполнения условия атомарности атрибутов, атрибуты класса Т_Адрес непосредственно транслируем в таблицы Т_Персона. Разбиение адреса на несколько атрибутов позволяет расширить возможности поиска и сортировки данных по адресу проживающих.

Для обеспечения связи по типу «один ко многим» между врачом и рецептом, а также, врачом и лекарствами в таблицы Т_Рецепт и Т_Лекарства для записи каждого врача указывается код врача.

Аналогично для связи между фармацевтом и лекарствами в таблице Т_Лекарства указывается код фармацевта.

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

Текстовые атрибуты типа String объектно-ориентированной модели преобразуются в поля типа CHAR с указанием длины в текстовых символах.

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

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

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

Используя UML, разработчик практически не зависит от организации процесса программирования; он не привязан к какому-либо конкретному циклу изготовления программного продукта. Тем не менее, разработчиками UML рекомендуется применять процесс, который:

— управляется прецедентами использования;

— основан на архитектуре;

— является итеративным и инкрементным.

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

Процесс называют основанным на архитектуре (Architecture-centric), когда системная архитектура является решающим фактором при разработке концепций, конструировании, управлении и развитии создаваемой системы.

Итеративным (Iterative) называется процесс, который предполагает управление потоком исполняемых версий системы. Инкрементный (Incremental) процесс подразумевает постоянное развитие системной архитектуры при выпуске новых версий, причем каждая следующая версия усовершенствована в сравнении с предыдущей. Процесс, являющийся одновременно итеративным и инкрементным, называется управляемым рисками (Risk-driven), поскольку при этом в каждой новой версии серьезное внимание уделяется выявлению факторов, представляющих наибольший риск для успешного завершения проекта, и сведению их до минимума.

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

3. Реализация информационной системы «Аптека»

Наиболее популярными средствами программирования на сегодняшний день являются Delphi, C++ Builder, Java-Builder, Visual Basic. Все они предоставляют развитые возможности по разработке программных продуктов, содержат мощные средства визуального программирования. При выполнении специфических задач работы с текстами, создания WEB-приложений могут быть использованы специализированные средства на основе языков PERL, PHP и др.

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

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

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

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

В Delphi существует много механизмов доступа к данным. Одной из распространенных технологий доступа к данным является разработанная Microsoft технология ADO (ActiveX Data Object).

На рисунке 9 изображено главное окно приложения информационно-справочной системы «Аптека», реализованная визуальными средствами Delphi.

Щелчок на кнопках Лекарства, Рецепт, Содержание приёма, приводят к появлению соответствующих рабочих форм (рис. 11). Данные форм реализуют интерфейс управления таблицами баз данных, содержащих информацию о медикаментах, врачах (выписывающих рецепты), дата (выписки рецепта) и т. д., для системы «Аптека». Для реализации данных табличных форм использовались следующие компоненты VCL: DBGrid и DBNavigator, которые с помощью компонентов ADOConnection, ADOTable и DataSourse были подключены к созданной в MS Access базе данных.

Щелчком на кнопке Help вызывается справочник по работе с приложением. Щелчок на кнопке Close закрывает главную форму.

Если в таблицах хранятся значения ключей из других таблиц (например, в поле SLKod - таблицы soderganie), то редактировать такие значения вручную, не зная, какому названию соответствует значение, бессмысленно. Добавление новых записей в такие таблицы проще осуществлять в отдельных формах программы, например, в такой как рабочая форма «Новый рецепт» (рис. 10). Она позволяет добавлять новые записи в соответствующую таблицу (soderganie) системы «Аптека».

Рис. 9. Главное окно приложения Рис. 10. Рабочее окно «Новый рецепт»

Рис. 11. Рабочие окна «Лекарства», «Рецепт», «Содержание рецепта»

Код программы главного окна приложения:

unit fmMainUnit;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, Buttons, StdCtrls, ExtCtrls, Menus;

type

TFMain = class(TForm)

Panel1: TPanel;

B1: TButton;

B2: TButton;

B3: TButton;

BitBtn1: TBitBtn;

BitBtn2: TBitBtn;

PopupMenu1: TPopupMenu;

N1: TMenuItem;

procedure FormShow (Sender: TObject);

procedure B1Click (Sender: TObject);

procedure B2Click (Sender: TObject);

procedure B3Click (Sender: TObject);

procedure BitBtn2Click (Sender: TObject);

procedure N1Click (Sender: TObject);

private

{Private declarations}

public

{Public declarations}

end;

var

FMain: TFMain;

implementation

uses dmAptekaUnit, FmLekarUnit, FmReceptUnit, FmSodRecUnit, fmQuery1Unit;

{$R *.dfm}

procedure TFMain. B1Click (Sender: TObject);

begin

FLekar. ShowModal;

end;

procedure TFMain. B2Click (Sender: TObject);

begin

FRec. ShowModal;

end;

procedure TFMain. B3Click (Sender: TObject);

begin

FSodRec. ShowModal;

end;

procedure TFMain. BitBtn2Click (Sender: TObject);

begin

dm.ADOrecept. Close;

DM.ADOlekar. Close;

dm.ADOsoderganie. Close;

end;

procedure TFMain. FormShow (Sender: TObject);

begin

FMain. Left:=0; FMain. Top:=0;

end;

procedure TFMain. N1Click (Sender: TObject);

begin

FQuery1. ShowModal;

end;

end.

Заключение

Информационные технологии (ИТ) на сегодняшний день являются неотъемлемой частью нашей жизни. Автоматизация процессов аптечной деятельности и использование ИТ в последние годы явились одним из рычагов для активного развития фармацевтической отрасли. Современные тенденции увеличения коммерческого сегмента в аптечном бизнесе, рост количества аптечных сетей приводят к тому, что нормальное функционирование и развитие аптеки уже не эффективно без использования ИТ. Их внедрение способствует обеспечению высокой скорости и оперативности работы и, что особенно важно, повышению прибыли, что позволяет аптекам выживать в условиях постоянной конкуренции. Кроме того, достаточно большая часть информации в настоящее время представлена в электронном виде, что в сегодняшних условиях развития коммуникаций обеспечивает ей более высокую мобильность, доступность и массовость.