Модель строится для того, чтобы лучше понимать разрабатываемую систему.Моделирование позволяет решить четыре различные задачи: 1 Визуализировать систему в ее текущем или желательном для нас состоянии; 2 Описать структуру или поведение системы; 3 Получить шаблон, позволяющий сконструировать систему; 4 Документировать принимаемые решения, используя полученные модели. Моделирование предназначено не только для создания больших систем. От моделирования может выиграть любой проект. Даже при создании одноразовых программ, когда зачастую бывает полезно выбрать неподходящий код из-за преимущества в скорости разработки, которое дают языки визуального программирования, моделирование поможет коллективу разработчиков лучше представить план системы, а значит, выполнить проект быстрее и создать именно то, что подразумевал первоначальный замысел. Чем сложнее проект, тем более вероятно, что из-за отсутствия моделирования он свернется раньше времени – или будет создано не то, что нужно. Все полезные и интересные системы с течением времени обычно усложняются. Пренебрегая моделированием в самом начале создания системы можно серьезно пожалеть об этом, когда будет уже слишком поздно. Моделирование имеет богатую историю во всех инженерных дисциплинах. Длительный опыт его использования позволил сформулировать четыре основных принципа. 1) Выбор модели оказывает определяющее влияние на подход к решению проблемы и на то, как будет выглядеть это решение (различные точки зрения на мир приводят к созданию различных систем, со своими преимуществами и недостатками). 2) Каждая модель может быть представлена с различной степенью точности (лучшей моделью будет та, которая позволяет выбрать уровень детализации в зависимости от того, кто и с какой целью на нее смотрит). 3) Лучшие модели – те, что ближе к реальности (поскольку модель всегда упрощает реальность, задача в том, чтобы это упрощение не повлекло за собой какие-то существенные потери). 4) Нельзя ограничиваться созданием только одной модели. Наилучший подход при разработке любой нетривиальной системы – использовать совокупность нескольких моделей, почти независимых друг от друга. Унифицированный язык моделирования (Unified Modeling Language – UML) – это стандартный инструмент для разработки «чертежей» программного обеспечения. Его можно использовать для визуализации, спецификации, конструирования и документирования артефактов программных систем. UML подходит для моделирования любых систем – от информационных систем масштаба предприятия до распределенных Web-приложений и даже встроенных систем реального времени. В лабораторном практикуме мы будем использовать UML для специфицирования (построения точных, недвусмысленных и полных моделей) системы и ее документирования. Язык UML предоставляет стандартный способ написания проектной документации на системы, включая концептуальные аспекты, такие как бизнес-процессы и функции системы, а также конкретные аспекты, такие как выражения языков программирования, схемы баз данных и повторно используемые компоненты ПО. Язык UML не является языком программирования (он инвариантен к языкам программирования). В нотации языка UML определены следующие виды канонических диаграмм: 1) вариантов использования (use case diagram); 2) классов (class diagram); 3) кооперации (collaboration diagram); 4) последовательности (sequence diagram); 5) состояний (statechart diagram); 6) деятельности (activity diagram); 7) компонентов (component diagram); 8) развертывания (deployment diagram). Перечень этих диаграмм и их названия являются каноническими в том смысле, что представляют собой неотъемлемую часть графической нотации языка UML. Более того, процесс ООАП неразрывно связан с процессом построения этих диаграмм. При этом совокупность построенных таким образом диаграмм является самодостаточной в том смысле, что в них содержится вся информация, которая необходима для реализации проекта сложной системы. Каждая из этих диаграмм детализирует и конкретизирует различные представления о модели сложной системы в терминах языка UML. Диаграмма вариантов использования представляет собой наиболее общую концептуальную модель сложной системы, которая является исходной для построения всех остальных диаграмм. Диаграмма классов, по своей сути, логическая модель, отражающая статические аспекты структурного построения сложной системы. Диаграммы кооперации и последовательностей представляют собой разновидности логической модели, которые отражают динамические аспекты функционирования сложной системы. Диаграммы состояний и деятельности предназначены для моделирования поведения системы. И, наконец, диаграммы компонентов и развертывания служат для представления физических компонентов сложной системы и поэтому относятся к ее физической модели. Рассмотрим более подробно каждую из перечисленных диаграмм. Диаграмма вариантов использования Визуальное моделирование с использованием нотации UML можно представить как процесс поуровневого спуска от наиболее общей и абстрактной концептуальной модели исходной бизнес-системы к логической, а затем и к физической модели соответствующей ПС. Вначале строится модель в форме так называемой диаграммы вариантов использования (use case diagram), которая описывает функциональное назначение системы и является исходным концептуальным представлением в процессе ее проектирования и разработки. На ней изображаются отношения между актерами и вариантами использования. Создание диаграммы вариантов использования имеет следующие цели: − Определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы. − Сформулировать общие требования к функциональному поведению проектируемой системы. − Разработать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей. − Подготовить исходную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями. Актер (actor) ‑ согласованное множество ролей, которые играют внешние сущности по отношению к вариантам использования при взаимодействии с ними (это может быть любой объект, субъект или система, взаимодействующая с моделируемой бизнес-системой извне, т.е. человек, техническое устройство, программа и т.п.). Вариант использования ‑ внешняя спецификация последовательности действий, которые система или другая сущность могут выполнять в процессе взаимодействия с актерами (он определяет набор действий, совершаемый системой при диалоге с актером). Цель спецификации варианта использования заключается в том, чтобы зафиксировать некоторый аспект или фрагмент поведения проектируемой системы без указания особенностей реализации данной функциональности. В этом смысле каждый вариант использования соответствует отдельному сервису, который предоставляет моделируемая система по запросу актера, т. е. определяет один из способов применения системы. Сервис, который инициализируется по запросу актера, должен представлять собой законченную последовательность действий. Это означает, что после того как система закончит обработку запроса актера, она должна возвратиться в исходное состояние, в котором снова готова к выполнению следующих запросов. Диаграмма вариантов использования содержит конечное множество вариантов использования, которые в целом должны определять все возможные стороны ожидаемого поведения системы. Для удобства множество вариантов использования может рассматриваться как отдельный пакет. Применение вариантов использования на всех этапах работы над проектом позволяет не только достичь требуемого уровня унификации обозначений для представления функциональности подсистем и системы в целом, но и является мощным средством последовательного уточнения требований к проектируемой системе на основе их итеративного обсуждения со всеми заинтересованными специалистами. Комментарии к примеру. На рисунке 7 приведен фрагмент диаграммы вариантов использования для разрабатываемой системы (он соответствует функциональной спецификации, приведенной в таблице 1, и дополняет ее новыми функциями). Любая диаграмма, входящая в Ваш UML-проект должна быть прокомментирована: кратко описаны все основные сервисы, которые приведены на диаграмме. Например, «Перед тем как работать в системе пользователь должен пройти процедуру авторизации (ввести логин и пароль). Система проверит введенные данные и настроит интерфейс пользователя на соответствующую роль. В системе должны быть предусмотрены две роли пользователя: администратор и игрок. Любой пользователь системы должен иметь возможность посмотреть справочную информацию (сведения о разработчиках и сведения о самой системе).
Рисунок 7 – Диаграмма вариантов использования системы (фрагмент)
Администратор может создавать кроссворд в ручном или автоматическом режиме, для этого он должен подключить словарь понятий и определить параметры кроссворда (выбрать значения, заданные по умолчанию, или изменить параметры); и т.д.» Следует отметить, что одним из требований языка UML является самодостаточность диаграмм для представления информации о моделях проектируемых систем. Однако большинство разработчиков и экспертов согласны с тем, что изобразительных средств языка UML явно не хватает для того, чтобы учесть на диаграммах вариантов использования особенности функционального поведения сложной системы. С этой целью рекомендуется дополнять этот тип диаграмм текстовыми сценариями, которые уточняют или детализируют последовательность действий, совершаемых системой при выполнении ее вариантов использования. Сценарий (scenario) ‑ определенная последовательность действий, которая описывает действия актеров и поведение моделируемой системы в форме обычного текста. В контексте языка UML сценарий используется для дополнительной иллюстрации взаимодействия актеров и вариантов использования. Предлагаются различные способы представления или написания подобных сценариев. Рассмотрим один из шаблонов для применения на начальных этапах концептуального моделирования. При написании сценариев вариантов использования важно понимать, что текст сценария должен дополнять или уточнять диаграмму вариантов использования, но не заменять ее полностью. В противном случае будут потеряны достоинства визуального представления моделей. Сценарий состоит из следующих разделов: 1. Главный раздел, в котором отражается имя варианта использования, перечисляются актеры, в нем участвующие, определяется цель и дается краткое описание. Кроме того, может быть указан тип сценария и даны ссылки на другие варианты использования. 2. Раздел «Основной поток событий», в котором отражается типичный ход событий, приводящий к успешному выполнению варианта использования. 3. Раздел «Исключения». 4. Раздел «Примечания». Комментарии к примеру. Рассмотрим вариант использования «Пройти авторизацию» для автоматизированной системы составления линейного кроссворда (прототип экранной формы приведен на рисунке 8).
Вариант использования: Пройти авторизацию Краткое описание. Даёт возможность любому пользователю войти в систему по своему имени и паролю с настройкой интерфейса системы на соответствующие права доступа. Пользователь двойным щелчком левой кнопки мыши по пиктограмме «Кроссворд» запускает приложение, перед ним открывается окно авторизации. Актант. Пользователь. Предусловия. Компьютер пользователя включён, на экране – главное окно операционной системы с набором пиктограмм на рабочем столе. Основной поток событий. 1) На экране появляется форма ввода имени пользователя и пароля с полями ввода «Логин», «Пароль» и с кнопками ОК и «Выход (Х)». 2) Пользователь вводит имя и пароль и щёлкает кнопку OK. А1: Щёлкнута кнопка «Выход». 3) Система проверяет имя и пароль. 4) Система закрывает форму ввода имени и пароля и выводит на экран главную форму приложения с пунктами меню. Состав пунктов меню настраивается в соответствии с правами пользователя. Вариант использования завершается успешно. А2: Имя и/или пароль неверны. Альтернативы. А1: Щёлкнута кнопка «Выход». А1.1. Система закрывает форму ввода имени и пароля и выводит на экран главное окно операционной системы. Вариант использования завершается. А2: Имя и/или пароль неверны. А2.1. Система выводит сообщение о неверном вводе имени и/или пароля и просит повторить вход или выйти из приложения. В последнем случае вариант использования завершается. Постусловия. При успешном завершении на экране – главная форма приложения с меню, настроенном на права пользователя. Неясные вопросы. Уточнить права пользователей и настройки.
|
