МИНИCTEPCTBO ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ Федеральное государственное автономное образовательное учреждение высшего образования «СЕВЕРО-КАВКАЗСКИЙ ФЕДЕРАЛЬНЫЙ УНИВЕРСИТЕТ» Институт сервиса, туризма и дизайна (филиал) СКФУ в г. Пятигорске МЕТОДИЧЕСКИЕ УКАЗАНИЯ ПО ВЫПОЛНЕНИЮ ЛАБОРАТОРНЫХ РАБОТ ПО ДИСЦИПЛИНЕ РАЗРАБОТКА ПРОГРАММНЫХ ПРИЛОЖЕНИЙ Направление подготовки Направленность (профиль) 09.03.02 Информационные системы и технологии Информационные системы и технологии Квалификация выпускника Бакалавр РАЗРАБОТАНО: Доцент кафедры ИБСиТ __________________ Мартиросян К.В. «__» _______________ 2018 г. Пятигорск, 2018 СОДЕРЖАНИЕ Введение .........................................................................................................................................3 1. Цель и задачи изучения дисциплины ......................................................................................4 2. Оборудование и материалы ......................................................................................................4 3. Наименование Лабораторных работ ........................................................................................4 4. Содержание лабораторных работ ............................................................................................6 Лабораторная работа 1. Технологии управления жизненным циклом программных приложений. Техническое задание на разработку программного приложения. .................6 Лабораторная работа 2. Архитектура программного приложения .....................................17 Лабораторная работа 3. Функциональное моделирование бизнес-процессов предметной области программных приложений .......................................................................................24 Лабораторная работа 4. Объектно-ориентированное моделирование функциональных компонентов программных приложений ..............................................................................29 Лабораторная работа 5. Проектирование базы данных информационной системы .........48 Лабораторная работа 6. Проектирование программного интерфейса информационной системы .....................................................................................................................................64 Лабораторная работа 7. Средства управления распределенными системами ...................74 Лабораторная работа 8. Разработка метрик качества программных приложений ............87 Лабораторная работа 9. Стратегии управления рисками применительно к проектам программных приложений ......................................................................................................95 5. Учебно-методическое и информационное обеспечение дисциплины .............................102 5.1. Перечень основной и дополнительной литературы, необходимой для освоения дисциплины ............................................................................................................................102 5.2. Перечень учебно-методического обеспечения самостоятельной работы обучающихся по дисциплине ...............................................................................................102 5.3. Перечень ресурсов информационно-телекоммуникационной сети Интернет, необходимых для освоения дисциплины ............................................................................102 ВВЕДЕНИЕ В методических указаниях содержатся материалы, необходимые для самостоятельной подготовки студентов к выполнению лабораторных работ. В описание лабораторных работ включены цель работы, порядок ее выполнения, рассмотрены теоретические вопросы, связанные с реализацией поставленных задач, приведена необходимая литература. Методические указания посвящены курсу «Разработка программных приложений». Процесс разработки функциональных подсистем представляет собой комплекс технических и программных задач с высокой степенью информационных обменов (связей) между задачами. При этом под задачей будем понимать некоторый процесс обработки информации с четко определенным множеством входной и выходной информации (например, начисление сдельной заработной платы, учет прихода материалов, оформление заказа на закупку и т.д.). Состав функциональных подсистем во многом определяется особенностями информационной системы, ее отраслевой принадлежностью, формой собственности, размером, характером деятельности предприятия. Функциональные подсистемы ИС могут строиться по различным принципам: предметному; функциональному; проблемному; смешанному (предметнофункциональному). Так, с учетом предметной направленности использования ЭИС в хозяйственных процессах промышленного предприятия выделяют подсистемы, соответствующие управлению отдельными ресурсами: управление сбытом готовой продукции; управление производством; управление материально-техническим снабжением; управление финансами; управление персоналом. При этом в подсистемах рассматривается решение задач на всех уровнях управления, обеспечивая интеграцию информационных потоков по вертикали. Для реализации функций управления выделяют следующие подсистемы: планирование; регулирование (оперативное управление); учет; анализ. Примером применения подхода к выделению функциональных подсистем на основе функций управления может служить многопользовательский сетевой комплекс (МСК) полной автоматизации, который включает 4 контура автоматизации в соответствии с функциями управления: контур планирования; контур оперативного управления; контур учета и контроля; контур анализа. Проблемный принцип формирования подсистем отражает необходимость гибкого и оперативного принятия управленческих решений по отдельным проблемам в рамках СППР, например решение задач бизнес-планирования, управления проектами. Такие подсистемы могут реализовываться в виде локальных информационных систем, импортирующих данные из корпоративной информационной системы (например, система бизнес-планирования на основе ППП Project-Expert), или в виде специальных подсистем в рамках корпоративной ЭИС (например, информационной системы руководителя). На практике чаще всего применяется смешанный предметнофункциональный подход, согласно которому построение функциональной структуры ИС это разделение ее на подсистемы по характеру деятельности, которое должно соответствовать структуре объекта и системе управления, а также характеру выполняемых функций управления. Используя этот подход, можно выделить следующий типовой набор функциональных подсистем в общей структуре ИС предприятия. Подсистемы, построенные по функциональному принципу, охватывают все виды хозяйственной деятельности предприятия (производство, снабжение, сбыт, персонал, финансы). Подсистемы, построенные по предметному принципу, относятся в основном к оперативному уровню управления ресурсами. 1. ЦЕЛЬ И ЗАДАЧИ ИЗУЧЕНИЯ ДИСЦИПЛИНЫ Целью освоения дисциплины «Разработка программных приложений» является формирование набора профессиональных компетенций будущего бакалавра по направлению подготовки 09.03.02 «Информационные системы и технологии». Задачи освоения дисциплины: изучение основных понятий разработки программных приложений, освоение технологий разработки программных приложений, получение навыков работы с инструментами разработки программных приложений. 2. ОБОРУДОВАНИЕ И МАТЕРИАЛЫ Аппаратные средства: персональный компьютер; Программные средства: ОС MS Windows; MS Visual Studio, MS Office. Учебный класс оснащен IBM-совместимыми компьютерами, объединенными в локальную сеть. Локальная сеть учебного класса имеет постоянный доступ к сети Internet по выделенной линии. Для проведения лабораторных работ необходимо следующее программное обеспечение: операционная система MS Windows, пакет офисных программ MS Office, пакет MS Visual Studio. 3. НАИМЕНОВАНИЕ ЛАБОРАТОРНЫХ РАБОТ № те м ы Наименование тем дисциплины, их краткое содержание Обьем часов Интеракт иная форма проведен ия Мастеркласс 7 семестр Раздел 1. Технологии разработки программных приложений 1 Тема 1. Технологии управления жизненным циклом программных приложений. Техническое задание на разработку программного приложения. Лабораторная работа 1. Технологии управления жизненным циклом программных приложений. Техническое задание на разработку программного приложения. Содержание: Методы и средства разработки программных приложений. Разработка концепции программного приложения. Техническое задание на разработку программного приложения. 4,5 3 Тема 3. Архитектура программного приложения Лабораторная работа 2. Архитектура программного приложения Содержание: Архитектура программного приложения. Разработка функциональных и технологических требований к программному приложению. 4,5 5 7 Тема 5. Функциональное моделирование бизнес-процессов предметной области программных приложений Лабораторная работа 3. Функциональное моделирование бизнеспроцессов предметной области программных приложений Содержание: Функциональное моделирование бизнес-процессов предметной области программных приложений. Реинжиниринг бизнес-процессов предметной области. Определение направления автоматизации бизнес-процессов предметной области программных приложений. Тема 7. Объектно-ориентированное моделирование функциональных компонентов программных приложений Лабораторная работа 4. Объектно-ориентированное моделирование функциональных компонентов программных приложений Содержание: Объектно-ориентированное моделирование функциональных компонентов программных приложений. Диаграмма вариантов использования; диаграммы взаимодействия для каждого варианта использования; диаграмма классов, диаграмма размещения функциональных компонентов программных приложений. Раздел 2. Инструментальное обеспечение технологий разработки программных приложений 9 Тема 9. Разработка информационного обеспечения программного приложения Лабораторная работа 5. Разработка информационного обеспечения программного приложения. Содержание: Разработка информационного обеспечения программных приложений. Инфологическое моделирование базы данных информационной системы. 11 Тема 11. Разработка интерфейса программного приложения. Лабораторная работа 6. Разработка интерфейса программного приложения. Содержание: Разработка интерфейса программного приложения. Разработка технологий ввода-вывода данных программного приложения. Разработка технологий взаимодействия базы данных и программного приложения. Разработка структурной схемы модулей программного приложения. 13 Тема 13. Средства управления распределенными системами Лабораторная работа 7. Средства управления распределенными системами Содержание: Межсистемные интерфейсы и драйверы. интерфейсы в распределенных системах. Средства управления распределенными системами. Открытые системы OSI. Возможность взаимодействия программных продуктов от различных производителей. Проектирование распределенных программных приложений. Разработка критериев тестирования распределенных программных приложений. 15 Тема 15. Разработка метрик качества программных приложений. Лабораторная работа 8. Разработка критериев качества программных приложений. Содержание: Разработка метрик качества программных приложений. Методы обеспечения качества информационных 4,5 4,5 4,5 4,5 4,5 4,5 Мастеркласс 17 систем. Метрики качества программного обеспечения. Стандартный метод оценки значений показателей качества. Управление качеством ПО. Верификация, валидация и аудит информационных систем. Стандарты верификации, валидации и аудита информационных систем. Задачи и методы исследования надежности информационных систем. Тема 17. Стратегии управления рисками применительно к проектам программных приложений Лабораторная работа 9. Стратегии управления рисками при проектировании программных приложений Содержание: Стратегии управления рисками. Схема процесса управления рисками. Определение рисков. Категории рисков. Анализ рисков. Планирование рисков. Стратегии управления рисками. Три категории стратегий управления рисками. Мониторинг рисков. Итого 4,5 40,5 4. СОДЕРЖАНИЕ ЛАБОРАТОРНЫХ РАБОТ Лабораторная работа 1. Технологии управления жизненным циклом программных приложений. Техническое задание на разработку программного приложения. Цель работы: составить и проанализировать требования к программному приложению; разработать техническое задание на проектирование информационной системы. Основы теории Проблемы, которые приходится решать специалистам в процессе создания программного обеспечения, очень сложны. Природа этих проблем не всегда ясна, особенно если разрабатываемая программная система инновационная. В частности, трудно чѐтко описать те действия, которые должна выполнять система. Описание функциональных возможностей и ограничений, накладываемых на систему, называется требованиями к этой системе, а сам процесс формирования, анализа, документирования и проверки этих функциональных возможностей и ограничений – разработкой требований. Требования подразделяются на пользовательские и системные. Пользовательские требования – это описание на естественном языке (плюс поясняющие диаграммы) функций, выполняемых системой, и ограничений, накладываемых на неѐ. Системные требования – это описание особенностей системы (архитектура системы, требования к параметрам оборудования и т.д.), необходимых для эффективной реализации требований пользователя. Разработка требований Разработка требований — это процесс, включающий мероприятия, необходимые для создания и утверждения документа, содержащего спецификацию системных требований. Различают четыре основных этапа процесса разработки требований: - анализ технической осуществимости создания системы, - формирование и анализ требований, - специфицирование требований и создание соответствующей документации, - аттестация этих требований. На рисунке 1.1 показаны взаимосвязи между этими этапами и результаты, сопровождающие каждый этап процесса разработки системных требований. Но поскольку в процессе разработки системы в силу разнообразных причин требования могут меняться, управление требованиями, т.е. процесс управления изменениями системных требований, является необходимой составной частью деятельности по их разработке. Формирование и анализ требований Следующим этапом процесса разработки требований является формирование (определение) и анализ требований. Рисунок 1.1 - Процесс разработки требований Обобщенная модель процесса формирования и анализа требований показана на рисунке 1.2. Каждая организация использует собственный вариант этой модели, зависящий от ―местных факторов‖: опыта работы коллектива разработчиков, типа разрабатываемой системы, используемых стандартов и т.д. Рисунок 1.2 - Процесс формирования и анализа требований Процесс формирования и анализа требований проходит через ряд этапов. 1. Анализ предметной области. Аналитики должны изучить предметную область, где будет эксплуатироваться система. 2. Сбор требований. Это процесс взаимодействия с лицами, формирующими требования. Во время этого процесса продолжается анализ предметной области. 3. Классификация требований. На этом этапе бесформенный набор требований преобразуется в логически связанные группы требований. 4. Разрешение противоречий. Без сомнения, требования многочисленных лиц, занятых в процессе формирования требований, будут противоречивыми. На этом этапе определяются и разрешаются противоречия различного рода. 5. Назначение приоритетов. В любом наборе требований одни из них будут более важны, чем другие. На этом этапе совместно с лицами, формирующими требования, определяются наиболее важные требования. 6. Проверка требований. На этом этапе определяется их полнота, последовательность и непротиворечивость. Процесс формирования и анализа требований циклический, с обратной связью от одного этапа к другому. Цикл начинается с анализа предметной области и заканчивается проверкой требований. Понимание требований предметной области увеличивается в каждом цикле процесса формирования требований. Рассмотрим три основных подхода к формированию требований: метод, основанный на множестве опорных точек зрения, сценарии и этнографический метод. Опорные точки зрения Подход с использованием различных опорных точек зрения к разработке требований признает различные (опорные) точки зрения на проблему и использует их в качестве основы построения и организации как процесса формирования требований, так и непосредственно самих требований. Различные методы предлагают разные трактовки выражения "точка зрения". Точки зрения можно трактовать следующим образом. 1. Как источник информации о системных данных. В этом случае на основе опорных точек зрения строится модель создания и использования данных в системе. В процессе формирования требований отбираются все такие точки зрения ( и на их основе определяются данные), которые будут созданы или использованы при работе системы, а также способы обработки этих данных. 2. Как структура представлений. В этом случае точки зрения рассматриваются как особая часть модели системы. Например, на основе различных точек зрения могут разрабатываться модели "сущность-связь", модели конечного автомата и т.д. 3. Как получатели системных сервисов. В этом случае точки зрения являются внешними (относительно системы) получателями системных сервисов. Точки зрения помогают определить данные, необходимые для выполнения системных сервисов или их управления. Наиболее эффективным подходом к анализу таких систем является использование внешних опорных точек зрения. На основе этого подхода разработан метод VORD (Viewpoint-Oriented Requirements Definition — определение требований на основе точек зрения) для формирования и анализа требований. Основные этапы метода VORD показаны на рисунке 1.3. 1. Идентификация точек зрения, получающих системные сервисы, и идентификация сервисов, соответствующих каждой точке зрения. 2. Структурирование точек зрения — создание иерархии сгруппированных точек зрения. Общесистемные сервисы предоставляются более высоким уровням иерархии и наследуются точками зрения низшего уровня. 3. Документирование опорных точек зрения, которое заключается в точном описании идентифицированных точек зрения и сервисов. 4. Отображение системы точек зрения, которая показывает системные объекты, определенные на основе информации, заключенной в опорных точках зрения. Рисунок 1.3 - Метод VORD Пример. Рассмотрим использование метода VORD на первых трех шагах анализа требований для системы системы поддержки заказа и учета товаров в бакалейной лавке. В бакалейной лавке для каждого товара фиксируется место хранения (определенная полка), количество товара и его поставщик. Система поддержки заказа и учета товаров должна обеспечивать добавление информации о новом товаре, изменение или удаление информации об имеющемся товаре, хранение (добавление, изменение и удаление) информации о поставщиках, включающей в себя название фирмы, ее адрес и телефон. При помощи системы составляются заказы поставщикам. Каждый заказ может содержать несколько позиций, в каждой позиции указываются наименование товара и его количество в заказе. Система по требованию пользователя формирует и выдает на печать следующую справочную информацию: - список всех товаров; - список товаров, имеющихся в наличии; - список товаров, количество которых необходимо пополнить; - список товаров, поставляемых данным поставщиком. Первым шагом в формировании требований является идентификация опорных точек зрения. Во всех методах формирования требований, основанных на использовании точек зрения, начальная идентификация является наиболее трудной задачей. Один из подходов к идентификации точек зрения — метод "мозговой атаки", когда определяются потенциальные системные сервисы и организации, взаимодействующие с системой. Организуется встреча лиц, участвующих в формировании требований, которые предлагают свои точки зрения. Эти точки зрения представляются в виде диаграммы, состоящей из ряда круговых областей, отображающих возможные точки зрения (рис. 4). Во время "мозговой атаки" необходимо идентифицировать потенциальные опорные точки зрения, системные сервисы, входные данные, нефункциональные требования, управляющие события и исключительные ситуации. Следующей стадией процесса формирования требований будет идентификация опорных точек зрения (на рисунке 1.4 показаны в виде темных круговых областей) и сервисов (показаны в виде затененных областей). Сервисы должны соответствовать опорным точкам зрения. Но могут быть сервисы, которые не поставлены им в соответствие. Это означает, что на начальном этапе "мозговой атаки" некоторые опорные точки зрения не были идентифицированы. Рисунок 1.4 - Диаграмма идентификации точек зрения В таблице 1.1 показано распределение сервисов для некоторых идентифицированных на рисунке 1.4 точек зрения. Один и тот же сервис может быть соотнесен с несколькими точками зрения. Таблица 1.1 - Сервисы, соотнесенные с точками зрения клиент покупател постоянн товар поставщи ь ый к покупател ь Проверка Занесение Получение Прием Занесение наличия в список скидки товара в базу товара клиентов данных Покупка товара Получение чека Заказ товара Занесение покупател я и суммы покупки в базу данных Получение информац ии продавец админист ратор Продажа товара Доступ к базе данных Занесение в базу данных Назначени е цены Печать чека Проверка статистики Доступ к каталогу Переопред еление цены «Покупаем ый» или «непокупа емый» товар Проверка наличия товара Оформлен ие заказа покупател ю Переопред еление цены Оформлен ие заказа Печать заказа Информация, извлеченная из точек зрения, используется для заполнения форм шаблонов точек зрения и организации точек зрения в иерархию наследования. Это позволяет увидеть общие точки зрения и повторно использовать информацию в иерархии наследования. Сервисы, данные и управляющая информация наследуются подмножеством точек зрения. На рисунке 1.5 показана часть иерархии точек зрения для системы поддержки заказа и учета товаров. Рисунок 1.5 - Иерархия точек зрения Аттестация требований Аттестация должна продемонстрировать, что требования действительно определяют ту систему, которую хочет иметь заказчик. Проверка требований важна, так как ошибки в спецификации требований могут привести к переделке системы и большим затратам, если будут обнаружены во время процесса разработки системы или после введения ее в эксплуатацию. Стоимость внесения в систему изменений, необходимых для устранения ошибок в требованиях, намного выше, чем исправление ошибок проектирования или кодирования. Причина в том, что изменение требований обычно влечет за собой значительные изменения в системе, после внесения которых она должна пройти повторное тестирование. Во время процесса аттестации должны быть выполнены различные типы проверок требований. 1. Проверка правильности требований. Пользователь может считать, что система необходима для выполнения некоторых определенных функций. Однако дальнейшие размышления и анализ могут привести к необходимости введения дополнительных или новых функций. Системы предназначены для разных пользователей с различными потребностями, и поэтому набор требований будет представлять собой некоторый компромисс между требованиями пользователей системы. 2. Проверка на непротиворечивость. Спецификация требований не должна содержать противоречий. Это означает, что в требованиях не должно быть противоречащих друг другу ограничений или различных описаний одной и той же системной функции. 3. Проверка на полноту. Спецификация требований должна содержать требования, которые определяют все системные функции и ограничения, налагаемые на систему. 4. Проверка на выполнимость. На основе знания существующих технологий требования должны быть проверены на возможность их реального выполнения. Здесь также проверяются возможности финансирования и график разработки системы. Существует ряд методов аттестации требований, которые можно использовать совместно или каждый в отдельности. 1. Обзор требований. Требования системно анализируются рецензентами. 2. Прототипирование. На этом этапе прототип системы демонстрируется конечным пользователям и заказчику. Они могут экспериментировать с этим прототипом, чтобы убедиться, что он отвечает их потребностям. 3. Генерация тестовых сценариев. В идеале требования должны быть такими, чтобы их реализацию можно было протестировать. Если тесты для требований разрабатываются как часть процесса аттестации, то часто это позволяет обнаружить проблемы в спецификации. Если такие тесты сложно или невозможно разработать, то обычно это означает, что требования трудно выполнить и поэтому необходимо их пересмотреть. 4. Автоматизированный анализ непротиворечивости. Если требования представлены в виде структурных или формальных системных моделей, можно использовать инструментальные CASE-средства для проверки непротиворечивости моделей. Для автоматизированной проверки непротиворечивости необходимо построить базу данных требований и затем проверить все требования в этой базе данных. Анализатор требований готовит отчет обо всех обнаруженных противоречиях. Пользовательские и системные требования На основании полученных моделей строятся пользовательские требования, т.е. как было сказано в начале описание на естественном языке функции, выполняемых системой, и ограничений, накладываемых на неѐ. Пользовательские требования должны описывать внешнее поведение системы, основные функции и сервисы предоставляемые системой, еѐ нефункциональные свойства. Необходимо выделить опорные точки зрения и сгруппировать требования в соответствии с ними. Пользовательские требования можно оформить как простым перечислением, так и используя нотацию вариантов использования. Далее составляются системные требования. Они включают в себя: 1. Требования к архитектуре системы. Например, число и размещение хранилищ и серверов приложений. 2. Требования к параметрам оборудования. Например, частота процессоров серверов и клиентов, объѐм хранилищ, размер оперативной и видео памяти, пропускная способность канала и т.д. 3. Требования к параметрам системы. Например, время отклика на действие пользователя, максимальный размер передаваемого файла, максимальная скорость передачи данных, максимальное число одновременно работающих пользователей и т.д. 4. Требования к программному интерфейсу. 5. Требования к структуре системы. Например, Масштабируемость, распределѐнность, модульность, открытость. - масштабируемость – возможность распространения системы на большое количество машин, не приводящая к потере работоспособности и эффективности, при этом способность системы наращивать свою мощность должна определяться только мощностью соответствующего аппаратного обеспечения. - распределенность - система должна поддерживать распределѐнное хранение данных. - модульность - система должна состоять из отдельных модулей, интегрированных между собой. - открытость - наличие открытых интерфейсов для возможной доработки и интеграции с другими системами. 6. Требования по взаимодействию и интеграции с другими системами. Например, использование общей базы данных, возможность получения данных из баз данных определѐнных систем и т.д. Техническое задание Техническое задание представляет собой документ, в котором сформулированы основные цели разработки, требования к программному продукту, определены сроки и этапы разработки и регламентирован процесс приемо-сдаточных испытаний. В разработке технического задания участвуют как представители заказчика, так и представители исполнителя. В основе этого документа лежат исходные требования заказчика, анализ передовых достижений техники, результаты выполнения научно-исследовательских работ, предпроектных исследований, научного прогнозирования и т. п. Порядок разработки технического задания Разработка технического задания выполняется в следующей последовательности. Прежде всего устанавливают набор выполняемых функций, а также перечень и характеристики исходных данных. Затем определяют перечень результатов, их характеристики и способы представления. Далее уточняют среду функционирования программного обеспечения: конкретную комплектацию и параметры технических средств, версию используемой операционной системы и, возможно, версии и параметры другого установленного программного обеспечения, с которым предстоит взаимодействовать будущему программному продукту. В случаях, когда разрабатываемое программное обеспечение собирает и хранит некоторую информацию или включается в управление каким-либо техническим процессом, необходимо также четко регламентировать действия программы в случае сбоев оборудования и энергоснабжения. 1. Общие положения 1.1. Техническое задание оформляют в соответствии со стандартом ГОСТ 19.20178, ГОСТ 34.602-89. 1.2. Для внесения изменений и дополнений в техническое задние на последующих стадиях разработки программы или программного изделия выпускают дополнение к нему. Согласование и утверждение дополнения к техническому заданию проводят в том же порядке, который установлен для технического задания. 1.3. Техническое задание должно содержать следующие разделы: 1) общие сведения; 2) назначение и цели создания (развития) системы; 3) характеристика объектов автоматизации; 4) требования к системе; 5) состав и содержание работ по созданию системы; 6) порядок контроля и приемки системы; 7) требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие; 8) требования к документированию; 9) источники разработки. В зависимости от особенностей программы или программного изделия допускается уточнять содержание разделов, вводить новые разделы или объединять отдельные из них. При необходимости допускается в техническое задание включать приложения. 2. Содержание разделов 2.1. В разделе «Общие сведения» указывают: 1) полное наименование системы и ее условное обозначение; 2) шифр темы или шифр (номер) договора; 3) наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты; 4) перечень документов, на основании которых создается система, кем и когда утверждены эти документы; 5) плановые сроки начала и окончания работы по созданию системы; 6) сведения об источниках и порядке финансирования работ; 7) порядок оформления и предъявления заказчику результатов работ по созданию системы (ее частей), по изготовлению и наладке отдельных средств (технических, программных, информационных) и программно-технических (программно-методических) комплексов системы. 2.2. Раздел «Назначение и цели создания (развития) системы» состоит из подразделов: 1) назначение системы; 2) цели создания системы. 2.2.1. В подразделе «Назначение системы» указывают вид автоматизируемой деятельности (управление, проектирование и т. п.) и перечень объектов автоматизации (объектов), на которых предполагается ее использовать. 2.2.2. В подразделе «Цели создания системы» приводят наименования и требуемые значения технических, технологических, производственно-экономических или других показателей объекта автоматизации, которые должны быть достигнуты в результате создания ИС, и указывают критерии оценки достижения целей создания системы. 2.3. В разделе «Характеристики объекта автоматизации» приводят: 1) краткие сведения об объекте автоматизации или ссылки на документы, содержащие такую информацию; 2) сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды. Примечание: Для САПР в разделе дополнительно приводят основные параметры и характеристики объектов проектирования. 2.4. Раздел «Требования к системе» состоит из следующих подразделов: 1) требования к системе в целом; 2) требования к функциям (задачам), выполняемым системой; 3) требования к видам обеспечения. Состав требований к системе, включаемых в данный раздел ТЗ на ИС, устанавливают в зависимости от вида, назначения, специфических особенностей и условий функционирования конкретной системы. В каждом подразделе приводят ссылки на действующие НТД, определяющие требования к системам соответствующего вида. 2.3.1. В подразделе «Требования к системе в целом» указывают: - требования к структуре и функционированию системы; - требования к численности и квалификации персонала системы и режиму его работы; - показатели назначения; - требования к надежности; - требования безопасности; - требования к эргономике и технической эстетике; - требования к транспортабельности для подвижных АС; - требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы; - требования к защите информации от несанкционированного доступа; - требования по сохранности информации при авариях; - требования к защите от влияния внешних воздействий; - требования к патентной чистоте; - требования по стандартизации и унификации; - дополнительные требования. 2.3.1.1. В требованиях к структуре и функционированию системы приводят: 1) перечень подсистем, их назначение и основные характеристики, требования к числу уровней иерархии и степени централизации системы; 2) требования к способам и средствам связи для информационного обмена между компонентами системы; 3) требования к характеристикам взаимосвязей создаваемой системы со смежными системами, требования к ее совместимости, в том числе указания о способах обмена информацией (автоматически, пересылкой документов, по телефону и т. п.); 4) требования к режимам функционирования системы; 5) требования по диагностированию системы; 6) перспективы развития, модернизации системы. 2.3.1.2. В требованиях к показателям назначения ИС приводят значения параметров, характеризующие степень соответствия системы ее назначению. Для ИС управления указывают: - допустимые пределы модернизации и развития системы; - временные характеристики, при которых сохраняется назначение системы. 2.3.2. В подразделе «Требования к видам обеспечения» в зависимости от вида системы приводят требования к математическому, информационному, лингвистическому, программному, техническому, метрологическому, организационному, методическому и другие видам обеспечения системы. 2.3.2.1. Для математического обеспечения системы приводят требования к составу, области применения (ограничения) и способам, использования в системе математических методов и моделей, типовых алгоритмов и алгоритмов, подлежащих разработке. 2.3.2.2. Для информационного обеспечения системы приводят требования: 1) к составу, структуре и способам организации данных в системе; 2) к информационному обмену между компонентами системы; 3) к информационной совместимости со смежными системами; 4) по использованию общесоюзных и зарегистрированных республиканских, отраслевых классификаторов, унифицированных документов и классификаторов, действующих на данном предприятии; 5) по применению систем управления базами данных; 6) к структуре процесса сбора, обработки, передачи данных в системе и представлению данных; 7) к защите данных от разрушений при авариях и сбоях в электропитании системы; 8) к контролю, хранению, обновлению и восстановлению данных; 9) к процедуре придания юридической силы документам, продуцируемым техническими средствами ИС (в соответствии с ГОСТ 6.10.4). 2.3.2.3. Для лингвистического обеспечения системы приводят требования к применению в системе языков программирования высокого уровня, языков взаимодействия пользователей и технических средств системы, а также требования к кодированию и декодированию данных, к языкам ввода-вывода данных, языкам манипулирования данными, средствам описания предметной области (объекта автоматизации), к способам организации диалога. 2.3.2.4. Для программного обеспечения системы приводят перечень покупных программных средств, а также требования: 1) к независимости программных средств от используемых СВТ и операционной среды; 2) к качеству программных средств, а также к способам его обеспечения и контроля; 3) по необходимости согласования вновь разрабатываемых программных средств с фондом алгоритмов и программ. 2.3.2.5. Для технического обеспечения системы приводят требования: 1) к видам технических средств, в том числе к видам комплексов технических средств, программно-технических комплексов и других комплектующих изделий, допустимых к использованию в системе; 2) к функциональным, конструктивным и эксплуатационным характеристикам средств технического обеспечения системы. 2.3.2.6. Для организационного обеспечения приводят требования к структуре и функциям подразделений, участвующих в функционировании системы или обеспечивающих эксплуатацию; 2.3.2.7. Для методического обеспечения ИС приводят требования к составу нормативно-технической документации системы (перечень применяемых при ее функционировании стандартов, нормативов, методик и т. п.). 2.4. Раздел «Состав и содержание работ по созданию (развитию) системы» должен содержать перечень стадий и этапов работ по созданию системы в соответствии с ГОСТ 24.601, сроки их выполнения, перечень организаций - исполнителей работ, ссылки на документы, подтверждающие согласие этих организаций на участие в создании системы, или запись, определяющую ответственного (заказчик или разработчик) за проведение этих работ. 2.5. В разделе «Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие» необходимо привести перечень основных мероприятий и их исполнителей, которые следует выполнить при подготовке объекта автоматизации к вводу ИС в действие. 2.6. В состав ТЗ на проектирование ИС при наличии утвержденных методик включают приложения, содержащие: 1) расчет ожидаемой эффективности системы; 2) оценку научно-технического уровня системы. Приложения включают в состав ТЗ на проектирование ИС по согласованию между разработчиком и заказчиком системы. Постановка задачи к лабораторной работе 1 1. Изучить предлагаемый теоретический материал. 2. Построить опорные точки зрения на основании метода VORD для формирования и анализа требований. Результатом должны явиться две диаграммы: диаграмма идентификации точек зрения и диаграмма иерархии точек зрения. 3. Составить информационную модель будущей системы, включающую в себя описание основных объектов системы и взаимодействия между ними. На основании информационной модели, диаграммы идентификации точек зрения, диаграммы иерархии точек зрения сформировать требования пользователя и системные требования. 4. На основании описания системы, информационной модели, пользовательских и системных требований разработать техническое задание (ТЗ) на проектирование информационной системы (Приложение А). ТЗ должно содержать основные разделы, описанные в ГОСТ 34.602-89. 5. Оформить отчет по лабораторной работе. Представить отчет для защиты. Варианты индивидуальных заданий В соответствии с указанной предметной областью и классом разрабатываемой информационной системы разработать техническое задание на проектирование ИС. № 1 2 3 4 5 6 7 8 9 10 Таблица 1.2 – Индивидуальные задания Предметная область Склад Производственное предприятие Торговое предприятие Торговое предприятие Торговое предприятие Портал Строительное предприятие Высшее учебное заведение Инфраструктура предприятия Аппаратная инфраструктура предприятия Класс ИС MRP ERP CRM SCM B2C В2В ИС учета ИС управления СППР Экспертная система Содержание отчета По выполненной работе составляется отчет. Отчет выполняется в электронном виде. По выполненному отчету проводится защита практической работы. Отчет по лабораторной работе должен состоять из следующих структурных элементов: - титульный лист; - вводная часть; - основная часть (описание работы): техническое задание на проектирование информационной системы; - заключение (выводы). Вводная часть отчета должна включать пункты: - условие задачи; - порядок выполнения. - программно-аппаратные средства, используемые при выполнении работы. Зашита отчета по лабораторной работе заключается в предъявлении преподавателю полученных результатов в виде файла и демонстрации полученных навыков при ответах на вопросы преподавателя. Контрольные вопросы 1. Что такое жизненный цикл программного продукта? 2. Дайте определение модели жизненного цикла ПО. 3. Приведите этапы разработки программного средства. 4. Какие этапы включает в себя модель ЖЦ ПС согласно ГОСТ 19.102-77? 5. Что включает в себя этап предпроектного исследования? 6. Перечислите функциональные требования к программному продукту. 7. Перечислите эксплуатационные требования к программному продукту. 8. Перечислите правила разработки технического задания. 9. Назовите основные разделы технического задания. 10. В каких отношениях находятся заказчик и разработчик при выработке требований к программному средству? Лабораторная работа 2. Архитектура программного приложения Цель работы: изучение методов и средств разработки архитектуры программного приложения; применение методов и средств разработки архитектуры программного приложения. Лабораторная работа направлена на ознакомление с процессом описания информационной системы и получение навыков по использованию основных методов анализа ИС. Требования к результатам выполнения лабораторной работы: - наличие описания информационной системы; - проведение анализа осуществимости выполнения проекта; - наличие заключения о возможности реализации проекта, содержащего рекомендации относительно разработки системы, базовые предложения по объѐму требуемого бюджета, числу разработчиков, времени и требуемому программному обеспечению. Основы теории Проблемы разработки архитектуры программного приложения впервые проявились в 60-х - начале 70-х годов, когда провалились многие большие проекты по разработке программных продуктов. Были зафиксированы задержки в создании ПО, оно было ненадежным, затраты на разработку в несколько раз превосходили первоначальные оценки, созданные программные системы часто имели низкие показатели производительности. Причины провалов коренились в тех подходах, которые использовались в управлении проектами. Применяемая методика была основана на опыте управления техническими проектами и оказалась неэффективной при разработке программного обеспечения. Важно понимать разницу между профессиональной разработкой ПО и любительским программированием. Необходимость управления программными проектами вытекает из того факта, что процесс создания профессионального ПО всегда является субъектом бюджетной политики организации, где оно разрабатывается, и имеет временные ограничения. Работа руководителя программного проекта по большому счету заключается в том, чтобы гарантировать выполнение этих бюджетных и временных ограничений с учетом бизнес-целей организации относительно разрабатываемого ПО. Руководители проектов призваны спланировать все этапы разработки программного продукта. Они также должны контролировать ход выполнения работ и соблюдения всех требуемых стандартов. Постоянный контроль за ходом выполнения работ необходим для того, чтобы процесс разработки не выходил за временные и бюджетные ограничения. Хорошее управление не гарантирует успешного завершения проекта, но плохое управление обязательно приведет к его провалу. Это может выразиться в задержке сроков сдачи готового ПО, в превышении сметной стоимости проекта и в несоответствии готового ПО спецификации требований. Процесс разработки ПО существенно отличается от процессов реализации технических проектов, что порождает определенные сложности в управлении программными проектами: 1. Программный продукт нематериален. Программное обеспечение нематериально, его нельзя увидеть или потрогать. Руководитель программного проекта не видит процесс "роста" разрабатываемого ПО. Он может полагаться только на документацию, которая фиксирует процесс разработки программного продукта. 2. Не существует стандартных процессов разработки ПО. На сегодняшний день не существует четкой зависимости между процессом создания ПО и типом создаваемого программного продукта. Другие технические дисциплины имеют длительную историю, процессы разработки технических изделий многократно опробованы и проверены. Процессы создания большинства технических систем хорошо изучены. Изучением же процессов создания ПО специалисты занимаются только последнее время. Поэтому пока нельзя точно предсказать, на каком этапе процесса разработки ПО могут возникнуть проблемы, угрожающие всему программному проекту. 3. Большие программные проекты - это часто "одноразовые" проекты. Большие программные проекты, как правило, значительно отличаются от проектов, реализованных ранее. Поэтому, чтобы уменьшить неопределенность в планировании проекта, руководители проектов должны обладать очень большим практическим опытом. Но постоянные технологические изменения в компьютерной технике и коммуникационном оборудовании обесценивают предыдущий опыт. Знания и навыки, накопленные опытом, могут не востребоваться в новом проекте. Перечисленные отличия могут привести к тому, что реализация проекта выйдет из временного графика или превысит бюджетные ассигнования. Программные системы зачастую оказываются новинками как в "идеологическом", так и в техническом плане. Поэтому, предвидя возможные проблемы в реализации программного проекта, следует всегда помнить, что многим из них свойственно выходить за рамки временных и бюджетных ограничений. Разработка архитектуры программного приложения Невозможно описать и стандартизировать все работы, выполняемые в проекте по созданию ПО. Эти работы весьма существенно зависят от организации, где выполняется разработка ПО, и от типа создаваемого программного продукта. Но всегда можно выделить следующие: - Написание предложений по созданию ПО. - Планирование и составление графика работ по созданию ПО. - Оценивание стоимости проекта. - Подбор персонала. - Контроль за ходом выполнения работ. - Написание отчетов и представлений. Первая стадия программного проекта может состоять из написания предложений по реализации этого проекта. Предложения должны содержать описание целей проектов и способов их достижения. Они также обычно включают в себя оценки финансовых и временных затрат на выполнение проекта. При необходимости здесь могут приводиться обоснования для передачи проекта на выполнение сторонней организации или команде разработчиков. Написание предложений — очень ответственная работа, так как для многих организаций вопрос о том, будет ли проект выполняться самой организацией или разрабатываться по контракту сторонней компанией, является критическим. Не существует каких-либо рекомендаций по написанию предложений, многое здесь зависит от опыт. На этапе планирования проекта определяются процессы, этапы и полученные на каждом из них результаты, которые должны привести к выполнению проекта. Реализация этого плана приведет к достижению целей проекта. Определение стоимости проекта напрямую связано с его планированием, поскольку здесь оцениваются ресурсы, требующиеся для выполнения плана. Контроль за ходом выполнения работ (мониторинг проекта) — это непрерывный процесс, продолжающийся в течение всего срока реализации проекта. Руководитель должен постоянно отслеживать ход реализации проекта и сравнивать фактические и плановые показатели выполнения работ с их стоимостью. Хотя многие организации имеют механизмы формального мониторинга работ, опытный руководитель может составить ясную картину о стадии развитии проекта просто путем неформального общения с разработчиками. Неформальный мониторинг часто помогает обнаружить потенциальные проблемы, которые в явном виде могут обнаружиться позднее. Например, ежедневное обсуждение хода выполнения работ может выявить отдельные недоработки в создаваемом программном продукте. Вместо ожидания отчетов, в которых будет отражен факт "пробуксовки" графика работ, можно обсудить со специалистами намечающиеся программистские проблемы и не допустить срыва графика работ. В течение реализации проекта обычно происходит несколько формальных контрольных проверок хода выполнения работ по созданию ПО. Такие проверки должны дать общую картину хода реализации проекта в целом и показать, насколько уже разработанная часть ПО соответствует целям проекта. Время выполнения больших программных проектов может занимать несколько лет. В течение этого времени цели и намерения организации, заказавшей программный проект, могут существенно измениться. Может оказаться, что разрабатываемый программный продукт стал уже ненужным либо исходные требования к создаваемому ПО просто устарели и их необходимо кардинально менять. В такой ситуации руководство организации-разработчика может принять решение о прекращении разработки ПО или об изменении проекта в целом с тем, чтобы учесть изменившиеся цели и намерения организации-заказчика. Руководители проектов обычно обязаны сами подбирать исполнителей для своих проектов. В идеальном случае профессиональный уровень исполнителей должен соответствовать той работе, которую они будут выполнять в ходе реализации проекта. Однако во многих случаях руководители должны полагаться на команду разработчиков, которая далека от идеальной. Такая ситуация может быть вызвана следующими причинами: 1. Бюджет проекта не позволяет привлечь высококвалифицированный персонал. В таком случае за меньшую плату привлекаются менее квалифицированные специалисты. 2. Бывают ситуации, когда невозможно найти специалистов необходимой квалификации как в самой организации-разработчике, так и вне ее. Например, в организации "лучшие люди" могут быть уже заняты в других проектах. 3. Организация хочет повысить профессиональный уровень своих работников. В этом случае она может привлечь к участию в проекте неопытных или недостаточно квалифицированных работников, чтобы они приобрели необходимый опыт и поучились у более опытных специалистов. Таким образом, почти всегда подбор специалистов для выполнения проекта имеет определенные ограничения и не является свободным. Вместе с тем необходимо, чтобы хотя бы несколько членов группы разработчиков имели квалификацию и опыт, достаточные для работы над данным проектом. В противном случае невозможно избежать ошибок в разработке ПО. Руководитель проекта обычно обязан посылать отчеты о ходе его выполнения как заказчику, так и подрядным организациям. Это должны быть краткие документы, основанные на информации, извлекаемой из подробных' отчетов о проекте. В этих отчетах должна быть та информация, которая позволяет четко оценить степень готовности создаваемого программного продукта. В рамках курса «Системная инженерия» выделены следующие роли в группе по разработке ПО: - Руководитель – общее руководство проектом, написание документации, общение с заказчиком ПО; - Системный аналитик – разработка требований (составление технического задания, проекта программного обеспечения); - Тестер – составление плана тестирования и аттестации готового ПО (продукта), составление сценария тестирования, базовый пример, проведение мероприятий по плану тестирования; - Разработчик – моделирование компонент программного обеспечения, кодирование. Планирование процесса разработки архитектуры программного приложения Эффективное управление программным проектом напрямую зависит от правильного планирования работ, необходимых для его выполнения. План помогает руководителю предвидеть проблемы, которые могут возникнуть на каких-либо этапах создания ПО, и разработать превентивные меры для их предупреждения или решения. План, разработанный на начальном этапе проекта, рассматривается всеми его участниками как руководящий документ, выполнение которого должно привести к успешному завершению проекта. Этот первоначальный план должен максимально подробно описывать все этапы реализации проекта. Процесс планирования начинается, исходя из описания системы, с определения проектных ограничений (временные ограничения, возможности наличного персонала, бюджетные ограничения и т.д.). Эти ограничения должны определяться параллельно с оцениванием проектных параметров, таких как структура и размер проекта, а также распределением функций среди исполнителей. Затем определяются этапы разработки и то, какие результаты документация, прототипы, подсистемы или версии программного продукта) должны быть получены по окончании этих этапов. Далее начинается циклическая часть планирования. Сначала разрабатывается график работ по выполнению проекта или дается разрешение на продолжение использования ранее созданного графика. После этого проводится контроль выполнения работ и отмечаются расхождения между реальным и плановым ходом работ. Далее, по мере поступления новой информации о ходе выполнения проекта, возможен пересмотр первоначальных оценок параметров проекта. Это, в свою очередь, может привести к изменению графика работ. Если в результате этих изменений нарушаются сроки завершения проекта, должны быть пересмотрены (и согласованы с заказчиком ПО) проектные ограничения. Конечно, большинство руководителей проектов не думают, что реализация их проектов пройдет гладко, без всяких проблем. Желательно описать возможные проблемы еще до того, как они проявят себя в ходе выполнения проекта. Поэтому лучше составлять "пессимистические" графики работ, чем "оптимистические". Но, конечно, невозможно построить план, учитывающий все, в том числе случайные, проблемы и задержки выполнения проекта, поэтому и возникает необходимость периодического пересмотра проектных ограничений и этапов создания программного продукта. План проекта должен четко показать ресурсы, необходимые для реализации проекта, разделение работ на этапы и временной график выполнения этих этапов. В некоторых организациях план проекта составляется как единый документ, содержащий все виды планов, описанных выше. В других случаях план проекта описывает только технологический процесс создания ПО. В таком плане обязательно присутствуют ссылки на планы других видов, но они разрабатываются отдельно от плана проекта. Детализация планов проектов очень разнится в зависимости от типа разрабатываемого программного продукта и организации-разработчика. Но в любом случае большинство планов содержат следующие разделы. 1. Введение. Краткое описание целей проекта и проектных ограничений (бюджетных, временных и т.д.), которые важны для управления проектом. 2. Организация выполнения проекта. Описание способа подбора команды разработчиков и распределение обязанностей между членами команды. 3. Анализ рисков. Описание возможных проектных рисков, вероятности их проявления и стратегий, направленных на их уменьшение. 4. Аппаратные и программные ресурсы, необходимые для реализации проекта. Перечень аппаратных средств и программного обеспечения, необходимого для разработки программного продукта. Если аппаратные средства требуется закупать, приводится их стоимость совместно с графиком закупки и поставки. 5. Разбиение работ на этапы. Процесс реализации проекта разбивается на отдельные процессы, определяются этапы выполнения проекта, приводится описание результатов ("выходов") каждого этапа и контрольные отметки. 6. График работ. В этом графике отображаются зависимости между отдельными процессами (этапами) разработки ПО, оценки времени их выполнения и распределение членов команды разработчиков по отдельным этапам. 7. Механизмы мониторинга и контроля за ходом выполнения проекта. Описываются предоставляемые руководителем отчеты о ходе выполнения работ, сроки их предоставления, а также механизмы мониторинга всего проекта. План должен регулярно пересматриваться в процессе реализации проекта. Одни части плана, например график работ, изменяются часто, другие более стабильны. Для внесения изменений в план требуется специальная организация документопотока, позволяющая отслеживать эти изменения. Общие сведения о требованиях к архитектуре программного приложения Проблемы, которые приходится решать специалистам в процессе создания программного обеспечения, очень сложны. Природа этих проблем не всегда ясна, особенно если разрабатываемая программная система инновационная. В частности, трудно чѐтко описать те действия, которые должна выполнять система. Описание функциональных возможностей и ограничений, накладываемых на систему, называется требованиями к этой системе, а сам процесс формирования, анализа, документирования и проверки этих функциональных возможностей и ограничений – разработкой требований. Требования подразделяются на пользовательские и системные. Пользовательские требования – это описание на естественном языке (плюс поясняющие диаграммы) функций, выполняемых системой, и ограничений, накладываемых на неѐ. Системные требования – это описание особенностей системы (архитектура системы, требования к параметрам оборудования и т.д.), необходимых для эффективной реализации требований пользователя. Разработка архитектуры программного приложения: анализ осуществимости Разработка требований — это процесс, включающий мероприятия, необходимые для создания и утверждения документа, содержащего спецификацию системных требований. Для новых программных систем процесс разработки требований должен начинаться с анализа осуществимости. Началом такого анализа является общее описание системы и ее назначения, а результатом анализа — отчет, в котором должна быть четкая рекомендация, продолжать или нет процесс разработки требований проектируемой системы. Другими словами, анализ осуществимости должен осветить следующие вопросы. 1. Отвечает ли система общим и бизнес-целям организации-заказчика и организации-разработчика? 2. Можно ли реализовать систему, используя существующие на данный момент технологии и не выходя за пределы заданной стоимости? 3. Можно ли объединить систему с другими системами, которые уже эксплуатируются? Критическим является вопрос, будет ли система соответствовать целям организации. Если система не соответствует этим целям, она не представляет никакой ценности для организации. В то же время многие организации разрабатывают системы, не соответствующие их целям, либо не совсем ясно понимая эти цели, либо под влиянием политических или общественных факторов. Выполнение анализа осуществимости включает сбор и анализ информации о будущей системе и написание соответствующего отчета. Сначала следует определить, какая именно информация необходима, чтобы ответить на поставленные выше вопросы. Например, эту информацию можно получить, ответив на следующее: 1. Что произойдет с организацией, если система не будет введена в эксплуатацию? 2. Какие текущие проблемы существуют в организации и как новая система поможет их решить? 3. Каким образом система будет способствовать целям бизнеса? 4. Требует ли разработка системы технологии, которая до этого не использовалась в организации? Далее необходимо определить источники информации. Это могут быть менеджеры отделов, где система будет использоваться, разработчики программного обеспечения, знакомые с типом будущей системы, технологи, конечные пользователи и т.д. После обработки собранной информации готовится отчет по анализу осуществимости создания системы. В нем должны быть даны рекомендации относительно продолжения разработки системы. Могут быть предложены изменения бюджета и графика работ по созданию системы или предъявлены более высокие требования к системе. Постановка задачи к лабораторной работе 2 1. Изучить предлагаемый теоретический материал. 2. Составить подробное описание информационной системы. 3. На основании описания системы провести анализ процесса организации проектирования информационной системы. В ходе анализа ответить на вопросы: - Что произойдет с организацией, если система не будет введена в эксплуатацию? - Какие текущие проблемы существуют в организации и как новая система поможет их решить? - Каким образом система будет способствовать целям бизнеса? - Требует ли разработка системы технологии, которая до этого не использовалась в организации? Результатом анализа должно явиться заключение о возможности реализации проекта. 4. Распределить роли в группе (руководитель проекта-разработчик, системный аналитик-разработчик, тестер-разработчик). 5. Заполнить разделы плана: - Введение - Организация выполнения проекта - Анализ рисков Разделы должны содержать рекомендации относительно разработки системы, базовые предложения по объѐму требуемого бюджета, числу разработчиков, времени и требуемому программному обеспечению. 6. Оформить отчет по лабораторной работе. Представить отчет для защиты. Варианты индивидуальных заданий В соответствии с указанной предметной областью и классом разрабатываемой информационной системы разработать описание информационной системы и провести анализ процесса организации проектирования информационной системы. № 1 2 Таблица 2.1 – Индивидуальные задания Предметная область Склад Производственное предприятие Класс ИС MRP ERP 3 4 5 6 7 8 9 10 Торговое предприятие Торговое предприятие Торговое предприятие Портал Строительное предприятие Высшее учебное заведение Инфраструктура предприятия Аппаратная инфраструктура предприятия CRM SCM B2C В2В ИС учета ИС управления СППР Экспертная система Содержание отчета По выполненной работе составляется отчет. Отчет выполняется в электронном виде. По выполненному отчету проводится защита практической работы. Отчет должен состоять из следующих структурных элементов: - титульный лист; - вводная часть: краткое описание целей проекта и проектных ограничений (бюджетных, временных и т.д.), которые важны для управления проектом. Вводная часть отчета должна включать пункты: условие задачи; порядок выполнения; программно-аппаратные средства, используемые при выполнении работы. - основная часть (описание работы): описание информационной системы; анализ процесса организации проектирования информационной системы; роли. Основная часть отчета включает в себя: описание информационной системы (ПО) наличие заключения о возможности реализации проекта, содержащего рекомендации относительно разработки системы, базовые предложения по объѐму требуемого бюджета, числу разработчиков, времени и требуемому программному обеспечению; анализ осуществимости: указать возможные проблемы и пути их решения; роли участников группы разработки ПО. - заключение (выводы); - список использованной литературы. Зашита отчета заключается в предъявлении преподавателю полученных результатов в виде файла и демонстрации полученных навыков при ответах на вопросы преподавателя. Контрольные вопросы 1. Предложите, кто бы мог участвовать в формировании требований для университетской системы регистрации студентов. Объясните, почему почти неизбежно, что требования, сформулированные разными лицами, будут противоречивы. 2. Разрабатывается система ПО для автоматизации библиотечного каталога. Эта система будет содержать информацию относительно всех книг в библиотеке и будет полезна библиотечному персоналу, абонентам и читателям. Система должна иметь средства просмотра каталога, средства создания запросов и средства, позволяющие пользователям резервировать книги, находящиеся в данный момент на руках. Определите основные опорные точки зрения, которые необходимо учесть в спецификации системы, и покажите их взаимоотношения, используя диаграмму иерархии точек зрения. 3. Для трех точек зрения, определенных в системе библиотечного каталога, укажите сервисы и соответствующие данные, которые обеспечиваются этими точками зрения, и события, которые управляют этими сервисами. 4. Кто должен проводить обзор требований? Нарисуйте модель процесса обзора требований. 5. Ваша компания использует стандартный метод анализа требований. В процессе работы вы обнаружили, что этот метод не учитывает социальные факторы, важные для системы, которую вы анализируете. Ваш руководитель дал вам ясно понять, какому методу анализа нужно следовать. Обсудите, что вы должны делать в такой ситуации. Лабораторная работа 3. Функциональное моделирование бизнес-процессов предметной области программных приложений Цель работы: Изучить и применить на практике методологии функционального моделирования бизнес-процессов предметной области программных приложений. Основы теории Основные понятия методологии функционального моделирования IDEF0 IDEF0 (Integrated Definition Function Modeling) - методология функционального моделирования. В основе IDEF0 методологии лежит понятие блока, который отображает некоторую бизнес-функцию. Четыре стороны блока имеют разную роль: левая сторона имеет значение "входа", правая - "выхода", верхняя - "управления", нижняя "механизма" (рисунок 3.1). Взаимодействие между функциями в IDEF0 представляется в виде дуги, которая отображает поток данных или материалов, поступающий с выхода одной функции на вход другой. В зависимости от того, с какой стороной блока связан поток, его называют соответственно "входным", "выходным", "управляющим". Рисунок 3.1 - Функциональный блок Принципы моделирования в IDEF0 В IDEF0 реализованы три базовых принципа моделирования процессов: принцип функциональной декомпозиции; принцип ограничения сложности; принцип контекста. Принцип функциональной декомпозиции представляет собой способ моделирования типовой ситуации, когда любое действие, операция, функция могут быть разбиты (декомпозированы) на более простые действия, операции, функции. Другими словами, сложная бизнес-функция может быть представлена в виде совокупности элементарных функций. Представляя функции графически, в виде блоков, можно как бы заглянуть внутрь блока и детально рассмотреть ее структуру и состав (рисунок 2.2). Принцип ограничения сложности. При работе с IDEF0 диаграммами существенным является условие их разборчивости и удобочитаемости. Суть принципа ограничения сложности состоит в том, что количество блоков на диаграмме должно быть не менее двух и не более шести. Практика показывает, что соблюдение этого принципа приводит к тому, что функциональные процессы, представленные в виде IDEF0 модели, хорошо структурированы, понятны и легко поддаются анализу. Принцип контекстной диаграммы. Моделирование делового процесса начинается с построения контекстной диаграммы. На этой диаграмме отображается только один блок главная бизнес-функция моделируемой системы. Если речь идет о моделировании целого предприятия или даже крупного подразделения, главная бизнес-функция не может быть сформулирована как, например, "продавать продукцию". Главная бизнес-функция системы - это "миссия" системы, ее значение в окружающем мире. Нельзя правильно сформулировать главную функцию предприятия, не имея представления о его стратегии. При определении главной бизнес-функции необходимо всегда иметь ввиду цель моделирования и точку зрения на модель. Одно и то же предприятие может быть описано по-разному, в зависимости от того, с какой точки зрения его рассматривают: директор предприятия и налоговой инспектор видят организацию совершенно по-разному. Контекстная диаграмма играет еще одну роль в функциональной модели. Она "фиксирует" границы моделируемой бизнес-системы, определяя то, как моделируемая система взаимодействует со своим окружением. Это достигается за счет описания дуг, соединенных с блоком, представляющим главную бизнес-функцию. Рисунок 3.2 - Декомпозиция функционального блока Пример На рисунках 3.3, 3.4 представлен пример построения функциональной диаграммы, описывающей изготовление изделия. Рисунок 3.3 является примером построения контекстной диаграммы, рисунок 3.4 представляет собой первый уровень декомпозиции. Рисунок 6.3 - Контекстная диаграмма Рисунок 3.4 - Диаграмма первого уровня декомпозиции Применение IDEF0 Существует два ключевых подхода к построению функциональной модели: построение ―как есть‖ и построение ―как будет‖. Построение модели ―как есть‖. Обследование предприятия является обязательной частью любого проекта создания или развития корпоративной информационной системы. Построение функциональной модели ―как есть‖ позволяет четко зафиксировать, какие деловые процессы осуществляются на предприятии, какие информационные объекты используются при выполнении деловых процессов и отдельных операций. Функциональная модель ―как есть‖ является отправной точкой для анализа потребностей предприятия, выявления проблем и "узких" мест и разработки проекта совершенствования деловых процессов. Построение модели ―как будет‖. Создание и внедрение корпоративной информационной системы приводит к изменению условий выполнения отдельных операций, структуры деловых процессов и предприятия в целом. Это приводит к необходимости изменения системы бизнес-правил, используемых на предприятии, модификации должностных инструкций сотрудников. Функциональная модель ―как будет‖ позволяет уже на стадии проектирования будущей информационной системы определить эти изменения. Применение функциональной модели ―как будет‖ позволяет не только сократить сроки внедрения информационной системы, но также снизить риски, связанные с невосприимчивостью персонала к информационным технологиям. Метод описания процессов IDEF3 Для описания логики взаимодействия информационных потоков наиболее подходит IDEF3, называемая также workflow diagramming - методологией моделирования, использующая графическое описание информационных потоков, взаимоотношений между процессами обработки информации и объектов, являющихся частью этих процессов. Диаграммы Workflow могут быть использованы в моделировании бизнес-процессов для анализа завершенности процедур обработки информации. С их помощью можно описывать сценарии действий сотрудников организации, например последовательность обработки заказа или события, которые необходимо обработать за конечное время. Каждый сценарий сопровождается описанием процесса и может быть использован для документирования каждой функции. IDEF3 - это метод, имеющий основной целью дать возможность аналитикам описать ситуацию, когда процессы выполняются в определенной последовательности, а также описать объекты, участвующие совместно в одном процессе, Техника описания набора данных IDEF3 является частью структурного анализа. В отличие от некоторых методик описаний процессов IDEF3 не ограничивает аналитика чрезмерно жесткими рамками синтаксиса, что может привести к созданию неполных или противоречивых моделей. IDEF3 может быть также использован как метод создания процессов. IDEF3 дополняет IDEF0 и содержит все необходимое для построения моделей, которые в дальнейшем могут быть использованы для имитационного анализа. Каждая работа в IDEF3 описывает какой-либо сценарий бизнес-процесса и может являться составляющей другой работы. Поскольку сценарий описывает цель и рамки модели, важно, чтобы работы именовались отглагольным существительным, обозначающим процесс действия, или фразой, содержащей такое существительное. Точка зрения на модель должна быть задокументирована. Обычно это точка зрения человека, ответственного за работу в целом. Также необходимо задокументировать цель модели - те вопросы, на которые призвана ответить модель. Диаграммы. Диаграмма является основной единицей описания в IDEF3. Единицы работы - Unit of Work (UOW). UOW, также называемые работами (activity), являются центральными компонентами модели. В IDEF3 работы изображаются прямоугольниками с прямыми углами и имеют имя, выраженное отглагольным существительным, обозначающим процесс действия, одиночным или в составе фразы, и номер (идентификатор); другое имя существительное в составе той же фразы обычно отображает основной выход (результат) работы, например, "Изготовление изделия". Связи. Связи показывают взаимоотношения работ. Все связи в IDEF3 однонаправлены и могут быть направлены куда угодно, но обычно диаграммы IDEF3 стараются построить так, чтобы связи были направлены слева направо. В IDEF3 различают три типа стрелок, изображающих связи, стиль которых устанавливается через меню Edit/Arrow Style: Старшая (Precedence) - сплошная линия, связывающая единицы работ (UOW), Рисуется слева направо или сверху вниз. Показывает, что работа-источник должна закончиться прежде, чем работа-цель начнется. Отношения (Relational Link) - пунктирная линия для изображения связей между единицами работ (UOW) а также между единицами работ и объектами ссылок. Потоки объектов (Object Flow) - стрелка с двумя наконечниками, применяется для описания того факта, что объект используется в двух или более единицах работы, например, когда объект порождается в одной работе и используется в другой. Старшая связь и поток объектов. Старшая связь показывает, что работа-источник заканчивается ранее, чем начинается работа-цель. Часто результатом работы-источника становится объект, необходимый для запуска работы-цели. В этом случае стрелку, обозначающую объект, изображают с двойным наконечником. Имя стрелки должно ясно идентифицировать отображаемый объект. Поток объектов имеет ту же семантику, что и старшая стрелка. Перекрестки (Junction). Окончание одной работы может служить сигналом к началу нескольких работ, или же одна работа для своего запуска может ожидать окончания нескольких работ. Перекрестки используются для отображения логики взаимодействия стрелок при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы. Различают перекрестки для слияния (Fan-in Junction) и разветвления (Fan-out Junction) стрелок. Перекресток не может использоваться одновременно для слияния и для разветвления. Для внесения перекрестка служит кнопка в палитре инструментов - добавить в диаграмму перекресток Junction. В диалоге Junction Type Editor необходимо указать тип перекрестка. Смысл каждого типа приведен в таблице 3.1. Таблица 3.1 - Типы перекрестков Обозначение Наименование Смысл в случае слияния стрелок Asynchronous Все предшествующие процессы AND должны быть завершены Synchronous AND Asynchronous OR Synchronous OR XOR (Exclusive OR) Смысл в случае разветвления стрелок Все следующие процессы должны быть запущены Все предшествующие процессы Все следующие завершены одновременно процессы запускаются одновременно Один или несколько Один или несколько предшествующих процессов следующих процессов должны быть завершены должны быть запущены Один или несколько Один или несколько предшествующих процессов следующих процессов завершены одновременно запускаются одновременно Только один предшествующий Только один процесс завершен следующий процесс запускается В отличие от IDEF0 в IDEF3 стрелки могут сливаться и разветвляться только через перекрестки. Декомпозиция работ. В IDEF3 декомпозиция используется для детализации работ. Методология IDEF3 позволяет декомпозировать работу многократно, т.е. работа может иметь множество дочерних работ. Это позволяет в одной модели описать альтернативные потоки. Возможность множественной декомпозиции предъявляет дополнительные требования к нумерации работ. Так, номер работы состоит из номера родительской работы, версии декомпозиции и собственного номера работы на текущей диаграмме (рисунок 3.5). Рисунок 3.5 - Номер единицы работы (UOW) Постановка задачи к лабораторной работе 3 1. Изучить предлагаемый теоретический материал. 2. Построить функциональную модель системы, описанной в лабораторной работе 2. Функциональная модель должна отвечать всем предъявленным к системе требованиям, должна представлять полный функционал системы (каждой функции в описании системы должен соответствовать по крайней мере один функциональный блок) и еѐ основные бизнес-процессы: 2.1. С помощью методологии IDEF0 построить контекстную диаграмму; 2.2. С помощью методологии IDEF0 построить диаграмму 1-го уровня (A0); 2.3. С помощью методологий IDEF0, IDEF3 декомпозировать блоки A0; 3. Построить отчѐт, включающий все полученные уровни модели, описание функциональных блоков, потоков данных, хранилищ и внешних объектов. 4. Оформить отчет. Представить отчет для защиты. Варианты индивидуальных заданий В соответствии с указанной предметной областью и классом разрабатываемой информационной системы разработать функциональную модель системы. № 1 2 3 4 5 6 7 8 9 10 Таблица 3.2 – Индивидуальные задания Предметная область Склад Производственное предприятие Торговое предприятие Торговое предприятие Торговое предприятие Портал Строительное предприятие Высшее учебное заведение Инфраструктура предприятия Аппаратная инфраструктура предприятия Класс ИС MRP ERP CRM SCM B2C В2В ИС учета ИС управления СППР Экспертная система Содержание отчета По выполненной работе составляется отчет. Отчет выполняется в электронном виде. По выполненному отчету проводится защита лабораторной работы. Отчет по практической работе должен состоять из следующих структурных элементов: - титульный лист; - вводная часть; - основная часть (описание работы): функциональная модель информационной системы и ее описание; - заключение (выводы). Вводная часть отчета должна включать пункты: - условие задачи; - порядок выполнения. - программно-аппаратные средства, используемые при выполнении работы. Зашита отчета по лабораторной работе заключается в предъявлении преподавателю полученных результатов в виде файла и демонстрации полученных навыков при ответах на вопросы преподавателя. Контрольные вопросы 1. Перечислите основные объекты IDEF0, их описание и назначение. 2. Назовите базовые принципы моделирования в IDEF0. 3. В каких случаях целесообразно применять построение модели ―как есть‖, а в каких ―как будет‖? 4. Перечислите основные объекты IDEF3, их описание и назначение. 5. В чѐм смысл использования перекрѐстков в IDEF3? 6. В чѐм отличия IDEF0 и IDEF3? Когда целесообразней использовать IDEF0, а когда IDEF3? Лабораторная работа 4. Объектно-ориентированное моделирование функциональных компонентов программных приложений Цель работы: Ознакомление с методологией объектно-ориентированного моделирования функциональных компонентов программных приложений. Работа направлена на ознакомление с основными элементами определения, представления, проектирования и моделирования программных систем с помощью языка UML, получение навыков по применению данных элементов для построения объектноориентированных моделей ИС на основании требований. Требования к результатам выполнения работы: - модель системы должна содержать: диаграмму вариантов использования; диаграммы взаимодействия для каждого варианта использования; диаграмму классов, позволяющая реализовать весь описанный функционал ИС; объединенную диаграмму компонентов и размещения; - для классов указать стереотипы; - в зависимости от варианта задания диаграмма размещения должна показывать расположение компонентов в распределенном приложении. Основы теории Общие сведения об объектном моделировании программных приложений Существует множество технологий и инструментальных средств, с помощью которых можно реализовать в некотором смысле оптимальный проект ИС, начиная с этапа анализа и заканчивая созданием программного кода системы. В большинстве случаев эти технологии предъявляют весьма жесткие требования к процессу разработки и используемым ресурсам, а попытки трансформировать их под конкретные проекты оказываются безуспешными. Эти технологии представлены CASE-средствами верхнего уровня или CASE-средствами полного жизненного цикла (upper CASE tools или full lifecycle CASE tools). Они не позволяют оптимизировать деятельность на уровне отдельных элементов проекта, и, как следствие, многие разработчики перешли на так называемые CASE-средства нижнего уровня (lower CASE tools). Однако они столкнулись с новой проблемой — проблемой организации взаимодействия между различными командами, реализующими проект. Унифицированный язык объектно-ориентированного моделирования Унифицированный язык объектно-ориентированного моделирования Unified Modeling Language (UML) явился средством достижения компромисса между этими подходами. Существует достаточное количество инструментальных средств, поддерживающих с помощью UML жизненный цикл информационных систем, и, одновременно, UML является достаточно гибким для настройки и поддержки специфики деятельности различных команд разработчиков. Создание UML началось в октябре 1994 г., когда Джим Рамбо и Гради Буч из Rational Software Corporation стали работать над объединением своих методов OMT и Booch. В настоящее время консорциум пользователей UML Partners включает в себя представителей таких грандов информационных технологий, как Rational Software, Microsoft, IBM, Hewlett-Packard, Oracle, DEC, Unisys, IntelliCorp, Platinum Technology. UML представляет собой объектно-ориентированный язык моделирования, обладающий следующими основными характеристиками: - является языком визуального моделирования, который обеспечивает разработку репрезентативных моделей для организации взаимодействия заказчика и разработчика ИС, различных групп разработчиков ИС; - содержит механизмы расширения и специализации базовых концепций языка. UML — это стандартная нотация визуального моделирования программных систем, принятая консорциумом Object Managing Group (OMG) осенью 1997 г., и на сегодняшний день она поддерживается многими объектно-ориентированными CASEпродуктами. UML включает внутренний набор средств моделирования, которые сейчас приняты во многих методах и средствах моделирования. Эти концепции необходимы в большинстве прикладных задач, хотя не каждая концепция необходима в каждой части каждого приложения. Пользователям языка предоставлены возможности: - строить модели на основе средств ядра, без использования механизмов расширения для большинства типовых приложений; - добавлять при необходимости новые элементы и условные обозначения, если они не входят в ядро, или специализировать компоненты, систему условных обозначений (нотацию) и ограничения для конкретных предметных областей. Язык UML Рисунок 4.1 - Интегрированная модель сложной системы в нотации языка UML Стандарт UML предлагает следующий набор диаграмм для моделирования: 1. диаграммы вариантов использования (use case diagrams) – для моделирования бизнес-процессов организации и требований к создаваемой системе); 2 диаграммы классов (class diagrams) – для моделирования статической структуры классов системы и связей между ними; 3. диаграммы поведения системы (behavior diagrams): 3.1 диаграммы взаимодействия (interaction diagrams): 3.1.1 диаграммы последовательности (sequence diagrams) и 3.1.2 кооперативные диаграммы (collaboration diagrams) – для моделирования процесса обмена сообщениями между объектами; 3.2 диаграммы состояний (statechart diagrams) – для моделирования поведения объектов системы при переходе из одного состояния в другое; 3.3 диаграммы деятельностей (activity diagrams) – для моделирования поведения системы в рамках различных вариантов использования, или моделирования деятельностей; 4. диаграммы реализации (implementation diagrams): 4.1 диаграммы компонентов (component diagrams) – для моделирования иерархии компонентов (подсистем) системы; 4.2 диаграммы развертывания (deployment diagrams) – для моделирования физической архитектуры системы. Диаграммы вариантов использования Понятие варианта использования (use case) впервые ввел Ивар Якобсон и придал ему такую значимость, что в настоящее время вариант использования превратился в основной элемент разработки и планирования проекта. Вариант использования представляет собой последовательность действий (транзакций), выполняемых системой в ответ на событие, инициируемое некоторым внешним объектом (действующим лицом). Вариант использования описывает типичное взаимодействие между пользователем и системой. В простейшем случае вариант использования определяется в процессе обсуждения с пользователем тех функций, которые он хотел бы реализовать. На языке UML вариант использования изображают следующим образом: Рисунок 4.2 - Вариант использования Действующее лицо (actor) – это роль, которую пользователь играет по отношению к системе. Действующие лица представляют собой роли, а не конкретных людей или наименования работ. Несмотря на то, что на диаграммах вариантов использования они изображаются в виде стилизованных человеческих фигурок, действующее лицо может также быть внешней системой, которой необходима некоторая информация от данной системы. Показывать на диаграмме действующих лиц следует только в том случае, когда им действительно необходимы некоторые варианты использования. На языке UML действующие лица представляют в виде фигур: Рисунок 4.3 - Действующее лицо (актер) Действующие лица делятся на три основных типа: - пользователи; - системы; - другие системы, взаимодействующие с данной; - время. Время становится действующим лицом, если от него зависит запуск каких-либо событий в системе. Связи между вариантами использования и действующими лицами В языке UML на диаграммах вариантов использования поддерживается несколько типов связей между элементами диаграммы. Это связи коммуникации (communication), включения (include), расширения (extend) и обобщения (generalization). Связь коммуникации – это связь между вариантом использования и действующим лицом. На языке UML связи коммуникации показывают с помощью однонаправленной ассоциации (сплошной линии). Рисунок 4.4 - Пример связи коммуникации Связь включения применяется в тех ситуациях, когда имеется какой-либо фрагмент поведения системы, который повторяется более чем в одном варианте использования. С помощью таких связей обычно моделируют многократно используемую функциональность. Связь расширения применяется при описании изменений в нормальном поведении системы. Она позволяет варианту использования только при необходимости использовать функциональные возможности другого. Рисунок 4.5 - Пример связи включения и расширения С помощью связи обобщения показывают, что у нескольких действующих лиц имеются общие черты. Рисунок 4.6 - Пример связи обобщения Диаграммы взаимодействия (interaction diagrams) Диаграммы взаимодействия (interaction diagrams) описывают поведение взаимодействующих групп объектов. Как правило, диаграмма взаимодействия охватывает поведение объектов в рамках только одного варианта использования. На такой диаграмме отображается ряд объектов и те сообщения, которыми они обмениваются между собой. Сообщение (message) – это средство, с помощью которого объект-отправитель запрашивает у объекта получателя выполнение одной из его операций. Информационное (informative) сообщение – это сообщение, снабжающее объектполучатель некоторой информацией для обновления его состояния. Сообщение-запрос (interrogative) – это сообщение, запрашивающее выдачу некоторой информации об объекте-получателе. Императивное (imperative) сообщение – это сообщение, запрашивающее у объекта-получателя выполнение некоторых действий. Существует два вида диаграмм взаимодействия: диаграммы последовательности (sequence diagrams) и кооперативные диаграммы (collaboration diagrams). Диаграмма последовательности (sequence diagrams) Диаграмма последовательности отражает поток событий, происходящих в рамках варианта использования. Рисунок 4.7 - Пример диаграммы последовательности Все действующие лица показаны в верхней части диаграммы. Стрелки соответствуют сообщениям, передаваемым между действующим лицом и объектом или между объектами для выполнения требуемых функций. На диаграмме последовательности объект изображается в виде прямоугольника, от которого вниз проведена пунктирная вертикальная линия. Эта линия называется линией жизни (lifeline) объекта. Она представляет собой фрагмент жизненного цикла объекта в процессе взаимодействия. Каждое сообщение представляется в виде стрелки между линиями жизни двух объектов. Сообщения появляются в том порядке, как они показаны на странице сверху вниз. Каждое сообщение помечается как минимум именем сообщения. При желании можно добавить также аргументы и некоторую управляющую информацию. Можно показать самоделегирование (self-delegation) – сообщение, которое объект посылает самому себе, при этом стрелка сообщения указывает на ту же самую линию жизни. Диаграмма кооперации (collaboration diagram) Диаграммы кооперации отображают поток событий через конкретный сценарий варианта использования, упорядочены по времени, а кооперативные диаграммы больше внимания заостряют на связях между объектами. На диаграмме кооперации представлена вся та информация, которая есть и на диаграмме последовательности, но кооперативная диаграмма по-другому описывает поток событий. Из нее легче понять связи между объектами, однако, труднее уяснить последовательность событий. На кооперативной диаграмме так же, как и на диаграмме последовательности, стрелки обозначают сообщения, обмен которыми осуществляется в рамках данного варианта использования. Их временная последовательность указывается путем нумерации сообщений. Рисунок 4.8 - Пример диаграммы кооперации Диаграммы классов. Общие сведения Диаграмма классов определяет типы классов системы и различного рода статические связи, которые существуют между ними. На диаграммах классов изображаются также атрибуты классов, операции классов и ограничения, которые накладываются на связи между классами. Диаграмма классов UML - это граф, узлами которого являются элементы статической структуры проекта (классы, интерфейсы), а дугами - отношения между узлами (ассоциации, наследование, зависимости). На диаграмме классов изображаются следующие элементы: - Пакет (package) - набор элементов модели, логически связанных между собой; - Класс (class) - описание общих свойств группы сходных объектов; - Интерфейс (interface) - абстрактный класс, задающий набор операций, которые объект произвольного класса, связанного с данным интерфейсом, предоставляет другим объектам. Класс Класс - это группа сущностей (объектов), обладающих сходными свойствами, а именно, данными и поведением. Отдельный представитель некоторого класса называется объектом класса или просто объектом. Под поведением объекта в UML понимаются любые правила взаимодействия объекта с внешним миром и с данными самого объекта. На диаграммах класс изображается в виде прямоугольника со сплошной границей, разделенного горизонтальными линиями на 3 секции: - Верхняя секция (секция имени) содержит имя класса и другие общие свойства (в частности, стереотип). - В средней секции содержится список атрибутов - В нижней - список операций класса, отражающих его поведение (действия, выполняемые классом). Любая из секций атрибутов и операций может не изображаться (а также обе сразу). Для отсутствующей секции не нужно рисовать разделительную линию и как-либо указывать на наличие или отсутствие элементов в ней. На усмотрение конкретной реализации могут быть введены дополнительные секции, например, исключения (Exceptions). Рисунок 4.9 - Пример диаграммы классов Стереотипы классов Стереотипы классов – это механизм, позволяющий разделять классы на категории. В языке UML определены три основных стереотипа классов: - Boundary (граница); - Entity (сущность); - Control (управление). Граничные классы Граничными классами (boundary classes) называются такие классы, которые расположены на границе системы и всей окружающей среды. Это экранные формы, отчеты, интерфейсы с аппаратурой (такой как принтеры или сканеры) и интерфейсы с другими системами. Чтобы найти граничные классы, надо исследовать диаграммы вариантов использования. Каждому взаимодействию между действующим лицом и вариантом использования должен соответствовать, по крайней мере, один граничный класс. Именно такой класс позволяет действующему лицу взаимодействовать с системой. Классы-сущности Классы-сущности (entity classes) содержат хранимую информацию. Они имеют наибольшее значение для пользователя, и потому в их названиях часто используют термины из предметной области. Обычно для каждого класса-сущности создают таблицу в базе данных. Управляющие классы Управляющие классы (control classes) отвечают за координацию действий других классов. Обычно у каждого варианта использования имеется один управляющий класс, контролирующий последовательность событий этого варианта использования. Управляющий класс отвечает за координацию, но сам не несет в себе никакой функциональности, так как остальные классы не посылают ему большого количества сообщений. Вместо этого он сам посылает множество сообщений. Управляющий класс просто делегирует ответственность другим классам, по этой причине его часто называют классом-менеджером. В системе могут быть и другие управляющие классы, общие для нескольких вариантов использования. Например, может быть класс SecurityManager (менеджер безопасности), отвечающий за контроль событий, связанных с безопасностью. Класс TransactionManager (менеджер транзакций) занимается координацией сообщений, относящихся к транзакциям с базой данных. Могут быть и другие менеджеры для работы с другими элементами функционирования системы, такими как разделение ресурсов, распределенная обработка данных или обработка ошибок. Помимо упомянутых выше стереотипов можно создавать и свои собственные. Атрибуты Атрибут – это элемент информации, связанный с классом. Атрибуты хранят инкапсулированные данные класса. Так как атрибуты содержатся внутри класса, они скрыты от других классов. В связи с этим может понадобиться указать, какие классы имеют право читать и изменять атрибуты. Это свойство называется видимостью атрибута (attribute visibility). У атрибута можно определить четыре возможных значения этого параметра: - Public (общий, открытый). Это значение видимости предполагает, что атрибут будет виден всеми остальными классами. Любой класс может просмотреть или изменить значение атрибута. В соответствии с нотацией UML общему атрибуту предшествует знак « + ». - Private (закрытый, секретный). Соответствующий атрибут не виден никаким другим классом. Закрытый атрибут обозначается знаком « – » в соответствии с нотацией UML. - Protected (защищенный). Такой атрибут доступен только самому классу и его потомкам. Нотация UML для защищенного атрибута – это знак « # ». - Package or Implementation (пакетный). Предполагает, что данный атрибут является общим, но только в пределах его пакета. Этот тип видимости не обозначается никаким специальным значком. В общем случае, атрибуты рекомендуется делать закрытыми или защищенными. Это позволяет лучше контролировать сам атрибут и код. С помощью закрытости или защищенности удается избежать ситуации, когда значение атрибута изменяется всеми классами системы. Вместо этого логика изменения атрибута будет заключена в том же классе, что и сам этот атрибут. Задаваемые параметры видимости повлияют на генерируемый код. Операции Операции реализуют связанное с классом поведение. Операция включает три части – имя, параметры и тип возвращаемого значения. Параметры – это аргументы, получаемые операцией «на входе». Тип возвращаемого значения относится к результату действия операции. На диаграмме классов можно показывать как имена операций, так и имена операций вместе с их параметрами и типом возвращаемого значения. Чтобы уменьшить загруженность диаграммы, полезно бывает на некоторых из них показывать только имена операций, а на других их полную сигнатуру. В языке UML операции имеют следующую нотацию: Имя Операции (аргумент: тип данных аргумента, аргумент2:тип данных аргумента2,...): тип возвращаемого значения Следует рассмотреть четыре различных типа операций: - Операции реализации; - Операции управления; - Операции доступа; - Вспомогательные операции. Операции реализации Операции реализации (implementor operations) реализуют некоторые бизнесфункции. Такие операции можно найти, исследуя диаграммы взаимодействия. Диаграммы этого типа фокусируются на бизнес-функциях, и каждое сообщение диаграммы, скорее всего, можно соотнести с операцией реализации. Каждая операция реализации должна быть легко прослеживаема до соответствующего требования. Это достигается на различных этапах моделирования. Операция выводится из сообщения на диаграмме взаимодействия, сообщения исходят из подробного описания потока событий, который создается на основе варианта использования, а последний – на основе требований. Возможность проследить всю эту цепочку позволяет гарантировать, что каждое требование будет реализовано в коде, а каждый фрагмент кода реализует какое-то требование. Операции управления Операции управления (manager operations) управляют созданием и уничтожением объектов. В эту категорию попадают конструкторы и деструкторы классов. Операции доступа Атрибуты обычно бывают закрытыми или защищенными. Тем не менее, другие классы иногда должны просматривать или изменять их значения. Для этого существуют операции доступа (access operations). Такой подход дает возможность безопасно инкапсулировать атрибуты внутри класса, защитив их от других классов, но все же позволяет осуществить к ним контролируемый доступ. Создание операций Get и Set (получения и изменения значения) для каждого атрибута класса является стандартом. Вспомогательные операции Вспомогательными (helper operations) называются такие операции класса, которые необходимы ему для выполнения его ответственностей, но о которых другие классы не должны ничего знать. Это закрытые и защищенные операции класса. Чтобы идентифицировать операции, выполните следующие действия: Изучите диаграммы последовательности и кооперативные диаграммы. Большая часть сообщений на этих диаграммах является операциями реализации. Рефлексивные сообщения будут вспомогательными операциями. Рассмотрите управляющие операции. Может потребоваться добавить конструкторы и деструкторы. Рассмотрите операции доступа. Для каждого атрибута класса, с которым должны будут работать другие классы, надо создать операции Get и Set. Связи Связь представляет собой семантическую взаимосвязь между классами. Она дает классу возможность узнавать об атрибутах, операциях и связях другого класса. Иными словами, чтобы один класс мог послать сообщение другому на диаграмме последовательности или кооперативной диаграмме, между ними должна существовать связь. Существуют четыре типа связей, которые могут быть установлены между классами: ассоциации, зависимости, агрегации и обобщения. Ассоциации Ассоциация (association) – это семантическая связь между классами. Их рисуют на диаграмме классов в виде обыкновенной линии. Рисунок 4.10 - Связь ассоциация Ассоциации могут быть двунаправленными, как в примере, или однонаправленными. На языке UML двунаправленные ассоциации рисуют в виде простой линии без стрелок или со стрелками с обеих ее сторон. На однонаправленной ассоциации изображают только одну стрелку, показывающую ее направление. Направление ассоциации можно определить, изучая диаграммы последовательности и кооперативные диаграммы. Если все сообщения на них отправляются только одним классом и принимаются только другим классом, но не наоборот, между этими классами имеет место однонаправленная связь. Если хотя бы одно сообщение отправляется в обратную сторону, ассоциация должна быть двунаправленной. Ассоциации могут быть рефлексивными. Рефлексивная ассоциация предполагает, что один экземпляр класса взаимодействует с другими экземплярами этого же класса. Зависимости Связи зависимости (dependency) также отражают связь между классами, но они всегда однонаправлены и показывают, что один класс зависит от определений, сделанных в другом. Например, класс A использует методы класса B. Тогда при изменении класса B необходимо произвести соответствующие изменения в классе A. Зависимость изображается пунктирной линией, проведенной между двумя элементами диаграммы, и считается, что элемент, привязанный к концу стрелки, зависит от элемента, привязанного к началу этой стрелки. Рисунок 4.11 - Связь зависимость При генерации кода для этих классов к ним не будут добавляться новые атрибуты. Однако, будут созданы специфические для языка операторы, необходимые для поддержки связи. Агрегации Агрегации (aggregations) представляют собой более тесную форму ассоциации. Агрегация – это связь между целым и его частью. Например, у вас может быть класс Автомобиль, а также классы Двигатель, Покрышки и классы для других частей автомобиля. В результате объект класса Автомобиль будет состоять из объекта класса Двигатель, четырех объектов Покрышек и т. д. Агрегации визуализируют в виде линии с ромбиком у класса, являющегося целым: Рисунок 4.12 - Связь агрегация В дополнение к простой агрегации UML вводит более сильную разновидность агрегации, называемую композицией. Согласно композиции, объект-часть может принадлежать только единственному целому, и, кроме того, как правило, жизненный цикл частей совпадает с циклом целого: они живут и умирают вместе с ним. Любое удаление целого распространяется на его части. Такое каскадное удаление нередко рассматривается как часть определения агрегации, однако оно всегда подразумевается в том случае, когда множественность роли составляет 1..1; например, если необходимо удалить Клиента, то это удаление должно распространиться и на Заказы (и, в свою очередь, на Строки заказа). Обобщения (Наследование) Обобщение (наследование) - это отношение типа общее-частное между элементами модели. С помощью обобщений (generalization) показывают связи наследования между двумя классами. Рисунок 4.13 - Пример связи наследование Большинство объектно-ориентированных языков непосредственно поддерживают концепцию наследования. Она позволяет одному классу наследовать все атрибуты, операции и связи другого. Наследование пакетов означает, что в пакетенаследнике все сущности пакета-предка будут видны под своими собственными именами (т.е. пространства имен объединяются). Наследование показывается сплошной линией, идущей от класса-потомка к классу-предку (в терминологии ООП - от потомка к предку, от сына к отцу, или от подкласса к суперклассу). Со стороны более общего элемента рисуется большой полый треугольник. Помимо наследуемых, каждый подкласс имеет свои собственные уникальные атрибуты, операции и связи. Множественность Множественность (multiplicity) показывает, сколько экземпляров одного класса взаимодействуют с помощью этой связи с одним экземпляром другого класса в данный момент времени. Например, при разработке системы регистрации курсов в университете можно определить классы Course (курс) и Student (студент). Между ними установлена связь: у курсов могут быть студенты, а у студентов – курсы. Вопросы, на который должен ответить параметр множественности: «Сколько курсов студент может посещать в данный момент? Сколько студентов может за раз посещать один курс?» Так как множественность дает ответ на оба эти вопроса, еѐ индикаторы устанавливаются на обоих концах линии связи. В примере регистрации курсов мы решили, что один студент может посещать от нуля до четырех курсов, а один курс могут слушать от 0 до 20 студентов. В языке UML приняты определенные нотации для обозначения множественности. Таблица 4.1 - Обозначения множественности связей в UML Имена связей Связи можно уточнить с помощью имен связей или ролевых имен. Имя связи – это обычно глагол или глагольная фраза, описывающая, зачем она нужна. Например, между классом Person (человек) и классом Company (компания) может существовать ассоциация. Можно задать в связи с этим вопрос, является ли объект класса Person клиентом компании, еѐ сотрудником или владельцем? Чтобы определить это, ассоциацию можно назвать «employs» (нанимает): Рисунок 4.14 - Пример имен связей Роли Ролевые имена применяют в связях ассоциации или агрегации вместо имен для описания того, зачем эти связи нужны. Возвращаясь к примеру с классами Person и Company, можно сказать, что класс Person играет роль сотрудника класса Company. Ролевые имена – это обычно имена существительные или основанные на них фразы, их показывают на диаграмме рядом с классом, играющим соответствующую роль. Как правило, пользуются или ролевым именем, или именем связи, но не обоими сразу. Как и имена связей, ролевые имена не обязательны, их дают, только если цель связи не очевидна. Пример ролей приводится ниже: Рисунок 4.15 - Пример ролей связей Пакет. Механизм пакетов В контексте диаграмм классов, пакет - это вместилище для некоторого набора классов и других пакетов. Пакет является самостоятельным пространством имен. Рисунок 4.16 - Обозначение пакета в UML В UML нет каких-либо ограничений на правила, по которым разработчики могут или должны группировать классы в пакеты. Но есть некоторые стандартные случаи, когда такая группировка уместна, например, тесно взаимодействующие классы, или более общий случай - разбиение системы на подсистемы. Пакет физически содержит сущности, определенные в нем (говорят, что "сущности принадлежат пакету"). Это означает, что если будет уничтожен пакет, то будут уничтожено и все его содержимое. Существует несколько наиболее распространенных подходов к группировке. Во-первых, можно группировать их по стереотипу. В таком случае получается один пакет с классами-сущностями, один с граничными классами, один с управляющими классами и т.д. Этот подход может быть полезен с точки зрения размещения готовой системы, поскольку все находящиеся на клиентских машинах пограничные классы уже оказываются в одном пакете. Другой подход заключается в объединении классов по их функциональности. Например, в пакете Security (безопасность) содержатся все классы, отвечающие за безопасность приложения. В таком случае другие пакеты могут называться Employee Maintenance (Работа с сотрудниками), Reporting (Подготовка отчетов) и Error Handling (Обработка ошибок). Преимущество этого подхода заключается в возможности повторного использования. Механизм пакетов применим к любым элементам модели, а не только к классам. Если для группировки классов не использовать некоторые эвристики, то она становится произвольной. Одна из них, которая в основном используется в UML, – это зависимость. Зависимость между двумя пакетами существует в том случае, если между любыми двумя классами в пакетах существует любая зависимость. Таким образом, диаграмма пакетов представляет собой диаграмму, содержащую пакеты классов и зависимости между ними. Строго говоря, пакеты и зависимости являются элементами диаграммы классов, то есть диаграмма пакетов – это форма диаграммы классов. Рисунок 4.17 - Пример диаграммы пакетов Зависимость между двумя элементами имеет место в том случае, если изменения в определении одного элемента могут повлечь за собой изменения в другом. Что касается классов, то причины для зависимостей могут быть самыми разными: - один класс посылает сообщение другому; - один класс включает часть данных другого класса; один класс использует другой в качестве параметра операции. Если класс меняет свой интерфейс, то любое сообщение, которое он посылает, может утратить свою силу. Пакеты не дают ответа на вопрос, каким образом можно уменьшить количество зависимостей в вашей системе, однако они помогают выделить эти зависимости, а после того, как они все окажутся на виду, остается только поработать над снижением их количества. Диаграммы пакетов можно считать основным средством управления общей структурой системы. Пакеты являются жизненно необходимым средством для больших проектов. Их следует использовать в тех случаях, когда диаграмма классов, охватывающая всю систему в целом и размещенная на единственном листе бумаги формата А4, становится нечитаемой. Диаграммы состояний Диаграммы состояний определяют все возможные состояния, в которых может находиться конкретный объект, а также процесс смены состояний объекта в результате наступления некоторых событий. Существует много форм диаграмм состояний, незначительно отличающихся друг от друга семантикой. На диаграмме имеются два специальных состояния – начальное (start) и конечное (stop). Начальное состояние выделено черной точкой, оно соответствует состоянию объекта, когда он только что был создан. Конечное состояние обозначается черной точкой в белом кружке, оно соответствует состоянию объекта непосредственно перед его уничтожением. На диаграмме состояний может быть одно и только одно начальное состояние. В то же время, может быть столько конечных состояний, сколько вам нужно, или их может не быть вообще. Когда объект находится в какомто конкретном состоянии, могут выполняться различные процессы. Процессы, происходящие, когда объект находится в определенном состоянии, называются действиями (actions). С состоянием можно связывать данные пяти типов: деятельность, входное действие, выходное действие, событие и история состояния. Деятельность Деятельностью (activity) называется поведение, реализуемое объектом, пока он находится в данном состоянии. Деятельность – это прерываемое поведение. Оно может выполняться до своего завершения, пока объект находится в данном состоянии, или может быть прервано переходом объекта в другое состояние. Деятельность изображают внутри самого состояния, ей должно предшествовать слово do (делать) и двоеточие. Входное действие Входным действием (entry action) называется поведение, которое выполняется, когда объект переходит в данное состояние. Данное действие осуществляется не после того, как объект перешел в это состояние, а, скорее, как часть этого перехода. В отличие от деятельности, входное действие рассматривается как непрерываемое. Входное действие также показывают внутри состояния, ему предшествует слово entry (вход) и двоеточие. Выходное действие Выходное действие (exit action) подобно входному. Однако, оно осуществляется как составная часть процесса выхода из данного состояния. Оно является частью процесса такого перехода. Как и входное, выходное действие является непрерываемым. Выходное действие изображают внутри состояния, ему предшествует слово exit (выход) и двоеточие. Поведение объекта во время деятельности, при входных и выходных действиях может включать отправку события другому объекту. В этом случае описанию деятельности, входного действия или выходного действия предшествует знак « ^ ». Соответствующая строка на диаграмме выглядит как Do: ^Цель.Событие (Аргументы) Здесь Цель – это объект, получающий событие, Событие – это посылаемое сообщение, а Аргументы являются параметрами посылаемого сообщения. Деятельность может также выполняться в результате получения объектом некоторого события. При получении некоторого события выполняется определенная деятельность. Переходом (Transition) называется перемещение из одного состояния в другое. Совокупность переходов диаграммы показывает, как объект может перемещаться между своими состояниями. На диаграмме все переходы изображают в виде стрелки, начинающейся на первоначальном состоянии и заканчивающейся последующим. Переходы могут быть рефлексивными. Объект может перейти в то же состояние, в котором он в настоящий момент находится. Рефлексивные переходы изображают в виде стрелки, начинающейся и завершающейся на одном и том же состоянии. У перехода существует несколько спецификаций. Они включают события, аргументы, ограждающие условия, действия и посылаемые события. События Событие (event) – это то, что вызывает переход из одного состояния в другое. Событие размещают на диаграмме вдоль линии перехода. На диаграмме для отображения события можно использовать как имя операции, так и обычную фразу. Большинство переходов должны иметь события, так как именно они, прежде всего, заставляют переход осуществиться. Тем не менее, бывают и автоматические переходы, не имеющие событий. При этом объект сам перемещается из одного состояния в другое со скоростью, позволяющей осуществиться входным действиям, деятельности и выходным действиям. Ограждающие условия Ограждающие условия (guard conditions) определяют, когда переход может, а когда не может осуществиться. В противном случае переход не осуществится. Ограждающие условия изображают на диаграмме вдоль линии перехода после имени события, заключая их в квадратные скобки. Ограждающие условия задавать необязательно. Однако если существует несколько автоматических переходов из состояния, необходимо определить для них взаимно исключающие ограждающие условия. Это поможет читателю диаграммы понять, какой путь перехода будет автоматически выбран. Действие Действием (action), как уже говорилось, является непрерываемое поведение, осуществляющееся как часть перехода. Входные и выходные действия показывают внутри состояний, поскольку они определяют, что происходит, когда объект входит или выходит из него. Большую часть действий, однако, изображают вдоль линии перехода, так как они не должны осуществляться при входе или выходе из состояния. Действие рисуют вдоль линии перехода после имени события, ему предшествует косая черта. Событие или действие могут быть поведением внутри объекта, а могут представлять собой сообщение, посылаемое другому объекту. Если событие или действие посылается другому объекту, перед ним на диаграмме помещают знак « ^ ». Рисунок 4.18 - Пример диаграммы состояний Диаграммы состояний не надо создавать для каждого класса, они применяются только в сложных случаях. Если объект класса может существовать в нескольких состояниях и в каждом из них ведет себя по-разному, для него может потребоваться такая диаграмма. Диаграммы размещения Диаграмма размещения (deployment diagram) отражает физические взаимосвязи между программными и аппаратными компонентами системы. Она является хорошим средством для того, чтобы показать маршруты перемещения объектов и компонентов в распределенной системе. Каждый узел на диаграмме размещения представляет собой некоторый тип вычислительного устройства – в большинстве случаев, часть аппаратуры. Эта аппаратура может быть простым устройством или датчиком, а может быть и мэйнфреймом. Диаграмма размещения показывает физическое расположение сети и местонахождение в ней различных компонентов. Рисунок 4.19 - Пример диаграммы размещения Диаграмма размещения используется менеджером проекта, пользователями, архитектором системы и эксплуатационным персоналом, чтобы понять физическое размещение системы и расположение еѐ отдельных подсистем. Диаграммы компонентов Диаграммы компонентов показывают, как выглядит модель на физическом уровне. На них изображены компоненты программного обеспечения и связи между ними. При этом на такой диаграмме выделяют два типа компонентов: исполняемые компоненты и библиотеки кода. Каждый класс модели (или подсистема) преобразуется в компонент исходного кода. После создания они сразу добавляются к диаграмме компонентов. Между отдельными компонентами изображают зависимости, соответствующие зависимостям на этапе компиляции или выполнения программы. Рисунок 4.20 -. Пример диаграммы компонентов Диаграммы компонентов применяются теми участниками проекта, кто отвечает за компиляцию системы. Из нее видно, в каком порядке надо компилировать компоненты, а также какие исполняемые компоненты будут созданы системой. На такой диаграмме показано соответствие классов реализованным компонентам. Она нужна там, где начинается генерация кода. Объединение диаграмм компонентов и развертывания В некоторых случаях допускается размещать диаграмму компонентов на диаграмме развертывания. Это позволяет показать, какие компоненты выполняются и на каких узлах. Постановка задачи к лабораторной работе 4 1. Изучить предлагаемый теоретический материал. 2. Постройте диаграмму вариантов использования для выбранной информационной системы. 3. Выполните реализацию вариантов использования в терминах взаимодействующих объектов и представляющую собой набор диаграмм: 3.1 диаграмм классов, реализующих вариант использования; 3.2 диаграмм взаимодействия (диаграмм последовательности и кооперативных диаграмм), отражающих взаимодействие объектов в процессе реализации варианта использования. 4. Разделить классы по пакетам, используя один из механизм разбиения. 5. Постройте диаграмму состояний для конкретных объектов информационной системы. 6. Построить отчѐт, включающий все полученные уровни модели, описание функциональных блоков, потоков данных, хранилищ и внешних объектов. Представить отчет по практической работе для защиты. Варианты индивидуальных заданий В соответствии с указанной предметной областью и классом разрабатываемой информационной системы постройте диаграмму вариантов использования для выбранной информационной системы, выполните реализацию вариантов использования, постройте диаграмму состояний для конкретных объектов информационной системы. Таблица 4.2 – Индивидуальные задания № Предметная область Класс ИС 1 Склад MRP 2 Производственное предприятие ERP 3 Торговое предприятие CRM 4 Торговое предприятие SCM 5 Торговое предприятие B2C 6 Портал В2В 7 Строительное предприятие ИС учета 8 Высшее учебное заведение ИС управления 9 Инфраструктура предприятия СППР 10 Аппаратная инфраструктура предприятия Экспертная система Содержание отчета По выполненной работе составляется отчет. Отчет выполняется в электронном виде. По выполненному отчету проводится защита лабораторной работы. Отчет по лабораторной работе должен состоять из следующих структурных элементов: - титульный лист; - вводная часть; - основная часть (описание работы): диаграмма вариантов использования информационной системы, диаграмма состояний для объектов информационной системы; - заключение (выводы). Вводная часть отчета должна включать пункты: - условие задачи; - порядок выполнения. - программно-аппаратные средства, используемые при выполнении работы. Зашита отчета заключается в предъявлении преподавателю полученных результатов в виде файла и демонстрации полученных навыков при ответах на вопросы преподавателя. Контрольные вопросы 1. Дайте определение понятию «вариант использования». 2. Какие типы связи могут присутствовать на диаграмме вариантов использования? 3. Дайте определение понятию «действующее лицо». 4. Какие типы сообщений могут присутствовать на диаграммах взаимодействия? 5. Дайте определение понятию класс, объект класса. 6. Кем и для чего может быть использована диаграмма размещения? Лабораторная работа 5. Проектирование базы данных информационной системы Цель работы: Изучить и применить на практике проектирование базы данных информационной системы. Основы теории Базовые понятия ERD Сущность (Entity) — множество экземпляров реальных или абстрактных объектов (людей, событий, состояний, идей, предметов и др.), обладающих общими атрибутами или характеристиками. Любой объект системы может быть представлен только одной сущностью, которая должна быть уникально идентифицирована. При этом имя сущности должно отражать тип или класс объекта, а не его конкретный экземпляр (например, АЭРОПОРТ, а не ВНУКОВО). Каждая сущность должна обладать уникальным идентификатором. Каждый экземпляр сущности должен однозначно идентифицироваться и отличаться от всех других экземпляров данного типа сущности. Каждая сущность должна обладать некоторыми свойствами: - иметь уникальное имя; к одному и тому же имени должна всегда применяться одна и та же интерпретация; одна и та же интерпретация не может применяться к различным именам, если только они не являются псевдонимами; - иметь один или несколько атрибутов, которые либо принадлежат сущности, либо наследуются через связь; - иметь один или несколько атрибутов, которые однозначно идентифицируют каждый экземпляр сущности. Каждая сущность может обладать любым количеством связей с другими сущностями модели. Связь (Relationship) — поименованная ассоциация между двумя сущностями, значимая для рассматриваемой предметной области. Связь — это ассоциация между сущностями, при которой каждый экземпляр одной сущности ассоциирован с произвольным (в том числе нулевым) количеством экземпляров второй сущности, и наоборот. Атрибут (Attribute) — любая характеристика сущности, значимая для рассматриваемой предметной области и предназначенная для квалификации, идентификации, классификации, количественной характеристики или выражения состояния сущности. Атрибут представляет тип характеристик или свойств, ассоциированных с множеством реальных или абстрактных объектов (людей, мест, событий, состояний, идей, предметов и т.д.). Экземпляр атрибута — это определенная характеристика отдельного элемента множества. Экземпляр атрибута определяется типом характеристики и ее значением, называемым значением атрибута. На диаграмме "сущность-связь" атрибуты ассоциируются с конкретными сущностями. Таким образом, экземпляр сущности должен обладать единственным определенным значением для ассоциированного атрибута. Метод IDEFI Наиболее распространенными методами для построения ERD-диаграмм являются метод Баркера и метод IDEFI. Метод Баркера основан на нотации, предложенной автором, и используется в caseсредстве Oracle Designer. Метод IDEFI основан на подходе Чена и позволяет построить модель данных, эквивалентную реляционной модели в третьей нормальной форме. На основе совершенствования метода IDEFI создана его новая версия — метод IDEFIX, разработанный с учетом таких требований, как простота для изучения и возможность автоматизации. IDEFIX-диаграммы используются в ряде распространенных CASE-средств (в частности, ERwin, Design/IDEF). В методе IDEFIX сущность является независимой от идентификаторов или просто независимой, если каждый экземпляр сущности может быть однозначно идентифицирован без определения его отношений с другими сущностями. Сущность называется зависимой от идентификаторов или просто зависимой, если однозначная идентификация экземпляра сущности зависит от его отношения к другой сущности. Рисунок 5.1 - Независимые от идентификации сущности Рисунок 5.2 - Зависимые от идентификации сущности Каждой сущности присваиваются уникальные имя и номер, разделяемые косой чертой "/" и помещаемые над блоком. Связь может дополнительно определяться с помощью указания степени или мощности (количества экземпляров сущности-потомка, которое может порождать каждый экземпляр сущности-родителя). В IDEFIX могут быть выражены следующие мощности связей: - каждый экземпляр сущности-родителя может иметь ноль, один или более одного связанного с ним экземпляра сущности-потомка; - каждый экземпляр сущности-родителя должен иметь не менее одного связанного с ним экземпляра сущности-потомка; - каждый экземпляр сущности-родителя должен иметь не более одного связанного с ним экземпляра сущности-потомка; - каждый экземпляр сущности-родителя связан с некоторым фиксированным числом экземпляров сущности-потомка. Если экземпляр сущности-потомка однозначно определяется своей связью с сущностью-родителем, то связь называется идентифицирующей, в противном случае — неидентифицирующей. Связь изображается линией, проводимой между сущностью-родителем и сущностью-потомком, с точкой на конце линии у сущности-потомка. Мощность связей может принимать следующие значения: N — ноль, один или более, Z — ноль или один, Р — один или более. По умолчанию мощность связей принимается равной N. Рисунок 5.3 - Графическое изображение мощности связи Идентифицирующая связь между сущностью-родителем и сущностью-потомком изображается сплошной линией. Сущность-потомок в идентифицирующей связи является зависимой от идентификатора сущностью. Сущность-родитель в идентифицирующей связи может быть как независимой, так и зависимой от идентификатора сущностью (это определяется ее связями с другими сущностями). Пунктирная линия изображает неидентифицирующую связь. Сущность-потомок в неидентифицирующей связи будет не зависимой от идентификатора, если она не является также сущностью-потомком в какой-либо идентифицирующей связи. Атрибуты изображаются в виде списка имен внутри блока сущности. Атрибуты, определяющие первичный ключ, размещаются наверху списка и отделяются от других атрибутов горизонтальной чертой. Сущности могут иметь также внешние ключи (Foreign Key), которые могут использоваться в качестве части или целого первичного ключа или неключевого атрибута. Для обозначения внешнего ключа внутрь блока сущности помещают имена атрибутов, после которых следуют буквы FK в скобках. Рисунок 5.4 - Неидентифицирующая связь Документирование модели Многие СУБД имеют ограничение на именование объектов (например, ограничение на длину имени таблицы или запрет использования специальных символов — пробела и т. п.). Зачастую разработчики ИС имеют дело с нелокализованными версиями СУБД. Это означает, что объекты БД могут называться короткими словами, только латинскими символами и без использования специальных символов (т. е. нельзя назвать таблицу, используя предложение — ее можно назвать только одним словом). Кроме того, проектировщики БД нередко злоупотребляют "техническими" наименованиями, в результате таблица и колонки получают наименования типа RTD_324 или CUST_A12 и т.д. Полученную в результате структуру могут понять только специалисты (а чаще всего — только авторы модели), ее невозможно обсуждать с экспертами предметной области. Разделение модели на логическую и физическую позволяет решить эту проблему. На физическом уровне объекты БД могут называться так, как того требуют ограничения СУБД. На логическом уровне можно этим объектам дать синонимы — имена более понятные неспециалистам, в том числе на кириллице и с использованием специальных символов. Например, таблице CUST_A12 может соответствовать сущность Постоянный клиент. Такое соответствие позволяет лучше документировать модель и дает возможность обсуждать структуру данных с экспертами предметной области. Уровни логической модели Различают три уровня логической модели, отличающихся по глубине представления информации о данных: - диаграмма сущность-связь (Entity Relationship Diagram, ERD); - модель данных, основанная на ключах (Key Based model, KB); - полная атрибутивная модель (Fully Attributed model, FA). Диаграмма сущность-связь представляет собой модель данных верхнего уровня. Она включает сущности и взаимосвязи, отражающие основные бизнес-правила предметной области. Такая диаграмма не слишком детализирована, в нее включаются основные сущности и связи между ними, которые удовлетворяют основным требованиям, предъявляемым к ИС. Диаграмма сущность-связь может включать связи "многие-комногим" и не включать описание ключей. Как правило, ERD используется для презентаций и обсуждения структуры данных с экспертами предметной области. Модель данных, основанная на ключах, — более подробное представление данных. Она включает описание всех сущностей и первичных ключей и предназначена для представления структуры данных и ключей, которые соответствуют предметной области. Полная атрибутивная модель — наиболее детальное представление структуры данных: представляет данные в третьей нормальной форме и включает все сущности, атрибуты и связи. Создание физической модели данных Физическая модель содержит всю информацию, необходимую для реализации конкретной БД. Различают два уровня физической модели: - трансформационную модель; - модель СУБД. Трансформационная модель содержит информацию для реализации отдельного проекта, который может быть частью общей ИС и описывать подмножество предметной области. Данная модель позволяет проектировщикам и администраторам БД лучше представить, какие объекты БД хранятся в словаре данных, и проверить, насколько физическая модель удовлетворяет требованиям к ИС. Модель СУБД автоматически генерируется из трансформационной модели и является точным отображением системного каталога СУБД. Физический уровень представления модели зависит от выбранного сервера. ERwin поддерживает более 20 реляционных и нереляционных БД. Модель сущность-связь Модель была предложена Петером Пин-Шен Ченом в 1976 г. На использовании разновидностей ER-модели основано большинство современных подходов к проектированию баз данных (главным образом, реляционных). Моделирование предметной области базируется на использовании графических диаграмм, включающих небольшое число разнородных компонентов. В связи с наглядностью представления концептуальных схем баз данных ER-модели получили широкое распространение в CASE-системах, поддерживающих автоматизированное проектирование реляционных баз данных. Базовыми понятиями ER-модели являются сущность, связь и атрибут. Сущность - это реальный или воображаемый объект, информация о котором представляет интерес. В диаграммах ER-модели сущность пред-ставляется в виде прямоугольника, содержащего имя сущности. При этом имя сущности - это имя типа, а не конкретного объекта - экземпляра этого типа. Каждый экземпляр сущности должен быть отличим от любого другого экземпляра той же сущности. Связь - это графически изображаемая ассоциация, устанавливаемая между двумя сущностями. Эта ассоциация всегда является бинарной и может существовать между двумя разными сущностями или между сущностью и ей же самой (рекурсивная связь). В любой связи выделяются два конца (в соответствии с парой связываемых сущностей), на каждом из которых указывается имя конца связи, степень конца связи (сколько экземпляров данной сущности связывается), обязательность связи (т. е. любой ли экземпляр данной сущности должен участвовать в данной связи). Связь представляется в виде линии, связывающей две сущности или ведущей от сущности к ней же самой. При этом в месте "стыковки" связи с сущностью используются трехточечный вход в прямоугольник сущности, если для этой сущности в связи могут использоваться много экземпляров сущности, и одноточечный вход, если в связи может участвовать только один экземпляр сущности. Обязательный конец связи изображается сплошной линией, а необязательный - прерывистой линией. Как и сущность, связь - это типовое понятие, все экземпляры обеих пар связываемых сущностей подчиняются правилам связывания. На рис. приведен пример изображения сущностей и связи между ними. Пример связи между сущностями Данная диаграмма может быть интерпретирована следующим образом: Каждый СТУДЕНТ учится только в одной ГРУППЕ; Любая ГРУППА состоит из одного или более СТУДЕНТОВ. На следующем рисунке изображена сущность ЧЕЛОВЕК с рекурсивной связью, связывающей ее с ней же самой. Пример рекурсивной связи Лаконичной устной трактовкой изображенной диаграммы является следующая: Каждый ЧЕЛОВЕК является сыном одного и только одного ЧЕЛОВЕКА; Каждый ЧЕЛОВЕК может являться отцом для одного или более ЛЮДЕЙ ("ЧЕЛОВЕК"). Атрибутом сущности является любая деталь, которая служит для уточнения, идентификации, классификации, числовой характеристики или выражения состояния сущности. Имена атрибутов заносятся в прямоугольник, изображающий сущность, под именем сущности и изображаются малыми буквами. Например: Изображение сущности с ее атрибутами Уникальным идентификатором сущности является атрибут, комбинация атрибутов, комбинация связей или комбинация связей и атрибутов, уникально отличающая любой экземпляр сущности от других экземпляров сущности того же типа. Как и в реляционных схемах баз данных, в ER-схемах вводится понятие нормальных форм, причем их смысл очень близко соответствует смыслу реляционных нормальных форм. Заметим, что формулировки нормальных форм ER-схем делают более понятным смысл нормализации реляционных схем. Мы рассмотрим только очень краткие и неформальные определения трех первых нормальных форм. В первой нормальной форме ER-схемы устраняются повторяющиеся атрибуты или группы атрибутов, т. е. производится выявление неявных сущностей, "замаскированных" под атрибуты. Во второй нормальной форме устраняются атрибуты, зависящие только от части уникального идентификатора. Эта часть уникального идентификатора определяет отдельную сущность. В третьей нормальной форме устраняются атрибуты, зависящие от атрибутов, не входящих в уникальный идентификатор. Эти атрибуты являются основой отдельной сущности.Мы остановились только на самых важных понятиях ER-модели данных. К числу более сложных элементов модели относятся следующие: Подтипы и супертипы сущностей. ER-модель позволяет задавать отношение IS-A между типами. При этом если Т1 IS-A Т2 (где Т1 и T2 - типы сущностей), то Т1 называется подтипом Т2 а Т2- супертипом Т1. Т.о., существует возможность наследования типа сущности, исходя из одного или нескольких супертипов. Связи "многие-со-многими". Иногда бывает необходимо связывать сущности таким образом, что с обоих концов связи могут присутствовать несколько экземпляров сущности (например, все члены кооператива сообща владеют имуществом кооператива). Для этого вводится разновидность связи "многие-со-многими". Уточняемые степени связи. Иногда бывает полезно определить возможное количество экземпляров сущности, участвующих в данной связи (например, служащему разрешается участвовать не более чем в трех проектах одновременно). Для выражения этого семантического ограничения разрешается указывать на конце связи ее максимальную или обязательную степень. Каскадные удаления экземпляров сущностей. Некоторые связи бывают настолько сильными (конечно, в случае связи "один-ко-многим"), что при удалении опорного экземпляра сущности (соответствующего концу связи "один") нужно удалить и все экземпляры сущности, соответствующие концу связи "многие". Соответствующее требование "каскадного удаления" можно сформулировать при определении сущности. Домены. Как и в случае реляционной модели данных, бывает полезна возможность определения потенциально допустимого множества значений атрибута сущности (домена). Эти и другие, более сложные элементы модели данных "Сущность-Связь", делают ее более мощной, но одновременно несколько усложняют ее использование. Конечно, при реальном использовании ER-диаграмм для проектирования баз данных необходимо ознакомиться со всеми возможностями. Программные средства проектирования реляционных баз данных BPwin - инструмент моделирования с возможностью анализа, документирования и корректирования бизнес процессов. Он поможет устранить лишние или неэффективные операции, уменьшить издержки, повысить гибкость и улучшить уровень обслуживания заказчика. В модели BPwin, Вы можете четко задокументировать важные позиции, такие как необходимые операции, проследить, как они выполняются и какие необходимы для этого ресурсы. Модель BPwin обеспечивает интегрированное изображение того, как работает ваша организация. Это изображение, в свою очередь, состоит из подмоделей отделов, пример которых приведен ниже в общей диаграмме дерева узлов. BPwin поддерживает двунаправленные линии связи с программой ERwin. ERwin - инструмент моделирования данных для разработки базы данных, который поддерживает методологии IDEF1X и IE . Вы можете совместно использовать BPwin и ERwin как для моделирования процесса, так и для моделирования данных и Вы можете обмениваться объектами и названиями атрибута между двумя программами. Эта возможность особенно полезна для пользователей, кто разрабатывает модель бизнес процесса и модель базы данных одновременно. Любые изменения, которые Вы проводите в объекте и названии атрибута в любой модели, могут быть внесены в другую модель. Вы можете также создать двухсторонние линии связи между моделью BPwin и связанной с ней моделью ERwin, что выполняется, автоматически каждый раз, когда Вы открываете одну из связанных диаграмм. Это проводится для синхронизации моделей. Средство автоматизированного проектирования баз данных ERwin ERwin - CASE-средство проектирования баз данных фирмы Platinum. ERwin сочетает графический интерфейс Windows, инструменты для построения ER-диаграмм, редакторы для создания логического и физического описания модели данных и прозрачную поддержку ведущих реляционных СУБД. Для удобства изложения материала здесь и далее использована оригинальная терминология, принятая в ERwin. ERwin не привязан к технологии какой-либо конкретной фирмы, поставляющей СУБД или средства разработки. Он поддерживает различные серверы баз данных и настольные СУБД, а также может обращаться к базе данных через интерфейс ODBC. ERwin можно использовать совместно с некоторыми популярными средствами разработки клиентских частей приложений: PowerBuilder, Visual Basic, Delphi. Кроме того, ERwin поддерживает работу в среде групповой разработки ModelMart, являющейся продуктом той же Platinum. Процесс моделирования в ERwin базируется на методологии проектирования реляционных баз данных IDEF1X. Данная методология была разработана для ВВС США и теперь широко используется в правительственных учреждениях и частных компаниях как в самих США, так и далеко за их пределами. Она определяет стандарты терминологии и графического изображения типовых элементов на ER-диаграммах. Структура процесса моделирования в ERwin В ERwin используются два уровня представления модели данных: логический и физический (что соответствует концептуальному и логическому уровню, принятым в теории БД). На логическом уровне не рассматривается использование конкретной СУБД, не определяются типы данных (например, целое или вещественное число) и не определяются индексы для таблиц. Целевая СУБД, имена объектов и типы данных, индексы составляют второй (физический) уровень модели ERwin. ERwin предоставляет возможности создавать и управлять этими двумя различными уровнями представления одной диаграммы (модели), равно как и иметь много вариантов отображения на каждом уровне. Процесс построения информационной модели состоит из следующих этапов: 1. Создание логической модели данных: • определение сущностей; • определение зависимостей между сущностями; • задание первичных и альтернативных ключей; • определение неключевых атрибутов сущностей. 2. Переход к физическому описанию модели: • назначение соответствий имя сущности - имя таблицы, атрибут сущности атрибут таблицы; • задание триггеров, хранимых процедур и ограничений. 3. Генерация базы данных. 8.3. Создание логической модели базы данных С точки зрения пользователя ERwin, процесс создания логической модели данных заключается в визуальном редактировании ER-диаграммы. Диаграмма ERwin строится из трех основных блоков: сущностей, атрибутов и связей. На диаграмме сущность изображается прямоугольником. В зависимости от режима представления диаграммы прямоугольник может содержать имя сущности, ее описание, список ее атрибутов и другие сведения. Основная информация, описывающая сущность, включает: • атрибуты, составляющие первичный ключ; • неключевые атрибуты; • тип сущности (независимая/зависимая). Первичный ключ - это атрибут или набор атрибутов, уникально идентифицирующий экземпляр сущности. Если несколько наборов атрибутов могут уникально идентифицировать сущность, то выбор одного из них осуществляется разработчиком на основании анализа предметной области и учета следующих требований к первичному ключу. • первичный ключ не должен принимать пустые (NULL) значения; • первичный ключ не должен изменяться в течение времени; • размер первичного ключа должен быть как можно меньшим. При этом если разработчик считает, что какой-либо из оставшихся наборов будет часто использоваться для доступа к сущности, то он может объявить его альтернативным ключом. В ERwin можно также составлять группы атрибутов, которые не идентифицируют уникально экземпляры сущности, но часто используются для доступа к данным. Они получили название инверсных входов. Одни и те же атрибуты сущности могут входить в несколько различных групп ключей. Рассмотрим выше сказанное на примере сущности СОТРУДНИК (рис. 5.5). Пример сущности Среди всех атрибутов данной сущности на роль первичного ключа могут претендовать "табельный номер" и группа атрибутов "фамилия", "имя","отчество", "дата рождения" (последний необходим, т. к. на предприятии могут работать полные тезки). Очевидно, что по соображению размера в качестве первичного ключа следует выбрать первый из вариантов. На диаграмме атрибуты, составляющие первичный ключ, располагаются в верхней части прямоугольника и отделяются от прочих (не входящих в первичных ключ) горизонтальной линией. Группа атрибутов "фамилия", "имя", "отчество", "дата рождения" может являться альтернативным ключом. Однако вряд ли кто-либо, пытающийся найти информацию о сотруднике, будет знать дату его рождения. А вот группа атрибутов "фамилия", "имя", "отчество", вполне возможно, будет достаточно часто использоваться для этих целей. Поэтому на основе этих атрибутов было бы логично создать инверсный вход. Инверсный вход обозначается на диаграмме символами IEn, заключенными в скобки. Пример использования альтернативного ключа приведен на рис. 2.6. Альтернативный ключ обозначается на диаграмме символами АКп, заключенными в скобки. Пример альтернативного ключа Если экземпляры сущности могут быть уникально идентифицированы без определения ее связей с другими сущностями, она называется независимой. В противном случае сущность называют зависимой. Зависимая сущность отображается в ERwin прямоугольником с закругленными углами. Связь в ERwin трактуется как функциональная зависимость между двумя сущностями (в частности, возможна связь сущности с самой собой). Если рассматривать диаграмму как графическое представление правил предметной области, то сущности являются существительными, а связи -глаголами. Например, между сущностями ОТДЕЛ и СОТРУДНИК существует связь "состоит из" (ОТДЕЛ состоит из СОТРУДНИКОВ). В ERwin связи представлены пятью основными элементами информации: тип связи; • родительская и дочерняя (зависимая) сущности;• мощность связи; • допустимость пустых (null) значений; • требования по обеспечению ссылочной целостности. ERwin поддерживает следующие основные типы связей: идентифицирующая, неидентифицирующая, полная категория, неполная категория, многие-ко-многим. Связь называется идентифицирующей, если экземпляр дочерней сущности идентифицируется через ее связь с родительской сущностью. Атрибуты, составляющие первичный ключ родительской сущности, при этом входят в первичный ключ дочерней сущности. Дочерняя сущность при идентифицирующей связи всегда является зависимой. Связь называется неидентифицирующей, если экземпляр дочерней сущности идентифицируется иначе, чем через связь с родительской сущностью. Атрибуты, составляющие первичный ключ родительской сущности, при этом входят в состав неключевых атрибутов дочерней сущности. Идентифицирующая связь изображается сплошной линией; неидентифицирующая - пунктирной линией. Линии заканчиваются точкой со стороны дочерней сущности. При определении связи происходит миграция атрибутов первичного ключа родительской сущности в соответствующую область атрибутов дочерней сущности. Поэтому такие атрибуты не вводятся вручную. На рис. приведен пример неидентифицируюшей связи. Первичный ключ сущности ОТДЕЛ "номер отдела" мигрировал в область неключевых атрибутов (поскольку связь неидентифицируюшая) сущности СОТРУДНИК. На диаграмме атрибуты, наследованные от родительской сущности, помечаются символами FK, заключенными в скобки. Пример неидентифицирующей связи Зависимая сущность может наследовать один и тот же атрибут от более чем одной родительской сущности или от одной и той же родительской сущности через несколько связей. Поскольку атрибуты первичного ключа родительской сущности по умолчанию мигрируют со своими именами, ERwin считает, что в зависимой сущности атрибуты внешнего ключа появляются только один раз. Чтобы избежать этого ограничения, ERwin позволяет ввести для них роли, т. е. новые имена, под которыми мигрирующие атрибуты будут представлены в дочерней сущности. В случае неоднократной миграции атрибута такое переименование необходимо. Например, при создании модели сделки по обмену валюты сущность СДЕЛКА (рис. 2.8) должна иметь два различных атрибута для кодов проданной и купленной валюты. В данном случае первичный ключ сущности ВАЛЮТА ("код валюты") имеет две роли в дочерней сущности. Пример использования ролей Ситуация, когда экземпляру одной сущности соответствует один или несколько экземпляров второй сущности, а экземпляру второй сущности соответствует один или несколько экземпляров первой сущности, отражается в логической модели связью многиеко-мпогим между данными сущностями. На диаграмме связь изображается сплошной линией с точками на концах. Например, для заключения сделки в некоторой фирме клиент обращается к любому из свободных сотрудников этой фирмы. В то же время сотрудник фирмы может обслуживать нескольких клиентов. Поэтому тип связи между сущностями КЛИЕНТ и СОТРУДНИК должен быть мно-гие-ко-многим (рис. 5.6). Пример связи многие-ко-мпогим Заметим, что связь типа многие-ко-многим возможна только на логическом уровне. Преобразование связи данного типа на физическом уровне будет рассмотрена в следующем пункте. Однако добавим, что связи многие-ко-многим рекомендуется избегать. В рассмотренном примере этого можно добиться, если ввести дополнительную сущность СДЕЛКА. Пример устранения связи многие-ко-многим Некоторые сущности определяют целую категорию объектов одного типа. В ERwin в таком случае создается сущность для определения категории и для каждого элемента категории, а затем вводится для них связь категоризации. Родительская сущность категории называется супертипом, а дочерние - подтипом. Пример неполной категории Пример полной категории Различная часть (например, данные почасовой оплаты для временных работников или данные о зарплате и отпуске для штатных работников) помещается в сущности- подтипы. В сущности-супертипе вводится атрибут-дискриминатор, позволяющий различать конкретные экземпляры сущности-подтипа. В зависимости от того, все ли возможные сущности-подтипы включены в модель, категорийная связь является полной или неполной. В ERwin полная категория изображается окружностью с двумя подчеркиваниями, а неполная - окружностью с одним подчеркиванием. На рис. категорийная связь между сущностью СОТРУДНИК и сущностями ПОСТОЯННЫЙ СОТРУДНИК и СОВМЕСТИТЕЛЬ является неполной, если предположить, что существует еще один тип сотрудников - консультант. Включение в модель сущности КОНСУЛЬТАНТ приводит к тому, что категорийная связь становится полной. Мощность связи представляет собой отношение количества экземпляров родительской сущности к соответствующему количеству экземпляров дочерней сущности. Мощность связи определяется только для идентифицирующих и неидентифицирующих связей и записывается как l:n. ERwin, в соответствии с методологией IDEF1X, предоставляет 4 варианта для п, которые изображаются дополнительным символом у дочерней сущности (рис. Обозначение кратности связи Допустимость пустых (NULL) значений в неидентифицирующих связях ERwin изображает пустым ромбиком на дуге связи со стороны родительской сущности. В целях контроля ссылочной целостности (под ссылочной целостностью в ERwin понимается обеспечение требования, чтобы значения внешнего ключа экземпляра дочерней сущности соответствовали значениям первичного ключа в родительской сущности) для каждой связи могут быть заданы требования по обработке операций INSERT/UPDATE/DELETE для родительской и дочерней сущности. ERwin представляет следующие варианты обработки этих событий: • отсутствие проверки; • проверка допустимости; • запрет операции; • каскадное выполнение операции (DELETE/UPDATE); • установка пустого (NULL-значения) или заданного значения по умолчанию. Постановка задачи «Оперативный анализ прибыли и убытков по товарам в супермаркете» Постановка задачи пользователем требует от него выполнения комплексов операций в последовательности, определяемой логикой их внутренней взаимосвязи, что отражает технологию этого процесса. Рассмотрим пример постановки задачи «Оперативный анализ прибыли и убытков по товарам в супермаркете». Комплекс № 1 «Организационно-экономическая сущность задачи». В данном комплексе осуществляются операции по определению назначения задачи, ее цели, периодичности и сроков выполнения. В этом же комплексе отражаются информационные взаимосвязи подразделений объекта, и при этом обращается внимание на внешние и внутренние связи подразделения, в котором решается задача. Затем раскрывается информационная взаимосвязь входной и выходной информации. Назначение задачи уточняет область ее применения, что отражается в конкретизации объекта, в котором осуществляется автоматизация информационных процессов. В рассматриваемом примере задача предназначена для торгового предприятия типа супермаркета. Цель отражает четкое, но достаточно общее описание результата, который ожидается получить в итоге постановки задачи и ее последующей реализации с помощью технических и программных средств. Цель рассматриваемой задачи заключается в своевременном получении информации для принятия решения относительно эффективности торговли и необходимости закупки новой партии товаров. Рисунок 5.10 - Информационная взаимосвязь подразделений супермаркета Периодичность и сроки решения задачи конкретизируют частоту потребности работника управления в информации (например, один раз в год, ежемесячно, по мере необходимости и т.п.). При этом оговариваются дата (число, месяц, год) и время дня суток (например, к десяти часам ежедневно). Данная задача решается в реальном времени, при котором обеспечивается доступ к базе данных по мере необходимости. Информационная взаимосвязь подразделений данного экономического объекта позволяет определить состав взаимосвязанных подразделений объекта и место подразделения, для функционирования которого необходимо решение данной задачи. Пример отражения информационной взаимосвязи подразделений супермаркета и выделение конкретного подразделения (в частности, отдела продаж) приведен на рисунке 5.10. Рисунок 5.11 - Внешние и внутренние информационные связи отдела продажи При изучении внешних и внутренних информационных связей подразделения раскрывается его структура и указывается конкретная информация, которая должна поступать на входе данного подразделения и на выходе. Пример отражения внешних и внутренних информационных связей подразделения представлен на рис. 12.6. Заключительной операцией в этом комплексе является отражение информационной взаимосвязи входной и выходной информации. Операция акцентирует внимание на уровнях детализации и обобщения информации. Пример взаимосвязи информации представлен на рис.3.11. Рисунок 5.12 - Информационная взаимосвязь входной и выходной информации Комплекс № 2 «Описание выходной информации». В данном комплексе осуществляются операции по определению состава реквизитов выходной информации, расположению реквизитов выходной информации с отражением контрольного примера, описанию полей (реквизитов) выходного документа. Определение состава реквизитов выходной информации зависит от поставленной перед задачей цели; состав реквизитов должен быть необходимым и достаточным для организации работы специалиста подразделения. Последовательность расположения реквизитов определяется правилами распределения реквизитов по частям документа (заголовочной, содержательной, оформительской) и отдельным зонам. Внутри зон реквизиты также располагаются по установленным правилам (удобство работы пользователя, специфика отражения итогов, акцентирование внимания на отдельных реквизитах и т.п.). В результате этой операции создается эскиз выходного документа с отображением контрольного примера. В контрольном примере дается логика расчета, при этом используются числа, легко подсчитываемые вручную. Заключительной операцией этого комплекса является описание полей (реквизитов) выходного документа, или иначе - представление структуры выходного документа. По рассматриваемой задаче структура выходного документа представлена в табл. 12.1. В таблице идентификация отражает короткое, легко запоминающееся название поля в латинском алфавите. Тип данных подчеркивает текстовую или числовую основу данных. В данном примере представлен только числовой тип данных. Разрядность по каждому реквизиту указывается максимальная. В комплексе 2 при проектировании выходного документа учитывается также влияние программных и технических средств (информационная емкость экрана, ширина печатающего устройства, возможность получения нескольких экземпляров и т.п.). В этом же комплексе обобщается специфика выходной информации: рассматриваются состав потребителей информации, способы передачи, объемно-временные характеристики, особенности контроля данных. Данный комплекс конкретизирует ответ на вопрос: «Что требуется получить в результате постановки задачи и ее реализации на персональном компьютере?», т.е. уточняет первоначально поставленную цель решения задачи. Комплекс 3 «Описание входной информации» отвечает на вопрос, на основании какой информации может быть получена выходная информация. Под входной информацией понимается вся информация, необходимая для решения задачи и расположенная на различных носителях: первичных документах, машинных носителях, в памяти персонального компьютера. С этой целью составляются перечень входной информации и состав реквизитов каждого вида входной информации, расположение реквизитов входной информации, описание полей (реквизитов) входных документов. При определении перечня входной информации описываются вид информации (текущая переменная, нормативно-справочная), источники информации, специфика сбора, хранения информации, способы поступления, а также объемно-временные характеристики и способы контроля. Таблица 5.1 - Структура выходного документа Наименование поля (реквизита) Идентификация Тип данных 1. Код группы товара GRUP Числовой 2. Код товара TOV Числовой 3. Количество товаров — продано, KPROD Числовой шт. 4. Цена покупки, руб. PGEN Числовой 5. Цена продажи, руб. PPROD Числовой 6. Объем реализации по закупочным VRP Числовой ценам, руб. 7. Объем реализации по ценам VRPP Числовой продажи, руб. 8. Наличие на складе — количество, KCKL Числовой шт. 9. Наличие на складе по ценам SCKL Числовой покупки, руб. 10. Прибыль или убыток, руб. PRIB Числовой Количество разрядов 2 6 3 3 3 4 4 3 4 4 Состав реквизитов входной информации зависит от особенностей входной информации. Он должен быть необходимым и достаточным для организации дальнейшей обработки. Расположение реквизитов осуществляется в соответствии с существующими правилами ее проектирования. Описание полей (реквизитов) выполняется по отношению ко всем видам входной информации и осуществляется аналогично подобной операции для выходной информации (см. табл. 5.1). В этом же комплексе обобщаются особенности входной информации, которые конкретизируют вид информации (текущая, нормативно-справочная), источники возникновения информации, специфику ее сбора, способы поступления, объемновременные характеристики, особенности контроля данных. Комплекс 4 «Алгоритмы решения задами» отвечает на вопрос: «Каким образом, т.е. на основе каких алгоритмов расчета входная информация преобразуется в выходную информацию?» Разработка алгоритмов решения задачи связана с выполнением неформализованного и формализованного моделирования. При неформализованном моделировании алгоритмы расчетов представляются в описательном виде. Например, в данной задаче «Оперативный анализ прибыли и убытков по товарам в супермаркете» используются алгоритмы: 1) Умножение Количества товаров - продано на Цену покупки для получения Объема реализации по ценам покупки. 2) Умножение Количества товаров — продано на Цену продажи для получения Объема реализации по ценам продажи. 3) Умножение Количества товаров на складе на Цену покупки для получения Наличия товаров на складе в стоимостном выражении. 4) Вычитание из Объема реализации по ценам продажи Объема реализации по ценам покупки и Наличия товаров на складе в стоимостном выражении для получения Прибыли (или Убытка) по Коду товара с указанием Кода группы товара. 5) Суммирование Прибыли и Убытков по Коду товара внутри Кода группы товара с целью получения Прибыли (или Убытка) по Коду группы товара. Результат взаимодействия показателей по изложенным алгоритмам желательно отразить в виде неформализованной модели, которая может быть представлена как схема взаимодействия различных показателей по их наименованиям или идентификаторам. Формализованное моделирование осуществляется по определенным правилам. Согласно правилам по каждому экономическому показателю выявляются реквизитыпризнаки и реквизиты-основания. Им присваиваются условные обозначения: реквизитамоснованиям заглавные буквы, реквизитам-признакам строчные буквы. Экономический показатель выражается в виде совокупности обозначений. Взаимосвязи показателей представляются в виде формул. Совокупность формул отражает инфологическую модель решения задачи. Инфологическая модель задачи «Оперативный анализ прибыли и убытков по товарам в супермаркете» представлена на рис. 3513. Рисунок 5.13 - Инфологическая модель задачи "Оперативный анализ прибыли и убытков по товарам в супермаркете" Инфологическая модель не только позволяет четко выразить логику расчета, но и служит основой для реализации других видов моделей: матричной, функциональной зависимости, графосхем. Это позволяет проектировать базы данных по задачам, комплексам задач, функциональным подсистемам и системе в целом. Созданием инфологической модели заканчивается технология постановки задачи. Технология постановки задачи находит продолжение в технологии ее реализации на персональном компьютере и полностью зависит от используемых программных и технических средств. Постановка задачи к лабораторной работе 5 1. Изучить предлагаемый теоретический материал. 2. Построить инфологическую модель базы данных 3. Разработать логическую и физическую схемы базы данных 4. Разработать схему в ERD-нотации, включающую все полученные уровни модели, описание сущностей и их реквизитов 5. Разработать соответствующую DFD-диаграмму, включающую хранилища и внешние объекты. 4. Оформить отчет. Представить отчет для защиты. Варианты индивидуальных заданий В соответствии с указанной предметной областью и классом разрабатываемой информационной системы разработать инфологическую модель базы данных; разработать логическую и физическую схемы базы данных; разработать схему в ERD-нотации, включающую все полученные уровни модели, описание сущностей и их реквизитов; разработать соответствующую DFD-диаграмму. № 1 2 3 4 5 6 7 8 9 10 Таблица 5.2 – Индивидуальные задания Предметная область Склад Производственное предприятие Торговое предприятие Торговое предприятие Торговое предприятие Портал Строительное предприятие Высшее учебное заведение Инфраструктура предприятия Аппаратная инфраструктура предприятия Класс ИС MRP ERP CRM SCM B2C В2В ИС учета ИС управления СППР Экспертная система Содержание отчета По выполненной работе составляется отчет. Отчет выполняется в электронном виде. По выполненному отчету проводится защита лабораторной работы. Отчет по практической работе должен состоять из следующих структурных элементов: - титульный лист; - вводная часть; - основная часть (описание работы): функциональная модель информационной системы и ее описание; - заключение (выводы). Вводная часть отчета должна включать пункты: - условие задачи; - порядок выполнения. - программно-аппаратные средства, используемые при выполнении работы. Зашита отчета по лабораторной работе заключается в предъявлении преподавателю полученных результатов в виде файла и демонстрации полученных навыков при ответах на вопросы преподавателя. Контрольные вопросы 1. Перечислите основные объекты DFD, их описание и назначение. 2. Назовите базовые принципы инфологического моделирования. 3. В каких случаях целесообразно применять построение модели ―как есть‖, а в каких ―как будет‖? 4. Перечислите основные объекты нотации ERD, их описание и назначение. 5. В чѐм смысл использования связей в реляционных базах данных? 6. В чѐм отличия IDEF0 и DFD? Когда целесообразней использовать IDEF0, а когда DFD? Лабораторная работа 6. Проектирование программного интерфейса информационной системы Цель работы: Ознакомление с методологией проектирования программного интерфейса информационной системы. Работа направлена на ознакомление с основными элементами определения, представления, проектирования и моделирования программных систем с помощью языка UML, получение навыков по применению данных элементов для построения объектноориентированных моделей ИС на основании требований. Требования к результатам выполнения работы: - модель системы должна содержать: диаграмму вариантов использования; диаграммы взаимодействия для каждого варианта использования; диаграмму классов, позволяющая реализовать весь описанный функционал ИС; объединенную диаграмму компонентов и размещения; - для классов указать стереотипы; - в зависимости от варианта задания диаграмма размещения должна показывать расположение компонентов в распределенном приложении. Основы теории Этапы проектирования форм электронных документов Проектирование форм электронных документов, т.е. создание шаблона формы с помощью программного обеспечения проектирования форм, обычно включает в себя выполнение следующих шагов: первый шаг - создание структуры ЭД, который заключается в рисовании линий, создании графических элементов (например, логотипов), т. е. подготовке внешнего вида с помощью графических средств проектирования; второй шаг - определение содержания формы ЭД, т.е. выбор способов, которыми будут заполняться поля. Поля могут быть заполнены вручную или посредством выбора значений из какого-либо списка, меню, базы данных. В последнем случае дизайнер форм должен связать форму с базой данных. Технологическая сеть процесса проектирования макетов экранных форм документов приведена на рис. 6.1. Рисунок 6.1 - Технологическая сеть процесса проектирования макетов экранных форм документов: Д 1.1 - постановка задачи; Д 1.2 - документы с оперативной информацией; Д 1.3 документы с постоянной информацией; Д 1.4 - документы с результатной информацией; Д 1.5 - перечни макетов с оперативной информацией; Д 1.6 - перечни макетов с постоянной информацией; Д 1.7 - перечни макетов с результатной информацией; Д 2.1 - содержание макетов - перечни полей; U 3.1 - универсум типов форм; Д 3.2 - логические структуры макетов; Д 4.1 - язык программирования; Д 4.2 - программы для ввода или вывода информации Для определения перечня макетов экранных форм по каждой задаче проектировщик анализирует (операция П1) «постановку» каждой задачи (Д1.1), в которой приводятся перечни используемых входных документов с оперативной и постоянной информацией (Д1.2,1.3) и документов с результатной информацией (Д 1.4). В процессе анализа определяется, будут ли создаваться макеты под каждый документ или будет осуществляться интеграция полей нескольких входных документов в один макет. В результате получается перечень макетов экранных форм входных и результатных документов (Д1.5 -Д1.7). Содержание макетов (операция П2) определяется на основе анализа состава реквизитов первичных документов с постоянной и оперативной информацией и результатных документов. Содержание макетов (Д2.1) - это перечни полей, значения которых должны находиться в файлах с оперативной и результатной информацией, и типы форматов этих полей. При выполнении третьей операции ПЗ осуществляются выбор типа формы для каждого макета и проектирование их логической структуры (Д3.2). Под логическим проектированием макетов подразумеваются распределение полей по зонам выбранной формы документа и определение последовательности полей в каждой зоне. На входе операции используется универсум типов форм документов (U3.1). При построении структур макетов для первичных документов с оперативной информацией используют комбинированную форму документа, максимально приближенную к той, которая была использована для построения самого документа. Расположение полей должно быть в последовательности, соответствующей логической структуре документа и файлов с оперативной информацией, сокращающей трудоемкость операции загрузки информации в информационную базу. При построении макетов для документов с постоянной информацией следует иметь в виду, что эти макеты используются для ввода и актуализации записей информационной базы, поэтому для их проектирования применяют, как правило, анкетную форму расположения реквизитов, удобную для выполнения этих операций. Макеты, предназначенные для вывода на экран результатной информации, строятся по методике проектирования результатных документов, т.е. на основе использования комбинированной формы с трехзонным расположением реквизитов и многострочной содержательной частью. В основе выбора формы макета лежат принципы минимальной трудоемкости и стоимости ввода информации в ЭВМ, максимальной степени читабельности результатной информации, выводимой на экран, и максимальной надежности и достоверности выполнения этих операций. Работа заканчивается выполнением операции «Программирование разработанных макетов экранных форм и их отладка» (операция П4) с использованием выбранного языка программирования (Д4.1) и апробацией их работы. В процессе проектирования и программирования макетов проектировщик должен делить экранное поле на две части: информационную, предназначенную для собственно самого макета, и служебную для дополнительной информации. Требования к форме электронных документов Информационная часть должна отвечать следующим требованиям: иметь хороший обзор; не должна быть перегружена справочными реквизитами, значения которых следует выдавать на экран в виде списков для просмотра при наборе значений группировочных признаков; значения группировочных признаков также следует выдавать на экран из справочников при переходе указателя в данное поле или при наборе неправильных значений этих признаков; каждое поле должно быть снабжено подсказкой, которую следует выдавать на экран при неправильных действиях пользователя; должна быть обеспечена возможность исправления ошибок в наборе; продвижение указателя должно быть обеспечено в прямом и обратном направлении по вертикали и по горизонтали с возможностью экранной прокрутки всего документа; текущее время и дата должны проставляться автоматически; общий цвет информационной части должен быть спокойных тонов, не вызывающих усталости пользователя при многочасовой работе с ним; цвет полей, подлежащих вводу с клавиатуры, должен отличаться от цвета информационной части; цвет активного поля должен отличаться от основного цвета информационной части и от цвета этого поля в пассивном состоянии. Служебная часть макета, как правило, помещается в нижней части экрана и должна быть отделена от информационной части графически и цветом. Она предназначается для включения подсказок об использовании тех кнопок, с помощью которых пользователь может работать с этим макетом: производить откат на одно поле назад; отказываться от ввода; производить загрузку введенной записи в базу данных; выдавать на печать и т.д. Кроме того, каждый макет должен иметь в этой части экрана инструкционную часть для пользователя со справочной информацией о порядке заполнения макетов и всех видах ошибок, которые могут возникнуть при работе с ними, и способами их исправления. Предпроектная стадия проектирования В целях изучения взаимосвязанных приемов и методов канонического проектирования ИС перечисленные 7 стадий можно сгруппировать в часто используемые на практике четыре стадии процесса разработки ИС (рис. 2.1): Вторая стадия «Техно-рабочее проектирование» выполняется в два этапа: техническое проектирование и рабочее проектирование. На этапе «Техническое проектирование» выполняются работы по логической разработке и выбору наилучших вариантов проектных решений, в результате чего создается «Технический проект». Этап «Рабочее проектирование» связан с физической реализацией выбранного варианта проекта и получением документации «Рабочего проекта». При наличии опыта проектирования эти этапы иногда объединяются в один, в результате выполнения которого получают «Техно-рабочий проект» (ТРП) - Д2.1. Третья стадия «Внедрение проекта» включает в себя три этапа: подготовка объекта к внедрению проекта; опытное внедрение проекта и сдача его в промышленную эксплуатацию. На этапе «Подготовка объекта к внедрению проекта» осуществляется комплекс работ по подготовке предприятия к внедрению разработанного проекта ЭИС. На этапе «Опытное внедрение» осуществляют проверку правильности работы некоторых частей проекта и получают исправленную проектную документацию и «Акт о проведении опытного внедрения». На этапе «Сдача проекта в промышленную эксплуатацию» осуществляют комплексную системную проверку всех частей проекта, в результате которой получают доработанный «Техно-рабочий проект» (Д3.1) и «Акт приемки проекта в промышленную эксплуатацию» (Д3.2). Рисунок 2.2 - ТСП стадий и этапов канонического проектирования ИС: Д1.1 - предметная область; Д1.2 - материалы обследования; Д1.3 - ТЭО, ТЗ на проектирование; Д1.4 - эскизный проект; Д2.1 - техно-рабочий проект (ТРП); Д3.1 исправленный ТРП, переданный в эксплуатацию; Д3.2 - акт о приемке проекта в промышленную эксплуатацию; Д4.1 - модернизированный ТРП Традиционно этапы исследования предметной области - предприятия, обоснование проекта ИС для него и разработки технического задания объединяют термином «Предпроектная стадия» («Предпроектное обследование»), поскольку результаты выполнения работ на данных этапах не являются законченным проектным решением. Основное назначение «Предпроектной стадии» заключается в обосновании экономической целесообразности создания ИС и формулировании требований к ней. Состав и содержание работ на предпроектной стадии создания ИС При изучении существующей экономической системы разработчики должны уточнить границы изучения системы, определить круг пользователей будущей ИС различных уровней и выделить классы и типы объектов, подлежащих обследованию и последующей автоматизации. Важнейшими объектами обследования могут являться: - структурно-организационные звенья предприятия (например, отделы управления, цехи, участки, рабочие места); - функциональная структура, состав хозяйственных процессов и процедур; - стадии (техническая подготовка, снабжение, производство, сбыт) и элементы хозяйственного процесса (средства труда, предметы труда, ресурсы, продукция, финансы). При каноническом проектировании основной единицей обработки данных является задача. Поэтому функциональная структура проблемной области на стадии предпроектного обследования изучается в разрезе решаемых задач и комплексов задач. При этом задача в содержательном аспекте рассматривается как совокупность операций преобразования некоторого набора исходных данных для получения результатной информации, необходимой для выполнения функции управления или принятия управленческого решения. В большинстве случаев исходные данные и результаты их преобразований представляются в форме экономических документов. Поэтому к числу объектов обследования относятся компоненты потоков информации (документы, показатели, файлы, сообщения). Кроме того, объектами обследования служат: - технологии, методы и технические средства преобразования информации; - материальные потоки и процессы их обработки. Основной целью выполнения первого этапа предпроектного обследования «Сбор материалов» является: - выявление основных параметров предметной области (например, предприятия или его части); - установление условий, в которых будет функционировать проект ЭИС; - выявление стоимостных и временных ограничений на процесс проектирования. На этом этапе проектировщиками выполняется ряд технологических операций и решаются следующие задачи: предварительное изучение предметной области; выбор технологии проектирования; выбор метода проведения обследования; выбор метода сбора материалов обследования; разработка программы обследования; разработка планаграфика сбора материалов обследования; сбор и формализация материалов обследования. Технологическая сеть проектирования представлена на рис. 2.3. Рисунок 2.3 -ТСП работ, выполняемых на этапе «Сбор материалов обследования»: Д 1.1 - общие сведения об объекте; Д 1.2 - примеры разработок проектов ЭИС для аналогичных систем; U 2.1 - универсум технологий проектирования; Д 2.1 - ресурсы; Д 2.2 - описание выбранной технологии, методов и средств проектирования; U 3.1 - универсум методов проведения обследования; Д 3.1 - описание выбранного метода; U 4.1 универсум методов сбора материалов обследования; 4.1 - описание выбранного метода; Д 5.1 - программа обследования; Д 6.1 - план-график выполнения работ на предпроектной стадии; U 7.1 - универсум методов формализации; Д 7.1 - общие параметры (характеристики) экономической системы; Д 7.2 - методики методики управления (алгоритм расчета экономических показателей); Д 7.3 - организационная структура экономической системы;Д 7.4 - параметры информационных потоков; Д 7.5 - параметры материальных потоков Состав и содержание работ на стадии техно-рабочего проектирования Работы на стадии «Техно-рабочего проектирования» выполняются на основе утвержденного «Технического задания». Разрабатываются основные положения проектируемой системы, принципы ее функционирования и взаимодействия с другими системами; определяется структура системы; разрабатываются проектные решения по обеспечивающим частям системы. На стадии «Техно-рабочего проектирования» выполняются два этапа работ: техническое и рабочее проектирование, технологическая сеть которых приведена на рис. 2.4. На первом из них - «Техническое проектирование» осуществляется логическая проработка функциональной и системной архитектуры ЭИС, в процессе которой строится несколько вариантов всех компонентов Рисунок 2.4 - ТСП выполнения работ на этапе технического проектирования: Д 1.1 - ТЗ; Д 1.2 - основные положения по ЭИС; Д 2.1 - описание организационной структуры; Д 3.1 - описание функциональной структуры; Д 4.1 - принципы организации информационного обеспечения; Д 5.1 - постановка задачи; Д 6.1 - формы первичных и результатных документов; Д 6.2 - система ведения документов; Д 7.1 - классификаторы; Д 8.1 - структуры сообщений; Д 9.1 - описание макетов и структур файлов; Д 10.1 - системы технологических процессов обработки данных; Д 11.1 - ТЭО; Д 11.2 - описание состава и характеристика периферийной техники; Д 12.1 - АП; Д 13.1 - проектно-сметная документация; Д 14.1 - показатели экономической эффективности; Д 15.1 - план мероприятий по подготовке объекта к внедрению проекта ЭИС; Д 16.1 - технический проект системы; проводится оценка вариантов по показателям: стоимости, трудоемкости, достоверности получаемых результатов, и составляется «Технический проект» системы. Все работы первого этапа можно разбить на две группы. К первой группе относится разработка общесистемных проектных решений, в том числе: - разработка общесистемных положений по ЭИС (П1); - изменение организационной структуры (П2); - определение функциональной структуры (ПЗ); - разработка проектно-сметной документации и расчет экономической эффективности системы (П13), (П14); - разработка плана мероприятий по внедрению ЭИС (П15). При разработке основных положений по системе (П1) уточняются цели создания ЭИС и выполняемые ею функции; устанавливается ее взаимосвязь с другими системами и формируется документ Д1.2 «Основные положения». Далее уточняется и изменяется организационная структура (П2) и получается описание организационной структуры (Д2.1). Наиболее принципиальной в данном комплексе работ является разработка функциональной архитектуры ЭИС (ПЗ) Д3.1 на базе универсума U3.1 принципов выделения функциональных подсистем (модулей, контуров): предметного, функционального, смешанного (предметно-функционального) и проблемного. Ко второй группе работ, выполняемых на этапе технического проектирования, относятся разработки локальных проектных решений, к числу которых относят следующие операции: - разработка «Постановки задачи» для задач, входящих в состав каждой функциональной подсистемы (П5), включающей основные компоненты описания задачи и служащей основанием для разработки проектных решений по задаче; - проектирование форм входных и выходных документов, системы ведения документов и макетов экранных форм документов (П6, П9); - проектирование классификаторов экономической информации и системы ведения классификаторов (П7); - разработка структуры входных и выходных сообщений (П8); - проектирование состава и структур файлов информационной базы (П4); - проектирование внемашинной и внутримашинной технологии решения каждой задачи (П10); - уточнение состава технических средств (П11), (П12). Основным компонентом локальных проектных решений, являющимся базой для разработки информационного, программного и технологического обеспечения для каждой задачи, является «Постановка задачи». Этот документ содержит три составные части (рис. 2.5): - характеристику задачи; - описание выходной информации; - описание входной информации. В состав раздела «Характеристика задачи» входят следующие компоненты: описание цели; назначение решения конкретной задачи; перечень функций и процессов, реализуемых решаемой задачей; характеристика организационной и техникоэкономической сущности задачи; обоснование целесообразности автоматизации решения задачи; указание перечня объектов, для которых решается задача; описание процедур решения задачи; указание периодичности решения задачи и требований к организации сбора первичных данных; описание связей с другими задачами. Под целью автоматизации решения задачи подразумевается получение определенных значений экономического эффекта в сфере управления какими-либо процессами системы или снижение стоимостных и трудовых затрат на обработку информации, улучшение качества и достоверности получаемой информации, повышение оперативности ее обработки и т.д., т.е. получение косвенного и прямого эффекта от внедрения данной задачи. Под экономической сущностью решаемой задачи понимаются состав экономических показателей, рассчитываемых при ее решении, документы, в которые заносятся эти показатели, перечень исходных показателей, необходимых для получения результатных и наименования тех первичных документов, в которых они содержатся. Организационная сущность задачи - это описание порядка решения задачи; организационной формы, применяемой для ее решения; режима решения; состава файлов с постоянной и переменной информацией; способа получения и ввода первичной информации в ЭВМ; формы выдачи результатной информации: на печать, на экран, на магнитный носитель или передача по каналам связи. Описание алгоритма решения задачи включает формализованное описание входных и результатных показателей и перечень формул расчета результатных показателей в случае решения задачи прямым методом счета или описание математической модели, экономико-математического метода, применяемого для ее реализации, и перечня последовательных шагов выполнения расчетов. Рисунок 2.5 - Схема структуры «Постановка задачи» Далее указываются периодичность решения задачи и регламент выдачи результатных документов, требования к организации сбора исходных данных, т.е. к способу и техническим средствам съема, регистрации, сбора и передачи данных для обработки. Большое значение имеет описание связи задачи с другими задачами функциональной подсистемы, в которую она входит, а также с задачами других подсистем или с внешней средой. Описание выходной информации включает в себя: перечень и описание выходных сообщений, документов; перечень структурных единиц информации; периодичность возникновения и сроки получения информации; наименование; идентификатор по каждой форме документа. Описание входной информации состоит из перечня входных сообщений; перечня структурных единиц информации; описания периодичности возникновения и сроков получения информации; наименования и идентификатора по каждой форме документа. Далее для каждой задачи разрабатываются все компоненты информационного, технического, математического и лингвистического обеспечения, а также некоторые компоненты программного обеспечения. Результатом работ на данной стадии является утвержденный «Технический проект», состав и содержание которого регламентируются стандартом (ГОСТ 34.201 - 89). На втором этапе - «Рабочем проектировании» осуществляется техническая реализация выбранных наилучших вариантов и разрабатывается документация «Рабочий проект» (рис. 2.6). Наиболее ответственной работой, выполняемой на этом этапе, являются «Кодирование и составление программной документации» (П1). В ее состав входят следующие компоненты (Д 1.2): - описание программ; - спецификация программ; - тексты программ; - контрольные примеры; - инструкции для системного программиста, оператора и пользователя. Большую роль в деле эффективного использования разработанного проекта ЭИС играет качественная технологическая документация, входящая в состав «Рабочего проекта». Эта часть проекта разрабатывается на операции П2 и предназначена для использования специалистами в своей деятельности на каждом автоматизированном рабочем месте. В состав технологической документации (Д2.1) входят: технологические карты, разрабатываемые на процессы обработки информации при решении задач каждого класса, и инструкционные карты, составляемые на каждую технологическую операцию. Технологическая документация разрабатывается в соответствии с требованиями ГОСТ 3.11.09 - 82 «Система технологической документации. Термины и определения основных понятий», и составляет содержание технологического обеспечения ЭИС, которое можно разделить на несколько типов в соответствии с выделением следующих классов задач, решаемых в ИС: - системы обработки данных (СОД); - системы поддержки принятия решений (СППР); - системы автоматизированного проектирования новой продукции (САПР) и т.д. Рисунок 2.6 - ТСП работ, выполняемых на этапе рабочего проектирования: Д 1.1 - технический проект; Д 1.2 -документы программного обеспечения; Д 2.1 технические документы и инструкции; Д 3.1 - правовые инструкции; Д 4.1 - рабочий проект К числу работ, выполняемых на этом этапе, относится «Разработка правовых инструкций»; (Д1.2) (П1), определяющих права и обязанности специалистов, работающих в условиях функционирования на предприятии компонентов ЭИС. Заключительной операцией служит «Оформление документации Рабочего проекта» (Д4.2) согласно ГОСТам (Д4.1) на операции П4. Постановка задачи к лабораторной работе 6 1. Изучить предлагаемый теоретический материал. 2. Разработать формы ввода-вывода: 2.1 разработать навигацию по меню ИС; 2.2 разработать макет интерфейса системы, 3. Составить спецификацию программных модулей системы. 4. Построить отчѐт. Представить отчет для защиты. Варианты индивидуальных заданий В соответствии с указанной предметной областью и классом разрабатываемой информационной системы разработать формы ввода-вывода, разработать навигацию по меню ИС, разработать макет интерфейса системы, составить спецификацию программных модулей системы. Таблица 6.1 – Индивидуальные задания № Предметная область Класс ИС 1 Склад MRP 2 Производственное предприятие ERP 3 Торговое предприятие CRM 4 Торговое предприятие SCM 5 Торговое предприятие B2C 6 Портал В2В 7 Строительное предприятие ИС учета 8 Высшее учебное заведение ИС управления 9 Инфраструктура предприятия СППР 10 Аппаратная инфраструктура предприятия Экспертная система Содержание отчета По выполненной работе составляется отчет. Отчет выполняется в электронном виде. По выполненному отчету проводится защита лабораторной работы. Отчет по лабораторной работе должен состоять из следующих структурных элементов: - титульный лист; - вводная часть; - основная часть (описание работы): диаграмма вариантов использования информационной системы, диаграмма состояний для объектов информационной системы; - заключение (выводы). Вводная часть отчета должна включать пункты: - условие задачи; - порядок выполнения. - программно-аппаратные средства, используемые при выполнении работы. Зашита отчета заключается в предъявлении преподавателю полученных результатов в виде файла и демонстрации полученных навыков при ответах на вопросы преподавателя. Контрольные вопросы 1. Дайте определение понятию «вариант использования». 2. Какие типы связи могут присутствовать на диаграмме вариантов использования? 3. Дайте определение понятию «действующее лицо». 4. Какие типы сообщений могут присутствовать на диаграммах взаимодействия? 5. Дайте определение понятию класс, объект класса. 6. Кем и для чего может быть использована диаграмма размещения? 7. Опишите процесс проектирования электронных форм ввода-вывода 8. Для чего применяется спецификация программных модулей? Лабораторная работа 7. Средства управления распределенными системами Цель работы: Изучение средства управления распределенными системами. Основы теории Межсистемные интерфейсы и драйверы. интерфейсы в распределенных системах Все возрастающее значение открытых систем привело к необходимости обеспечить возможность взаимодействия программных продуктов от различных производителей. Для обеспечения упорядоченности развития сетей и обеспечения взаимодействия процессов, выполняющихся в гетерогенных сетях, компанией IBM разработана концепция Open Blueprint , отвечающая всем требованиям, предъявляемым к открытым системам. Open Blueprint определяет структуру для управления распределенными системами и обеспечивает основу, на которой строятся, выполняются и управляются распределенные приложения в гетерогенных сетях. Она разработана на основе промышленных стандартов и позволяет удовлетворять требования заказчиков, предъявляемые к продуктам и решениям, которые соединяют различные аппаратные и программные платформы как корпорации IBM, так и других производителей. Следует отметить, что открытые распределенные вычисления, или технология клиент-сервер, в настоящее время являются основной моделью, определяющей развитие информационных технологий. Структура Open Blueprint дает возможность всем, кто имеет отношение к открытым распределенным средам, рассматривать систему как часть распределенной сети, а сеть, в свою очередь, трактовать как единую информационную структуру. Структура Open Blueprint представлена на рис. 7.1. Рисунок 7.1. -Структура системы Open Blueprint Основные ее <строительные блоки> - это менеджеры ресурсов, которые функционально сгруппированы в наборы сервисов: Сетевые сервисы. Они обеспечивают перемещение данных из одной системы в другую. Эта группа сервисов включает в себя семантику общей транспортной среды, физическую сеть, охватывающую локальные и глобальные сети, каналы и протоколы передачи данных. При этом семантика общей транспортной среды рассматривается как промежуточный слой между сервисами вышестоящего уровня и собственно сетевыми сервисами, такими как SNA (Systems Network Architecture), высокоуровневые сети с соединениями (APPN), сети TCP/IP, NetBIOS, IPX и др. Развивающиеся информационные технологии, такие, как компьютерная телефония, обмен видеоинформацией, конференц-связь, требуют прямого доступа к функциям сетевых сервисов. Для удобства объединения различных областей обработки данных и обеспечения доступа к сетевым протоколам в Open Blueprint введена система сигнализации и управления. Она обеспечивает выполнение таких функций, как установка/разрыв соединений и управление видео- и аудио конференциями. Сигнальная система в сетях связи - это набор процедур, используемых для динамической установки, поддержки и разрыва соединений, которые требуются для обмена данными между пользователями сети и узлами коммутации. Функции этой системы определяют необходимые последовательность и форматы сообщений, обмен которыми осуществляется через сетевой интерфейс. Например, в среде подсетей АТМ одно мультимедийное приложение через сигнальную систему может одновременно принимать данные, используя транспортные сервисы и устанавливать соединения для приема и передачи аудио- и видеоинформации. Таким образом, сигнальная система является объединением множества сетевых протоколов и специфических функций, имеющих отношение к подсетям. Сервисы распределенных систем Сервисы распределенных систем. Этот набор включает в себя три вида сервисов. Первый - это коммуникационные сервисы. Они предоставляют механизмы, позволяющие частям распределенных приложений или менеджерам ресурсов взаимодействовать друг с другом. Этими механизмами являются: диалоговые соединения, вызов удаленных процедур и очередь сообщений. Следующие сервисы в этом наборе - сервисы управления объектами. Они обеспечивают прозрачный доступ к локальным и удаленным объектам (принтеры, диски и пр.) и содержат менеджеры объектов. Третья составляющая рассматриваемого набора - это распределенные сервисы. Они обеспечивают общие механизмы, помогающие частям распределенных приложений или менеджерам ресурсов взаимодействовать друг с другом. К ним относятся сервисы файловых каталогов, безопасности, времени, а также менеджер транзакций. Сервисы приложений и сервисы, включающие приложения. Этот набор также объединяет три типа сервисов. Первый тип - сервисы уровня представления, которые определяют взаимодействие между приложениями и пользователями через различные устройства. Следующие сервисы в этом наборе - сервисы доступа к данным. Они обеспечивают приложениям доступ к различным типам данных в файлах или базах данных. Третья составляющая в рассматриваемом наборе - это сервисы приложений, которые состоят из общих функций, однажды разработанных в стандартном виде. К ним относятся монитор транзакций, монитор потока заданий и электронная почта. Все перечисленные службы являются основой для сервисов управления системами. Они обеспечивают системных администраторов средствами управления, как средой распределенных вычислений, так и функционированием локальных операционных систем. Рассмотренные менеджеры ресурсов совсем не обязательно соответствуют какимлибо конкретным продуктам. Концепция Open Blueprint реализована в виде различных продуктов на различных системных и аппаратных платформах. Она только определяет атрибуты и свойства программного обеспечения, отражает функциональную модульность и стандартизирует различные интерфейсы. Анализ приведенной выше структуры позволяет сделать вывод, что взаимодействием распределенных сетевых процессов и, следовательно, распределенными системами непосредственно управляют сервисы распределенных систем и сетевые сервисы. В данном разделе рассматриваются сервисы, непосредственно относящиеся к взаимодействию сетевых процессов. Эти сервисы в рамках концепции Open Blueprint называются коммуникационными. Кроме того, анализируется промежуточный слой между коммуникационными и сетевыми сервисами - семантика общей транспортной среды CTS. Коммуникационные сервисы являются подсистемой распределенных системных сервисов, обеспечивающих механизм взаимодействия сетевых процессов. Они определяют три программных интерфейса: межпрограммный интерфейс взаимодействия (CPI-C) для диалоговых сервисов; интерфейс вызова удаленных процедур (RPC) для сервисов вызова удаленных процедур; интерфейс очереди сообщений (MQI) для сервисов очереди сообщений. Перечисленные интерфейсы представляют собой три различные модели, определяющие способы взаимодействия между менеджерами сетевых ресурсов, а также функционирования распределенных сетевых процессов (приложений) . CPI-C поддерживает взаимодействие между одновременно выполняющимися прикладными процессами, основанное на установке между ними логического соединения. Отсюда следует, что сетевой сеанс связи в этом случае имеет место только для взаимодействующих программ. Интерфейс CPI-C разработан, в первую очередь, для структурированного обмена информацией между программами. При этом взаимодействующие программы являются клиент-серверными приложениями, то есть приложениями, устанавливающими логическое соединение. Каждая программа при этом функционирует в своем (локальном) адресном пространстве. Программы, использующие интерфейс CPI-C, могут выполнять операции по обмену данными различного назначения. В рамках стандарта ISO диалоговая модель является базовой для обработки транзакций в спецификации протоколов OSI, базирующейся на архитектуре APPC SNA. Операционные системы используют протокол межпрограммного взаимодействия (APPC) для облегчения применения интерфейса CPI-C при разработке приложений. Указанный протокол в рамках систем MVS/ESA и OS-390 предлагает разработчикам набор встроенных функций для использования в клиент-серверных приложениях. Эти функции доступны из программ, написанных на языках высокого уровня, что избавляет от необходимости написания ассемблерных программ. Вызов удаленных процедур (RPC) использует механизм вызова/возврата в/из процедуры для обеспечения взаимодействия между клиент/серверными приложениями. Клиентская (вызывающая) программа определяет местоположение сервера в сети (вызываемой процедуры), устанавливает необходимую связь и передает фактические параметры для выполнения требуемой процедуры. Вызывающая программа ждет завершения работы процедуры (выполнение этой операции синхронно!) и принимает результат. На сегодняшний день рабочие станции с приложениями, реализующими интерфейс RPC, работают как клиентские части в рамках системы OS-390 с использованием функций сервера сетевой файловой системы (NFS), поддерживаемых операционной системой. Кроме того, OS-390 поддерживает RPC в рамках сетевой вычислительной системы Apollo. В рамках архитектуры OSF интерфейс RPC выбран в качестве базовой коммуникационной модели для распределенных вычислительных элементов (DCE). Интерфейс RPC в стандарте OSF/DCE поддерживается операционными системами OS-390 и MVS/ESA. Интерфейс очереди сообщений MQI является асинхронным межпрограммным интерфейсом, использующим управляемую сообщениями отложенную обработку взаимодействий через очереди, а не через собственно межпроцессные соединения. Программы, использующие MQI, заполняют и освобождают очереди сообщений. Вызывающая программа помещает запрос в очередь, но при этом не дожидается ответа, продолжая свою работу. Приходящий ответ помещается в другую очередь, где и дожидается обработки. Сервисы MQI доставляют сообщения в соответствующее место назначения в сети так, чтобы они были доступны программам, обслуживаемым очередью. Это обеспечивает гарантированную доставку сообщений и ответов на них, а также там, где это необходимо, - возможность синхронизации. MQI-приложения могут быть клиентсерверными, или иметь более сложные реализации. Сервис MQSeries IBM упрощает процесс межплатформенного взаимодействия, основанный на MQI. Этот сервис работает независимо от нижележащих сетевых протоколов. Использование MQSeries дает разработчикам возможность проектировать и реализовывать межплатформенные связи между приложениями быстрее и эффективнее, чем это может быть сделано с помощью традиционной техники программирования сетевых процессов. MQSeries поддерживает соответствующие коммуникационные протоколы и восстановление в случае возникновения аварийных ситуаций, обеспечивая корректную доставку сообщений. Информация может передаваться между приложениями, работающими в рамках System/390, серверов и персональных компьютеров. Наиболее целесообразным применение этого сервиса оказывается в тех случаях, когда взаимодействующие приложения характеризуются длительными промежутками работы без необходимости в установлении соединения, или промежутками периодического обслуживания. Такие случаи характерны для приложений, обрабатывающих транзакции с использованием IMS, CICS и TSO. Мосты для таких типов транзакций дают возможность пользователям различных систем иметь доступ к приложениям, работающим на мэйнфреймах, без перепрограммирования собственных интерфейсов. MQSeries поддерживает соединения как по протоколу TCP/IP, так и по протоколу SNA APPC. Поддерживаемые этим сервисом платформы включают в себя такие системы, как OS/2, MVS/ESA, OS/390, OS/400, VSE/ESA, VAX/VMS, UNIX, Sun Solaris и др. Межпрограммный интерфейс взаимодействия CPI-C Межпрограммный интерфейс взаимодействия CPI-C представляет собой программный интерфейс приложений, или API, который обеспечивает соединение (диалог) между программами в среде SNA . Интерфейс CPI-C обеспечивает возможность совместной работы прикладных программ, расположенных в географически удаленных узлах сети. Взаимодействуя друг с другом, такие программы могут решать различные общие задачи, например, осуществлять связь с удаленной базой данных, копировать удаленные файлы, обмениваться сообщениями электронной почты и т.д. Для обеспечения такого взаимодействия в среде SNA необходимы различные элементы оборудования и программного обеспечения. На рис. 7.2 показаны эти элементы и связи между ними. Рисунок 7.2 - Взаимодействие между программами Каждая сетевая программа связана с логическим устройством LU, которое является для нее точкой доступа в сеть. С точки зрения прикладной программы LU выступает в качестве интерфейса, который она использует для установки связи с другой программой через сеть. Интерфейс CPI-C использует LU типа 6.2, которые поддерживают соединение между логическими устройствами. Прежде чем две программы смогут начать взаимодействие, их LU должны быть соединены между собой через сессию, которая является логической связью между двумя LU. Сессия устанавливается при включении особого режима, определяющего набор сетевых параметров, указывающих способ использования сессии. LU типа 6.2 могут обеспечить множественную сессию (две или более конкурирующих сессий с одним и тем же взаимодействующим LU). Прикладные программы имеют доступ к интерфейсу CPI-C через вызовы CPI-C. Каждый вызов выполняет определенные действия, такие, как начало или завершение диалога, передача или прием данных, установка режимов и т.п. Программа, выполнившая вызов, рассматривается как локальная, другая программа считается удаленной. Вызовы CPI-C доступны для программ, написанных на различных языках программирования. APPC (Advanced Program-to-Program Communications) - протокол, разработанный IBM и позволяющий приложениям работать на различных компьютерах и непосредственно обмениваться данными . Протокол APPC реализован как программное обеспечение, функционирующее в рамках различных операционных систем IBM и других типов. Он может являться или частью собственно ОС, или устанавливаться как отдельный программный пакет. Протокол APPC выступает в качестве связующего звена между прикладными программами и сетью. Когда прикладная программа на локальной ЭВМ - источнике передает информацию протоколу APPC, последний преобразует ее соответствующим образом и отправляет сетевому интерфейсу, например адаптеру локальной сети. Далее информация передается через сеть на ЭВМ - получатель, протокол APPC которой принимает ее от соответствующего сетевого адаптера. Далее протокол преобразует принятую информацию в исходный формат и передает соответствующему прикладному процессу. Очевидно, что связь между системами в этом случае выполняется на одном уровне (одноранговая связь). Для обращения к протоколу APPC из прикладных программ используются функции интерфейса прикладных программ (API) различного назначения. Примером таких API могут служить функции протокола передачи файлов APPC File Transfer Protocol (AFTP), обеспечивающие возможность обмена файлами между удаленными прикладными процессами. Для взаимодействия между прикладными процессами протокол APPC пользуется сессиями, установленными с помощью вызовов CPI-C, однако эти действия являются прозрачными для взаимодействующих процессов. Вызов удаленных процедур Идея вызова удаленных процедур (Remote Procedure Call - RPC) состоит в расширении хорошо известного и понятного механизма передачи управления и данных внутри программы, выполняющейся на одной машине, до передачи управления и данных через сеть. Средства удаленного вызова процедур предназначены для облегчения организации распределенных вычислений. Наибольшая эффективность использования RPC достигается в тех приложениях, в которых существует интерактивная связь между удаленными компонентами с небольшим временем отклика и относительно малым количеством передаваемых данных. Такие приложения называются RPCориентированными. Характерными чертами вызова локальных процедур являются: асимметричность, то есть одна из взаимодействующих сторон является инициатором; синхронность, то есть выполнение вызывающей процедуры приостанавливается с момента выдачи запроса и возобновляется только после возврата из вызываемой процедуры. Реализация удаленных вызовов существенно сложнее реализации вызовов локальных процедур. Поскольку вызывающая и вызываемая процедуры выполняются на разных машинах, они имеют разные адресные пространства, и это создает проблемы при передаче параметров и результатов, особенно если машины не идентичны. Так как RPC не может рассчитывать на разделяемую память, это означает, что параметры RPC не должны содержать указателей на ячейки не стековой памяти и что значения параметров должны копироваться с одного компьютера на другой. Следующее отличие RPC от локального вызова заключается в том, что он обязательно использует нижележащую систему связи, однако это не должно быть явно видно ни в определении процедур, ни в самих процедурах. Идея, положенная в основу RPC, состоит в том, чтобы вызов удаленной процедуры выглядел по возможности так же, как вызов локальной процедуры. Другими словами сделать RPC прозрачным: вызывающей процедуре не нужно знать, что вызываемая процедура находится на другой машине, и наоборот. RPC достигает прозрачности следующим путем. Когда вызываемая процедура действительно является удаленной, вместо локальной процедуры используется другая ее версия, называемая клиентской заглушкой (stub). Подобно локальной процедуре, заглушка вызывается с использованием того же списка параметров, только в отличие от локальной процедуры она отправляет вызывающее сообщение на сервер. Вызывающее сообщение содержит параметры процедуры для процесса на сервере. Далее клиентский процесс ожидает от сервера ответного сообщения. Процесс на серверной стороне ожидает поступления вызывающего сообщения, дождавшись которого, извлекает параметры процедуры, выполняет необходимые вычисления и отправляет ответное сообщение клиенту. Далее процесс на серверной стороне ждет следующего вызывающего сообщения. Процесс на клиентской стороне получает ответное сообщение, извлекает из него результаты вычислений и продолжает выполнение. Взаимодействие программных компонентов при выполнении удаленного вызова процедуры показано на рис. 3. На этом рисунке слева изображен клиентский процесс, содержащий прикладную программу клиента, клиентскую заглушку и библиотеку RPC времени выполнения. На серверной стороне (справа) показаны менеджер процедур сервера (часть процесса сервера), серверная заглушка и библиотека RPC времени выполнения сервера. Пунктиром обозначены виртуальные связи, сплошными линиями - реальный маршрут данных. Следует отметить, что модель RPC предполагает активность только одного из процессов в каждый момент времени. Рисунок 7.3 -Вызов удаленной процедуры Из вышеизложенного следует, что перед выполнением компиляции и связывания RPC-программы необходимо решить весьма важную предварительную задачу. Эта задача заключается в создании и компиляции файла определения интерфейсов, в котором находится описание клиент-серверных интерфейсов. Эти интерфейсы определяются на специальном языке определения интерфейсов (Interface Definition Language, IDL) и содержат набор <прототипов> для вызовов удаленных процедур со стороны клиента, которые реально должны быть выполнены на серверной стороне. После создания такого файла он компилируется специальным IDL-компилятором. Выходом этого компилятора является пара объектных файлов, один из которых относится к серверному модулю, а второй - к клиентскому. Они содержат коды клиентских и серверных заглушек, где все детали удаленного выполнения процедур, передачи данных и т.д. увязаны с библиотекой RPC времени выполнения. Эти файлы в дальнейшем связываются с результатом компиляции программ клиентской и серверной сторон. Кроме того, IDL-компилятор генерирует заголовочный файл для подключения его к исходным файлам клиента и сервера на этапе их компиляции. Заголовочный файл содержит все объявления, полученные из определений, имеющихся в IDL-файле. В частности, там находится глобальный уникальный идентификатор интерфейса (Global Unique Identifier, GUID), который используется во время выполнения для описания и привязки определенных в RPC-приложении интерфейсов. Вызовы удаленных процедур могут быть реализованы на любом языке программирования, поэтому язык определения интерфейсов является стандартным для всех сетевых платформ. Интерфейс RPC не зависит от транспортных протоколов. В зависимости от ситуации, на транспортном уровне могут быть использованы или протокол TCP, или протокол UDP. В общем случае, взаимодействующие процессы пользуются механизмом сокетных соединений, что также показано на рис. 7.3. Интерфейс очереди сообщений Основными элементами системы MQSeries являются: сообщения, которые прикладные программы посылают друг другу; очереди для хранения сообщений; менеджеры очередей, управляющие очередями и обработкой сообщений; каналы передачи сообщений, связывающие менеджеры между собой. Прикладная программа передает свое сообщение серверу (менеджеру очередей), который записывает его в локальную очередь, а затем передает по сети другому менеджеру очередей, содержащему очередь-адресат. Программа-адресат обращается к своей очереди и получает доступ к сообщению. В результате система очередей сообщений предоставляет асинхронный метод взаимодействия программ, не требующий установки между ними прямой связи. При этом гарантируется, что передаваемое сообщение не будет потеряно или получено дважды. Процесс взаимодействия прикладных программ с помощью менеджера очередей представлен на рис. 7.4. Рисунок 7.4 -Взаимодействие приложений с помощью диспетчера очередей На рисунке показано, что приложения выбирают сообщения из очереди, обрабатывают их и помещают результаты в другую очередь. Если приложение помещает сообщение в одну очередь, то оно может извлечь адресованные ему данные только из другой очереди. Следует отметить, что перед началом выполнения приложения должны быть соблюдены следующие условия: менеджер очередей должен существовать и выполняться; должна быть определена очередь, из которой извлекаются сообщения; должна быть определена очередь, в которую помещаются сообщения; оба приложения должны быть связаны с очередями. Сообщения (Message) MQSeries представляют собой структуру данных, состоящую из заголовка сообщения размером 324 байт (MQ Message Descriptor) и прикладных данных, в зависимости от платформы имеющих размер до 100 Мбайт. Заголовок содержит контрольную информацию о сообщении и его характеристиках. С помощью этой информации менеджер очередей решает, каким образом обрабатывать и куда передавать сообщение. Прикладная часть сообщения может включать данные в специальных предопределенных форматах или данные в форматах пользователя. Для приложений, функционирующих под управлением разных ОС и оперирующих различными кодовыми страницами, поддерживаются методы преобразования данных. Очередь сообщений (Queue) является основным местом хранения и обработки сообщений. Физическое управление очередями полностью скрыто от прикладных программ - приложения могут получить доступ к очередям только через интерфейс MQI (Message Queue Interface). Менеджер очередей (Queue Manager) отвечает за управление очередями сообщений и прием вызовов от прикладных программ. Внутренняя реализация менеджеров очередей для каждой операционной системы своя. Однако с функциональной точки зрения менеджеры очередей MQSeries представляют собой совокупность очередей различных типов, каналов передачи сообщений между менеджерами, программ-мониторов и административных утилит. Прикладные программы взаимодействуют с системой MQSeries через интерфейс прикладного программирования MQI, который имеет единую структуру на всех платформах и основан на простой системе из десятка команд. Семантика общей транспортной среды Взаимодействие сетевых процессов является <сердцем> инфраструктуры распределенных систем. В ранних поколениях вычислительных систем коммуникационные структуры в значительной степени влияли на сервисы и подсистемы, доступные прикладным программам. Современные распределенные высокоуровневые сервисы и менеджеры ресурсов, опирающиеся на клиент-серверную технологию, должны поддерживать различные операционные системы и широкий спектр сетевого оборудования. Отсюда следует, что менеджеры ресурсов нуждаются в сервисах, не зависящих от конкретных сетевых и канальных протоколов. Поэтому все современные распределенные системы обеспечивают четкое разделение между коммуникационными протоколами и сетевыми сервисами. Эта тенденция привела к структуре сетевого сервиса, определенной в Open Blueprint корпорации IBM. Она состоит из семантики общей транспортной среды (Common Transport Semantics), транспортных сервисов, подсетей, а также системы сигнализации и управления. В данном разделе рассматривается семантика (набор правил) общей транспортной среды (Common Transport Semantics, CTS) и ее реализация в виде коммуникационных серверов. Common Transport Semantics изолирует сервисы вышестоящего уровня (CPI-C, RPC и MQI) от расположенных ниже транспортных сервисов. Это достигается обеспечением единой внешней структуры транспортных протоколов. Отсюда следует независимость сервисов высших уровней от транспортных протоколов, что, в свою очередь, ведет к возможности включения различных сетевых транспортных драйверов в общую реализацию этих сервисов. Кроме того, использование CTS делает возможной интеграцию сетей с различными протоколами через транспортные шлюзы, которые компенсируют различия в нижележащих сетевых транспортах. Это, в свою очередь, делает возможной совместную работу рабочих станций независимо от физической среды локальной сети LAN (маркерное кольцо, Ethernet) или транспортных протоколов (IPX, NetBIOS, SNA или TCP/IP). В рамках Open Blueprint CTS тесно связана с мультипротокольной транспортной сетевой архитектурой (MPTN). MPTN определяет интерфейс как набор транспортных сервисов, объединяющих связи через множество сетевых протоколов. В дополнение к логическим связям через однородные сети она отделяет прикладные программы от сетей таким образом, что сообщения от приложений могут передаваться посредством любого протокола, объявленного в интерфейсе. Связь приложения и интерфейса осуществляется с помощью CTS. Таким образом, MPTN можно рассматривать как группу однопротокольных сетевых транспортов, каждый из которых имеет собственный протокол. Однако все они физически связаны и реализуют один и тот же протокол. Отсюда следует, что MPTN для пользователя имеет вид единой логической сети, имеющей единый протокол. Это обеспечивается двумя основными составляющими MPTN: Common Transport Semantics и шлюзами MPTN. На рис. 5 представлена логическая сеть MPTN, содержащая две однопротокольные сети, которые связаны через шлюз MPTN. Архитектура MPTN является открытой, и вообще говоря, исключает принудительные привязки сетевых протоколов и приложений к транспортным сервисам. Другими словами, API приложений и их сервисы могут взаимодействовать через протокол, отличающийся от предназначенного для них изначально. Приложения должны быть попарно согласованы, а именно, оба должны использовать один и тот же протокол. Рисунок 7.5 -Мультипротокольная транспортная сеть Например, две программы, изначально использующие APPC и взаимодействующие через SNA, могут взаимодействовать через TCP/IP, две гнездовые программы, изначально использовавшие TCP/IP, могут взаимодействовать через SNA. Но APPC-приложение не может взаимодействовать с гнездовой программой ни через SNA, ни через TCP/IP. Архитектура MPTN реализована как семейство продуктов AnyNet корпорации IBM. Семейство продуктов AnyNet дает возможность существующим приложениям без всяких модификаций взаимодействовать через сети с множеством сетевых транспортных протоколов. Использование функций этого семейства продуктов позволяет уменьшить количество транспортных протоколов в сетях, что, в свою очередь, ведет к снижению общей сложности распределенных систем. Семейство продуктов AnyNet состоит из различных компонентов для использования в различных операционных системах IBM: AIX, MVS, OS/2, OS/400 и на платформах Windows. Так, например: CS/AIX предназначен для операционной среды AIX; CS Linux предназначен для операционной среды Linux; AnyNet/MVS предназначен для операционной среды MVS; AnyNet/2 предназначен для операционной среды OS/2; CS/NT предназначен для операционной среды Windows. Семейство продуктов AnyNet реализует архитектуру MPTN, которая поддерживает сетевые соединения на основе смешанных протоколов и функции межсетевых соединений. Частью продуктов AnyNet, например, являются: APPC через TCP/IP. Эта функция имеется в операционных системах MVS, AIX OS/2 и Windows. Она позволяет прикладным программам, использующим интерфейсы APPC или CPI-C, взаимодействовать с парными программами через IP-сети. Поддерживаются протоколы LU 6.2 для независимых логических устройств LU. Функция APPC через TCP/IP может работать и в качестве шлюза MPTN, разрешая сессию LU 6.2 и потоки данных между сетями SNA и TCP/IP. Она позволяет взаимодействовать с парными программами через IP-сети. SNA через TCP/IP. Эта функция также имеется в операционных системах MVS, AIX OS/2 и Windows. Она позволяет приложениям SNA взаимодействовать с парными программами через IP-сети. Кроме поддержки независимой связи через LU 6.2, функция SNA через TCP/IP обеспечивает взаимодействие зависимых логических устройств, таких как принтеры и эмуляторы. Гнездовые соединения через SNA. Эта функция также имеется в операционных системах MVS, AIX OS/2 и Windows. Она позволяет прикладным программам, использующим интерфейс гнездовых соединений или интерфейс WinSock взаимодействовать через сети SNA. Функция гнездовых соединений через SNA использует диалог LU 6.2 для обеспечения взаимодействия. Гнездовые соединения через шлюз SNA. Эта функция также имеется в операционных системах MVS, AIX OS/2 и Windows. Она соединяет IP-сети с сетями SNA для обеспечения взаимодействия между приложениями, использующими интерфейс гнездовых соединений. Такие приложения, работающие в существующих сетях TCP/IP, могут взаимодействовать с приложениями, использующими гнездовые соединения в сетях SNA, не нуждаясь в каком-либо перепрограммировании. Рисунок 7.6 - Взаимодействие прикладных программ с помощью функции APPC через TCP/IP На рис. 7.6 показана связь двух прикладных программ с помощью функции APPC через TCP/IP. Взаимодействующие программы используют функции API независимого LU 6.2 для доступа друг к другу. На этом рисунке отсутствует шлюз, поэтому оба прикладных процесса связываются через IP-сеть. Если сконфигурировать коммуникационный сервер как сетевой узел, то функция APPC через TCP/IP может выполняться в качестве шлюза. В этом случае возможна установка сессии и потока данных между сетями SNA и TCP/IP, как это показано на рис. 7. Следует отметить, что функция APPC через TCP/IP поддерживает два или более шлюзов между двумя сетями, а также два или более шлюзов, соединяющие три или более сетей. Рисунок 7.7 -Взаимодействие APPC-программ с помощью функции APPC через TCP/IP, используемой в качестве шлюза Свойство мультипротокольности реализовано в виде коммуникационных серверов. Коммуникационные серверы работают на различных платформах: OS-390, OS/400, UNIX (Linux), Sun Solaris и др. Используя различные коммуникационные серверы, APPCприложения взаимодействуют с рабочими станциями в сети TCP/IP, имеющими доступ к API APPC. Таким образом, APPC-приложение через протокол TCP/IP, может являться хостом по отношению к рабочей станции, рабочей станцией по отношению к рабочей станции или хостом по отношению к хосту. Кроме того, в коммуникационных серверах поддерживается интерфейс гнездовых соединений BSD (Berkley Software Distribution) через протокол SNA. Примером такого сервера может служить коммуникационный сервер CS Linux. Этот сервер представляет собой коммуникационное программное обеспечение, функционирующее в среде операционной системы Linux. Коммуникационный сервер CS Linux связывает прикладные программы через сети SNA и TCP/IP. Он преобразует рабочую станцию, функционирующую под управлением операционной системы Linux, в узел сети SNA. Такое преобразование выполняется с помощью добавления к рабочей станции ресурсов и протоколов SNA, что позволяет ей взаимодействовать с другими рабочими станциями и хостами в сети SNA. На рис.7.8 показаны возможные варианты использования коммуникационного сервера CS Linux. В левой части рис. 7.8 CS Linux установлен на отдельной системе z800, что разгружает основную систему z/OS. В правой части этого рисунка показан вариант установки CS Linux в одном из разделов основной системы z/OS. Коммуникационный сервер CS Linux обеспечивает выполнение следующих служб: Поддержка иерархических сетей SNA. В сетях такого типа один хост управляет взаимодействием между рабочими станциями, осуществляет менеджмент сети в целом и обеспечивает хранение больших объемов данных. Все остальные узлы в сети по отношению к главному узлу являются подчиненными. Рабочие станции AIX могут находиться в иерархической сети, если сконфигурированы как сателлитные узлы. Поддержка сетей APPN <точка-к-точке>. Для среды распределенной обработки данных коммуникационный сервер CS Linux поддерживает сети APPN и TCP/IP. В таких сетях рабочие станции осуществляют функции обработки и взаимодействия друг с другом напрямую, как <точечные> узлы. Такого вида сети полностью используют возможности рабочих станций AIX, являющихся альтернативой высокопроизводительным хостам. Сеть APPN может включать в свой состав как сетевые узлы APPN, так и конечные узлы APPN. Узлы первого типа обеспечивают управление трафиком, динамическую маршрутизацию и сервисы управления сетью. Узлы второго типа используют сервисы APPN для взаимодействия с сетевыми узлами APPN. Следует отметить, что хосты могут функционировать в качестве сетевых узлов, используя независимые LU 6.2 для связи с рабочими станциями и другими хостами. Рисунок 7.8 - Варианты использования коммуникационного сервера CS Linux На уровне управления данными сервер CS Linux предоставляет различные возможности для установки параметров трафика, таких как скорость передачи, размер блоков данных, параметров безопасности и т. п. Коммуникационный сервер CS Linux поддерживает различные типы LU для различных классов прикладных программ. Так, для иерархических сетей это зависимые LU. Например, LU0 обеспечивает простейшее межпрограммное взаимодействие, LU2 поддерживает эмуляцию терминала серии IBM 3270. Другие типы LU позволяют прикладным программам принимать участие в распределенных вычислениях или взаимодействовать с удаленными терминалами. В сетях APPN поддерживаются и независимые LU типа 6.2, с помощью которых обеспечивается автономное сетевое управление и межпроцессные взаимодействия. Каждое из взаимодействующих приложений связывается со своим LU и устанавливает таким образом сессию Коммуникационный сервер CS Linux обеспечивает несколько сот таких сессий одновременно. Для разработки прикладных программ в состав сервера включен программный интерфейс приложений (API) для различных типов LU, для распределенных процессов, сетевого управления и администрирования собственно сервера CS Linux. Кроме того, в состав API этого сервера входят функции, обеспечивающие его совместимость с аналогичными серверами других типов из семейства AnyNet, предназначенны для работы в иных операционных средах. В контексте коммуникационных серверов последний может рассматриваться как интерфейс, дающий возможность транзакционным программам (ТР) взаимодействовать с поддерживающими их LU. Он состоит из библиотеки команд (также называемых функциями, вызовами или подпрограммами), из которой ТР выбирает все необходимое для создания запроса к LU на выполнение какого-либо действия. Таким действием, например, может быть передача данных (SEND_DATA). LU обрабатывает полученный запрос и строит поток данных в соответствии с требуемым протоколом, добавляет заголовок с указанием адреса назначения и передает данные партнерскому LU. Одним из наиболее мощных коммуникационных серверов является интерфейс CPI-C, подробно рассмотренный выше. CPI-C использует общий для всех систем IBM набор синтаксических правил, вследствие чего в настоящее является фактическим стандартом. Другие возможности коммуникационного сервера CS Linux включают в себя функции поддержки интерфейса APPC, который также был подробно рассмотрен выше, функции поддержки интерфейса гнездовых соединений IBM, функции поддержки интерфейса распределенных вычислений и процессов, таких как DB/2 и т.п. Постановка задачи к лабораторной работе 7 1. Изучить предлагаемый теоретический материал. 2. Разработать структуру распределенной системы 3. Разработать смету для инфраструктуры распределенной системы 4. Построить отчѐт, включающий все полученные диаграммы стратегии планирования рисков. Представить отчет для защиты. и описание Варианты индивидуальных заданий В соответствии с указанной предметной областью и классом разрабатываемой информационной системы разработать структуру распределенной системы, разработать смету для инфраструктуры распределенной системы, построить отчѐт, включающий все полученные схемы и таблицы и описание стратегии планирования рисков.. № 1 2 3 4 5 6 7 8 9 10 Таблица 7.1 – Индивидуальные задания Предметная область Склад Производственное предприятие Торговое предприятие Торговое предприятие Торговое предприятие Портал Строительное предприятие Высшее учебное заведение Инфраструктура предприятия Аппаратная инфраструктура предприятия Класс ИС MRP ERP CRM SCM B2C В2В ИС учета ИС управления СППР Экспертная система Содержание отчета По выполненной работе составляется отчет. Отчет выполняется в электронном виде. По выполненному отчету проводится защита лабораторной работы. Отчет по лабораторной работе должен состоять из следующих структурных элементов: - титульный лист; - вводная часть: краткое описание целей проекта. Вводная часть отчета должна включать пункты: условие задачи; порядок выполнения; программно-аппаратные средства, используемые при выполнении работы. - основная часть (описание работы). - заключение (выводы); - список использованной литературы. Зашита отчета по лабораторной работе заключается в предъявлении преподавателю полученных результатов в виде файла и демонстрации полученных навыков при ответах на вопросы преподавателя. Контрольные вопросы 1. Управление распределенной системой. 2. Стандарт OSI открытых систем. 3. Структура распределенной системы. 4. Инфраструктура распределенной системы. 7. Типы рисков, которые могут оказать влияние на проект распределенной системы 8. Распределенная телекоммуникационная сеть 9. Распределенные клиенты и нагрузка на клиента Лабораторная работа 8. Разработка метрик качества программных приложений Цель работы: Изучение стандартов качества программных приложений. Получение навыков по применению стандартов качества при проектировании, разработке, тестировании и аудите программных приложений. Изучение методов управления качеством проектирования информационных систем Лабораторная работа направлена на ознакомление с основными понятиями управления качеством проектирования программных приложений, получение навыков по применению данных понятий при построении плана проекта, построения графика работ, распределения исполнителей, управления рисками, изучение методов управления качеством проектирования информационных систем Требования к результатам выполнения лабораторной работы: Построить модель управления проектом, включающую: - определение всех этапов проекта, зависимых этапов, определение длительности этапов; - построение на основе полученных данных сетевой и временной диаграмм; - построение диаграммы распределения работников по этапам; При определении этапа указывается его название – отражающее суть этапа (например, определение пользовательских требований, проектирование интерфейса); этапов должно быть не менее 7, в проекте задействовано 3 человека персонала (группа разработчиков). Основы теории Управления качеством разработки программных приложений. Планирование проекта Управление программным проектом зависит от правильного планирования работ, необходимых для его выполнения. План помогает менеджеру предвидеть проблемы, которые могут возникнуть на каких-либо этапах создания ПО, и разработать превентивные меры для их предупреждения или решения. План, разработанный на начальном этапе проекта, рассматривается всеми его участниками как руководящий документ, выполнение которого должно привести к успешному завершению проекта. Этот первоначальный план должен максимально подробно описывать все этапы реализации проекта. Кроме разработки плана проекта, на менеджера ложится обязанность разработки других видов планов. Эти виды планов кратко описаны в таблице 8.1. В листинге 1 показан процесс планирования создания ПО в виде псевдокода. Здесь сделан акцент на том, что планирование — это итерационный процесс. Поскольку в процессе выполнения проекта постоянно поступает новая информация, план должен регулярно пересматриваться. Важными факторами, которые должны учитываться при разработке плана, являются финансовые и деловые обязательства организации. Если они изменяются, эти изменения также должны найти отражение в плане работ. Таблица 8.1 - Виды планов План Описание План качества Описывает стандарты и мероприятия по поддержке качества разрабатываемого ПО План аттестации Описывает способы, ресурсы и перечень работ, необходимых для ат- тестации программной системы План управления Описывает структуру и процессы управления конфигурацией конфигурацией План сопровож- Предлагает план мероприятий, требующихся для сопровождения ПО дения ПО в процессе его эксплуатации, а также расчет стоимости сопровождения и необходимые для этого ресурсы План по управле- Описывает мероприятия, направленные на повышение квалификанию персоналом ции членов команды разработчиков Листинг 1. Процесс планирования проекта Определение проектных ограничений Первоначальная оценка параметров проекта Определение этапов выполнения проекта и контрольных отметок while пока проект не завершится или не будет остановлен loop Составление графика работ Начало выполнения работ Ожидание окончания очередного этапа работ Отслеживание хода выполнения работ Пересмотр оценок параметров проекта Изменение графика работ Пересмотр проектных ограничений if (возникла проблема) then Пересмотр технических или организационных параметров проекта end if end loop Контрольные отметки этапов работ Менеджеру для организации процесса создания ПО и управления им необходима информация. Поскольку само программное обеспечение неосязаемо, эта управленческая информация может быть получена только в виде документов, отображающих выполнение очередного этапа разработки программного продукта. Без этой информации нельзя судить о степени готовности создаваемого продукта, невозможно оценить произведенные затраты или изменить график работ. При планировании процесса определяются контрольные отметки— вехи, отмечающие окончание определенного этапа работ. Для каждой контрольной отметки создается отчет, который предоставляется руководству проекта. Эти отчеты не должны быть большими объемными документами; они должны подводить краткие итоги окончания отдельного логически завершенного этапа проекта. Этапом не может быть, например, "Написание 80% кода программ", поскольку невозможно проверить завершение такого "этапа"; кроме того, подобная информация практически бесполезна для управления, поскольку здесь не отображается связь этого "этапа" с другими этапами создания ПО. Обычно по завершении основных больших этапов, таких как разработка спецификации, проектирование и т.п., заказчику ПО предоставляются результаты их выполнения, так называемые контрольные проектные элементы. Это может быть документация, прототип программного продукта, законченные подсистемы ПО и т.д. Контрольные проектные элементы, предоставляемые заказчику ПО, могут совпадать с контрольными отметками (точнее, с результатами выполнения какого-либо этапа). Но обратное утверждение неверно. Контрольные отметки — это внутренние проектные результаты, которые используются для контроля за ходом выполнения проекта, и они, как правило, не предоставляются заказчику ПО. Для определения контрольных отметок весь процесс создания ПО должен быть разбит на отдельные этапы с указанным "выходом" (результатом) каждого этапа. Например, на рисунке 4.1 показаны этапы разработки спецификации требований в случае, когда для ее проверки используется прототип системы, а также представлены выходные результаты (контрольные отметки) каждого этапа. Здесь контрольными проектными элементами являются требования и спецификация требований. Рисунок 8.1 - Этапы процесса разработки спецификации График работ Составление графика - одна из самых ответственных работ, выполняемых менеджером проекта. Здесь менеджер оценивает длительность проекта, определяет ресурсы, необходимые для реализации отдельных этапов работ, и представляет их (этапы) в виде согласованной последовательности. Если данный проект подобен ранее реализованному, то график работ последнего проекта можно взять за основу для данного проекта. Но затем следует учесть, что на отдельных этапах нового проекта могут использоваться методы и подходы, отличные от использованных ранее. Если проект является инновационным, первоначальные оценки длительности и требуемых ресурсов наверняка будут слишком оптимистичными, даже если менеджер попытается предусмотреть все возможные неожиданности. С этой точки зрения проекты создания ПО не отличаются от больших инновационных технических проектов. Новые аэропорты, мосты и даже новые автомобили, как правило, появляются позже первоначально объявленных сроков их сдачи или поступления на рынок, чему причиной являются неожиданно возникшие проблемы и трудности. Именно поэтому графики работ необходимо постоянно обновлять по мере поступления новой информации о ходе выполнения проекта. В процессе составления графика (рисунок 8.2) весь массив работ, необходимых для реализации проекта, разбивается на отдельные этапы и оценивается время, требующееся для выполнения каждого этапа. Обычно многие этапы выполняются параллельно. График работ должен предусматривать это и распределять производственные ресурсы между ними наиболее оптимальным образом. Нехватка ресурсов для выполнения какого-либо критического этапа - частая причина задержки выполнения всего проекта. Длительность этапов обычно должна быть не меньше недели. Если она будет меньше, то окажется ниже точности временных оценок этапов, что может привести к частому пересмотру графика работ. Также целесообразно (в аспекте управления проектом) установить максимальную длительность этапов, не превышающую 8 или 10 недель. Если есть этапы, имеющие большую длительность, их следует разбить на этапы меньшей длительности. При расчете длительности этапов менеджер должен учитывать, что выполнение любого этапа не обойдется без больших или маленьких проблем и задержек. Разработчики могут допускать ошибки или задерживать свою работу, техника может выйти из строя либо аппаратные или программные средства поддержки процесса разработки могут поступить с опозданием. Если проект инновационный и технически сложный, это становится дополнительным фактором появления непредвиденных проблем и увеличения длительности реализации проекта по сравнению с первоначальными оценками. Кроме временных затрат, менеджер должен рассчитать другие ресурсы, необходимые для успешного выполнения каждого этапа. Особый вид ресурсов — это команда разработчиков, привлеченная к выполнению проекта. Другими видами ресурсов могут быть необходимое свободное дисковое пространство на сервере, время использования какого-либо специального оборудования и бюджетные средства на командировочные расходы персонала, работающего над проектом. Требования к ПО Диаграммы процессов и временные диаграммы Рисунок 8.2 - Процесс составления графика работ Существует хорошее эмпирическое правило: оценивать временные затраты так, как будто ничего непредвиденного и "плохого" не может случиться, затем увеличить эти оценки для учета возможных проблем. Возможные, но трудно прогнозируемые проблемы существенно зависят от типа и параметров проекта, а также от квалификации и опыта членов команды разработчиков. К исходным расчетным оценкам рекомендуется добавлять 30% на возможные проблемы и затем еще 20%, чтобы быть готовым к тому, что невозможно предвидеть. График работ по проекту обычно представляется в виде набора диаграмм и графиков, показывающих разбиение проектных работ на этапы, зависимости между этапами и распределение разработчиков по этапам. Временные и сетевые диаграммы Временные и сетевые диаграммы полезны для представления графика работ. Временная диаграмма показывает время начала и окончания каждого этапа и его длительность. Сетевая диаграмма отображает зависимости между различными этапами проекта. Эти диаграммы можно создать автоматически с помощью программных средств поддержки управления на основе информации, заложенной в базе данных проекта. Рассмотрим этапы некоего проекта, представленные в табл. 8.2, из которой, в частности, видно, что этап Т3 зависит от этапа Т1. Это значит, что этап Т1 должен завершиться прежде, чем начнется этап Т3. Например, на этапе Т1 проводится компонентный анализ создаваемого программного продукта, а на этапе Т3 — проектирование системы. Таблица 8.2 - Этапы проекта Этап Длительность (дни) Т1 8 Т2 15 Т3 15 Т4 10 Т5 10 Т6 5 Т7 20 Т8 25 Т9 15 Зависимость Т1 (М1) Т2, Т4 (М2) Т1, Т2 (М3) Т1 (М1) Т4 (М5) Т3, Т6 (М4) Т10 Т11 Т12 15 7 10 Т5, Т7 (М7) Т9 (М6) Т11 (М8) На основе приведенных значений длительности этапов и зависимости между ними строится сетевой график последовательности этапов (рисунок 8.3). На этом графике видно, какие работы могут выполняться параллельно, а какие должны выполняться последовательно друг за другом. Этапы обозначены прямоугольниками. Контрольные отметки и контрольные проектные элементы показаны в виде овалов и обозначены (как и в табл. 8.2) буквой М с соответствующим номером. Даты на данной диаграмме соответствуют началу выполнения этапов. Сетевую диаграмму следует читать слева направо и сверху вниз. Рисунок 8.3 - Сетевая диаграмма этапов Если для создания сетевой диаграммы используются программные средства поддержки управления проектом, каждый этап должен заканчиваться контрольной отметкой. Очередной этап может начаться только тогда, когда будет получена контрольная отметка (которая может зависеть от нескольких предшествующих этапов). Поэтому в третьем столбце табл. 8.2 приведены контрольные отметки; они будут достигнуты только тогда, когда будет завершен этап, в строке которого помещена соответствующая контрольная отметка. Любой этап не может начаться, пока не выполнены все этапы на всех путях, ведущих от начала проекта к данному этапу. Например, этап Т9 не может начаться, пока не будут завершены этапы ТЗ и Т6. Отметим, что в данном случае достижение контрольной отметки М4 говорит о том, что эти этапы завершены. Минимальное время выполнения всего проекта можно рассчитать, просуммировав в сетевой диаграмме длительности этапов на самом длинном пути (длина пути здесь измеряется не количеством этапов на пути, а суммарной длительностью этих этапов) от начала проекта до его окончания (это так называемый критический путь). В нашем случае продолжительность проекта составляет 11 недель или 55 рабочих дней. На рис. 8.3 критический путь показан более толстыми линиями, чем остальные пути. Таким образом, общая продолжительность реализации проекта зависит от этапов работ, находящихся на критическом пути. Любая задержка в завершении любого этапа на критическом пути приведет к задержке всего проекта. Задержка в завершении этапов, не входящих в критический путь, не влияет на продолжительность всего проекта до тех пор, пока суммарная длительность этих этапов (с учетом задержек) на каком-нибудь пути не превысит продолжительности работ на критическом пути. Например, задержка этапа Т8 на срок, меньший 20 дней, никак не влияет на общую продолжительность проекта. На рис. 8.4 представлена временная диаграмма, на которой показаны возможные задержки на каждом этапе. Рисунок 8.4 - Временная диаграмма длительности этапов Сетевая диаграмма позволяет увидеть в зависимости этапов значимость того или иного этапа для реализации всего проекта. Внимание к этапам критического пути часто позволяет найти способы их изменения с тем, чтобы сократить длительность всего проекта. Менеджеры используют сетевую диаграмму для распределения работ. На рис. 8.5 показано другое представление графика работ. Это временная диаграмма (иногда называемая по имени ее изобретателя диаграммой Ганта) может быть построена программными средствами поддержки процесса управления. Она показывает длительность выполнения каждого этапа и возможные их задержки (показаны затененными прямоугольниками), а также даты начала и окончания каждого этапа. Этапы критического пути не имеют затененных прямоугольников; это означает, что задержка с завершением данных этапов приведет к увеличению длительности всего проекта. Таблица 8.3 - Распределение исполнителей по этапам Этап Т1 Т2 Т3 Т4 Т5 Исполнитель Джейн Анна Джейн Фред Мэри Т6 Анна Т7 Джим Т8 Фред Т9 Джейн Т10 Анна Т11 Фред Т12 Фред Подобно распределению времени выполнения этапов, менеджер должен рассчитать распределение ресурсов по этапам, в частности назначить исполнителей на каждый этап. В табл. 8.3 приведено распределение разработчиков на каждый этап, представленный на рис. 8.5. Приведенная таблица может быть использована программными средствами поддержки процесса управления для построения временной диаграммы занятости сотрудников на определенных этапах работ (рис. 8.5). Персонал не занят в работе над проектом все время его реализации. В течение периода незанятости сотрудники могут быть в отпуске, работать над другими проектами, проходить обучение и т.д. Рисунок 8.5 - Временная диаграмма распределения работников по этапам В больших организациях обычно работает много специалистов, которые задействуются в проекте по мере необходимости. Конечно, такой подход может создать определенные проблемы для менеджеров проектов. Например, если специалист занят в проекте, который задерживается, это может создать прямые сложности для других проектов, где он также должен участвовать. Первоначальный график работ неизбежно содержит какие-нибудь ошибки или недоработки. По мере реализации проекта рассчитанные оценки длительности выполнения этапов работ должны сравниваться с реальными сроками выполнения этих этапов. Результаты сравнения должны использоваться в качестве основы для пересмотра графика работ еще не реализованных этапов проекта, в частности для того, чтобы попытаться уменьшить длительность этапов критического пути. Постановка задачи к лабораторной работе 8 1. Изучить предлагаемый теоретический материал. 2. Построить временную и сетевую диаграммы для выбранного проекта. 3. Построить диаграмму распределения участников группы по этапам. 4. Построить список возможных рисков с указанием названия и описания риска. 5. Провести анализ рисков. 6. Описать стратегию планирования рисков. 7. Построить отчѐт, включающий все полученные диаграммы и описание стратегии планирования рисков. Представить отчет для защиты. Варианты индивидуальных заданий В соответствии с указанной предметной областью и классом разрабатываемой информационной системы построить временную и сетевую диаграммы; построить диаграмму распределения участников группы по этапам; построить список возможных рисков с указанием названия и описания риска; провести анализ рисков; описать стратегию планирования рисков. № 1 2 3 4 5 6 7 8 9 10 Таблица 8.4 – Индивидуальные задания Предметная область Склад Производственное предприятие Торговое предприятие Торговое предприятие Торговое предприятие Портал Строительное предприятие Высшее учебное заведение Инфраструктура предприятия Аппаратная инфраструктура предприятия Класс ИС MRP ERP CRM SCM B2C В2В ИС учета ИС управления СППР Экспертная система Содержание отчета По выполненной работе составляется отчет. Отчет выполняется в электронном виде. По выполненному отчету проводится защита лабораторной работы. Отчет по лабораторной работе должен состоять из следующих структурных элементов: - титульный лист; - вводная часть: краткое описание целей проекта. Вводная часть отчета должна включать пункты: условие задачи; порядок выполнения; программно-аппаратные средства, используемые при выполнении работы. - основная часть (описание работы): описание информационной системы; временная и сетевая диаграммы управления проектом разработки ИС; диаграмма распределения участников группы по этапам; список рисков; анализ рисков; стратегия планирования рисков. - заключение (выводы); - список использованной литературы. Зашита отчета по лабораторной работе заключается в предъявлении преподавателю полученных результатов в виде файла и демонстрации полученных навыков при ответах на вопросы преподавателя. Контрольные вопросы 1. Управление качеством программного продукта. 2. Процесс планирования создания ПО. 3. Контрольные отметки этапов работ. 4. Диаграммы процессов и временные диаграммы. 5. Временные и сетевые диаграммы. 6. Распределение исполнителей по этапам 7. Типы рисков, которые могут оказать влияние на данный проект 8. Схема процесса управления рисками 9. Результаты анализа рисков Лабораторная работа 9. Стратегии управления рисками применительно к проектам программных приложений Цель работы: Изучение стратегии управления рисками IT-проектов. Получение навыков по применению данных методологий для планирования проекта. Изучение методов управления рисками применительно к проектам программных приложений. Лабораторная работа направлена на ознакомление с основными понятиями управления рисками применительно к проектам программных приложений, получение навыков по применению данных понятий при проектировании программных приложений, построения графика работ, распределения исполнителей, управления рисками . Требования к результатам выполнения лабораторной работы: Построить стратегию управления рисками, включающую: - определение всех этапов проекта, зависимых этапов, определение длительности этапов; - построение на основе полученных данных сетевой и временной диаграмм; - построение диаграммы распределения работников по этапам; - разработку показателей качества выполнения проекта по этапам; - разработку стратегии управления рисками по этапам. При определении этапа указывается его название. Основы теории Стратегии управления рисками применительно к проектам программных приложений Важной частью работы менеджера проекта является оценка рисков, которые могут повлиять на график работ или на качество создаваемого программного продукта, и разработка мероприятий по предотвращению рисков. Результаты анализа рисков должны быть отражены в плане проекта. Определение рисков и разработка мероприятий по уменьшению их влияния на ход выполнения проекта называется управлением рисками. Конкретные типы рисков, которые могут оказать влияние на данный проект, зависят от вида создаваемого программного продукта и от организационного окружения, где реализуется программный проект. Вместе с тем многие типы рисков способны повлиять на любые программные проекты, эти риски приведены в табл. 9.1. Таблица 9.1 - Возможные риски программных проектов Риск Типы риска Описание риска Текучесть Риск для проекта Опытные разработчики покидают проект до разработчиков его завершения Изменение в Риск для проекта Организация меняет свои приоритеты в управлении управлении проектом организацией Неготовность Риск для проекта Аппаратные средства, которые необходимы аппаратных средств для проекта, не поступили вовремя или не готовы к эксплуатации Изменение Риск для проекта и Появление большого количества требований для непредвиденных изменений в требованиях, разрабатываемого предъявляемых к разрабатываемому ПО продукта Задержка в Риск для проекта и Спецификации основных интерфейсов разработке для подсистем не поступили к разработчикам в спецификации разрабатываемого соответствии с графиком работ продукта Риск для проекта и Размер системы значительно превысил для первоначальную оценку разрабатываемого продукта Недостаточная Риск для CASE-средства, предназначенные для эффективность CASE- разрабатываемого поддержки проекта, оказались менее средств продукта эффективными, чем ожидалось Изменения в Бизнес-риск Основные технологии построения технологии программной системы заменяются новыми разработки ПО Появление Бизнес-риск На рынке программных продуктов до конкурирующего окончания проекта появилась программного конкурирующая программная система продукта Упрощенно риск можно понимать как вероятность проявления каких-либо неблагоприятных обстоятельств, негативно влияющих на реализацию проекта. Риски могут угрожать проекту в целом, создаваемому программному продукту или организацииразработчику. Можно выделить три типа рисков. 1. Риски для проекта, которые влияют на график работ или ресурсы, необходимые для выполнения проекта. 2. Риски для разрабатываемого продукта, влияющие на качество или производительность разрабатываемого программного продукта. 3. Бизнес-риски, относящиеся к организации-разработчику или поставщикам. Конечно, эти типы рисков могут пересекаться. Например, если опытный программист покидает проект, это будет риском для проекта (поскольку задерживается срок сдачи готового продукта), риском для продукта (так как новый программист, заменивший ушедшего, может оказаться не слишком опытным и сделать ошибки в программе) и бизнес-риском (поскольку задержка данного проекта может негативно повлиять на будущие деловые контакты между заказчиком и организациейразработчиком). Схема процесса управления рисками показана на рис. 9.1. Этот процесс состоит из четырех стадий. 1. Определение рисков. Определяются возможные риски для проекта, для разрабатываемого продукта и бизнес-риски. 2. Анализ рисков. Оценивается вероятность и последовательность появления рисковых ситуаций. 3. Планирование рисков. Планируются мероприятия по предотвращению рисков или минимизации их воздействия на проект. 4. Мониторинг рисков. Постоянное оценивание вероятностей рисков и выполнение мероприятий по смягчению последствий проявления рисковых ситуаций. Недооценка размера разрабатываемой системы Рисунок 9.1 - Процесс управления рисками Процесс управления рисками, как и другие процессы планирования, является итерационным, выполняемым в течение всего срока реализации проекта. Сначала разрабатываются планы управления рисками, затем постоянно отслеживается ситуация вокруг реализации проекта. При поступлении новой информации о возможных рисках заново проводится анализ рисков и первостепенное внимание уделяется новым рискам. По мере поступления новой информации также изменяются планы мероприятий по предотвращению и смягчению рисков. Результаты процесса управления рисками документируются в виде планов управления рисками. Они должны включать описание возможных проектных рисков, их анализ и перечень мероприятий, необходимых для управления рисками. Определение рисков Определение рисков — первая стадия процесса управления рисками. На этой стадии описываются риски, которые могут проявиться при реализации проекта. В принципе на этой стадии не должна оцениваться вероятность и значимость рисков, но на практике маловероятные риски с незначительными последствиями обычно отбрасываются сразу. Определение рисков может выполняться в режиме командной работы с использованием подхода "мозговой штурм" либо основываться на опыте менеджера. При определении рисков может помочь приведенный ниже список возможных категорий рисков. 1. Технологические риски. Проистекают из программных и аппаратных технологий, на основе которых разрабатывается система. 2. Риски, связанные с персоналом. Связаны с членами команды разработчиков. 3. Организационные риски. Проистекают из организационного окружения, в котором выполняется проект. 4. Инструментальные риски. Связаны с используемыми CASE-средствами и другими средствами поддержки процесса создания ПО. 5. Риски, связанные с системными требованиями. Проявляются при изменении требований, предъявляемых к разрабатываемой системе. 6. Риски оценивания. Связаны с оцениванием характеристик программной системы и ресурсов, необходимых для реализации проекта. В табл. 9.2 представлены некоторые примеры, относящиеся к каждой из описанных категорий рисков. Результатом этапа определения рисков будет длинный список возможных рисков, которые могут повлиять на разрабатываемый программный продукт, проект или организацию-разработчика. Таблица 9.2 - Категории рисков Категория рисков Примеры рисков Технологические риски База данных, которая используется в программной системе, не обеспечивает обработку ожидаемого объема транзакций. Программные компоненты, которые используются повторно, имеют дефекты, ограничивающие их функциональные возможности Риски, связанные с Невозможно подобрать работников с требуемым персоналом профессиональным уровнем. Ведущий разработчик заболел в самое критическое время. Невозможно организовать необходимое обучение персонала Организационные риски В организации, выполняющей разработку ПО, произошла реорганизация, в результате чего изменились приоритеты в управлении проектом. Финансовые затруднения в организации привели к уменьшению бюджета проекта Инструментальные риски Программный код, генерируемый CASE-средствами, не эф- фективен. CASE-средства невозможно интегрировать с другими средствами поддержки проекта Риски, связанные с Изменения требований приводят к значительным повторным системными требованиями темными требованиями работам по проектированию системы. Первоначальная нечеткая формулировка пользовательских требований привела к значительным изменениям системных требований, проявившихся на поздних стадиях разработки проекта Риски оценивания Недооценки времени выполнения проекта. Скорость выявления дефектов в системе ниже ранее запланированной. Размер системы значительно превышает первоначально рассчитанный Анализ рисков При анализе для каждого определенного риска подсчитывается вероятность его проявления и ущерб, который он может нанести. Не существует простых методов выполнения анализа рисков — в значительной мере он основан на мнении и опыте менеджера. Можно привести следующую шкалу вероятностей рисков и их последствий. Вероятность риска считается очень низкой, если она имеет значение менее 10%; низкой, если ее значение от 10 до 25 %; средней при значениях от 25 до 50%; высокой, если значение колеблется от 50 до 75%; очень высокой при значениях более 75%. Возможный ущерб от рисковых ситуаций можно подразделить на катастрофический, серьезный, терпимый и незначительный. Результаты анализа рисков должны быть представлены в виде таблицы рисков, упорядоченных по степени возможного ущерба. В табл. 9.3 приведен упорядоченный список рисков, описанных в табл. 9.2 там же указаны вероятности этих рисков. Здесь вероятности рисков и степень ущерба от них указаны произвольно. На практике для их определения необходима подробная информация о проекте, технологии создания ПО, команде разработчиков и о самой организации. Таблица 9.3 - Список рисков после проведения их анализа Риск Вероятность Финансовые затруднения в организации привели к Низкая уменьшению бюджета проекта Невозможно подобрать работников с требующимся Высокая профессиональным уровнем Ведущий разработчик заболел в самое критическое Средняя время Программные компоненты, используемые повторно, Средняя имеют дефекты, ограничивающие их функциональные возможности Изменения требований приводят к значительным Средняя повторным работам по проектированию системы В организации, выполняющей разработку ПО, Высокая произошла реорганизация, в результате чего изменились приоритеты в управлении проектом База данных, которая используется в программной Средняя системе, не обеспечивает обработку ожидаемого объема транзакций Степень ущерба Катастрофическая Катастрофическая Серьезная Серьезная Серьезная Серьезная Серьезная Недооценки времени выполнения проекта CASE-средства невозможно интегрировать с другими средствами поддержки проекта Первоначальная нечеткая формулировка пользовательских требований привела к значительным изменениям системных требований, проявившихся на поздних стадиях разработки проекта Невозможно организовать необходимое обучение персонала Скорость выявления дефектов в системе ниже ранее спланированной Размер системы значительно превышает первоначально рассчитанный Программный код, генерируемый CASE-средствами, неэффективен Высокая Высокая Серьезная Терпимая Средняя Терпимая Средняя Терпимая Средняя Терпимая Высокая Терпимая Средняя Незначительная Конечно, как вероятность рисков, так и возможный ущерб от них должны пересматриваться при поступлении дополнительной информации об этих рисках и по мере реализации мероприятий по управлению ими. Поэтому подобные таблицы рисков должны переделываться на каждой итерации процесса управления рисками. После проведения анализа рисков определяются наиболее значимые риски, которые затем отслеживаются на протяжении всего срока выполнения проекта. Определение этих значимых рисков зависит от их вероятностей и возможного ущерба. В общем случае всегда отслеживаются риски с катастрофическими последствиями, а также риски с серьезным ущербом, значение вероятности которых выше среднего. В некоторых статьях рекомендуется определить и отслеживать "10 верхних" рисков, но это не всегда обоснованная рекомендация. Количество рисков, которые необходимо отслеживать, зависит от конкретного проекта. Это может быть пять рисков, а может — пятнадцать. Но, конечно, количество рисков, по которым проводится мониторинг, должно быть обозримым. Большое количество отслеживаемых рисков потребует огромного количества собираемой информации. Из списка рисков, представленных в табл. 9.6, для мониторинга следует отобрать те риски, которые могут привести к катастрофическим и серьезным последствиям для вашего проекта. Планирование рисков Планирование заключается в определении стратегии управления каждым значимым риском, отобранным для мониторинга после анализа рисков. Здесь также не существует общепринятых подходов для разработки таких стратегий — многое основывается на "чутье" и опыте менеджера проекта. В табл. 9.4 показаны возможные стратегии управления основными рисками, приведенными в табл. 9.3. Таблица 9.4 - Стратегии управления рисками Риск Стратегия Финансовые проблемы Подготовить краткий документ для руководства организации, организации показывающий важность данного проекта для достижения финансовых целей организации Проблемы Предупредить заказчика о потенциальных трудностях и неквалифицированного возможной задержке проекта, рассмотреть вопрос о покупке персонала компонентов системы Болезни персонала Реорганизовать работу команды разработчиков таким образом, чтобы обязанности и работа членов команды перекрывали друг друга, вследствие этого разработчики будут знать и понимать задачи, выполняемые другими сотрудниками Дефектные системные Заменить потенциально дефектные системные компоненты компоненты покупными компонентами, гарантирующими качество работы Изменения требований Попытаться определить требования, наиболее вероятно подверженные изменениям; в структуре системы не отображать детальную информацию Реорганизация Подготовить краткий документ для руководства компании, компаниипоказывающий важность данного проекта для достижения разработчика финансовых целей компании Недостаточная Рассмотреть возможность покупки более производительной базы производительность данных базы данных Недооценки времени Рассмотреть вопрос о покупке системных компонентов, выполнения проекта исследовать возможность использования генератора программного кода Существует три категории стратегий управления рисками. 1. Стратегии предотвращения рисков. Согласно этим стратегиям следует проводить мероприятия, снижающие вероятность проявления рисков. Примером может служить стратегия исключения потенциально дефектных компонентов, описанная в табл. 9.4. 2. Минимизационные стратегии. Направлены на уменьшение возможного ущерба от рисков. Примером служит стратегия уменьшения ущерба от болезни членов команды разработчиков (см. табл. 9.4). 3. Планирование "аварийных" ситуаций. Согласно этим стратегиям необходимо иметь план мероприятий, которые следует выполнить в случае проявления рисковой ситуации. В табл. 9.4 это стратегия поведения при возникновении финансовых проблем у организации-разработчика. Мониторинг рисков Мониторинг рисков заключается в регулярном пересчете вероятностей рисков и ущерба, который они могут нанести. Для этого необходимо постоянно отслеживать факторы, которые влияют на вероятность рисков и возможный ущерб. Эти факторы зависят от типов риска. В табл. 9.5 приведены признаки, которые помогают определить тип риска. Таблица 9.5 - Признаки рисков Тип риска Признаки Технологические Задержки в поставке оборудования или программных средств риски поддержки процесса создания ПО, многочисленные документированные технологические проблемы Риски, связанные с Низкое моральное состояние персонала, натянутые отношения персоналом между членами команды разработчиков, низкое качество выполненной работы Организационные Разговоры среди персонала о пассивности и недостаточной риски компетентности высшего руководства организации Инструментальные Нежелание разработчиков использовать программные средства риски поддержки, неодобрительные отзывы о CASE-средствах, запросы на более мощные инструментальные средства Риски, связанные с Необходимость пересмотра многих системных требований, системными недовольство заказчика ПО требованиями Риски оценивания Изменения графика работ, многочисленные отчеты о нарушении графика работ Мониторинг рисков должен быть непрерывным процессом, отслеживающим ход выполнения мероприятий по управлению рисками, при этом каждый основной риск должен рассматриваться отдельно. Постановка задачи к лабораторной работе 9 1. Изучить предлагаемый теоретический материал. 2. Построить временную и сетевую диаграммы для выбранного проекта. 3. Построить диаграмму распределения участников группы по этапам. 4. Построить список возможных рисков с указанием названия и описания риска. 5. Провести анализ рисков. 6. Описать стратегию планирования рисков. 7. Построить отчѐт, включающий все полученные диаграммы и описание стратегии планирования рисков. Представить отчет для защиты. Варианты индивидуальных заданий В соответствии с указанной предметной областью и классом разрабатываемой информационной системы построить временную и сетевую диаграммы; построить диаграмму распределения участников группы по этапам; построить список возможных рисков с указанием названия и описания риска; провести анализ рисков; описать стратегию планирования рисков. № 1 2 3 4 5 6 7 8 9 10 Таблица 9.6 – Индивидуальные задания Предметная область Склад Производственное предприятие Торговое предприятие Торговое предприятие Торговое предприятие Портал Строительное предприятие Высшее учебное заведение Инфраструктура предприятия Аппаратная инфраструктура предприятия Класс ИС MRP ERP CRM SCM B2C В2В ИС учета ИС управления СППР Экспертная система Содержание отчета По выполненной работе составляется отчет. Отчет выполняется в электронном виде. По выполненному отчету проводится защита лабораторной работы. Отчет по лабораторной работе должен состоять из следующих структурных элементов: - титульный лист; - вводная часть: краткое описание целей проекта. Вводная часть отчета должна включать пункты: условие задачи; порядок выполнения; программно-аппаратные средства, используемые при выполнении работы. - основная часть (описание работы): описание информационной системы; временная и сетевая диаграммы управления проектом разработки ИС; диаграмма распределения участников группы по этапам; список рисков; анализ рисков; стратегия планирования рисков. - заключение (выводы); - список использованной литературы. Защита отчета по лабораторной работе заключается в предъявлении преподавателю полученных результатов в виде файла и демонстрации полученных навыков при ответах на вопросы преподавателя. Контрольные вопросы 1. Управление рисками при проектировании программного продукта. 2. Процесс управления рисками. 3. Контрольные отметки этапов работ. 4. Диаграммы процессов и временные диаграммы. 5. Временные и сетевые диаграммы. 6. Распределение исполнителей по этапам 7. Типы рисков, которые могут оказать влияние на данный проект 8. Схема процесса управления рисками 9. Результаты анализа рисков 5. УЧЕБНО-МЕТОДИЧЕСКОЕ И ИНФОРМАЦИОННОЕ ОБЕСПЕЧЕНИЕ ДИСЦИПЛИНЫ 5.1. Перечень основной и дополнительной литературы, необходимой для освоения дисциплины 5.1.1. Перечень основной литературы 1. Заботина, Н. Н. Проектирование информационных систем: учеб. пособие/ Н.Н. Заботина. – М.: ИНФРА-М, 2017. – 329 с. 2. Коваленко, В. В. Проектирование информационных систем: учеб. пособие для вузов/ В.В. Коваленко. – М.: Форум, 2016. – 319 с. 5.1.2. Перечень дополнительной литературы 1. Емельянова, Н. З. Проектирование информационных систем: учебное пособие/ Н. З. Емельянова, Т. Л. Партыка, И. И. Попов. – М.: ФОРУМ, 2017. – 432 с. 2.Гвоздева, Т. В. Проектирование информационных систем: учеб. пособие/ Т. В. Гвоздева, Б. А. Баллод. – Ростов-на-Дону: Феникс, 2016. – 508 с. 5.2. Перечень учебно-методического обеспечения самостоятельной работы обучающихся по дисциплине 1. Методические указания по выполнению лабораторных работ по дисциплине «Разработка программных приложений». 2. Методические рекомендации для студентов по организации самостоятельной работы по дисциплине «Разработка программных приложений». 5.3. Перечень ресурсов информационно-телекоммуникационной сети Интернет, необходимых для освоения дисциплины 1. Национальный Открытый Университет. Интуит. http://www.intuit.ru. 2. Федеральный портал «Российское образование. http://www.edu.ru. 3. Российская государственная библиотека. http://www.rsl.ru. Приложение А ТЕХНИЧЕСКОЕ ЗАДАНИЕ на разработку ИС «Система» Общие сведения 1.1. Наименование системы Аналитическая информационная система «Система». 2.1. Назначение и цели создания системы Система «Система» предназначена для информационного обеспечения процессов, которые происходят на кафедре связанных с учебно-методической, научной, общественной, организационно-методической и воспитательной работой. Характеристика объектов информатизации 3.1. Краткое описание работы кафедры К основным направлениям работы кафедры относятся: - Учебно-методическая работа; - Научная работа; - Организационно-методическая работа; - Работа со студентами заочниками; - Общественная работа; - Воспитательная работа. … 3.2. Описание объектов информатизации К основным объектам информатизации системы относятся: Кафедра - Наименование кафедры - Факультет, к которому относится кафедра - Веб-сайт кафедры - Заведующий кафедрой … 3.2.1. Учебно-методическая работа План учебно-методической работы кафедры - Учебный год - Заведующий кафедрой, составивший план - Кафедра Тема для учебно-методической работы - Названия работ - Сроки исполнения - Ответственные за выполнение темы … Требования к информационной системе 4.1. Базовые принципы разработки подсистем При проектировании и разработке подсистем должны использоваться следующие базовые принципы: - Исключение дублирования ввода информации и повышение ее достоверности, за счет отождествления ранее введенной информации; … Система должна удовлетворять следующим требованиям: - Пользовательский интерфейс системы должен быть сформирован в соответствии с навыками и профилем пользователей; … Система должна содержать: - Средства поиска информации; … Выбор прикладного программного обеспечения системы должен удовлетворять следующим критериям: - Интеграция с базами данных, поддерживающих Web-технологии; … 4.2. Требования к архитектуре системы. Архитектура системы «Система» является трехзвенной. В качестве клиентского приложения выступает стандартный веб-браузер. … 4.3. Требования к способам и средствам связи для информационного обмена между компонентами (модулями) Системы Подсистемы должны взаимодействовать в пределах единой компьютерной сети (Интернет/Интранет), в которой происходит весь обмен информацией. … 4.4. Требования к характеристикам взаимосвязей системы со смежными системами Смежными системами для информационной системы «Система» являются: «Система2», … 4.5. Требования к режимам функционирования подсистемы Разрабатываемая система должна функционировать 24 часа в сутки, 365 дней в году… … 4.6. Требования к пользователям Система подразумевает четыре типа пользователя: - Сотрудник – имеет доступ к просмотру общих данных по своей кафедре, а также к просмотру и редактированию личных данных, имеет возможность ; … 4.7. Требования по эргономике и технической эстетике Основными требованиями по эргономике и технической эстетике является адекватность времени реакции модулей системы на сложность запроса пользователя к базам данных: - При выполнении стандартных запросов пользователь должен работать с системой в реальном режиме времени; … 4.8. Требования к численности и квалификации персонала системы и режиму его работы. Квалификация персонала, порядок его подготовки и контроль знаний и навыков. … 4.9. Требования к защите информации от несанкционированного доступа. Разрабатываемая система должна обладать специализированной подсистемой разграничения доступа к информационным ресурсам, функционирующей на основе системы пользователей и пользовательских групп. … 4.10. Требования к обмену данными - Обмен данными должен происходить по сети в среде Intranet/Internet с поддержкой протокола TCP/IP; … 4.11. Требования к внешней среде системы Сервер баз данных или сервер приложений должен обеспечивать: … 4.12. Требования к хранению данных База данных «Система» должна содержать следующие данные: - Данные о планировании учебно-методической работы; … 4.13. Требования к отдельным подсистемам 4.13.1. Учебно-методическая работа Функции заведующего кафедрой - Создание плана учебно-методической работы на учебный семестр, заполнения, редактирования и удаления данных плана; … Состав и содержание работ по созданию Системы Разработать модель БД, позволяющую хранить и обрабатывать все необходимые… … Приемо-сдаточные испытания Системы После завершения всех работ по разработке компонентов, настройке подсистем и … Внесение корректировок в программный продукт, связанных с ошибками в Системе Все ошибки, которые будут выявлены в работе Системы в течении 12 месяцев … Тестирование Перед сдачей Модулей и Компонент Заказчику для выявления возможных сбоев в работе … Порядок контроля и приемки Системы Для проверки выполнения заданных функций Системы, определения и проверки соответствия требованиям ТЗ количественных и (или) качественных характеристик Системы, выявления и устранения недостатков в действиях Системы и в разработанной документации, поэтапного контроля над ходом разработки должны быть проведены следующие виды испытаний: - Предварительные; … Процедуры тестирования и контроля качества При проведении испытаний должны использоваться следующие типы процедур тестирования и контроля качества: - функциональное тестирование - тестирование ПО на соответствие функциональным спецификациям; … Общие требования к приемке работ Сроки и место приемки, порядок приемки работ определяются в соответствии с настоящим ТЗ. … Требования к документированию 12.1. Требования к проектной документации Состав и комплектность проектной документации должна соответствовать требованиям ГОСТ 34.201-89. Перечень документации по созданию системы включает: - Описание информационного обеспечения системы (П5); …
