План лекции Предварительные замечания > Эволюция разработки программного обеспечения Предварительные замечания icon

План лекции Предварительные замечания > Эволюция разработки программного обеспечения Предварительные замечания


Смотрите также:
План лекции Предварительные замечания Введение Генезис современного российского капитализма:...
Литература
Моделирование требований к системе 29...
Предварительные замечания...
Предварительные замечания...
Предварительные замечания...
А. И. Яковлев Предварительные замечания...
Общая характеристика лекций Замечания по лекциям каждого преподавателя > Общие замечания и...
Доклад посвящен применению теории сетей Петри для моделирования процессов разработки...
«Компетенции членов команды разработки программного обеспечения»...
«Техническое задание»...
Современная концепция образовательной области «искусство» в школе Предварительные замечания...



Загрузка...
страницы: 1   2   3   4   5   6   7   8   9   10   11
вернуться в начало
скачать
^

Лекция 9. ИНСТРУМЕНТАЛЬНЫЕ И ЯЗЫКОВЫЕ СРЕДСТВА ПОДДЕРЖКИ И АВТОМАТИЗАЦИИ ПРОЕКТИРОВАНИЯ ПРОГРАММНЫХ СИСТЕМ


План лекции

1. ПРЕДВАРИТЕЛЬНЫЕ ЗАМЕЧАНИЯ

2. ПОДДЕРЖКА ПРОЦЕССА ЖИЗНЕННОГО ЦИКЛА ПС С ПОМОЩЬЮ МЕТОДОВ МОДЕЛИРОВАНИЯ

^

3. ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА АВТОМАТИЗАЦИИ РАЗРАБОТКИ ПС


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

1. ПРЕДВАРИТЕЛЬНЫЕ ЗАМЕЧАНИЯ


В настоящее время существуют несколько сред программирования «под Windows», использующих объектно-ориентированный подход и включающих мощные библиотеки объектов. В качестве примеров можно назвать среды разработки Visual C++, Delphi, C++Builder, которые позволяют сравнительно легко создавать сложнейшие приложения Windows. Эти пакеты автоматизируют многие операции создания приложения, предлагая разработчику большое количество различных шаблонов и заготовок, начиная от заготовки будущего приложения.

Примечание. Visual C++ является наиболее универсальным из названных трех пакетов, но и, соответственно, самым сложным. Он использует развитую объектную модель C++ и имеет более мощную по сравнению с Delphi и C++Builder библиотеку объектов. Интерфейс и средства Visual C++ ориентированы на профессиональные разработки высокого уровня и далее в настоящем курсе рассматриваться не будут.

Delphi и C++Builder используют идентичные среды и одну и ту же библиотеку объектов VCL (Visual Component Library - библиотека визуальных компонент). Практически эти среды различаются только языком разработки: Delphi использует язык на основе Object Pascal, a C++Builder, как указано в названии, C++. Используемые объектные модели также во многом похожи.
^

2. ПОДДЕРЖКА ПРОЦЕССА ЖИЗНЕННОГО ЦИКЛА ПС С ПОМОЩЬЮ МЕТОДОВ МОДЕЛИРОВАНИЯ


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

3. Инструментальные средства разработки и сопровождения программных средств


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

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

* редакторы,

* анализаторы,

* преобразователи,

* инструменты, поддерживающие процесс выполнения программ.


^ 16.2. Инструментальные среды разработки и сопровождения программных средств и принципы их классификации.

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

Часто разработка ПС производится на том же компьютере, на котором оно будет применяться. Это достаточно удобно. Во-первых, в этом случае разработчик имеет дело только с компьютерами одного типа. А, во-вторых, в разрабатываемое ПС могут включаться компоненты самой инструментальной среды. Однако, это не всегда возможно. Например, компьютер, на котором должно применяться ПС, может быть неудобен для поддержки разработки ПС или его мощность недостаточна для обеспечения функционирования требуемой инструментальной среды. Кроме того, такой компьютер может быть недоступен для разработчиков этого ПС (например, он постоянно занят другой работой, которую нельзя прерывать, или он находится еще в стадии разработки). В таких случаях применяется так называемый инструментально-объектный подход. Сущность его заключается в том, что ПС разрабатывается на одном компьютере, называемым инструментальным, а применяться будет на другом компьютере, называемым целевым (или объектным).

