4) Системный анализ

Системный анализ
Лекция 4
С сего начать?
Выяснить
какие задачи должна решать программная система,
какими свойствами она должна обладать
«Проблема заказчика»
Заказчик
формулирует задачу на своем профессиональном языке;
имеет достаточно расплывчатое представление о функциях будущей программной системы;
не способен оценить возможности реализации тех или иных своих пожеланий

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

Анализ предметной области – это первый шаг этапа системного анализа, с которого начинается разработка программной системы
Что в результате
В результате
разработчики должны научиться понимать язык, на котором говорят заказчики;
выявить цели их деятельности;
определить набор решаемых ими задач;
определить набор сущностей, с которыми приходится иметь дело при решении этих задач
Схема Захмана
При проведении анализа предметной области бывает полезно воспользоваться схемой, предложенной в 1987 году Джоном Захманом (John A. Zachman)

Основная идея
Деятельность любой организации можно описать, используя ответы на простые вопросы:
«ЧТО делается», или объекты/данные;
«КАК делается», или функции/процессы;
«ГДЕ делается», —инфраструктура;
«КТО делает» — люди;
«КОГДА делается» — графики работ;
«ЗАЧЕМ делается» — стимулы и стратегии

Структура матриц Захмана
Шести вопросам соответствуют шесть столбцов матрицы Захмана
Шесть строк соответствуют шести уровням рассмотрения
Каждая ячейка матрицы задает свой тип описания (модели) свойств предприятия
Модели предметной области
Анализом предметной области занимаются системные аналитики или бизнес-аналитики
Они передают полученные ими знания другим членам проектной команды, сформулировав их на более понятном разработчикам языке
Для передачи этих знаний обычно служит некоторый набор моделей, в виде графических схем и текстовых документов
Системы и модели
Под системой подразумевается совокупность взаимодействующих компонентов и взаимосвязей между ними
Моделью M некоторой системы S называется информационный объект, который может быть использован для получения ответов на некоторый круг вопросов относительно S

Цель моделирования
Получение ответов на эту совокупность вопросов является целью моделирования
Цель моделирования формулируется на самом раннем этапе разработки модели
Объект моделирования
Объектом моделирования является сама система. При этом необходимо точно определить границы системы, чтобы избежать включения в модель посторонних объектов
Точка зрения модели
Круг вопросов, на которые модель должна дать ответ определяется точкой зрения данной модели
Точку зрения лучше всего представлять как место позицию человека или объекта, на которую надо встать, чтобы увидеть систему в действии
Итак
Объект определяет, что включить в модель, а что исключить из нее
Точка зрения диктует автору модели выбор нужной информации об объекте и форму ее подачи
Цель становится критерием окончания моделирования
Результат моделирования
Результатом моделирования является набор взаимоувязанных описаний, начиная с описания самого верхнего уровня системы и кончая подробным описанием деталей или операций

Виды моделей
Формальные модели, используемые на этапе анализа предметной области можно разделить на две группы:
модели, зависящие от подхода к разработке (структурного или объектно-ориентированного)
модели, не зависящие от подхода к разработке
Структурный подход
Сущность структурного подхода заключается в декомпозиции программной системы по функциональному принципу
Структурный подход
При структурном подходе первичным считают проектирование обрабатывающих компонентов - процедур
Проектирование же структур данных выполняют параллельно
Объектный подход
В основе объектного подхода к разработке программного обеспечения лежит объектная декомпозиция, предполагающая объединение процедур и структур данных
процедуры + структуры данных = классы
Объектный подход
При этом разрабатываемое ПО представляется в виде совокупности взаимодействующих объектов, совместно обеспечивающих выполнение требуемых функций

