Конспект лекций, страница 12

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

Если вдальнейшем, в процессе развития системы, ее непосредственными пользователями будутстановиться действующие лица бизнес-процессов, то модель вариантов использованиябудет соответствующим образом модифицироваться.BusinessUse-Case ModelMoney Trans actionCustomer: Customer: Clerk: Loan SpecialistBusinessObject Model: Customer ProfileUse-Case ModelStep 1ClerkUse-Case ModelStep 2Cus tomerMoney Trans action 1: AccountMoney Transaction 2Money Transaction 1.1 Money Transaction 2: LoanLoan Spe cialis tLoa n Spec ialis tДля описания функциональных требований используются диаграммы деятельности:для описания поведения, включающего большое количество параллельных процессовдля анализа варианта использования (описывают последовательность действий и ихвзаимосвязь)для анализа потоков работ (workflow) в различных вариантах использования.

Когдаварианты использования взаимодействуют друг с другом, диаграммы деятельностиявляются средством представления и анализа их поведения.7Пример:ПолучитьЗаказHМножественнаяактивизацияОтменитьЗаказдля каждойстроки заказа*[не прошел]ПроверитьПлатежПроверитьПозициюЗаказа[в наличиина складе][прошел]УсловиесинхронизацииЗакрепитьза Заказом[все товарыимеютсяна складе,и платежпрошел][необходимповторныйзаказ]ПовторнозаказатьПозициюВыполнитьПоставкуМодель вариантов использования можно считать завершенной, если естьутвердительный ответ на следующие вопросы: Можно ли на основании модели сформировать четкое представление о функцияхсистемы и их взаимосвязях? Присутствует ли каждое функциональное требование хотя бы в одном вариантеиспользования? Если требование не нашло отражение в варианте использования, ононе будет реализовано. Учли ли вы, как с системой будет работать каждое заинтересованное лицо? Какую информацию каждое заинтересованное лицо будет передавать системе? Учли ли вы все внешние системы, с которыми будет взаимодействовать данная?Литература к лекции 51.

Коберн А. Современные методы описания функциональных требований к системам.:Пер. с англ. – М. Лори, 2002.2. Вендров А. М. Проектирование программного обеспечения экономическихинформационных систем. 2-е изд. – М.: Финансы и статистика, 2005. Параграфы 2.42.5.3. Соммервил И. Инженерия программного обеспечения. 6-е изд.: Пер. с англ. –М.: Вильямс, 2002. – Главы 5, 6.4. Якобсон А., Буч Г., Рамбо Дж.

Унифицированный процесс разработки программногообеспечения.: Пер. с англ. – СПб.: Питер, 2002. – Главы 6, 7.8Лекции 6. Анализ и проектирование программного обеспечения.Анализ ПОСначала охарактеризуем в целом технологический процесс анализа ипроектирования (один из процессов в рамках RUP). Его цели: трансформация требований в системный проект; создание стабильной архитектуры системы; адаптация системного проекта к среде реализации.На входе анализа и проектирования находятся модель вариантов использования,глоссарий и дополнительная спецификация, на выходе – проектная модель системы,модель базы данных, описание архитектуры.Процесс анализа и проектирования является итерационным, т.

е. разбит на несколькоитераций в ходе которых выполняется часть работ по анализу и проектированию частисистемы. Результаты каждой итерации интегрируются в общую модель. Поток работможно представить диаграммой деятельности:Эскизная архитектура включает: Набор ключевых абстракций. Набор классов анализа. Механизмы анализа. Иерархию уровней. Структуру системы. Реализации вариантов использования.Уточнение архитектуры состоит в переходе от классов анализа к проектным классам.1Определяются: проектные классы; механизмы проектирования; представлениеразмещения.Анализ поведения включает: анализ вариантов использования; определение элементов проекта; рецензирование проекта.Проектирование элементов включает: выявление пакетов и подсистем; проектирование классов; проектирование подсистем.Проектирование БД включает: выделение устойчивых классов; разработку структуры БД; определение механизмов хранения (таких как ODBC или OODBMS).Анализ и проектирование отличаются подходом к создаваемой системе.

