Методические указания по выполнению лабораторных занятий

жүктеу/скачать 3,94 Mb.

бет	51/102
Дата	01.09.2022
өлшемі	3,94 Mb.
	#38357
түрі	Методические указания

1 ... 47 48 49 50 51 52 53 54 ... 102

Вопросы для самопроверки

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

2. Дайте определение понятиям: «объект», «класс», «наследование», «инкапсуляция», «полиморфизм».

3. Назовите и дайте краткую характеристику базовых составляющих объектно-ориентированного подхода.

4. Перечислите преимущества объектно-ориентированного подхода перед структурным.

Лекция № 9. ОСНОВЫ УНИФИЦИРОВАННОГО ПРОЦЕССА
9.1. Структура Унифицированного процесса
9.2. Технологические процессы
9.3. Артефакты
9.4. Утилиты
9.5. Базовые концепции Унифицированного процесса
9.1. Структура Унифицированного процесса
Унифицированный процесс как процесс разработки программного обеспечения представляет собой методологию, содержащую детальное описание работ по созданию и внедрению ПО (авторы Айвар Якобсон, Грэди Буч и Джеймс Рамбо). Она отвечает «на вопросы когда, как, кто, что и с помощью чего реализуется проект» [30], а именно содержит описание:
 технологических процессов (когда) – последовательности видов деятельности (работ), дающих ощутимый результат. Технологический процесс, как правило, представляется в виде диаграммы, отображающей состав работ и их последовательность на той или иной стадии разработки ПО;
 видов деятельности (как) – работ, осуществляемых исполнителями (рис. 9.1);
 исполнителей (кто) – заинтересованных в реализации проекта отдельных лиц или групп. Исполнитель характеризуется строго определенным поведением и обязанностями (ролью). Поведение выражается через виды деятельности, осуществляемые исполнителем, а обязанности – через результаты, получаемые в процессе выполнения работ. В процессе реализации проекта один и тот же человек может выступать в разных ролях (рис. 9.2);


Рис. 9.1. Пример вида деятельности	Рис. 9.2. Пример исполнителя

 артефактов (что) – информации, создаваемой, изменяемой или используемой исполнителями в проекте. Другими словами, артефакт – это не только то, что создается в результате деятельности (технические артефакты – модели системы, исходные коды программ, готовый программный продукт, документация к нему и т. д.), но и то, что направляет эту деятельность (артефакты управления – календарный план, техническое задание, инструкции и т. д.) (рис. 9.3);

Рис. 9.3. Примеры артефактов
 используемых утилит (с помощью чего) – программных продуктов, рекомендуемых при выполнении работ.
9.2. Технологические процессы
Унифицированный процесс придерживается спиральной модели (стратегии) жизненного цикла ПО, предложенной Барри Боэмом (рис. 9.4).

Рис. 9.4. Спиральная стратегия жизненного цикла
Каждый виток характеризуется приращением (инкрементом) функциональности системы и одинаковым набором технологических процессов и стадий (рис. 9.5, в Унифицированном процессе – фаз). В рамках одной стадии также используется идея спиральной разработки. Перед началом выполнения каждой стадии планируется количество итераций, каждая из которых характеризуется некоторым приращением результатов. В рамках одной итерации выполняются основные процессы, начиная от формирования требований и заканчивая внедрением [29, 30].
В Унифицированном процессе принято временное разбиение жизненного цикла на четыре стадии: начало, уточнение, конструирование и переход. Каждая стадия должна завершаться достижением конкретного результата (созданием артефактов), используемого далее в качестве управления последующими работами или завершающего реализацию проекта.

