Автореферат

          Введение

     Рассматривая современную тенденцию к развитию науки и техники, процесс автоматизации становится все более и более обширным. Для того, чтобы автоматизировать какой либо процесс, необходимо иметь в наличии вычислительное устройство, а также программное обеспечение, которое будет управлять процессом. В качестве вычислительного устройства можно использовать персональный компьютер (ПК). Так как ПК обладает возможностями, которые порой являются избыточными, вследствие чего расходуется больше средств на его покупку и техническую поддержку. Целесообразней использовать так называемые встраиваемые устройства, которые призваны решать узкоспециализированный круг задач. Такие устройства стоят дешевле, компактнее и в целом могут справляться с решением поставленной задачи.

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

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

          Объектно-ориентированная парадигма

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

     В области разработки программных систем наиболее развитой и широко используемой, на данный момент, является объектно-ориентированная парадигма [2]. Эта парадигма включает следующие элементы (рис. 1):

• анализ – это метод, исследующий требования клиента к системе в виде множества взаимодействующих абстракций;
• проектирование – это методология, объединяющая объектно-ориентированную декомпозицию и определенную систему обозначений;
• программирование (конструирование) – это процесс непосредственного кодирования (реализации) проекта системы, с использованием объектно-ориентированного языка программирования [3].

Рисунок 1 – Основные элементы объектно-ориентированной парадигмы

     Как было отмечено, объектно-ориентированное проектирование основывается на объектно-ориентированной декомпозиции, которая, в свою очередь, может представляться посредством UML-диаграмм (рис. 2) [4][5].

Рисунок 2 – Инструменты объектно-ориентированного проектирования

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

     Гибкость объектно-ориентированных систем достигается за счет получения устойчивых промежуточных форм, используемых при дальнейшей эволюции системы (рис. 3) [2]. Получение промежуточной устойчивой формы заключается в создании множества абстракций и их реализации (программировании), обеспечивающих ожидаемое поведение системы.

Рисунок 3 – Эволюция системы, основанная на устойчивых промежуточных формах

     Концептуальной основой объектно-ориентированной парадигмы является ряд принципов (рис. 4) [2]:

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

Рисунок 4 – Элементы объектно-ориентированной модели. Рисунок является анимацией и содержит 5 кадров, повторяется 5 раз, имеет размер 1,87 КБ

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

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

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

     Существует два способа организации абстракций в иерархии. В первом случае абстракции связываются отношением «является» («is-a») (рис. 5а) – наследование, во втором – отношением "включает" («has-a») (рис. 5б) – агрегация.

Рисунок 5 – Отношение наследования (а), отношение агрегации (б)

     Согласно Буч, наследование подразумевает создание иерархии классов, в которых подклассы заимствуют свойства одного или нескольких суперклассов[2]. Наследование применяется для изменения или расширения существующей структуры и поведения суперкласса. В иерархии наследования ссылки на объекты суперкласса, также могут ссылаться и на объекты подклассов, такая возможность называется полиморфизмом (рис. 6). При переопределении подклассами части поведения суперкласса, можно считать, что объекты производных классов обеспечивают полиморфное поведение, тем самым позволяют динамически (во время выполнения программы) изменять поведение суперкласса.

Рисунок 6 – Полиморфное поведение объектов

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

Рисунок 7 – Делегирование обязанностей агрегатам

          Многоуровневая архитектура

     Согласно Бушман, многоуровневая архитектура – это способ структурировать системы на группы однотипных подзадач[8]. Рассматриваемая архитектура применятся в том случае, если, например, в приложении присутствуют элементы высокоуровневой логики приложения, а также и низкоуровневой. Например, низкоуровневый код считывания информации с аналоговых датчиков, и высокоуровневый код его обработки. Если система будет спроектирована в виде монолитного блока, то по коду будет расползаться низкоуровневые обращения к датчикам:

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

     В общем случае многоуровневая архитектура представляет собой набор слабосвязанных уровней с однотипными подзадачами (рис. 8).

Рисунок 8 – Обобщенная архитектура многоуровневой системы

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

• абстрагирование;
• удаленность от аппаратуры;
• скорость изменения.

     Общая архитектура корпоративных приложений представляет собой многоуровневую архитектуру, состоящую из трех уровней:

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

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

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

     При проектировании многоуровневых систем важно придерживаться определенных концепций [8]:

• Поздние изменения кода не должны расползаться по всей системе, то есть они должны быть ограничены одним компонентом и не затрагивать остальные (рис. 9).



Рисунок 9 – Сокращение влияний изменений на остальные компоненты системы

• Части системы должны быть заменяемыми. Компоненты должны иметь возможность заменяться различными альтернативными реализациями без затрагивания остальной части системы (рис. 10).



Рисунок 10 – Взаимозаменяемость частей системы

• Каждый компонент должен выполнять только свои обязанности, то есть быть связным.

     Наиболее известным примером многоуровневой архитектуры является эталонная семиуровневая сетевая модель OSI [9] (рис. 11).

Рисунок 11 – Семиуровневая модель OSI

     Модель OSI представляет собой набор уровней, которые взаимодействуют между собой по определенным протоколам [8]. Понятие протокола, означает наличие совокупности правил и форматов (синтаксических и семантических), которые определяют взаимодействие между объектами [9]. Слой более высокого уровня использует службы, поставляемые нижележащим уровням, но тот не "осведомлен" о наличии вышележащего уровня. Причем, каждый уровень «знает» о существовании только последующего нижележащего уровня [10].

          Вывод

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

          Список литературы:

1. Кун Т.С., Структура научных революций. - М.: Прогресс, 1977. - 300 с.
2. Буч Г., Максимчук. Объектно-ориентированный анализ и проектирование с примерами приложений, 3-е изд. Пер.с англ. – М.:ООО И.Д. Вильямс, 2008 . – 720 с.: ил. – Парал. тит.англ.
3. Мейер Б. Объектно-ориентированное конструирование программных систем. - М.: Русская Редакция, 2005. - 1204 с.: ил.
4. Буч Г., Рамбо Д., Якобсон И., Язык UML. Руководство пользователя. - М.: ДМК пресс, 2007. - 496 с.: ил.
5. Фаулер М., UML. Основы. - СПб.: Символ-Плюс, 2006. - 192 с.: ил.
6. Брукс Ф., Мифический человеко - месяц или Как создаются программные системы. - СПб.: Символ-Плюс, 2006. - 304 с.: ил.
7. Макконнелл С., Совершенный код. - СПб.: Питер, 2007. - 896 с.: ил.
8. Buschmann F., Meunier R., Rohnert H., Sommerlad P., Stal M., Sommerlad P. Pattern-Oriented Software Architecture, Volume 1: A System of Patterns. - US: John Wiley, 1996.
9. ISO/IEC 7498-1:1994(E), Information technology - Open Systems Interconnection - Basic Reference Model: The Basic Model.
10. Фаулер М., Архитектура корпоративных программных приложений. Шаблоны корпоративных приложений. - М.:ООО И.Д. Вильямс, 2007. - 544 с.: ил.

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