4625

Технология разработки программных средств

Реферат

Информатика, кибернетика и программирование

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

Русский

2012-11-23

229 KB

94 чел.

Технология разработки программных средств

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


Водная часть.

Несмотря на то, что Программирование в последние 20-30 лет претерпело огромнейшие изменения: от применения в машинных кодах до объектно-ориентированных языков типа VB и Delphi в ближайшие годы вряд ли стоит ожидать переход к каким-либо другим (интеллектуальным)  способам решения задач на ЭВМ.

Вам придется не только работать на готовых программных средствах, но и разрабатывать свои программы или программные комплексы. При разработке программных средств (ПС) потребуется и умения использовать  так называемые программные инструменты для разработки ПС.

Основная часть

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

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

Определение: ЖЦПО - период времени, который начинается с момента принятия решения о необходимости создания ПО и заканчивается в момент его полного изъятия из эксплуатации.

Основным нормативным документом, регламентирующим состав процессов ЖЦ ПО, является международный стандарт ISO/IEC 12207:1995 «Information Technology - Software Life Cycle Processes».

Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО (его российский аналог ГОСТ Р ИСО/МЭК 12207—99 введен в действие в июле 2000 г.). В данном стандарте процесс определяется как совокупность взаимосвязанных действий, преобразующих некоторые входные данные в выходные. Каждый процесс характеризуется определенными задачами и методами их решения, исходными данными, полученными от других процессов, и результатами.

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

В соответствии со стандартом ГОСТ Р ИСО/МЭК 12207-99 все процессы ЖЦ ПО разделены на три группы (рис. 1.).

пять основных процессов (приобретение, поставка, разработка, эксплуатация, сопровождение);

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

четыре организационных процесса (управление, инфраструктура, усовершенствование, обучение).

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

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

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

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

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

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

  1.  редакторы,
  2.  анализаторы,
  3.  преобразователи,
  4.  инструменты,

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

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

На этапе программирования (кодирования) вместо текстового редактора может оказаться более удобным синтаксически управляемый редактор, ориентированный на используемый язык программирования.

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

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

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

Примером такого инструмента является эмулятор кода другого компьютера. К этой группе инструментов следует отнести и различные отладчики.

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

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

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

Часто разработка ПС производится на том же компьютере, на котором оно будет применяться. Это достаточно удобно.

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

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

В таких случаях применяется так называемый инструментально-объектный подход [1]. Сущность его заключается в том, что ПС разрабатывается на одном компьютере, называемым инструментальным, а применяться будет на другом компьютере, называемым целевым (или объектным).

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

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

  1.   ориентированность на конкретный язык программирования,
  2.   специализированность,
  3.   комплексность,
  4.   ориентированность на конкретную технологию программирования,
  5.   ориентированность на коллективную разработку,
  6.   интегрированность.

Ориентированность на конкретный язык программирования (языковая ориентированность) показывает: ориентирована ли среда на какой-либо конкретный язык программирования (и на какой именно) или может поддерживать программирование на разных языках программирования.

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

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

Комплексность инструментальной среды показывает: поддерживает ли она все процессы разработки и сопровождения ПС или нет. В первом случае продукция этих процессов должна быть согласована. Поддержка инструментальной средой фазы сопровождения ПС, означает, что она должна поддерживать работу сразу с несколькими вариантами ПС, ориентированными на разные условия применения ПС и на разную связанную с ним аппаратуру, т.е. должна обеспечивать управление конфигурацией ПС [ 1, 3].

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

Ориентированность на коллективную разработку показывает: поддерживает ли среда управление (management) работой коллектива или нет. В первом случае она обеспечивает для разных членов этого коллектива разные права доступа к различным фрагментам продукции технологических процессов и поддерживает работу менеджеров [ 1] по управлению коллективом разработчиков. Во втором случае она ориентирована на поддержку работы лишь отдельных пользователей.

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

  1.  интегрированность по пользовательскому интерфейсу,
  2.  интегрированность по данным,
  3.  интегрированность по действиям (функциям),

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

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

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

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

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

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

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

Рис.  1. Основные классы инструментальных сред разработки и сопровождения ПС.

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

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

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

Оно существенно использует свойства специализированности, ориентированности на конкретную технологию программирования и, как правило, интегрированности.

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

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

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

3 Компьютерная технология (CASE-технология) разработки программных средств и ее рабочие места

3.1 Общие положения CASE-технологий

За последние десятилетия сформировалось новое направление в программотехнике — CASE (Computer-Aided Software/System Engineering), в дословном переводе — разработка ПО И С при поддержке (с помощью) компьютера. В настоящее время не существует общепринятого определения CASE, этот термин используется в весьма широком смысле.

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

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

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

CASE-технологии успешно применяются для построения практически всех типов систем ПО, однако устойчивое положение они занимают в следующих областях:

