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

Р Е Ф Е РА Т

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

2001р.

ПЛАН.

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

2. Опис ЯП.

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

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

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

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

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

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

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

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

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

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

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р.