Автореферат

          Вступ

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

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

     Тому ця робота являє собою розробку методики проектування систем для вбудованих пристроїв з використанням об'єктно-орієнтованої парадигми і багаторівневої архітектури.

          Об'єктно-орієнтована парадигма

     Згідно [1] парадигма – це безліч теоретичних принципів, практичних прийомів і інструментів, які є основою для наукових досліджень в певній області, та застосовуються протягом тривалого періоду часу.

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

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

Рисунок 1 – Основні елементи об'єктно-орієнтованої парадигми

     Як було відмічено, об'єктно-орієнтоване проектування ґрунтується на об'єктно-орієнтованій декомпозиції, яка, у свою чергу, може представлятися за допомогою UML-діаграм (рис. 2) [4][5].

Рисунок 2 – Інструменти об'єктно-орієнтованого проектування

     В процесі об'єктно-орієнтованої декомпозиції, логічна структура системи виражається набором об'єктів, що взаємодіють між собою за допомогою передачі повідомлень один одному. У такому разі можна сказати, що об'єкт, який посилає повідомлення, є клієнтом. А об'єкт, що оброблює повідомлення, є постачальником.

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

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

     Концептуальною основою об'єктно-орієнтованої парадигми є ряд принципів (рис. 4) [2]:

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

Рисунок 4 – Елементи об'єктно-орієнтованої моделі. Рисунок є анімацією і містить 5 кадрів, повторюється 5 разів, має розмір 1,83 КБ

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

     Основним призначенням інкапсуляції є приховання деталей реалізації абстракції. Це означає, що клієнта турбує тільки коректне виконання контракту класу, що використовується, а то, як він це робить, вважається неістотним [2].

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

     Існує два способи організації абстракцій в ієрархії. У першому випадку абстракції зв'язуються відношенням "є" ("is-a") (рис. 5а) – спадкоємство, в другому – відношенням "включає" ("has-a") (рис. 5б) – агрегація.

Рисунок 5 – Відношення спадкоємства (а), відношення агрегації (б)

     Згідно [2] спадкоємство має на увазі створення ієрархії класів, у яких підкласи запозичують властивості одного або декількох суперкласів. Спадкоємство застосовується для зміни або розширення існуючої структури і поведінки суперкласу. У ієрархії спадкоємства посилання на об'єкти суперкласу, також можуть посилатися і на об'єкти підкласів, така можливість називається поліморфізмом (рис. 6). При перевизначенні підкласами частини поведінки суперкласу, можна вважати, що об'єкти похідних класів забезпечують поліморфну поведінку, тим самим дозволяють динамічно (під час виконання програми) змінювати поведінку суперкласу.

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

     У свою чергу агрегація створює ієрархію об'єктів, в яких один об'єкт можна розглядати як частина іншого. У цьому випадку об'єкт, що включається, є таким, що агрегується, а об'єкт, що включається – є агрегатом. В цьому випадку, динамічна поведінка агрегату реалізується шляхом делегування (передачі) обов'язків об'єктам, що агрегуються (рис. 7).

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

          Багаторівнева архітектура

     Згідно [7] багаторівнева архітектура – це спосіб структурувати системи на групи однотипних підзадач. Дана архітектура застосуються в тому випадку, якщо, наприклад, у програмі присутні елементи високорівневої логіки, а також і низькорівневою. Наприклад, низькорівневий код зчитування інформації з аналогових датчиків, і високорівневий код її обробки. Якщо система буде спроектована у вигляді монолітного блоку, то за кодом розповзатиметься низькорівневі звернення до датчиків:

     При використанні багаторівневої архітектури показаною на рис. 1.13 код міг би виглядати таким чином:

     У загальному випадку багаторівнева архітектура є набором слабко пов'язаних рівнів з однотипними підзадачами (рис. 8).

Рисунок 8 – Узагальнена архітектура багаторівневої системи

     Для розділення системи на рівні, необхідно для кожної групи підзадач визначити критерій, що зв'язує дану групу, об'єднати їх, а також визначити інтерфейс взаємодії з іншими рівнями. Такими критеріями розділення на рівні можуть служити:

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

     Загальна архітектура корпоративних програм є багаторівневою архітектурою, що складається з трьох рівнів:

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

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

     Припустимо, що основним завданням програми, що розробляється, необхідно надати користувачеві максимально швидкий графічний інтерфейс, що дозволяє швидко відображати динамічні тривимірні об'єкти. Розробники ухвалили рішення про використання бібліотеки відображення тривимірних об'єктів, що динамічно розвивається, кожна нова версія якої покращує стару, а також додає нову функціональність. Щоб розв'язати графічний інтерфейс користувача і графічну бібліотеку, яка використовується, можна використовувати багаторівневу архітектуру основним критерієм розділення якої є швидкість зміни графічної бібліотеки.

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

• Пізні зміни коду не повинні розповзатися по всій системі, тобто вони повинні бути обмежені одним компонентом і не зачіпати інші (рис. 9).



Рисунок 9 – Скорочення впливів змін на решту компонентів системи

• Частини системи повинні бути такими, що взаємно заміняються. Компоненти повинні мати можливість замінюватися різними альтернативними реалізаціями без зачіпання решти частини системи (рис. 10).



Рисунок 10 – Взаємозамінність частин системи

• Кожен компонент повинен виконувати тільки свої обов'язки, тобто бути зв'язним.

     Найбільш відомим прикладом багаторівневої архітектури є еталонна семирівнева мережева модель OSI [8] (рис. 11).

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

     Модель OSI уявляє собою набір рівнів, які взаємодіють між собою згідно до певних протоколів [7]. Поняття протоколу, означає наявність сукупності правил і форматів (синтаксичних і семантичних), які визначають взаємодію між об'єктами [8]. Шар вищого рівня використовує служби, що поставляються рівнем, що пролягає нижче, але той не "обізнаний" про наявність рівня, що пролягає вище. Причому, кожен рівень "знає" про існування тільки подальшого рівня, який пролягає нижче [9].

          Висновок

     У даній роботі розробляється методика проектування пов'язана з програмно-апаратними системами, аналіз і розробка яких вимагає особливого підходу. Тому метою даного дипломного проекту і буде розробка узагальненої методики проектування об'єктно-орієнтованих багаторівневих програмно-апаратних систем.

          Перелік літератури:

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 р. Повний текст роботи і матеріали по темі можуть бути отримані у автора, або його керівника після вказаної дати.