Классификация моделей
Структурное моделирование
Методология структурного моделирования SADT (Structured Analysis And Design Technique) появилась в 1970-х годах и предназначалась для анализа сложных систем различного профиля
Методология SADT
В основных чертах сформулирована Дугласом Т.Россом (компания SofTech) в 1973 году
Применяется на ранних этапах процесса создания системы, часто еще до разработки технического задания (ТЗ)
Достоинства SADT
Может использоваться для проектирования сложных систем любого назначения
Позволяет отражать в модели такие системные характеристики, как управление, обратная связь и исполнители
Имеет развитые процедуры поддержки коллективной работы
Может быть использована на ранних этапах создания системы
Может сочетаться с другими структурными методами проектирования

Основные направления
Существует два основных направления в SADT-моделировании:
функциональные модели выделяют события в системе,
модели данных выделяют объекты (данные) системы, связывающие функции между собой и с их окружением
Стандартизованный вариант методологии создания функциональных моделей – IDEF0
Графическое представление моделей
Наиболее удобной формой представления информации при анализе предметной области являются графические диаграммы различного рода
Проект ICAM
Методология IDEF0 появилась в рамках проекта ICAM (Integrated Computer-Aided Manufacturing), имевшем целью разработку методов анализа процессов взаимодействия в производственных (промышленных) системах и инициированного Министерством обороны США
Цель проекта
Основная цель – обеспечение возможности эффективного обмена информацией между всеми специалистами - участниками программы ICAM (отсюда название методологии IDEF - Icam DEFinition)

Методологии IDEF
В рамках проекта ICAM планировалась разработка семейства методологий моделирования различных аспектов функционирования систем:
IDEF0 – методология создания функциональной модели системы (основана на методе SADT Росса);
Методологии IDEF
IDEF1 – методология создания информационной модели системы (основана на реляционной теории Кодда и использовании ER-диаграмм Чена);
IDEF2 – методология создания динамической модели системы;
IDEF3 – методология создания модели потоков работ (обычно используется вместе с диаграммами потоков данных DFD Data flow diagram)

Синтаксис IDEF0-моделей
Основной формой представления IDEF0-модели является диаграмма
Каждая IDEF0-диаграмма содержит блоки (работы) и дуги (стрелки).
Блоки изображают функции моделируемой системы.
Дуги связывают блоки вместе и отображают взаимодействия и взаимосвязи между ними.
Функциональные блоки на диаграмме изображаются прямоугольниками, а дуги – стрелками
Блоки и стрелки
Основные правила
Каждая сторона функционального блока должна иметь стандартное отношение блок/стрелки:
входные стрелки должны связываться с левой стороной блока;
управляющие стрелки должны связываться с верхней стороной блока;
выходные стрелки должны связываться с правой стороной блока;
Основные правила
стрелки механизма (кроме стрелок вызова) должны указывать вверх и подключаться к нижней стороне блока;
стрелки вызова механизма должны указывать вниз, подключаться к нижней стороне блока, и помечаться ссылкой на вызываемый блок
В метках стрелок не должны использоваться следующие термины: функция, вход, управление, выход, механизм, вызов
Основные правила
Сегменты стрелок, за исключением стрелок вызова, должны помечаться существительным или оборотом существительного
Чтобы связать стрелку с меткой, следует использовать "тильду" (~)
Пример блока и стрелок
Принцип декомпозиции
Функции моделируемой системы могут быть разбиты на составные части и представлены в виде более подробных диаграмм (принцип декомпозиции)
Диаграмма верхнего уровня называется контекстной и обеспечивает наиболее общее описание объекта моделирования
За этой диаграммой следует серия дочерних диаграмм, дающих детальное представление об объекте
Контекстная диаграмма
Декомпозиция диаграмм
Состав IDEF0-модели
IDEF0-модели состоят из трех типов документов:
графических диаграмм,
текста,
глоссария
Эти документы имеют перекрестные ссылки друг на друга
Текстовое сопровождение
Графическая диаграмма – главный компонент IDEF0-модели, содержащий блоки, стрелки, соединения блоков и стрелок и ассоциированные с ними отношения
Текст используется для объяснений и уточнений характеристик, потоков, внутриблочных соединений и т.д.
Глоссарий
Глоссарий предназначен для определения аббревиатур, ключевых слов и фраз, используемых в качестве имен и меток на диаграммах
Глоссарий определяет понятия и термины, которые должны быть одинаково понимаемы всеми участниками разработки и пользователями модели
Семантика стрелок
Стрелки на диаграмме IDEF0 , представляют данные или материальные объекты
Входные и управляющие стрелки блока, соединяющие его с другими блоками или с внешней средой, описывают условия, которые необходимо выполнить для реализации функции, записанной в качестве имени блока
Отношения между блоками
В методологии IDEF0 существует 6 типов отношений между блоками в пределах одной диаграммы:
доминирование;
управление;
выход - вход;
обратная связь по управлению;
обратная связь по входу;
выход – механизм
Отношение доминирования
Определяется взаимным расположением блоков на диаграмме
Предполагается, что блоки, расположенные на диаграмме выше и левее, «доминируют» над блоками, расположенными ниже и правее
Доминирование понимается как влияние, которое один блок оказывает на другие блоки диаграммы
Отношения управления и выход-вход
Отношение управления возникает тогда, когда выход одного блока служит управляющим воздействием на блок с меньшим доминированием
Отношение выход – вход возникает при соединении выхода одного блока с входом другого блока с меньшим доминированием

