69081

КОМПОНЕНТНА ІДЕОЛОГІЯ

Лекция

Информатика, кибернетика и программирование

Крос-платформними можна назвати більшість сучасних мов програмування високого рівня. Наприклад, C, С++ і Object Pascal — крос-платформні мови на рівні компіляції, тобто для цих мов є компілятори під різні платформи. Java і C# — крос-платформні мови на рівні виконання, тобто їх виконувані файли...

Украинкский

2014-09-29

207.5 KB

20 чел.

PAGE  2

МІЖНАРОДНИЙ НАУКОВО-ТЕХНІЧНИЙ УНІВЕРСИТЕТ

ІМЕНІ АКАДЕМІКА ЮРІЯ БУГАЯ

Крос-платформне програмування

Освітньо-кваліфікаційний рівень – «Бакалавр»

Галузь знань “ Інформатика та обчислювальна техніка

Напрям підготовки – 6.050101  «Комп’ютерні науки»

Конспект лекцій

КИЇВ - 2011


Розроблено кафедрою Комп’ютерних наук та інформаційних систем МНТУ відповідно до освітньо-професійної програми, освітньо-кваліфікаційної характеристики та навчального плану підготовки бакалаврів з галузі знань “Інформатика та обчислювальна техніка”, напряму підготовки 6.050101 “Комп’ютерні науки”

Укладач: к. фіз.-мат.н., доц. Т.М. Коротун


ЛЕКЦІЯ 1. КОМПОНЕНТНА ІДЕОЛОГІЯ

План

1.1. Поняття крос-платформності, її типи

1.2. Визначення та властивості компонентів. Специфікація інтерфейсу як контракту

1.3. Модель посилань (узагальнена модель компонентної системи)

1.4. Компонента модель .Net Framework. Типи компонентів

1.5. Динамічна бібліотека DLL як приклад компонента

Висновки

1.1. Поняття крос-платформності, її типи

Означення 1

Крос-платформне програмне забезпечення — програмне забезпечення, що працює більш ніж на одній апаратній платформі і операційній системі (ОС).

Означення 2

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

Рівні кросплатформності

Поняття кросплатформності може використовуватися на різних рівнях абстракції інформаційних систем:

1. На рівні мови програмування

Крос-платформними можна назвати більшість сучасних мов програмування високого рівня. Наприклад, C, С++ і Object Pascal — крос-платформні мови на рівні компіляції, тобто для цих мов є компілятори під різні платформи. Java і C# — крос-платформні мови на рівні виконання, тобто їх виконувані файли можна запускати на різних платформах без попередньої перекомпіляції.

Це забезпечує двох-етапна компіляція через проміжний код. В Java для цього використовується байт-код і віртуальна машина (JRE), реалізація якої є для різних ОС, а в C# - через проміжний код на проміжній мові програмування (близькій до мови ассемблера) і загальномовного середовища програмування (CLRCommon Language Runtime). Нагадаємо, що CLR – це динамічна складова .Net Framework.

Реалізація .Net Framework є для всіх версій Windows. Реалізація для платформи Linux – проект MONO.

Мови скриптів - PHP, ActionScript, Perl, Python, Tcl і Ruby — кросплатформні мови, що інтерпретуються, їх інтерпретатори існують для багатьох платформ.

2. На рівні прикладних програм

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

Приклади:

  •  Apache
  •  BinkD
  •  CVS
  •  Emacs
  •  GIMP
  •  GoldEd
  •  Inkscape
  •  Lotus Notes
  •  Mozilla Firefox, Mozilla Thunderbird, SeaMonkey
  •  MySQL
  •  OpenOffice.org
  •  Opera
  •  VIM

3. На рівні операційної системи

Сучасні операційні системи також часто є крос-платформними. Наприклад, операційні системи з відкритим кодом, такі як NETBSD, Linux, FREEBSD, AROS можуть працювати на декількох різних платформах, найчастіше це x86, m68k, POWERPC, Alpha, AMD64, SPARC. Microsoft Windows може працювати як на платформі Intel x86, так і на Intel Itanium. Операційна система NETBSD є самою переносною, вона портована на більшість існуючих платформ.

Емуляція

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

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

1.2. Визначення та властивості компонентів. Специфікація інтерфейсу як контракту

Сучасні кросплатформні системи створюються з використанням  компонентно-орієнтованого підходу.

