RUP. Моделирование при проектировании ПО и ИС.
Цель и задачи анализа и проектирования
Цель процесса анализа и проектирования состоит в разработке технических инструкций, предписывающих, как реализовать ПС, удовлетворяющую сформулированным требованиям. Для этого следует хорошо понять требования к ПС и преобразовать их в проект системы, выбрав правильную стратегию реализации. На ранних стадиях процесса должна быть создана устойчивая архитектура, на основе которой можно спроектировать ПС, легкую для понимания, построения и развертывания. Архитектура должна быть согласована со средой реализации с целью удовлетворения требований к производительности, устойчивости, безопасности, расширяемости и тестируемости.
К числу решаемых задач при этом относятся:
разработка точной архитектуры распределенной программной системы;
преобразование модели требований в модель проектную разрабатываемой системы;
адаптация проекта системы к среде реализации с целью повышения производительности разработки;
выбор механизмов реализации и определение ограничений на реализацию;
разработка компонентной структуры;
распределение компонентов по узлам.
Главной задачей анализа является преобразование требований в форму, понятную разработчику, то есть, определение подсистем, компонентов и классов, с помощью которых реализуется требуемое поведение ПС. В основе такого преобразования лежат ВИ, созданные при определении требований к ПС. При этом рассматриваются только функциональные требования и игнорируются нефункциональные.
|
|
|
Проектирование – это уточнение результатов анализа, направленное на оптимизацию с учетом ограничений, накладываемых нефункциональными требованиями, средой реализации и т. д.
Роли
Системный архитектор – руководит работами по анализу и проектированию ПС. Он определяет общую структуру каждого архитектурного представления (см. статью «RUP.Общие сведения»), декомпозицию представлений, группировку элементов и интерфейсы между группами.
Разработчик – проектирует классы и отношения между ними Он определяет, как согласовывать классы со средой реализации.
Разработчик БД – отвечает за проектирование базы данных ПС.
Артефакты
В процессе анализа и проектирования создаются следующие документы:
Модель проектирования – это основная модель ПС. Она описывает подсистемы, пакеты, компоненты, интерфейсы и классы, а также их взаимодействия, обеспечивающие требуемое поведение ПС.
Документ «Архитектура ПС», в котором собраны различные архитектурные представления ПС.
Модель данных – это описание структуры данных, хранимых в БД (например, реляционная модель данных).
|
|
|
Итерационный подход к проектированию ИС. Прототип системы.
RUP
предлагает итеративную модель разработки, включающую четыре фазы: начало, исследование, построение и внедрение. Прохождение через четыре основные фазы называется циклом разработки. Используется объектно-ориентированный анализ, объектно-ориентированное
программирование.
Методология RUP позволяет объединить проектную команду, предоставляя в ее распоряжение проверенные мировой практикой лучшие подходы к разработке ИС. К ним относятся такие процессы жизненного цикла создания ПО, как управление проектами, бизнес-моделирование, управление требованиями, анализ и проектирование, тестирование и контроль изменений. Внедрение в организации способствует выработке качественных внутрикорпоративных стандартов и повышению общей культуры разработки.
Основа RUP — итеративный процесс разработки. В условиях активно развивающегося мирового бизнеса практически невозможно создавать современные сложные программные системы последовательно, т. е. сначала выявлять все проблемы, затем принимать проектные решения, потом формировать программное обеспечение и, наконец, проверять полученное изделие. Итеративный подход позволяет улучшать понимание проблем на основе последовательных усовершенствований и конкретизировать их в эффективных решениях. Этот подход обеспечивает большую гибкость при изменяющихся требованиях и тактических коррективах в бизнес-целях, что позволяет более эффективно и заблаговременно идентифицировать и снижать проектные риски.
|
|
|
28. Понятие архитектуры ПО и ИС, артефакты, выпускаемые при проектировании архитектуры.
RUP – процесс, основанный на архитектуре
В основе RUP лежит КБ разработка ПС, предусматривающая разработку компонентов и сборку ПС из разработанных и готовых компонент. В основе любого проекта лежат кардинальные решения, определяющие принципы построения ПС, которые находят свое отражение в архитектуре системы. Разработка архитектуры ПС в RUP преследует следующие цели:
Описание организации ПС;
Определение компонентов и их интерфейсов;
Определение подсистем и объединение компонентов в подсистемы;
Создание основы для повторного использования компонентов;
Создание базиса для разработки;
Контроль над проектом и поддержка целостности системы.
|
|
|
Архитектура ПС находит отражение в различных архитектурных представлениях.
Логическое представление отражает функциональные требования к системе. Оно определяет основные (архитектурно значимые) пакеты, подсистемы и классы проекта.
Реализационное представление описывает организацию статических программных модулей (компонентов, файлов данных, исходного кода и др.) в терминах пакетов и уровней.
Процедурное представление отражает аспекты параллельности задач, потоков и процессов во время работы системы и их взаимодействия.
Представление развертывания показывает, как компоненты отображаются на базовые платформы и вычислительные узлы.
Usecase представление содержит ключевые ВИ и сценарии.
Архитектурные представления акцентируют внимание только на таких элементах, которые имеют существенное влияние на структуру ПС, ее производительность, масштабируемость, устойчивость, сопровождаемость, возможность развития. К числу таких элементов относятся:
Классы, моделирующие основные объекты деятельности;
Механизмы, определяющие поведение этих классов;
Уровни и подсистемы;
Интерфейсы;
Основные процессы и управляющие потоки.
В RUP предусмотрено создание отдельного документа, содержащего описание архитектуры ПС.
артефакты – документы, используемые, порождаемые или модифицируемые процессом. Основные артефакты в RUP – модель, элемент модели, документ, исходный код, исполняемая программа.
При моделировании создаются следующие артефакты в виде текстовых документов и моделей, описанных на UML:
Документ «Видение бизнеса» – определяет цели проведение бизнес-анализа.
Структура организации – статическое описание подразделений организации и отношений подчиненности в виде диаграмм пакетов и/или классов.
Модель видов деятельности включает бизнес-актеров и виды деятельности организации. К числу бизнес-актеров относятся: заказчики, партнеры, поставщики, власти (представители закона, инспекция и др.), дочерние организации, собственники и инвесторы, внешние информационные системы.Бизнес-актеры помогают определить границы организации, которую требуется описать. Виды деятельности представляют собой бизнес-процессы. Модель видов деятельности представляется с помощью usecase диаграмм.
Объектная модель включает бизнес-актеров, бизнес-исполнителей и бизнес-сущности, а также содержит описание их взаимодействий при реализации видов деятельности. Модель представляется на UML с помощью диаграмм классов и взаимодействий (последовательностей, коопераций, деятельностей), которые иногда называют технологическими сценариями.
Модель предметной области является подмножеством объектной модели. Она описывает основные бизнес-сущности и связи между ними. Эта модель представляется в виде диаграмм классов.
Глоссарий – текстовый документ, содержащий определения основных понятий, используемых в данном бизнесе.
Оценка деятельности организации – текстовый документ, описывающий текущее состояние организации, в которой будет использоваться ПС.
Бизнес-правила – текстовый документ, определяющий условия и ограничения, которым должен удовлетворять бизнес.
Дополнительные спецификации – текстовый документ, содержащий описание свойств бизнеса, не включенных в бизнес-модель.
Дата добавления: 2018-02-15; просмотров: 695; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!