Статическое моделирование и язык UML Хотя диаграммы классов являются в UML стандартными, нет единого мнения о том, как их следует применять при построении статической модели, то есть каким методом пользоваться для их разработки. Некоторые методологи советую включать в статическую модель все классы. Другие считают, что в статической модели должны быть отражены только сущностные, то есть информационно насыщенные классы, которые обычно отображаются на базу данных. Третьи рекомендуют различные уровни статического моделирования - начиная с концептуального на этапе анализа и заканчивая более детальным на этапе проектирования. Концептуальная статическая модель строится на раннем тапе анализа и используется для лучшего освоения предметной области. Цель состоит в том, чтобы сосредоточить внимание на тех аспектах предметной области, которые наиболее заметны в статической модели, в частности на физических информационно насыщенных классах, которые называются, сущностными. В этом разделе описывается процесс создания черновой концептуальной статической модели, выполняемый на этапе анализа; более подробная статическая модель строится позже, на этапе проектирования. Статическое моделирование предметной области При построении статической модели предметной области в методе COMET сначала моделируются физические и сущностные классы. К физическим классам относятся классы, обладающие физическими характеристиками, то есть описывающие предметы, которые можно увидеть или потрогать. Это физические устройства (нередко являющиеся частью предметной области во встраиваемых приложениях), пользователи, внешние системы и таймеры. Сущностными называются концептуальные информационно насыщенные классы, которые обычно являются устойчивыми, то есть долго живущими. Сущностные классы особенно часто встречаются в информационных системах. Так, в банковских системах бывают дебетовые карточки, счета и транзакции. Для встраиваемых систем, где есть датчики и приводы, диаграммы классов помогают моделировать реальные устройства. Например, в системе управления лифтами полезно промоделировать физические устройства (мотор, дверь, кнопки и лампочки), их ассоциации и кратности ассоциаций. Для изображения составных частей класса, отражающего некий аспект реального мира, обычно пользуется составными классами. Так, лифт - это составной класс, включающий в себя мотор, дверь, несколько кнопок и лампочек. Рассмотрим статическую модель предметной области для банковской сист емы. У банка есть несколько банкоматов (рис. 1). Каждый банкомат - это составной класс, содержащий Устройство Считывания Карточек, Устройство Выдачи Наличных, Устройство Печати Чеков и Клиента Банкомата, который взаимодействует с системой посредством клавиатуры и дисплея. Устройство Считывания Карточек читает пластиковую Карточку, являющуюся физической сущностью. Устройство Выдачи Наличных выдает Наличные, то есть бумажные купюры определенного достоинства, которые также вполне осязаемы Устройство Печати Чеков распечатывает Чек - тоже физическую сущность в виде листка бумаги. Физические сущности представляют собой классы предметной области, для которых в программе требуется построить концептуальное представление. В большинстве случаев нужно создать программные классы, отражающие данные физические сущности. Такие решения принимаются во вpемя проектирования классов и объектов. Помимо этого есть еще Оператор, также являющийся пользователем, в обязанности которого входит обслуживание банкомата. Как и Клиент Банкомата, Оператор взаимодействует с системой при помощи клавиатуры и дисплея. 1 Рис. 1 Статическое моделирование контекста системы Важно хорошо понимать интерфейс между системой и внешней средой - контекст системы. В структурном анализе он изображается на диаграмме контекста системы. Контекст системы можно изобразить посредством статической модели или модели кооперации. При моделировании предметной области полезно выявить границы системы, для чего разрабатывается диаграмма классов системы, контекста системы, дающая более детальное представление о границах, чем диаграмма прецедентов. Диаграмма классов контекста системы можно построить путем статического моделирования внешних классов, соединенных с системой. В частности, физические классы это зачастую устройства ввода/вывода, которые выступают в роли внешних для системы классов. Можно воспользоваться диаграммой прецедентов, рассмотрев актеров и устройства, которыми они пользуются для взаимодействия с системой. Ниже описывайся оба подхода. Внешние классы С помощью нотации UML контекст системы моделируется так: система изображается в виде агрегатного класса со стереотипом «система», а внешняя среда - в виде набора внешних классов, с которыми система должна взаимодействовать. Внешние классы характеризуются с помощью стереотипов. Внешний класс можно назвать «внешним устройством ввода», «внешним устройством вывода», «внешним устройством ввода/вывода», «внешним пользователем» «внешней системой» или «внешним таймером». Для систем реального времени желательно выявить низкоуровневые классы, соответствующие физическим устройствам ввода/вывода. Эти внешние классы изображаются со стереотипом «внешнее устройство ввода/вывода». Примерами могут служить Вал в системе круиз-контроля и Мотор в системе управления лифтами. Человек часто взаимодействует с системой посредством стандартных устройств ввода/вывода. Характеристики данных устройств несущественны, так как с ними работает операционная система. Гораздо полезнее описать интерфейс с точки зрения того, какую информацию пользователь получает, а какую - вводит. Поэтому внешний пользователь, взаимодействующий с системой при помощи стандартных устройств, моделируется как «внешний пользователь», а не как устройство. Общая рекомендация такова: пользователя-человека следует представлять классом внешнего пользователя, если для работы с системой он применяет только стандартные устройства. С другой стороны, если ему приходится использовать специализированные устройства ввода/вывода, то их нужно представлять классами внешних устройств. 2 Класс «внешнего таймера» используется, если приложение должно следить за временем или если события внешнего таймера инициируют какие-то события в системе. Чаще всего класс «внешнего таймера» бывает полезен в системах бального времени. Примером может служить Тактовый Генератор в системе круиз-контроля: он нужен для того, чтобы система могла вести отсчет времени при вычислении скорости движения, и для запуска различных периодических видов деятельности. Иногда потребность в таких видах деятельности становится очевидной только на этапе проектирования. Класс «внешней системы» необходим в случаях, когда система данными с другими системами. Так, система автоматизации производства взаимодействует с двумя внешними: Подъемно-Транспортным Роботом и Сборочным Роботом. Ассоциации между системными агрегатными классами и внешними классами, а также их кратности изображаются на диаграмме классов контекста системы. Таким ассоциациям присваиваются стандартные имена: Вводит, Выводит, Соединен, Взаимодействует и Пробуждает, например: «внешнее устройство ввода» Вводит-в «систему» «система» Выводит-на «внешнее устройство вывода» «внешний пользователь» Взаимодействует-с «системой» «внешняя система» Соединена-с «системой» «внешний таймер» Пробуждает «систему» Пример разработки диаграммы классов контекста системы с внешними классами Пример диаграммы классов контекста системы приведен на рис. 2, где изображены внешние классы, с которыми должна связываться банковская система, Внешние классы определяются непосредственно из ранее описанной статической модели предметной области. С точки зрения общей программно-аппаратной структуры системы клиент банкомата является внешним по отношению к системе, тогда как устройства ввода/вывода - частями самой системы. С точки зрения только программного обеспечения устройства ввода/вывода для программы являются внешними, поэтому моделируются как внешние классы. В данном примере выделяются три класса внешних устройств: Устройство Считывания Карточек, Устройство Печати Чеков и Устройство Выдачи Наличных. Рис 2. Есть также два класса внешних пользователей: Клиент Банкомата и Оператор, которые взаимодействуют с системой посредством клавиатуры и дисплея. Для каждого банкомата имеется ровно по одному экземпляру этих внешних классов. 3 Актеры и внешние классы Рассмотрим, как можно вывести диаграмму классов контекста системы путем анализа взаимодействующих с ней актеров. Актеры - это более абстрактная концепция, нежели внешние классы. Между актерами и внешними классами существуют следующие отношения: актер-устройство ввода/вывода эквивалентен классу внешнего устройства ввода/вывода. Это значит, что такой актер связан с системой посредством класса внешнего устройства; актер-внешняя система эквивалентен классу внешней системы; актер-таймер связан с системой посредством класса внешнего таймера, генерирующего для системы события; актер-человек обладает наибольшей гибкостью. В простейшем случае он общается с системой при помощи стандартного устройства ввода/вывода. Внешнему классу присваивается имя актера-человека, поскольку интерес представляет именно логическая структура информации, поставляемой человеком. В более сложных случаях такой актер способен общаться с системой посредством различных внешних классов. Примером может служить актер-клиент в банковской системе. Пример разработки диаграммы классов контекста системы на основе рассмотрения актеров Чтобы определить внешние классы по актерам, необходимо ясно представлять себе характеристики каждого актера и его взаимодействие с системой. Эту информацию можно почерпнуть из описания прецедентов. Рассмотрим случай, когда актерами являются люди. В банковской системе есть два актера-человека: Клиент Банкомата и Оператор. На рис. 2 показана диаграмма классов контекста банковской системы. Банковская система представлена в виде одного агрегатного класса и соединенных с ним внешних классов. Оператор общается с системой с помощью стандартного Устройства и потому изображен как внешний пользователь: характеристики пользователя в таком случае важнее характеристик устройства. Что касается клиента, то он взаимодействует с системой посредством одного стандартного и трех специализированных устройств. К нестандартным относится одно внешнее Устройство ввода/вывода (Устройство Считывания Карточек) и два внешних устройства ввода (Устройство Печати Чеков и Устройство Выдачи Наличых). Все пять внешних классов связаны с банковской системой ассоциациями один-ко-многим. На рис. 2 представлено, как актеры соотносятся с внешними весами (в общем случае показывать актеров на диаграммах классов контекста системы необязательно). Статическое моделирование сущностных классов Сущностными называются концептуальные информационно насыщенные классы. В них хранятся устойчивые (долго живущие) данные, к которым, имеются обращения из нескольких прецедентов. Чаще всего сущностные классы встречают в информационных системах, но многие распределенные приложения и приложения реального времени тоже нуждаются в информации. Сущностные классы нередко отображаются на базу данных на этапе проектирования. При построении статической модели предметной области акцент ставится на выявлении сущностных классов, их атрибутов и взаимоотношений. В частности в банковской системе есть банки, счета, клиенты, дебетовые карточки и транзакции. Каждая из этих сущностей реального мира моделируется в виде сущностного класса и изображается со стереотипом «сущность». Затем определяются атрибуты таких классов и отношения между ними. Пример концептуальной статической модели сущностных классов в банковской системе приведен на рис. 3. На этом рисунке изображен класс Банк, который находится в отношении один-ко-многим с классами Клиент и Дебетовая Карточка. Между классами Клиент и Счет имеется отношение многие-ко-многим. У класса Счет есть специализации Чековый Счет 4 Рис 3. и Сберегательный Счет. В случае, когда атрибуты принадлежат ассоциации, а не связанным ею классам могут понадобиться классы-ассоциации. Так, для ассоциации многие-ко-многим между дебетовой Карточкой и Счетом индивидуальные счета, доступные по данной карточке, - это атрибуты класса-ассоциации Карточный Счет, а не классов Дебетовая Карточка или Счет. Другой пример сущностного класса - Транзакция Банкомата, у него есть специализации для разных транзакций. 5