Компонентне програмування є подальшим розвитком об'єктно-орієнтованого програмування (ООП) і концепції «повторного використання» (reuse).

Компонентне програмування покликане забезпечити простішу і швидшу процедуру інсталяції прикладного програмного забезпечення, а також збільшити відсоток повторного використання коду, тобто підсилити основні переваги ООП.

Перш за все, сформулюємо головне для даного підходу визначення компонента.

Під компонентом далі матимемо на увазі незалежний модуль програмного коду, призначений для повторного використання і розгортання.

Такий компонент є структурною одиницею програмної системи, що має чітко визначений інтерфейс.

Компонент може бути незалежно поставлений або не поставлений, доданий до складу деякої системи або видалений з неї, у тому числі, може включатися до складу систем інших постачальників.

Таким чином, компонент — це виділена структурна одиниця розгортання з чітко визначеним інтерфейсом.

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

Властивості компонентів

1. Використання компонента (виклик його методів) можливе лише через його інтерфейси відповідно до контракту.

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

Для опису інтерфейсів призначені мови опису інтерфейсів IDL (Interface Definition Language).

Ці мови містять операції, які є викликами відкритих (public) методів класів, що входять до складу компонента, і операнди – відкриті (public) поля класів.

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

Це вимагає наявності певної інфраструктури, яка дозволяє компонентам знаходити один одного і взаємодіяти по певних правилах.

Набір правил визначення інтерфейсів компонентів і їх реалізацій, а також правил, за якими компоненти працюють в системі і взаємодіють один з одним, прийнято називати компонентною моделлю (component model).

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

Існують декілька компонентних моделей в різних ОС і від різних виробників. Правильно взаємодіяти один з одним можуть лише компоненти, побудовані в рамках однієї моделі, оскільки компонентна модель визначає «мову», на якій компоненти можуть спілкуватися один з одним.

Окрім компонентної моделі, для роботи компонентів необхідний деякий набір базових служб (basic services). Наприклад, компоненти повинні уміти знаходити один одного в середовищі, яке, можливо, розподілене на декілька машин. Компоненти повинні уміти передавати один одному дані, знову ж таки, можливо, за допомогою мережевих взаємодій, але реалізації окремих компонентів самі по собі не повинні залежати від вигляду використовуваного зв'язку і від розташування їх партнерів по взаємодії. Набір таких базових, необхідних для функціонування більшості компонентів служб, разом з підтримуваною з їх допомогою компонентною моделлю називається компонентним середовищем (або компонентним каркасом, component framework). Приклади відомих компонентних середовищ — різні реалізації J2EE, .NET Framework, CORBA, COM, COM+, DCOM.

3. Компоненти відрізняються від класів об'єктно-орієнтованих мов.

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

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

4. Компоненти не залежать від мов програмування.

Компоненти зберігаються і поширюються у бінарному вигляді і не залежать від мов програмування програмної системи.

Користувач і постачальник компонента можуть використовувати різні мови і бути територіально розподіленими.

1.3. Модель посилань (узагальнена модель компонентної системи)  

Компонентна програмна система складається з незалежних компонентів. Узагальнена модель такої системи зображена на рис.1.1.

Рис. 1.1. Узагальнена модель компонентної системи

Компонент (1) – це програмна реалізація (виконуваний код) функцій об'єкту, призначена для виконання. Разом з функціональністю компонент реалізує один або декілька інтерфейсів (2) відповідно до певних зобов'язань, описаних у контракті (3). Контрактні зобов'язання гарантують, що незалежно розроблені компоненти можуть взаємодіяти один з одним і розгортатися в стандартних середовищах (4) (на етапі побудови системи або на етапі її виконання).

Компонентна програмна система ґрунтується на невеликій кількості компонентів різних типів (5), кожний з яких має спеціалізовану роль в системі і описується інтерфейсом (2). Компонентна модель (6) утворена множиною типів компонентів, їх інтерфейсів, а також специфікацією допустимих шаблонів (паттернів) взаємодії типів компонентів. Компонентний каркас (7) забезпечує множину сервісів (8) для підтримки функціонування компонентної моделі. У багатьох відношеннях компонентні каркаси подібні спеціалізованим операційним системам, хоча вони оперують на більш високих рівнях абстракції і мають більш обмежений діапазон механізмів координації взаємодії компонентів.