Обратные связи
Обратная связь по управлению возникает тогда, когда выход некоторого блока создает управляющее воздействие на блок с большим доминированием
Отношение обратной связи по входу имеет место тогда, когда выход блока становиться входом другого блока с большим доминированием
Отношение «выход-механизм»
Обратная связь по управлению и обратная связь по входу представляют итерацию (выход функции влияет на будущее выполнение других функций с большим доминированием)
Связи «выход – механизм» отражают ситуацию, при которой выход одной функции становиться средством достижения цели для другой
Отношение «выход-механизм»
Связи «выход – механизм» возникают при отображении в модели процедур пополнения и распределения ресурсов, создания или подготовки средств для выполнения функций системы

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

Исполнение сценария
Исполнение каждого сценария сопровождается соответствующим документооборотом, который состоит из двух основных потоков:
документов, определяющих структуру и последовательность процесса (технологических указаний, описаний стандартов и т.д.),
документов, отображающих ход его выполнения (результатов тестов и экспертиз, отчетов о браке, и т.д.).
Синтаксические элементы
Функциональные элементы или элементы поведения (Unit of Behavior, UOB), обозначающие событие, стадию процесса или принятие решения – изображаются прямоугольниками
Стрелки или линии являются отображением перемещения объекта между UOB-блоками в ходе процесса
Перекрестки (Junction) используются для отображения логики взаимодействия стрелок (потоков) при слиянии и разветвлении
Типы перекрестков
Пример IDEF0-модели
Пример IDEF0-модели
Пример IDEF0-модели
Пример IDEF0-модели
Пример IDEF0-модели
Пример IDEF0-модели
Пример IDEF3-модели
Диаграммы потоков данных
Эти диаграммы (Data flow diagramming, DFD) хорошо дополняют функциональные диаграммы модели, описывая потоки данных
Позволяют проследить, каким образом происходит обмен информацией как внутри системы между бизнес-функциями, так и системы в целом с внешней информационной средой
Используются для описания документооборота, обработки информации
Преимущества DFD-диаграмм
DFD-диаграммы создавались как средство проектирования программных систем, тогда как IDEF0 - как средство проектирования систем вообще
DFD имеют более богатый набор элементов, адекватно отражающих специфику программных систем (например, хранилища данных являются прообразами файлов или баз данных).
Преимущества DFD-диаграмм
С помощью DFD-диаграмм требования к проектируемой ИС разбиваются на функциональные компоненты (процессы) и представляются в виде сети, связанной потоками данных
Главная цель декомпозиции DFD-функций - продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами
Синтаксические элементы
На DFD-диаграммах могут присутствовать следующие элементы:
функциональные блоки (процессы);
стрелки (данные);
хранилища данных;
внешние ссылки
Нотации для DFD
Используются несколько систем обозначений для перечисленных элементов
Наиболее известны
нотация Йордана-ДеМарко (Yourdon-DeMarco)
нотация Гэйна-Сарсона (Gane-Sarson)
Обе предложены в 1979 году
Пример нотации Йордана-ДеМарко
Пример нотации Гейна-Сарсона
Детализация процесса "Управление персоналом"
Объектное моделирование
Методы объектного анализа и моделирования используются при разработке объектно-ориентированного программного обеспечения
Графические средства
В качестве графических моделей в этих методах применяются:
диаграммы вариантов использования (вместо диаграмм потоков данных)
диаграммы классов (вместо диаграмм сущностей и связей)
Варианты использования
Вариантом использования (use case) или прецедентом называют некоторый сценарий действий системы, обеспечивающий значимый для ее пользователей результат
Это сценарий, неоднократно возникающий во время работы системы и имеющий определенные условия начала и завершения
Диаграммы прецедентов
Диаграммы вариантов использования менее информативны по сравнению с диаграммами потоков данных
процессы + хранилища данных = варианты использования
Кроме того, на них указываются связи между прецедентами и действующими лицами – аналогами внешних сущностей
Пример
Отношение расширения
Вариант использования A расширяет (extends) другой вариант использования B, если в ходе сценария работы A при определенных условиях надо включить полный сценарий работы B
Сценарий «Удаление товара» расширяет сценарий «Поиск товара»
Отношение включения
Вариант использования A включает (includes, или использует, uses) вариант использования B, если A всегда в некоторый момент включает полностью сценарий работы B
Сценарий «Заказ товара» включает сценарий «Выбор способа оплаты»
Описание прецедента
Должно содержать:
имя, говорящее о назначении прецедента
несколько предложений с его описанием
частота возникновения прецедента
условия его запуска – предусловия
условия, которые должны быть выполнены после его успешного завершения – постусловия
основной сценарий работы

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

