Курс лекций инструментальные средства. Конспект лекций
 Скачать 1.6 Mb.
|
|
КОНСПЕКТ ЛЕКЦИЙ междисциплинарного курса МДК.03.02. ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Специальность 09.02.03 Программирование в компьютерных системах Квалификация выпускника – Техник-программист Форма обучения – Очная 2016 г Содержание 1 Введение 3 1.1 Инструментальное программное обеспечение. Основные понятия и определения 3 Базовые принципы построения CASE-средств 4 Основные функциональные возможности CASE-средств 6 1.2 Назначение и виды инструментального ПО 9 1.3 Модели процесса разработки программного обеспечения 12 Контрольные вопросы 17 2 Разработка программного обеспечения 19 2.1 Основные методы и средства эффективной разработки ПО 19 2.2 Основные подходы к интегрированию программных модулей 32 2.3 Модульная структура программных продуктов 36 Контрольные вопросы 41 3 Методологии моделирования предметной области 43 3.1 Основные принципы разработки надежного программного обеспечения 43 3.2 Функциональная методология IDEF0 55 3.3 Методология DFD 63 3.4 Методология IDEF3 65 Контрольные вопросы 73 4 Проектирование программного обеспечения при объектном подходе 74 4.1 Разработка структуры программного обеспечения при объектном подходе. Основы унифицированного языка моделирования UML 74 4.2 Экстремальное программирование 81 Контрольные вопросы 85 1 Введение 1.1 Инструментальное программное обеспечение. Основные понятия и определения Очевидно, что большие размеры и высокая сложность разрабатываемых ПС при ограничениях на бюджетные и временные затраты проекта могут привести к низкому качеству конечных программных продуктов и системы в целом. В этой связи в последнее время все большее внимание уделяется современным технологиям и инструментальным средствам, обеспечивающим автоматизацию процессов ЖЦ ПС (CASE-средствам). Использование таких инструментальных средств позволяет существенно сократить длительность и стоимость разработки систем и ПС при одновременном повышении качества процесса разработки и, как следствие, качества разработанных ПС. В истории развития CASE-средств обычно выделяется шесть периодов. Данные периоды различаются применяемой техникой и методами разработки ПС. Эти периоды используют в качестве инструментальных средств следующие средства. Период 1. Ассемблеры, анализаторы. Период 2. Компиляторы, интерпретаторы, трассировщики. Период 3. Символические отладчики, пакеты программ. Период 4. Системы анализа и управления исходными текстами. Период 5. Первое поколение CASE (CASE-I). Это CASE-средства, позволяющие выполнять поддержку начальных работ процесса разработки ПС и систем (анализ требований к системе, проектирование архитектуры системы, анализ требований к программным средствам, проектирование программной архитектуры, логическое проектирование баз данных). Адресованы непосредственно системным аналитикам, проектировщикам, специалистам в предметной области. Поддерживают графические модели, экранные редакторы, словари данных. Не предназначены для поддержки полного ЖЦ ПС. Период 6. Второе поколение CASE (CASE-II). Представляют собой, как правило, набор (линейку) инструментальных средств, каждое их которых предназначено для поддержки отдельных этапов процесса разработки или других процессов ЖЦ ПС. В совокупности обычно поддерживают практически полный ЖЦ ПС. Используют средства моделирования предметной области, графического представления требований, поддержки автоматической кодогенерации ПС. Содержат средства контроля и управления разработкой, интеграции системной информации, оценки качества результатов разработки. Поддерживают моделирование и прототипирование системы, тестирование, верификацию, анализ сгенерированных программ, генерацию документации по проекту. Ко второму поколению CASE-средств относятся, например, линейки Telelogic и AllFusion. CASE-технологии предлагают новый, основанный на автоматизации подход к концепции ЖЦ ПС. Современные варианты CASE-моделей ЖЦ, называемые обычно RAD-моделями. Наибольшие изменения в ЖЦ ПС при использовании CASE-технологий касаются первых этапов ЖЦ, связанных с анализом требований и проектированием. CASE-средства позволяют использовать визуальные среды разработки, средства моделирования и быстрого прототипирования разрабатываемой системы или ПС. Это позволяет на ранних этапах разработки оценить, насколько будущая система или программное средство устраивает заказчика и насколько она дружественна будущему пользователю. Таблица 1.1 содержит усредненные оценки трудозатрат по основным этапам разработки ПС при различных подходах к процессу разработки. Номерам строк в данной таблице соответствуют: 1 – традиционная разработка с использованием классических технологий; 2 – разработка с использованием современных структурных методологий проектирования; 3 – разработка с использованием CASE–технологий. Таблица 1.1 – Сравнительная оценка трудозатрат по этапам процесса разработки программных средств
Из таблицы видно, что при традиционной разработке ПС основные усилия направлены на кодирование и тестирование, а при использовании CASE-технологий – на анализ и проектирование, поскольку CASE предполагают автоматическую кодогенерацию, автоматизированное тестирование и автоматический контроль проекта. Сопровождение кодов ПС заменяется сопровождением спецификаций проектирования. В результате данных факторов цена ошибок, вносимых в проект при разработке и сопровождении ПС и систем, существенно снижается. Резюме В истории развития CASE-средств обычно выделяется шесть периодов. При традиционной разработке ПС основные усилия направлены на кодирование и тестирование, при использовании CASE-технологий – на анализ и проектирование. Базовые принципы построения CASE-средств Большинство CASE-средств основано на парадигме метод – нотация –средство. Парадигма – это система изменяющихся форм некоторого понятия. В данном случае метод реализуется с помощью нотаций. Метод и нотации поддерживаются инструментальными средствами. Метод – это систематическая процедура или техника генерации описаний компонент ПС. Нотация – это система обозначений, предназначенная для описания структуры системы, элементов данных, этапов обработки; может включать графы, диаграммы, таблицы, схемы алгоритмов, формальные и естественные языки. Например, метод JSP реализуется с помощью нотации, базирующейся на применении четырех базовых конструкций данных. Современной нотацией методологии SADT является IDEF0. Средства – это инструментарий для поддержки методов, помогающий пользователям при создании и редактировании графического проекта в интерактивном режиме, способствующий организации проекта в виде иерархии уровней абстракции, выполняющий проверки соответствия компонентов. Например, средством, поддерживающим метод JSP, является SmartDraw. IDEF0 поддерживается средством BPwin. Фактически CASE-средство – это совокупность графически ориентированных инструментальных средств, поддерживающих процессы или отдельные этапы процессов ЖЦ ПС и систем. К CASE-средствам может быть отнесено любое программное средство, обеспечивающее автоматическую помощь при разработке ПС, их сопровождении или управлении проектом, базирующееся на следующих основополагающих принципах: Графическая ориентация. В CASE-средствах используется мощная графика для описания и документирования систем или ПС и для улучшения интерфейса с пользователем. Интеграция. CASE-средство обеспечивает легкость передачи данных между своими компонентами и другими средствами, входящими в состав линейки CASE-средств. Это позволяет поддерживать совокупность процессов ЖЦ ПС. Локализация всей проектной информации в репозитории (компьютерном хранилище данных). Исполнителям проекта доступны соответствующие разделы репозитория в соответствии с их уровнем доступа. Это обеспечивает поддержку принципа коллективной работы. Информация из репозитория может использоваться для работ над текущим проектом, в том числе для автоматической кодогенерации ПС или систем, разработки следующих проектов, сбора статистики по выполненным ранее проектам организации. Помимо данных принципов в основе концептуального построения CASE-средств лежат следующие положения. Человеческий фактор. Его учет позволяет привести процессы ЖЦ ПС и систем к легкой, удобной и экономичной форме. Использование базовых программных средств, применяющихся в других приложениях (СУБД, компиляторы с различных языков программирования, отладчики, языки четвертого поколения 4GL и др.). Автоматизированная или автоматическая кодогенерация. При автоматизированной кодогенерации выполняется частичная генерация кодов программного средства, остальные участки программируются вручную. При автоматической кодогенерации выполняется полная генерация кодов программного средства. Возможны различные виды генерации (например, генерация проектной документации, базы данных по информационной модели, кодов из разработанных спецификаций программного средства; автоматическая сборка модулей, хранящихся в репозитории). Ограничение сложности. Такое ограничение позволяет поддерживать сложность компонентов разрабатываемого программного средства или системы на уровне, доступном для понимания, использования и модификации. Доступность для различных категорий пользователей, в том числе заказчиков, специалистов в предметной области, системных аналитиков, проектировщиков, программистов, тестировщиков, инженеров по качеству, менеджеров проектов. CASE-средства содержат инструменты различного функционального назначения, поддерживающие различные этапы основных, вспомогательных и организационных процессов ЖЦ ПС и систем. Рентабельность, обеспечивающая быструю окупаемость денежных средств, вложенных в приобретение CASE-средства, за счет сокращения сроков и стоимости проектов. Сопровождаемость. CASE-средства обладают способностью адаптации к изменяющимся требованиям и целям проекта. Резюме CASE-средства представляют собой совокупность графически ориентированных инструментальных средств, поддерживающих ЖЦ ПС и систем. CASE-средства базируются на принципах графической ориентации, интеграции и локализации всей проектной информации в репозитории. В основе построения CASE-средств лежат человеческий фактор, использование базовых ПС, автоматизированная или автоматическая кодогенерация, ограничение сложности, доступность для разных категорий пользователей, рентабельность, сопровождаемость. Основные функциональные возможности CASE-средств В состав CASE-средств входят четыре основных компонента: Средства централизованного хранения всей информации о проекте (репозиторий). Предназначены для хранения информации о разрабатываемом программном средстве или системе в течение всего ЖЦ разработки. Средства ввода. Служат для ввода данных в репозиторий, организации взаимодействия участников проекта с CASE-средством. Должны поддерживать различные методологии анализа, проектирования, тестирования, контроля. Предназначены для использования в течение ЖЦ программного средства или системы различными категориями участников проекта (системными аналитиками, проектировщиками, программистами, тестировщиками, менеджерами, специалистами по качеству и т.д.). Средства анализа и разработки. Предназначены для анализа различных видов графических и текстовых описаний и их преобразований в процессе разработки. Средства вывода. Служат для кодогенерации, создания различного вида документов, управления проектом. Все компоненты CASE-средств в совокупности обладают следующими функциональными возможностями: поддержка графических моделей; контроль ошибок; поддержка репозитория; поддержка основных, вспомогательных и организационных процессов ЖЦ ПС. Поддержка графических моделей В CASE-средствах разрабатываемые ПС представляются схематически. На разных уровнях проектирования могут использоваться различные виды и нотации графического представления ПС. Обычно применяются диаграммы различных типов, в том числе иерархии требований, диаграммы функционального моделирования (например IDEF0, DFD), диаграммы информационного моделирования (например IDEF1X), структурограммы , диаграммы Джексона, диаграммы Варнье – Орра, UML-диаграммы и т.п. Разработка диаграмм осуществляется с помощью специальных графических редакторов, основными функциями которых являются создание и редактирование иерархически связанных диаграмм, их объектов и связей между объектами, а также автоматический контроль ошибок. Контроль ошибок В CASE- средствах , как правило, реализуются следующие типы контроля: Контроль синтаксиса диаграмм и типов их элементов. Например, при IDEF0-моделировании контролируется максимальное и минимальное количество функциональных блоков на диаграммах, наличие дуги управления и выходной дуги для любого функционального блока и т.п. Контроль полноты и корректности диаграмм. При данном типе контроля выполняется проверка наличия имен у всех элементов диаграмм, проверка наличия необходимых описаний в репозитории и др. Контроль декомпозиции функций. При данном типе контроля выполняется оценка декомпозиции на основе различных метрик. Например, может быть оценена эффективность и корректность декомпозиции с точки зрения связности и сцепления модулей. Сквозной контроль диаграмм одного или различных типов на предмет их взаимной корректности. Например, при IDEF0-моделировании контролируется соответствие граничных дуг родительского блока с внешними дугами дочерней диаграммы. При разработке IDEF0- и IDEF1Х-моделей предметной области выполняется контроль их взаимной корректности и непротиворечивости. Поддержка репозитория Основными функциями репозитория являются хранение, обновление, анализ, визуализация всей информации по проекту и организация доступа к ней. Репозиторий обычно хранит более 100 типов объектов (например, диаграммы, определения экранов и меню, проекты отчетов, описания данных, модели данных, модели обработки, исходные коды, элементы данных). Каждый информационный объект, хранящийся в репозитории, описывается совокупностью своих свойств, например, идентификатор, тип, текстовое описание, компоненты, область значений, связи с другими объектами, времена создания и последнего обновления объекта, автор и т.п. Репозиторий является базой для автоматической генерации документации по проекту. Основными типами отчетов являются: отчеты по содержимому – включают информацию по потокам данных и их компонентов; списки функциональных блоков диаграмм и их входных и выходных потоков; списки всех информационных объектов и их атрибутов; историю изменений объектов; описания модулей и интерфейсов между ними; планы тестирования модулей и т.п.; отчеты по перекрестным ссылкам – содержат информацию по связям всех вызывающих и вызываемых модулей; списки объектов репозитория, к которым имеет доступ конкретный исполнитель проекта; информацию по связям между диаграммами и конкретными данными; маршруты движения данных от входа к выходу; отчеты по результатам анализа – включают данные по взаимной корректности диаграмм, списки неопределенных информационных объектов, списки неполных диаграмм, данные по результатам анализа структуры проекта и т.п.; отчеты по декомпозиции объектов – включают совокупности объектов, входящих в каждый объект, а также объекты, в состав которых входит каждый объект. Поддержка процессов жизненного цикла программных средств и систем Основой поддержки процесса разработки являются следующие свойства современных CASE-средств. Покрытие всего жизненного цикла систем или программных средств. Как отмечалось, современные CASE-средства поддерживают практически полный ЖЦ ПС. Однако первоочередное внимание уделяется начальным работам процесса разработки – анализу требований к системе, проектированию системной архитектуры, анализу требований к программным средствам и проектированию программной архитектуры. Грамотная разработка требований к системе и ПС является основой всего проекта, их полнота и корректность определяют уровень соответствия результатов разработки требованиям заказчика. Поддержка прототипирования. Большинство моделей ЖЦ, предназначенных для разработки сложных или критичных продуктов, базируются на применении прототипирования. Это касается в первую очередь моделей, поддерживающих инкрементную и эволюционную стратегии разработки. Прототипирование применяется на ранних этапах ЖЦ и позволяет уточнять требования к системе или программному средству, а также прогнозировать поведение разрабатываемого продукта. Поддержка современных методологий разработки систем или программных средств. Современные линейки CASE-средств поддерживают, как правило, различные методологии, предназначенные для использования на различных этапах процесса разработки. При этом выполняется графическая поддержка построения диаграмм различных типов, контроль корректности использования шагов проектирования и подготовка документации. Автоматическая кодогенерация. Кодогенерация позволяет построить автоматически до 90 % исходных кодов на языках высокого уровня. Различными CASE-средствами поддерживаются практически все известные языки программирования. Средства кодогенерации можно подразделить на два вида: средства генерации управляющей структуры продукта; данные средства выполняют автоматическое построение логической структуры программного средства, кодов для базы данных, файлов, экранов, отчетов. Остальные фрагменты программного средства кодируются вручную; средства генерации полного продукта; данные средства позволяют на основе разработанных спецификаций или моделей генерировать полные коды программного средства, пользовательскую и программную документацию к нему. Резюме В состав CASE-средств входят средства централизованного хранения информации о проекте (репозиторий), средства ввода, средства анализа и разработки, средства вывода. Все компоненты CASE-средств в совокупности поддерживают графические модели, репозиторий, процесс разработки и ряд вспомогательных и организационных процессов, выполняют контроль ошибок. 1.2 Назначение и виды инструментального ПО Все CASE-средства подразделяются на типы, категории и уровни. Классификация по типам Данная классификация отражает функциональное назначение CASE-средства в ЖЦ ПС и систем. 1. Анализ и проектирование Средства этого типа используются для поддержки начальных этапов процесса разработки: анализа предметной области, разработки требований к системе, проектирования системной архитектуры, разработки требований к программным средствам, проектирования программной архитектуры, технического проектирования программных средств. Средства данного типа поддерживают известные методологии анализа и проектирования. На выходе генерируются спецификации системы, ее компонентов и интерфейсов, связывающих эти компоненты, архитектура системы, архитектура программного средства, технический проект программного средства, включая алгоритмы и определения структур данных. К средствам данного типа можно отнести, например, AllFusion Process Modeler (BPwin), CASE.Аналитик, Design/IDEF, Telelogic DOORS, Telelogic Modeler, Telelogic TAU, Telelogic Rhapsody, Telelogic Statemate 2. Проектирование баз данных и файлов Средства этого типа обеспечивают логическое моделирование данных, автоматическое преобразование моделей данных в третью нормальную форму, автоматическую генерацию схем баз данных и описаний форматов файлов на уровне программного кода. К средствам этого типа можно отнести, например, AllFusion Data Modeler (ERwin), CA ERwin Data Model Validator (ранее ERwin Examiner), S-Designor, Silverrun, Designer2000, Telelogic TAU, Telelogic Rhapsody. 3. Программирование и тестирование Средства этого типа поддерживают седьмую работу процесса разработки (программирование и тестирование). Данные средства выполняют автоматическую кодогенерацию ПС на основе спецификаций или моделей. Содержат графические редакторы, средства поддержки работы с репозиторием, генераторы и анализаторы кодов, генераторы тестов, анализаторы покрытия тестами, отладчики. К средствам данного типа можно отнести, например, TAU/Developer, TAU/Tester, Logiscope Audit, Logiscope RuleChecker, Logiscope TestChecker, Logiscope Reviewer, Rhapsody Developer. 4. Сопровождение и реинженерия Общей целью средств этого типа является поддержка корректировки, изменения, преобразования, реинженерия существующей системы, поддержка документации по проекту. К данным средствам относятся средства документирования, анализаторы программ, средства управления изменениями и конфигурацией ПС и систем, средства реструктурирования и реинженерии (реинженерия, реинженеринг – reverse engineering – обратное проектирование, например, построение спецификаций или моделей по исходным текстам программ), средства обеспечения мобильности, позволяющие перенести разработанную систему или программные средства в новое операционное или аппаратное окружение. Средства реинженерии включают: статические анализаторы для генерирования схем программного средства из его кодов и оценки влияния модификаций; динамические анализаторы, включающие трансляторы со встроенными отладочными возможностями; документаторы, автоматически обновляющие документацию при изменении кода программного средства; редакторы кодов, автоматически изменяющие при редактировании кодов предшествующие ему структуры, в том числе и спецификации требований; средства доступа к спецификациям, позволяющие выполнять их модификацию и генерацию модифицированного кода; средства реверсной инженерии, транслирующие коды в спецификации или модели. К средствам данного типа можно отнести, например, Telelogic DocExpress, Telelogic Synergy, Telelogic Change, средства линейки AllFusion Change Management Suite. Следует отметить, что ряд CASE-средств других типов содержат в своем составе средства реинженерии. Это касается, например, CASE-средств AllFu-sion Data Modeler, Telelogic Rhapsody. 5. Окружение К средствам данного типа относятся средства поддержки интеграции CASE-средств и данных. К данному типу можно отнести, например, Telelogic Rhapsody Gateway, Telelogic Rhapsody Interface Pack, AllFusion Data Profiler, AllFusion Model Manager, AllFusion Model Navigator. 6. Управление проектом К средствам данного типа относятся средства поддержки процесса управления ЖЦ ПС и систем. Их функциями являются планирование, контроль, руководство, организация взаимодействия и т.п. К средствам данного типа можно отнести, например, Telelogic Focal Point, Telelogic Dashboard, AllFusion Process Management Suite, ADvisor. Резюме Классификация CASE-средств по типам отражает функциональное назначение CASE-средства в ЖЦ ПС. Выделяют типы CASE-средств, ориентированные на следующие этапы процесса разработки и другие процессы ЖЦ: анализ и проектирование, проектирование баз данных и файлов, программирование и тестирование, сопровождение и реинженерия, окружение, управление проектом. Классификация по категориям Данная классификация отражает уровень интегрированности CASE-средств по выполняемым функциям. 1. Категория Tool (tool – рабочий инструмент) Включает средства самого низкого уровня интегрированности. В данную категорию средств входят инструментальные средства, решающие небольшую автономную задачу при разработке программного средства или системы. Обычно средства данной категории являются компонентами CASE-средств более высокого уровня интегрированности. 2. Категория ToolКit (toolкit – набор инструментов, пакет разработчика) Включает CASE-средства среднего уровня интегрированности. Средства данной категории используют репозиторий для всей информации о проекте и ориентированы обычно на поддержку одного этапа или одной работы процесса разработки или на поддержку одного из вспомогательных или организационных процессов ЖЦ ПС или систем. CASE-средства данной категории представляют собой интегрированную совокупность инструментальных средств, имеющих как правило общую функциональную ориентацию. К CASE-средствам данной категории может быть отнесено, например, большинство CASE-средств из линеек Telelogic и AllFusion при их изолированном использовании. 3. Категория Workbench (workbench – рабочее место). CASE-средства данной категории обладают самой высокой степенью интеграции. Они представляют собой интегрированную совокупность инструментальных средств, поддерживающих практически весь процесс разработки и ряд вспомогательных и организационных процессов ЖЦ ПС и систем. Используют репозиторий для хранения информации по проекту, поддерживают организацию коллективной работы над проектом. Обычно к категории Workbench относятся линейки CASE-средств при их интегральном использовании. Примерами являются линейки Telelogic и AllFusion. Данные линейки CASE-средств поддерживает практически полностью процесс разработки ПС и систем, процессы сопровождения, документирования, управления конфигурацией, частично процессы обеспечения качества, верификации, аттестации. Таким образом, линейки Telelogic и AllFusion поддерживают практически весь ЖЦ ПС и систем. Резюме Классификация по категориям отражает уровень интегрированности CASE-средств по выполняемым функциям. Различают категории Tool, ToolКit, Workbench. Классификация по уровням Данная классификация связана с областью действия CASE-средств в ЖЦ ПС, систем и организаций. 1. Верхние (Upper) CASE-средства CASE-средства данного уровня называют средствами компьютерного планирования. Их основной целью является помощь руководителям организаций, предприятий и конкретных проектов в определении политики организации и создании планов проекта. CASE-средства данного уровня позволяют строить модель предметной области, проводить анализ различных сценариев (существующего, наилучших, наихудших), накапливать информацию для принятия оптимальных решений. Таким образом, применительно к ЖЦ ПС и систем данные средства поддерживают процесс заказа и первую работу процесса разработки (подготовка процесса разработки). Графические средства данного уровня используются как формализованный язык общения между заказчиком (пользователем) и разработчиком требований. К средствам данного уровня можно отнести, например, Telelogic System Architect, Telelogic Focal Point, Telelogic Dashboard, средства линейки AllFusion Modeling Suite. 2. Средние (Middle) CASE-средства CASE-средства данного уровня поддерживают начальные этапы процесса разработки (анализ предметной области, разработка требований к системе, проектирование системной архитектуры, разработка требований к программным средствам, проектирование программной архитектуры). При этом встроенные графические средства используются как формализованный язык общения между заказчиком (пользователем) и разработчиком спецификаций требований. Обычно данные средства обладают возможностями накопления и хранения информации по проекту. Это позволяет использовать накопленные данные как в текущем, так и в других проектах. Например, с помощью накопленной информации могут оцениваться продукты текущего проекта. При этом аналогичная информация предыдущих проектов используется в качестве базовой для оценки. CASE-средства данного уровня зачастую поддерживают прототипирование и автоматическое документирование. К CASE-средствам данного уровня можно отнести, например, линейку AllFusion Modeling Suite, средства Telelogic DOORS, Telelogic Modeler, Telelogic Tau, Telelogic Rhapsody, Telelogic Statemate, Telelogic DocExpress. 3. Нижние (Lower) CASE-средства CASE-средства данного уровня поддерживают вторую половину работ процесса разработки ПС. Содержат графические средства, исключающие необходимость разработки физических мини – спецификаций для программных модулей. Спецификации представляются обычно в виде моделей, которые непосредственно преобразуются в программные коды разрабатываемого программного средства или системы. Автоматически генерируется до 90 % кодов. Входной информацией для кодогенераторов являются спецификации, разработанные как в CASE-средствах данного уровня, так и в CASE-средствах среднего уровня. CASE-средства нижнего уровня, как правило, поддерживают также прототипирование, тестирование, управление конфигурацией, генерацию документации, облегчают модификацию и сопровождение ПС или систем. К CASE-средствам данного уровня можно отнести AllFusion Data Modeler, Telelogic Rhapsody, Telelogic Tau, Telelogic Statemate, Telelogic TAU Logiscope, Telelogic Change, Telelogic Synergy, Telelogic DocExpress. Следует отметить, что в состав CASE-средств среднего и высокого уровней интегрированности обычно входят инструментальные средства, относящиеся к нескольким уровням. Линейки CASE-средств, предназначенные для поддержки всего ЖЦ ПС и систем, включают в свой состав средства всех трех уровней. Резюме Классификация по уровням связана с областью действия CASE-средств в ЖЦ ПС и систем. Различают верхние, средние и нижние CASE-средства. Линейки CASE-средств включают в свой состав средства всех трех уровней. 1.3 Модели процесса разработки программного обеспечения Исторически в ходе развития теории проектирования программного обеспечения и по мере его усложнения утвердились четыре основные модели ЖЦ. Первой по времени появления и самой распространенной явилась каскадная модель (рисунок 1.1).  Рисунок 1.1 – Каскадная модель жизненного цикла ПО Каскадная модель характеризуется следующими основными особенностями: последовательным выполнением входящих в ее состав этапов; окончанием каждого предыдущего этапа до начала последующего; отсутствием временного перекрытия этапов (последующий этап не начнется, пока не завершится предыдущий); отсутствием (или определенным ограничением) возврата к предыдущим этапам; наличием результата только в конце разработки. Выявление и устранение ошибок в каскадной модели производится только на стадии тестирования, которая может растянуться во времени или вообще никогда не завершиться. Следующей стадией развития теории проектирования ПО стала итерационная модель ЖЦ, или так называемая поэтапная модель с промежуточным контролем (рисунок. 1.2). Основной ее особенностью является наличие обратных связей между этапами, вследствие этого появляется возможность проведения проверок и корректировок проектируемой ИС на каждой стадии разработки. В результате трудоемкость отладки по сравнению с каскадной моделью существенно снижается. Итерационность модели проявляется в обработке ошибок, выявленных промежуточным контролем. Если на каком-либо этапе в ходе промежуточной проверки обнаружена ошибка, допущенная на более ранней стадии разработки, необходимо повторить весь цикл работ этой стадии. При этом анализируются причины ошибки и корректируются в случае необходимости исходные данные этапа или его содержание (последовательность действий).  Рисунок 1.2 - Итерационная модель жизненного цикла ПО К сожалению, в процессе разработки системы могут измениться начальные требования, и в этом случае итерационная модель может оказаться неэффективной.  Рисунок 1.3 – Спиральная модель жизненного цикла ПО Третья модель ЖЦ ПО — спиральная (spiral) модель (рисунок 1.3) — поддерживает итерации поэтапной модели, но особое внимание уделяется начальным этапам проектирования: анализу требований, проектированию спецификаций, предварительному проектированию и детальному проектированию. Каждый виток спирали соответствует поэтапной модели создания фрагмента или версии ПО, уточняются цели и требования к про грамм ному обеспечению, оценивается качество разработанного фрагмента или версии и планируются работы следующей стадии разработки (витка). Таким образом, углубляются и конкретизируются все детали проектируемого ПО, в результате получается продукт, который удовлетворяет всем требованиям заказчика. RationalObjectoryProcess— модель жизненного цикла (методология объектно-ориентированного программирования) Известно, что объектно-ориентированное проектирование программного обеспечения стало результатом появления объектно-ориентированного программирования (ООП), т. е. применение новой методологии, как псегда1, началось с этапа кодирования. Ранние стадии описания предметной области и разработки архитектуры системы не поддерживались, первые варианты использования объектно-ориентированной методологии в большей степени являлись чистым повторением принципов ООП. Такие вопросы» как декомпозиция предметной области, спецификация требований, интерфейс пользователя, не рассматривались, однако успехи объектно-ориентированного программирования заставили распространить новую технологию на весь жизненный цикл ПО. В результате все преимущества подхода применяются не только в процессе кодирования, но и на более ранних этапах. Таким образом, были определены основные компоненты методологии: модель жизненного цикла; действия; нотация языка. Жизненныйцикл UML (Rational Objectory Process) Фирма Rational Software, разработавшая язык UML (Unified Modeling Language — унифицированный язык моделирования), предложила также и свою модель ЖЦ, которая называется Rational Objcctory Process (ROP). Означенная технология прямого перс-вода не имеет, так как rational в данном случае употребляется в значении «рациональный» и как название фирмы одновременно, во-вторых, слова objectory в английском языке не существует, его лингвообразованис аналогично слову repository (накопитель). Перечислим основные свойства ROP-технологии. Rational Objectory Process — итеративный процесс, в течение которого происходит последовательное уточнение результатов. Rational Objectory Process направлен именно на создание моделей, а не на разработку каких-либо других элементов проекта (например, текстовых документов). Действия Rational Objectory Process определяются в первую очередь блоками использования (use case) (рисунок 1.4).  Рисунок 1.4 – Молель жизненного цикла UML Rational Objectory Process разбит на циклы, каждый из которых, в свою очередь, состоит из четырех фаз: начальная стадия (Inception); разработка (Elaboration); конструирование (Construction); ввод в эксплуатацию (Transition). Результатом работы каждого такого цикла является своя версия программной системы. Каждая стадия завершается в четко определенной контрольной точке (milestone). В этот момент времени должны достигаться важные результаты и приниматься критически важные решения о дальнейшей разработке. Начальная стадия может принимать множество разных форм. Для крупных проектов — это всестороннее изучение всех возможностей реализации на протяжении нескольких месяцев. Здесь же вырабатывается бизнес-план проекта, определяется его стоимость, примерный доход, а также ограничения ресурсов — иными словами, выполняется некоторый начальный анализ оценки проекта. Окончанием начального этапа могут служить следующие результаты: начальный проектный словарь терминов; общее описание системы — основные требования к проекту, его характеристики и ограничения; начальная модель вариантов использования; начальный бизнес-план; план проекта, отражающий стадии и итерации; один или несколько прототипов. На стадии разработки выявляются более детальные требования к системе, выполняется высокоуровневый анализ предметной области и проектирование базовой архитектуры системы, создается план конструирования и устраняются наиболее рискованные элементы проекта. Самым важным результатом стадии разработки является описание базовой архитектуры будущей системы. Эта архитектура включает: модель предметной области, которая служит отправным пунктом для формирования основных абстракций предметной области; технологическую платформу, определяющую основные элементы технологии реализации системы и их взаимодействие. Стадия разработки занимает примерно пятую часть времени создания проекта, результатом которой являются: оценка времени реализации каждого варианта использования; идентификация всех наиболее серьезных рисков и возможности их ликвидации. Сущность стадии конструирования заключается в определении последовательности итераций конструирования и вариантов использования, реализуемых на каждой итерации, которые являются одновременно инкрементными и повторяющимися. При этом необходимо отмстить следующее: итерации являются инкрементными в соответствии с выполняемой функцией. Каждая итерация добавляет очередные конструкции к вариантам использования, реализованным во время предыдущих итераций; итерации являются повторяющимися по отношению к разрабатываемому коду. На каждой итерации некоторая часть существующего кода переписывается с целью сделать его более гибким. Результатом стадии конструирования является продукт, готовый к передаче пользователям и содержащий, как правило, руководство пользователей и готовый к интеграции на требуемых платформах. Назначением стадии ввода в эксплуатацию является передача готового продукта в полное распоряжение конечных пользователей. Данная стадия включает: бета-тестирование, позволяющее убедиться, что новая система соответствует ожиданиям пользователей; параллельное функционирование с существующей (legacy) системой, которая подлежит постепенной замене; оптимизацию производительности; обучение пользователей и специалистов службы сопровождения. |