Файл: Инфрам.pdf

15 недостаточно высокая квалификация разработчиков, отсутствие необ- ходимого опыта.
Потребность контролировать процесс разработки ПО, прогнозировать и гарантировать стоимость разработки, сроки и качество результатов при- вели в конце 70-х годов прошлого века к необходимости перехода от кус- тарных к индустриальным способам создания ПО. Начала развиваться совокупность инженерных методов и средств создания программного обеспечения, объединенных общим названием программная инженерия.
Впервые этот термин (software engineering) был использован как тема конференции, проведенной под эгидой НАТО в 1968 году. В 1975 году в
Вашингтоне была проведена первая международная конференция, по- священная программной инженерии.
В процессе становления и развития программной инженерии можно выделить два этапа: 70-е и 80-е годы – систематизация и стандартизация процессов создания ПО (на основе структурного подхода) и 90-е годы – начало перехода к сборочному, индустриальному способу создания ПО на основе объектно-ориентированного подхода.
1.4. Становление и развитие программной инженерии
Программная инженерия – это область компьютерной науки и техно- логии, которая занимается построением программных систем, настолько больших и сложных, что для этого требуется участие слаженных команд разработчиков различных специальностей и квалификаций. Обычно такие системы существуют и применяются долгие годы, развиваясь от версии к версии, претерпевая на своем жизненном пути множество изменений, улучшение существующих функций, добавление новых или удаление устаревших возможностей, адаптацию для работы в новой среде, устра- нение дефектов и ошибок. Суть методологии программной инженерии состоит в применении систематизированного, научного и предсказуемого процесса проектирования, разработки и сопровождения программных средств [19].
В основе программной инженерии лежит фундаментальная идея: про- ектирование ПО является формальным процессом, который можно изу- чать и совершенствовать. Однако, как показывает опыт более тридцати прошедших лет, использовать математические методы для формализации процесса проектирования программных систем не столь просто, и успехи в этом отношении достаточно скромные.
Ф. Брукс, руководитель проекта разработки операционной системы
OS/360, отмечал, что самым существенным свойством программных сис- тем является их сложность [5]. По причине уникальности и несхожести своих составных частей программные системы отличаются от техниче- ских систем, например, компьютеров, в которых преобладают повто- ряющиеся элементы. Сами компьютеры сложнее большинства продуктов человеческой деятельности. Количество их возможных состояний очень велико, поэтому их так трудно понимать, описывать и тестировать. У

16 программных систем количество возможных состояний на порядок пре- вышает количество состояний компьютеров.
Дополнительно к отмеченным выше особенностям ПО нужно доба- вить следующие [4, 8, 9, 20]:
сложность описания программной системы, обусловленная большим количеством функций, процессов, элементов данных и сложными взаимосвязями между ними);
наличие, как правило, в программной системе совокупности тесно
взаимодействующих подсистем, имеющих локальные задачи и цели функционирования, которые могут быть противоречивыми;
отсутствие полных аналогов, ограничивающее возможность исполь- зования типовых проектных решений и прикладных систем при соз- дании новой программной системы;
необходимость интеграции существующих и вновь разрабатываемых программных систем и приложений;
функционирование сложной программной системы в неоднородной
среде на нескольких аппаратных платформах и в различных операци- онных средах, часто трудно совместимых;
разобщенность и разнородность отдельных групп разработчиков по уровню квалификации и сложившимся традициям использования тех или иных инструментальных средств;
временная протяженность проекта, обусловленная сложностью про- екта, ограниченными возможностями коллектива разработчиков, мас- штабами организации-заказчика и различной степенью готовности подразделений заказчика к внедрению программной системы.
Как уже отмечалось, сложность – существенное свойство программ- ных систем. Многие проблемы разработки следуют из этой сложности и ее нелинейного роста при увеличении размера системы. Сложность явля- ется причиной затруднений, возникающих в процессе общения между разработчиками, что ведет к ошибкам в продукте, превышению стоимо- сти разработки, затягиванию графика работ. Сложность вызывает трудно- сти понимания всех возможных состояний программ, что приводит к снижению их надежности. Сложность структуры сдерживает развитие программной системы и возможность добавления новых функций.
Для успешной реализации проекта объект проектирования (ПС) дол- жен быть адекватно описан, т.е. должны быть построены полные и не-
противоречивые модели архитектуры ПС, определяющей совокупность структурных элементов системы и связей между ними, поведение эле- ментов системы в процессе их взаимодействия, а также иерархию подсис- тем, объединяющих структурные элементы.
По мнению Г. Буча [6], моделирование – центральное звено всей дея- тельности по созданию качественного программно обеспечения. Модели строятся, чтобы понять и осмыслить структуру и поведение будущей сис- темы, облегчить управление процессом ее создания, уменьшить возмож- ный риск, а также документировать принимаемые проектные решения.
Модель – это полное описание программной системы с определенной точки зрения. Ни одна модель не является абсолютно достаточной. На-

17 против, чтобы понять большинство систем, кроме самых тривиальных, требуется множество взаимосвязанных моделей. Хорошие модели явля- ются основой взаимодействия участников проекта и гарантируют кор- ректность архитектуры.
Модели разрабатываются на специальных языках. Язык моделирова- ния должен включать: элементы модели – функциональные концепции моделирования и их семантику; нотацию (систему обозначений) – визуальное представление элемен- тов моделирования; руководство по использованию – правила применения элементов в рамках построения тех или иных типов моделей программных систем.
Модели представляют собой абстракции, которые отображают основу сложной проблемы или структурируют ее, скрывая второстепенные дета- ли, и тем самым делают проблему более доступной для понимания. Для создания сложной системы разработчик должен рассмотреть ее с разных точек зрения, построить модель с использованием подходящей для дан- ной предметной области терминологии (нотации), проверить, что модель удовлетворяет требованиям, предъявляемым к системе, и, наконец, по- строить на основе созданной модели требуемую сложную систему.
Уже более 10 лет унифицированный язык моделирования UML
(Unified Modeling Language) является промышленным стандартом для визуализации, специфицирования, конструирования и документирования артефактов систем, в которых главная роль принадлежит программному обеспечению. Артефакты являются строительными блоками при модели- ровании физических аспектов системы. Артефакт – это физическая и за- меняемая часть системы. Артефакты используются для моделирования таких физических сущностей, которые могут располагаться на узлах – физических элементах, представляющих вычислительный ресурс, – на- пример, исполняемых программ, библиотек, таблиц, файлов и докумен- тов. Будучи де-факто стандартным языком моделирования, UML дает разработчикам возможность достичь взаимопонимания и избежать разно- чтений [6, 14].
Очевидно, что конечная цель разработки ПС – это не модель, а рабо- тающее приложение в форме программного кода. Диаграммы UML, в конечном счете, – лишь наглядные изображения, поэтому используя язы- ки графического моделирования, важно понимать, чем они могут помочь при написании кода программы. Использование графических языков мо- делирования целесообразно в следующих случаях: при изучении методов проектирования. Программисты, многие годы работающие до появления объектно-ориентированной технологии от- мечают серьезные трудности, связанные с освоением объектно- ориентированных методов и, в первую очередь, со сменой парадигмы.
Графические средства облегчают решение этой проблемы; при общении с заказчиками программной системы, будущими пользо- вателями и экспертами организации. Графические методы наглядно и

18 понятно представляют архитектуру системы и объясняют, что эта сис- тема будет делать; при получении общего представления о системе. Графические методы показывают, какого рода абстракции существуют в системе и какие ее части нуждаются в дальнейшем уточнении. Эта информация полезна при появлении в коллективе разработчиков новых сотрудников.
Следует отметить, что в последней версии UML 2.0 возможности язы- ка были расширены (формальная спецификация последней версии UML
2.0 опубликована в августе 2005 года, последняя версия UML 2.3 опубли- кована в мае 2010 года). Благодаря свой выразительности он позволяет моделировать буквально все – от офисных информационных систем и распределенных Web-приложений до встроенных систем реального вре- мени. Язык UML – нечто большее, чем просто набор графических симво- лов. Каждый из этих символов имеет четкую семантику. Это означает, что один разработчик может описать модель на языке UML, а другой раз- работчик и даже инструментальное средство – однозначно интерпретиро- вать ее.
Язык UML – это язык специфицирования, он позволяет специфици- ровать все важные решения, касающиеся анализ, дизайна и реализации, принимаемые в процессе разработки и внедрения программных систем.
UML не является языком визуального программирования, но его модели могут быть непосредственно ассоциированы с такими языками програм- мирования, как Java, C++, C# или Visual Basic. Отображение модели на язык программирования позволяет осуществить прямое проектирование
– генерацию кода из модели, обратное проектирование (восстановление модели по коду) также возможно. Многие компании, специализирующие- ся на разработке программных продуктов, помимо исполняемого кода производят и другие продукты. Сюда относится все, что связано с разра- боткой требований, архитектурой, проектными решениями (дизайном), исходным кодом, проектными планами, тестами, прототипами, релизами
(версиями) и др.
Корпорация IBM – крупнейшая в мире компания, работающая в об- ласти информационных технологий, – лидер в разработке и внедрении инновационных решений, предлагает полный комплекс решений, сетевых технологий и услуг, которые помогают преобразовать традиционные процессы в компаниях-разработчиках программного обеспечения и мак- симально эффективно использовать их интеллектуальные ресурсы и но- вые рыночные возможности. В 2003 году в состав компании IBM вошла корпорация Rational Software. Платформа Rational вместе с Lotus, Tivoli,
WebSphere и DB2 вошла в число ключевых компонентов стратегии IBM по созданию программного обеспечения. IBM Rational выпускает CASE- средства, системы автоматизированного проектирования ПО, а также средства управления проектами, связанными с разработкой, документи- рованием и сопровождением крупных информационных систем.
Например, продукт IBM Rational Software Architect (RSA) предназна- чен для построения моделей разрабатываемых программных систем с использованием унифицированного языка моделирования UML 2.0, пре-

19 жде всего моделей архитектуры разрабатываемого приложения. Тем не менее, RSA объединяет в себе многие функции таких программных про- дуктов, как Rational Application Developer, Rational Web Developer и
Rational Software Modeler, тем самым предоставляя возможность архитек- торам и аналитикам создавать различные представления разрабатываемой информационной системы с использованием языка UML 2.0, а разработ- чикам – выполнять разработку J2EE, XML, Web-сервисов и т.д.
В процессе развития практики и науки создания программных систем сложились определенные технологии программирования [7, 9, 10, 17, 18].
Эти технологии целесообразно рассмотреть в историческом контексте, выделяя основные этапы развития программирования как науки.