Анализ

Аналитическое моделирование имеет стратегически важное значение, поскольку на этом этапе делается попытка смоделировать основное поведение системы.
Цель рабочего потока анализа (с точки зрения ОО-анализа) – создание аналитической модели. Данная модель фокусируется на том, что должна делать система. Детали того, как система будет это делать, предоставляются потоку проектирования.
Граница между анализом и проектированием довольно неопределенная, и до известной степени все зависит от аналитика.

В рабочем потоке анализа создаются два ключевых артефакта:
• классы анализа – ключевые понятия в бизнес сфере;
• реализации прецедентов – иллюстрируют, как экземпляры классов анализа могут взаимодействовать для реализации поведения системы, описанного прецедентами.

Задачи рабочего потока

• Архитектурный анализ
• Анализ прецедента
• Анализ класса
• Анализ пакета

Аналитическая модель – практические правила:

• Аналитическая модель всегда создается на языке соответствующей сферы деятельности. Абстракции аналитической модели должны формировать часть словаря бизнес сферы.
• Создаваемые модели должны «рассказывать историю». Каждая диаграмма должна раскрывать некоторые важные части поведения системы. Иначе зачем они нужны?
• Необходимо сосредоточиться на отображении основной картины. Не надо углубляться в детали того, как будет работать система. Для этого отводится достаточно времени при проектировании.
• Необходимо четко различать предметную область (бизнес требования) и область решения (детальные конструктивные соображения). Основное внимание всегда должно быть направлено на абстракции предметной области. Например, при моделировании системы электронной торговли в аналитической модели должны присутствовать классы Customer (клиент), Order (заказ) и ShoppingBasket (корзина покупок). Здесь не должно быть классов доступа к базе данных или классов для установления соединений, поскольку они – артефакты области решения.
• Всегда необходимо стремиться минимизировать связанность (coupling). Каждая ассоциация между классами увеличивает их связанность.
• Если присутствует естественная и очевидная иерархия абстракций, должна быть рассмотрена возможность применения наследования. При анализе иерархия никогда не должна применяться просто для повторного использования кода. Наследование – самая сильная форма связанности классов.
• Всегда должен задаваться вопрос: «Модель полезна для всех заинтересованных сторон?» Нет ничего хуже, чем создавать аналитическую модель, которая игнорируется пользователями или проектировщиками и разработчиками. Пока что это происходит очень часто, особенно с неопытными аналитиками. Основная превентивная стратегия при этом – сделать аналитическую модель и процесс моделирования максимально открытыми, по возможности привлечь в него заинтересованные стороны, проводить частые и публичные обзоры.

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

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

Исходные данные для деятельности Выявление актеров и прецедентов

• Бизнес модель – может быть предоставлена в распоряжение разработчиков модели системы, но это не всегда выполняется. Если она есть, это превосходный источник для сбора требований.
• Модель требований – создаётся разработчиками по результатам сбора информации.
Эти требования являются хорошим исходным материалом для процесса моделирования прецедентов. В частности, функциональные требования предложат прецеденты и актеров. Нефункциональные требования – то, о чем надо помнить при создании модели прецедентов.
• Список возможностей – это набор потенциальных требований, которые могут быть представлены в форме общего описания (vision) проекта или чего либо подобного.

Выявление актеров

Следующие вопросы помогут идентифицировать актеров.
• Кто или что использует систему?
• Какие роли они играют во взаимодействии?
• Кто устанавливает систему?
• Кто или что запускает и выключает систему?
• Кто обслуживает систему?
• Какие системы взаимодействуют с данной системой?
• Кто или что получает и предоставляет информацию системе?
• Происходит ли что нибудь в точно установленное время?
При моделировании актеров необходимо помнить следующие моменты.
• Актеры всегда являются внешними по отношению к системе, следовательно, находятся вне вашего контроля.
• Актеры взаимодействуют непосредственно с системой – так они помогают в определении контекста системы.
• Актеры представляют роли, исполняемые людьми или сущностями по отношению к системе, а не конкретных людей или сущностей.
• Один человек или сущность может играть по отношению к системе множество ролей одновременно или последовательно во времени. Например, вы составляете и ведете учебные курсы. С точки зрения системы планирования курсов вы играете две роли: Trainer (инструктор) и CourseAuthor (автор курса).
• У каждого актера должно быть короткое, осмысленное с прикладной точки зрения имя.
• Каждого актера должно сопровождать краткое описание (одна или две строчки), объясняющее, что данный актер из себя представляет с прикладной точки зрения.
• Как и в классах, в обозначении актеров могут быть представлены атрибуты актера и события, которые он может получать. Такие обозначения не часто используются и редко отображаются на диаграммах прецедентов. Далее в этой книге они не упоминаются.
•  Если необходимо смоделировать что-то, происходящее с системой в определенный момент времени, но неинициируемое ни одним из актеров, можно ввести актера под названием Time (время). В качестве примера приведем автоматическое сохранение резервной копии системы, выполняемое ежедневно вечером.

