Визуальное моделирование
жүктеу/скачать 10,86 Mb.
|
bibliofond.ru 656650
- Бұл бет үшін навигация:
- КодирТабл
| Интерфейс (Interface) - это совокупность операций, которые определяют сервис (набор услуг), предоставляемый классом или компонентом. Таким образом, интерфейс описывает видимое извне поведение элемента. Интерфейс может представлять поведение класса или компонента полностью или частично; он определяет только спецификации операций (сигнатуры), но никогда - их реализации. Графически интерфейс изображается в виде круга, под которым пишется его имя. Интерфейс редко существует сам по себе - обычно он присоединяется к реализующему его классу или компоненту. Интерфейс всегда предполагает наличие некоторого «контракта» между стороной, которая декларирует выполнение ряда операций и стороной, которая эти операции реализует.
Рис. 4. Упрощенная диаграмма классов Поместим на диаграмму класс электронная таблица, в котором инкапсулированы все свойства и операции электронной таблицы, позволяющей редактировать данные. Структуру данного класса раскрывать ввиду большой сложности не будем. Так в современных средствах разработки приложений пользователь пользуется готовыми классами и шаблонами, наследуя их возможности, например библиотека VCL (Delphi) содержит класс TTable, инкапсулирующий возможности электронной таблицы. Потомки класса электронная таблица являются конкретными электронными таблицами, содержащие конкретные данные по лекарствам, рецепту (выписанному рецепту), фармацевту, врачу. Делая соответствующие классы потомками класса электронная таблица, мы декларируем для этих классов все свойства и операции, присущие электронным таблицам (регистрацию в системе, вставку, удаление, редактирование данных, сортировку и т.д.). Для класса электронная таблица, а соответственно и для всех его потомков определим интерфейс редактирование, подразумевая все возможные операции редактирования данных (вставку, удаление, изменение данных). Также для этого класса определим интерфейс менеджер отчётов, содержащий операции: формирование отчетов за день, учет заказов и т.д. При этом предполагается, что в классе электронная таблица данные возможности реализованы. Использование специального класса электронная таблица и наследование позволило избежать определения специальных свойств и интерфейсов редактирования данных, менеджера отчётов для каждой электронной таблицы. Отобразим интерфейс поиск лекарства с указанием списка операций. Отношение реализации отображается пунктирной стрелкой с закрытым наконечником. Также определим интерфейс заполнение рецепта, подразумевающий операции - ввод наименования лекарства, единиц измерения, режим приёма и т.д., присоединенный к соответствующему классу. Состав операций данного интерфейса раскрывать не будем, т.к. он достаточно тривиален. Естественно предполагается, что введенные интерфейсы реализуется средствами классов, к которым они присоединены отношением реализации, то есть соответствующие классы содержат операции и методы, реализующие заявленные интерфейсы. Для облегчения восприятия данные механизмы не визуализируются. Для управления правами доступа и авторизацией пользователя введем класс менеджер доступа. Менеджер доступа имеет атрибут закрытого типа доступа таблица паролей, который является экземпляром класса КодирТабл (Кодированная таблица), содержащей пароли (password) и входные имена (login) пользователей-администраторов. Предполагается, что возможности служебного класса КодирТабл не позволяют постороннему пользователю считывать пароли пользователей. На данном этапе проектирования мы просто декларируем такие возможности, не останавливаясь на механизме их реализации, но предполагая, что таковые инкапсулированы в класс КодирТабл. Класс менеджер доступа содержит открытые операции ввод пароля и предоставление прав администратора, средствами которых реализуется авторизация и управление правами доступа. Укажем зависимость между интерфейсом редактирования данных (редактирование) и менеджером доступа, предполагая, что полные возможности по редактированию данных имеют только пользователи с правами администратора. Итоговая диаграмма приводится на рис. 5. Итак, разработка модели системы «Аптека» средствами диаграммы классов UML на данном этапе можно считать законченной. Естественно, возможны возвращения к ней и пересмотр некоторых элементов в ходе проектирования системы, при корректировке задач, при уточнении отдельных деталей. Процесс проектирования информационных систем является итеративным. Необходимо отметить, что разработанная диаграмма классов содержит элементы явно или скрыто реализующие все прецеденты использования диаграммы прецедентов. Каждому прецеденту диаграммы прецедентов должен соответствовать либо интерфейс, либо операция интерфейса (реализация предполагается в соответствующих интерфейсу классах), либо открытая операция класса, либо набор открытых операций (в данном случае прецедент реализуется непосредственно соответствующим классом или набором классов). Рассмотрим процесс создания новой записи о лекарстве средствами диаграммы последовательности. Создание новой записи предполагает права администратора, поэтому действующим лицом данного взаимодействия будет фармацевт. Данный элемент уже был введен на диаграмме прецедентов, поэтому перетащим его на диаграмму последовательности из браузера вида с точки зрения прецедентов. Следует обратить внимание, что на диаграммах взаимодействия фигурируют объекты, то есть конкретные экземпляры классов (имя объекта всегда подчеркивается). Ведем объекты: форма ввода, менеджер записей, запись о лекарстве Ampilicilin (как конкретный пример записи о лекарстве), менеджер транзакций. Данный набор объектов является типовым при модификации записи в таблице базы данных. жүктеу/скачать 10,86 Mb. Достарыңызбен бөлісу:
|