Использование инструментальных средств

Для обеспечения инструментальной поддержки всех процессов жизненного цикла разработки и сопровождения ПС RUP рекомендует использование специализированных инструментальных средств IBM Rational:
— управление требованиями – IBM Rational RequisitePro;
— визуальное моделирование и генерация объектного кода – IBM Rational Rose, IBM Rational XDE;
— разработка — IBM Rational RapidDeveloper
— конфигурационное управление – IBM Rational ClearCase;
— управление изменениями – IBM Rational ClearQuest;
— автоматизированное документирование – IBM Rational SoDA;
— автоматизированное тестирование – IBM Rational TeamTest, IBM Rational TestFactory, IBM Rational Robot, IBM Rational PurifyPlus, Rational Visual Quantify, Rational Visual PureCoverage, Rational PerformanceStudio, IBM Rational SiteCheck и IBM Rational SiteLoad.

· Rational Requisite Pro - поддерживает обновления и отслеживает изменения в требованиях для всего коллектива разработчиков, представляя их в удобном виде для чтения, обсуждения и изменений.

• Rational ClearQuest - Windows и Web-размещаемый продукт, который помогает коллективу разработчиков отслеживать и управлять всеми действиями по изменению ПО в течение его жизненного цикла.
• Rational Rose - мировой лидер среди средств визуального моделирования для бизнес процессов, анализа требований, и проектирования на основе архитектуры компонентов.
• Rational SoDA - автоматизирует создание документации для всего процесса разработки ПО, значительно сокращая стоимость документации и время на ее создание.
• Rational Purify - средство поиска ошибок на run-time для разработчиков приложений и компонентов, программирующих на C/C++; помогает находить ошибки утечки памяти.
• Rational Visual Quantify - средство измерения характеристик для разработчиков приложений и компонентов, программирующих на C/C++, Visual Basic и Java; помогает определять и устранять узкие места в производительности ПО.
• Rational Visual PureCoverage - автоматически определяет области кода, которые не подвергаются тестированию; разработчики могут учесть это и более тщательно выполнять проверку.
• SQA TeamTest - создает, обслуживает и выполняет автоматизированные функциональные тесты, позволяя тщательно протестировать код и проверить, соответствует ли ПО предъявляемым к нему требованиям.
• Rational PerformanceStudio - простое в использовании, точное и масштабируемое средство, которое измеряет и предсказывает характеристики клиент/серверных и Web систем.
• Rational ClearCase - лидирующее на рынке средство конфигурационного управления, позволяющее менеджерам проекта отслеживать эволюцию каждого разрабатываемого проекта.

Контрольные вопросы:

1. Какие принципы лежат в основе методологии RUP?

2. На использование какой модели разработки направлена методология RUP?

3. Что представляет собой прецедент?

4. Что представляет собой сценарий использования?

5. Что описывает динамическая структура процесса RUP?

6. Что описывает статическая структура процесса RUP?

7. Какие основные стации выделяют в RUP? Задачи, решаемые на каждой стадии.

8. Какие рабочие процессы выделяют в RUP? Что выполняет каждый процесс?

9. Какие поддерживающие процессы выделяют в RUP? Что выполняет каждый процесс?

10. Что входит в RUP как в готовый продукт?

11. Какие инструментальные средства IBM Rationalрекомендует использовать RUP для обеспечения инструментальной поддержки всех процессов жизненного цикла разработки и сопровождения ПС?

Лекция 4

ТЕМА:Этап логического проектирования ИС. Основные подходы при создании концептуальной модели.

Литература: 1. Зелковиц М., Шоу А., Гэннон Дж. Принципы разработки программного обеспечения.

2. Гецци К., Джазайери М., Мандриоли Д. Основы инженерии программного обеспечения.

3. Камаев В. А., Костерин В. В. Технологии программирования.

4. Грекул В.И. Проектирование информационных систем.

Рассмотрим такие понятии, как «Предметная область» и «Бизнес-моделирование».

Предметная область - часть реального мира, подлежащая изучению с целью организации управления и, в конечном счете, автоматизации. Предметная область представляется множеством фрагментов, например, предприятие - цехами, дирекцией, бухгалтерией и т.д. Каждый фрагмент предметной области характеризуется множеством объектов и процессов, использующих объекты, а также множеством пользователей, характеризуемых различными взглядами на предметную область.

Бизнес-моделирование (деловое моделирование) - деятельность по формированию моделей организаций, включающая описание деловых объектов (подразделений, должностей, ресурсов, ролей, процессов, операций, информационных систем, носителей информации и т. д.) и указание связей между ними. Требования к формируемым моделям и их соответствующее содержание определяются целями моделирования.

