конспект лекцій (ТСПП). Конспект лекцій з дисципліни 07 технологія створення програмних продуктів напряму 050101 Компютерні науки
 Скачать 14.87 Mb.
|
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) - підтримує ітерації поетапної моделі, але особлива увага приділяється початковим етапам проектування : аналізу вимог, проектуванню специфікацій, попередньому проектуванню і детальному проектуванню. Кожен виток спіралі відповідає поетапній моделі створення фрагмента або версії ПО, уточнюються цілі і вимоги до програмного забезпечення, оцінюється якість розробленого фрагмента або версії і плануються роботи наступної стадії розробки (витка). Таким чином, поглиблюються і конкретизуються усі деталі проектованого ПО, в результаті виходить продукт, який задовольняє усім вимогам замовника. |