Основы программирования в контексте инженерии программного обеспечения

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

Повний опис

Збережено в:

Бібліографічні деталі
Дата:	2019
Автор:	Сидоров, Н.А.
Формат:	Стаття
Мова:	Russian
Опубліковано:	Інститут програмних систем НАН України 2019
Назва видання:	Проблеми програмування
Теми:	Методи та засоби програмної інженерії
Онлайн доступ:	http://dspace.nbuv.gov.ua/handle/123456789/161496
Теги:	Додати тег Немає тегів, Будьте першим, хто поставить тег для цього запису!
Назва журналу:	Digital Library of Periodicals of National Academy of Sciences of Ukraine
Цитувати:	Основы программирования в контексте инженерии программного обеспечения / Н.А. Сидоров // Проблеми програмування. — 2019. — № 3. — С. 45-57. — Бібліогр.: 22 назв. — рос.

Репозитарії

Digital Library of Periodicals of National Academy of Sciences of Ukraine

id	irk-123456789-161496
record_format	dspace
spelling	irk-123456789-1614962019-12-12T01:26:42Z Основы программирования в контексте инженерии программного обеспечения Сидоров, Н.А. Методи та засоби програмної інженерії Рассматривается применение конструктивного подхода к построению текстов программ, который систематически культивируется в инженерии программного обеспечения и стало возможным благодаря ряду фундаментальных результатов, полученных в теории программирования. Рассматривается применение конструктивного подхода к построению текстов программ, который систематически культивируется в инженерии программного обеспечения и стало возможным благодаря ряду фундаментальных результатов, полученных в теории программирования. The article discusses the use of a constructive approach to building a program that is systematically cultivated in software engineering and made possible by a number of fundamental results obtained in programming theory. 2019 Article Основы программирования в контексте инженерии программного обеспечения / Н.А. Сидоров // Проблеми програмування. — 2019. — № 3. — С. 45-57. — Бібліогр.: 22 назв. — рос. 1727-4907 DOI: https://doi.org/10.15407/pp2019.03.045 http://dspace.nbuv.gov.ua/handle/123456789/161496 502:004.45 (075.8) ru Проблеми програмування Інститут програмних систем НАН України
institution	Digital Library of Periodicals of National Academy of Sciences of Ukraine
collection	DSpace DC
language	Russian
topic	Методи та засоби програмної інженерії Методи та засоби програмної інженерії
spellingShingle	Методи та засоби програмної інженерії Методи та засоби програмної інженерії Сидоров, Н.А. Основы программирования в контексте инженерии программного обеспечения Проблеми програмування
description	Рассматривается применение конструктивного подхода к построению текстов программ, который систематически культивируется в инженерии программного обеспечения и стало возможным благодаря ряду фундаментальных результатов, полученных в теории программирования.
format	Article
author	Сидоров, Н.А.
author_facet	Сидоров, Н.А.
author_sort	Сидоров, Н.А.
title	Основы программирования в контексте инженерии программного обеспечения
title_short	Основы программирования в контексте инженерии программного обеспечения
title_full	Основы программирования в контексте инженерии программного обеспечения
title_fullStr	Основы программирования в контексте инженерии программного обеспечения
title_full_unstemmed	Основы программирования в контексте инженерии программного обеспечения
title_sort	основы программирования в контексте инженерии программного обеспечения
publisher	Інститут програмних систем НАН України
publishDate	2019
topic_facet	Методи та засоби програмної інженерії
url	http://dspace.nbuv.gov.ua/handle/123456789/161496
citation_txt	Основы программирования в контексте инженерии программного обеспечения / Н.А. Сидоров // Проблеми програмування. — 2019. — № 3. — С. 45-57. — Бібліогр.: 22 назв. — рос.
series	Проблеми програмування
work_keys_str_mv	AT sidorovna osnovyprogrammirovaniâvkonteksteinženeriiprogrammnogoobespečeniâ
first_indexed	2025-07-14T14:03:32Z
last_indexed	2025-07-14T14:03:32Z
_version_	1837631341026344960
fulltext	Методи та засоби програмної інженерії © Н.А. Сидоров, 2019 ISSN 1727-4907. Проблеми програмування. 2019. № 3 45 УДК 502:004.45 (075.8) https://doi.org/10.15407/pp2019.03.045 Н.А. Сидоров ОСНОВЫ ПРОГРАММИРОВАНИЯ В КОНТЕКСТЕ ИНЖЕНЕРИИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Рассматривается применение конструктивного подхода к построению текстов программ, который си- стематически культивируется в инженерии программного обеспечения и стало возможным благодаря ряду фундаментальных результатов, полученных в теории программирования. Во-первых, на основе известной структурной теоремы, аргументировано отказались от использования оператора go to и предложили метод структурного программирования, что обеспечило реальный путь к созданию понят- ных программ. Во-вторых, понятие подпрограммы, хотя и использовалось только для уменьшения ру- тинной работы в процессе программирования, стало первым средством модульного представления про- грамм. Позднее блок и подпрограмма составили основу блок-ориентированных (процедурных, подпро- граммных) языков и метода процедурного (подпрограммного) программирования. В-третьих, для отве- та на вопросы, относящихся к определению границ, размеров и устройства модуля ввели понятия свя- зывания частей, составляющих модуль и соединения между модулями; создали конкретные критерии модуляризации; предложили устройство модуля на основе понятия сокрытия информации. Модуль был реализован в языке программирования Modula, а позже Modula-2, в которых использовался на основе метода модульного (композиционного) программирования. При разработке языка Simula 67, были за- ложены основы объектно-ориентированных языков, которые получили развитие благодаря работам по концепциям наследования, позднего связывания и ссылкам и основы были завершены разработкой объектно-ориентированных языков и методом объектно-ориентированного (классификационного) про- граммирования. Таким образом, была создана база для повторного, многократного использования и компонентной разработки программного обеспечения. Сейчас эти работы развиваются в направлении исследования и создания программного обеспечения как системы систем (system of systems), используя связь системного анализа и инженерии программного обеспечения, и развивая системную инженерию программного обеспечения. В статье, для обучения основам программирования, как средство, которое позволяет уточнить понятие программной конструкции, использовано классификацию, а как классифи- кационный признак - уровень инкапсуляции, который строится на основе принципов инженерии про- граммного обеспечения - инкапсуляции и многоуровневого представления, Применяя принцип инкап- суляции на разных уровнях представления структуры программы, соответствующие различным степе- ням абстракции программного обеспечения, получено понятие уровня инкапсуляции. Воспользовав- шись этим понятием, можно выяснить типы программных конструкций и соответствующие методы программирования (конструирования) программ. На основе конструктивного подхода, и введенных по- нятий к построению программы, автором создана дидактика основ программирования, которая внедре- на путем использования в лекциях для студентов специальности «Инженерия программного обеспече- ния» (121) и при написании автором учебного пособия для студентов и аспирантов, указанной специ- альности по основам программирования. Ключевые слова: обучение, дидактика, основы программирования, языки программирования, инжене- рия программного обеспечения. Введение Функционирование своей машины Ч. Бэббидж основал на принципе про- граммного управления, и вследствие этого появилась необходимость писать програм- мы, процесс – программирование и первые программисты. Впоследствии, с появлени- ем электронных вычислительных машин и их широким распространением, этот про- цесс стал массовым, а, принимая во вни- мание его сложность и стоимость, стои- мость труда писателей и исполнителей программ еще и дорогим. В первое время к созданию программного обеспечения от- носились как к созданию «железа», но к 60-ым годам пришло понимание, что про- граммное обеспечение принципиально отличается от «железа». Во-первых, про- граммное обеспечение легко модифициро- валось и копировалось. Во-вторых, про- граммное обеспечение не изнашивалось, а его сопровождение отличалось от сопро- вождения «железа». Программное обеспе- https://doi.org/10.15407/pp2019.03.0 Методи та засоби програмної інженерії 46 чение было невидимо, не имело веса, но при этом было очень дорогим. Разработка программного обеспечения была практи- чески неуправляемой и требовала огром- ного количества спецификаций (в 50 раз больше чем для «железа») [1]. В-третьих, с распространением машин в программиро- вании появилась кадровая проблема – не- хватка программистов, которую решали путем тренинга гуманитариев, филологов, социологов и специалистов из подобных отраслей. Изменение отношения отрази- лось и на программировании, которое ста- ли квалифицировать как процесс относя- щийся к искусству. Для решения проблем была предложена инженерия программно- го обеспечения (Software engineering) – приложение систематического, дисципли- нированного, измеримого подхода к разра- ботке, функционированию и сопровожде- нию программного обеспечения, а также исследованию этого подхода; приложение дисциплины инженерии к программному обеспечению (ISO/IEC/IEEE 24765-2010) [2]. Поскольку основным процессом в ин- женерии программного обеспечения по- прежнему оставалось программирование, то первые результаты были получены в этой области. Во-первых, на основе из- вестной структурной теоремы, аргументи- ровано отказались от использования опера- тора go to и предложили метод структурно- го программирования, что обеспечило ре- альный путь к созданию понятных про- грамм. Во-вторых, понятие подпрограммы, хотя и использовалось только для умень- шения рутинной работы в процессе про- граммирования, стало первым средством модульного представления программ. Позднее блок и подпрограмма составили основу блок-ориентированных (процедур- ных, подпрограммных) языков и метода процедурного (подпрограммного) про- граммирования. В-третьих, для ответа на вопросы, относящиеся к определению гра- ниц, размеров и устройства модуля ввели понятия связывания (cohesion) частей, со- ставляющих модуль и соединения (coupling) между модулями [3]. Затем вве- ли конкретные критерии модуляризации и предложили устройство модуля на основе понятия сокрытия информации. В 1980 году реализовали язык программирования Modula, а позже Modula-2, в которых ис- пользовалось понятие модуля и модульно- го (композиционного) программирования [4]. В 1984 году был создан язык програм- мирования Ada, в котором такое же поня- тие реализовано в форме пакета [5]. В 1967 году, используя блок и сокрытие информа- ции при разработке языка Simula 67, были заложены основы объектно-ориентирован- ных языков [6]. Эти основы получили раз- витие благодаря работам по концепциям наследования, позднего связывания и ссылкам [7]. Завершены эти работы были разработкой объектно-ориентированных языков и методом объектно-ориентирован- ного (классификационного) программи- рования [8]. Таким образом, в основном были завершены работы в области модуля- ризации, как для композиционных, так и классификационных языков и создана ос- нова для повторного, многократного ис- пользования и компонентной разработки программного обеспечения. Сейчас эти работы развиваются в направлении иссле- дования и создания программного обеспе- чения как системы систем (system of systems), используя связь системного ана- лиза и инженерии программного обеспече- ния, и развивая системную инженерию программного обеспечения (system soft- ware engineering) [9]. Конструктивный подход к устройству программы в контексте инженерии программного обеспечения В контексте инженерии программ- ного обеспечения, рассматривая программу метафорически с точки зрения теории ма- шин, будем иметь в виду три точки зрения на машину, а именно технологическую, кинематическую и конструктивную [10]. В статье будет применяется послед- няя точка зрения, конструктивная. Кон- структивный подход к рассмотрению про- граммы, систематически культивируется в инженерии программного обеспечения и стал возможным благодаря ряду фунда- ментальных результатов, полученных в теории программирования, о которых Методи та засоби програмної інженерії 47 кратко говорится во введении статьи. Кон- структивная теория машин рассматривает их с точки зрения форм и частей целого, статически, разделяя машину на отдельные части и подчеркивая ее конструкцию. В XVIII веке утверждалось, что «многооб- разные механизмы движения, которыми пользуются для устройства рабочих ма- шин, не должны заново изобретаться каждый раз. Это было необходимо, когда были изобретены паровые и прядильные машины, так как тогда были известны лишь немногие механизмы для преобразо- вания движений. Теперь же известно очень много разнообразных механизмов и всегда можно отыскать такой, который подходит для частного случая. Таким образом, лишь для совершенно необычных условий дви- жения действительно необходимы новые изобретения, и очень ясное и полное зна- ние изобретенных до настоящего времени передаточных механизмов, служащих для устройства рабочих машин, является необычайно важным» [11]. В работе [12], B. Boehm делает аналогичное предполо- жение относительно программного обес- печения, аргументируя повторное исполь- зование (reuse и systematic reuse) про- граммного обеспечения как наиболее перспективный подход для повышения продуктивности создания и сопровожде- ния программного обеспечения на бли- жайшие десятилетия. С годами, это пред- положение подтвердилось. Очевидно, что продуктивность этого подхода зависит от реализации конструктивной точки зре- ния на программы. При этом, такой взгляд имеет важное значение не только при про- ектировании, но и при программировании. К сожалению, компонентный (конструк- тивный) подход дается студентам поздно, только в дисциплинах проектирования программного обеспечения и совсем не применяется в раннем обучении основам программирования. Студенты, в контексте обучения по специальности инженерия программного обеспечения должны не только учиться писать работающие про- граммы, но программы, которые отвечают ряду дополнительных требований, связан- ных с реализацией компонентного подхо- да. Не владея конструктивным взглядом на программы невозможно удовлетворять эти требования. При обучении основам программи- рования, как средство, которое позволяет уточнить понятие программной конструк- ции, предложено использовать классифи- кацию, а как классификационный признак – уровень инкапсуляции, который строится на основе принципов инженерии про- граммного обеспечения – инкапсуляции и многоуровневого представления [13]. Инкапсуляция в целом – это про- цесс создания оболочки вокруг тех или иных веществ. Оболочка называется кап- сулой, а вещества в капсуле инкапсулиро- ванными и характеризуются высокими внутренними (cohesion) и низкими внеш- ними (coupling) связями. Инкапсуляция в программировании – это процесс, который агрегирует «вещество» программ, кодиро- ванного в том или ином языке программи- рования, образуя капсулы. Они могут ис- пользоваться в программировании как единственные в определенном смысле за- конченные части программ. Этот процесс, как увидим дальше, регламентирован. В программе роль инкапсулирован- ного «вещества» играют ее компоненты, например, операторы, подпрограммы. Об- разование капсулы (конструкции) вокруг компонентов программы позволяет до- стичь следующих, присущих конструктив- ному взгляду, целей [13]: - манипулировать при написании, отладке и понимании программ капсулами, рассматривая их как законченные части; - указать метод программирова- ния, который регламентирует использова- ние капсул; - указать значения, обрабатывае- мые капсулой; - ограничивать допуск к компо- нентам, размещенным в капсуле; - скрывать детали реализации компонентов, размещенных в капсуле; - использовать капсулы для по- строения других капсул. Капсула строится агрегированием необходимых частей программы и созда- нием оболочки и интерфейса, что обеспе- чивает правильное применение капсулы. При создании или повторном использова- Методи та засоби програмної інженерії 48 нии капсул перед программистом возни- кают три вопроса. Во-первых, в каком слу- чае (для реализации каких проектных ре- шений – действий) может применяться та или иная капсула (какова концепция кап- сулы). Во-вторых, какой должна быть кап- сула (какое устройство, конструкция кап- сулы). В-третьих, как связывается капсула с окружением (контекст капсулы). Про- граммист, создавая или повторно, много- кратно используя капсулы, применяет их в соответствии с методом программирова- ния и реализует проектные решения, полу- ченные в предыдущих фазах жизненного цикла программы, что составляет часть процессов конструирования программ. Капсулу, которая применяется в соответ- ствии с методом программирования можно называть программной конструкцией. Чтобы охарактеризовать известные ныне программные конструкции, а также выяс- нить, какие значения они обрабатывают и в чем заключаются методы конструирова- ния (программирования) программ из них, воспользуемся еще одним принципом ин- женерии программного обеспечения – многоуровневым представлением. Применяя принцип инкапсуляции на разных уровнях представления структу- ры программы, соответствующие различ- ным степеням абстракции программного обеспечения, получено понятие уровня инкапсуляции [13]. Воспользовавшись этим понятием, можно выяснить типы программных конструкций и соответству- ющие методы программирования (кон- струирования) программ. Сейчас можно выделить шесть уровней инкапсуляции и столько же типов программных конструк- ций (таблица). Таблица. Уровни инкапсуляции Уровень инкапсуляции Инкапсулируемые части программы Создаваемая конструкция (капсула) Метод програм- мирования (применения) Средства и механизмы Метафора Лексический Символы алфавита языка программирования Лексема Правила создания лексем и выражений Оператор присваи- вания, операции Звено Операторный Лексемы и выражения из них Структурный оператор Структурное программирова- ние Структурный опера- торный базис языка программирования Цепь Подпрограм- мный Описание данных, структурные операторы Подпрограм- ма (макрос, процедура, функция) Процедурное (подпрограммное) программирова- ние Независимая компиляция Механізм Модульный Описание данных, подпрограммы Модуль (пакет) Модульное (ком- позиционное) программирова- ние Механизмы сокрытия и видимо- сти, раздельная компиляция Механізм Классный Описание данных, подпрограммы Класс Объектно- ориентированное (классификаци- онное) програм- мирование Наследование, полиморфизм, связывание Механізм Мегамодуль- ный (система систем) Онтология, модули, классы Мегамодуль (система) Мегапрограм- мирование Операционная неза- висимость, незави- симое управление и поведение, геогра- фическая распреде- ленность, эволюци- онное и адаптивное развитие Машина Методи та засоби програмної інженерії 49 Степень абстрагирования и пони- мания программы повышается от лексиче- ского уровня к мегамодульному. Каждому уровню инкапсуляции соответствует свой тип капсул (программная конструкция), правила образования и дисциплина их ис- пользования в конструировании программ (метод программирования). Программные конструкции. В ас- пекте конструктивной точки зрения на про- грамму, программная конструкция – это фундаментальное понятие языка програм- мирования. С точки зрения инженерии программного обеспечения каждая часть программы – это программная конструк- ция, если в ней инкапсулированы другие части программы (нижнего уровня инкап- суляции), она характеризуется конструк- тивными (системными) свойствами и име- ет собственный способ применения [13]. Простейшая программная кон- струкция, это лексема. Являясь обозначе- нием, она играет важную роль в построе- нии таких конструкций как литерал, кон- станта, переменная. Более сложными про- граммными конструкциями являются вы- ражение, оператор, подпрограмма, модуль, класс, мегамодуль (система систем). Лексемы. Символы алфавита не играют в языке самостоятельной роли, од- нако они используются для построения лексем. С одной стороны, лексемы – это простые программные конструкции, кото- рые составляют словарный запас языка. А с другой стороны, лексемы – это капсулы, которые инкапсулируют символы алфави- та. «Оболочки» капсул образуют специ- альные символы, или символы других лек- сем. Капсулу-лексему можно подать раз- меченной цепочкой: Sіl1 l2...ln Sj..., где Si, Sj, lk  V; V – алфавит языка; Si, Sj – про- бельные символы или символы других лексем; lk, (k = 1, ..., n) – символы лексе- мы, при этом l1 – первый символ, а ln – последний символ лексемы (если Si, Sj сим- волы других лексем). В лексеме-капсуле можно установить порядок (последова- тельность) символов, который дает поня- тие границ капсулы (первый и последний символы капсулы) и используется лекси- ческим анализатором – программой, вхо- дящей в состав транслятора. Этот порядок позволяет говорить о входе в капсулу и выходе из нее. Все лексемы в тексте про- граммы являются обозначениями. Это означает, что лексемы обозначают другие конструкции программы, которые строятся и используются в процессах трансляции и выполнения программы. На лексическом уровне инкапсуляции текст программы конструктивно состоит из последователь- ности лексем. Когда программа трансли- руется или выполняется, тогда каждой лексеме ставится в соответствие некоторое значение. Соответствие между лексемой и значением может устанавливать програм- мист или транслятор, или это соответствие может заранее определяться стандартным окружением языка программирования. На рис. 1 показана роль лексемы в конструк- ции переменной. Длина значения из типа в описании переменной Генератор захватывает память' Обозначение Ссылка Обозначение Значение Генератор размещает ссылку Адрес значения в памяти Имя переменной Содержимое переменной Рис. 1. Конструкция простой переменной Методи та засоби програмної інженерії 50 Установление соответствия между лексемой и значением или между обозна- чением и значением, или еще шире - меж- ду двумя объектами программы обеспечи- вается механизмом связывания (binding). Выражение описывает правило об- работки значений, содержащихся в про- граммных объектах, входящих в его со- став. В результате выполнения правила образуется значение, которое является значением выражения. Таким образом, текст выражения – это обозначение, и по- сле выполнения выражения – это обозна- чение связывается с значением. Поэтому, выражение является программной кон- струкцией наряду с литералом, константой и переменной. Операторы. Структурные опера- торы составляют структурный оператор- ный базис языков программирования, ко- торого достаточно для записи любой про- граммы. Именно структурные операторы и структурное программирование – метод их применения – в свое время стали фун- даментальными концепциями в языках программирования. Лексемы выступают как части, которые образуют структурную капсулу, а оболочка капсулы и интерфейс реализуются через организационные ограничения. Во-первых, что касается оболочки, запрещается произвольный до- ступ к конструкциям внутри капсулы, и произвольный выход из капсулы (рис. 2). Это запрет применения операторов go to, break, exit или continuous. Во-вторых, что касается интерфейса, указанные ограни- чения технически можно преодолеть, но если их учитывать, то в любой структур- ной капсуле предполагается только один вход и один выход (рис. 2), с помощью которых она соединяется с другими кап- сулами, образуя пары (звенья цепи) и це- пи (таблица). break, go to, exit, continuous Структурная капсула go to Вход Выход Рис. 2. Структурная капсула Применение структурного програм- мирования ведет к созданию программных текстов, которые легко читаются и моди- фицируются. В рамках структурного про- граммирования рассматриваются преобра- зования программ, которые могут выпол- няться вручную или автоматически. Рассмотрим простой пример. В тех- нологическом аспекте необходимо создать подпрограмму («механизм»), которая осу- ществляет обмен значений целого типа, swap (int a, int b). Имеем следующую кон- струкцию (рис. 3, 4): Начало Конец a == b F == 1 F = 1; F = 0; Temp = a; a = b; b = Temp; ДаНет ДаНет Рис. 3. Конструкция программы Рис. 4. Текст программы void swap(int &a, int &b) { int F; int Temp; if a == b F = 0; else F = 1; if F == 1 { Temp = a; a = b; b = Temp; } } Методи та засоби програмної інженерії 51 - две «цепочки» типа условный оператор в форме альтернативы и выбора; - три «звена» типа преобразова- тельного оператора (оператор присваива- ния); - один механизм, полученный путем последовательного соединения «це- почек». Таким образом, процесс конструи- рования подпрограммы, это использование конструкций-«звеньев», сочетание «звень- ев» (построение «цепочек») и построение «механизма» путем последовательного соединения «цепочек». «Механизм» – это «замкнутая» последовательность «цепо- чек» в смысле выполняемой функции, ко- торая, как известно у модуля должна быть одна. Очевидно, что полученная кон- струкция проста для понимания и модифи- кации, что является требованиями компо- нентного подхода. Подпрограммы. Программная конструкция на подпрограммном уровне инкапсуляции состоит из операторов и называется подпрограммой. Из подпро- грамм формируются библиотеки подпро- грамм, которые когда-то стали основой систем программирования. Сначала под- программы рассматривались как повто- ряющиеся части программ, которые пред- варительно описываются, хранятся от- дельно от программы или непосредствен- но в ней и многократно используются пу- тем встраивания вызовов подпрограмм в программу. Таким образом, подпрограм- мы служили средством сокращения тек- стов программ. Сейчас благодаря проце- дурной абстракции и абстракции управ- ления подпрограмма играет очень важную роль в модульной организации программ и их проектировании и является фунда- ментальной концепцией любого языка программирования, средством абстраги- рования и проектирования. Подпрограмма — это повторяющаяся часть программы, которая важна с двух точек зрения: во- первых, как средство сокращения затрат на запись программы, во-вторых, как средство проектирования программ. На подпрограммном уровне инкапсуляции содержимое капсулы, составленное из структурных операторов методом струк- турного программирования, не интересует программиста, поэтому основной интерес представляет оболочка капсулы и, в част- ности ее интерфейс. Оболочка капсулы открытой подпрограммы не существует после ее вызова, поэтому она «непроч- ная», а содержимое капсулы, видно про- граммисту. Оболочка закрытой подпро- граммной капсулы существует и после вызова, хотя ее содержимое также видно программисту, но она более «прочная», чем оболочка капсулы структурного опе- ратора. Степень «прочности» определяет- ся оператором go to. Если для капсулы структурного оператора переход в нее и выход из нее оператором go to запрещены организационно, то в подпрограммной капсуле (закрытая подпрограмма) это не- возможно уже конструктивно. Поэтому часть оболочки подпрограммной капсулы должна играть роль интерфейса (рис. 5). go to Интерфейс капсулы Оболочка капсулы Тело капсулы Взаимодействие с капсулой Рис. 5. Капсула подпрограммы Интерфейс обеспечивает связь внешнего окружения капсулы с компонен- тами, размещенными в середине капсулы. По определению инкапсуляции подпро- граммного уровня следует, что подпро- граммная капсула – это последователь- ность структурных операторов, «поме- щенных» в оболочку. Порядок размещения операторов в капсуле соответствует алго- ритму решаемой капсулой задачи. Отражая сущность процедурной абстракции, поня- тие подпрограммной капсулы позволяет программисту-читателю абстрагироваться от того, как решает задачу капсула, и со- средоточиться на том, какую задачу она решает. Методи та засоби програмної інженерії 52 Подпрограммную капсулу можно рассматривать как «черный ящик», на вход которого передается управление, а на вы- ходе управление возвращается. В резуль- тате передачи управления и выполнения операторов капсулы можно получить по- лезный эффект, который найдет отражение в векторе состояния программы, в точке после вызова подпрограммы. Такой взгляд на подпрограмму составляет сущность абстракции управления. Таким образом, закрытая подпрограмма – это не столько средство сокращения записи текста про- граммы (как считалось ранее), сколько средство разложения (декомпозиции) про- граммы на логически связанные, закон- ченные и, в определенном смысле, закры- тые компоненты. Перед началом разработ- ки программы программист имеет более или менее точную формулировку задачи в терминах некоторого домена и инструмент – язык программирования. Говорят, что между сформулированной задачей и язы- ком программирования существует кон- цептуальноя расстояние, которое преодо- левается с помощью программирования [14]. Абстрактные типы данных – это фун- даментальная концепция программирова- ния, которая направляет как замыслы раз- работчиков языков программирования, так и повседневные действия программистов. Для первых, абстрактный тип данных – это та концепция, которую должен эффектив- но реализовать язык программирования, а для вторых – это, тот продукт, который должен создавать программист в любом домене. Подпрограммный уровень инкап- суляции позволяет реализовывать аб- страктные типы данных, но очень неэф- фективно. Именно это является причиной того, что требуется применение возможно- стей классного или модульного уровней инкапсуляции. Именно на эффективную реализацию абстрактных типов данных и направлены возможности этих уровней инкапсуляции. Класс и модуль – компо- ненты, которые обычно представляют аб- страктный тип данных. Модуль. На сегодня известно две схемы реализации пост подпрограммного уровня инкапсуляции – композиционная и классификационная. Обе существуют од- новременно. Первая используется на мо- дульном уровне инкапсуляции, а вторая - на классном. Обе схемы строятся на осно- ве понятия отношения между компонента- ми схемы. Различия проявляются в разной интерпретации понятия отношение в схе- мах как при организации сред (библиотек, коллекций) из программных компонентов (модулей или классов), так и при их ис- пользовании. При разработке программ, которые состоят из большого количества частей, основное требование разложения программы на составные части приобрета- ет первостепенное значение. Разложив большую задачу на части, можно получить задачи-компоненты с таким количеством деталей, когда ее можно реализовать, а каждый компонент можно реализовывать отдельно и независимо. Такое разложение, которое реализуется на основе независи- мой компиляции, абсолютно необходимо, если в разработке программы участвует более одного программиста. Образующие- ся в результате разложения задачи реали- зуются частями программы, которые назы- ваются в процедурном программировании – подпрограммы, в композиционном про- граммировании – модули или пакеты. Мо- дуль – это капсула, которая инкапсулирует данные и подпрограммы. В ограниченном виде модуль ввел Н. Вирт в языке Pascal, а наибольшего развития он приобрел в язы- ках Modula-2, Modula-3 и Аdа. В языке Аdа модуль называется пакетом. Другое требование – сокрытие де- талей реализации модулей приводит к то- му, что модуль обычно подается двумя конструкциями. В первой – интерфейсе – описываются ресурсы (сервисы), которые представляет модуль (в зависимости от типа модуля). Во второй – описываются реализации ресурсов, поданных интерфей- сом модуля. Таким образом, любая капсу- ла-модуль состоит из интерфейса и инкап- сулированных конструкций (рис. 6). Меха- низм экспорта и импорта действует через перечень экспортируемых ресурсов (типы, объекты и подпрограммы), описанных в модуле определения и перечень импорти- руемых ресурсов, объявленных в модуле реализации. Обычно, при обучении осно- вам программирования различают модули, Методи та засоби програмної інженерії 53 которые поставляют с языком программи- рования и реализуют, например, ввод/вывод. Тело модуля (реализация сервисов) Интерфейс модуля (описание сервисов) Рис. 6. Капсула модуля Модульное программирование – это метод создания программ из программ- ных конструкций модулей, который при- меняется на модульном уровне инкапсу- ляции. Он основывается на механизме раздельной компиляции, который наряду с указанным устройством модуля обеспе- чивает полное сокрытие информации о реализации модуля. Суть механизма за- ключается в том, что обе части модуля (интерфейс и реализация) компилируются раздельно. Благодаря этому в случае из- менения реализации ресурсов (с сохране- нием ее интерфейсов) в перекомпиляции нуждаются только модули реализации и не требует программа, в которой приме- нены соответствующие модули определе- ния. Модульное программирование назы- вается еще композиционным программи- рованием. Альтернативой ему является классификационное программирования, реализацией которого является объектно- ориентированное программирование. Вы- деление программного модуля влияет на программирование в трех аспектах: - понятность – программа понят- на, если она состоит из модулей; - эффективность – программа ра- ботает более эффективно, поскольку мо- дуль позволяет рационально организовать структуру текста; - тестируемость – программа легче тестируется, если она модульная. Классы. Концепция объектно- ориентированного программирования ис- торически тесно связана с концепцией универсального языка программирования, которая интенсивно разрабатывалась в 70х. Основными принципами объектно- ориентированного программирования яв- ляются наследование и полиморфизм. Для реализации полиморфизма в объектно- ориентированном программировании кро- ме раннего связывания – механизма, кото- рый обеспечивает установление связи между интерфейсом программной кон- струкции и одной из реализаций (форм) конструкции, предусмотренных для нее, во время компиляции, вводится позднее свя- зывание – установление указанной связи во время выполнения программы. Кроме основных могут применяться дополни- тельные принципы: параметризация, мно- гократное и повторное использование. Многократное использование (systematic reuse) – принцип, обеспечивающий созда- ние, так называемых типовых программ- ных конструкций (компонентов), которые можно использовать многократно. Этим принципом в модульном и объектно- ориентированном программировании ру- ководствуются при проектировании моду- лей и классов. Повторное использование (reuse) – принцип, который обеспечивает использование наследуемого программно- го обеспечения в новых разработках. Лю- бой класс как программная конструкция в целом, также как модуль состоит из ин- терфейса и тела (рис. 7). Интерфейс опи- сывает ресурсы, которые предоставляются классом. Тело состоит из конструкций, описывающих реализацию ресурсов, кото- рые предоставляет класс. В зависимости от конкретного языка программирования строение класса может отличаться. Тело класса (реализация методов) Интерфейс класса (описание данных и методов) Рис. 7. Капсула класса Поскольку класс, как правило – это абстрактный тип данных, то тело класса и также, как и модуля должно содержать описание следующих компонентов: Методи та засоби програмної інженерії 54 - значений, предоставляемых аб- страктным типом данных (классом) - подпрограмм, обеспечивающих обработку значений абстрактного типа данных (класса). Важно, что класс, в отличии от мо- дуля не реализует важный принцип моду- ляризации – сокрытие информации. Он реализуется либо схемой, имитирующей раздельную компиляцию (подобно мо- дульному сокрытию), либо путем введения дополнительных понятий в язык програм- мирования. Мегамодули. Системы систем. Понятие мегамодуля введено в работе [15], и в отличие от модуля инкапсулирует не только данные и операции, но и поведение и доменные знания, отражающие, в част- ности, языки, культуры и традиции. При этом, несколько мегамодулей могут вхо- дить в мегапрограмму, которая пишется на языке мегапрограммирования. Позднее, было введено понятие системы систем (system of systems), которое по сути явля- ется мегапрограммой [16]. Так как про- граммирование системы систем значи- тельно сложнее основ программирования, этот класс модулей и составление из них систем должен изучаться в отдельной дис- циплине, например, при подготовке маги- стров. Дидактика основ программирования В 2006 г. постановлением Кабинета Министров Украины было открыто новое направление обучения 6.050103 «Про- граммная инженерия». Сейчас, это 121 специальность «Инженерия программного обеспечения». Был разработан соответ- ствующий стандарт для подготовки бака- лавров [17]. Новое направление обучения, очевидно требует собственного учебно- методического обеспечения, поскольку, например, от направления «Компьютерные науки» его отличает четкая инженерная направленность. Дисциплины учебного плана этого направления должны как мож- но больше учитывать указанную направ- ленность. К сожалению, в основном из-за нехватки грамотных, в смысле инженерии программного обеспечения, педагогиче- ских кадров, в университетах сложилась ситуация, которая характеризуется тем, что не только не выдерживается соответ- ствующий стандарт «в большом», но и «в малом», особенно в дисциплинах, которые перешли, например, из Компьютерных наук. Это относится и к дисциплине «Ос- новы программирования», которая препо- дается как правило на первом курсе уни- верситета. Поэтому не удивительно то, что отрасль по-прежнему недовольна уровнем подготовки студентов, и как следствие несет огромные затраты по «доводке» сту- дентов до требуемого уровня [18]. Прини- мая во внимание, то, что в отрасли ката- строфически не хватает грамотных про- граммистов, дидактика дисциплины «Ос- новы программирования» приобретает особое значение. На основе конструктивного подхода к программе, изложенного в статье по- строена дидактика основ программирова- ния, которая реализована в учебном посо- бии автора [19]. Известно два подхода к преподава- нию основ программирования [20]: - императивный (imperative-first) – традиционный подход, в котором изло- жение основ осуществляется, начиная с императивных аспектов языка программи- рования: выражения, управляющие струк- туры, процедуры и функции и другие ос- новные элементы процедурных языков программирования. Объектно-ориентиро- ванное программирование рассматривает- ся позже в другой дисциплине; - объектно-ориентированный (ob- jects-first) – с самого начала обучения главное внимание уделяется объектно- ориентированному программированию, объясняя понятие класса, объекта и насле- дования, затем предлагают студентам написать объектно-ориентированные про- граммы. Позже вводятся императивные аспекты объектно-ориентированного языка программирования. Традиционно, в Украине использу- ется только первый подход при обучении основам программирования. Это ведет к тому, что, когда начинается обучение объектно-ориентированному программи- Методи та засоби програмної інженерії 55 рованию студенты с трудом усваивают такие концепции как класс, объект, насле- дование, полиморфизм, виртуальные функции, и еще труднее даётся понимание специальных конструкций языков (интер- фейсы, делегаты), ориентированных на реализацию модульности. Автор делал попытку, применения второго подхода при обучении. Опыт по- казал, что такая подача конструкций про- грамм также затрудняет обучение. Не- большой начальный опыт в объектно- ориентированном программировании с последующим переключением на проце- дурное программирование только запуты- вает студента. Вероятно, проблем бы не было или было меньше, если изучать «чи- стый» объектно-ориентированный язык подобный SmallTalk, но это не привлекает студентов в Украине, в перспективе трудо- устройства. Многолетний опыт автора в исполь- зовании изложенного в статье конструк- тивного подхода показал, что он понятен студентам и позволяет на общей основе осваивать как сложные конструкции импе- ративной части – переменная, ссылка, ука- затель, подпрограммы, и механизмы – разыменование, приведение типов, так и конструкции модульной части – модули, классы, объекты, и механизмы – сокрытие, полиморфизм, наследование. Конструк- тивный подход знакомит студентов не только с традиционно распространённым в Украине объектно-ориентированном про- граммировании, но с менее известным у нас – модульным программированием. Кроме этого, студенты с первых занятий осознанно настраиваются на применение повторного и многократного использова- ния, понимая цели и задачи компонентной инженерии программного обеспечения. Дидактика основ программирова- ния, основанная на конструктивном под- ходе, базируется на понятии конструкции и структурирует изложение учебного ма- териала в соответствии с уровнями инкап- суляции (табл.). Для объяснения устрой- ства конструкций широко используются графические схемы подобные тем, что бы- ли введены в работах [21, 22] (например, рис. 1). Выводы Известно два подхода к преподава- нию основ программирования: - императивный – традиционный подход, в котором изложение основ осу- ществляется, начиная с императивных ас- пектов языка программирования; - объектно-ориентированный – с самого начала обучения главное внимание уделяется объектно-ориентированному программированию. В контексте инженерии программ- ного обеспечения для обучения студентов основам программирования целесообразно использовать конструктивный подход, ко- торый подготовит студентов к созданию и сопровождению программного обеспече- ния методами многократного и повторного использования в рамках парадигмы ком- понентной разработки. Литература 1. Boehm B., 2006, A View of 20 th and 21 st Cen- tury Software engineering [Text]. ICSE’06. May 20–28. China. 2006. P. 12–29. 2. Report on a conference sponsored by the NATO science committee, Garmisch, Germa- ny, 7th to 11th October 1968, Editors: Peter Naur and Brian Randell. 3. Segmentation and Design Strategies for Mod- ular Programming." In T. O. Barnett and L. L. Constantine (eds.), Modular Programming: Proceedings of a National Symposium. Cambridge, Mass.: Information & Systems Press, 1968. 4. Wirth N. Programming in Modula-2. Spring- er-Verlag, Heidelberg, New York, 1982. 5. Jean Ichbiah (October 1984). «Ada: Past, Present, Future – An Interview with Jean Ichbiah, the Principal Designer of Ada». Communications of the ACM. 27 (10). P. 990–997. doi:10.1145/358274.358278. 6. Dahl O.-J., Myhrhaug B., Nygaard K. SIMU- LA67, Common base language/-Oslo. 1968. 96 p. 7. Hoare C.A.R. An axiomatic basis for comput- er programming, Comm. Of ACM, 12(1969). P. 576–580. http://doi.acm.org/10.1145/358274.358278 http://doi.acm.org/10.1145/358274.358278 http://doi.acm.org/10.1145/358274.358278 http://doi.acm.org/10.1145/358274.358278 https://ru.wikipedia.org/wiki/Communications_of_the_ACM https://ru.wikipedia.org/wiki/%D0%98%D0%B4%D0%B5%D0%BD%D1%82%D0%B8%D1%84%D0%B8%D0%BA%D0%B0%D1%82%D0%BE%D1%80_%D1%86%D0%B8%D1%84%D1%80%D0%BE%D0%B2%D0%BE%D0%B3%D0%BE_%D0%BE%D0%B1%D1%8A%D0%B5%D0%BA%D1%82%D0%B0 https://dx.doi.org/10.1145%2F358274.358278 Методи та засоби програмної інженерії 56 8. Goldberg A., Robson D. SmallTalk 80 The language and its implementation, Addison- Wesley, New-York, 1983. 9. Maier M.W. Architecting principels for sys- tems-of-systems, Systems engineering, 1, 4(1998). P. 267–284. 10. Энгельмейер П.К. Философия техники, М. 1912. 11. Redtenbacher F., Der Maschinbau, Mannheim, 1862. 12. Boehm B.W. Improving Software Productivi- ty. Computer. 1987. Vol. 20, N 9. P. 43–57. 13. Сидоров Н.А. Применение принципов про- граммной инженерии в преподавании ос- нов программирования. Управляющие си- стемы и машины. 1998. № 4. С. 50–59. 14. Дал У., Дейкстра Э., Хоор К. Структурное программирование = Structured Programming. 1-е изд. М.: Мир, 1975. 247 с. 15. Widerhold G., Wegner P., Ceri S., Toward megaprogramming. Communication of the ACM. 1992. Vol. 35, N 11. P. 89–99. 16. System of systems engineering, ed.by Jam- shidi M., John Wiley&Sons, 2009, 591 p. 17. Сидоров Н.А. Инженерия программного обеспечения – учебная дисциплина или подготовка бакалавра? Управляющие си- стемы и машины. 2006. № 2. С. 25–34. 18. It Ukraine from a to z, http://www.uadn.net/files/ua_hightech.pdf 19. Сидоров М. Основи програмування. Київ, 2018, 435 с. 20. Bennedsen J., Teaching and Learning Intro- ductory Programming, – A Model-Based Ap- proach. 327 p. 21. Линдси Ч., ван дер Мюйлен С., Нефор- мальное введение в Алгол 68, М., Мир, 1973. 22. Баррон Д., Введение в языки программи- рования, М., Мир, 1980. 189 с. Referenses 1. Boehm B., 2006, A View of 20 th and 21 st Cen- tury Software engineering[Text]. ICSE’06.- May 20–28 China. 2006. P. 12–29. 2. Report on a conference sponsored by the NATO science committee, Garmisch, Germany, 7-th to 11-th October 1968, Editors: Peter Naur and Brian Randell. 3. Segmentation and Design Strategies for Modular Programming." In T. O. Barnett and L. L. Constantine (eds.), Modular Programming: Proceedings of a National Symposium. Cambridge, Mass.: Information & Systems Press, 1968. 4. Wirth N. Programming in Modula-2. Springer-Verlag, Heidelberg, New York, 1982. 5. Jean Ichbiah (October 1984). «Ada: Past, Present, Future — An Interview with Jean Ichbiah, the Principal Designer of Ada». Communications of the ACM 27 (10): 990–997. DOI:10.1145/358274.358278 6. Dahl O.-J., Myhrhaug B., Nygaard K. SIMU- LA67, Common base language/-Oslo, 1968, 96 p. 7. Hoare C.A.R. An axiomatic basis for comput- er programming, Comm. Of ACM, 12 (1969). P. 576–580. 8. Goldberg A., Robson D. SmallTalk 80 The language and its implementation, Addison- Wesley, New-York, 1983. 9. M.W.Maier Architecting principels for sys- tems-of-systems, Systems engineering, 1, 4(1998). P. 267–284. 10. Engelmeyer. P. C. Philosophy of technology. М., 1912. 11. Redtenbacher F., Der Maschinbau, Mann- heim, 1862. 12. Boehm B.W. Improving Software Productivi- ty. Computer. 1987. Vol. 20, N 9. P. 43–57. 13. Sydorov M. Using the software engineering principals in basics programming education, USIM. 1998. N 4. P. 50–59. 14. Dijkstra E.W. Structured Programming. 1975. 247 p. 15. Widerhold G., Wegner P., Ceri S. Toward megaprogramming. Communication of the ACM. 1992. Vol. 35, N 11. P. 89–99. 16. System of systems engineering, ed.by Jam- shidi M., John Wiley&Sons, 2009, 591 p. 17. Sydorov M. Is the software engineering edu- cation subject or postgraduate, USIM. 2006. N 2. P. 25–34. 18. It Ukraine from a to z, http://www.uadn.net/files/ua_hightech.pdf 19. Sydorov M., Basics of programming, Kiev 2018, 435 p. 20. Bennedsen J. Teaching and Learning Intro- ductory Programming, – A Model-Based Ap- proach. 327 p. https://www.google.de/search?hl=ru&tbo=p&tbm=bks&q=inauthor:%22Ferdinand+Redtenbacher%22 https://ru.wikipedia.org/wiki/%D0%A5%D0%BE%D0%B0%D1%80,_%D0%A7%D0%B0%D1%80%D0%BB%D1%8C%D0%B7_%D0%AD%D0%BD%D1%82%D0%BE%D0%BD%D0%B8_%D0%A0%D0%B8%D1%87%D0%B0%D1%80%D0%B4 http://www.uadn.net/files/ua_hightech.pdf http://doi.acm.org/10.1145/358274.358278 http://doi.acm.org/10.1145/358274.358278 http://doi.acm.org/10.1145/358274.358278 http://doi.acm.org/10.1145/358274.358278 https://ru.wikipedia.org/wiki/Communications_of_the_ACM https://ru.wikipedia.org/wiki/%D0%98%D0%B4%D0%B5%D0%BD%D1%82%D0%B8%D1%84%D0%B8%D0%BA%D0%B0%D1%82%D0%BE%D1%80_%D1%86%D0%B8%D1%84%D1%80%D0%BE%D0%B2%D0%BE%D0%B3%D0%BE_%D0%BE%D0%B1%D1%8A%D0%B5%D0%BA%D1%82%D0%B0 https://dx.doi.org/10.1145%2F358274.358278 https://www.google.de/search?hl=ru&tbo=p&tbm=bks&q=inauthor:%22Ferdinand+Redtenbacher%22 http://www.uadn.net/files/ua_hightech.pdf Методи та засоби програмної інженерії 57 21. Lindsey C., van der Meulen S., Informal in- troduction to ALGOL 68, London, 1971. 22. Barron D.W. An introduction to the study of programming languages, Cambridge universi- ty press, London, 1977. Получено 18.07.2019 Об авторе: Сидоров Николай Александрович, доктор технических наук, профессор. Количество научных публикаций в украинских изданиях – 118. Количество научных публикаций в зарубежных изданиях – 12. http://orcid.org/0000-0002-3794-780X Место работы автора: Национальный Технический Университет Украины «Киевский политехнический институт имени Игоря Сикорского», факультет информатики и вычислительной техники, кафедра автоматизированных систем обработки информации и управления, АСОИУ, профессор. 02000, Киев, ул. Политехническая, 41. Моб. тел.: 067 7980361. Тел.: 044 2343600. E-mail: nikolay.sidorov@livenau.net, sna@nau.edu.ua http://asu.kpi.ua/ http://asu.kpi.ua/ http://asu.kpi.ua/ mailto:nikolay.sidorov@livenau.net mailto:sna@nau.edu.ua

Основы программирования в контексте инженерии программного обеспечения

Репозитарії

Схожі ресурси