Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Документація.doc
Скачиваний:
12
Добавлен:
23.02.2016
Размер:
1.27 Mб
Скачать
  1. Курсовий реферат

Зміст

I. Концепція………………………………………………………………..……49

1. Складність....................................................................................................49

2. Об'єктна модель ………….……………………………………….............51

3. Класи і об'єкти …………………………………………………….……...54

ІІ. Метод…………………………………………………………………............57

1. Система позначень………………………………………………………..57

2.Процес……………………………………………………….……………..62

3. Практичні питання………………………………………………………..62

Концепція

Глава 1 Складність

Складність викликається чотирма основними причинами:

1. Складністю реальної предметної області, з якої виходить замовлення на розробку.

2. Трудністю управління процесом розробки.

3. Необхідністю забезпечити достатню гнучкість програми.

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

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

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

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

П'ять ознак складної системи:

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

2. Вибір, які компоненти в даній системі вважаються елементарними, довільний і у великій мірі залишається на розсуд дослідника.

3. Внутрішньокомпонентний зв'язок звичайно сильніше, ніж зв'язок між компонентами. Ця обставина дозволяє відокремлювати «високочастотні» взаємодії всередині компонентів від «низькочастотної» динаміки взаємодії між компонентами.

4. Ієрархічні системи зазвичай складаються з небагатьох типів підсистем, по-різному комбінованих і організованих.

5. Будь-яка працююча складна система є результатом розвитку роботи більш простої системи ... Складна система, спроектована «з нуля», ніколи не запрацює. Слід починати з працюючої простої системи.

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

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

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

  • метод структурного проектування зверху вниз;

  • метод потоків даних;

  • об'єктно-орієнтоване проектування.

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

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

Об'єктно-орієнтоване проектування (object-oriented design) - в основі OOD лежить уявлення про те, що програмну систему необхідно проектувати як сукупність взаємодіючих один з одним об'єктів, розглядаючи кожен об'єкт як екземпляр певного класу, причому класи утворюють ієрархію.

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

Про проектування складних систем

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

1. Задовольняє заданим функціональним специфікаціям.

2. Узгоджена з обмеженнями, що накладаються обладнанням.

3. Задовольняє явним і неявним вимогам за експлуатаційними якостями і ресурс поживанню.

4. Задовольняє явним і неявним критеріям дизайну продукту.

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

Елементи програмного проектування. Було розроблено десятки різних методів, які можна класифікувати за трьома категоріями:

 Умовні позначення - мова для опису кожної моделі.

2. Процес - правила проектування моделі.

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

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

1. Динамічна. 2. Статично. 3. Логічна. 4. Фізична.