Этапы определения потребностей
Выделение небольшого числа основных проблем
Анализ каждой из основных проблем:
причины возникновения
степень влияния на другие проблемы
Поиск наиболее существенных проблем, влекущих появление остальных
Определение ограничений на возможные решения
Область применения
После выделения основных потребностей нужно решить вопрос об области ответственности будущей системы, т.е. определить, какие из потребностей надо пытаться удовлетворить в ее рамках, а какие — нет

Функции системы
На основе выделенных потребностей пользователей формулируются возможные функции будущей системы
Формулировка функций должна быть достаточно короткой, ясной для пользователей, без лишних деталей
Функции системы
Например:
Все данные о сделках и клиентах будут сохраняться в базе данных
Расписание проведения ремонтных работ будет строиться автоматически
Система будет поддерживать до 10000 одновременно работающих пользователей
Функции системы
Предлагая те или иные функции, нужно уметь оценивать их влияние на структуру и деятельность организаций, в рамках которых будет использоваться ПО:
«as-is» ? «to-be»
Это можно сделать, имея полученные при анализе предметной области модели их текущей деятельности
Системный анализ
Системная спецификация
Результаты системного анализа представляются в виде системной спецификации, в которой должны быть описаны:
функции разрабатываемой системы,
ее характеристики,
ограничения разработки,
состав входной и выходной информации
Требования к ПО
Системная спецификация служит исходным документом при проведении анализа требований к программной системе
Требования детализируют способ реализации запланированных функций
Анализ требований
Имеет своей целью:
определить функции и характеристики программного продукта
обозначить его интерфейс с другими системными элементами
определить проектные ограничения программного продукта
выбрать формы представления информации в ходе проектирования
построить модели режимов функционирования продукта

Спецификация требований
Результаты анализа требований сводятся в спецификацию требований к программному продукту