Автореферат

          Вступ

     На даний момент майже в кожній сім'ї, в кожному будинку є декілька приладів, які використовують вбудовувані системи. Гарним прикладом цього може бути СВЧ-піч. Більшість людей навіть не усвідомлюють, що програмне забезпечення бере участь у приготуванні їх сніданку або обіду. Вбудовувані системи застосовуються в світі все більше і більше в домашній техніці, в сучасних автомобілях, практично на будь-якому виробництві [1]. Таким чином, методика написання вбудовуваної системи у наш час є вельми актуальною.

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

          Об'єктна модель

     Об'єктно-орієнтована технологія заснована на об'єктно-орієнтованій моделі. Її основними принципами є: абстрагування, інкапсуляція, модульність і ієрархічність. Ці принципи самі по собі не нові, але в сукупності вони були вперше застосовані лише в об'єктно-орієнтованій моделі.

     Об'єкт – деяка суть, що характеризується своєю поведінкою, станом і стосунками до інших об'єктів (рис. 1).

Рисунок 1 – представлення об'єкту

     Об'єкти володіють цілісністю, тобто властивостю залишати об'єкт та його поведінку незмінними.

     Основними складовими об'єктно-орієнтованої моделі є об'єктно-орієнтований аналіз, об'єктно-орієнтоване проектування і об'єктно-орієнтоване програмування (рис. 2).

Рисунок 2 – порядок дотримання процесів при розробці ПЗ. Рисунок є анімацією і містить 4 кадри, повторюється 7 разів, має розмір 17.4 КБ

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

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

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

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

     Об'єктну модель характеризують чотири головні елементи:

• Абстрактність.
• Інкапсуляція.
• Модульність.
• Ієрархічність.

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

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

     Модульність – це властивість системи, розкладеної на слабо зв'язані між собою модулі. Модулі це фізичні одиниці системи, в які вміщаються визначення класів і об'єктів при логічному проектуванні системи.

     Ієрархія – це явище впорядковування абстракцій і розташування їх по рівнях.

     Без якого-небудь з цих параметрів модель не буде об'єктно-орієнтованою.[2]

          Багаторівнева архітектура програмно-апаратних систем

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

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

     З високорівневої точки зору рішення досить просте. Розбити систему на деяку кількість шарів і розташувати їх один відносно одного. У першому шарі розташовуватимуться самі низькорівневі абстракції. Це основа системи. Наступні шари розташовуються один за іншим по рівню сходження абстракцій.

Рисунок 3 – розташування шарів

     Уявімо, що система розбита на n шарів. На рисунку 3 представлені три шари, розташовані один відносно одного. Шар i надає сервіси, які використовує шар i + 1, і у свою чергу делегує підзадачі шару i - 1. При цьому шар i взаємодіє лише з тими двома шарами, які розташовані поряд з ним за ієрархією. Така концепція дуже зручна, оскільки для того, щоб замінити i – ий шар, потрібно лише внести незначні зміни в 2 шари, які стоять вище і нижче за нього за ієрархією.

     Якщо розглядати всю концепцію детальніше, взаємодіють між собою не шари, а задачі, які на цих шарах розташовані.

Рисунок 4 - розташування задач по рівнях

     На рисунку 4 показано розташування задач по рівнях. По рисунку видно, що певна задача може взаємодіяти з однією або більш іншими задачами. При цьому задача може взаємодіяти не лише з іншими задачами рівнем вище, або рівнем нижче, але і на тому ж рівні. [3]

     Не дивлячись на те, що концепція розшарування є дуже вдалим рішенням для більшості складних систем, вона має свої недоліки:

• Концепція шарів може не все вдало інкапсулювати. Інколи модифікація одного шару змушує каскадно модифікувати інші шари.
• Можуть виникнути деякі надлишкові шари (дуже велика кількість шарів) за рахунок того, що при переході з одного шару в іншій модельована суть піддається перетворенню з одного шару в іншій.

     Найскладніше при реалізації концепції шарів для свого застосування є точне визначення вмісту і кордонів кожного шару [4].

          Висновки

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

          Література

1. Barr M., Massa A. Programming Embedded Systems. O'Reilly. 2006. - 304 p.
2. Буч Г., Максимчук, и др. Объектно-ориентированный анализ и проектирование с примерами приложений, 3-е изд. Пер.с англ. – М.:ООО “И.Д. Вильямс”, 2008 . – 720 с.: ил. – Парал. тит.англ.
3. 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. - 634 p.
4. Фаулер М., Архитектура корпоративных программных приложений.: Пер. с англ. — М.: Издательский дом "Вильямс", 2006. — 544 с.: ил. — Парал. тит. англ.

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

Copyright © 2009, ДонНТУ, Гордєєв Андрій Георгійович