Б С Бусигін - Прикладна інформатика - страница 21

Страницы:
1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30  31  32  33  34  35  36  37  38  39  40  41  42  43  44  45  46  47  48  49  50  51  52  53  54  55  56  57  58  59  60  61  62  63  64  65  66  67  68  69  70  71  72  73  74  75  76  77  78  79  80  81  82  83 

О Низький рівень (машинно-орієнтовані мови - мова асемблера)

© Високий рівень (процедурно-орієнтовані мови: FORTRAN, ALGOL, PL/1, Pascal. Пізніше деякі з них були дороблені до модульно -орієнтованого рівня у більш пізніх версіях). Сюди ж відносяться мови так званого третього покоління (3GL) (див. главу 5).

© Рівень задачі, що вирішується (проблемно-орієнтовані мови - GPS, SQL). Сюди ж відносяться мови четвертого покоління (4GL) (див. главу 5)

О Об'єктний рівень (об'єктно-орієнтовані мови - Smalltalk, C++, Delphi Object Pascal, Java і т.д.).

© Компонентний рівень (компонентно-орієнтовані мови - С#, Java і

т.д.)

Результатом постійного розвитку мов, у яких узагальнення поняття «тип даних» стали класи об'єктів (наприклад, у мові C++) або об'єктні типи (мова Pascal), котрі можуть містити (рос.-содержать) у якості елементів не тільки дані визначеного типу, але й методи їх обробки (функції і процедури) (рис. 7.4).

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

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

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

Окрім того, у об'єктно-орієнтованому підходу завжди присутні три типи даних і п'ять операційних характеристик, які є найбільш важливими базовими елементами і операціями. Типи даних уключають: об'єкт, клас і екземпляр. П'ять характеристик об'єктно-орієнтованої системи містить: абстракцію (abstraction), наслідування (inheritance), інкапсуляцію (encapsulation), поліморфізм (polymorphism) та динамічне зв'язування (dynamic binding). Ці елементи створюють потужне середовище для розробки додатків.

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

7.5).

Клас Book (Книга)

Об'єкти MyBook (МояКнига)

Author

Title

-FrontPage 2002 для Windows -Нолан Хестер -«ДМК Пресс» -2002

Publisher

-VB Script и ActiveX -Скотт Палмер -«ПИТЕР» -1999

Year

Рис. 7.5. Об'єкти MyBook класу Book

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

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

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

Алан Кей, автор і розробник першої об'єктно-орієнтованої мови програмування SmallTalk (рис.7.7), підсумовує (рос.-суммирует) п'ять головних її характеристик.

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

вирішити (собак, дома, послугу і

т.д.) і уявити його як об'єкт у вашої програмі.

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

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

О Кожний об'єкт має тип. Іншими словами, кожний об'єкт уявляється екземпляром класу, де "клас" - це синонім "типу". Більшість важливих відмінностей характеристик класу у тому, "Які повідомлення Ви можете йому посилати?"

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

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

7.2.Моделювання складних інформаційних систем

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

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

164

(рос.-определенному) об'єкту.

Рисунок 7.7. Автор першої ОО мови програмування Smalltalk Аллан Кей (позаду) і винахідник першого маніпулятора «миша» Дуг Знгельбарт (Doug EngelBart)

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

Рисунок 7.8. Фізична модель складної інформаційної системи і комплекс її об'єктно орієнтованих моделей у взаємозв'язку

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

2 У 1972 році була створена перша ОО мова SmallTalk, а у 1980 - ОО мова C++.

165

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

Рис. 7.9. Автоматизація залізничних перевезень за допомогою геоінформаційних систем (ГІС) у Австрії

Важливою ланкою (рос.-звеном) у розвитку ОО технологій аналізу, проектування і розробки програмних систем стало утворення в 1989 році некомерційного консорціуму «Група Управління Об'єктами» (Object Management Group - OMG3) (рис. 7.10), котрий об'єднав таких провідних виробників ПЗ, як DEC, HP, IBM, Microsoft, Oracle, Rational Software та ін. Це об'єднання стало могутнім каталізатором активізації продовження робіт з уніфікації методів та розробці індустріальних стандартів у області створення інтероперабельних4 неоднорідних розподілених об'єктних середовищ у інформаційних технологіях.

Прийняття OMG, починаючи з 1991 року, ряду версій індустріального стандарту CORBA (Common Object Request Broker Architecture) і деяких інших, пов'язаних з його інфраструктурою, а також активне практичне впровадження (рос.-внедрение) самих CORBA-технологій, не могли не викликати великий інтерес у розробників і користувачів цього стандарту до методів ОО аналізу і проектування,   до   усвідомлення   необхідності   розробки   стандарту мови

Заснована у квітні 1989 року одинадцятью компаніями, Object Management Group™ (OMG™), є неприбутковою організацією, що вже у 2003 році об'єднувала більш ніж 800 организацій-членів. В рамках діяльності корпорації розробляються комерційно перспективні і незалежні від виробників специфікації для софтверної індустрії. OMG™ продвигає Архітектуру, Ведомую Моделлю (Model Driven Architecture ™ ) у якості «Архітектури Вибору для Зв'язаного (комунікаціями) Світу» ("Architecture of Choice for a Connected World" ™) на базі розробляємих нею стандартних всесвітньо ввідомих специфікацій: CORBA®, CORBA/IIOP™, UML™, XMI™, MOF™, Object Services, Internet Facilities і Domain Interface. 4 Інтероперабельність - взаємна можливість/властивість інформаційних систем або комп'ютерів обмінюватися повідомленнями, виконувати програми або пересилати дані поміж їх різними функціональними блоками таким чином, щоб користувач при цьому практично ничого не повинен був би знати про особливості цих блоків. Підтримується засобами розвинутих багаторівневих інтерфейсів.