Найбільш важливий аспект компонентної ідеології побудови – передбачуваність композиції взаємодіючих компонентів і каркасів. Можливі три основні види композицій в програмній системі:

– «компонент-компонент» (взаємодія по контрактах прикладного рівня, яка визначається під час розробки (раннє зв’язування) або під час виконання (пізнє зв’язування);

– «каркас-компонент» (взаємодія між компонентом і іншими компонентами каркаса по контрактах системного рівня із забезпеченням управління ресурсами);

  •  «каркас-каркас» (взаємодія між компонентами, які розгортаються в гетерогенних середовищах (каркасах) по контрактах інтероперабельного (interoperation) рівня).

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

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

інформаційну частину - опис призначення, дати виготовлення, умов застосування (ОС, платформа тощо) та можливостей повторного використання;

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

– інтероперабільність – здатність взаємодіяти з компонентами інших середовищ;

– переносність (мобільність) – здатність працювати на різних платформах;

– інтегрованість – здатність до об'єднання з іншими компонентами в складі програмної системи;

– не функціональні характеристики - безпека, надійність і захист компоненту і даних;

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

Специфікація інтерфейсу може виконуватися засобами API (Application Programming Interface) мови програмування або на мові специфікації інтерфейсу (не залежному від мови програмування) - Interface Definition Language (IDL).

Сучасні мови програмування, наприклад, Java, мають розширення, спеціально призначені для специфікації поведінки: iContract, JML (Java Modeling Language), Jass (Java with assertions), Biscotti, and JINSLA (Java INterface Specification LAnguage).

Таким чином, компонентні системи ґрунтуються на чітко визначених стандартах і угодах для розробників компонентів (встановлених у компонентній моделі) та інфраструктурі компонентів (компонентному каркасі), яка реалізує сервіси для моделі, спрощуючи розгортання окремих компонентів і застосунків.

Компонентна модель пропонує:

- стандарти по типах компонентів (наприклад, проекти, форми, COBRA-компоненти, RMI-компоненти, стандартні класи-оболонки, бази даних, JSP-компоненти, сервлети, XML-документи, DTD-документи і т.п., які визначені у відповідних мовах програмування);

- стандарти схем взаємодії (методи локалізації, протоколи комунікації, необхідні атрибути якості взаємодії – безпека, управління транзакціями тощо);

- угоди про зв’язування компонентів з ресурсами (сервісами, що надаються каркасом або іншим компонентом, розгорненим у цьому каркасі). Модель описує, які ресурси доступні компонентам, як і коли компоненти зв'язуються з цими ресурсами. Каркас, у свою чергу, розглядає компоненти як ресурси, що підлягають управлінню.

Найбільш відомі компонентні моделі - COM (Component Object Model) (DCOM – розподілена компонентна модель, COM+), CORBA, .Net Framework.

1. Component Object Model (COM) – початковий стандарт Microsoft для компонентів. Визначає протокол для конкретизації і використання компонент усередині процесу, між процесами або між комп'ютерами. Основа для ActiveX, OLE і багатьох інших технологій. Може використосуватися в Visual Basic, C++ і ін.

2. Java Beans – стандарт Sun Microsystems для компонентів (тільки для Java).

3. CORBA (стандарт OMG, має громіздкий IDL-інтерфейс, складність відображення однієї мови реалізації в іншу).

4. Dot Net Framework сучасна компонента модель Microsoft для розробки складних розподілених програмних систем.

Компонентний каркас (подібно операційній системі, об'єкти дії якої - компоненти) керує ресурсами, розподіленими компонентами, і надає механізми для організації взаємодії компонентів. Каркас необов'язково існує окремо від компонентів під час роботи системи, його реалізація може бути об'єднана з реалізацією компоненту, хоча переважно перше, як, наприклад, каркас для підтримки компонентної моделі EJB (Enterprise JavaBeans).

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

1.4. Компонента модель .Net Framework. Типи компонентів

Поняття платформи MS.NET.  

Під платформою Microsoft.NET слід розуміти інтегровану систему (інфраструктуру) засобів розробки, розгортання і виконання складних (як правило, розподілених) програмних систем.

Основа .Net – це Microsoft .Net Framework – компонентний каркас, набір засобів і технологій для розробки і виконання програмних систем.

Ключові характеристики MS.NET

1. Сучасні засоби розробки - платформа MS.Net включає як готові компоненти для побудови ПЗ, так і інтегроване середовище розробки, яке забезпечує можливість багатомовної розробки ПЗ з використанням різних мов програмування (C#, C++, VBasic.Net). Як результат, розробник програм вже не обмежується вибором однієї якої-небудь мови програмування, а може варіювати засоби розробки з урахуванням власного досвіду і властивостей програм, що розробляються, навіть в межах однієї програмної системи. 

2. Компонентне представлення ПЗ – MS.Net розвиває існуючі підходи до основного способу зниження складності ПЗ - компонентному представленню програмних систем - пропонуючи більш простий, зручний і надійний метод формування програмних компонентів.

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

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

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

Між збірками і просторами імен існує наступне співвідношення. Збірка може містити декілька просторів імен. В той же час, простір імен може займати декілька збірок.

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

В результаті компіляції програмного коду в середовищі обчислень .NET  створюється або збірка, або так званий модуль. При цьому збірка існує у формі виконуваного файлу (з розширенням EXE), або файлу динамічної бібліотеки (з розширенням DLL). Природно, до складу збірки входить маніфест. Модуль є файлом з розширенням NETMODULE. Він не містить маніфесту.

Приклад 1. Маніфест збірки

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">

 <assemblyIdentity version="1.0.0.0" name="MyApplication.app"/>

 <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">

   <security>

     <requestedPrivileges xmlns="urn:schemas-microsoft-com:asm.v3">

       <requestedExecutionLevel level="asInvoker" uiAccess="false"/>

     </requestedPrivileges>

   </security>

 </trustInfo>

</assembly>

1.5. Динамічна бібліотека DLL як приклад компонента

Динамічна бібліотека — набір функцій, скомпонованих разом у вигляді бінарного файлу, який може бути динамічно завантажений в адресний простір процесу, що використовує ці функції. Динамічне завантаження (dynamic loading) — завантаження під час виконання процесу.

Оскільки динамічні бібліотеки є двійковими файлами, можна організувати спільну роботу бібліотек, розроблених із використанням різних мов програмування і програмних засобів, що спрощує створення застосунків на основі програмних компонентів (отже, динамічне компонування лежить в основі компонентного підходу до розробки програмного забезпечення).

1.5.1. Створення DLL-бібліотеки

Створення DLL-бібліотеки розглянемо на конкретному прикладі.

Запустіть Visual Studio 2008, із стартової сторінки перейдіть до створення проекту, виберіть тип проекту «Class Library».  У вікні створення DLL всі поля заповнені значеннями за замовчанням. Як правило, їх слід перевизначити, задаючи власну інформацію.

У полі Name задайте ім'я DLL –бібліотеки, наприклад,  MyLib.

У полі Location вкажіть шлях до каталогу, де зберігатиметься Рішення, що містить проект.

Розмістіть рішення в папці Lab1.

У полі Solution вибраний елемент «Create New Solution», що створює нове Рішення. Альтернативою є елемент списку, який вказує, що проект може бути доданий до існуючого Рішення.

У вікні Solution Name задано ім'я Рішення. Виберіть Lab1.

Зверніть увагу на інші налаштування, зроблені в цьому вікні, - включений прапорець (за замовчанням) «Create directory for solution», у верхньому віконці із списку можливих каркасів вибраний каркас Framework .Net 3.5. Задавши необхідні установки і клацнувши по кнопці «OK», отримаємо автоматично побудований проект DLL, відкритий в середовищі Visual Studio 2008 .

Імена класів повинні бути змістовними. Змініть ім'я «Class1» на ім'я «MySin».  Для цього у вікні коду проекту виділіть ім'я змінної об'єкту, потім в головному меню виберіть пункт Refactor і підпункт Rename. У вікні, що відкрилося, вкажіть нове ім'я. Тоді будуть показані всі місця, що вимагають перейменування об'єкту. В нашому прикладі буде лише одна очевидна заміна, але в загальному випадку замін багато, так що автоматична заміна всіх входжень корисна.

Наступний крок також продиктований правилом стилю – ім'я класу і ім'я файлу, що зберігає клас, повинні бути однаковими. Перейменування імені файлу робиться безпосередньо у вікні проектів Solution Explorer.

І наступний крок, продиктований також важливим правилом стилю, - додавання коментаря. Для цього в рядку перед заголовком класу слід набрати три слеша (три косі риски). В результаті перед заголовком класу з'явиться заголовний коментар – тег «summary», в який і слід додати короткий, але змістовний опис призначення класу. Теги «summary», якими слід супроводжувати класи, відкриті (public) методи і поля класу відіграють три важливі ролі. Вони полегшують розробку і супровід проекту, роблячи його самодокументованим. Клієнти класу при створенні об'єктів класу отримують інтелектуальну підказку, що пояснює суть того, що можна робити з об'єктами. Спеціальний інструментарій дозволяє побудувати документацію за проектом, що включає інформацію з тегів «summary».

У нашому випадку коментар до класу MySin може бути достатньо простим – «Обчислення математичних функцій ».

Напишемо реалізацію одного методу класу – обчислення функції Sin(x) через ряд Тейлора.

Спочатку напишемо коментарі до методу (у форматі XML). Далі напишемо реалізацію методу. Отримаємо код.

Лістинг 1.1. Код бібліотечного методу

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

namespace MyLib

{

///Обчислення математичних фунцій

   public class MySin

   {

    /// <summary>

    /// Sin(x)

    /// </summary>

    /// <param name="x">кут в радіанах – перший аргумент функції  Sin</param>

    ///<param name="n">показник ступеня – другий аргумент функції  Sin</param>

    /// <returns>Повертає значення функції Sin для заданого кута</returns>

       public static double Sin(double x, int n)

       {

           double result = 0;

           for (int i = 0; i < n; i++)

           {

               result = result + (Math.Pow((-1), i) * Math.Pow(x, (2 * i + 1))) / F(2 * i + 1);

           }

           return result;

       }

       static double F(int n)

       {

           double tmp = 1;

           for (int i = 1; i <= n; i++)

           {

               tmp = tmp * i;

           }

           return tmp;

       

       }

   }

}

Побудуйте Рішення, що містить проект, для чого в Головному меню виберіть пункт Build|Build Solution. В результаті успішної компіляції буде побудований файл з розширенням dll. Оскільки побудована збірка не містить виконуваного файлу, то безпосередньо запустити наш проект на виконання не удасться. Побудуємо консольний  проект, до якого приєднаємо нашу DLL, і протестуємо, наскільки коректно працюють створені нами методи.

1.5.2. Створення консольного проекту для тестування функції з бібліотеки

Виберіть пункт меню File|New|Project, задайте тип проекту ConsoleApplication, назвіть йому – ConsoleMySin, вкажіть, що проект додається до існуючого Рішення Lab1. В результаті у вже існуюче Рішення додасться ще один проект.

Напишіть код, який викликає реалізовану функцію Sin(x,n), стандартну функцію Sin(x), обчислює похибку і виводить результат на консоль.

Лістинг 1.2. Консольний застосунок, який викликає бібліотечний метод

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

namespace ConsoleMySin

{

   class Program

   {

       /// <summary>

       /// Виклик бібліотечного методу Sin(x,n) з MySin.dll

       /// </summary>

       /// <param name="args"></param>

       static void Main(string[] args)

       {

           Console.WriteLine("Введите x- угол в радианах");

           double x = double.Parse(Console.ReadLine());

           Console.WriteLine("Введите показатель степени n");

           int n = int.Parse(Console.ReadLine());

           //вызов метода вычисления sin(x) из библиотеки

           double my_sinus = MyLib.MySin.Sin(x, n);

           //вызов метода из класса Math

           double sinus = Math.Sin(x);

           double delta = sinus - my_sinus;

           Console.WriteLine("my_sinus= {0},sin={1},delta={2}", my_sinus, sinus, delta);

           Console.ReadKey();

       }

   }

}

Побудуємо рішення і отримаємо повідомлення про помилку. Наша бібліотека не підключена  до проекту.

Підключення проекту бібліотеки до консольного проекту.

Для цього додайте посилання на проект з DLL MySin. У вікні Solution Explorer наведіть покажчик миші до імені консольного проекту і з контекстного меню виберіть пункт меню «Add Reference». Виберіть вкладку «Projects». Оскільки проект MySin включений в Рішення, то він автоматично з'явиться у вікні, Якщо посилання потрібно встановити на проект, не включений в Рішення, то у вікні додавання посилань потрібно вказати шлях до проекту.

Посилання  на DLL з'явиться в папці «References» консольного проекту. Тепер проекти зв'язані і з консольного проекту доступний реалізований бібліотечний метод.

Перебудуйте рішення, щоб не було помилок.

Встановлення стартового проекту.

У вікні Solution Explorer наведіть курсор миші на заголовок консольного проекту і виберіть:

Set as StartUp Project

Після цього його можна запустити на виконання.

1.5.3 Створення Windows-проекту в тому самому рішенні

Виберіть пункт меню File|New|Project, задайте тип проекту Windows Forms Application, назвіть його – WindowsMySin, вкажіть, що проект додається до існуючого Рішення Lab1.

На формі створіть 2 текстові поля для введення вхідних параметрів, третє і четверте – для результатів (рис. 2.1).

Рис. 1.1. Форма для обчислення sin(x)

Додамо 2 кнопки. При натисканні кнопки "Обчислення Sin" виконується виклик функцій, "Вихід" – завершення роботи.

Лістинг 1.3. Код форми

using System;

using System.Collections.Generic;

using System.ComponentModel;

using System.Data;

using System.Drawing;

using System.Linq;

using System.Text;

using System.Windows.Forms;

namespace WindowsMySin

{

   public partial class Form1 : Form

   {

       public Form1()

       {

           InitializeComponent();

       }

       private void button1_Click(object sender, EventArgs e)

       {

          double x = double.Parse(txt_x.Text);

          int n = int.Parse(txt_n.Text);

          //вызов метода вычисления sin(x) из библиотеки

          double my_sinus = MyLib.MySin.Sin(x, n);

          //вызов метода из класса Math

          double sinus = Math.Sin(x);

          txt_y1.Text = my_sinus.ToString();

          txt_y2.Text = sinus.ToString();

       }

       private void button2_Click(object sender, EventArgs e)

       {

           this.Close();

       }

   }

}

Робимо проект стартовим і запускаємо на виконання. Результат:

Рис. 1.2. Результат роботи форми

1.5.4. Створення DLL-бібліотеки як окремого рішення (в іншому процесі)

Основна мета створення і використання DLL-бібліотек – забезпечення повторного використання коду. Тому в реальних системах різні компоненти можуть викликати однакові бібліотечні методи. Для цього DLL-бібліотека повинна знаходитися в окремому рішенні.

Для підключення бібліотеки до проекту файл зі збіркою, що містить бібліотеку потрібно підключити з меню «Add Reference».  Оскільки проект не включений в Рішення, то у вікні додавання посилань потрібно вказати шлях до проекту у файловій системі.

Висновки

Важливим наслідком реалізації компонентного підходу є зниження вартості проектування ПЗ.

До переваг компонентного програмування слід віднести і можливість удосконалення стратегії повторного використання коду.

В платформі Microsoft .NET реалізовано компонентно-орієнтований підхід до програмування. Цей підхід до проектування і реалізації програмних систем і комплексів є розвитком об'єктно-орієнтованого і практично придатніший для розробки великих і розподілених систем.

В компонентній моделі .Net компонентом є збірка, яка може бути у вигляді виконуваного файлу (з розширенням EXE), або файлу динамічної бібліотеки (з розширенням DLL). До складу збірки входить маніфест.

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

Збірка має маніфест, який містить інформацію про збірку (метадані, які описують збірку).

Велику роль в сучасних системах відіграють бібліотеки повторного використання, зокрема DLL-бібліотеки.

DLL-бібліотеки містять методи, які викликаються динамічно при роботі програмної системи. Вони є окремими компонентами з розширенням .dll. Інтерфейсом бібліотеки є відкриті (public) методи і поля бібліотечних класів. DLL-бібліотека не містить точки входу (main), тому її методи можуть викликатися лише іншими компонентами. Разом з цим, в бібліотеці можуть бути і закриті методи класу, які викликаються методами в середині бібліотеки. DLL-бібліотеки – основа компонентної ідеології і повторного використання коду.

Контрольні запитання та завдання

1. Що таке інтерфейс компонента і яке його призначення?

2. Що таке компонент, чим він відрізняється від класу?

3. Що визначає інтерфейсний контракт? Що являє собою інтерфейс компонента?

4. Основні властивості компонентів?

5. Рівні кросплатформності і різниця між ними?

6. Для чого в Dot.Net використовується компіляція через проміжний код?

7. Для чого використовується компонентний каркас?

8. Що таке компонентна модель і яке її призначення?

9. Що таке DLL-бібліотека? Чим вона відрізняється від консольного проекту?

10. Для чого потрібно XML-документування коду? Як воно допомагає при написанні виклику бібліотечних методів?

11. Чому бібліотечні методи повинні визначатися з модифікатором доступу public?

12. Що є інтерфейсним контрактом бібліотеки?


 

А также другие работы, которые могут Вас заинтересовать

52869. Розвиток комунікативних здібностей школярів на уроках англійської мови 188.5 KB
  Наприклад якщо учні познайомилися один з одним на початку нового шкільного року в них ніколи потім не виникає потреби знову це робити. Учні в класі як правило не мають потреби ставити запитання про те як пройти чи проїхати кудись у певному напрямку але вони мусять знати як це робити в реальних життєвих ситуаціях. Наприклад спочатку учні відпрацьовують команди напрямку.
52870. План-конспект уроку для 4 класу за темою „Christmas” 161 KB
  Тhis day people usually visit their friends. There is a lot of dancing and eating. People bring a piece of coal for good luck. People decorate trees with toys, send greeting cards and find presents in their stockings. People send cards to people they love. They don`t write their names.
52871. СТВОРЕННЯ ТА ВИКОРИСТАННЯ ЕЛЕКТРОННОГО СУПРОВОДУ УРОКІВ АНГЛІЙСЬКОЇ МОВИ 319.5 KB
  Важливого значення з огляду на це набуває питання використання у педагогічному процесі мультимедійних засобів навчання МЗН. Іноземна мова – це навчальний предмет який в силу своєї специфічності створення для учнів штучного мовного середовища передбачає найбільш гнучке і широке використання різних технічних засобів навчання. Головною метою навчання іноземних мов у загальноосвітніх навчальних закладах є надбання учнями вмінь та навичок грамотного використання іноземної мови у реальних життєвих ситуаціях не тільки повсякденного але й...
52872. ШЛЯХИ ЕФЕКТИВНОГО ВИКОРИСТАННЯ ПІСЕННОГО МАТЕРІАЛУ НА УРОКАХ АНГЛІЙСЬКОЇ МОВИ 123 KB
  Музика, а саме пісня іноземною мовою, має великі можливості для реалізації навчально-виховних завдань на уроках англійської мови. Важлива роль полягає саме в методично правильному доборі пісенного матеріалу та методики його використання.
52874. ШЛЯХИ ЕФЕКТИВНОГО ВИКОРИСТАННЯ ПІСЕННОГО МАТЕРІАЛУ НА УРОКАХ АНГЛІЙСЬКОЇ МОВИ 164.5 KB
  У структуру гри як процесу входять: а ролі узяті на собі граючи; б ігрові дії як засіб реалізації цих ролей; в ігрове вживання предметів тобто заміщення реальних речей ігровими умовними; г реальні відносини між граючи; д сюжет зміст область дійсності умовно відтворена в грі. Рольові ігри Ідея використання рольової поведінки на уроці одержала підкріплення з боку теорії ролей розробленої соціологами і соціопсіхологамі. Ігри позитивно впливають на формування пізнавальних інтересів школярів сприяють усвідомленому освоєнню іноземної...
52875. Особливості навчання англійської мови молодших школярів 216 KB
  У сучасних умовах іноземна мова розглядається як засіб спілкування і залучення до культури іншого народу. Це поступово стає домінуючою стратегією викладання іноземної мови в початковій школі. Особлива увага приділяється навчанню іноземної мови школярів в початкових класах, бо в дитинстві схильність до вивчення мов набагато більша.
52876. «В чарівній країні англійської мови» «In the Magic Land of English» Сценарій позакласного заходу з англійської мови (7 клас) 138 KB
  Every season is beautiful in its own way but Autumn is a wonderful season. It's like an old woman who is still beautiful and comes to breakfast in her diamonds. Who lights a million candles over the gabled roof and never looks back to see them black, The trees are beautiful in their fantastic yellow, red, golden and brown dresses. The ground is like a carpet of many colours.And everybody feels happy.
52877. The Week of English 1.46 MB
  Аfter World War II Pablo Picasso, was responsible for the decisive use of the dove of peace: his lithograph designed for the international peace congress in Paris, 1949, features the white ancestor of a new family of doves. Since then, graphic artists have produced an endless series of doves of peace in different shapes.