Еволюція мов програмування

Інформатика, програмування

Р Е Ф Е РА Т

Еволюція мов програмування.

2001р.

ПЛАН.

1. Мови програмування (ЯП).

2. Опис ЯП.

3. Технології програмування.

4. CASE - системи.

5. Штучний інтелект, експертні системи.

6. Список використаної літератури.

1. Мови програмування (ЯП).

Проведемо асоціації комп'ютера з людиною. У комп'ютера є органи сприйняття інформації із зовнішнього світу - це клавіатура, миша, накопичувачі на магнітних дисках. У комп'ютера є органи, "переварювати" отриману інформацію, - це центральний процесор і оперативна пам'ять. І нарешті, у комп'ютера є органи мови, що видають результати переробки. Сучасним комп'ютерам, звичайно далеко до людини. Їх можна порівняти з істотами, що взаємодіють із зовнішнім світом на рівні обмеженого набору безумовних рефлексів. Цей набір рефлексів утворює систему машинних команд. На якому б високому рівні ми не спілкувалися з комп'ютером, в кінцевому підсумку все зводиться до нудною та одноманітною послідовності машинних команд. Кожна машинна команда є свого роду подразником для порушення того чи іншого безумовного рефлексу. Реакція на цей подразник завжди однозначна і "зашита" в блоці мікрокоманд у вигляді прошивки. Ця вбудоване і реалізує дії з реалізації машинної команди, але вже на рівні сигналів, що подаються на ті чи інші логічні схеми комп'ютера, тим самим, керуючи різними підсистемами комп'ютера. У цьому полягає так званий принцип мікропрограмного управління. Продовжуючи аналогію з людиною, відзначимо: для того, щоб комп'ютер правильно харчувався, придумано безліч операційних систем, компіляторів сотень мов програмування. Але всі вони є по суті лише стравою, на якому за певними правилами доставляється їжа (програми) шлунку (комп'ютера). Тільки шлунок комп'ютера любить дієтичну, одноманітну їжу - подавай йому інформацію структуровану, у вигляді строго організованих послідовностей нулів і одиниць, комбінації яких складають машинний мова. Таким чином, зовні будучи поліглотом, комп'ютер розуміє тільки одну мову - мову машинних команд.

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

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

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

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

2. Опис ЯП Мова Основне використання Опис Ада В обороні Високого рівня Асемблер Роботи, які потребують детального контролю за апаратним забезпеченням, швидкого виконання і програм малого розміру Швидкий і ефективний, але вимагає певних зусиль і навичок Бейсік В освіті, бізнесі, будинки Простий у вивченні З Системне програмування, універсальне програмування Швидкий і ефективний, широко використовується як універсальна мова С + + В об'єктно-орієнтованому програмуванні Заснований на мові С Кобол Програмування в бізнесі Жорстко орієнтований на комерційні завдання, легко навчитися, але дуже багато операторів Форт Управління додатками Використовує інверсно польську запис Фортран Наукова робота і обчислення Заснований на математичних формулах Лісп Штучний інтелект Мова символів з репутацією важко вивчається Модула-2 Системне програмування і програмування в режимі реального часу, універсальне програмування Високо структурований, призначений замінити Паскаль для програм "реального світу" Оберон Універсальне програмування Невеликий, компактний мова, що поєднує багато рис Паскаля і Модула-2 Паскаль Універсальна мова Високо структурований Пролог Штучний інтелект Символьно-логічна система програмування, на початку призначена для вирішення теорем, але зараз використовується частіше для вирішення завдань, пов'язаних зі штучним інтелектом

3. Технології програмування.

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

Структурне програмування.

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

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

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

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

Концепція модульного програмування.

Так само як і для структурної технології програмування, концепцію модульного програмування можна сформулювати у вигляді декількох понять і положень:

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

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

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

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

Об'єктно-орієнтоване програмування (ООП).

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

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

Спадкування - властивість об'єктів породжувати своїх нащадків. Об'єкт - нащадок автоматично успадковує від батьків усі поля і методи, може доповнювати об'єкти новими полями і замінювати (перекривати) методи з батьків або доповнювати їх.

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

4. CASE - системи.

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

В Америці з - за сільнейшнй конкуренції CASE - кошти використовуються переважною більшістю фірм - розробників програмного забезпечення. Потужний поштовх CASE - засобу отримали в пору впровадження об'єктів - орієнтованої технології розробки ПЗ, коли старого, перевіреного часом методу проектування "зверху вниз" стало явно недостатньо. До того ж з'явилися технології об'єктного моделювання Booch, OMT, UML, самі по собі дуже складні для прив'язки до мов програмування, щоб оперувати ними вручну.

Сьогодні лідерів у світі CASE-системою вважається Rational Rose корпорації Rational Software. Система Rational Rose націлена на створення модулів з використанням мови Unified Modeling Language (UML). До речі, UML став стандартним мовою об'єктно-орієнтованої розробки не без подачі Rational Software, яка не тільки випускає програмні продукти, де використовуються UML, але й активно бере участь в організації Object Management Group (OMG), зайнятої створенням та оновленням специфікацій мови UML, технології розподілених обчислень CORBA і т.д. в компанії Rational працюють три творці і євангеліста об'єктно-орієнтованої розробки та мови UML. Це Граді Буч, Айвар Джекобсон і Джим Рамбаух.

Остання версія CASE-системи компанії Rational Software Rational Rose 98 вже щосили застосовується для створення комерційного ПЗ і підтримує популярні мови програмування Java, Cu + +, Смолток, Ада, Visual Basic, Power Builder і Forte. Крім того, пакет Rose 98 здатний генерувати описи на мовах Interface Definition Language (IDL) для додатків CORBA і Data Definition Language (DDL) для програм доступу до баз даних, у тому числі і Oracle 8. Зрозуміло, підтримка тієї чи іншої мови програмування залежить від того, про яку редакції пакета Rational Rose 98 йде мова.

Наприклад, не можна вимагати багато чого від найпростішого варіанту пакету - Rose 98 Modeler Edition. Зате Rose 98 Enterprise Edition оснащений від душі.

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

Переваги від застосування Rational Rose 98 значні:

1. Скорочення циклу розробки програми.

2. Збільшення продуктивності роботи програмістів.

3. Поліпшення споживчих якостей створюваних програм за рахунок орієнтації на користувачів і бізнес.

4. Здатність вести великі проекти і групи проектів.

5. Можливість повторного використання вже створеного програмного забезпечення за рахунок упору на розбір їх архітектури і компонентів.

6. Мова UML є універсальним "містком" між розробниками з різних відділів.

5. Технологічна схема розв'язання задач.

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

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

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

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

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

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

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

Індустрія штучного інтелекту.

Бум, що виник в кінці с?? мідесятих років в штучному інтелекті і який призвів до створення нової галузі промисловості, не випадковий. Три причини викликали його.

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

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

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

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

Експертні системи.

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

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

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

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

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

Інтелектуальний інтерфейс

Користувач

Малюнок демонструє загальну структуру консультаційної експертної системи.

Система спілкування дозволяє вводити в експертну систему на інформацію, обмеженому рамками професійної області, природною мовою і організовує ведення діалогу з користувачем. Ця система повідомляє користувача про незрозумілих для неї словах, про допущені ним помилки, пропонує набори дій, які користувач при бажанні може виконати. Якщо користувач ще не освоїв "етику прийому", то в справу включається блок навчання; в діалоговому режимі він поступово навчає користувача з спілкування з ЕОМ, вчить його, використовуючи приклади, розв'язання задач. Користувач може звертатися до цього вчителя, коли захоче, - система завжди знайде час для пояснення незрозумілих користувачеві моментів.

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

Коли археолог через систему спілкування звертається до системи за консультацією, то вона може почати з того, що зажадає ввести опис усіх тих знахідок (мовою, зрозумілою системі), якими цей археолог має в своєму розпорядженні. Отримавши в своє розпорядження ці описи, експертна система починає формувати логічний висновок. Від вихідних фактів, введених у неї, і за допомогою тих взаємозв'язків, які повинні існувати між фактами, вона виводить гіпотези, які не суперечать спостережуваних фактів. Якщо ця гіпотеза однозначна, то вона повідомляється користувачеві. Якщо має альтернативні можливості, то експертна система може задати археологу додаткові уточнюючі питання, наприклад, про характері малюнків на залишках знайденої кераміки, які ще не були повідомлені системі. Якщо археолог не може повідомити системі ніяких нових додаткових відомостей, то йому буде повідомлено кілька гіпотез про датування. При цьому кожна гіпотеза може оцінюватися деяким вагою достовірності. Наприклад, відповідь може мати вигляд: "Цей об'єкт відноситься до періоду А з вірогідністю 15% і до періоду В з вірогідністю 85%". Якщо при подальших розкопках буде виявлений інший предмет, то він датується періодом В як найбільш імовірним. Для кожного знову знайденого предмета можуть бути отримані вірогідності датування, а потім всі результати можуть бути проаналізовані спільно.

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

Система пояснення - найважливіша відмітна компонента експертних систем. До неї користувач може звертатися з питаннями типу "Що є Х?", "Як отриманий У?", "Чому отриманий У, а не Z?" і "Навіщо потрібен Х?". За кожним таким питанням ховається свій комплекс процедур, виконання яких дозволяє дати користувачеві, що його цікавить відповідь. Питання "Що є Х?" вимагає видачі користувачеві всієї інформації про Х, якою система має в своєму розпорядженні, що може зажадати вельми непростих пошукових процедур в базі знань. Ці процедури реалізуються в розв'язувача, тому що в багатьох випадках для відповіді на питання користувача треба з вихідних фактів, що зберігаються в базі, отримати логічним шляхом нові похідні факти.

Питання "Як отриманий У?" означає, що користувач хоче ознайомитися з тим, як міркувала система, крок за кроком виводячи з повідомлених їй користувачем фактів свій висновок. Щоб відповісти на таке питання система пояснення має звернутися до вирішувач, у пам'яті якого, як на екрані електронно-променевої трубки з післясвіченням, повинен деякий час зберігатися "трек" того шляху, який пройшов вирішувач.

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

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

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

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

6. Список використаної літератури.

1. Журнал "Наука и жизнь" № 6 1987р.

2. Юров В., Хорошенко С. Assembler: навчальний курс. СПб: Видавництво "Пітер", 1999р.

3. Фаронов В.В TurboPascal 7.0: початковий курс. М: Видавництво "Нолидж", 1998р.

4. Кишеньковий словник "Computing & Multimedia". М: Видавництво "Внешсігма", 1996р.

5. Журнал "Мир ПК" № 4 1999р.