Визуальное моделирование

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

жүктеу/скачать 10,86 Mb. бет 7/14 Дата 20.11.2022 өлшемі 10,86 Mb. #159057

Бұл бет үшін навигация:

• Т_Адрес

Разработка вида с точки зрения проектирования Вид с точки зрения проектирования является основным этапом концептуальной проработки модели. На данном этапе вводятся основные абстракции, определяются классы, и интерфейсы посредством которых реализуется решение поставленных задач. Если прецеденты только декларируют поведение системы, то на этапе разработки вида с точки зрения проектирования определяется какими средствами данные прецеденты будут реализованы. Статические аспекты данного вида разрабатываются посредством диаграммы классов, динамические - посредством диаграмм взаимодействий и состояний (автомат). Диаграммы классов содержат классы, интерфейсы, кооперации, а так же связи между ними. Начинать разработку диаграммы классов следует с определения классов, соответствующих основным сущностям системы, которые, как правило, определяются на начальных этапах разработки при описании предметной области. Здесь следует решить какие сущности удобнее смоделировать как классы, а какие как их атрибуты. При моделировании необходимо помнить, что каждому классу должна соответствовать некоторая реальная сущность или концептуальная абстракция из области, с которой имеет дело пользователь или разработчик. Хорошо структурированный класс обладает следующими свойствами: является четко очерченной абстракцией некоторого понятия из словаря проблемной области или области решения; содержит небольшой, точно определенный набор обязанностей и выполняет каждую из них; поддерживает четкое разделение спецификаций абстракции и ее реализации; понятен и прост, но в то же время допускает расширение и адаптацию к новым задачам. В рамках разработки модели «Аптека» определим классы: врач, фармацевт, лекарства, рецепт. Очевидно, что первые из них имеют много общих атрибутов, поэтому введем абстрактный класс персона, который будет инкапсулировать все свойства, относящиеся к человеку в контексте разрабатываемой системы (фамилия, имя, отчество, телефон, адрес). В данном случае персона будет суперклассом, и связываться отношением обобщения с классами врач, фармацевт. Атрибут адрес имеет собственную структуру, чтобы отразить ее можно ввести дополнительный класс, назовем его Т_Адрес (как принято во многих системах программирования названия классов начинать с буквы T). Следует иметь ввиду что, атрибут адрес класса персона является экземпляром класса Т_Адрес, то есть между этими классами устанавливается отношение зависимости (отображается пунктирной стрелкой с открытым наконечником, стрелка направлена от зависимого элемента к независимому). В нашем случае изменение структуры класса Т_Адрес влечет за собой изменение класса персона через структуру соответствующего атрибута (адрес). При моделировании класса Т_Адрес атрибут индекс зададим посредством примитивного типа T_POSTIDX, определяемого как шестизначное десятичное число. Примитивные типы моделируются стереотипом «type», диапазон значений указывается через ограничения, заключенные в фигурные скобки. В классе лекарства выделим специфические атрибуты, относящиеся только к лекарству: дата поступления, цена (лекарства), единицы измерения, имеющееся количество, срок годности. Атрибут единицы измерения лучше определить специализированным типом через перечисление. Перечисления моделируются классом со стереотипом «enum» (enumeration - перечисление), допустимые значения записываются как атрибуты, метки, определяющие видимость атрибутов при этом подавляются. В рассматриваемом примере через перечисление введем специализированный класс Т_ЕдИзм, определяющий возможные единицы измерения через перечисления. В данном случае, как и везде в подобных случаях при создании классов, специфицирующих атрибуты основного класса, устанавливаются отношения зависимости. Учитывая, что и лекарства и рецепт имеют общие атрибуты можно ввести дополнительный абстрактный класс, например, медикаменты, являющийся суперклассом для классов лекарства и рецепт, что позволит несколько сократить число связей. Класс медикаменты имеет атрибуты: наименование, группа. Атрибут группа посредством введенного через перечисление специализированного типа Т_Группа определяет к какой группе относится лекарство: к жаропонижающим, желчегонным, против гриппа или антибиотикам. Для класса рецепт вводится специфический атрибут дата, поликлиника (номер поликлиники), срок хранения рецепта, режим приёма (лекарства). Класс фармацевт имеет атрибут квалификация. Класс врач имеет атрибут специальность. При визуализации структуры классов следует обращать внимание на видимость атрибутов. Все рассмотренные атрибуты должны быть доступны и иметь видимость Public (обозначается знаком «+» или пиктограммой без замка). В рассмотренных классах мы делали упор на структуру, а не на поведение (операции не описывались и не предполагается их описывать), поэтому для облегчения восприятия диаграммы желательно изображение операций подавить. На введенном множестве классов необходимо доопределить связи. Связи обобщения и зависимости были уже определены, осталось определить ассоциации. Множественность отношения фармацевт - лекарства «многие к одному». Каждое лекарство относится к определенному фармацевту, в свою очередь определенному фармацевту может соответствовать несколько лекарств, поэтому ассоциация фармацевт - лекарства имеет тип множественности «многие к одному». На данной ассоциации со стороны фармацевта можно указать роль: учёт данных (т.е. формирование отчётов, редактирование данных и т.д.). Для того чтобы отобразить выписку рецепта у врача необходимо ввести ассоциацию между врачом и лекарством по типу «многие к одному», у одного врача может быть несколько рецептов. На данной ассоциации со стороны врача можно явно указать роль: выписка рецепта. Аналогично введём ассоциацию между врачом и лекарством: тип множественности ассоциации «многие к одному». Диаграмма классов приводится на рис. 3. Получившаяся диаграмма достаточно сложна и нагружена элементами, однако моделирование классов еще далеко не закончено: необходимо еще определить некоторые служебные классы и интерфейсы. С целью разгрузить диаграмму классов построим новый ее вид (на отдельной диаграмме) оставив изображение основных классов и подавив отображения вспомогательных, определяющих типы атрибутов (рис. 4). На рис. 4 наряду с основными классами, соответствующими концептуальным элементам системы показан также класс Т_Адрес, раскрывающий структуру адреса, данный класс также имеет важное значение, поскольку содержит необходимые элементы данных для врача и фармацевта - потомков класса персона. Перейдем к определению интерфейсов. Классы взаимодействуют с внешним миром через интерфейсы. жүктеу/скачать 10,86 Mb. Достарыңызбен бөлісу: