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

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

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

CASE-средства. Характеристика современных CASE-средств

Обзор объектно-ориентированных инструментальных средств

Объектно-ориентированное программирование возникло раньше объектно-ориентированного анализа и проектирования, поэтому на сегодняшний день существует достаточно большое количество языков, поддерживающих данную технологию. Первым из них, по дате возникновения, считается язык Smalltalk , хотя многие элементы объектно-ориентированного подхода были использованы еще в языке Simula в 1967г. Наиболее мощным инструментом создания объектно-ориентированных программ на сегодня является язык C++ , созданный на базе языка структурного программирования C . Успешно развивается язык Java , который изначально разрабатывался как объектно-ориентированный.

Разработка крупных программных систем в современных условиях невозможна без использования средств автоматизации разработки программного обеспечения (CASE средств). CASE, поддерживающих объектно-ориентированный подход, не так много. Наиболее известное средство в этом направлении – система Rational Rose , которая поддерживает, в том числе, этапы объектно-ориентированного анализа и проектирования.

Объектно-ориентированное CASE средство Rational Rose

Разработчик Rational Rose - фирма Rational Software Corp., известная своими наработками в области объектно-ориентированных технологий, главной из которых является язык UML. Именно на поддержку UML, как основного языка проектирования ПО, и ориентированна данная CASE система.

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

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

Из основных возможностей можно перечислить следующие:

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

Удобная навигация между элементами модели при помощи "инспектора проекта".

Хранение результатов проектирования в виде единой модели.

Поддержка работы над проектом группы разработчиков.

Мощная система подготовки отчетов и документации о проекте.

Возможности синтеза программ практически на всех современных объектно-ориентированных языках, в том числе и на межплатформенном языке Java.

Поддержка компонентных технологий построения программных систем.

Широкие возможности по проектированию ПО различной архитектуры, от простых программ, до крупных "клиент-серверных" систем и Интернет-приложений.

Возможность реинжиниринга модели на основе исходных текстов программы. Этим обеспечивается поддержание единства проектной информации и реализации.

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

Принципы разработки программных систем в Rational Rose

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

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

На всех этапах предоставляется возможность применять специализированные графические редакторы элементов модели и использовать инспектор модели для навигации среди ее компонентов. Вся проектная информация сохраняется в едином файле модели (*.mdl).

Работа начинается с построения диаграммы использования (Use Case Diagram), характеризующей основные задачи и окружение проектируемой системы. Далее, для каждого блока использования (Use Case), представленного на диаграмме использования, разрабатываются диаграммы последовательностей (Sequence Diagram), идентифицирующие объекты в системе и описывающие последовательности событий, возникающих в процессе общения объектов. Rational Rose позволяет автоматически связывать диаграммы последовательностей с блоками использования.

Объекты, присутствующие на диаграммах последовательностей, определяются в системе с помощью классов. Классы и их взаимосвязь задается с помощью диаграмм классов, разработка которых также поддерживается Rational Rose . Классы группируются в пакеты. Rational Rose позволяет определить набор пакетов, взаимосвязи между ними и представить составляющие их классы на вложенных диаграммах классов.

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

Для полностью определенной модели можно осуществить генерацию исходных программных текстов на различных объектно-ориентированных языках программирования, поддерживаемых Rational Rose , например Java или C++.

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

Проектирование программных средств

Моделирование предметной области . Создание проекта начинается с формирования принципов использования системы. В рамках Rational Rose это этап именуется "Use Case View". Реализация этого этапа позволяет идентифицировать внешних пользователей, блоки использования, объекты системы и связи между ними.

Составляется диаграмма использования, отражающая внешнее функционирование создаваемой системы. Эта модель во многом аналогична диаграмме потоков данных в структурном анализ. Основными ее составляющими являются внешние пользователи (actors), блоки использования (use case) и связи между компонентами. Для создания диаграммы в Rational Rose используется специализированный графический редактор.

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

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

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

Разработка логической структуры. После завершения формирования принципов использования системы, наступает этап разработки ее логической структуры. В Rational Rose он именуется "Logical View". Результатом данного этапа должна стать главная диаграмма, и детализирующие диаграммы для ее элементов.

На этом этапе следует определить классы, которые необходимы в системе. Экземпляры этих классов уже указаны на диаграммах последовательностей. Классы и их связи отражается в модели в виде диаграммы классов. Группы классов на этих диаграммах могут быть объединены в пакеты.

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

Встроенный в Rational Rose редактор диаграмм классов представляет удобные средства для таких операций, а инспектор модели облегчает перемещение по иерархии диаграмм.

Для каждого класса задается спецификация, описывающая состав атрибутов и методов, связи, шаблон, на основе которого создан класс, и особенности реализации.

Наличие шаблонов позволяет легко создавать классы различной структуры.

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

Кроме диаграмм классов, для описания логики системы применяются на данном этапе применяются диаграммы состояний, диаграммы сценариев и другие элементы языка UML

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

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

Для визуализации компонентов проектируемой системы используются диаграммы компонент. Этап построения диаграмм компонент в Rose именуется "Component View". Он состоит из построения общей диаграммы и, при необходимости, детализации отдельных компонентов на вложенных диаграммах.

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

Построение диаграмм выполняется в специализированном редакторе. Для компонента задаются составляющие его классы.

Для компонента может производится генерация исходного текста на различных языках программирования, поддерживаемых Rational Rose, или назначаться программные фрагменты, разработанные вне среды Rose . В последнем случае их интерфейс должен соответствовать объявленному в модели.

Последним этапом в проектировании программного обеспечения является подготовка диаграммы развертывания. В Rose этот этап именуется "Deployment View". Диаграммы развертывания показывает конфигурацию исполняемой программной системы. Она состоит из узлов и отношений взаимодействия между узлами и компонентами. Узлы могут включать компоненты и объекты. Узлы являются физическими элементами времени выполнения.

Построение и сопровождение системы

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

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

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

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

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

Rational Rose 98 Enterprise Edition позволяет генерировать исходный текст на Visual Basic, C++, Java, а также получать описание интерфейсов компонент на языке IDL и создавать проекты для системы Oracle 8.

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

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

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

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

Поддержка этапов разработки

Компоненты и шаблоны. Одной из возможностей Rose является моделирование двоичных компонентов, поддерживающих спецификацию COM. В модели подобные компоненты представляются интерфейсными классами, созданными на основе IDL файлов, сопровождающих COM объект. Это позволяет включать в модель различные готовые компоненты.

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

Рабочие среды. Логичным развитием идеи использования шаблонов и внешних двоичных компонентов в Rational Rose стало появление рабочей среды (Framework).

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

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

Среда проектирования распределенных приложений (Application Performance Explorer)

Стандартная среда (Standard). Ориентированна на создание приложений на Visual Basic. Включает объявление многих стандартных объектов VB.

Среда проектирования приложений для Интернет (Internet). Включает определение различных компонентов ActiveX и библиотек VB.

Среда проектирования приложений для работы с локальными базами данных (Local Database). Содержит объявление объектов системы DAO

Среда проектирования приложений с использованием RDO (Remote Data Object). Позволяет использовать объекты RDO для создания клиент-серверных приложений.

Среда проектирования приложений для доступа к SQL-серверами (SQL Server Distributed Management Object (SQL-DMO)), поддерживающая доступ к SQL через объекты OLE-Automation.

Среда поддержки Microsoft Transaction Server

Среда поддержки Microsoft Outlook

Среды проектирования приложений на Java (Java JDK 114 Full и Java JDK 114 Quick). Включают модели классов и интерфейсов Java полученные путем реинжиниринга.

Среда поддержки Oracle8

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

Среды разработки представляют собой замечательный механизм для настройки Rose на конкретный проект. Можно создать собственную среду разработки, которая будет включать необходимые вам элементы из различных стандартных сред. В состав Rational Rose входит "мастер" по созданию рабочих сред.

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

Наряду с удобным средством инспектирования модели, облегчающим переключение между этапами, в Rational Rose определены механизмы поддержки группы разработчиков.

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

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

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

Добавление необходимых расширений обычно производится при начальной установки системы, однако их можно установить и позднее. Поддерживается распространение расширений через сеть Internet

Для управления расширениями в Rose существует менеджер расширений. С его помощью можно активизировать и де активизировать различные модули расширений.

Достоинства и недостатки Rational Rose

Данное CASE средство может быть применено для создания разнообразного объектно-ориентированного программного обеспечения, в первую очередь для платформы Windows, а так же на межплатформенном языке Java.

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

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

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

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

Введение

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

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

Этапы, роли, инструменты…

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

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

Определение требований

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

Какие инструменты требуются бизнес-аналитику? Потребность в инструментах определяется масштабом проекта, требованиями заказчика к оформлению документации, стандартами, принятыми в той или иной компании-разработчике. Бизнес-аналитик может обойтись и текстовым процессором (например, Microsoft Word), изложив требования в виде текста. Однако в последнее время описание требований принято иллюстрировать UML- и IDEF0-диаграммами, описывающими сценарии взаимодействия пользователя с продуктом, порядок передачи сообщений от одних объектов к другим, взаимодействие объектов друг с другом, потоки работ и изменение состояний объектов. Для создания таких диаграмм можно применять Microsoft Visio, Rational Rose, Rational XDE, Borland Together, для создания диаграмм в стандарте IDEF0 наиболее активно используется CA AllFusion Process Modeler (ранее носивший название BPwin).

Какой именно инструмент подходит для данного проекта, во многом зависит от постановки процессов разработки. Если бизнес-аналитику нужно только проиллюстрировать проектную документацию, то выбор инструмента не принципиален - лишь бы можно было нарисовать с его помощью ту или иную диаграмму. Если же бизнес-аналитик должен не просто сделать иллюстрацию, а создать модель для последующего использования системными аналитиками, разработчиками и специалистами по тестированию на последующих этапах проекта, то выбор инструмента определяется его способностью к интеграции со средствами разработки, которые со значительной степенью вероятности будут использоваться в качестве инструментария реализации кода. Из наиболее технологически совершенных современных пар «средство разработки - средство моделирования» стоит отметить такие, как Visual Studio .NET - Rational XDE, Visual Studio .NET - Borland Together, Borland JBuilder - Borland Together.

Помимо текстовых редакторов и средств моделирования, бизнес-аналитики могут применять средства управления требованиями, позволяющие хранить структурированный и систематизированный список требований к продукту в какой-либо базе данных и обращаться к нему на последующих этапах, связывая требования с реализующими их составными частями продукта и тестами, проверяющими соответствие продукта требованиям, а также корректно отслеживать изменения в требованиях, которые возникают практически в каждом проекте, как бы тщательно ни проводилось исследование, и влияние этих изменений на результаты последующей работы. Из наиболее известных сегодня средств управления требованиями следует отметить RequisitePro (IBM/Rational), DOORS (Telelogic) и CaliberRM (Borland). Собственно, при надлежащей организации процесса разработки и при наличии необходимых шаблонов техническое задание можно сгенерировать с помощью средства управления требованиями и даже соблюсти при этом требования российских государственных стандартов.

Типичный интерфейс средства управления требованиями (Borland Caliber RM)

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

Проектирование

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

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

Какие инструменты применяются на этом этапе? Для создания диаграмм классов и диаграмм развертывания используются вышеперечисленные инструменты UML-моделирования. Для проектирования данных обычно применяют такие инструменты, как CA AllFusion Data Modeler (бывший ERwin), Sybase Power Designer, Oracle Designer, а также аналогичные инструменты компаний Embarcadero и Popkin Software. Для СУБД, разработанных компанией Microsoft, можно достаточно успешно применять и Microsoft Visio. Перечисленные инструменты позволяют создать как минимум скрипт для генерации базы данных, а различия между ними заключаются в способах управления генерацией серверного кода, связанного с созданием триггеров и хранимых процедур.

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

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

Таким образом, на этапе проектирования нужны средства моделирования и проектирования данных и UML-моделирования, а в некоторых случаях - средства создания изображений форм.

Разработка продукта

На этапе собственно разработки создается код приложения в соответствии с техническим проектом, в том числе и серверный код, реализующий функциональность, отсутствующую в модели данных. На этом этапе основным инструментом, обязательным к применению, является средство разработки приложений. Выбор средства разработки определяется в первую очередь платформой (Windows, .NET, Java/J2EE, Linux/UNIX) и архитектурой (приложения с графическим интерфейсом, консольные приложения и службы, Web-приложения) и в настоящее время достаточно разнообразен. Средства разработки Java/J2EE-приложений производят компании IBM, Oracle, Borland, средства разработки Windows-приложений - Microsoft, Borland, Sybase, средства разработки.NET-приложений - Microsoft и Borland, средства разработки приложений для Linux - Borland и некоторые другие компании.

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

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

На этапе разработки приложения средства моделирования тоже применяются, особенно в том случае, когда они могут осуществлять не только генерацию кода на различных языках программирования, но и поддерживать обратное проектирование, создавая диаграмму классов на основе готового приложения либо позволяя синхронно редактировать и код, и модель. Функция синхронного изменения кода и модели существенно упрощает многие процессы, сопровождающие собственно разработку, так что если есть возможность выбора инструментов, то стоит обратить внимание на ее поддержку (например, синхронное изменение кода и модели поддерживают некоторые редакции инструмента UML-моделирования Borland Together).

Нередко на этапе создания приложений применяются средства оптимизации кода и его отладки. Такие инструменты могут входить в состав средств разработки или поставляться отдельно.

Тестирование и оценка качества

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

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

Основными производителями средств тестирования в настоящее время являются компании Compuware, Segue, Mercury Interactive, IBM/Rational, Borland. Каждая из них производит несколько инструментов автоматизированного тестирования, включая средства нагрузочного тестирования, проверки пользовательских интерфейсов, тестирования ошибок исполнения.

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

Если приложение предназначено для работы под управлением различных операционных систем и их языковых версий (например, разных 32-разрядных версий и редакций Microsoft Windows), то специалистам по тестированию могут пригодиться средства создания виртуальных машин, позволяющие иметь на одном компьютере несколько различных операционных систем, загруженных одновременно, и организовывать между ними сетевое взаимодействие (о продуктах данной категории мы планируем рассказать в отдельной статье). Из ПО такого класса широко распространены продукты компаний Microsoft и VMWare. При тестировании программ для установки приложений могут применяться также средства резервного копирования и восстановления образов жестких дисков, выпускаемые компаниями Symantec, PowerQuest и др.

Документирование

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

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

На основе руководства пользователя с помощью специальных инструментов обычно генерируются файлы справочной системы. В простейшем случае файл справочной системы можно создать с помощью Microsoft Word и утилит от Microsoft для создания help-файлов, включаемых в состав многих средств разработки, но при большом объеме работы нередко используются специализированные средства таких компаний, как Blue Sky Software, EC Software, JGsoft.

Внедрение и сопровождение

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

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

Коллективная разработка и управление проектом

Если над какой-либо частью проекта работает более одного человека, полезными при разработке могут оказаться средства контроля версий (наиболее популярными из них являются Merant PVCS Version Manager и Microsoft Visual SourceSafe). Нередко их применяют при создании не только кода приложения, но и документов (например, технического задания) либо моделей. В крупных проектах часто используются и средства управления изменениями. Подобные продукты позволяют хранить в единой базе данных все составные части проекта и их версии и упрощают управление версиями кода, моделей, требований, а также дают возможность отслеживать влияние изменений в одной части проекта на остальные его части. Из самых популярных сегодня средств управления изменениями следует отметить продукты компаний Borland и IBM/Rational.

Ни один проект не обходится без человека, несущего за него ответственность и осуществляющего планирование деятельности всех специалистов и управление всеми процессами разработки. Хотя планировать работу можно и на бумаге, но в последнее время основным инструментом руководителя проекта (а в крупных проектах - менеджеров, отвечающих за составные части проекта) служит какое-либо специализированное средство управления проектами. Лидером среди продуктов данной категории является семейство продуктов Microsoft Project.

Пример плана проекта разработки программного продукта (Microsoft Project)

Заключение

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

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

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

оригинальное программирование;

использование пакетов прикладных программ – типовые программы, реализующие функции обработки данных;

автоматизацию основных этапов разработки программ.

Наиболее традиционными средствами разработки являются языки и системы программирования. Языки программирования принято делить на машинные и алгоритмические языки.

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

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

Машинно -ориентированные языки программирования являются языками низкого уровня, поскольку они учитывают архитектуру и тип компьютеров. Программирование на таких языках трудоемко, но программы оптимальны с точки зрения потребных ресурсов компьютера. Примеры машинно-ориентированных языков программирования - различные ассемблеры 1 (Macro Assembler, Turbo Assembler и др.) определенного класса компьютеров.

Процедурно -ориентированные языки программирования, такие как Visual Basic, Pascal, C++, Ada, Cobol, PL1 и др. позволяют описать набор процедур обработки, реализуют типовые вычислительные структуры:

1. Последовательности блоков (инструкций): 1, 2, 3, 4 и т.д.

Все блоки (инструкции) выполняются в строгой последовательности (Рис.5 А)

2. Условный переход (Рис.5 Б) – проверка заданного условия (2) и выбор альтернативного действия: если условие истинно – 3, иначе - 4. После этого управление передается блоку 5.

3. Альтернативный выбор (Рис.5 В) – проверка условия (2), если условие истинно – выполнение действия 3, иначе проверка условия (4); если условие истинно – выполнение действия 5 и т.д. Если не выполнилось ни одного условия или выполнились действия (3 или 5 и т.п.), управление передается блоку 6.

А Б В

Рисунок 5

4. Циклический процесс – цикл «пока» (Рис. 6А). Цикл повторяется, пока истинно условие (2) – блок 3. Если условие (2) ложно, передача управления блоку 4.

5. Циклический процесс – цикл «до» (Рис. 6Б). Цикл выполняется как минимум один раз – блок 2. После проверки условия (3), если оно истинно, выполняется блок (2), иначе управление передается блоку 4.

Рисунок 6

Языки программирования объектного типа используют в программном коде класса объектов или процедурах обработки событий также элементы структурного программирования.

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

Пакеты прикладных программ (ППП) делятся на классы:

Проблемно-ориентированные ППП – обеспечивают решение задач определенной предметной области;

Методо-ориентированные ППП – поддерживают определенного вида модели и методы решения задач, применяются независимо от предметной области;

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

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

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

В качестве такого специального ПС можно указать компилятор с какого-либо языка программирования.

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

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

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

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

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

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

редакторы,·

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для таких инструментальных сред характерно,

во-первых, использование как программных, так и аппаратных инструментов, и,

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

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

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

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

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

(рис. 16.1): ·

среды программирования, ·

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

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

Среда программирования предназначена

в основном для поддержки процессов программирования (кодирования), тестирования и отладки ПС.

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

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

Для таких систем стоимость сопровождения обычно превышает стоимость разработки.

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

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

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

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

Кроме того, могут быть и другие инструменты, например, для статического или динамического анализа программ.

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

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

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

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

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

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

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

Такие среды разделяются на два подкласса: ·

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Разработка спецификаций распадается на несколько разных процессов.

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

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

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

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

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

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

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

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

технологическая определенность, ·

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

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

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

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

Интегрированность компьютерной поддержки означает:

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

Интегрированность по пользовательскому интерфейсу,

Интегрированность по действиям (функциям),

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

Интегрированность по пользовательскому интерфейсу означает, что все инструменты объединены единым пользовательским интерфейсом.

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

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

база данных разработки (репозиторий),·

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

интерфейсы.

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

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

Интерфейсы разделяются на

1)пользовательский

2) системные.

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

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

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

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

1)инструментальные системы поддержки проекта и

2) языково-зависимые инструментальные системы.

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

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

Примером такой системы является среда поддержки программирования на Аде (APSE ).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Унифицированный язык моделирования UML Большинство существующих методов объектно-ориентированного анализа и проектирования (ООАП) включают как язык моделирования, так и описание процесса моделирования. Язык моделирования – это нотация (в основном графическая), которая используется методом для описания проектов. Нотация представляет собой совокупность графических объектов, которые используются в моделях; она является синтаксисом языка моделирования. Например, нотация диаграммы классов определяет, каким образом представляются такие элементы и понятия, как класс, ассоциация и множественность. Процесс – это описание шагов, которые необходимо выполнить при разработке проекта. Унифицированный язык моделирования UML (Unified Modeling Language) – это преемник того поколения методов ООАП, которые появились в конце 80 -х и начале 90 -х гг.

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

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

UML выделяют следующие типы диаграмм: – диаграммы вариантов использования (usecase diagrams) – для моделирования бизнес-процессов организации (требований к системе); – диаграммы классов (class diagrams) – для моделирования статической структуры классов системы и связей между ними. На таких диаграммах показывают классы, интерфейсы, объекты и кооперации, а также их отношения. При моделировании объектно-ориентированных систем этот тип диаграмм используют чаще всего. Диаграммы классов соответствуют статическому виду системы с точки зрения проектирования; – диаграммы поведения системы (behavior diagrams); диаграммы взаимодействия (interaction diagrams) – для моделирования процесса обмена сообщениями между объектами. – диаграммы состояний (statechart diagrams) – для моделирования поведения объектов системы при переходе из одного состояния в другое.

– диаграммы деятельностей (activity diagrams) – для моделирования поведения системы в рамках различных вариантов использования или моделирования деятельностей. – диаграммы реализации (implementation diagrams): диаграммы компонентов (component diagrams) – для моделирования иерархии компонентов (подсистем) системы; диаграммы размещения (deployment diagrams) – для моделирования физической архитектуры системы.