Бизнес-моделирование является отдельным подпроцессом в процессе разработки программного обеспечения, в котором описывается деятельность компании и определяются требования к системе, т.е. те подпроцессы и операции, которые подлежат автоматизации в разрабатываемой информационной системе.

Моделью бизнес-процесса называется его формализованное (графическое, табличное, текстовое, символьное) описание, отражающее реально существующую или предполагаемую деятельность предприятия.

Модель, как правило, содержит следующие сведения о бизнес-процессе:

· набор составляющих процесс шагов - бизнес-функций;

· порядок выполнения бизнес-функций;

· механизмы контроля и управления в рамках бизнес-процесса;

· исполнителей каждой бизнес-функции;

· входящие документы/информацию, исходящие документы/информацию;

· ресурсы, необходимые для выполнения каждой бизнес-функции;

· документацию/условия, регламентирующие выполнение каждой бизнес-функции;

· параметры, характеризующие выполнение бизнес-функций и процесса в целом.

Модели бизнес-процессов применяются предприятиями для различных целей, что определяет тип разрабатываемой модели.

Графическая модель бизнес-процесса в виде наглядной, общепонятной диаграммы может служить для обучения новых сотрудников их должностным обязанностям, согласования действий между структурными единицами компании, подбора или разработки компонентов информационной системы и т. д. Описание с помощью моделей такого типа существующих и целевых бизнес-процессов используется для оптимизации и совершенствования деятельности компании путем устранения узких мест, дублирования функций и прочего.

Имитационные модели бизнес-процессов позволяют оценить их эффективность и посмотреть, как будет выполняться процесс с входными данными, не встречавшимися до сих пор в реальной работе предприятия.

Исполняемые модели бизнес-процессов могут быть запущены на специальном программном обеспечении для автоматизации процесса непосредственно по модели.

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

В последние годы разработчики программных средств моделирования бизнес-процессов уделяют большое внимание преобразованию графических моделей в модели других видов, в частности в исполняемые, назначением которых является обеспечение автоматизации бизнес-процесса и интеграция работы задействованных в его исполнении информационных систем.

Согласно еще одной классификации, пришедшей из моделирования сложных систем, выделяют следующие виды моделей бизнес-процессов:

· функциональные, описывающие совокупность выполняемых системой функций и их входы и выходы;

· поведенческие, показывающие, когда и/или при каких условиях выполняются бизнес- функции, с помощью таких категорий, как состояние системы, событие, переход из одного состояния в другое, условия перехода, последовательность событий;

· структурные, характеризующие морфологию системы - состав подсистем, их взаимосвязи;

· информационные, отражающие структуры данных - их состав и взаимосвязи.

Проблема сложности является главной проблемой, которую приходится решать при создании больших систем любой природы, в том числе и ЭИС. Ни один разработчик не в состоянии выйти за пределы человеческих возможностей и понять все систему в целом. Единственно эффективный подход к решению этой проблемы заключается в построении сложной системы из небольшого количества крупных частей, каждая из которых, в свою очередь, строится из частей меньшего размера и т.д., до тех пор, пока самые небольшие части можно будет строить из имеющегося материала. Этот подход известен под самыми разными названиями, среди них такие, как «разделяй и властвуй», иерархическая декомпозиция и др. По отношению к проектированию сложной программной системы это означает, что ее необходимо разделять (декомпозировать) на небольшие подсистемы, каждую из которых можно разрабатывать независимо от других. Это позволяет при разработке подсистемы любого уровня держать в уме информацию только о ней, а не обо всех остальных частях системы. Правильная декомпозиция является главным способом преодоления сложности разработки больших систем. Понятие «правильная» по отношению к декомпозиции означает следующее:

1. Количество связей между отдельными подсистемами должно быть минимальным.

2. Связность отдельных частей внутри каждой подсистемы должна быть максимальной.

Структура системы должна быть таковой, чтобы все взаимодействия между ее подсистемами укладывались в ограниченные, стандартные рамки:

1. Каждая подсистема должна инкапсулировать свою содержимое (скрывать его от других подсистем).

2. Каждая подсистема должна иметь четко определенный интерфейс с другими подсистемами.

На сегодняшний день в программной инженерии существуют два основных подхода к разработке ПО ЭИС, принципиальное различие которых обусловлено разными способами декомпозиции систем:

1. Функционально-модульный или структурный

2. Объектно-ориентированный.

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

Функциональные методики, наиболее известной из которых является методика IDEF, рассматривают организацию как набор функций, преобразующий поступающий поток информации в выходной поток. Процесс преобразования информации потребляет определенные ресурсы. Основное отличие от объектной методики заключается в четком отделении функций (методов обработки данных) от самих данных.

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