«Проектирование информационных систем»
Каскадная модель ЖЦ ПО: принципы, схема, достоинства, недостатки, применимость
Спиральная модель ЖЦ ПО: принципы, схема, достоинства, недостатки, применимость
Канонический подход к проектированию программного обеспечения ИС
Типовые проектные решения – назначение, классификация, применимость.
Технология RUP (принципы, схема, фазы, дисциплины, применимость)
Case-средства; классификация Case-средств (по уровню применения, специализированные, вспомогательные, интегрированные).
Общие сведения о языке визуального моделирования UML
Сущности в UML.
Диаграмма Вариантов использования в UML: назначение, принципы построения.
Диаграмма Классов в UML: назначение, принципы построения.
Диаграмма Последовательности в UML: назначение, принципы построения.
Диаграмма Состояний в UML: назначение, принципы построения.
Порядок и цель проведения объектно-ориентированного анализа
Порядок и цель проведения объектно-ориентированного проектирования
Каскадная модель ЖЦ ПО: принципы, схема, достоинства, недостатки, применимость
В 1970 г. эксперт в области ПО Уинстон Ройс разработал методику, которая позднее получила название «модель водопада» (waterfall model), или «каскадная модель». Каскадная модель (водопад - waterfall) характерна для периода 1970-1985 гг и включает выполнение следующих фаз:
исследование концепции — происходит исследование требований, разрабатывается видение продукта и оценивается возможность его реализации.
определение требований — определяются программные требования для информационной предметной области системы, предназначение, линии поведения, производительность и интерфейсы.
разработка проекта — разрабатывается и формулируется логически последовательная техническая характеристика программной системы, включая структуры данных, архитектуру ПО, интерфейсные представления и процессуальную (алгоритмическую) детализацию;
реализация — эскизное описание ПО превращается в полноценный программный продукт. Результат: исходный код, база данных и документация. В реализации обычно выделяют два этапа: реализацию компонент ПО и интеграцию компонент в готовый продукт. На обоих этапах выполняется кодирование и тестирование, которые тоже иногда рассматривают как два подэтапа.
эксплуатация и поддержка - подразумевает запуск и текущее обеспечение, включая предоставление технической помощи, обсуждение возникших вопросов с пользователем, регистрацию запросов пользователя на модернизацию и внесение изменений, а также корректирование или устранение ошибок;
сопровождение — устранение программных ошибок, неисправностей, сбоев, модернизация и внесение изменений. Состоит из итераций разработки.
Основными принципами каскадной модели являются:
Строго последовательное выполнение фаз:
Каждая последующая фаза начинается лишь тогда, когда полностью завершено выполнение предыдущей фазы
Каждая фаза имеет определенные критерии входа и выхода: входные и выходные данные.
Выполняемые в логической последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие затраты
Каждая фаза полностью документируется
Переход от одной фазы к другой осуществляется посредством формального обзора с участием заказчика
Основа модели – сформулированные требования (ТЗ), которые меняться не должны
Критерий качества результата – соответствие продукта установленным требованиям.
Каскадная модель. Преимущества и недостатки
Каскадная модель имеет следующие преимущества:
Проста и понятна заказчикам, т.к часто используется другими организациями для отслеживания проектов, не связанных с разработкой ПО
Проста и удобна в применении:
процесс разработки выполняется поэтапно.
ее структурой может руководствоваться даже слабо подготовленный в техническом плане или - неопытный персонал;
она способствует осуществлению строгого контроля менеджмента проекта;
Каждую стадию могут выполнять независимые команды (все документировано)
Позволяет достаточно точно планировать сроки и затраты
Недостатки:
Попытка вернуться на одну или две фазы назад, чтобы исправить какую-либо проблему или недостаток, приведет к значительному увеличению затрат и сбою в графике. Реальный процесс создания системы никогда полностью не укладывается в такую жесткую схему, постоянно возникает потребность в возврате к предыдущим этапам и уточнении или пересмотре ранее принятых решений. В результате реальный процесс создания ИС оказывается соответствующим поэтапной модели с промежуточным контролем
Интеграция компонент, на которой обычно выявляется большая часть ошибок, выполняется в конце разработки, что сильно увеличивает стоимость устранения ошибок;
Если в процессе выполнения проекта требования изменились, то получится устаревший результат. Согласование результатов разработки с пользователями производится после завершения каждого этапа работ, а общие требования к ИС зафиксированы в виде технического задания на все время ее создания. Таким образом, пользователи зачастую получают систему, не удовлетворяющую их реальным потребностям
Недостатки каскадной модели особо остро проявляются в случае, когда трудно (или невозможно) сформулировать требования или требования могут меняться в процессе выполнения проекта. В этом случае разработка ПО имеет принципиально циклический характер.
Каскадная модель. Применимость
Каскадная (водопадная) модель была первой моделью, получившей широкую известность и структурирующая процесс разработки ПО. Она была создана в 1968 г. И была доработана Уинстоном Ройсом В семидесятых-восьмидесятых годах XX века модель была принята как стандарт министерства обороны США. Со временем недостатки каскадной модели стали проявляться все чаще и возникло мнение, что она безнадежно устарела. Между тем, каскадная модель не утратила своей актуальности при решении следующих типов задач:
Требования и их реализация максимально четко определены и понятны; используется неизменяемое определение продукта и вполне понятные технические методики. Это задачи научно-вычислительного характера (пакеты и библиотеки научных программ типа расчета несущих конструкций зданий, мостов, …)
Выпуск новой версии уже существующего продукта, если вносимые изменения вполне определены и управляемы (перенос уже существующего продукта на новую платформу)
Принципы каскадной модели находят применение как элементы моделей других типов, о чем речь пойдет ниже.
Спиральная модель ЖЦ ПО: принципы, схема, достоинства, недостатки, применимость
На практике, при решении достаточно большого количества задач, разработка ПО имеет циклический характер, когда после выполнения некоторых стадий приходится возвращаться на предыдущие. Можно указать две основные причины таких возвратов:
Ошибки разработчиков, допущенные на ранних стадиях и выявленные на поздних стадиях – ошибки анализа, проектирования, кодирования, выявляемые, как правило, на стадии тестирования.
Изменение требований в процессе разработки («ошибки» заказчиков). Это или неготовность заказчиков сформулировать требования («Сказать, что должна делать программа я смогу только после того, как увижу как она работает»), или изменения требований, вызванные изменениями ситуации в процессе разработки (изменения рынка, новые технологии, …).
Истоки концепции итерационной разработки прослеживаются в относящихся к 1930-м годам. В 1988 году Барри Боэм предложил свой вариант циклической модели ПО - спиральную модель. Спиральная модель была предложена как альтернатива каскадной модели, учитывающая повторяющийся характер разработки ПО.
Спиральная модель Боэма сфокусирована на проектировании. Собственно разработка ПО происходит лишь на последнем витке спирали по обычной каскадной модели, однако этому предшествует несколько итераций проектирования на основе создания прототипов – при этом каждая итерация включает стадию выявления и анализа рисков и наиболее сложных задач.
Основные принципы спиральной модели можно сформулировать следующим образом:
Разработка вариантов продукта, соответствующих различным вариантам требований с возможностью вернуться к более ранним вариантам
Создание прототипов ПО как средства общения с заказчиком для уточнения и выявления требований
Планирование следующих вариантов с оценкой альтернатив и анализом рисков, связанных с переходом к следующему варианту
Переход к разработке следующего варианта до завершения предыдущего в случае, когда риск завершения очередного варианта (прототипа) становится неоправданно высок.
Использование каскадной модели как схемы разработки очередного варианта
Активное привлечение заказчика к работе над проектом. Заказчик участвует в оценке очередного прототипа ПО, уточнении требований при переходе к следующему, оценке предложенных альтернатив очередного варианта и оценке рисков.
Схема
работы спиральной модели выглядит
следующим образом. Разработка вариантов
продукта представляется как набор
циклов раскручивающейся спирали. Каждому
циклу спирали соответствует такое же
количество стадий, как и в модели
каскадного процесса. При этом, начальные
стадии, связанные с анализом и планированием
представлены более подробно с добавлением
новых элементов. В каждом цикле выделяются
четыре базовые фазы:
определение целей, альтернативных вариантов и ограничений.
оценка альтернативных вариантов, идентификация и разрешение рисков.
разработка продукта следующего уровня.
планирование следующей фазы.
«Раскручивание» проекта начинается с анализа общей постановки задачи на разработку ПО. Здесь на первой фазе определяются общие цели, устанавливаются предварительные ограничения, определяются возможные альтернативы подходов к решению задачи. Далее проводится оценка подходов, устанавливаются их риски. На шаге разработки создается концепция (видение) продукта и путей его создания.
Следующий цикл начинается с планирования требований и деталей ЖЦ продукта для оценки затрат. На фазе определения целей устанавливаются альтернативные варианты требований, связанные с ранжировкой требований по важности и стоимости их выполнения. На фазе оценки устанавливаются риски вариантов требований. На фазе разработки – спецификация требований (с указанием рисков и стоимости), готовится демо-версия ПО для анализа требований заказчиком.
Следующий цикл – разработка проекта – начинается с планирования разработки. На фазе определения целей устанавливаются ограничения проекта (по срокам, объему финансирования, ресурсам), определяются альтернативы проектирования, связанные с альтернативами требований, применяемыми технологиями проектирования, привлечением субподрядчиков. На фазе оценки альтернатив устанавливаются риски вариантов и делается выбор варианта для дальнейшей реализации. На фазе разработки выполняется проектирование и создается демо-версия, отражающая основные проектные решения.
Следующий цикл – реализация ПО – также начинается с планирования. Альтернативными вариантами реализации могут быть применяемые технологии реализации, привлекаемые ресурсы. Оценка альтернатив и связанных с ними рисков на этом цикле определяется степенью «отработанности» технологий и «качеством» имеющихся ресурсов. Фаза разработки выполняется по каскадной модели с выходом – действующим вариантном (прототипом) продукта.
Спиральная модель. Преимущества и недостатки
Спиральная модель (по отношению к каскадной) имеет следующие очевидные преимущества:
Более тщательное проектирование (несколько начальных итераций) с оценкой результатов проектирования, что позволяет выявить ошибки проектирования на более ранних стадиях.
Поэтапное уточнение требований в процессе выполнения итераций, что позволяет более точно удовлетворить требованиям заказчика
Участие заказчика в выполнении проекта с использованием прототипов программы. Заказчик видит, что и как создается, не выдвигает необоснованных требований, оценивает реальные объемы финансирования.
Планирование и управление рисками при переходе на следующие итерации позволяет разумно планировать использование ресурсов и обосновывать финансирование работ.
Возможность разработки сложного проекта «по частям», выделяя на первых этапах наиболее значимые требования.
Основные недостатки спиральной модели связаны с ее сложностью:
Сложность анализа и оценки рисков при выборе вариантов.
Сложность оценки точки перехода на следующий цикл
Бесконечность модели – на каждом витке заказчик может выдвигать новые требования, которые приводят к необходимости следующего цикла разработки.
Спиральная модель. Применимость
Спиральную модель целесообразно применять при следующих условиях:
Когда пользователи не уверены в своих потребностях или когда требования слишком сложны и могут меняться в процессе выполнения проекта и необходимо прототипирование для анализа и оценки требований.
Когда проект является сложным, дорогостоящим и обоснование его финансирования возможно только в процессе его выполнения
Когда речь идет о применении новых технологий, что связано с риском их освоения и достижения ожидаемого результата
При выполнении очень больших проектов, которые в силу ограниченности ресурсов можно делать только по частям.
Канонический подход к проектированию программного обеспечения ИС
Организация канонического проектирования ИС ориентирована на использование главным образом каскадной модели жизненного цикла ИС. Стадии и этапы работы описаны в стандарте ГОСТ 34.601-90.
В зависимости от сложности объекта автоматизации и набора задач, стадии и этапы работ могут иметь различную трудоемкость. Допускается объединять последовательные этапы и даже исключать некоторые из них на любой стадии проекта. Допускается также начинать выполнение работ следующей стадии до окончания предыдущей.
Стадии и этапы создания ИС, выполняемые организациями-участниками, прописываются в договорах и технических заданиях на выполнение работ:
Формирование требований к ИС
Разработка концепции ИС.
Техническое задание.
Эскизный проект
Технический проект
Рабочая документация
Ввод в действие
Сопровождение ИС
Стадия 1. Формирование требований к ИС.
На начальной стадии проектирования выделяют следующие этапы работ:
обследование объекта и обоснование необходимости создания ИС;
формирование требований пользователей к ИС;
оформление отчета о выполненной работе и технического задания на разработку.
Oбследование- это изучение и диагностический анализ организационной структуры предприятия, его деятельности и существующей системы обработки информации. На этапе обследования целесообразно выделить две составляющие: определение стратегии внедрения ИС и детальный анализ деятельности организации.
Основная задача первого этапа обследования - оценка реального объема проекта, его целей и задач. Эти задачи могут быть реализованы заказчиком ИС самостоятельно или с привлечением консалтинговых организаций. Этап предполагает тесное взаимодействие с основными потенциальными пользователями системы. Основная задача взаимодействия - получить полное и однозначное понимание требований заказчика. Как правило, нужная информация может быть получена в результате интервью, бесед или семинаров с руководством, экспертами и пользователями.
По завершении обследования появляется возможность определить вероятные технические подходы к созданию системы и оценить затраты на ее реализацию (затраты на аппаратное обеспечение, закупаемое программное обеспечение и разработку нового программного обеспечения).
Результатом этой стадии является технико-экономическое обоснование проекта (документ), где четко сформулировано:
что получит заказчик, если согласится финансировать проект, указываются также ограничения и риски, совокупность условий, при которых предполагается эксплуатировать будущую систему
когда он получит готовый продукт (график выполнения работ, сроки завершения отдельных этапов)
сколько это будет стоить (для крупных проектов должен быть составлен график финансирования на разных этапах работ).
Стадия 2. Разработка концепции ИС.
изучение объекта автоматизации;
проведение необходимых научно-исследовательских работ;
разработка вариантов концепции ИС, удовлетворяющих требованиям пользователей;
оформление отчета и утверждение концепции.
Вначале изучаются организационная структура, штаты и содержание работ по управлению предприятием, а также характер подчиненности вышестоящим органам управления. Одной из наиболее трудоемких, хотя и хорошо формализуемых задач этого этапа является описание документооборота организации.
По результатам этого процесса устанавливается перечень задач управления, решение которых целесообразно автоматизировать, и очередность их разработки.
Стадия 3. Техническое задание.
разработка и утверждение технического задания на создание ИС.
Техническое задание- это документ, определяющий цели, требования и основные исходные данные, необходимые для разработки автоматизированной системы управления.
При разработке технического задания необходимо решить следующие задачи:
установить общую цель создания ИС, определить состав подсистем и функциональных задач;
разработать и обосновать требования, предъявляемые к подсистемам;
разработать и обосновать требования, предъявляемые к информационной базе, математическому и программному обеспечению, комплексу технических средств (включая средства связи и передачи данных);
установить общие требования к проектируемой системе;
определить перечень задач создания системы и исполнителей;
определить этапы создания системы и сроки их выполнения;
провести предварительный расчет затрат на создание системы и определить уровень экономической эффективности ее внедрения.
Стадия 4. Эскизный проект.
разработка предварительных проектных решений по системе и ее частям;
разработка эскизной документации на ИС и ее части.
Эскизный проект предусматривает разработку предварительных проектных решений по системе и ее частям.
Выполнение стадии эскизного проектирования не является строго обязательной. Если основные проектные решения определены ранее или достаточно очевидны для конкретной ИС и объекта автоматизации, то эта стадия может быть исключена из общей последовательности работ.
Содержание эскизного проекта задается в ТЗ на систему. Как правило, на этапе эскизного проектирования определяются:
функции ИС;
функции подсистем, их цели и ожидаемый эффект от внедрения;
состав комплексов задач и отдельных задач;
концепция информационной базы и ее укрупненная структура;
функции системы управления базой данных;
состав вычислительной системы и других технических средств;
функции и параметры основных программных средств.
По результатам проделанной работы оформляется, согласовывается и утверждается документация в объеме, необходимом для описания полной совокупности принятых проектных решений и достаточном для дальнейшего выполнения работ по созданию системы.
Стадия 5. Технический проект.
разработка проектных решений по системе и ее частям;
разработка документации на ИС и ее части;
разработка и оформление документации на поставку комплектующих изделий;
разработка заданий на проектирование в смежных частях проекта.
На основе технического задания (и эскизного проекта) разрабатывается технический проект ИС. Технический проект системы - это техническая документация, содержащая общесистемные проектные решения, алгоритмы решения задач, а также оценку экономической эффективности автоматизированной системы управления и перечень мероприятий по подготовке объекта к внедрению.
Состав и содержание технического проекта
Пояснительная записка: основания для разработки системы, перечень организаций разработчиков краткая характеристика объекта
Функциональная и организационная структура системы: выделение подсистем, перечень задач, решаемых в каждой подсистеме, схема информационных связей между подсистемами и между задачами в рамках каждой подсистемы
Постановка задач и алгоритмы решения: организационно-экономическая сущность и экономико-математическая модель задачи, входная, накапливаемая и пр. информация
Организация информационной базы: источники поступления информации и способы ее передачи, методы хранения, поиска, внесения изменений и контроля, предложения по унификации документации
Система математического обеспечения: обоснование выбора системы программирования, перечень стандартных программ
Принцип построения комплекса технических средств: обоснование и выбор технических средств, обоснование требований к разработке нестандартного оборудования, комплекс мероприятий по обеспечению надежности функционирования технических средств
Расчет экономической эффективности системы: сводная смета затрат, связанных с эксплуатацией систем, расчет годовой экономической эффективности
В завершение стадии технического проектирования производится разработка документации на поставку серийно выпускаемых изделий для комплектования ИС, а также определяются технические требования и составляются ТЗ на разработку изделий, не изготовляемых серийно.
Стадия 6. Рабочая документация.
разработка рабочей документации на ИС и ее части;
разработка и адаптация программ.
На стадии осуществляется разработка всей сопровождающей документации. Документация должна содержать все необходимые и достаточные сведения для обеспечения выполнения работ по вводу ИС в действие и ее эксплуатации, а также для поддержания уровня эксплуатационных характеристик (качества) системы. Разработанная документация должна быть соответствующим образом оформлена, согласована и утверждена.
Стадия 7. Ввод в эксплуатацию.
подготовка объекта автоматизации;
подготовка персонала;
комплектация ИС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями);
строительно-монтажные работы;
пусконаладочные работы;
проведение предварительных испытаний;
проведение опытной эксплуатации;
проведение приемочных испытаний.
Для ИС, которые являются разновидностью автоматизированных систем, устанавливают следующие основные виды испытаний: предварительные, опытная эксплуатация и приемочные. При необходимости допускается дополнительно проведение других видов испытаний системы и ее частей.
В зависимости от частей ИС и объекта автоматизации испытания могут быть автономные или комплексные. Автономные испытания охватывают части системы. Их проводят по мере готовности частей системы к сдаче в опытную эксплуатацию. Комплексные испытания проводят для групп взаимосвязанных частей или для системы в целом.
Для планирования проведения всех видов испытаний разрабатывается документ "Программа и методика испытаний". Разработчик документа устанавливается в договоре или ТЗ. В качестве приложения в документ могут включаться тесты или контрольные примеры.
Предварительные испытания проводят для определения работоспособности системы и решения вопроса о возможности ее приемки в опытную эксплуатацию.
Опытную эксплуатацию системы проводят с целью определения фактических значений количественных и качественных характеристик системы и готовности персонала к работе в условиях ее функционирования, а также определения фактической эффективности и корректировки документации.
Приемочные испытания проводят для определения соответствия системы техническому заданию, оценки качества опытной эксплуатации и решения вопроса о возможности приемки системы в постоянную эксплуатацию.
Стадия 8. Сопровождение ИС.
выполнение работ в соответствии с гарантийными обязательствами;
послегарантийное обслуживание.
Типовые проектные решения – назначение, классификация, применимость.
Типовое проектирование ИС предполагает создание системы из готовых типовых элементов. Требованием для применения методов типового проектирования является возможность декомпозиции проектируемой ИС на множество составляющих компонентов (подсистем, комплексов задач, программных модулей и т.д.).
Для реализации выделенных компонентов выбираются имеющиеся на рынке типовые проектные решения, которые настраиваются на особенности конкретного предприятия.
Типовое проектное решение (ТПР)- это тиражируемое (пригодное к многократному использованию) проектное решение. Выделяются следующие классы ТПР:
Элементные ТПР - типовые решения по задаче или по отдельному виду обеспечения задачи (информационному, программному, техническому, математическому, организационному). Они представляют собой Библиотеки методо-ориентированных программ.
Достоинства обеспечивается применение модульного подхода к проектированию и документированию ИС. Недостатки большие затраты времени на сопряжение разнородных элементов вследствие информационной, программной и технической несовместимости, большие затраты времени на доработку ТПР отдельных элементов
Подсистемные ТПР - в качестве элементов типизации выступают отдельные подсистемы, разработанные с учетом функциональной полноты и минимизации внешних информационных связей. К ним относятся пакеты прикладных программ
Достоинства достигается высокая степень интеграции элементов ИС, обеспечивают сокращение затрат на проектирование и программирование взаимосвязанных компонентов; хорошее документирование отображаемых процессов обработки информации Недостатки возникают проблемы в объединении разных функциональных подсистем,
Объектные ТПР - типовые отраслевые проекты, которые включают полный набор функциональных и обеспечивающих подсистем ИС. Отраслевые проекты
Достоинства объединение всех компонентов ИС за счет методологического единства и информационной, программной и технической совместимости, открытость архитектуры — позволяет устанавливать ТПР на разных программно-технических платформах, масштабируемость — допускает конфигурацию ИС для переменного числа рабочих мест, конфигурируемость — позволяет выбирать необходимое подмножество компонентов
Недостатки проблемы привязки типового проекта к конкретному объекту управления, что вызывает в некоторых случаях даже необходимость изменения организационно-экономической структуры объекта автоматизации
Каждое типовое решение предполагает наличие, кроме собственно функциональных элементов (программных или аппаратных), документации с детальным описанием ТПР и процедур настройки в соответствии с требованиями разрабатываемой системы.
Для реализации типового проектирования используются два подхода:
параметрически-ориентированное проектирование
модельно-ориентированное проектирование.
Параметрически-ориентированное проектирование включает следующие этапы:
определение критериев оценки пригодности пакетов прикладных программ (ППП) для решения поставленных задач,
анализ и оценка доступных ППП по сформулированным критериям,
выбор и закупка наиболее подходящего пакета,
настройка параметров (доработка) закупленного ППП.
Критерии оценки ППП делятся на следующие группы:
назначение и возможности пакета;
отличительные признаки и свойства пакета;
требования к техническим и программным средствам;
документация пакета;
факторы финансового порядка;
особенности установки пакета;
особенности эксплуатации пакета;
помощь поставщика по внедрению и поддержанию пакета;
оценка качества пакета и опыт его использования;
перспективы развития пакета.
Внутри каждой группы критериев выделяется некоторое подмножество частных показателей, детализирующих каждый из десяти критериев. Числовые значения показателей для конкретных ППП устанавливаются экспертами по выбранной шкале оценок (например, 10-балльной). На их основе формируются групповые оценки и комплексная оценка пакета (путем вычисления средневзвешенных значений). Нормированные взвешивающие коэффициенты также получаются экспертным путем.
Модельно-ориентированное проектирование заключается в адаптации состава и характеристик типовой ИС в соответствии с моделью объекта автоматизации.
Технология проектирования в этом случае должна обеспечивать единые средства для работы как с моделью типовой ИС, так и с моделью конкретного предприятия.
Типовая ИС имеет специальную базу метаинформации – репозитории. Она содержит модель объекта автоматизации, на основе которой осуществляется конфигурирование программного обеспечения. Таким образом, модельно-ориентированное проектирование ИС предполагает, прежде всего, построение модели объекта автоматизации с использованием специального программного инструментария (например, SAP Business Engineering Workbench (BEW), BAAN Enterprise Modeler).
Возможно также создание системы на базе типовой модели ИС из репозитория, который поставляется вместе с программным продуктом и расширяется по мере накопления опыта проектирования информационных систем для различных отраслей и типов производства.
Репозиторий содержит базовую (ссылочную) модель ИС, типовые (референтные) модели определенных классов ИС, модели конкретных ИС предприятий.
Базовая модель ИС в репозитории содержит описание бизнес-функций, бизнес-процессов, бизнес-объектов, бизнес-правил, организационной структуры, которые поддерживаются программными модулями типовой ИС.
Типовые модели описывают конфигурации информационной системы для определенных отраслей или типов производства.
Построенная модель предприятия в виде метаописания хранится в репозитории и при необходимости может быть откорректирована. На основе этой модели автоматически осуществляется конфигурирование и настройка информационной системы.
Внедрение типовой информационной системы начинается с анализа требований к конкретной ИС, которые выявляются на основе результатов предпроектного обследования объекта автоматизации.
Для оценки соответствия этим требованиям программных продуктов может использоваться описанная выше методика оценки ППП.
После выбора программного продукта на базе имеющихся в нем референтных моделей строится предварительная модель ИС, в которой отражаются все особенности реализации ИС для конкретного предприятия.
Предварительная модель является основой для выбора типовой модели системы и определения перечня компонентов, которые будут реализованы с использованием других программных средств или потребуют разработки с помощью имеющихся в составе типовой ИС инструментальных средств.
Реализация типового проекта предусматривает выполнение следующих операций:
установку глобальных параметров системы;
задание структуры объекта автоматизации;
определение структуры основных данных;
задание перечня реализуемых функций и процессов;
описание интерфейсов;
описание отчетов;
настройку авторизации доступа;
настройку системы архивирования.
Технология RUP (принципы, схема, фазы, дисциплины, применимость)
Одна из наиболее совершенных технологий, претендующих на роль мирового корпоративного стандарта — Rational Unified Process. RUP представляет собой программный продукт, разработанный компанией Rational Software, которая в настоящее время входит в состав IBM.
Ее основными принципами являются:
1. Итерационный и инкрементный (наращиваемый) подход к созданию ПО.
2. Планирование и управление проектом на основе функциональных требований к системе — вариантов использования.
3. Построение системы на базе архитектуры ПО.
Разработка системы выполняется в виде нескольких краткосрочных мини-проектов фиксированной длительности (от 2 до 6 недель), называемых итерациями. Каждая итерация включает свои собственные этапы анализа требований, проектирования, реализации, тестирования, интеграции и завершается созданием работающей системы.
Итерационный цикл основывается на постоянном расширении и дополнении системы в процессе нескольких итераций с периодической обратной связью и адаптацией добавляемых модулей к существующему ядру системы. Система постоянно разрастается шаг за шагом, поэтому такой подход называют итерационным и инкрементным.
При таком подходе исключено и слишком быстрое написание кода (без детальной проработки) и чрезмерно длительный этап детального проектирования и построения моделей без обратной связи.
На слайде показано общее представление RUP в двух измерениях:
• горизонтальное измерение представляет время, отражает динамические аспекты процессов и оперирует такими понятиями, как стадии, итерации и контрольные точки;
• вертикальное измерение отражает статические аспекты процессов и оперирует такими понятиями, как виды деятельности (технологические операции), рабочие продукты, исполнители и дисциплины (технологические процессы).
Согласно технологии RUP ЖЦ ПО разбивается на отдельные циклы, в каждом из которых создается новое поколение продукта.Каждый цикл, в свою очередь, разбивается на четыре последовательные стадии:
• начальная стадия (inception);
• стадия разработки (elaboration);
• стадия конструирования (construction);
• стадия ввода в действие (transition).
Каждая стадия завершается в четко определенной контрольной точке (milestone). В этот момент времени должны достигаться важные результаты и приниматься критически важные решения о дальнейшей разработке.
Начальная стадия Inception
Определяются:
основные цели проекта,
бюджет проекта,
основные средства выполнения проекта — технологии, инструменты, ключевой персонал,
предварительные планы проекта.
Цель фазы — достичь компромисса между всеми заинтересованными лицами относительно задач проекта
Результаты начальной стадии
• общее описание системы: основные требования к проекту, его характеристики и ограничения;
• начальная модель вариантов использования (степень готовности – 10_20%);
• начальный проектный глоссарий (словарь терминов);
• начальный бизнес_план;
• один или несколько прототипов.
Стадия разработки (проработки) Elaboration
Выявляются детальные требования к системе,
Выполняется высокоуровневый анализ предметной области
Выполняется проектирование для построения базовой архитектуры системы,
Создается план конструирования
Устраняются наиболее рискованные элементы проекта.
Результаты стадии разработки
• модель вариантов использования (завершенная по крайней мере на 80%)
• перечень дополнительных требований
• описание базовой архитектуры системы;
• работающий прототип;
• уточненный бизнес_план;
• план разработки всего проекта
Признаки завершения стадии разработки
разработчики в состоянии оценить с достаточно высокой точностью, сколько времени потребуется на реализацию каждого варианта использования;
идентифицированы все наиболее серьезные риски, и степень понимания наиболее важных из них такова, что известно, как справиться с ними.
Стадия конструирования (построения) Construction
Цель — детальное прояснение требований и разработка системы, удовлетворяющей им, на основе спроектированной ранее архитектуры.
Результаты стадии конструирования
• ПО, интегрированное на требуемых платформах;
• руководства пользователя;
• описание текущей реализации.
Стадия ввода в действие Transition
Цель - передача готового продукта в распоряжение пользователей
тестирование,
параллельное функционирование
конвертирование баз данных;
оптимизация производительности;
обучение пользователей и специалистов службы сопровождения.
Основные элементы технологии RUP
роль (role) - определяет поведение и ответственность лица или группы лиц, составляющих проектную команду
виды деятельности (activity) – единица выполняемой исполнителем работы – технологическая операция
артифакт (artifact) - рабочий продукт - информационная или материальная сущность, которая создается, модифицируется или используется в некоторой технологической операции: модель, элемент модели, документ, исходный код, план и пр.
руководства (guidelines) - методики выполнения технологических операций
дисциплина (discipline) - последовательность действий, приводящую к получению значимого результата
Case-средства; классификация Case-средств (по уровню применения, специализированные, вспомогательные, интегрированные).
Для автоматизации процессов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации используются CASE-средства - Computer Aided System Engineering - инструментальные средства проектирования ИС.
CASE средства могут быть классифицированы по нескольким признакам:
По уровню применения:
- Upper CASE -средства анализа требований
- Middle CASE - средства проектирования
- Low CASE - средства разработки приложений
Специализированные
- Средства проектирования баз данных
- Средства реинжиниринга (восстановления) модели (формирование ERD на основе анализа схем БД или формирования диаграмм на основе анализа программных кодов)
Вспомогательные
- Планирования и управления проектом
- Конфигурационного управления
- Тестирования
Интегрированные CASE охватывают все этапы и процессы создания ПО от анализа требований до тестирования и выпуска документации. Интегрированные CASE выступают, как правило, в виде набора согласованных по интерфейсу средств, предназначенных для поддержки отдельных этапов процесса.
В настоящее время существует очень много CASE средств и фирм, специализирующихся на их разработке.
При выборе CASE средств следует руководствоваться основным принципом: сначала метод создания ПО, а потом – CASE средства, применимые для этого метода. Выбор наоборот чреват нехорошими последствиями.
CASE-средства. Общая характеристика
Современные CASE-средства поддерживают все этапы технологий проектирования ИС: от простых средств анализа и документирования до полномасштабных средств автоматизации, покрывающих весь жизненный цикл ПО.
CASE-средства это относительно дешевые системы для персональных компьютеров с весьма ограниченными возможностями и дорогостоящие системы для неоднородных вычислительных платформ и операционных сред. Так, современный рынок программных средств насчитывает около 300 различных CASE-средств, наиболее мощные из которых так или иначе используются практически всеми ведущими западными фирмами.
Обычно к CASE-средствам относят любое программное средство, автоматизирующее ту или иную совокупность процессов жизненного цикла ПО и обладающее следующими основными характерными особенностями:
мощные графические средства для описания и документирования ИС,
интеграция отдельных компонент CASE-средств, обеспечивающая управляемость процессом разработки ИС;
использование специальным образом организованного хранилища проектных метаданных (репозитория).
Интегрированное CASE-средство (или комплекс средств, поддерживающих полный ЖЦ ПО) содержит следующие компоненты;
репозиторий - обеспечивает хранение версий проекта и его отдельных компонентов, синхронизацию поступления информации от различных разработчиков при групповой разработке, контроль метаданных на полноту и непротиворечивость;
графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (DFD, ERD и др.), образующих модели ИС;
средства разработки приложений, включая языки программирования и генераторы кодов;
средства документирования;
средства тестирования;
средства управления проектом;
средства реинжиниринга.
Потребности организации в CASE-средствах должны соразмеряться с реальной ситуацией на рынке или собственными возможностями разработки. Для анализируемых case-средств необходимо выяснить возможность интеграции с другими средствами, используемыми организацией.
Критерии выбора и оценки Case-средств принимать различные формы. Но все средства должны удовлетворять функциональным требованиям, быть надежными, простыми в использовании, эффективными, быть сопровождаемыми разработчиками, совместимыми с другим ПО.
На сегодняшний день Российский рынок программного обеспечения располагает следующими наиболее развитыми CASE-средствами:
Silverrun американской фирмы Сomputer Systems Advisers, Inc. (CSA)
Uniface 7 - продукт фирмы Compuware (США) ".
Designer 2.0 фирмы ORACLE.
Локальные средства (ERwin, BPwin, S-Designor, CASE.Аналитик)
ERwin - средство концептуального моделирования БД, использующее методологию IDEF1X.
BPwin - средство функционального моделирования, реализующее методологию IDEF0, IDEF3, DFD.
CASE.Аналитик является практически единственным в настоящее время конкурентоспособным отечественным CASE-средством функционального моделирования и реализует построение диаграмм потоков данных
Объектно-ориентированные CASE-средства (Rational Rose)
Rational Rose - CASE-средство фирмы Rational Software Corporation (США) - предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках программированияи выпуска проектной документации.
Rational Rose использует метод объектно-ориентированного анализа и проектирования, основанный на подходах трех ведущих специалистов в данной области: Буча, Рамбо и Якобсона. Разработанная ими универсальная нотация для моделирования объектов (UML - Unified Modeling Language) претендует на роль стандарта в области объектно-ориентированного анализа и проектирования.
Rational Rose реализует генерацию кодов программ для C++, Visual C++, Visual Basic, Java, Delphi, генерацию физических баз данных, а также позволяет разрабатывать проектную документацию в виде диаграмм и спецификаций. Кроме того, Rational Rose содержит средства реверсного инжиниринга программ и баз данных, обеспечивающие повторное использование программных компонентов в новых проектах.
В основе работы Rational Rose лежит построение различного рода диаграмм и спецификаций, определяющих логическую и физическую структуры модели, ее статические и динамические аспекты. В их число входят диаграммы классов, состояний, сценариев, модулей, процессов.
В составе Rational Rose можно выделить 6 основных структурных компонент:
Репозиторий представляет собой объектно-ориентированную базу данных.
Графический интерфейс пользователя
Средства просмотра обеспечивают "навигацию" по проекту, в том числе, перемещение по иерархиям классов и подсистем, переключение от одного вида диаграмм к другому и т. д.
Средства контроля и сбора статистики дают возможность находить и устранять ошибки по мере развития проекта, а не после завершения его описания.
Генератор отчетов формирует тексты выходных документов на основе содержащейся в репозитории информации.
Средства автоматической генерации кодов программ, используя информацию, содержащуюся в логической и физической моделях проекта, формируют файлы описаний классов и объектов. Создаваемый таким образом скелет программы может быть уточнен путем прямого программирования на языке. Тексты программ являются заготовками для последующей работы программистов. В дальнейшем эти исходные тексты развиваются программистами в полноценные программы.
Rational Rose интегрируется со средством PVCS для организации групповой работы и управления проектом и со средством SoDA - для документирования проектов.
Общие сведения о языке визуального моделирования UML
Существует множество технологий и инструментальных средств, с помощью которых можно реализовать в некотором смысле оптимальный проект ИС, начиная с этапа анализа и заканчивая созданием программного кода системы.
Эти технологии представлены CASE-средствами. CASE - Computer Aided System Engineering. Мощный толчок к разработке этого направления информационных технологий дало распространение объектно-ориентированных языков программирования в конце 1980-х — начале 1990-х годов. Необходим был единый язык, который объединял бы сильные стороны ОО методов и обеспечивал наилучшую поддержку моделирования.
Таким языком оказался Унифицированный язык объектно-ориентированного моделирования Unified Modeling Language (UML). Существует достаточное количество инструментальных средств, поддерживающих с помощью UML жизненный цикл информационных систем, и, одновременно, UML является достаточно гибким для настройки и поддержки специфики деятельности различных команд разработчиков.
UML был создан для ООАП, которые появились в конце 80-х и начале 90-х гг. Создание UML фактически началось в конце 1994 г. До этого времени американский инженер, руководитель исследований в IBM ResearchГради Буч самостоятельно пытался реализовать собственный метод ООМоделирования - Booch.
Данный метод был изложен в книге «Объектно-ориентированный анализ и проектирование». Также Буч был автором одной из самых популярных в то время книг о программировании на языке Ada. С середины 1990-х Гради Буч занимал должность руководителя исследований компании Rational Software, где работал до 18 марта 2008 года. В настоящий момент Буч руководит исследованиями и проектами IBM Research.
В это же время Джеймс Рамбо разрабатывал собственный метод ОМТ (Object Modeling Technique). OMT был ориентирован на анализ, а метод Буча — на проектирование программных систем. Вскоре Буч и Рамбо начали работу по объединению методов Booch и ОМТ под эгидой компании Rational Software.
К концу 1995 г. они создали первую спецификацию объединенного метода, названного ими Unified Method, версия 0.8.
Осенью 1995 года к ним присоединился Ивар Якобсон (Айвар Джекобсон), автор метода Object-Oriented Software Engineering — OOSE, обеспечивавшего возможности для спецификации бизнес-процессов и анализа требований при помощи сценариев использования.
Таким образом, UML является прямым объединением и унификацией методов Буча, Рамбо и Якобсона, однако дополняет их новыми возможностям
В настоящее время принят в качестве стандартного языка моделирования и получил широкую поддержку в индустрии создания ПО. UML принят на вооружение почти всеми крупнейшими компаниями~ производителями ПО (Microsoft, IBM, Hewlett-Packard, Oracle, Sybase и др.). Кроме того, почти все мировые производители CASE-средств поддерживают UML в своих продуктах
Полное описание UML можно найти на сайтах http://www.omg.org и http://www.rational.com.
Существует консорциум пользователей UML Partners включает в себя представителей таких грандов информационных технологий, как Rational Software, Microsoft, IBM, Hewlett-Packard, Oracle, DEC, Unisys, IntelliCorp, Platinum Technology.
UML представляет собой объектно-ориентированный язык визуального моделирования, который обеспечивает разработку репрезентативных моделей для организации взаимодействия заказчика и разработчика ИС, различных групп разработчиков ИС.
Объектная модель является наиболее естественным способом представления реального мира.
Основные цели, которые преследовались при разработке UML следующие:
Предоставить пользователям готовый к использованию выразительный язык визуального моделирования, позволяющий им разрабатывать понятные им модели и возможность обмениваться ими для разных групп разработчиков (проектировщиков).
Обеспечить независимость от конкретных языков программирования и процессов разработки
Предусмотреть механизмы для расширения базовых концепций (ядра UML);
Обеспечить формальную основу для понимания языка. Язык должен быть одновременно точным и доступным для понимания, без лишнего формализма.
Словарь UML включает три вида основных конструкций (строительных блоков):
Сущности (предметы) – реальный или воображаемый объект (абстракции), имеющий существенное значение для рассматриваемой предметной области;
Отношения связывают сущности;
Диаграммы группируют представляющие интерес множества сущностей и отношений. Диаграммы позволяют описать поведение системы (для анализа) или показать детали архитектуры (для проектирования).
Сущности в UML.
Сущности (предметы) – реальный или воображаемый объект (абстракции), имеющий существенное значение для рассматриваемой предметной области;
Объект – осязаемая сущность – предмет или явление (процесс), имеющие четко определяемое поведение. Объект представляет собой абстракцию некоторой сущности предметной области (объект реального мира) или программной системы (архитектурный объект). Любой объект обладает состоянием (State), поведением (behavior) и индивидуальностью (identity).
На языке UML существует следующее представление:
-
только имя объекта
Класс (class) - это множество объектов, связанных общими свойствами (атрибутами), поведением (операциями), связями и семантикой (смысл). Структура и поведение схожих объектов определяют общий для них класс. Термин экземпляр класса и объект являются эквивалентными.
Актер (actor) – роль, которую играют пользователи системы во время взаимодействия с ней. Актерами могут быть как люди, так и другие автоматизированные системы.
Прецедент (вариант использования) (use case) - это описание последовательности выполняемых системой действий, которая производит наблюдаемый результат, значимый для какого-то определенного актера.
В модели элемент Use Case применяется для структурирования предметов поведения. Элемент Use Case реализуется кооперацией.
Компонент (component) - это относительно независимая физическая заменяемая часть программного обеспечения системы,.
Узел (node) – физический элемент реальной системы, который существует во время функционирования программного продукта и представляет собой некоторый вычислительный ресурс. обычно имеющий память и возможности обработки. В узле размещается набор компонентов, который может перемещаться от узла к узлу.
Взаимодействие (interaction) - это поведение, суть которого заключается в обмене сообщениями (messages) между объектами в рамках конкретного контекста для достижения определенной цели.
Взаимодействие может определять динамику как совокупности объектов, так и отдельной операции. Элементами взаимодействия являются сообщения, последовательность действий (поведение, вызываемое сообщением) и связи (соединения между объектами).
Автомат (state machine) - поведение, определяющее последовательность состояний объекта, через которые объект проходит на протяжении своего жизненного цикла в ответ на различные события, а также реакции на эти события.
С помощью конечного автомата может определяться поведение индивидуального класса или кооперации классов. Элементами конечного автомата являются состояния, переходы (от состояния к состоянию), события (предметы, вызывающие переходы) и действия (реакции на переход).
Пакеты (packages) представляют собой универсальный механизм распределения элементов в группы. В пакет могут помещаться структурные предметы, предметы поведения и даже другие группировки предметов. В отличие от компонента (который существует в период выполнения), пакет — чисто концептуальное понятие. Это означает, что пакет существует только в период разработки.
Диаграмма Вариантов использования в UML: назначение, принципы построения
Разработку спецификаций программного обеспечения начинают с анализа требований к функциональности, указанных в техническом задании. В процессе анализа выявляют внешних пользователей разрабатываемого программного обеспечения и перечень отдельных аспектов его поведения в процессе взаимодействия с конкретными пользователями.
Идея описать функциональные требования в виде вариантов использования была сформулирована в 1986 году Иваром Якобсоном. Эта идея была признана конструктивной и получила широкое одобрение. Впоследствии наиболее значительный вклад в решение проблемы определения сущности вариантов использования и способов их описания внес Алистер Коберн.
Диаграмма отражает динамические аспекты поведения системы. Диаграммы использования описывают функциональность ИС, которая будет видна пользователям системы. Каждая функциональность изображается в виде прецедентов (вариантов использования (use case).
Вариант использования (use case). представляет собой последовательность действий (транзакций), выполняемых системой в ответ на событие, инициируемое некоторым внешним объектом (действующим лицом). Вариант использования:
описывает типичное взаимодействие между пользователем и системой
отражает представление о поведении системы с точки зрения пользователя.
В простейшем случае вариант использования определяется в процессе обсуждения с пользователем тех функций, которые он хотел бы реализовать, или целей, которые он преследует по отношению к разрабатываемой системе.
Не следует путать вариант использования с конкретными операциями будущей системы. Каждый вариант использования связан с некоторой целью, имеющей самостоятельное значение, например для текстового редактора Формирование оглавления - это вариант использования, а Связывание заголовков со специальными стилями - операция, которую необходимо выполнить, чтобы стало возможно автоматическое построение оглавления.
Обозначается на диаграмме овалом, связанным с пользователями, которых принято называть действующими лицами (актеры, actors).
Таким образом, вариант использования — это типичное взаимодействие пользователя с системой, которое:
описывает видимую пользователем функцию,
может представлять различные уровни детализации,
обеспечивает достижение конкретной цели, важной для пользователя.
Действующее лицо (actor) — это роль, которую пользователь играет по отношению к системе. Действующие лица представляют собой роли, а не конкретных людей или наименования работ. На диаграмме изображается только одно действующее лицо, однако реальных пользователей, выступающих в данной роли по отношению к ИС, может быть много.
Несмотря на то, что на диаграммах вариантов использования они изображаются в виде стилизованных человеческих фигурок, действующее лицо может также быть внешней системой, которой необходима некоторая информация отданной системы.
Действующие лица делятся на 4 основных типа — пользователи системы, другие системы, взаимодействующие с данной, какие-либо технические средства, взаимодействующие с разрабатываемым программным обеспечением, и время. Время становится действующим лицом, если от него зависит запуск каких-либо событий в системе.
Список всех прецедентов фактически определяет функциональные требования к ИС, которые лежат в основе разработки технического задания на создание системы.
Для наглядного представления вариантов использования применяются диаграммы вариантов использования (диаграммы прецедентов). Она отражает функциональные требования к системе с точки зрения пользователя, какие действующие лица инициируют ВИ.
Таким образом, варианты использования — это функции, выполняемые системой, а действующие лица — это заинтересованные лица (stakeholders) по отношению к создаваемой системе. Такие диаграммы показывают, какие действующие лица инициируют варианты использования. Направленная от варианта использования к действующему лицу стрелка показывает, что вариант использования предоставляет некоторую информацию, используемую действующим лицом.
Действующие лица могут играть различные роли по отношению к варианту использования. Они могут пользоваться его результатами, инициировать действие, сами непосредственно в нем участвовать. Значимость различных ролей действующего лица зависит от того, каким образом используются его связи.
Цель построения диаграмм ВИ – документирование функциональных требований к системе в самом общем виде, поэтому они должны быть предельно простыми.
Правила построения ДВИ
Не моделировать связи между актерами. По определению действующие лица находятся вне сферы действия системы. Это означает, что связи между ними также не относятся к ее компетенции.
Не соединяйте стрелкой два варианта использования непосредственно. Диаграммы данного типа описывают только сами варианты использования, а не порядок их выполнения. Для отображения порядка выполнения вариантов использования применяют диаграммы деятельности и сценарии вариантов использования.
Каждый ВИ должен быть инициирован актером. Т.е. всегда должна быть стрелка, начинающаяся на актере и заканчивающаяся на ВИ (исключение – те случаи, когда происходит передача управления другой системе или используется тип связи - расширение).
Как определить варианты использования:
Хорошим источником для идентификации вариантов использования служат внешние события. Следует начать с перечисления всех событий, происходящих во внешнем мире, на которые система должна каким-то образом реагировать. Какое-либо конкретное событие может повлечь за собой реакцию системы, не требующую вмешательства пользователей, или, наоборот, вызвать чисто пользовательскую реакцию. Идентификация событий, на которые необходимо реагировать, помогает идентифицировать варианты использования.
Различные разработчики подходят к описанию вариантов использования с разной степенью детализации. Например, Ивар Якобсон утверждал, что для проекта с трудоемкостью 10 человеко-лет количество вариантов использования может составлять около 20 (не считая связей «включения» и «расширения»). Следует предпочитать небольшие и детализированные варианты использования, поскольку они облегчают составление и реализацию согласованного плана проекта.
Достоинства модели вариантов использования:
1. определяет пользователей и границы системы
2. определяет системный интерфейс
3. удобна в общении пользователя и разработчика
4. используется для написания тестов
5. является основой для написания пользовательской документации
6. хорошо вписывается в любые методы проектирования.
Диаграмма Классов в UML: назначение, принципы построения.
Диаграммы классов - центральное звено объектно-ориентированных методов разработки программного обеспечения, поэтому все существующие методы используют диаграммы классов в одной из известных нотаций. Однако в основном диаграммы классов в этих методах применяют на этапе проектирования, для того чтобы показать особенности построения конкретных классов.
На диаграммах класс изображается в виде прямоугольника, внутри которого указано имя класса, атрибуты классов, операции классов и ограничения, которые накладываются на связи между классами. Линии между классами отображают отношения (или ассоциации) между ними. Сообщения обозначаются ярлыками возле стрелок, они могут иметь нумерацию и показывать возвращаемые значения.
Между классами возможны различные отношения.
Изначально, на этапе анализа программного обеспечения между классами устанавливаются ассоциации и обобщения.
Отношение ассоциации означает наличие связи между экземплярами классов или объектами, Когда класс участвует в ассоциации, он играет в этом отношении определенную роль. Роль определяет, каким представляется класс на одном конце ассоциации для класса на противоположном конце ассоциации.
Обобщение (Generalization), это отношение между общей сущностью (родителем — класс "клиент") и ее конкретным воплощением (потомком — классы "корпоративный клиент" или "частный клиент"). Объекты класса-потомка могут использоваться всюду, где встречаются объекты класса-родителя, но не наоборот. При этом он наследует свойства родителя (его атрибуты и операции). Операция потомка с той же сигнатурой, что и у родителя, замещает операцию родителя.
На этапе анализа достаточно указать ассоциации и обобщение классов. На этапе проектирования необходимо уточнить отношений между ними. Па этапе проектирования помимо ассоциации и обобщения различают еще два типа отношения между классами: агрегацию и композицию.
К сожалению, до настоящего времени не существует единой устоявшейся терминологии объектно-ориентированного проектирования. Агрегацией называют ассоциацию между целым и его частью или частями. Агрегацию вместо ассоциации указывают, если отношение «целое-часть» в конкретном случае существенно.
Например, если колесо нас интересует только как часть автомобиля, то между соответствующими классами целесообразно указать отношение агрегации, а если колесо - товар, также как и автомобиль, то связь целое-часть не существенна.
Композиция - более сильная разновидность агрегации, которая подразумевает, что объект-часть может принадлежать только единственному целому. Объект-часть при этом создается и уничтожается только вместе со своим целым.
Уточненные отношения между классами фиксируют на диаграмме классов. Для этого используют специальные уловные обозначения. Поскольку отношение ассоциации и его подвиды (агрегация и композиция) означают наличие обмена сообщениями между объектами классов целесообразно уточнить направление передачи сообщений. Навигацию (направление ассоциации) показывают стрелкой на конце линии ассоциации. Если стрелки указаны с обеих сторон, то это означает двунаправленную ассоциацию.
Диаграмма Последовательности в UML: назначение, принципы построения.
Диаграммы последовательностей отображают взаимодействие объектов, упорядоченное по времени. На ней показывают внутренние объекты, а также последовательность сообщений, которыми обмениваются объекты в процессе реализации фрагмента варианта использования, называемого сценарием.
Этот вид диаграмм используется для точного определения логики сценария выполнения ВИ. Диаграммы последовательностей отображают объекты, взаимодействующих при исполнении прецедентов. Они отображаются в верхней части диаграммы в виде прямоугольников на вершине пунктирной вертикальной линии. Эта вертикальная линия называется линией жизни (lifeline) объекта. Она представляет собой фрагмент жизненного цикла объекта в процессе взаимодействия.
Объекты изображают в виде прямоугольников, внутри которого указана информация, идентифицирующая объект: имя, имя объекта и имя класса или только имя класса.
Каждое сообщение представляют в виде линии со стрелкой, соединяющей линии жизни двух объектов. Эти линии помещают на диаграмму в порядке генерации сообщений (сверху вниз и слева направо). Стрелки с надписями названий методов означают вызов метода у объекта. Сообщения появляются в том порядке, как они показаны на диаграмме сверху-вниз. Если предусматривается отправка сообщения объектом самому себе (самоделегирование), то стрелка начинается и заканчивается на одной "линии жизни".
Не все объекты, показанные на диаграмме, явно присутствуют в потоке событий. Там, например, может не быть форм для заполнения, но их необходимо показать на диаграмме, чтобы позволить действующему лицу ввести новую информацию в систему или просмотреть ее. В потоке событий, скорее всего, также не будет и управляющих объектов (control objects). Эти объекты управляют последовательностью событий в варианте использования.
На диаграммы может быть добавлена управляющая информация: описание условий, при которых посылается сообщение; признак многократной отправки сообщения (маркер итерации); признак возврата сообщения.
Диаграмма Состояний в UML: назначение, принципы построения.
Диаграммы состояний используются для описания поведения сложных систем. Они определяют все возможные состояния, в которых может находиться объект, а также процесс смены состояний объекта в результате некоторых событий. Эти диаграммы обычно используются для описания поведения одного объекта в нескольких прецедентах.
Диаграмма состояний показывает:
1) набор состояний объекта;
2) события, которые вызывают переход из одного состояния в другое;
3) действия, которые происходят в результате изменения состояния.
Существует много форм диаграмм состояний, незначительно отличающихся друг от друга семантикой.
Состояние изображается как закругленный прямоугольник, обычно включающий его имя и подсостояния (если они есть). Состояниям соответствуют определенные значения атрибутов объектов. Имеется также два вида псевдо-состояний: начальное состояние, в котором находится только что созданный объект, и конечное состояние, которое объект не покидает, как только туда перешел.
Между состояниями возможны различные типы переходов. Обычно переход инициируется событием. Допускаются переходы и без событий. Наконец, разрешены условные или охраняемые переходы.
В общем случае переходы имеют метки, которые синтаксически состоят из трех необязательных частей
<Событие> <[Условие]> < / Действие>.
Стрелки представляют переходы от одного состояния к другому, которые вызываются выполнением некоторых функций объекта.
На
рисунке обозначено:
Событие — происшествие, вызывающее изменение состояния,
Действие — набор операций, запускаемых событием.
Иначе говоря, события вызывают переходы, а действия являются реакциями на переходы.
Порядок выполнения условного перехода:
1) происходит событие;
2) вычисляется условие УсловиеПерехода;
3) при УсловиеПерехода=true запускается переход и активизируется действие, в противном случае переход не выполняется.
На диаграммах также отображаются функции, которые выполняются объектом в определенном состоянии (действия в состоянии). Синтаксис метки деятельности: выполнить/< деятельность >.
Для указания действий, выполняемых при входе в состояние и при выходе из состояния, используются метки entry и exit соответственно. Например, при входе в состояние Активна выполняется операция УстановитьТревогу() из класса Контроллер, а при выходе из состояния — операция СбросТревоги().
Действие, которое должно выполняться, когда система находится в данном состоянии, указывается после метки do. Считается, что такое действие начинается при входе в состояние и заканчивается при выходе из него. Например, в состоянии Активна это действие ПодтверждатьТревогу().
На слайде приведен пример диаграммы состояний для банковского счета. Из данной диаграмме видно, в каких состояниях может существовать счет. Можно также видеть процесс перехода счета из одного состояния в другое. Например, если клиент требует закрыть открытый счет, он переходит в состояние «закрыт».
Требование клиента называется событием (event), именно такие события и вызывают переход из одного состояния в другое. Если клиент снимает деньги с открытого счета, он может перейти в состояние «Превышение кредита». Это происходит, только если баланс по этому счету меньше нуля, что отражено условием [отрицательный баланс] на диаграмме. Заключенное в квадратных скобках ограничивающее условие (guard condition) определяет, когда может или не может произойти переход из одного состояния в другое.
На диаграмме имеются два специальных состояния — начальное (start) и конечное (stop). Начальное состояние выделено черной точкой, оно соответствует состоянию объекта, когда он только что был создан. Конечное состояние обозначается черной точкой в белом кружке, оно соответствует состоянию объекта непосредственно перед его уничтожением.
На диаграмме состояний может быть только одно начальное состояние, а конечных состояний может быть столько, сколько нужно, или их может не быть вообще. Когда объект находится в каком-то конкретном состоянии, могут выполняться различные процессы.
При превышении кредита клиенту посылается соответствующее сообщение. Процессы, происходящие, когда объект находится в определенном состоянии, называются действиями (actions). С состоянием можно связывать данные пяти типов: деятельность, входное действие, выходное действие, событие и история состояния.
Диаграммы состояний не надо создавать для каждого класса, они применяются только в сложных случаях. Если объект класса может существовать в нескольких состояниях и в каждом из них ведет себя по-разному, для него может потребоваться такая диаграмма.
Порядок и цель проведения объектно-ориентированного анализа
Объектно-ориентированный анализ включает:
Точное формулирование требований к системе;
Проектирование диаграммы вариантов использования
Формирование представления об интерфейсе пользователя;
Выполняется спецификация вариантов использования (создание потоков событий и сценариев ВИ)
Выполняется анализ вариантов использования (создание классов уровня предварительного проектирования, участвующих в вариантах использования)
Проектирование модели предметной области уровня анализа.
1 Шаг - Точное формулирование требований к системе
В начале пути у нас есть лишь один главный вопрос: «Что должна делать система?».
Необходимо четко, лаконично и формально описать требования к системе. Например, система должна:
Формировать справочник…
Вводить информацию о …..
Осуществлять поиск ….
Рекомендуется сначала проанализировать те данные, которые будут храниться в вашей системе постоянно (условно-постоянно). Обычно такими данными являются справочники. Затем необходимо сформировать требования, предъявляемые к хранению и обработке заново возникающей информации или часто изменяющейся (документы).
Затем следует описать обработки данных в системе, осуществление поиска, различных расчетов и пр. Затем следует анализировать формирование отчетов системы. В некоторых случаях возникают и другие действия: авторизация пользователя и пр. Требования к таким возможностям системы тоже необходимо формулировать.
Сформулированные требования в дальнейшем будут основой для создания диаграммы вариантов использования.
2 Шаг - Проектирование диаграммы вариантов использования
Создается диаграмма вариантов использования на основе сформулированных требований.
Цель построения диаграмм ВИ – документирование функциональных требований к системе в самом общем виде, поэтому они должны быть предельно простыми.
Поиск актеров — большая работа. Актером может быть как пользователь, так и другая система и время.
Каждый элемент Use Case задает некоторый путь использования системы, выполнение некоторой части функциональных возможностей. Полная совокупность элементов Use Case определяет все существующие пути использования системы.
Рассматривая каждого актера, мы решаем, какие элементы Use Case он может выполнять. Для этого изучается описание системы (с точки зрения актера) или проводится обсуждение с теми, кто будет действовать как актер.
Чаще всего полные описания элементов Use Case формируются за несколько итераций. На каждом шаге в описание вводятся дополнительные детали.
Не всегда очевидно, как распределить функциональные возможности по отдельным элементам Use Case и что является вариантом одного и того же элемента Use Case. Основной критерий выбора — сложность элемента Use Case. При анализе вариантов поведения рассматривают их различия. Если различия малы, варианты встраивают в один элемент Use Case. Если различия велики, то варианты описываются как отдельные элементы Use Case. ПРИМЕР
Элемент Use Case описывает, что должна делать система, но не определяет, как она должна это делать. При моделировании это позволяет отделять внешнее представление системы от ее внутреннего представления.
Правила построения ДВИ
Не моделировать связи между актерами
Не соединять непосредственно два ВИ
Каждый ВИ должен быть инициировать актером. Т.е. всегда должна быть стрелка, начинающаяся на актере и заканчивающаяся на ВИ (исключение – те случаи, когда происходит передача управления другой системе или используется тип связи - расширение).
3 Шаг - Формирование представления об интерфейсе пользователя;
Предварительное представление об интерфейсе системы включает в себя создание прототипа диалоговых окон.