Анализхарактеризуется тем, что: в центре внимания – проблема; не придается значения деталям; описывается структура и поведение системы; реализуются функциональные требования в архитектуре системы; модель анализа имеет относительно небольшой размер.Характеристики проектирования: в центре внимания – решение; придается значение деталям – операциям и атрибутам; учитываются аспекты производительности; модель приближена к реальному коду; реализуются нефункциональные требования; проектная модель значительно больше модели анализа.В целях борьбы со сложностью система создается на различных уровняхдетализации (абстракции): уровне анализа, уровне проектирования, уровне реализации исамом низком – уровне кода.анализпроектированиереализациякодЦельюобъектно-ориентированногоанализаявляетсятрансформацияфункциональных требований к ПО в предварительный системный проект и создание2стабильной основы архитектуры системы.

В дальнейшем предварительный проектуточняется с учетом нефункциональных требований и выбранных средств реализациипроекта – это происходит при проектировании.Исполнителями процесса анализа являются архитектор, разработчик, разработчикБД, разработчик пользовательского интерфейса, рецензент. Обязанности архитектора: координация и руководство процессом анализа и проектирования; определение структуры каждого архитектурного представления; осуществление архитектурного анализа.Обязанности разработчика: анализ вариантов использования; определение обязанностей, поведения, свойств классов и связей между классами; анализ одного или нескольких пакетов или подсистем.Разработчик БД отвечает за модель данных (схему БД).Разработчик пользовательского интерфейса (UI) создает экранные формы,навигационные карты, осуществляет прототипирование UI.Рецензент оценивает решения, принятые в ходе процесса и созданные рабочиепродукты (документы).Объектно-ориентированный анализ включает два вида деятельности выполняемыедруг за другом:1) архитектурный анализ;2) анализ вариантов использования.Архитектурный анализ выполняется архитектором системы и включает в себяследующие работы:1) утверждение общих стандартов (соглашений) моделирования и документированиясистемы;2) предварительное выявление архитектурных механизмов (механизмов анализа);3) формирование набора основных абстракций предметной области (классов анализа);4) формирование начального представления архитектурных уровней.Соглашения моделирования определяют: используемые диаграммы и элементы модели; правила их применения; соглашения по именованию элементов модели; организацию модели (пакеты).Соглашения фиксируются в документе «Руководящие указания по проектированию»(Design Guidelines).

Пример соглашений:1) Имена вариантов использования должны быть короткими глагольными фразами.2) Для каждого варианта использования должен быть создан пакет Use-Case Realization,включающий:a)по крайней мере одну реализацию варианта использования;b)диаграмму “View Of Participating Classes” (VOPC).3) Имена классов должны быть существительными, соответствующими, по возможности,понятиям предметной области.4) Имена классов должны начинаться с заглавной буквы.5) Имена атрибутов и операций должны начинаться со строчной буквы.6) Составные имена должны быть сплошными, без подчеркиваний, каждое отдельноеслово должно начинаться с заглавной буквы.Архитектурные механизмы отражают нефункциональные требования к системе(надежность, безопасность, хранение данных в конкретной среде, интерфейсы свнешними системами и т.д.) и их реализацию в архитектуре системы.

Архитектурныемеханизмы представляют собой набор типовых решений, или образцов, принятых вкачестве стандарта данного проекта. Категории архитектурных механизмов: Механизмы анализа: обеспечивают взаимодействие классов и компонентов3предметной области, без деталей реализации. Проектные механизмы: учитывают некоторые детали среды реализации, без привязкик конкретной среде (например, выбор между РСУБД и ООСУБД). Механизмы реализации: зависят от конкретной технологии, языка программирования,поставщика (Oracle, Sun или Microsoft) и т.д.Примеры механизмов анализа: Устойчивость (persistency): элементы модели, которые должны сохранять своесостояние в течение длительного времени должны быть определены как устойчивые(для каждого устойчивого элемента определяются его размер и количество хранимыхобъектов, сроки хранения, механизмы и частотные характеристики доступа). Интерфейс с унаследованными системами (legacy interface) – к этому механизмуотносят все элементы модели, ответственные за интерфейс с унаследованнойсистемой. Безопасность (уровни, правила, привилегии) – элементы, обеспечивающие контрольдоступа к системе. Распределение – элементы, которые должны быть распределены по узлам сети.Идентификация основных абстракций заключается в определении набора классовсистемы (классов анализа) на основе описания предметной области и спецификациитребований к системе (в частности, глоссария проекта).