Выявление прецедентов

• прецеденты всегда инициируются актером;
• прецеденты всегда описываются с точки зрения актеров.

Ниже приводится полезный список вопросов, которые можно задавать при идентификации прецедентов.
• Какие функциональные возможности понадобятся конкретному актеру от системы?
• Система сохраняет и извлекает информацию? Если да, какой из актеров инициирует это поведение?
• Что происходит, когда система изменяет состояние (например, при запуске и выключении системы)? Кто нибудь из актеров получает при этом уведомление?
• Какие либо внешние события оказывают влияние на систему? Как система узнает об этих событиях?
• Система взаимодействует с какой либо внешней системой?
• Система генерирует какие либо отчеты?

Глоссарий проекта

Глоссарий обеспечивает словарь ключевых деловых терминов и определений. Он должен быть понятен всем участникам проекта, включая все заинтересованные стороны.

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

Спецификация прецедента

Матрица отображаемости требований

Когда применять моделирование прецедентов

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

Прецеденты не стоит применять в тех случаях, когда:
• в системе преобладают нефункциональные требования;
• в системе мало пользователей;
• в системе мало интерфейсов.

Отношения прецедентов

Отношение «include» выносит шаги, общие для нескольких прецедентов, в отдельный прецедент, который потом включается в остальные.
 Отношение «extend» – способ введения нового поведения в существующий прецедент.

Определение требований

Прецеденты могут отражать только функциональные требования, которые являются описанием того, что будет делать система. Однако есть и другие требования, не относящиеся к функциональности, которые являются описаниями ограничений, накладываемых на систему (производительность, надежность и т. п.), и не могут быть представлены в виде прецедентов.
SRS - Software requirements specification

Задачи рабочего потока

• Выявление функциональных требований.
• Выявление нефункциональных требований.
• Назначение приоритетов требований.
• Отображение (trace) требований в прецеденты.
• Выявление актеров и прецедентов.
• Детализация прецедента.
• Построение модели прецедентов.
• Назначение приоритетов прецедентов.
• Создание прототипа пользовательского интерфейса.

Понятие требования

Требование можно определить как «подробное описание того, что должно быть реализовано». Существует два основных типа требований:
• функциональные требования – какое поведение должна предлагать система;
• нефункциональные требования – особое свойство или ограничение, накладываемое на систему.

Требования указывают, что должно быть построено, но не говорят, как это сделать.

Атрибуты требований

Каждый атрибут требования имеет описательное имя и значение. Так же требование может иметь атрибут source (источник), в качестве значения которого выступает описание того, откуда возникло данное требование. Конкретный набор используемых атрибутов зависит от природы и нужд проекта и может меняться в зависимости от типа требования.
Наверное, самым распространенным атрибутом требований является priority (приоритет). Его значение определяет приоритет требования относительно остальных требований. Обычно для назначения приоритетов применяется набор критериев MoSCoW.

Ниже приведён набор атрибутов требований, использующийся в RUP:

Поиск требований

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

 При выяснении у людей требований, предъявляемых к программной системе, вы всегда пытаетесь добиться от них точной картины, или карты, модели их сферы деятельности.
Подробная карта создается тремя процессами: пропуск (deletion), искажение (distortion) и обобщение (generalization). Эти процессы абсолютно необходимы, поскольку мы просто не располагаем механизмом познания, способным фиксировать каждый нюанс и деталь нашей сферы деятельности в некоторой воображаемой, подробной до мельчайших деталей карте. Поэтому приходится быть изобретательными. Мы осуществляем «выборку» из огромного массива возможной информации, применяя три фильтра:
• пропуск – информация отфильтровывается;
• искажение – информация изменяется взаимосвязанными механизмами вымысла и представления;
• обобщение – информация обобщается в правила, убеждения и понятия об истинности и ложности.
Эти фильтры образуют естественный язык. О них важно знать при тщательном сборе и анализе требований, поскольку для восстановления информации может понадобиться активно их идентифицировать и ставить под сомнение.

Примеры кванторов общности:
• все
• каждый
• всегда
• никогда
• никто
• нисколько
При встрече с квантором общности всегда можно найти пропуск, искажение или обобщение. Кванторы общности обычно свидетельствуют о достижении границ или пределов ментальной карты субъекта. Обычно при проведении анализа следует ставить под сомнение кванторы общности. Чуть не написали «всегда следует ставить под сомнение кванторы общности», но тогда мы бы опровергали самих себя!

