Главная страница

конспект лекцій (ТСПП). Конспект лекцій з дисципліни 07 технологія створення програмних продуктів напряму 050101 Компютерні науки


Скачать 14.87 Mb.
НазваниеКонспект лекцій з дисципліни 07 технологія створення програмних продуктів напряму 050101 Компютерні науки
Анкорконспект лекцій (ТСПП).docx
Дата15.12.2017
Размер14.87 Mb.
Формат файлаdocx
Имя файлаконспект лекцій (ТСПП).docx
ТипКонспект
#11579
страница18 из 62
1   ...   14   15   16   17   18   19   20   21   ...   62

4.5. Об'єктно-орієнтоване програмування.


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

Основними обов’язковими елементами об’єктної моделі є:

  • абстрагування;

  • інкапсуляція;

  • модульність;

  • ієрархія.

Додатковими (необов’язковими) є:

♦ типізація;

♦ паралелізм;

♦ стійкість.

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

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

Модульність — це можливість декомпозиції системи на модулі, не пов’язані між собою.

Ієрархія — це впорядкована за рівнями система абстракцій. Ієрархія за номенклатурою — це структура класів; ієрархія за складом — це структура об’єктів.

Типізація — це властивість об’єктів перебувати в активному чи пасивному стані і розрізняти активні й пасивні об’єкти між собою.

Стійкість — це існування об’єкта у часі і просторі незалежно від процесу, який його створив.

4.6. Уніфікована мова моделювання. Мови і платформи розробки.


UML (англ. Unified Modeling Language) — уніфікована мова об'єктно-орієнтованого моделювання, використовується у парадигмі об'єктно-орієнтованого програмування. Є невід'ємною частиною уніфікованого процесу розробки програмного забезпечення.

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

Діаграми дають можливість представити систему (як ділову, так і програмну) у такому вигляді, щоб її можна було легко перевести в програмний код.

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

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

Практично усі CASE-засоби (програми автоматизації процесу аналізу і проектування) мають підтримку UML. Моделі розроблені в UML, дозволяють значно спростити процес кодування і направити зусилля програмістів безпосередньо на реалізацію системи.

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

4.7. Засоби розробки програмного забезпечення. Оптимальний порядок вивчення ТОП.


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

Існує декілька моделей життєвого циклу (ЖЦ), кожна з яких визначає різну методологію створення систем, проте усі без виключення моделі ЖЦ включають п'ять етапів і зв'язків між ними з детальним описом дій, моделей і результатів кожного етапу. Приведемо назви і короткий зміст кожного етапу відповідно до ГОСТ 19.102-77.

1. Технічне завдання:

  • постановка завдання;

  • вибір критеріїв ефективності;

  • проведення попередніх науково-дослідних робіт (НДР);

  • розробка ТЗ.

2. Ескізний проект:

  • структура вхідних і вихідних даних;

  • уточнення методів рішення;

  • загальний алгоритм;

  • розробка документації ескізного проекту.

3. Технічний проект:

  • уточнення структури вхідних і вихідних даних;

  • розробка алгоритмів;

  • форми даних;

  • семантика і синтаксис мови;

  • структура програми;

  • конфігурація технічних засобів;

  • план робіт.

4. Робочий проект:

  • програмування і відладка;

  • розробка документів;

  • підготовка і проведення випробувань;

  • коригування програми і документів за підсумками випробувань.

5. Впровадження:

  • передача програми і документів для супроводу;

  • оформлення акту;

  • передача до Фонду алгоритмів і програм (ФАП).

Історично в ході розвитку теорії проектування програмного забезпечення і у міру його ускладнення затвердилися чотири основні моделі ЖЦ.

Першою за часом появи і найпоширенішою стала каскадна модель (мал. 2.5).



Мал. 2.5. Каскадна модель життєвого циклу ПО

Каскадна модель характеризується наступними основними особливостями:

  • послідовним виконанням тих, що входять до її складу эта-пов;

  • закінченням кожного попереднього етапу до початку того, що потім-дме;

  • відсутністю тимчасового перекриття етапів (наступний етап не почнеться, поки не завершиться попередній);

  • відсутністю (чи певним обмеженням) повернення до попередніх етапів;

наявністю результату тільки у кінці розробки.

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

Наступною стадією розвитку теорії проектування ПО стала ітераційна модель ЖЦ, або так звана поетапна модель з проміжним контролем (мал. 2.6). Основною її особливістю є наявність зворотних зв'язків між етапами, внаслідок цього з'являється можливість проведення перевірок і коригувань проектованою ІС на кожній стадії розробки. В результаті трудомісткість відладки в порівнянні з каскадною моделлю істотно знижується. Итерационность моделі проявляється в обробці помилок, виявлених проміжним контролем. Якщо на якому-небудь етапі в ході проміжної перевірки виявлена помилка, допущена на більше ранній стадії розробки, необхідно повторити увесь цикл робіт цієї стадії. При цьому аналізуються причини помилки і коригуються у разі потреби початкові дані етапу або його зміст (послідовність дій).



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



Третя модель ЖЦ ПО - спіральна (spiral) модель (мал. 2.7) - підтримує ітерації поетапної моделі, але особлива увага приділяється початковим етапам проектування : аналізу вимог, проектуванню специфікацій, попередньому проектуванню і детальному проектуванню. Кожен виток спіралі відповідає поетапній моделі створення фрагмента або версії ПО, уточнюються цілі і вимоги до програмного забезпечення, оцінюється якість розробленого фрагмента або версії і плануються роботи наступної стадії розробки (витка). Таким чином, поглиблюються і конкретизуються усі деталі проектованого ПО, в результаті виходить продукт, який задовольняє усім вимогам замовника.

1   ...   14   15   16   17   18   19   20   21   ...   62


написать администратору сайта