Рис. 9.5. Интенсивность процессов при создании версии информационной системы
Начало (англ. inception). Основной целью фазы является фиксация требований к разрабатываемой информационной системе, т. е. достижения согласия всех заинтересованных сторон относительно вида и возможностей конечного продукта. Данная фаза начинается с системного анализа предметной области и заканчивается утверждением технического задания.
Уточнение (англ. elaboration). Целью фазы является разработка архитектуры и моделей проектируемой системы, основным результатом – технический проект.
Конструирование (англ. construction). Целью фазы является разработка действующей версии системы, основным результатом – версия системы.
Переход (англ. transition). Целью фазы является внедрение версии у заказчика, т. е. переход на новую технологию выполнения работ в организации. С точки зрения разработчиков основной результат данной фазы – удовлетворение потребностей заказчика и акты приемки-сдачи, а заказчика – обученный персонал, документация к информационной системе и, естественно, сама работающая система.
Организация работ по содержанию разбита на две группы технологических процессов: основные и вспомогательные.
Основные технологические процессы по названиям совпадают со стадиями жизненного цикла, но в контексте Унифицированного процесса они отражают, в первую очередь, не временной аспект реализации проекта, а их содержание, т. е. определяют, какие виды работ должны быть выполнены и какой результат (артефакты) должен быть получен. Более подробно стадии жизненного цикла рассмотрены в второй части.
Вспомогательные технологические процессы обеспечивают выполнение основных и рассмотрены во второй части и в [5].
Интенсивность работ на рис. 9.5 дана приближено и зависит от многих факторов (имеются ли аналоги у проекта, квалификация разработчиков, запросы заказчика, фаза жизненного цикла и т.д.). Как видно из рис. 9.5, проектирование не заканчивается в фазе уточнения, к концу которой должен быть получен технический проект. В фазе конструирования выполняется не меньший, а порой и больший, объем работ, связанный с проектированием классов, компонентов и подсистем.
В то же время следует отметить, что не существует такого процесса разработки информационных систем, который мог бы применяться во всех случаях. Он должен иметь возможность адаптироваться под текущие нужды конкретного проекта. Внутри организации, выполняющей проект, процесс должен быть более-менее единым. Это единство позволит легко обмениваться компонентами, перебрасывать персонал и руководителей с одного проекта на другой, иметь возможность сравнения показателей выполнения работ и т. д.
Как было отмечено выше, технологический процесс представляется в виде диаграммы. На рис. 9.6 показан пример диаграммы, отображающей обобщенную схему процесса «Управление проектом» [30].

Рис. 9.6. Обобщенная схема технологического процесса «Управление проектом»
9.3. Артефакты
Все виды деятельности направлены на создание артефактов, самым главным и ценным из которых является разработанная информационная система. С точки зрения разработчиков не менее ценными артефактами являются разработанные модели системы, так как они, с одной стороны, фиксируют результаты одних работ, а с другой – выступают в качестве управляющей и направляющей информации для других. В Унифицированном процессе модели, как правило, соответствуют основным технологическим процессам. Каждая модель представляет собой набор взаимосвязанных диаграмм UML и документов. Краткая характеристика моделей дана в табл. 9.1 [29].
Таблица 9.1. Краткая характеристика моделей

Процесс	Модель	Назначение
Формирование требований	Модель вариантов использования	Отображает существенные функциональные требования к системе в форме, удобной для всех заинтересованных лиц. Под существенными требованиями понимаются требования, реализация которых принесет пользователям ощутимый и значимый результат. Наименее формальная, но управляет всем процессом разработки
Анализ требований	Модель анализа	Детализирует варианты использования с точки зрения организации внутренней архитектуры системы, а именно: состава основных сущностей (классов анализа) и взаимодействия между ними. Класс анализа – укрупненный класс (сущность), который в дальнейшем будет разбит на составляющие
Проектирование	Модель проектирования	Содержит полное детализированное описание внутренней архитектуры и алгоритмов работы системы. Применяется внутри организации, разрабатывающей систему
Реализация	Модель реализации	Содержит описание исполняемой системы: компонентов (исходных текстов программ, исполняемых модулей, таблиц БД и т. д.) и схемы развертывания системы
Тестирование	Модель тестирования	Предназначена для проверки соответствия полученного ПО требованиям

Модели описывают проектируемую систему с различных точек зрения и на разном уровне абстракции. При этом некоторые элементы (например, диаграммы или классы) могут одновременно входить в разные модели. Более того, один и тот же элемент может входить в две и более моделей с разной степенью детализации. Графическое обозначение модели см. на рис. 9.7.

Рис. 9.7. Модель
Модели могут быть вложены друг в друга. Вложенность моделей изображается двумя способами (рис. 9.8).

Рис. 9.8. Способы отображения вложенности моделей
В Унифицированном процессе набор получаемых артефактов, как и технологический процесс, также может отображаться в виде диаграммы. На рис. 9.9 показан пример диаграммы артефактов для процесса «Управление проектом» [30].