Рис. 7.10. Логотип організації

OMG

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

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

проектується.

Але так, як к середині 90-х існувало вже більш ніж 50-и різноманітних об'єктно-орієнтованих мов моделювання, розробники і замовники утруднялися (рос.-затруднялись) при виборі метода проектування ІС, котрий, як правило, включав у себе і власну нотацію (тобто засоби уявлення систем и їх реалізацій). В той же час, у число передових вирвались покрашені версії деяких конкуруючих методологій, серед котрих особливо виділялися техніка Booch'90 (автор Граді Буч (Grady Booch)) (рис. 7.11), об'єктно-орієнтована методологія OMT (Object Modeling Technique) (автор Джим Рамбо (Jim Rumbaugh)) (рис. 7.12) і ОО підхід Fusion.

Ці та деякі інші методи почали змішувати техніки один одного, в результаті чого з'явилося декілька широко відомих методологій: OOSE (Object Oriented System Engineering), OMT-2 и Booch'93. Але, у цілому, кожен з вищевказаних методів володів (рос.-обладал) своїй специфікою і оставався відособленим від інших. Коротко особливості кожного з цих методів можна висловити (рос.-выразить) наступним чином.

OOSE уявляв собою UseCase-орієнтованим підходом, котрий забезпечував прекрасні рішення у області бізнес-інжинірінгу5, а також при аналізі потреб до системи.

OMT-2 добре зарекомендував себе на стадії аналізу у системах, де вирішальну роль грала модель збереження (рос.-хранения) даних.

Рис. 7.11.

Гради Буч

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

Рис. 7.12. Джим Рамбо

Техніка Booch'93 була корисна на стадії проектування і грала велику роль при побудові систем зі складними алгоритмами функціонування.

У результаті серії переговорів і сприянні OMG розробка Уніфікованої Мови Моделювання UML (Unified Modeling Language) була почата як уніфікація двох методів (Booch'93 і OMT) у жовтні 1994 року Граді Бучем (Grady Booch) і Джимом Рамбо (Jim Rumbaugh) у колективі і при підтримці великої софтверної фірми Rational    Software    Corporation.    Перша версія Уніфікованого  Методу  (Unified Method  0.8) була оприлюднена у жовтні 1995. Восени 1995 до роботи приєднався Айвар Якобсон (Ivar Jacobson) (рис. 7.13), який уключив у загальний процес уніфікації ідеї свого методу    OOSE.     Таким    чином,    на першому концептуальному етапі UML мав трьох авторів: Буча, Рамбо і Якобсона, кожний з котрих був ідеологом свого ОО методу візуального моделювання. У жовтні 1996 року була випущена редакція UML 0.91, у котрої були відображені багаточисельні пропозиції, які "три друга (three amigos)"" отримали впродовж 1996 року. Каталізатором об'єднання зусиль з уніфікації UML став випуск   консорціумом   OMG   "запиту   на   пропозиції   (рус.-запроса на предложения)" з UML (RFP - Request for Proposal), так як випуск RFP є першим кроком процедури прийняття OMG того чи іншого стандарту.

Після цього Rational Software під своєю егідою об'єднала спеціалістів у організацію "Консорціум UML партнерів" ("UML Partners consortium") для вироблення формального визначення (рос.-определения) UML 1.0 у якості (рос.-качестве) єдиного стандарту. У роботі консорціуму прийняли участь представники таких відомих компаній як: Digital Equipment Corp., Hewlett-Packard, i-Logix, IntelliCorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational Software, TI, Unisys та ін.

Кожен з партнерів у OMG вніс свій вагомий внесок у розробку загального проекту. Hewlett-Packard, наприклад, забезпечувала зв'язок поміж моделями UML і концепцією "повторного використання", IBM розробляла мову OCL (Object Constraint Language - Мова Об'єктних Обмежень (рос. -Ограничений)), яка описує семантику мови UML. Microsoft розвивала концепцію компонентного програмування у рамках моделі (СОМ - Component Object Model) і використання моделей і артефактів UML у репозиторії6. Слід

Рис. 7.13. Айвар Якобсон

6 Репозиторій - сховище метаінформації (тобто описової інформації) про додатки, компоненти, сховища (рос.-хранилища) даних, бази даних і т.д., які розробляються,. Містить також, моделі процесів, що діються у системі,відмітити, що вперше програмний продукт Microsoft Repository, заснований на технологіях СОМ почав розповсюджуватися у складі Microsoft Visual Basic 5.0. До 2000 року було продано більш 700 000 його копій і більш 65-и компаній розробили додатки, які використовували Microsoft Repository (рис. 7.14).

Рисунок 7.14. Модель уявлення репозиторія корпорації Microsoft

Oracle розширила рамки UML для моделювання бізнес-моделей у базах даних. Загальний список співвиконавців вийшов достатньо чисельним (рос.-обширным), так як кожна компанія у роботі вирішувала свої конкретні задачі, але погоджуючи їх з загальним напрямком робіт. З врахуванням зусиль всіх офіційних учасників у січні 1997 p. OMG затвердив варіант UML 1.0, а після розгляду і урахування відгуків представників громадськості і UML 1.1.

Страницы:
1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30  31  32  33  34  35  36  37  38  39  40  41  42  43  44  45  46  47  48  49  50  51  52  53  54  55  56  57  58  59  60  61  62  63  64  65  66  67  68  69  70  71  72  73  74  75  76  77  78  79  80  81  82  83 


Похожие статьи

Б С Бусигін - Прикладна інформатика