1. Введение в программную инженерию

   1. Программная инженерия

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

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

Потребность контролировать процесс разработки ПО, прогнозировать и гарантировать стоимость разработки, сроки и качество результатов привела в конце 70-х годов к необходимости перехода от кустарных к индустриальным способам создания ПО и появлению совокупности инженерных методов и средств создания ПО, объединенных общим названием «программная инженерия». Впервые этот термин был использован как тема конференции, проводившейся под эгидой НАТО в 1968 г. Спустя 7 лет, в 1975г. в Вашингтоне была проведена первая международная конференция, посвященная программной инженерии.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Программное средство (изделие) – программа или логически связанная совокупность программ:

• записанная на носителях данных;

• являющаяся продуктом промышленного производства;

• снабженная программной документацией;

• предназначенная для широкого распространения посредством продажи или методами freeware, shareware или OEM.

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

2. Связь программной инженерии с другими сферами науки

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

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

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

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

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

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

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

Основные сведения

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

Так как область все еще относительно молода по сравнению со своими сестринскими областями инженерии, есть все еще большая работа и дебаты вокруг того, что представляет собой «инженерия программного обеспечения», и удовлетворяет ли оно понятию инженерии. Этот спор развивается естественным образом, начавшись с попыток рассматривать создание программного обеспечения только как программирование. Разработка программного обеспечения — термин, иногда предпочитаемый практиками в промышленности, которые рассматривают разработку программного обеспечения как несравнимо более мощную и конструкционноёмкую методологию в сравнении с процессом написания кода программистом.

Все же, несмотря на юность профессии, будущее области радужно, поскольку, Money Magazine и Salary.com оценили профессию разработчика программного обеспечения как лучшую работу в Америке в 2006.

Разработка программного обеспечения связана с дисциплинами информатики, управления проектами, и инженерии систем.

История

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

специализаций.

Работа

Большинство программных инженеров и программистов работает 40 часов в неделю, а около 15 процентов программных инженеров и 11 процентов программистов работали более 50 часов в неделю в 2008 году. Травмы в этих профессиях встречаются редко. Однако, как и в других профессиях, где надо проводить много времени перед компьютером, люди этих специальностей более подвержены к усталости глаз, болям в спине, а также болезням рук и запястий, таких как синдром запястного канала.

Влияние глобализации

Первоначальное развитие аутсорсинга, а также относительно низкая стоимость человеческих ресурсов в развивающихся странах третьего мира привело к взрыву мыльного пузыря .com 1990-х годов. Это оказало негативное воздействие на многие аспекты профессии программного инженера. Например, некоторые студенты в развитых странах не хотели получать образование, связанное с программной инженерией из-за страха оффшорного аутсорсинга (импорт программных продуктов или услуг из других стран) и вытеснения иностранными рабочими. Хотя судя по статистике в настоящее время ничего не угрожает программной инженерии как таковой. Однако профессии, связанные с программированием кажется, действительно, были затронуты. Тем не менее, способность ловко использовать зарубежные рабочие ресурсы, улучшило общую работоспособность многих организаций. Когда североамериканцы будут уходить с работы, азиаты только прибывать на нее. Когда азиаты будут уходить с работы, европейцы будут на нее приезжать. Это обеспечивает непрерывную возможность иметь людей, следящих за критически важными бизнес-процессами 24 часа в сутки, без выплаты компенсации за сверхурочную работу и не лишая людей сна.

Образование

Знания в области программирования являются необходимым условием для того, чтобы стать программным инженером. В 2004 году IEEE Computer Society выпустил SWEBOK, который был опубликован в качестве стандарта ISO / IEC 19759:2004, описывающего объем знаний, который по их мнению, должен получить дипломированный программный инженер с четырехлетним опытом. Многие люди входят в эту профессии, получив высшее образование или отучившись в профессионально-техническом училище. Стандартный учебный план для международной степени бакалавра программной инженерии был определен CCSE, и обновлен в 2004 году. Ряд университетов имеют программы обучения программных инженеров. С 2010 года насчитывалось 244 очных программы, 70 Интернет-курсов, 230 программ для специалистов, 41 программ для ученых в этой области, а также 69 программ для сертификатов в Соединенных Штатах.

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

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

Использование

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

UML позволяет также разработчикам программного обеспечения достигнуть соглашения в графических обозначениях для представления общих понятий (таких как класс, компонент, обобщение (англ. generalization), агрегация (англ. aggregation) и поведение) и больше сконцентрироваться на проектировании и архитектуре.

История языка UML

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

По определению Гради Буча унифицированный язык моделирования (Unified Modelling Language, UML) является графическим языком для визуального представления, составления спецификаций, проектирования и документирования систем, в которых большая роль принадлежит программному обеспечению. Мы будем называть такие системы автоматизированными информационными системами (АИС) и полагать, что в работе АИС участвуют люди. С помощью языка UML можно разработать общесистемную документацию АИС, документацию ее программного обеспечения и создать многократно используемые (т.е. типовые) компоненты программного обеспечения.

Решающую роль в создании языка UML сыграли Гарди Буч, Джеймс Рамбо и Айвар Джекобсон и созданные ими следующие методы моделирования различных сторон сложных систем:

Метод Буча (Booch'93), ориентированный, в первую очередь, на моделирование программного обеспечения сложных систем.

Метод Рамбо (ОМТ- Object-Modeling Technique), ориентированный на анализ процессов обработки данных в информационных системах.

Метод Джекобсона (метод OOSE Object-Oriented Software Engineering ), ориентированный на анализ требований к бизнес-приложениям.

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

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

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

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

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

В 1996 г. была создана первая версия языка UML 0.9. После этого ведущие компьютерные фирмы Microsoft, IBM, Oracle и многие другие осознали, что язык UML имеет стратегическое значение для их бизнеса. В результате был организован консорциум UML, деятельность которого оплачивается за счет ежегодных денежных взносов фирм членов консорциума.

Важную роль в создании языка UML сыграла его поддержка Группой по управлению объектами OMG (Object Management Group). Группа OMG объединяет около 300 ведущих компьютерных фирм. Она выпускает стандарты в области Интернет/Веб. Язык UML приобрел статус второго стратегического направления деятельности OMG. В 1997 г. были созданы версии языка UML 1.0 и 1.1. В 1998 г была создана версия UML 1.2, а в 1999 г - версия UML 1.3. В переводной российской литературе по языку UML описывается его версия 1.3.

В настоящее время разработаны инструментальные программы поддержки языка UML. Наиболее известной из них является программы Rational Rose 2000 фирмы Rational Software. Кроме того создан ряд средств визуального программирования, обеспечивающую прямую генерацию кода программ из UML моделей. Эти средства интегрированы с наиболее распространенными языками программирования Java, C++ и многими другими.

Группа OMG продолжает работы по созданию новых версий языка UML.

UML - язык моделирования и документирования сложных систем

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

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

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

Возникает естественный вопрос. Почему 300 ведущих компьютерных фирм, объединенных в консорциуме OMG, придают такое большое значение работам по созданию версий языка UML? Чтобы ответить на этот вопрос обратимся к Рис.3.1

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

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

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

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

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

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

Мы рассмотрели лишь часть проблем, решаемых с помощью языка UML.

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