обеспечение разработки делового и коммерческого ПО —
широкое применение
CAS Е-технологий обусловлено массовостью
этой прикладной области, в которой
CASE применяется не толь
ко для разработки ПО, но и для создания моделей систем, помогающих решать задачи стратегического планирования, управления
финансами, определения политики фирм, обучения персонала и
др. (это направление получило свое собственное название — бизнес-анализ);

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

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

С самого начала CASE-технологии развивались с целью преодоления ограничений при использовании структурных методологий проектирования 60 —70-х гг. прошлого века (сложности понимания, большой
трудоемкости и стоимости использования.

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

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

улучшают качество создаваемого ПО за счет средств автоматического контроля (прежде всего, контроля проекта);

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

ускоряют процесс проектирования и разработки;

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

поддерживают развитие и сопровождение разработки;

• поддерживают технологии повторного использования компонентов разработки.

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

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

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

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

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

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

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

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

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

интерпретирующие среды,

синтаксически-управляемые среды.

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

4.Общая архитектура инструментальных систем технологии программирования

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

В действительности, в это понятие вкладывается более узкий (специальный) смысл, который постепенно размывается (как это всегда бывает, когда какое-либо понятие не имеет строгого определения). Первоначально под CASE понималась [ 4] инженерия ранних этапов разработки ПС (определение требований, разработка внешнего описания и архитектуры ПС) с использованием программной поддержки (программных инструментов).

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

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

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

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

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

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

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

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

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

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

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

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

Рис.  3. Жизненный цикл программного средства для компьютерной технологии.

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

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

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

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

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

Генерация программ ПС. На этом этапе автоматически генерирует скелеты кодов программ ПС или полностью коды этих программ по формальным спецификациям ПС.

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

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

Аттестация ПС имеет прежнее содержание.

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

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

  •  конструкторы пользовательских интерфейсов;
  •  инструмент работы со словарем именованных сущностей;
  •  графические и тестовые редакторы спецификаций;
  •  анализаторы спецификаций;
  •  генератор программ;
  •  документаторы.

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

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

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

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

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

интерфейсы.

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

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

Самая общая архитектура инструментальных систем  технологии программирования представлена на рис.  4.

Рис.  4. Общая архитектура инструментальных систем технологии программирования.

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

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

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

Литература

1. Ian Sommerville. Software Engineering. - Addison-Wesley Publishing Company, 1992. P. 349-369.

2. Е.А. Жоголев. Введение в технологию программирования (конспект лекций). - М.: "ДИАЛОГ-МГУ", 1994.

3. М.М. Горбунов-Посадов. Конфигурации программ. Рецепты безболезненных изменений. – М.: «Малип», 1994.

4. CASE:  Компьютерное проектирование программного обеспечения. - Издательство Московского университета, 1994.

 5. Requirements for Ada Programming Support Environments. - USA: DoD, Stoneman, 1980.


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

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

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

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

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

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

Языково-ориентированные среды

Интерпретирующие среды

Синтаксически-управляемые среды

Прототипирование ПС

Разработка спецификаций ПС

Автоматизированный контроль спецификаций ПС

Генерация программ

ПС

Автоматизированное документирование ПС

Комплексное тестирование и отладка ПС

Аттестация ПС

Сопровождение ПС

Применение ПС

ЯДРО

Системный интерфейс

ИМПОРТИРОВАННЫЕ ИНСТРУМЕНТЫ

ВСТРОЕННЫЕ ИНСТРУМЕНТЫ

ВНЕШНИЕ

ИНСТРУМЕНТЫ

О Б О Л О Ч К А

Пользовательский интерфейс

РЕПОЗИТОРИЙ

ФАЙЛЫ


 

А также другие работы, которые могут Вас заинтересовать

74773. Колебания, виды колебаний, характеристики, энергия колебания. Гармонические колебания. Примеры (маятники) 97.5 KB
  Колебательные процессы широко распространены в природе и технике например качание маятника часов переменный электрический ток и т. При колебательном движении маятника изменяется координата его центра масс в случае переменного тока колеблются напряжение и ток в цепи.
74774. Затухающие колебания и их характеристики. Декремент затухания 35 KB
  Простейшим механизмом уменьшения энергии колебаний является ее превращение в теплоту вследствие трения в механических колебательных системах а также омических потерь и излучения электромагнитной энергии в электрических колебательных системах.
74775. Вынужденные колебания. Уравнение, характеристики. Резонанс. Примеры 58.96 KB
  Колебания, совершающиеся под воздействием внешней периодической силы, Внешняя сила совершает положительную работу и обеспечивает приток энергии к колебательной системе. Она не дает колебаниям затухать, несмотря на действие сил трения.
74776. Сложение одинаково направленных колебаний. Биение. Примеры 54.5 KB
  Колеблющееся тело может участвовать в нескольких колебательных процессах тогда необходимо найти результирующее колебание иными словами колебания необходимо сложить. Сложим гармонические колебания одного направления и одинаковой частоты воспользовавшись методом вращающегося...