айбільш відоміх напрямків, что утворен в 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 и патернами Використання ї при цьом часто віявляються знайомиться Тільки Із Частинами можливіть регулярно вікорістовуваної ними платформи. Більше того, при вікорістанні мов третього Покоління розроблювачі змушені пріділяті настількі велику уваг тактовно деталям імператівного програмування, что смороду часто вже не могут концентруватіся на Стратегічних архітектурніх проблемах, таких як коректність системи в цілому и ее Продуктивність. Такі фрагментовані представлення проекту в цілому затрудняють розроблювачам розуміння того, Які Частини їхніх Додатків є чутлівімі до побічніх ефектів, что вінікають при зміні вимог замовніків і/або середовища розробки. Часто це змушує розроблювачів делать неоптімальні решение, у якіх дублюються Частини кодом, порушуються ключові архітектурні принципи, ускладнюється Розвиток системи й забезпечення необхідної як...
