Складність програмного забезпечення як наслідок складності систем

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

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

Причини складності за Г. Бучем:

— складність предметної області розробки ПЗ;

— складність управління процесом розробки ПЗ;

— необхідність забезпечення достатньої гнучкості ПЗ;

— незадовільні способи опису великих дискретних систем

Узгодженість

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

Здатність до змін:

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

Інноваційність процесів розробки ПЗ:

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

Інновації – завжди ризик

Незримість

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

4. Механізм боротьби зі складністю на основі об’єктно-орієнтованої парадигми. (хз что тут надо =\)

Об’єктно-орієнтована парадигма:

— ОО-аналіз – це методологія, за допомогою якої вимоги до системи сприймаються з точки зору класів і об’єктів, виявлених в предметній області

— ОО-проектування – це методологія проектування, що поєднує в собі процес об’єктної декомпозиції та прийоми представлення логічної та фізичної, а також статичної та динамічної моделей системи, яка проектується.

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

— Послідовність виконання проекту: ОО-аналіз -> ОО-проектування -> ОО-програмування

—

Визначення об'єктно-орієнтованого програмування:

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

— Об'єкт - Окремий екземпляр класу. Сукупність значень атрибутів окремого об'єкта називається станом.

— Метод - Можливості об'єкта.

— Обмін повідомленнями - Передача даних від одного процеса іншому, або надсилання викликів методів.

ПРИНЦИПЫ:

— Успадкування - Клас може мати «підкласи», спеціалізовані, розширені версії надкласу. Можуть навіть утворюватись цілі дерева успадкування.

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

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

— Поліморфізм - означає залежність поведінки від класу, в якому ця поведінка викликається, тобто, два або більше класів можуть реагувати по різному на однакові повідомлення.

5. Класифікація прецедентів.

— Прецеденти високого рівня – загальні визначення без деталізації

— Розгорнуті прецеденти – більш детальний опис, ніж прецеденти високого рівня, призначені для поглибленого розуміння вимог і процесів, що відбуваються. Як правило, оформлюються у вигляді діалогу користувача і системи

ТАКЖЕ:

— Головні прецеденти (primary use cases) – загальні процеси, наприклад, купівля товару

— Другорядні прецеденти (secondary use cases) – менш значні чи більш рідкі процеси, наприклад, запит на асортимент нових товарів

— Додаткові прецеденти (optional use cases) – процеси, що можуть бути не реалізовані у системі

И ЕЩЕ

Ідеальні

— розгорнуті прецеденти, що відображають загальну сутність процесів без деталізації їх реалізації.

— прецеденти високого рівня завжди ідеальні

Реальні

— конкретно описують процес в термінах реальних проектних рішень, на основі конкретних технологій введення/виведення інформації та ін.

6. Визначення прецедентів за цілями користувачів.

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

Актор має цілі.

Поиск по сайту: