Файл: Применение объектно-ориентрованного подхода при проектировании информационной системы (Объектный подход при разработке программ).pdf

Введение

Есть ли на планете человек полностью понимающий, как работает хотя бы один современный лекарственный препарат?

Есть ли на планете человек знающий устройство и принцип работы хотя бы одной современной микросхемы?

Есть ли планете человек знающий, как устроена хотя бы одна современная компьютерная программа?

Для специалистов, работающих в соответствующих областях, ответ на заданные выше вопросы очевиден – нет!

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

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

Современный подход к разработке продуктов с использованием, так называемых, CASE-технологий [28] все больше отдаляет инженера от понимания принципов работы, создаваемых им изделий. Современный инженер не понимает принципов работы объектов, которыми он манипулирует (как кубиками «LEGO»). Стоит ли говорить о том, что подобный подход к производству рано или поздно приведет к непоправимым последствиям.

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

Все вышесказанное представляет собой актуальность темы исследования настоящей курсовой работы. Целью исследования является анализ опасности объектного подход к проектированию в современном мире. Объектный подход к проектированию является предметом исследования.

Настоящая работа не будет затрагивать банальные, хорошо исследованные темы объектных (классовых) языков программирования (C#, UML, SмallTalk и т.п.), а сосредоточена на опасностях, которые обязательно возникнут перед «объектно-ориентрованным» человечеством в будущем.

---

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

Вторая глава описывает предпосылки появления объектного проектирования в недалеком прошлом (именно в такой последовательности, тут нет ни какой ошибки в логике повествования!).

Третья глава подробно описывает опасности объектного проектирования, которые уже приводят и будут будущем в будущем к трагическим последствиям.

Литературы, посвященной опасности объектного подхода в проектирования, не просто мало, а ее вообще нет на книжном рынке, поэтому большая часть использованных источников информации по главной теме повествования являются сетевыми ресурсами. Описание принципов объектного подхода при проектировании ПО основано на книгах М. Вайсфельда [7] и Г. Буча [5].

Настоящая работа затрагивает проблемы не только объектного (модульного, классового, шаблонного) способа разработки программ, но и объектного способа разработки электронных, механических и других изделий, тем самым показывая, что модульность является тенденцией современного производства, описание этого изложено в книге В.Н. Княгинина [15] и в статьях сайта kmpu.ru [36].

Понятия «модуль» и «объект» в настоящей работе являются равнозначными.

1. Принципы объектного проектирования

1.1. Объектный подход при разработке электроники

В настоящее время имя «ардуино» (“arduino”) уже является нарицательным. Модульная технология создания электронной и роботизированной техники, разработанная в Италии, преподавателем местного института города Ивреа, Массимо Банци, получила всемирное распространение. Мотиватором к созданию технологии послужило желание М. Банци создать дешевую платформу для обучения своих студентов программированию электронных устройств. Уже существующие на том момент электронные платформы, были слишком дороги для обеспечения ими каждого студента [4].

Технология, разработанная Банцы представляла собой электронную плату, с дешевым микроконтроллером (ATmega328 [2]), Си++-подобным, объектным языком программирования, средой разработки (Arduino IDE) и огромным количеством готовых библиотек (классов, объектов, паттернов) для быстрого написания управляющих программ и подключения к плате наиболее распространенных, недорогих датчиков и исполнительных механизмов, рисунок 1.

---

Рисунок 1. Первый прототип платы «Arduino» (слева), коммерческий вариант платы «Ардуино» (справа)

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

Со временем многие фирмы начали выпускать ардуино-совместимые модули со стандартными интерфейсами подключения (UART, 1-wire, I2C, SPI [14]) и конструирование техники на основе «Ардуино» стало тривиальной задачей [12], которая по силам даже детям, рисунок 2.

Рисунок 2. Модули для подключения к плате «Adrduino»

Простота разработки устройств на основе «Ардуино» не говорит о том, что технология предназначается только для детей или для непрофессионалов. На основе данной технологии разрабатываются достаточно серьезные проекты, к которым относятся: космические аппараты, планетоходы, системы автоматизированного управления, летательные аппараты, робототехника и многое другое [34], рисунок 3.

Рисунок 3. Микро-спутник, созданный на «Ардуино»

Модульный подход к разработке электронных устройств отличается от модульного подхода к разработке программного обеспечения. Если программист имеет возможность создать недостающий модуль самостоятельно (для этого нужен только язык программирования и компьютер), то разработчик электроники манипулирует только имеющимися модулями, самостоятельно разработать и произвести недостающую микросхему разработчик электроники не может [36].

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

---

Естественно, что ни программист, использующий объектный подход программирования, ни человек, занимающийся модульным созданием электронных устройств, не понимают особенностей функционирования блоков, на основе которых они строят свою разработку [39]. Эти особенности функционирования блоков могут не проявлять себя значительное время, и даже могут быть не выявлены на стадии тестирования. Так, например, разработчикам устройств на «Ардуино» хорошо известна проблема нехватки ресурсов, когда разные устройства пытаются воспользоваться одним и тем же узлом микроконтроллера (например, каналом таймера), что приводит к сбою работы всей системы [4].

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

Модульная разработка устройств и программ, кроме очевидных различий, имеет некоторые сходства в части интерфейсов передачи данных между объектами. В обоих случаях они стандартизированы. Как известно, передача данных между методами класса (объекта) осуществляется либо через стек, либо через глобальные переменные или константы, либо через файл или сеть [13].

Передача данных между объектами модульных электронных устройств также осуществляется через широко-распространенные каналы связи: UART, I2C, 1-WIRE, SPI, JTAG и их модификации: RS-232, RS-485, RS-422, USB, USART, SBUS, CAN и др.

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

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

---

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

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

Подводя итог, можно сказать, что объектное (модульное) проектирование электронных устройств обладает похожими преимуществами и недостатками, что и объектная (классовая) разработка программного обеспечения

Рисунок 4. Абстрактное модульное электронное устройство

1.2. Объектный подход при разработке программ

Цель, которую преследовали, разработчики объектно-ориентированного подхода в программировании ясна – упростить и укорить разработку программных продуктов, тем людям, которые будут использовать уже готовые, созданные кем-то ранее, классы [1].

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

1. Возможность создание массива (в том числе динамического) классов, каждый из которых будет иметь свои экземпляры переменных;

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

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

---