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

Елементи презентаційної розмітки є забороненими в останніх чинних специфікаціях HTML і XHTML, а також і в проекті HTML 5.

Добрий семантичний HTML також покращує доступність веб-документів. Наприклад, коли браузер або аудіо-браузер може правильно встановити структуру документа, він не буде витрачати час користувачів з вадами зору, на прочитання повторюваної або неактуальної інформації, якщо вона була розмічена правильно.

Проект специфікації HTML 5

HTML 5 -- це наступна значна переробка стандарту HTML. Робота над створенням специфікації, відома під назвою «Web Applications 1.0», розпочата WHATWG в червні 2004 року.

HTML 5 спрямований на скорочення використання заснованих на плагінах, RIA-технологій, таких як Adobe Flash, Microsoft Silverlight і Sun JavaFX, хоча досягнення цієї мети займе багато років.

Специфікація HTML 5 зводиться до надання семантичного рівня мови розмітки і пов'язаних з ними семантичних рівнів API для сценаріїв задля авторизації доступних сторінок в Всесвітній павутині, починаючи від статичних документів і закінчуючи динамічними застосунками. HTML 5 вводить ряд нових елементів і атрибутів, які відображають типову архітектуру сучасних веб-сторінок. Деякі з них є семантичними замінами загально-використовуваних блочних (div) і вбудованих (span) елементів, наприклад елемент nav (навігаційного блок сторінки) і footer. Інші елементи, забезпечують нові функціональні можливості через стандартизований інтерфейс, наприклад елементи audio і video.

Наразі специфікація має статус: «у розробці», та, як очікується, матиме його ще протягом трьох років, хоча розробка частин HTML 5 буде завершена і реалізована в браузерах ще до того, як специфікація отримає остаточний статус Рекомендації W3C.

XHTML

HTML, ймовірно, найбільш успішна мова розмітки документів у всьому світі. Проте, коли світові представили XML, було вирішено створити нову версію HTML, похідну від XML. Адже з XML-заснованим HTML інші XML-мови могли би включати частини XHTML, а XHTML-документи могли б включати частини інших мов розмітки. Також автори веб-документів могли б скористатися перевагами редизайну задля очищення деяких з найбільш неохайних частини HTML, а також додати деякі з нових необхідних функцій, таких як покращені форми. Нижче зазначені деякі переваги використання XHTML замість HTML.

Якщо документ є лише чистим XHTML 1.0 (не включає інші мови розмітки), то різниця між XHTML та HTML майже не помітна. Проте, оскільки стають доступними все більше і більше XML-інструментів (наприклад, XSLT для перетворення документів), переваги використання XHTML стають все помітнішими. Наприклад, XForms дозволяє досить просто керувати редагуванням документів XHTML (або будь-яких інших видів документа XML). Семантичні веб-застосунки також зможуть скористатися документами XHTML за своїми потребами. Якщо документ більш ніж просто XHTML 1.0 (наприклад, у документі використовуються мови розмітки MathML, SMIL, або SVG), тоді переваги використання XHTML значно помітніші, адже HTML не підтримує такі комбінації мов розмітки в одному документі.

2.9 FreeBSD

