- •«Белгородский государственный национальный исследовательский университет»
- •Теория систем и системный анализ
- •Предисловие
- •Содержание
- •Тема 1. Системные исследования 9
- •Тема 2. Моделирование и анализ систем. Основные подходы 18
- •Тема 3. Технологии системного моделирования 50
- •Тема 4. Технология объектного моделирования и анализа 125
- •4.2. Требования к объектному моделированию бизнес-систем 151
- •4.3. Case-инструментарий объектного моделирования и анализа 170
- •Тема 5. Технология системно-объектного моделирования и анализа 182
- •Тема 6. Графический язык моделирования бизнес-процессов bpmn. 231
- •Тема 1. Системные исследования
- •1.1. Структура самостоятельного научного направления
- •1.2. Структура системных исследований
- •1.3. Эволюция системного подхода
- •Вопросы для повторения
- •Резюме по теме
- •Тема 2. Моделирование и анализ систем. Основные подходы
- •2.1. Традиционный системный подход
- •2.1.1. Особенности и проблемы традиционного системного подхода и системного анализа
- •2.1.2. Причины существования проблем традиционного системного подхода и системного анализа
- •2.2. Объектно-ориентированный подход
- •2.2.1. Особенности объектно-ориентированного подхода
- •2.2.2. Необходимость интеграции объектного и системного подходов
- •2.3. Системология – системный подход ноосферного этапа развития науки
- •2.3.1. Основные понятия
- •2.3.2. Системология – язык теории организации, логистики и инжиниринга бизнеса
- •2.3.3. Системологический и объектно-ориентированный подход
- •Вопросы для повторения
- •Резюме по теме
- •Тема 3. Технологии системного моделирования
- •3.1. Технология системно-структурного моделирования и анализа «3-View Modeling»
- •3.1.1. Диаграммы потоков данных: нормативная система; построение модели; словарь данных; спецификация процесса
- •Нормативная система
- •Построение модели
- •Словарь данных
- •3 {Болт} 7 – от 3 до 7 итераций
- •1 {Болт} – 1 и более итераций
- •Спецификация процесса
- •3.1.2. Диаграммы «сущность-связь»: нотация Чена; нотация Баркера; построение модели
- •Нотация Чена
- •Нотация Баркера
- •Построение модели
- •3.1.3. Диаграммы переходов состояний
- •3.2. Стандарты системного моделирования и анализа серии «Icam deFinition»
- •3.2.1. Стандарт функционального моделирования idef0
- •3.2.2. Стандарт информационного моделирования idef1
- •3.2.3. Стандарт моделирования баз данных idef1x
- •3.2.4. Стандарт моделирования сценариев idef3.
- •3.2.5. Стандарт моделирования онтологий idef5
- •3.3. Case-инструментарий системного моделирования и анализа
- •3.3.1. Назначение и возможности «AllFusion Process Modeler/bPwin»
- •3.3.2. Особенности «bPwin»
- •3.3.3. Недостатки инструментария системного моделирования
- •Вопросы для повторения
- •Резюме по теме
- •Тема 4. Технология объектного моделирования и анализа
- •4.1.1. Сущности: структурные; поведенческие; группирующие; аннотационные
- •Структурные сущности
- •Поведенческие сущности
- •Группирующие сущности
- •Аннотационные сущности
- •4.1.2. Отношения
- •4.1.3. Диаграммы
- •4.1.4. Процесс объектно-ориентированного моделирования/проектирования: начальная фаза; исследование; построение; внедрение; дополнительные средства
- •Начальная фаза проекта (Inception)
- •Исследование (Elaboration)
- •Построение (Construction)
- •Внедрение (Transition)
- •Дополнительные средства
- •4.2. Требования к объектному моделированию бизнес-систем
- •4.2.1. Внешняя модель бизнес-системы
- •4.2.2. Внутренняя модель бизнес-системы
- •4.2.3. Пример uml-модели бизнес-системы
- •4.2.4. Пример модели информационного обеспечения бизнеса
- •4.3. Case-инструментарий объектного моделирования и анализа
- •4.3.1. Назначение и возможности «ibm Rational Software Architect»
- •4.3.2. Интерфейс «ibm Rational Software Architect»
- •4.3.3. Представление модели в «ibm Rational Software Architect»: представление вариантов использования; логическое представление; представление компонент; представление размещения
- •Представление вариантов использования
- •Логическое представление
- •Представление компонент
- •Представление размещения
- •4.3.4. Недостатки инструментария объектного моделирования
- •Вопросы для повторения
- •Резюме по теме
- •Тема 5. Технология системно-объектного моделирования и анализа
- •5.1. Методология системно-объектного моделирования и анализа
- •5.1.1. Системологический подход «Узел-Функция-Объект»
- •5.1.2. Адаптивная нормативная система уфо-анализа
- •5.1.3. Классификация бизнес-систем
- •5.2. Процедура системно-объектного моделирования и анализа
- •5.2.1 Алгоритм уфо-анализа.
- •5.2.2. Примеры уфо-моделей.
- •5.3. Case-инструментарий системно-объектного моделирования и анализа
- •5.3.1. Назначение и возможности «ufo-toolkit»
- •5.3.2. Особенности функционирования «ufo-toolkit»
- •5.3.3 Технология представление моделей в «ufo-toolkit»
- •Торгово-закупочная деятельность
- •Вопросы для повторения
- •Резюме по теме
- •Тема 6. Графический язык моделирования бизнес-процессов bpmn.
- •6.1. Назначение и область применения.
- •6.2. Диаграммы бизнес-процессов (bpd).
- •6.2.1. Элементы потока.
- •6.2.2. Соединяющие элементы.
- •6.2.3. Зоны ответственности и артефакты.
- •6.2.4. Правила соединения Элементов потока.
- •6.3. Соотношение bpmn, xpdl, bpel, bpml.
- •6.3.1. Стандарты sgml и xml
- •6.3.5. Соотношение языков.
- •6.4. Case-инструментарий бизнес-моделирования в нотации bpmn.
- •6.4.1. Назначение и возможности.
- •6.4.2. Особенности функционирования и интерфейса.
- •6.4.3. Примеры моделей в нотации bpmn.
- •6.4.4. Недостатки моделирования в нотации bpmn.
- •Вопросы для повторения
- •Резюме по теме
- •Вместо заключения
- •Представление dfd-диаграммы с помощью уфо-модели
- •Представление idef0-диаграммы с помощью уфо-модели.
- •Представление bpmn-диаграммы с помощью уфо-модели.
- •Глоссарий
- •Список литературы
Построение (Construction)
На стадии построения разработка системы выполняется путем серии итераций. Каждая итерация является своего рода мини-проектом. На каждой итерации для конкретных вариантов использования выполняются анализ, проектирование, кодирование, тестирование и интеграция. Итерация завершается демонстрацией результатов пользователям и выполнением системных тестов с целью контроля корректности реализации вариантов использования.
Причиной такого построения процесса разработки является необходимость снижение степени риска. Причиной появления риска является откладывание решения сложных проблем на самый конец проекта. При итеративной разработке на каждой итерации выполняется весь процесс, что позволяет оперативно справляться со всеми возникающими проблемами.
Главная идея итеративной разработки – поставить весь процесс разработки на регулярную основу с тем, чтобы команда разработчиков смогла получить конечный продукт. Однако есть некоторые вещи, которые не следует выполнять слишком рано, например оптимизация.
Оптимизация снижает прозрачность и расширяемость системы, однако повышает ее производительность. В этой ситуации необходимо принять компромиссное решение – в конце концов, система должна быть достаточно производительной, чтобы удовлетворять пользовательским требованиям. Слишком ранняя оптимизация затруднит последующую разработку, поэтому ее следует выполнять в последнюю очередь.
Рекомендуется очень серьезно относиться к тестированию. Объем написанного разработчиком кода тестов должен быть по меньшей мере равен объему кода самого программного продукта. Тестирование должно быть непрерывным процессом. Не рекомендуется писать программный код до тех пор, пока не известно, как его тестировать. Как только написан код, сразу же пишите для него тесты. Пока все тесты не отработают, нельзя утверждать, что написание кода завершено [81].
Однажды написанный тестовый код должен использоваться постоянно. Тестовый код должен быть организован таким образом, чтобы можно было запускать каждый тест с помощью простой командной строки или нажатия кнопки на графическом экране. Результатом выполнения теста должно быть «ОК» или список ошибок. Кроме того, все тесты должны проверять свои собственные результаты. Ничто не приводит к столь неоправданной трате времени, как получение на выходе теста числового значения, с интерпретацией которого нужно разбираться отдельно.
Рекомендуется разделить все тесты на автономные и системные. Автономные тесты рекомендуется писать самим разработчикам. Они должны быть организованы в пакеты и тестировать интерфейсы всех классов. Системные тесты рекомендуется разрабатывать отдельной небольшой командой, которая занимается исключительно тестированием. Такая команда должна рассматривать всю систему как черный ящик и находить особое удовольствие в поиске ошибок.
Итерации на стадии конструирования являются одновременно инкрементными (наращиваемыми) и повторяющимися.
Итерации являются инкрементными в соответствии с той функцией, которую они выполняют. Каждая итерация добавляет очередные конструкции к вариантам использования, реализованным во время предыдущих итераций.
Они являются повторяющимися по отношению к разрабатываемому коду. На каждой итерации некоторая часть существующего кода заново переписывается с целью сделать его более гибким. В этом процессе очень часто используется метод реорганизации (см. далее). Рекомендуется внимательно наблюдать за тем, какой объем кода оказывается ненужным после каждой итерации. Если каждый раз выбрасывается менее 10% предыдущего кода, то это должно вызывать подозрение.
Процесс интеграции должен быть непрерывным. В конце каждой итерации должна выполняться полная интеграция. Тем не менее, интеграция может и должна выполняться еще чаще. Разработчику рекомендуется интегрировать приложения после выполнения любой сколько-нибудь значительной части работы. Во время каждой интеграции должен выполняться полный набор автономных тестов, чтобы обеспечить таким образом полное регрессионное тестирование.
В рамках каждой итерации рекомендуется заниматься более детальным планированием. Самой важной частью любого плана являются меры, которые нужно предпринимать, если что-то происходит не так, как было запланировано. Главная особенность итеративной разработки заключается в том, что она жестко ограничена временными рамками, и сдвигать сроки недопустимо. Исключением может быть перенос реализации каких-либо вариантов использования на более позднюю итерацию по соглашению с заказчиком. Смысл таких ограничений – поддерживать строгую дисциплину разработки и не допускать переноса сроков. Если, например, слишком много вариантов использования перенесено на более поздний срок, то пора корректировать план, пересмотрев при этом оценку трудоемкости реализации вариантов использования. На этой стадии разработчики должны иметь более глубокое представление о такой оценке.
На стадии построения полезными являются все методы UML.
Концептуальная диаграмма классов полезна для приблизительного описания некоторых понятий варианта использования и определения того, как эти понятия согласуются с уже разработанным ПО, а также более детального отображения классов. Если вариант использования содержит значительные элементы потоков работ, то рекомендуется обратиться к их представлению на диаграмме деятельности.
Преимущество этих методов на данной стадии заключается в том, что они могут быть использованы в сотрудничестве с экспертом предметной области. Анализ становится осмысленным только при непосредственном участии эксперта предметной области.
Диаграммы взаимодействия полезны для представления взаимодействия классов, в котором выражается реализация варианта использования. Если поведение класса в течение его жизненного цикла достаточно сложно описать, рекомендуется использовать диаграмму состояния.
Рекомендуется ограничить документацию теми случаями, когда она действительно помогает. Если обнаруживается, что от документации нет никакого толку, это верный признак, что что-то идет не так. Документация в нормальном случае должна содержать три основных элемента:
одну или две страницы с описанием нескольких классов, присутствующих на диаграмме классов;
несколько диаграмм взаимодействия, показывающих, как классы взаимодействуют между собой;
небольшое текстовое описание, связывающее диаграммы воедино.
Важнейшие цели:
Завершить анализ, проектирование, кодирование и тестирование всех вариантов использования (функциональных возможностей).
Создать готовый к использованию продукт.
Добиться надлежащего качества и полезности версий.
Оценить готовность к развертыванию.
Уменьшить затраты на разработку, оптимизируя продукт и используемые ресурсы.
Важнейшие действия:
Управление ресурсами.
Контроль качества и оптимизация.
Разработка компонент, автономное тестирование.
Интеграция и системное тестирование.
Определение готовности ПО с учетом критериев его приемки.