Рис. 9.9. Диаграмма артефактов технологического процесса «Управление проектом»
9.4. Утилиты
Качественное и своевременное выполнение проекта невозможно без применения средств автоматизации деятельности – утилит. К утилитам относятся различные инструментальные средства, поддерживающие жизненный цикл ПО. В качестве примера системного подхода к разработке информационных систем можно привести продукты компании 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, IBM Rational SiteCheck и IBM Rational SiteLoad.
Методологической основой использования перечисленных продуктов является IBM Rational Unified Process (IBM RUP) – «электронный аналог» Унифицированного процесса. IBM RUP поставляется в виде «on-line» документации (размещаемой в Web базы знаний), что позволяет его использовать во внутренней сети организации с целью приобщения всех сотрудников к полезной информации, и состоит:
 из руководств для всех членов коллектива разработчиков и каждого временного интервала жизненного цикла ПО. Руководства представлены в двух видах: для осмысления процесса на верхнем уровне и в виде подробных наставлений по повседневной деятельности;
 рекомендаций по использованию инструментальных средств, автоматизирующих стадии жизненного цикла ПО;
 примеров и шаблонов для Rose, которые служат руководствами по тому, как «правильно» проектировать систему;
 шаблонов для SoDA, которые помогают автоматизировать документирование ПО;
 шаблонов Microsoft Word, которые предназначены для поддержки документации по всем стадиям и работам жизненного цикла ПО;
 планов в формате Microsoft Project, отражающих итерационную разработку;
 Development Kit (англ. – комплект разработки), содержащего описание возможностей по конфигурации и расширения IBM RUP для специфических нужд проекта;
 доступа к Resource Center, содержащего последние публикации, обновления, подсказки, методики, а также ссылки на add-on (англ. – расширения) и сервисы;
 книгу Филиппа Кратчена «Введение в Rational Unified Process» [30]. Книга содержит более 200 страниц и является хорошим вводным руководством к Унифицированному процессу и базе знаний.
IBM RUP ориентирован на всех участников проекта. На рис. 9.9 приведена стартовая страница продукта RUP.

Рис. 9.10. Стартовая страница RUP
Ключевым продуктом для автоматизации технологического процесса «Проектирование» является IBM Rational Rose, которое представляет собой классическое Case-средство. К основным возможностям Rose относятся:
 прямое проектирование – построение модели системы в виде диаграмм UML и глоссария;
 кодогенерация – получение кода программы на основе модели системы. Поддерживаются: С++, Ada, Java, Visual Basic, CORBA¹/IDL². Сторонние производители разрабатывают специальные мосты к не входящим в стандартную поставку языкам (например, к Object Pascal);
 генерация схем БД для Oracle, скриптов DDL³ и документов XML⁴;
 обратное проектирование (реинжиниринг) – получение модели на основе кода программы, БД, скрипта или документа;
 синхронизация модели и ее физической реализации для поддержания итеративной разработки системы.
IBM Rational Rose позиционируется для использования аналитиками, проектировщиками и разработчиками.
Для разработки программ рекомендуется использовать среду разработки программного обеспечения IBM Rational RapidDeveloper.
Аналогичная линейка продуктов, поддерживающая ключевые процессы жизненного цикла, выпускается компанией Borland (Borland Together Designer, Borland Together Architect, Borland StarTeam, Borland CaliberRM и др.).
Следует отметить, что в последнее время наблюдается тенденция к объединению в одном продукте возможностей Case-средства (функций проектирования) и среды разработки программ (функций реализации).

¹CORBA – Common Object Request Broker Architecture (общая объектная архитектура брокеров запроса).
²IDL – Interface Definition Language (язык описания интерфейсов).
³DDL – Data Definition Language (язык определения данных, составная часть SQL). SQL – Structured Query Language (структурированный язык запросов).
⁴XML – eXtensible Markup Language (расширяемый язык разметки).
9.5. Базовые концепции Унифицированного процесса
Базовыми концепциями Унифицированного процесса являются следующие:
 разработка ведется итеративно;
 разработка направляется (руководствуется) требованиями, реализация и изменение которых постоянно отслеживаются. Ключевыми требованиями являются варианты использования системы (функциональные требования);
 модели и программный код системы ориентирован на модульную архитектуру, позволяющую эффективно распределять обязанности между участниками проекта и достичь более высокой степени повторного использования результатов в текущем и в других проектах;
 использование визуального моделирования в целях создания полного и согласованного описания всех аспектов разрабатываемой системы (моделей). В качестве базового средства создания моделей используется UML;
 все процессы должны поддерживаться согласованным набором инструментальных средств (утилит).

жүктеу/скачать 3,94 Mb.

Достарыңызбен бөлісу:

1 ... 47 48 49 50 51 52 53 54 ... 102