FreeBSD -- UNIX-подібна операційна система, коріння якої тягнеться від AT&T UNIX, через Berkeley Software Distribution (BSD) гілку операційних систем 386BSD та 4.4BSD. Працює на Intel x86 (IA-32), сумісних з ПК системах (включно з Microsoft Xbox, а також DEC Alpha, Sun UltraSPARC, Itanium (IA-64), AMD64, PowerPC та NEC PC-98 архітектурах. FreeBSD добре зарекомендувала себе як система для побудови інтранет- і інтернет-серверів. Вона надає достатньо надійні мережеві служби і ефективне управління пам'яттю.

FreeBSD розробляється, як повноцінна операційна система. Ядро, драйвери пристроїв та базові користувацькі утиліти (так звані Userland), на кшталт командного процесору (shell) розробляються в єдиному дереві джерельних текстів. Це одна з головних відмінностей системи від Linux, у котрій робота над розробкою ядра ведеться однією групою програмістів, базових користувацьких утиліт іншою (на приклад, проектом GNU), а усі пакунки збираються третіми групами у так званий дистрибутив.

2.9.1 Історія та розробка

Розробка FreeBSD почалася в 1993 році із набору патчів користувачів системи 386BSD, що швидко зростав. Цей набір пізніше виріс і відокремився від 386bsd в окрему операційну систему, що увібрала код від Free Software Foundation. Перша офіційна версія FreeBSD 1.0 вийшла у грудні 1993 року. Walnut Creek CDROM погодилася поширювати FreeBSD на компакт-диску і також надала для роботи проекту окремий комп'ютер з інтернет-з'єднанням. Керівництво до FreeBSD містить докладнішу історичну інформацію про походження системи.

Проте, в січні 1995 року з міркувань законності використання запозиченого у 386BSD коду, а також через судовий процес між Novell та Берклі, проект випустив спеціальну версію системи FreeBSD 2.0, де було переписано більшу частину її коду, чимало якого запозичено у 4.4BSD-Lite.

FreeBSD 3.0 приніс до проекту багато змін: перехід до двійкового формату ELF, з'явилася початкова підтримка SMP-систем і 64-розрядної архітектури Alpha. У свій час, гілка 3.х серйозно критикувалася, оскільки багато змін не були очевидно вигідними і мало впливали на роботу, однак, вона була необхідним кроком у розвитку проекту, котрий допоміг гілці 4.х стати дуже успішною.

FreeBSD 4 була дуже популярною серед інтернет-провайдерів і хостерів часів першого «міхура доткомів» і вважалася за одну з найстабільніших і високопродуктивних систем класу Unix. Одним з головних недоліків FreeBSD 4 вважається погана підтримка багатопроцесорних систем, особливо в режимі багатоточності. FreeBSD 4 поставила своєрідний рекорд за тривалістю розробки однієї гілки операційної системи -- за п'ять років було усунено велику кількість помилок і отримана на рідкість стабільна система. В середині розробки FreeBSD 4 від неї відокремився проект Dragonflybsd, засновники якого поставили собі за мету серйозну оптимізацію ядра для високо-навантажених систем, зокрема кращу підтримку багатопроцесорності (зменшення часу, необхідного для перемикання ниток і ін.).

Модель розробки FreeBSD

Існує близько 4000 розробників, які працюють над системою на добровільній основі. Всі вони можуть читати дерево репозиторія, але не можуть вносити зміни. Замість цього розробник звертається до коммітера, який має право вносити зміну до коду. Існує близько 400 коммітерів. Розробник може вирости по соціальних сходах проекту і стати коммітером. Кандидатуру нового коммітера пропонує до розгляду ментор майбутнього коммітера. Залежно від основної області діяльності, новий коммітер затверджується основною командою, portmgr@ або docmgr@. Основна команда є адміністративним ядром проекту і складається з 9 чоловік, які вибираються на 2 роки коммітерами зі свого складу. Основна команда вирішує конфлікти між коммітерами.

Учасники проекту розробляють гілку CURRENT («поточна» версія) і декілька STABLE («стабільна», стабільність означає гарантію незмінності інтерфейсів, як API, ABI і так далі).

Новий код поміщають у гілку CURRENT, де він отримує ширше тестування. Нові функції, додані в CURRENT, можуть залишитися в системі або від них можуть відмовитися, якщо реалізація виявиться невдалою. Інколи ця версія може опинитися в непридатному для використання стані. З початком використання perforce як допоміжного репозиторія, і з виділенням projects/ області в svn, проект прагне гарантувати постійну працездатність CURRENT.

STABLE-версія містить тільки ті нововведення, які пройшли перевірку в CURRENT. Проте, ця версія теж призначена в основному для розробників. Не рекомендується оновлювати відповідальні робочі сервери до STABLE, заздалегідь її не протестувавши. На основі STABLE регулярно створюються ретельно протестовані розробниками, групою release-інженерів і ширшим довкола користувачів RELEASE-версії.

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

Спочатку, FreeBSD використовувала в якості свого логотипу демона BSD, однак у 2005 році, був влаштований конкурс на створення нового логотипу. 8 жовтня 2005 змагання завершилися, і переміг у них Anton K. Gural, малюнок котрого став новим логотипом проекту. Однак, демон BSD залишається талісманом проекту FreeBSD.

Ліцензія

Як і споріднені з нею операційні системи, код FreeBSD розповсюджується під різними ліцензіями. Весь код ядра і весь новостворений код розповсюджується під ліцензією BSD, котра дозволяє будь-кому використовувати і розповсюджувати FreeBSD скільки їм заманеться.

FreeBSD популярна завдяки своїй ліцензії, яка істотно відрізняється від широко відомої ліцензії GNU GPL -- вона дозволяє використовувати код не лише в вільному ПЗ, але і в пропрієтарному. На відміну від GNU LGPL, яка теж дозволяє використовувати вільний код в закритій програмі, ліцензія BSD простіша і коротша.

Частина коду утиліт розповсюджується за ліцензіями GPL, LGPL, ISC, CDDL та Beerware.

Деякий код доступний лише у двійковому вигляді, на кшталт шару абстрагування апаратних засобів (HAL) драйверів для бездротових пристроїв Atheros та утиліт для Adaptec AAC RAID (поставляється у вигляді пакету).

Сумісність з Linux

FreeBSD забезпечує сумісність з деякими іншими UNIX-подібними операційними системами, зокрема, з Лінукс. Шар сумісності надає можливість працювати з програмним забезпеченням для Лінукс, котре розповсюджується лише у двійковому форматі, і не може бути портовано на FreeBSD.

FreeBSD має два можливих варіанти сумісності: для користувачів та для розробників. Варіант для користувачів має назву, що починається linux_base а для розробників -- linux_dist. Обидва варіанти можна встановити із портів, розділ emulators (емулятори).

2.9.2 Відгалуження

· DragonFlyBSD -- відгалуження від FreeBSD 4.8. Вона має систему потокової обробки повідомлень, схожу на ту, що застосовується в системах із мікроядром.

· FreeNAS -- дистрибутив на базі мінімального FreeBSD, орієнтований для створення NAS-систем

· Frenzy -- LiveCD-дистрибутив на базі FreeBSD, орієнтований на україномовних та російськомовних системних адміністраторів.

· FreeSBIE -- LiveCD-дистрибутив FreeBSD.

· BSDeviant -- також LiveCD-дистрибутив FreeBSD.

· PicoBSD -- мініатюрна версія FreeBSD, відгалуження від другої вітки, в наш час не розвивається.

· Darwin -- ядро Mac OS X, чимало запозичило у FreeBSD, розробляється фірмою Apple.

· PC-BSD -- дистрибутив із графічним інсталятором, орієнтований на настільні системи.

· DesktopBSD -- дистрибутив для настільних систем.

· TrueBSD -- дистрибутив для настільних систем.

· RoFreeSBIE -- румунський дистрибутив для настільних систем.

2.9.3 Варіанти установки

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

· dvd-rom;

· CD-ROM;

· USB флеш-накопичувач;

· дискета;

· магнітна стрічка;

· FAT-розділ жорсткого диска;

· віддалений сервер (по протоколу FTP або nfs).

2.9.4 Порти і пакети

В даний час FreeBSD надає користувачеві дві взаємодоповнюючі технології установки програмного забезпечення сторонніх розробників: колекція портів FreeBSD і бінарні пакети з програмним забезпеченням.

Будь-яка з цих систем може бути використана для установки найостанніших версій додатків з локальних носіїв або прямо з мережі. Тепер колекція портів налічує понад 22 тис. додатків самого різного призначення.

2.9.5 Талісмани-логотипи

Основним талісманом системи є червоне чортеня, відомий також як beastie. Окрім нього, за талісман також вважається Devilette, дівчина в червоному костюмі демона.

2.10 Мова програмування С++

2.10.1 Виникнення і еволюція мови C + +

Бьерн Страуструп є розробником мови С + + і творцем першого транслятора. Він - співробітник науково-дослідного обчислювального центру AT & T Bell Laboratories в Мюррей Хілл (Нью-Джерсі, США). Він отримав звання магістра математики та обчислювальної техніки в університеті м. Аарус (Данія), а лікарське звання з обчислювальної техніки в Кембриджського університету (Англія). Він спеціалізується в галузі розподілених систем, операційних систем, моделювання та програмування. Разом з М. А. Елліс він є автором повного керівництва по мові С + + - "Керівництво по С + + з примітками".

Безумовно С + + багатьом зобов'язаний мові С, який зберігається як його підмножина. Збережено і усі властиві З засоби низького рівня, призначені для вирішення найбільш нагальних завдань системного програмування. С, у свою чергу, багато чим зобов'язаний своєму попередникові мови BCPL. Коментар мови BCPL був відновлений в С + +. Ще одним джерелом натхнення була мова SIMULA-67; саме з нього була запозичена концепція класів (разом c похідними класами і віртуальними функціями). Можливість в С + + перевантаження операцій і свобода розміщення описів скрізь, де може зустрічатися оператор, нагадують мову Алгол-68.

Більш ранні версії мови, що отримали назву "С з класами", використовувалися, починаючи з 1980 р. Ця мова виникла тому, що автору потрібно написати програми моделювання, керовані перериваннями. Мова SIMULA-67 ідеально підходить для цього, якщо не враховувати ефективність. Мова "С з класами" використовувався для великих завдань моделювання. Суворій перевірці піддалися тоді можливості написання на ньому програм, для яких критичні ресурси часу і пам'яті. У цій мові бракувало перевантаження операцій, посилань, віртуальних функцій і багатьох інших можливостей. Вперше С + + вийшов за межі дослідницької групи, в якій працював автор, в липні 1983 р., однак тоді багато можливості С + + ще не були розроблені.

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

Спочатку С + + був задуманий для того, щоб авторові та його друзям не треба було програмувати на асемблері, С або інших сучасних мовах високого рівня. Основне його призначення - спростити і зробити більш приємним процес програмування для окремого програміста. До недавнього часу не було плану розробки С + + на папері. Проектування, реалізація та документування йшли паралельно. Ніколи не існувало "проекту С + +" або "Комітету з розробки С + +". Тому мова розвивалася і продовжує розвиватися так, щоб подолати всі проблеми, з якими зіткнулися користувачі. Поштовхами до розвитку служать також і обговорення автором всіх проблем з його друзями та колегами.

З моменту виходу в світ першого видання цієї книги мову С + + піддався істотним змінам і уточненням. В основному це стосується вирішення неоднозначності при перевантаженні, зв'язуванні та управлінні пам'яттю. Разом з тим, були внесені незначні зміни з метою збільшити сумісність з мовою С. Були також введені деякі узагальнення і суттєві розширення, як то: множинне успадкування, функції-члени зі специфікаціями static і const, захищені члени (protected), шаблони типу і обробка особливих ситуацій. Всі ці розширення та доопрацювання були націлені на те, щоб С + + стала мовою, на якому можна створювати і використовувати бібліотеки.

Інші розширення, введені за період між 1985 і 1991 р.р. (Такі як множинне спадкування, статичні функції-члени і чисті віртуальні функції), швидше за з'явилися в результаті узагальнення досвіду програмування на С + +, ніж були почерпнуті з інших мов.

Зроблені за ці шість років розширення мови насамперед були спрямовані на підвищення виразності С + + як мови абстракції даних і об'єктно-орієнтованого програмування взагалі і як засобу для створення високоякісних бібліотек з користувача типами даних зокрема.

Приблизно в 1987 р. стало очевидно, що робота зі стандартизації С + + неминуча і що слід негайно приступити до створення основи для неї.
Фірма AT & T Bell Laboratories внесла основний внесок в цю роботу. Близько ста представників з порядка 20 організацій вивчали й коментували те, що стало сучасною версією довідкового керівництва і вихідними матеріалами для ANSI по стандартизації. С + +.

Нарешті, з ініціативи фірми Hewlett-Packard в грудні 1989 р. у складі ANSI був утворений комітет X3J16. Очікується, що роботи зі стандартизації С + + в ANSI (американський стандарт) стануть складовою частиною робіт по стандартизації силами ISO (Міжнародної організації зі стандартизації).

С + + розвивався одночасно з розвитком деяких фундаментальних класів.

2.10.2 Зауваження щодо проекту мови

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

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

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

Мова С + + проектувався для використання в досить традиційному середовищі, а саме: в системі програмування С операційної системи UNIX. Але є цілком обгрунтовані доводи на користь використання С + + в багатшій програмному середовищі. Такі можливості, як динамічне завантаження, розвинені системи трансляції і бази даних для зберігання визначень типів, можна успішно використовувати без шкоди для мови.

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

2.10.3 Порівняння мов С + + і С

Вибір С в якості базової мови для С + + пояснюється наступними його перевагами[13]:

(1) універсальність, стислість і відносно низький рівень;

(2) адекватність більшості завдань системного програмування;

(3) він іде в будь-якій системі і на будь-якій машині;

(4) повністю підходить для програмного середовища UNIX.

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

С + + став використовуватися ширше, але у міру зростання його можливостей, що виходять за межі С, знову і знову виникала проблема сумісності. Ясно, що відмовившись від частини спадщини З, можна уникнути деяких проблем. Це не було зроблено з наступних причин:

· Існують мільйони рядків програм на С, які можна поліпшити за допомогою С + +, але за умови, що повної переписом їх на мову С + + не потрібно;

· Існують мільйони рядків бібліотечних функцій та службових програм на С, які можна було б використовувати в С + + за умов сумісності обох мов на стадії зв'язування і їх великої синтаксичного подібності;

· Існують сотні тисяч програмістів, які знають С; їм достатньо опанувати тільки новими засобами С + + і не треба вивчати основ мови;

· Оскільки С і С + + будуть використовуватися одними і тими ж людьми на одних і тих же системах багато років, відмінності між мовами повинні бути або мінімальними, або максимальними, щоб звести до мінімуму кількість помилок і непорозумінь.

Опис С + + було перероблено так, щоб гарантувати, що будь-яка допустима в обох мовах конструкція означала в них одне і те ж. Як мова, так і стандартні бібліотеки С + + проектувалися в розрахунку на переносимість. Наявні реалізації мови будуть працювати в більшості систем, що підтримують С. У програмах на С + + можна використовувати бібліотеки С. Більшість службових програм, розрахованих на С, можна використовувати і в С + +.

Мова С сама розвивалася в останні кілька років, що частково було пов'язане з розробкою С + +. Стандарт ANSI для С містить, наприклад, синтаксис опису функцій, запозичений з мови "С з класами". Відбувається взаємне запозичення, наприклад, тип покажчика void * був придуманий для ANSI З, а вперше реалізований в С + +. Опис С + + було доопрацьовано, щоб виключити невиправдані розбіжності. Тепер С + + більш сумісний з мовою С, ніж це було. В ідеалі С + + повинен максимально наближатися до ANSI C, але не більше. Стовідсоткової сумісності ніколи не було і не буде, оскільки це порушить надійність типів і узгодженість використання вбудованих і призначених для користувача типів, а ці властивості завжди були одними з головних для С + +.

Для вивчення С + + не обов'язково знати С. Програмування на С сприяє засвоєнню прийомів і навіть трюків, які при програмуванні на С + + стають просто непотрібними. Наприклад, явне перетворення типу (приведення), в С + + потрібно набагато рідше, ніж в С (див. "Зауваження для програмістів на С" нижче). Тим не менш, гарні програми на мові С по суті є програмами на С + +. Наприклад, всі програми з класичного опису є програмами на С + +. У процесі вивчення С + + буде корисний досвід роботи з будь-якою мовою зі статичними типами.

Зауваження для програмістів на С

Чим краще програміст знає С, тим складніше буде для нього при програмуванні на С + + відійти від стилю програмування на С. Так він втрачає потенційні переваги С + +.

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

2.10.4 Ефективність та структура

Розвиток мови С + + відбувалося на базі мови С, і, за невеликим винятком, С був збережений як підмножини C + +. Базова мова С був спроектований таким чином, що є дуже тісний зв'язок між типами, операціями, операторами та об'єктами, з якими безпосередньо працює машина, тобто числами, символами та адресами. За винятком операцій new, delete і throw, а також перевіряється блоку, для виконання операторів і виразів С + + не потрібно прихованої динамічної апаратної або програмної підтримки.

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

У проекті С + + особлива увага приділяється структуруванню програми. Це викликано збільшенням розмірів програм з часу появи С. Невелику програму (скажімо, не більше 1000 рядків) можна змусити з упертості працювати, порушуючи всі правила хорошого стилю програмування. Однак, діючи так, людина вже не зможе впоратися з великою програмою. Якщо у вашої програми в 10 000 рядків погана структура, то ви виявите, що нові помилки з'являються в ній так само швидко, як видаляються старі. С + + створювався з метою, щоб велику програму можна було структурувати таким чином, щоб одній людині не довелося працювати з текстом в 25000 рядків. В даний час можна вважати, що ця мета повністю досягнута.

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

На жаль, не всяку частина програми можна добре структурувати, зробити незалежною від апаратури, досить зрозумілою і т.д. У С + + є засоби, які безпосередньо й ефективно представляють апаратні можливості. Їх використання дозволяє позбутися від занепокоєння про надійність і простоті розуміння програми. Такі частини програми можна приховувати, надаючи надійний і простий інтерфейс з ними.

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

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

2.11 Мова Асемблер

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

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

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

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

Асемблер (assembler) -- система програмування, яка включає мову асемблера та транслятор з цієї мови. Є мовою програмування низького рівня. Чим нижчий рівень мови програмування, тим ближча специфіка роботи програми до самого процесора, для якого вона й була написана. Вважається, що мови низького рівня складніші й потребують більш вузької спеціалізації програміста, оскільки програма написана на асемблері для одного типу процесорів виявиться не завжди придатною для роботи з іншими процесорами. З іншого боку програми написані на асемблері компактні та швидкі, що теж є немаловажливим.

Поки існують процесори, буде існувати й асемблер.

Висновки до розділу 2

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

Розділ 3. Практична реалізація проекту

Маніпулятор було збудовано на базі мікроконтролера AVR ATMega32 виробництва Atmel. Моделювання схеми проводилось у програмі Proteus Portable 7.4. Програма для мікроконтролера була створена у AVRStudio 5.0. Детальніше про ці програмні продукти можна дізнатися у розділі 2. Функції маніпулятора:

- Можливість повороту на 360 градусів навколо вертикальної осі;

- Кут нахилу „стріли” маніпулятора - 130 градусів;

- Можливість обертання схвату навколо своєї осі;

- Електромагнітний підпружинений схват;

- Можливість безпосередньо спостерігати за своїми діями реалізована за допомогою веб-камери і бібліотеки комп'ютерного зору OpenCV.

3.1 Апаратна реалізація

В якості рушійної сили були використані двигуни ДПР-42-Н1-03, а також мікросхема-драйвер двигуна L293D. Керуюча схема збиралась на стандартній двошаровій текстолітній платі з мідним покриттям. Травка плати виконувалась за допомогою хлорного заліза. Розмітка наносилась на заготовку лазерно-прасковим методом.

3.1.1 Розробка схеми

Схема прототипа була розроблена в програмному комплексі Proteus Portable 7.4. Спочатку, за допомогою програми ISIS було побудовано, перевірено і протестовано макет схеми (Рис. 3.1.)



Рис. 3.1 Макет схеми маніпулятора

Далі, за допомогою програми ARES, елементи було скомпоновано, розведені доріжки та роздруковано шаблон для лазерно-праскового методу перенесення на текстолітову основу (Рис. 3.2, 3.3, 3.4).



Рис. 3.2 Схема з розведеними доріжками

Рис. 3.3 Верхній шар плати



Рис. 3.4 Нижній шар плати

3.1.2 Лазерно-прасковий метод

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

Етап 1. Малюємо плату. Можна користуватися спеціальними програмами, які автоматично розводять плату за принциповою схемою, наприклад PCAD , Proteus або Sprint Layout.

Ставимо сітку 2,54 мм (0,1 дюйма) - це крок між ногами мікросхем і цілком вистачає на більшість деталей (якщо розміщувати резистори і діоди стоячи). Малювати зручніше з боку деталей, при цьому схема виходить більш наочною, а при друку зображення доріжок не треба перевертати. Зручно зробити окремі шари для друкованих провідників і для зображення деталей (можна включити / виключити при перегляді і друку). Доріжки малюються лінією 2pt, площадки під виводи кільцями 0,7 / 1,5-2,0 мм, під дроти 1,25 / 2,5-3,0 мм (внутрішній / зовнішній діаметр). Після остаточної компоновки деталей і розводки плати зручно обвести її по контуру з припуском 0,5-1 мм лінією 1pt на шарі провідників, для обрізки (особливо актуально для плат із складним контуром). Також позначаємо на шарі провідників отвори для кріплення і інші технологічні мітки.

Увага: перед тим, як щось робити далі, обов'язково двічі перевірте розведення провідників (особливо, якщо робили не в спеціалізованій програмі, а в графічному редакторі) і чи потрібно віддзеркалити зображення перед друком. Загальне правило таке: якщо на малюнку друковані провідники (неважливо якого шару) видно зі свого боку плати, перед друком зображення ПОТРІБНО віддзеркалити (неважливо, від горизонталі або вертикалі, головне один раз). Якщо ж провідники видно «крізь плату» (наприклад, малюємо провідники зі зворотного боку плати, а дивимося з боку деталей), то віддзеркалювати малюнок НЕ ПОТРІБНО. Якщо сумніваєтеся, роздрукуйте зображення кожного шару (це, до речі, рекомендується робити і для перевірки розводки) і прикиньте необхідність віддзеркалення "наживо". Тільки пам'ятайте, що один раз зображення віддзеркалиться при перенесенні з паперу на текстоліт.

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

Етап 3. Береться лазерний принтер і друкується малюнок доріжок на дуже тонкому крейдованому папері. При друку не забудьте залишити краї приблизно в половину відповідного розміру плати (зліва і справа - половину ширини, зверху і знизу - висоти). Я використовую Samsung SCX 3200 з максимальною "чорнотою" (відключити економний режим, максимальна насиченість) і папір з журналів "Кореспондент". У нього крім дуже маленької товщини є особливість застрягати в принтері перед пічкою, тому після витягування аркуша ми отримуємо незакріплене зображення. Але якщо Ваш папір пічку пройшов, має вийти не гірше. Хоча якщо робити плати доводиться часто, може є сенс зробити можливість відключення печі у вашого принтера.

Етап 4. Отриману роздруківку кладемо на стіл зображенням вгору. Готуємо смужки скотчу шириною сантиметр-два і довжиною в залежності від розмірів плати. Накладаємо заготовку плати на папір підготовленою стороною до зображення і загортаємо краї паперу, фіксуючи папір приготованими смужками скотчу. Папір повинен бути трохи натягнутим, щоб плата не могла зміститися всередині отриманої обгортки. Після цього загортаємо весь "бутерброд" ще одним аркушем звичайного паперу (в один шар). Тепер береться звичайна праска, увімкнена на максимальну температуру і ставиться на загорнуту в папір плату з боку малюнка. Плата прогрівається 20-30 сек. під власною вагою праски, після чого праска кілька разів з натиском проводиться по поверхні плати. Для маленьких плат і незакріпленого зображення досить 4-6 разів з не дуже сильним натиском (не всією вагою). При сильному натиску тонер може поповзти і сусідні доріжки злипнуться, при слабкому - не приклеїтися.

Етап 5. Після охолодження знімаємо зовнішній папір і зрізаємо папір із зворотного боку плати. Потім кидаємо плату з папером що прилип в гарячу (градусів 40-50, тобто терпимо гаряча на дотик) воду і чекаємо, поки папір не розмокне. Коли це станеться, папір можна буде відокремити від плати, а тонер залишиться, надійно припеченний до плати (пальцем не отскребешь). Пальцем під водою скочуємо залишки паперу. Плата сушиться (без додаткового підігріву, щоб тонер не почав відходити), після чого озброюємося лупою і проглядаємо дефекти. Можна охайно промокнути плату туалетним папером, щоб прискорити процес сушіння. При правильно виконаних попередніх кроках дефект що зустрічається найбільш часто - не до кінця видалений папір, що при травленні може призвести до замикання провідників. Папір видаляємо гострим предметом: шилом, голкою, кінчиком ножа. При зворотній проблемі - відсутності провідників там, де вони повинні бути, можна підправити малюнок лаком або незмивним маркером (потрібно заздалегідь випробувати маркер щоб переконатися в його стійкості).

Етап 6. Травимо плату в хлорному залізі. Розчин краще підігріти до тих же 40-50 градусів, правда він все одно охолоджується швидше, ніж травиться плата. Основна проблема при травленні - плата повинна лежати малюнком вниз (щоб продукти реакції опускалися на дно, а не лежали на платі), але при цьому потрібно забезпечити доступ розчину. Я вирішую цю проблему приклеюванням до країв (той самий припуск) сірників, а якщо плата більша можна просвердлити отвори і вставити в них пластикові (не металеві!) стійки для материнських плат. Або ті ж сірники. Після того, як малюнок повністю протравиться, плату виймають, заклеюють сторону з малюнком скотчем, щоб уникнути подальшого подтравливания доріжок, після чого перевертають і стравлюють фольгу з боку деталей. Можна травити плати і у вертикальному положенні, наприклад у вузькому стакані, тоді описаних труднощів можна уникнути, але важче забезпечити рівномірність травлення.

Етап 7. Змиваємо тонер, наприклад, уайт-спіритом, потім свердлимо отвори, вирізаємо плату по необхідному контуру, покриваємо каніфольним лаком, залужуємо контактні майданчики. Далі монтаж деталей.

3.1.3 Монтаж пристрою

Монтаж елементів на плату проводився за допомогою паяльного пристрою ЕПСН 40/220, флюса F3, припою ПОС 61 та рідини для змивання залишків каніфолі на нейтральній основі.

В якості джерела живлення використовується комп'ютерний блок живлення Codegen 200W (220В, 200Вт), живлення підводиться через стандартний молекс-роз'єм. (J3 на схемі). Обмін даними проводиться за допомогою LPT-під'єднання (J1). Роз'єм J2 служить для підімкнення двигунів та електромагнітного хвата.

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

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

3.2 Програмна частина

3.2.1 Програма мікроконтроллера

Мікроконтроллер програмувався мовою С за допомогою AVR Studio i CVAVR.

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

3.2.2 Програма обміну даними між користувачем і маніпулятором

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

· Кут повороту ліворуч/праворуч;

· Кут підйому вгору/вниз;

· Кут обертання схвату;

· Схватити/відпустити;

Кути вираховуються за допомогою затримки, впродовж якої до маніпулятора надходить той чи інший сигнал. Знаючи швидкість обертання двигуна і час, на який встановлена затримка, можна без зусиль вирахувати, на який кут повернеться/підніметься та чи інша ланка маніпулятора. Програму створено за допомогою GNU C Compiler (GCC), що входить до складу ОС FreeBSD.

3.2.3 Користувацький веб-інтерфейс

Інтерфейс користувача написаний мовами програмування PHP i HTML. Користувач заходить на сервер і бачить панель керування маніпулятором, а також вікно, в котре передається відео потік з веб-камери.

ВИСНОВКИ

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

· Сформульовано вимоги до розробки власної моделі маніпулятора та системи керування;

· Досліджено сучасні технологіі, методи та засоби автоматизації та керування;

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

При реалізації проекту було використано:

· Для проектування прототипу - засоби AVR Studio, Proteus 7.4;

· Для реалізації системи керування - мови PHP, HTML, C, Assembler;

· В якості платформи для системи керування - ОС FreeBSD, веб-сервер Apache 2.2;

· В якості головного процесора маніпулятора - мікроконтроллер AVR ATMega32;

· Підключення маніпулятора до комп'ютера здійснюється за допомогою паралельного порта (LPT);

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

Список використаних джерел

1. Енциклопедія кібернетики в 2 т. / За ред. В. М. Глушкова. -- Київ: Головна редакція Української радянської енциклопедії, 1973.;

2. http://www.labcenter.com/index.cfm;

3. AVR RISC microcontrollers handbook By Claus Kuhnel, ISBN 0-7506-9996-9, глава «4.2 ATMEL AVR Studio AVR Studio», стр 144--146;

4. http://www.html.net/tutorials/html/introduction.asp;

5. http://www.freebsd.org/;

6. Christopher Negus, Francois Caen, BSD UNIX Toolbox: 1000+ Commands for FREEBSD, OPENBSD and NETBSD, Wiley, May 5 2008, 309 стор., ISBN 0-470-37603-1.

7. http://httpd.apache.org/

8. http://www.php.net/manual/en/index.php

9. http://www.gaw.ru/html.cgi/txt/ic/Atmel/micros/avr/atmega32.htm

10. http://avr123.nm.ru/

11. http://locv.ru/wiki/%D0%9E%D0%B3%D0%BB%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5

12. www.opensource.org

13. Керниган, Ричи. Язык C;

14. Таненбаум Архітектура комп'ютера;

15. Рудаков П.И., Финогенов К.Г. Язык ассемблера - уроки программирования -М.:ДИАЛОГ-МИФИ, 2001.-640 с.

Размещено на Allbest.ru