Инструментальная среда не обязательно должна функционировать на том компьютере, на котором должно будет применяться разрабатываемое с помощью ее ПС.

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

* ориентированность на конкретный язык программирования,

* специализированность,

* комплексность,

* ориентированность на конкретную технологию программирования,

* ориентированность на коллективную разработку,

* интегрированность.

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

^ 16.3. Основные классы инструментальных сред разработки и сопровождения программных средств.

В настоящее время выделяют три основных класса инструментальных сред разработки и сопровождения ПС:

* инструментальные среды программирования,

* рабочие места компьютерной технологии,

* инструментальные системы технологии программирования.

16.3. Инструментальные среды программирования.

Инструментальная среда программирования включает, прежде всего, текстовый редактор, позволяющий конструировать программы на заданном языке программирования, а также инструменты, позволяющие компилировать или интерпретировать программы на этом языке, тестировать и отлаживать полученные программы. Различают следующие классы инструментальных сред программирования:

* среды общего назначения,

* языково-ориентированные среды.


^ 16.4. Понятие компьютерной технологии разработки программных средств и ее рабочие места.

Имеются некоторые трудности в выработке строгого определения CASE-технологии (компьютерной технологии разработки ПС). CASE - это абревиатура от английского Computer-Aided Software Engineering (Компьютерно-Помогаемая Инженерия Программирования). Под CASE может пониматься и инженерия всего жизненного цикла ПС (включая и его сопровождение), но только в том случае, когда программы частично или полностью генерируются по документам, полученным на указанных ранних этапах разработки. В этом случае CASE-технология стала принципиально отличаться от ручной (традиционной) технологии разработки ПС: изменилось не только содержание технологических процессов, но и сама их совокупность.

В настоящее время компьютерную технологию разработки ПС можно характеризовать использованием

* программной поддержки для разработки графических требований и графических спецификаций ПС,

* автоматической генерации программ на каком-либо языке программирования или в машинном коде (частично или полностью),

* программной поддержки прототипирования.

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

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

^ 14.5. Инструментальные системы технологии программирования.

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

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

* репозиторий,

* инструментарий,

* интерфейсы.

Инструментарий - набор инструментов, определяющий возможности, предоставляемые системой коллективу разработчиков..

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

Различают два класса инструментальных систем технологии программирования: инструментальные системы поддержки проекта и языково-зависимые инструментальные системы.

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

Языково-зависимая инструментальная система - это система поддержки разработки ПС на каком-либо одном языке программирования, существенно использующая в организации своей работы специфику этого языка.
^

Лекция 10. Документирование программных средств

1. Документация, создаваемая и используемая в процессе разработки программных средств.


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

Эту документацию можно разбить на две группы:

* Документы управления разработкой ПС.

* Документы, входящие в состав ПС.

Документы управления разработкой ПС (software process documentation) управляют и протоколируют процессы разработки и сопровождения ПС, обеспечивая связи внутри коллектива разработчиков ПС и между коллективом разработчиков и менеджерами ПС (software managers) - лицами, управляющими разработкой ПС. Эти документы могут быть следующих типов:

* Планы, оценки, расписания. Эти документы создаются менеджерами для прогнозирования и управления процессами разработки и сопровождения ПС.

* Отчеты об использовании ресурсов в процессе разработки. Создаются менеджерами.

* Стандарты. Эти документы предписывают разработчикам, каким принципам, правилам, соглашениям они должны следовать в процессе разработки ПС. Эти стандарты могут быть как международными или национальными, так и специально созданными для организации, в которой ведется разработка ПС.

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

* Заметки и переписка. Эти документы фиксируют различные детали взаимодействия между менеджерами и разработчиками.

