CC BY
145
ЭВОЛЮЦИЯ МЕТОДОВ И ТЕХНОЛОГИЙ ПРОГРАММИРОВАНИЯ Е.Б. Боб, А.В. Латников, А.М. Мальцев, А.Е. Потехин Научный руководитель - д.т.н., профессор А.А. Шалыто
В статье приводится анализ недостатков объектно-ориентированного метода программирования и соответствующих технологий. Предлагается использование технологии автоматного программирования в качестве альтернативы объектно-ориентированному программированию.
Введение
В данной статье рассматриваются основные этапы развития методов и технологий программирования, а также поднимается вопрос об основных причинах, повлекших описанный процесс. Анализ недостатков объектно-ориентированного программирования (ООП) как метода программирования, а также соответствующих технологий [1], позволяет поставить под сомнение возможность дальнейшего развития этого направления. Авторами предлагается использовать технологию автоматного программирования [2] в качестве альтернативы ООП, что позволит устранить существующие недостатки, а также ускорить технологический процесс, одновременно улучшив такие качества программного продукта, как надежность, масштабируемость и переносимость.
Эволюция методов программирования
У истоков всех языков программирования лежат машинные коды. Формально, возможно, даже неправильно называть их именно языком, так как программирование в чистом виде представляло собой не какую-нибудь абстракцию, а жесткое задание инструкций аппаратуре, которые должно было выполнить вполне конкретное компьютерное «железо». Важно отметить, что программа в то время полностью соответствовала своему поведению, иными словами, невозможна была ситуация, когда программа выполняла действия, которые не мог объяснить программист. Отчасти это следствие относительной простоты программ, отчасти - досконального знания архитектуры компьютера самим программистом. Процесс программирования был сложным, но вместе с тем прозрачным.
Первым шагом к абстрагированию программиста от компьютерного «железа» стал язык ассемблера. Впервые появилось некое подобие переносимости программ -для семейства машин со схожим набором инструкций возможно было написать одну ассемблерную программу, демонстрировавшую одинаковое поведение для всех представителей этого семейства. Однако наиболее значительный шаг с точки зрения эволюции - появление компилятора как промежуточного звена в цепочке «программист -компьютер». Отныне программист, с одной стороны, освобождался от необходимости досконально изучать архитектуру той машины, с которой работал, а с другой - целиком полагался на «интеллект» компилятора, своеобразного переводчика с языка программирования на язык, понятный машине.
Дальнейшее направление развития языков программирования вполне очевидно -раз появилась возможность абстрагировать программиста от платформы, необходима разработка как можно более универсальных средств такой абстракции. Фортран, Кобол, Бейсик, Паскаль, Си - все это отдельные точки на выбранном маршруте.
Отдельной вехой в развитии методов программирования стоит выделить появление объектно-ориентированных языков, первым из которых стал язык Simula, предложенный в 1967 г. [3]. Впоследствии объектно-ориентированные надстройки появились практически для всех используемых на тот момент языков программирования. Наиболее популярный пример - язык Си+ + .
Здесь стоит еще раз остановиться именно на методах программирования вне зависимости от используемых языков. От оперирования машинными кодами программисты постепенно уходили ко все более абстрактным операциям - инструкциям, процедурам, структурам, классам. Несложно заметить, что эволюция пошла по пути упрощения структуры языка - по пути упрощения программирования для самих программистов. Следствиями такого подхода являются:
• универсализация языков программирования с точки зрения решаемых задач и архитектуры компьютера;
• усложнение программ за счет введения все большего числа абстрактных понятий и структур;
• как следствие, тотальное усложнение компиляторов, обеспечивающих согласование «абстрактных структур», которыми оперирует программист, с тем, что реально работает «в железе».
Последнее - основная причина неэффективного использования компьютерных ресурсов. «Неэффективные программы - отнюдь не кощунство. Кощунство - это языки, которые заставляют программистов выполнять ненужную работу. Не расход машинного времени, а пустая трата времени программиста - вот истинная неэффективность» [4].
Как отмечалось выше, наиболее распространенным методом программирования в настоящее время является ООП. Конечно, оно обладает рядом существенных преимуществ по сравнению с теми методами, которые стоят ниже по эволюционной лестнице [5]:
• унификация принципов работы с типами данных, возможность определять новые типы совместно с методами их обработки;
• расширяемость и модульность кода;
• наглядность структуры программного кода;
• локализация данных и методов, объединенных определенными логическими отношениями.
Не стоит забывать при этом и про очевидные недостатки ООП, среди которых стоит особо выделить трудности при описании поведения объектов и программ в целом. Иногда под термином «поведение» ошибочно понимают набор методов, которые предоставляет класс. Однако набор методов - это всего лишь список тех действий, которые объект может выполнить над другими объектами. Этот набор лишен логической последовательности, которая и определяет поведение. Поэтому появляется необходимость в сложной и запутанной документации, которая призвана хоть как-то улучшить понимание программ.
К недостаткам ООП также можно отнести и неэффективное использование компьютерных ресурсов, о котором уже упоминалось выше. Использование сторонних библиотек со скрытой реализацией и недостаточно подробной документацией может отрицательно сказаться на производительности продукта. При этом ООП не позволяет добиться значительного улучшения продуктивности разработки по сравнению с процедурным программированием [6].
Одним из способов устранить или хотя бы сгладить недостатки методов программирования является изменение, а зачастую и усложнение, технологического процесса разработки.
Современный технологический процесс
В любой организации, занимающейся разработкой программного обеспечения, существует некоторый набор правил и методик, согласно которому сотрудники выпускают программный продукт. Эти правила могут быть тщательно задокументированы или же, наоборот, хаотичны, но именно они и называются процессом разработки.
Одной из наиболее известных моделей процесса разработки является «модель водопада» (Waterfall), предложенная еще в 70-х гг. XX века. После нее появилось множество самых разнообразных процессных моделей: итеративная, спиральная, Rational Unified Process, eXtreme Programming и т.д. Существуют даже международные стандарты на процессы разработки (ISO 9000, CMM/CMMI) [7, 8].
Основной причиной такого многообразия является желание уменьшить производственный цикл, не ухудшив конечный результат - сам программный продукт. В качестве оптимального решения предлагается использовать ту или иную модель в зависимости от размеров проекта: сложности продукта, количества программистов в команде и т.д. Тем не менее, ни одна модель пока не принесла действительно значительных улучшений [9].
Следует отметить, что фазы технологического процесса практически не изменяются. В зависимости от процессной модели может изменяться порядок или взаимодействие фаз друг с другом. Некоторые модели предлагают методики и инструментальные средства для использования на каждой фазе.
В таблице приведены общепринятые фазы процесса разработки [10], а также примерное процентное соотношение временных затрат на каждую фазу для моделей Waterfall и eXtreme Programming (таблица).
Фаза Описание Waterfall eXtreme Programming
Анализ требований к продукту Сбор требований к системе, их систематизация, документирование и анализ 20% 20%
Разработка архитектуры продукта Создание функциональной модели системы, удовлетворяющей требованиям 20% 10%
Кодирование Непосредственно программирование: перевод функциональной модели в программный код 10% 55%
Тестирование Проверка программы на соответ-стие требованиям и наличие внутренних ошибок 35%
Документирование Создание документации пользователя 15% 15%
Сопровождение Внедрение и поддержка готового продукта N/A N/A
Таблица. Фазы технологического процесса
Из таблицы видно, что в теории наименее длительными являются фазы документирования и кодирования (для модели Waterfall). Действительно, это вполне возможно, но только при тщательной и детальной разработке архитектуры программы, что, к сожалению, крайне редко. На практике усилия на кодирование значительно увеличиваются за счет ошибок и неточностей при сборе требований и разработке архитектуры.
Для компаний по производству программного обеспечения обычно наивысший приоритет имеет срок сдачи продукта заказчику, а отнюдь не качество программы с точки зрения программирования. В ситуации, когда поставка продукта уже не за горами, а программа еще не готова, попытка уменьшить любую из фаз разработки приводит к ухудшению качества конечного продукта:
• при сокращении затрат на тестирование естественным образом уменьшается надежность системы;
• уменьшение затрат на разработку архитектуры приведет в первую очередь к более длительному циклу кодирования;
• сокращение фазы документирования отражается на качестве пользовательской документации. При этом не факт, что вообще кто-то поймет, как пользоваться программой;
• при сокращении фазы сбора и анализа требований появляется риск, что готовый продукт окажется совершенно не тем, что требовалось заказчику.
Наиболее затратной оказывается фаза сопровождения системы, которая может тянуться годами (конечно, если заказчик это оплачивает). Именно на этой фазе всплывают основные недостатки уже готового продукта, и именно тогда разработчики начинают ощущать последствия непродуманной архитектуры и непрозрачного кода. Ошибочная функциональная модель продукта, незадокументированный код увеличивают время исправления каждой ошибки в десятки раз.
Попробуем более детально разобраться в причинах, которые зачастую не позволяют реализовать приведенную «идеальную» модель в реальных проектах.
Вспомним три постулата ООП: наследственность, полиморфизм и инкапсуляция данных. Это не что иное, как структурные требования. Как уже отмечалось выше, средствами объектно-ориентированных языков очень сложно описать поведение программы, в то время как именно к поведению выдвигаются основные требования. Поэтому несколько искусственно выглядят модели поведения программ на этапе проектирования - гарантировать точное сответствие поведения реальной программы и ее модели могут только программисты. Даже если архитектура программы составлена корректно, на этапе кодирования она может быть неточно перенесена в программу из-за того, что программисты используют средства ООП. В этом случае возникают дополнительные временные затраты на тестирование - проверку соответствия программы той схеме, что была спроектирована. Таким образом, помимо проверки соответствия программного продукта требованиям, приходится проводить дополнительное тестирование для проверки соответствия кода спроектированной модели, что на самом деле является еще одним недостатком используемой технологии ООП.
Кроме дополнительных затрат на тестирование, возникает необходимость дополнительного документирования кода. Ведь разработанную архитектуру нельзя считать полноценной документацией, так как она отражает лишь желаемую модель, которой должен соответствовать итоговый продукт. Важно подчеркнуть, что соответствие продукта архитектурной модели является негласным требованием и также нуждается в тестировании и документировании.
Здесь может быть скрыта еще одна проблема. В теоретической модели процесса создание документации происходит лишь после того, как написан код и проведено тестирование. Однако документация необходима не только заказчику продукта, но и программистам, которые впоследствии будут поддерживать выпущенный продукт. Соответственно, необходимо, чтобы документация охватывала все стадии разработки от сбора требований до тестирования. Поэтому на практике проектная документация обычно накапливается в течение всего цикла разработки. Таким образом, помимо необходимости обеспечить соответствие модели программы и ее реального кода, необходимо также поддерживать единство документации, создаваемой в ходе разработки.
Для этого разработчики на каждом этапе стараются переиспользовать ту часть документации, что была создана ранее. Например, на этапе кодирования необходимо создавать лишь ту часть документов, которые описывают существенные аспекты реализации, но не затрагивают поведенческую модель, разработанную и задокументированную на этапе проектирования.
Это опять же, является новым требованием, которое по своей сути является очередным недостатком технологии ООП. Невыполнение этого требования обычно приводит:
• либо к полному несоответствию документов на архитектуру и на код, что, в свою очередь, выливается в удвоенные затраты на документирование модели поведения программы (первый раз - на этапе проектирования, второй раз - на этапе кодирования, чтобы обеспечить полноту документации);
• либо к необходимости реструктуризации кода с точки зрения требований к документации (выглядит опять же несколько искуственно);
• либо к дополнительным, часто даже не планируемым, затратам на этапе поддержки.
Таким образом, сокращение общего цикла разработки программного продукта невозможно за счет сокращения хотя бы одной из его фаз - обязательно пострадает сам продукт. С другой стороны, из-за недостатков используемой технологии ООП появляются дополнительные временные затраты, которых можно избежать, выбрав в качестве основы процесса разработки технологию автоматного программирования [11].
Автоматное программирование - хорошо забытое старое
Традиционное место использования автоматов в классическом процессе разработки программного обеспечения - этап проектирования, когда создается графическое представление модели программы в виде конечного автомата. Это позволяет, во-первых, явно определить все состояния, в которых может находиться программа, во-вторых, описать входные и выходные воздействия, в-третьих, при необходимости провести формальную верификацию модели программы, что, в свою очередь, позволит сократить время тестирования конечного продукта, а также повысить надежность всей системы. Впервые явно выделять состояния программы было предложено в языке SDL (Specification and Description Language, ITU-T Recommendation Z.100), который до сих пор является признанным стандартом описания телекоммуникационных протоколов [12].
Возможно, именно из-за того, что автоматный подход используется в основном для описания модели поведения программы, большинство программистов ассоциирует термин «конечный автомат» именно с «картинкой», представлением, которым следует руководствоваться при написании кода программы, используя современные (объектно-ориентированные) языки программирования. Именно из-за этого возникают сложности с сокращением цикла разработки, о которых упоминалось выше.
Для того чтобы та или иная технология программирования нашла свое отражение в виде признанного промышленного процесса, необходимо как минимум три вещи: строгая математическая модель, наглядное (желательно графическое) представление этой модели - нотация и инструментальное средство разработки программ в заданной нотации [13]. При этом необходимо обеспечить согласованность всех трех составляющих: если уж в качестве математической модели широко используется конечный автомат, разработаны и стандартизованы графические средства представления программ с использованием автоматов, то остается выполнить последний шаг - перенести автоматы в программы, или, точнее, писать программы «в автоматах».
Отметим, что существуют инструментальные средства, позволяющие из описания программы (с использованием диаграмм состояний), получить программный код на выбранном целевом языке программирования. Чаще всего недостатком таких средств является их ориентированность на использование в рамках сложившегося процесса разработки, а следовательно привязанность к определенным языкам программирования [14].
В [15] полностью описан технологический процесс создания программного продукта при использовании технологии автоматного программирования совместно с существующими языками программирования. Преимущества использования автоматного подхода при программировании очевидны:
• единство поведенческой модели программы, разработанной на этапе проектирования, и самой программы фактически избавляет от необходимости тестирования кода на соответствие архитектуре. Более того, архитектура программы уже является не просто преставлением - это управляющий автомат, целиком и полностью задающий поведение программы;
• исчезает необходимость документирования кода в части поведения: если код по сути является управляющим автоматом, исчерпывающей документацией является сам автомат;
• появляется возможность повысить надежность конечного продукта за счет верификации автомата, задающего логику работы системы.
Таким образом, использование технологии автоматного программирования позволяет устранить существующие недостатки, описанные выше. Однако остается открытым вопрос использования ООП совместно с автоматным подходом. В [15], например, предлагается применять автоматный подход в качестве дополнения к существующей технологии ООП. В таком случае необходимо, чтобы автомат стал основной базовой конструкцией языка программирования, чтобы обеспечить изоморфность программы и диаграммы состояний на протяжении всего цикла жизни программного продукта, особенно в процессе поддержки, когда код может быть неодократно модифицирован.
Использование автоматов на этапе программирования фактически упраздняет многие языковые конструкции современных языков программирования. Более того, в [14] отмечается, что модель программы в виде конечного автомата является исполнимой, что, по сути, избавляет от необходимости построения кода, так как программа является интерпретацией автоматной модели. Функциональная нагрузка на язык программирования, таким образом, сводится к описанию входных и выходных воздействий на автомат. Для этого программистам совершенно необязательно иметь весь тот инструментарий, который предоставляют современные языки программирования.
Упрощение языка программирования и превращение его в язык описания входных и выходных воздействий позволит также избавиться еще от одного существенного недостатка объектно-ориентированных языков - неэффективного использования компьютерных ресурсов. Компилятор программ превращается в таком случае в интерпретатор автоматной модели, снабженный сопроцессором, позволяющим выполнять выходные действия, которыми помечен автомат, а единственным представлением программы остается конечный автомат.
Описанная технология программирования, также как и технология автоматного программирования, базируется на понятии конечного автомата как основного элемента, явно определяемого на всех этапах разработки программного продукта. Но существенным отличием является отказ от процедуры кодогенерации на этапе программирования, а также сведение программирования как такового к описанию входных и выходных действий автомата на специальном языке программирования. Вместе с тем предлагаемая технология, вследствие отсутствия явного определения понятий «объект» и «отношение», является также альтернативой технологии ООП.
Заключение
Современные методы и технологии программирования являются вершиной долгого эволюционного процесса, в основе которого лежит желание сократить сложность программирования, внедряя новые уровни абстракции. Программисты тем самым освободились от необходимости детального изучения архитектуры платформы, для которой они пишут код, появились мощные средства разработки, сформировались четкие технологические процессы. Вместе с тем на первый план выходят требования к качеству итогового продукта, а также ко времени его разработки. И в свете этих требований
всплывают неочевидные до сих пор недостатки используемых методов и технологий программирования.
В данной работе предпринята попытка анализа этих недостатков, а также способов выхода из сложившейся ситуации, которые могли бы существенно изменить структуру современного технологического процесса.
Предагается использовать концепцию автоматного программирования на всех этапах разработки программного продукта, что позволит выдвинуть на первый план поведение разрабатываемого приложения. Таким образом, единственным представлением программы будет являться конечный автомат, а задача программиста сведется к описанию входных и выходных воздействий на специальном, сильно упрощенном, языке программирования.
В отличие от существующей технологии автоматного программирования [2], предлагается также отказаться от процедуры генерации программного кода из автоматного описания, введя понятие интерпретатора автоматных программ. Таким образом, поведенческая модель программы становится исполнимой и требует лишь описания входных и выходных воздействий.
Представление программы в виде конечного автомата будет использоваться на этапе разработки архитектуры, когда будет разрабатываться основная логика поведения программы, определяться входные и выходные воздействия, проводиться формальная верификация модели. Это же описание будет использоваться на этапе кодирования и оно же в итоге будет являться исполнимой программой.
Предлагаемая технология обладает всеми преимуществами технологии автоматного программирования и вместе с тем устраняет многие недостатки ООП, такие как, например, неэффективное использование компьютерных ресурсов.
Литература
1. Грэхем И. Объектно-ориентированные методы. Принципы и практика. 3-е изд. - М.: Издательский дом «Вильямс», 2004. - 880 с.
2. Шалыто А.А. Технология автоматного программирования / Труды Всероссийской научной конференции «Методы и средства обработки информации» - М.: МГУ. 2003. - с.528 - 535.
3. Sklenar J. Introduction to OOP in Simula / Proceedings of 30 Years of Object Oriented Programming. - University of Malta. 1997.
4. Грэм П. Языки программирования через сто лет. // Компьютерра-онлайн, 08.2004. -Режим доступа: http://www.computerra.ru/hitech/35042/
5. Moessenboeck H. Object-Oriented Programming in Oberon-2 - Springer-Verlag. 1993. -Режим доступа: http://www.uni-vologda.ac.ru/oberon/infoart/plusfcmin.htm
6. Thomas E. Potok, Mladen Vouk, and Andy Rindos. Productivity Analysis of Object-Oriented Software Developed in a Commercial Environment. //Software - Practice and Experience. - 1999. - № 10. - pp. 833-847.
7. M. Paulk, C. Weber, B. Curtis, M. Chrissis, et al. The Capability Maturity Model. - Addi-son-Wesley. 1995.
8. CMMI for Development. Version 1.2 / Carnegie Mellon Software Engineering Institute. -August 2006. ESC-TR-2006-008. - Режим доступа: http://chrguibert.free.fr/cmmi12/cmmi-dev/text/index.php
9. Askar Rahimberdiev Современные процессы разработки программного обеспечения». // RSDN Magazine. - 2006. - №4.
10. Макконнелл С. Профессиональная разработка программного обеспечения. - СПб: Символ-Плюс. 2007. - 240 с.
11. Шалыто А. А., Тукель Н.И. SWITCH-технология - автоматный подход к созданию программного обеспечения «реактивных» систем. //Программирование. - 2001. -№5. - С. 45-62.
12. Гольдштейн Б.С. Сигнализация в сетях связи. 3-е издание. - М.: Радио и связь, 2001. - 446 с.
13. Туккель Н.И., Шалыто А. А. Программирование с явным выделением состояний. // Мир ПК. - 2001. - №8. - С. 116-121, №9. - С. 132-138.
14. Гуров В., Нарвский А., Шалыто А. Исполняемый UML из России // PC Week, Russian Edition. - 2005. - № 26. - С. 18-19.
15. Шалыто А. А. SWITCH-технология. Алгоритмизация и программирование задач логического управления. - СПб: Наука, 1998. - 628 с.
