4. Керована моделями інженерія. Огляд
Останні п'ятдесят років дослідники й розроблювачі програмного забезпечення створюють абстракції, що допомагають їм програмувати в термінах цілей свого проекту, а не використовуваного комп'ютерного середовища, і захищаючі їх від складностей цього середовища. Із самого початку ці абстракції включали технології мов програмування й операційних систем. Наприклад, ранні мови програмування (мови асемблера й Fortran) захищали розроблювачів від складностей програмування в машинних кодах. [10.1]
Аналогічно, ранні операційні системи захищали їх від складностей програмування прямо на рівні апаратури. Хоча ці ранні мови й платформи підвищували рівень абстракції, вони явно були "орієнтованими на обчислення". Зокрема, вони забезпечували абстракції простору рішень (тобто області самих комп'ютерних технологій), а не абстракції, що дозволяють звістки розробку в термінах прикладної області. Згодом уживали численні спроби подальшого підвищення рівня абстракції. [14]
Одним з найбільш відомих напрямків, що утворилися в 1980-е рр., є інженерія програмного забезпечення з комп'ютерною підтримкою (Computer-Aided Software Engineering, CASE), що забезпечує методи й засоби розробки програмного забезпечення, що дозволяють розроблювачам виражати свої конструкції з використання графічних програмних засобів загального призначення, різного виду діаграм. Однієї із цілей CASE-Засобів було забезпечення більше ретельного аналізу графічних програм за рахунок їхньої меншої складності, чим у програм, представлених на традиційних мовах програмування (наприклад, у графічних програмах неможливі помилки, що приводять до ушкодження пам'яті).
Іншою проблемою підходу CASE була його нездатність масштабуватися до складних, виробничих систем у широкому діапазоні прикладних областей. Загалом кажучи, CASE-Засобу не підтримували паралельну розробку; на їхній основі можна було розробляти програми поодинці або групою, члени якої по черзі зверталися до файлів, використовуваним цими засобами. [10/1]
У результаті в 1990-е рр. підхід CASE робив порівняно невеликий вплив на розробку комерційного програмного забезпечення, фокусуючись на декількох прикладних областях, наприклад, на обробці викликів у телекомунікаційних системах, де добре підходили подання у вигляді кінцевих автоматів. Навіть там, де CASE-Засоби застосовувалися на практиці, звичайно використовувалася тільки їхня частина, що дозволяє розроблювачам малювати діаграми програмних архитектур і документувати свої рішення, на основі чого програмісти потім вручну робили й розвивали реалізації. Однак, оскільки був відсутній прямий зв'язок між діаграмами й реалізаціями, розроблювачі не прагнули до великої точності діаграм, оскільки вони рідко синхронізувалися із кодом на подальших стадіях проектів.
В останні двадцять років досягнення в області мов програмування й платформ привели до підвищення рівня абстракцій, доступних для розроблювачів, зм'якшивши один з недоліків підходу CASE. Наприклад, сьогодні розроблювачі звичайно використовують більше виразні об’єктно-орієнтовані мови (зокрема, C++, Java і C#), а не Fortran або C. Повторно використовувані бібліотеки класів і платформи підтримки додатків мінімізують потребу у винаході загальних і прикладних сервісів - транзакцій, відмовостійкості, оповіщення про події, безпеку, розподіленого керування ресурсами й т.д. Все це дозволяє розроблювачам краще захиститися від складності, пов'язаної зі створенням додатків на основі традиційних технологій.[14]
Незважаючи на ці досягнення, залишається кілька неприємних проблем. У центрі цих проблем лежить складність платформ, що росте швидше здатності мов загального призначення маскувати її. Наприклад, популярні платформи проміжного програмного забезпечення J2EE, .NET і CORBA містять тисячі класів і методів з багатьма складними залежностями й тонкими побічними ефектами, що вимагає значних зусиль при програмуванні й ретельному настроюванні.
Родинна проблема полягає в тому, що код більшості додатків і платформ як і раніше пишеться на мовах третього покоління, для чого потрібно багато часу й зусиль, особливо для виконання інтеграційних дій - розгортання, конфігурування й підтримка якості системи. Наприклад, на Java або C# важко написати код, коректно й оптимально розгортає великомасштабної розподіленої системи із сотнями тисяч взаємозалежних компонентів.
Ситуацію не рятує навіть використання описів розгортання мовою XML, використовуваних у компонентних і сервіс-орієнтованих платформах проміжного програмного забезпечення, оскільки в цьому випадку є семантичний розрив між метою розробки й вираженням цієї мети в тисячах рядків вручну зробленого XML, синтаксис якого не має відносини ні до семантики прикладної області, ні до мети розробки. Через наявність цих проблем індустрія програмного забезпечення наближається до гранично припустимої складності.
У той же час платформні технології нового покоління, наприклад, Web-Сервіси й архітектури продуктових ліній (product-line architecture) стають настільки складними, що роками опановують платформними API і паттернами використання й при цьому часто виявляються знайомими тільки із частиною можливостей регулярно використовуваної ними платформи. Більше того, при використанні мов третього покоління розроблювачі змушені приділяти настільки велику увагу тактичним деталям імперативного програмування, що вони часто не можуть концентруватися на стратегічних архітектурних проблемах, таких як коректність системи в цілому і її продуктивність. Такі фрагментовані представлення проекту в цілому затрудняють розроблювачам розуміння того, які частини їхніх додатків є чутливими до побічних ефектів, що виникають при зміні вимог замовників і/або середовища розробки. Часто це змушує розроблювачів робити неоптимальні рішення, у яких дублюються частини коду, порушуються ключові архітектурні принципи, ускладнюється розвиток системи й забезпечення необхідної якості.
Багатообіцяючим підходом, спрямованим на рішення цих проблем, є розробка технологій інженерії, керованої моделями, (Model-Driven Engineering, MDE). При використанні MDE розробка ведеться на предметно-предметно-орієнтованих мовах моделювання (Domain-Specific Modeling Language, DSML), у системах типів яких формалізується структура, поводження й вимоги додатка усередині відповідної предметної області. DSML описуються з використанням метамоделей, у яких визначаються зв'язки між поняттями предметної області й точно специфується основна семантика й обмеження, асоційовані із цими поняттями. [10.1]
... І Моделювання предметної області є одним з найбільш важливих етапів робіт при проектуванні програмних систем масштабу підприємства. У даній курсовій роботі демонструється можливий підхід до моделювання системи обліку слухачів на курсах з використанням уніфікованої нотації, заснований на застосуванні Уніфікованої Мови Моделювання (Unified Modeling Language) (UML), і гармонійно сполучить у собі ...
... реінжиніринг модулів і бібліотек форматів EXE, DLL, TLB, OCX, підтримку CORBA, IDL, ADO, COM, Java. Висновки Результатом виконання курсового проекту є змодельована система бухгалтерського обліку. Моделювання даної системи дозволяє нам наочно продемонструвати бажану структуру і поведінку системи. Моделювання також необхідно для візуалізації і управління архітектурою системи. Моделі допомагають ...
... ГІС може бути дослідною, охоплювати територію певного регіону, базуватися переважно на векторних форматах просторових даних та мати доступ до корпоративної мережі. 1.3 Геоінформаційні системи в екології Становлення екологічного управління і регулювання екологічних процесів вимагає серйозної технічної підтримки і використання сучасних технологій для вирішення задач різного плану і різного ...
... між усіма парами вершин); • алгоритм Йена (перебування k-оптимальних маршрутів між двома вершинами). Зазначені алгоритми легко виконуються при малій кількості вершин у графі. При збільшенні їх кількості завдання пошуку найкоротшого шляху ускладнюється. Тут на допомогу приходить сучасна техніка. Комп'ютерні засоби та інформаційні технології підвищили можливості такого всеосяжного методу ...
0 комментариев