Моделирование при помощи диаграмм прецедентов

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

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

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

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

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

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

· С целью поиска ошибок и чтобы убедиться в адекватности дизайна:

отличная идея после первого перевода с UML на язык программирования сделать обратный перевод и сравнить исходные и восстановленные UML-модели (желательно, чтобы эти переводы выполнялись разными командами). Это позволит убедиться в том, что дизайн системы соответствует модели, никакая информация в ходе перевода не была утеряна, да и попросту выловить некоторые "баги". Такой подход называется обратной семантической трассировкой (или RST - Reverse Semantic Traceability) и разрабатывается компанией INTSPEI (http://www.intspei.com) как одна из базовых техник методологии INTSPEI P-Modeling Framework, краткие сведения о которой вы можете найти в приложении к этому курсу.

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

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

Рис. 6.14.

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

Рис. 6.15.

Следующие три примера уже по традиции мы позаимствовали с сайта шуток на UML (http://www.umljokes.com), продолжая доказывать, что на UML можно шутить - это полноценный язык общения, который можно применять так же, как и любой другой. Первый из примеров - это часть всем известной сказки о "Курочке Рябе", которую автор очень красочно оформил (рис. 6.16).

Рис. 6.16.

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

Рис. 6.17.

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

И наконец, третья картинка, которая не является хорошим примером диаграммы прецедентов, но просто забавна. Это рассказ о способах поведения, позволяющих гарантированно (!) провалить любой экзамен (рис. 6.18):

Рис. 6.18.

Выводы

· Модель прецедентов позволяет описать систему на концептуальном уровне.

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

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

· Эктор - это набор ролей, которые исполняет пользователь в ходе взаимодействия с некоторой сущностью.

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

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

· Каждый прецедент реализуется одной или несколькими кооперациями.

· Сценарии специфицируют прецеденты, а диаграммы взаимодействий визуализируют сценарии.

Контрольные вопросы

· Что такое нефункциональные требования? Как они отображаются на диаграммах прецедентов?

· Какие способы изображения экторов вы знаете?

· В какие отношения могут вступать экторы между собой?

· В чем состоит смысл отношений включения и расширения?

· Что такое точка расширения?

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

· Как прецеденты применяют в прямом и обратном проектировании?

 

 

Предложена методика проектирования прикладных приложений на платформе «1С:Предприятие 8» с использованием языка UML, которая апробирована автором в учебном процессе в рамках дипломного проектирования в течение 4 лет. Унифицированный язык моделирования (Unified Modeling Language) является в настоящее время фактически промышленным стандартом языка описания, визуализации и документирования объектно-ориентированных систем и бизнес-процессов с ориентацией на дальнейшую реализацию в виде программного обеспечения. Объектная ориентированность технологической платформы системы «1С:Предприятие» позволяет эффективно использовать для проектирования предметно-ориентированных прикладных приложений язык UML.

Проектирование прикладной конфигурации с использованием языка UML можно представить как процесс поуровневого спуска от исходного концептуального представления к объектной модели прикладных объектов конфигурации. Сначала для спецификации функционального назначения системы строится общая концептуальная модель прикладной конфигурации в виде диаграммы прецедентов (Use case diagram). На рис. 1 представлен пример диаграммы прецедентов, описывающей набор функциональных сервисов автоматизированной системы налогового бюджетирования (АСНБ) [1].

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

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

Рис. 1. Диаграмма прецедентов системы АСНБ

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

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

Рис. 2. Использование отношения обобщения для отражения механизма наследования

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

Таким образом, рассмотрены особенности использования графической нотации UML для визуализации, специфицирования, конструирования и документирования процесса разработки прикладных приложений на платформе «1С:Предприятие». Описанная методика позволяет разработать модель прикладной системы в терминах объектно-ориентированной технологической платформы «1С:Предприятие», которая является основой для построения конфигурации в среде «1C:Предприятие».

 

⇐ Предыдущая12345678

Поделиться: