Текст книги "Системы автоматизации разработки программного обеспечения"

Соловьев Н. А., Чернопрудова Е. Н.
Системы автоматизации разработки программного обеспечения

Введение

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

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

Основой изложенного материала стал учебник «Технология программирования», разработанного в МГТУ им. Н. Баумана профессором Г.С. Ивановой, и допущенного Министерством образования и науки Российской Федерации (Минобрнауки РФ) для студентов ВУЗов, обучающихся по направлению 2301000 – Информатика и вычислительная техника. Материал доработан в процессе многолетней апробации на кафедре программного обеспечения вычислительной техники и автоматизированных систем «Оренбургский государственный университет».

1 Методология автоматизации разработки программного обеспечения

1.1 Актуальность автоматизации разработки программного обеспечения

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

Поэтому состояние отрасли напрямую определяет благополучие специалистов-разработчиков программного обеспечения (ПО).

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

В конце ХХ – го века в программной инженерии сложилось критическая ситуация, неразрешенная до сих пор. Кризис выражается в том, что большие проекты ПО стали выполняться с отставанием графика и со значительным превышением расходов, а разработанный продукт не обладал требуемыми функциональными возможностями или производительностью, что не устраивает потребителей. Так, например, в 1995 г. компания Standish Group проанализировала работу 364 американских корпораций по итогам выполнения более 23 000 проектов, связанных с разработкой ПО.

Результаты анализа, представленные на рисунке 1.1, оказались удручающими.

Рисунок 1.1 – Результаты анализа проектов в области программной инженерии

Причины кризиса:

– нечеткая и неполная формулировка требований к ПО;

– недостаточное вовлечение пользователей в работу над проектом;

– отсутствие необходимых ресурсов и неудовлетворительное планирование;

– частое изменение требований спецификаций;

– новизна используемой технологии для организации;

– отсутствие грамотного управления проектом.

В конце 20 – го века утвердилось понимание необходимости перехода от кустарных к индустриальным технологиям создания ПО, к созданию совокупности инженерных методов и средств разработки программных продуктов, объединенных общим названием «программная инженерия» (software engineering). Тогда же появилось первое издание, посвященное программной инженерии – IEEE Transaction on Software Engineering.

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

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

Предметной областью специалистов ПОВТАС являются АИС. Как отмечал Фредерик Брукс, руководитель проекта операционной системы OS/360, самым существенным свойством программных систем (ПС), к классу которых относится АИС, является их сложность. Благодаря уникальности и несхожести своих составных частей АИС принципиально отличается от технических систем, в которых преобладают повторяющиеся элементы.

Тенденциями развития АИС в современных условиях становятся:

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

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

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

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

– функционирование в неоднородной среде на нескольких аппаратных платформах;

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

– значительная временная протяженность проекта.

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

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

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

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

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

Структура учебного пособия представлена на рисунке 1.2.

Рисунок 1.2 – Структура учебного пособия

Задачи учебного пособия:

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

– рассмотреть современное состояние развития CASE – средств и промышленных технологий разработки ПО;

– изучить унифицированный язык объектно – ориентированного моделирования UML и визуальный редактор на его основе – Rational Rose.

1 Перечислите причины кризиса программной инженерии.

2 Какая идея лежит в основе программной инженерии?

3 Каковы тенденции развития современных АИС?

4 Дополните определение: «СASE-технология представляет собой совокупность методов проектирования АИС, а также…».

5 Какие методы применялись в 80-90-х годах прошлого века при разработки программного обеспечения (ПО).

1.2 Методологические основы разработки программного обеспечения

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

Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12207 (ISO – International Organization of Standardization – Международная организация по стандартизации, IEC – International Electrotechnical Commission – Международная комиссия по электротехнике). Стандарт определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.

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

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

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

Рисунок 1.3 – Спиральная модель ЖЦ ПС

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

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

Как и любая технология, технология программирования представляет собой набор технологических процессов, включающих:

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

– перечисление условий, при которых выполняется та или иная операция;

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

Рисунок 1.4 – Описание технологических операций

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

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

На формальном уровне метод определяется как совокупность составляющих языка моделирования:

– концепций (теоретических основ). В качестве таких основ выступают структурный или объектно – ориентированный подходы (парадигмы) программирования;

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

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

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

Рисунок 1.5 – Составляющие языка моделирования

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

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

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

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

Однопользовательские архитектуры реализуют в виде:

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

– пакета программ (совокупность программ, решающих задачи некоторой предметной области, например, библиотека программ);

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

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

Многопользовательские программные системы организуют сетевое взаимодействие отдельных компонентов ПО, построенные по принципам «файл – сервер», «клиент – сервер» и т.д.

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

– стандарт проектирования;

– стандарт оформления проектной документации;

– стандарт пользовательского интерфейса.

Содержание стандартов рассматривается в курсе ТРПО.

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

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

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

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

Известная формула Вирта «алгоритмы + структура данных = программа» свидетельствует, что в недрах ПО существуют два начала, две противоположности, находящиеся, как водится, в диалектическом единстве и борьбе. Одно начало императивное, алгоритмическое, а другое – декларативное, непроцедурное, основанное на моделях.

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

Рисунок 1.6 – Эволюция технологий проектирования

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

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

Последовательность технологических операций, характерная для технологий процедурного программирования, представлена на рисунке 1.7.

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

Рисунок 1.7 – Последовательность операций технологии процедурного программирования и их исполнители

На верхнем уровне рисунка 1.8 изображена архитектура таких программ.

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

Появление АССЕМБЛЕРА и высокоуровневых языков FORTRAN, ALGOL позволило повысить сложность разрабатываемых ПО за счет использования подпрограмм. Однако слабым местом такой архитектуры было то, что при увеличении количества подпрограмм возрастала вероятность искажения части данных, которые не делились на глобальные и данные подпрограмм.

Рисунок 1.8 – Развитие архитектуры программ при технологиях процедурного и структурного программирования

Кроме того, разрабатываемое ПО с локальными данными по прежнему ограничивалось возможностью программиста отслеживать процессы их обработки. Это предопределило возникновение первого «кризиса программирования» (60-е годы ХХ-го века) – колоссальные успехи в области развития средств вычислительной техники пришли в противоречие с низкой производительностью труда программистов, отсюда проекты устаревали раньше, чем были готовы к внедрению. Появление операционных систем снизило остроту проблем. Однако оставалась разработка ПО «снизу-вверх» – подход при котором сначала разрабатывались сравнительно простые подпрограммы, из которых затем пытались построить сложную программу.

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

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

1 Дайте определение технологии проектирования ПО?

2 Что понимают под архитектурой ПО? 3 Что представляют собой модели ПО?

4 В каких случаях строятся модели?

5 Что является центральным процессом моделирования? Что включает в себя язык моделирования?

6 Перечислите последовательность операций технологии процедурного программирования.

7 Какие объекты включает в себя технологические операции?

8 Дайте определение методу проектирования.

9 В чем заключается сущность стихийного программирования?

10 Перечислите и поясните последовательность операций технологий процедурного программирования и их исполнителей.

1.3 Базовые технологии разработки программного обеспечения

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