Способы выявления требований

• Интервью
• Анкеты
• Семинары

UP

SEP - Software Engineering Process
SDP - Software Development Process


UP базируется на трех аксиомах. Он является:
• управляемым требованиями и риском;
• архитектуро-центричным;
• итеративным и инкрементным.

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

Риск – это еще один управляющий механизм UP, поскольку если не атаковать риски, они будут атаковать вас! Все, кто участвовал в проектах по разработке ПО, без сомнения, согласятся с этим утверждением. UP решает эту проблему, заложив анализ рисков в основу создания ПО.

Подход UP к разработке программных систем заключается в создании и развитии надежной архитектуры системы. Архитектура описывает стратегические аспекты разбиения системы на компоненты, а также взаимодействия и развертывания этих компонентов на аппаратных средствах. Очевидно, что качественно разработанная архитектура обеспечит создание работоспособной системы, а не просто наспех скомпонованного набора кустарного исходного кода.

Итеративный аспект UP означает, что проект разбивается на небольшие подпроекты (итерации), которые обеспечивают функциональность системы по час тям, или инкрементам, приводя к созданию полнофункциональной системы. Другими словами, ПО создается путем пошаговой детализации. Фактически к ключевым рабочим потокам UP, таким как анализ, мы возвращаемся по нескольку раз в течение проекта. этих «мини проектов» и есть итерация.

Каждая итерация включает все элементы обычного проекта по разработке ПО

• Планирование
• Анализ и проектирование
• Построение
• Интеграция и тестирование
• Версия для внутреннего или внешнего использования

Основные рабочие потоки

• определение требований – сбор данных о том, что должна делать система;
• анализ – уточнение и структурирование требований;
• проектирование – реализация требований в архитектуре системы;
• реализация – построение программного обеспечения;
• тестирование – проверяется, отвечает ли реализация предъявляемым требованиям.

Структура UP

Начало

Цели

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

На что обращено внимание

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

Контрольная точка

Уточнение

Цели

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

На что обращено внимание

• определение требований – детализация предметной области системы и требований;
• анализ – выяснение, что необходимо построить;
• проектирование – создание стабильной архитектуры;
• реализация – построение базовой версии архитектуры;
• тестирование – тестирование базовой версии архитектуры.

Контрольная точка

Построение

Цели

Цель фазы Построение – завершить определение требований, анализ и проектирование и развить исполняемую базовую версию архитектуры, созданную в фазе Уточнение, в завершенную систему. Главная проблема Уточнения – поддержание целостности архитектуры системы.

На что обращено внимание

• определение требований – выявление всех неучтенных требований;
• анализ – завершение аналитической модели;
• проектирование – завершение модели проектируемой системы;
• реализация – создание базовой функциональности;
• тестирование – тестирование базовой функциональности.

Контрольная точка

Внедрение

Цели

• исправление дефектов;
• подготовка пользовательских мест под новое программное обеспечение;
• настройка работоспособности программного обеспечения на пользовательских местах;
• изменение программного обеспечения в случае возникновения непредвиденных проблем;
• создание руководств для пользователей и другой документации;
• предоставление пользователям консультаций;
• проведение послепроектного анализа.

На что обращено внимание

• Определение требований – не проводится.
• Анализ – не проводится.
• Проектирование – изменение конструкции в случае выявления проблем при бета тестировании.
• Реализация – настройка ПО под пользовательские места и исправление проблем, не выявленных при бета тестировании.
• Тестирование – бета тестирование и приёмочные испытания на пользовательских местах.

Контрольная точка

Структура UML

• строительные блоки – основные элементы, отношения и диаграммы UML модели;
• общие механизмы – общие UML пути достижения определенных целей;
• архитектура – UML представление архитектуры системы.

Строительные блоки UML

• Сущности – это сами элементы модели.
• Отношения связывают сущности. Отношения определяют, как семантически связаны две или более сущностей.
• Диаграммы – это представления моделей UML. Они показывают наборы сущностей, которые «рассказывают» о программной системе и являются нашим способом визуализации того, что будет делать система (аналитические диаграммы) или как она будет делать это (проектные диаграммы).

Сущности

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

Отношения

Диаграммы

Общие механизмы UML

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

Архитектура

Существует множество способов описания архитектуры, но самым распространенным является «4+1 представление».

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

MDA

MDA - Model Driven Architecture
CIM - computer independent model
PIM - platform independent model
PSM - platform specific model