Мансуров Н. Н., Майлингова О. Л. - Методы формальной спецификации программ - языки MSC и SDL, страница 3

Основной особенностью фазыанализа требований является точка зрения на системы как на «черный ящик»,находящийся в некотором окружении. Основные усилия разработчиковнаправляются на уточнение непосредственного окружения системы.8Назначение фазы анализа системы (system analysis) заключается внахождении основных объектов системы, необходимых для достижениятребуемой функциональности.Назначение фазы системного проектирования (system design)заключается в уточнении архитектуры системы, выделении компонентовсистемы (подсистем) и определении детальных интерфейсов междукомпонентами системы. Фаза системного проектирования включает в себятакже дополнительный анализ системы с точки зрения среды разработки инахождение такой организации компонентов системы, при которой возможнопоследующаяреализациянесколькиминезависимымигруппамиразработчиков.Фаза детального проектирования (detailed design) заключается вуточнении поведения всех объектов системы.Фаза реализации (implementation) заключается в создании исполнимогоприложения, отвечающего исходным требованиям.Интересно, что на ранних фазах разработки имеет местопреимущественно аналитическая деятельность, связанная с обнаружением иописанием объектов и свойств, тогда как на более поздних фазах имеет местопреимущественно синтетическая деятельность, связанная с изобретением,построением новых объектов и свойств.Мы будем рассматривать современный объектно-ориентированныйметод разработки.

Форма моделей и последовательность их построенияпредставлена на Рис. 1. Основу метода составляют модели двух типов:объектные модели и сценарные модели.Рассмотрим фазы разработки и соответствующие модели болееподробно.1.1. Фаза анализа требованийФаза анализа требований разделяется на два вида деятельности:Анализ предметной областиАнализ требований к системе.9Рис.

1. Фазы разработки и моделиНазначением анализа предметной области является достижениепонимания среды, для которой разрабатывается система, безотносительно ксамой системе. Формой представления знания о предметной области являетсятак называемая объектная модель требований (объектная модель на Рис. 1).Объектная модель документирует все понятия предметной области, а такжесвязи (отношения) между этими понятиями.

Преимущества построения такоймодели трудно переоценить:Разработчики и заказчики получают общее понятийное поле, котороеможно использовать для проверки взаимопонимания10Объектная модель существенно облегчает построение архитектурноймодели. Объектная модель позволяет быстро интегрировать новых членовколлектива разработчиков, ранее не знакомых с данной предметнойобластью.Для формализации объектной модели мы будем использовать такназываемый язык объектных моделей (OMT).Назначением анализа требований к системе является формализациятребований заказчика к разрабатываемой системе. Формой представлениязнания о решаемой задаче является так называемая сценарная модель.Сценарная модель представляет собой набор описаний сценариевиспользования системы, т.е.

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

Назначением словаря проекта являетсястандартизация терминологии, применяемой всеми участниками проекта,включая разработчиков, заказчиков и пользователей.1.2. Фаза анализа системыРассмотрим теперь следующую фазу – анализ системы. Назначениемфазы анализа системы является выявление архитектуры разрабатываемойсистемы. Основу системного анализа составляет поиск оптимального набораобъектов, взаимодействие которых обеспечит выполнение требований ксистеме.

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

Формойдокументирования результатов системного анализа является так называемаяархитектурная модель – объектная модель, описывающая компонентысистемы, их назначение (т.е. выполняемые им функции) и их взаимосвязи.11Именно на этапе анализа системы происходит выбор стабильной, устойчивойк изменениям, расширяемой архитектуры, которая будет способнаобеспечить последующую эволюцию системы на протяжении ее ожидаемойжизни.Дополнительно, на фазе системного анализа происходит уточнениесценариев использования системы и описание динамики архитектуры, т.е.описание взаимодействия компонентов системы по каждому сценарию.Формой документирования динамики архитектуры являются диаграммывзаимодействия MSC.1.3.

Фаза системного проектированияНа данной фазе принимаются окончательные решения по одному изсамых важных вопросов разработки – определение архитектуры системы, т.е.того, как сложная система строится из более простых частей, которые, в своюочередь, могут состоять из еще более простых частей и так далее. Выявлениеархитектуры происходит на фазе анализа системы, но ее точное определениеявляется основным содержанием фазы системного проектирования.Источником информации для фазы системного проектированияявляются архитектурная модель и соответствующая ей сценарная модель,построенные на фазе анализа системы. Результатом фазы является детальноеописание компонентов системы и их интерфейсов.На фазе системного проектирования создаются следующие модели:Определение архитектуры системыСтруктура проектных модулей системыДетальная сценарная модель, соответствующая архитектуреАрхитектура системы описывается на языке SDL. В языке SDL основнойструктурной единицей является блок.

Блок является контейнером для другихобъектов.Архитектураописываетлогическуюструктурусистемы.Дополнительно, производится разделение системы на проектные модули.Проектные модули представляют собой организационное деление системы начасти, которые могут быть реализованы независимо и параллельно другдругу разными группами разработчиков. На языке SDL проектные модулиобычно представляются как пакеты.

При описании структуры проектныхмодулей может быть описано, каким образом в системе планируетсяиспользовать стандартные каркасы, компоненты и инструментальныесредства. Дополнительно здесь принимаются решения по стратегииреализации каждого модуля. Структура проектных модулей описывается припомощи объектной диаграммы.12Интерфейсы компонентов архитектуры системы описываются на языкеSDL.

В SDL средством описания интерфейса являются определениясигналов. Динамический аспект интерфейсов, т.е. описание взаимодействияблоков, моделируется при помощи очередного уточнения сценарной модели.1.4. Фаза детального проектированияДанная фаза завершает разработку системы. Существует тесная связьмежду данной фазой и предшествующей фазой системного проектирования,т.к. на фазе детального проектирования решаются вопросы представления иопределения поведения объектов, тогда как на фазе системногопроектирования происходит распределение объектов по блокам иорганизация коммуникации между блоками.13Глава 2. Сценарные моделиСценарные модели предназначены для описания внешнего поведениясистемы. Сценарная модель представляет собой систематическое описаниеспособов использования системы.

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

Основные понятияСценарная модель использует понятия агент (от англ. actor), роль,интерфейс и сценарий. Каждый агент использует систему для достиженияопределенной цели. Основная идея сценарной модели заключается вописании поведения системы как совокупности ролей по отношению кагентам. По определению, роль – это определенная функциональность,которой должна обладать система для достижения одним из агентов одной изего целей. Достижение агентом своей цели предполагает взаимодействиемежду агентом и системой.

Система взаимодействует с каждым из агентов водной из ролей. Каждой роли соответствует отдельный интерфейс. Каждаяроль описывается как сценарий взаимодействия между агентом и системой,т.е. как возможные последовательности событий. Такой сценарийназывается сценарием использования системы, т.к.

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

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