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