Документы, входящие в состав ПС (software product documentation), описывают программы ПС как с точки зрения их применения пользователями, так и с точки зрения их разработчиков и сопроводителей (в соответствии с назначением ПС). Здесь следует отметить, что эти документы будут использоваться не только на стадии эксплуатации ПС (в ее фазах применения и сопровождения), но и на стадии разработки для управления процессом разработки (вместе с рабочими документами) - во всяком случае, они должны быть проверены (протестированы) на соответствие программам ПС. Эти документы образуют два комплекта с разным назначением:

* Пользовательская документация ПС (П-документация).

* Документация по сопровождению ПС (С-документация).
^

2. Пользовательская документация программных средств.


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

В связи с этим следует различать две категории пользователей ПС: ординарных пользователей ПС и администраторов ПС. Ординарный пользователь ПС (end-user) использует ПС для решения своих задач (в своей предметной области). Это может быть инженер, проектирующий техническое устройство, или кассир, продающий железнодорожные билеты с помощью ПС. Он может и не знать многих деталей работы компьютера или принципов программирования. Администратор ПС (system administrator) управляет использованием ПС ординарными пользователями и осуществляет сопровождение ПС, не связанное с модификацией программ. Например, он может регулировать права доступа к ПС между ординарными пользователями, поддерживать связь с поставщиками ПС или выполнять определенные действия, чтобы поддерживать ПС в рабочем состоянии, если оно включено как часть в другую систему.

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

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

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

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

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

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

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

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

3. Документация по сопровождению программных средств.

Документация по сопровождению ПС (system documentation) описывает ПС с точки зрения ее разработки. Эта документация необходима, если ПС предполагает изучение того, как оно устроена (сконструирована), и модернизацию его программ. Как уже отмечалось, сопровождение - это продолжающаяся разработка. Поэтому в случае необходимости модернизации ПС к этой работе привлекается специальная команда разработчиков-сопроводителей. Этой команде придется иметь дело с такой же документацией, которая определяла деятельность команды первоначальных (основных) разработчиков ПС, - с той лишь разницей, что эта документация для команды разработчиков-сопроводителей будет, как правило, чужой (она создавалась другой командой). Чтобы понять строение и процесс разработки модернизируемого ПС, команда разработчиков-сопроводителей должна изучить эту документацию, а затем внести в нее необходимые изменения, повторяя в значительной степени технологические процессы, с помощью которых создавалось первоначальное ПС.

Документация по сопровождению ПС можно разбить на две группы:

1. документация, определяющая строение программ и структур данных ПС и технологию их разработки;

2. документацию, помогающую вносить изменения в ПС.

Документация первой группы содержит итоговые документы каждого технологического этапа разработки ПС. Она включает следующие документы:

* Внешнее описание ПС (Requirements document).

* Описание архитектуры ПС (description of the system architecture), включая внешнюю спецификацию каждой ее программы (подсистемы).

* Для каждой программы ПС - описание ее модульной структуры, включая внешнюю спецификацию каждого включенного в нее модуля.

* Для каждого модуля - его спецификация и описание его строения (design description).

* Тексты модулей на выбранном языке программирования (program source code listings).

* Документы установления достоверности ПС (validation documents), описывающие, как устанавливалась достоверность каждой программы ПС и как информация об установлении достоверности связывалась с требованиями к ПС.

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

Документация второй группы содержит

* Руководство по сопровождению ПС (system maintenance guide), которое описывает особенности реализации ПС (в частности, трудности, которые пришлось преодолевать) и как учтены возможности развития ПС в его строении (конструкции). В нем также фиксируются, какие части ПС являются аппаратно- и программно-зависимыми.

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




оставить комментарий
страница11/11
Дата28.09.2011
Размер0,7 Mb.
ТипЛекция, Образовательные материалы
Добавить документ в свой блог или на сайт

страницы: 1   2   3   4   5   6   7   8   9   10   11
отлично
  2
Ваша оценка:
Разместите кнопку на своём сайте или блоге:
rudocs.exdat.com

Загрузка...
База данных защищена авторским правом ©exdat 2000-2017
При копировании материала укажите ссылку
обратиться к администрации
Анализ
Справочники
Сценарии
Рефераты
Курсовые работы
Авторефераты
Программы
Методички
Документы
Понятия

опубликовать
Загрузка...
Документы

наверх