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

Охарактеризуйте основні етапи процесу розробки програмного забезпечення (від виникнення ідеї розробки до прийняття рішення про виведення з експлуатації). Які програмні системи призначені для автоматизації процесу розробки програмного забезпечення на різних етапах?

Основні етапи процесу розробки програмного забезпечення:

1) Виникнення і дослідження ідеї-це класичний процес має наступні дії: виникнення та первинне дослідження ідеї; детальне дослідження ідеї, вироблення концепції, постановка задачі; експертиза ідеї фахівцями, прийняття рішення про початок процесу планування. Тут використовують пошукові інформаційні системи (google, yandex...), системи пошуку рішень.

2) Управління - цей процес триватиме майже весь життєвий цикл програмного продукту, одним з найважливіших дій управління є планування, яке починається слідом за прийняттям рішення, про те, що проект потрібно реалізувати. Тут використовують 3 групи інструментів-системи управління проектами (Microsoft project, time line), організаційні засоби (електронна пошта, електронний календар...), засоби оцінки якості (metricate)

3) Аналіз вимог і проектування двох тісно пов'язаних процесу, вони виконують загальну задачу, результатом кіт має стати чітке уявлення про систему на основі якого буде створено програмний код. Аналіз вимог це процес життєвого циклу програми під час якого вимоги замовника уточнюються, формалізується і документуються. Проектування - це процес життєвого циклу програми під час кіт досліджуються її структура та взаємозв'язки елементів. Проектування, як правило, є ітераційний процесом. Проектування та аналіз вимог можуть різнитися різними способами декомпозиції систем-структурна декомпозиція (розглядає структуру системи в термінах ієрархії функцій та передачі інформації) і об'єктна декомпозиція (розглядає структуру об'єктів та зв'язків між ними, а також поведінка системи в термінах обміну повідомлень між об'єктами). Тут використовують при структурному підході (Erwin, Oracle Designer), при об'єктно-орієнтованому підході (Rational Rose...)

4) Програмування (реалізація). Тут використовують С #, c + +, Delphi, java

5) Тестування та налагодження. Тестування - це процес виконання програми з метою виявлення факту наявності помилок. Налагодження - це процес локалізації та усунення помилок. Тестування починається з розробки безлічі тестів і їх виконання на основі однієї з обраних методик. Після порівняння результатів з еталонними починається або діагностика проблеми або оцінка достатності повноти тестування. Тут використовують Prodelphi, rational purecoverage

6) Запровадження програми в дію - істотно залежить від того чи була ця розробка для конкретного замовника або вона є продуктом розрахованим на широкого користувача. Існує 3 основних способи доставки програми до користувача-індивідуальна доставка, коробкова доставка, доставка через Інтернет. Тут використовують Create install, InstallShild

7) Експлуатація та супровід. Під супроводом розуміють всі дії щодо підвищення надійності програмного продукту після завершення налагодження й розробку удосконалення версій. Основні класи задач вирішуються на етапі супроводу: адаптація, як правило модифікація функцій, вдосконалення, звичайно додавання нових функцій, корекція (або виправлення помилок), попередження проблем, які можуть виникнути в майбутньому. Тут використовують системи деінсталяції.

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

 

2. Структурний підхід до розробки програмного забезпечення. Низхідне та висхідне проектування та програмування. Використання заглушок.

Цей підхід полягає в декомпозиції задачі на функції або процеси (скласти звіт, додати ресурси...).

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

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

· опис вихідних даних та результатів (типи, формати, точність, спосіб передачі, обмеження); опис завдання, що реалізується програмою; спосіб звернення до програми;

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

II етап. Розробка внутрішніх структур даних. Більшість алгоритмів залежить від того, яким чином організовані дані, тому інтуїтивно зрозуміло, що починати проектування програми треба не з алгоритмів, а з розробки структур, необхідних для представлення вхідних, вихідних і промежут6чних даних. При цьому беруться до уваги багато факторів, наприклад, обмеження на розмір даних, необхідна точність, вимоги до швидкодії програми. Структури даних можуть бути статичним або динамічними.

III етап. Проектування (визначення загальної структури та взаємодії модулів). На цьому етапі застосовується технологія спадної проектування програми, основна ідея якого теоретично проста: розбиття задачі на під задачі меншої складності, які можна розглядати окремо. При цьому використовується метод покрокової деталізації. Дуже важливою на цьому етапі є специфікація інтерфейсів, тобто способів взаємодії під задач. Для кожної під задачі складається зовнішня специфікація, аналогічна наведеній вище. На цьому ж етапі вирішуються питання розбиття програми на модулі, головний критерій - мінімізація їх взаємодії. Одна задача може реалізовуватися за допомогою декількох модулів і навпаки, в одному модулі може вирішуватися кілька завдань. На більш низький рівень проектування переходять тільки після закінчення проектування верхнього рівня. Алгоритми записують в узагальненій формі - наприклад, словесної, у вигляді узагальнених блок-схем або іншими способами. На етапі проектування слід враховувати можливість майбутніх модифікацій програми і прагнути проектувати програму таким чином, щоб вносити зміни було можливо простіше. Процес проектування є ітераційний, оскільки в програмах реального розміру неможливо продумати всі деталі з першого разу.

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

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

 

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

Для забезпечення надійності не бажаний прямий доступ до полів об'єкта: читання та оновлення їх вмісту повинне здійснюватися за допомогою виклику відповідних методів. Це правило і є інкапсуляція.

У моделі об'єктів мови Object Pascal існує механізм доступу до частин об'єкта, що визначає області, де ними можна користуватися (області видимості). Поля і методи можуть ставитися до чотирьох груп (секціями), відмінним областями видимості. Методи і поля можуть бути загальними (секція public), особистими (секція private), захищеними (секція protected) та опублікованими (секція published), для створення OLE об'єктів (секція automized). Поля, властивості та методи секції public не мають обмежень на видимість. Вони доступні з інших функцій і методів об'єктів, як у даному модулі, так і у всіх інших, які посилаються на нього. Поля, властивості та методи, що знаходяться в секції private, доступні лише в методах класу та у функціях, що містяться в тому ж модулі, що і стосуються клас. Поля, властивості та методи секції protected також доступні тільки всередині модуля з описуваних класом. Але, вони доступні і в класах, що є нащадками даного класу, в тому числі і в інших модулях. Область видимості, що визначається четвертої директивою - pubLished, має особливе значення для інтерфейсу візуального проектування Delphi. У цій секції повинні бути зібрані ті властивості об'єкта, які буде видно не тільки під час виконання програми, але й з середовищі розробки.

Принцип успадкування означає, що якщо ви хочете створити новий клас, лише трохи відрізняється від старого, то абсолютно немає необхідності в переписування заново вже існуючих полів і методів. Ви розкажете, що новий классTNewObject = class (TOldObject); є нащадком або дочірнім класом старого класу TOldObject, званого предком або батьківським класом, і додати до нього нові поля, методи і властивості. Успадковані від класу-предка поля і методи доступні в дочірньому класі; якщо має місце збіг імен методів, то говорять, що вони перекриваються. Мова C + + допускає так зване множинне успадкування. У цьому випадку новий клас може успадковувати частину своїх елементів від одного батьківського класу, а частина - від іншого. Множинне успадкування створює відому проблему (в C + +), коли клас успадковується від декількох класів-посередників, які у свою чергу успадковуються від одного класу. Якщо метод загального предка був пере визначено в посередниках, невідомо, яку реалізацію методу повинен наслідувати загальний нащадок. Вирішується ця проблема шляхом відмови від множинного успадкування для класів і роздільною здатністю множинного спадкоємства для повністю абстрактних класів (т. н. Інтерфейсів) (C #, Delphi, Java). В Object Pascal поняття множинного наслідування відсутнє. Якщо ви хочете, щоб новий клас об'єднував властивості кількох, створити класи-предки один від іншого, або включити в один клас кілька полів, що відповідають іншим бажаних класами.

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

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

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

Абстрагування полягає у відділенні інтерфейсу від реалізації.

 

В чому полягає принцип поліморфізму? Як реалізується принцип поліморфізму в об’єктно-орієнтованих мовах програмування? Обґрунтуйте доцільність використання віртуальних або динамічних методів. Як здійснити виклик з методів потомка перекритих (віртуалізованих) методів предка?

Метою поліморфізму є використання одного імені для задання загальних для класу дій. Виконання кожної конкретної дії визначатиметься типом даних. Наприклад для мови С, в якому поліморфізм підтримується недостатньо, знаходження абсолютної величини числа вимагає трьох різних функцій: abs (), labs() і fabs(). Ці функції підраховують і повертають абсолютну величину цілих, довгих цілих і чисел з плаваючою крапкою відповідно. У С++ кожна з цих функцій може бути названа abs (). Тип даних, який використовується при виклику функції, визначає, яка конкретна версія функції дійсно виконується. У С++ можна використовувати одне ім'я функції для безлічі різних дій. Це називається перевантаженням функцій (function overloading). У загальнішому сенсі, концепцією поліморфізму є ідея "один інтерфейс, безліч методів". Поліморфізм може застосовуватися також і до операторів. Фактично у всіх мовах програмування обмежено застосовується поліморфізм, наприклад, в арифметичних операторах. Так, в С, символ + використовується для складання цілих, довгих цілих, символьних змінних і чисел з плаваючою крапкою. В цьому випадку компілятор автоматично визначає, який тип арифметики потрібний. У С++ ви можете застосувати цю концепцію і до інших, заданим вами, типам даних. Такий тип поліморфізму називається перевантаженням операторів (operator overloading). Ключовим в розумінні поліморфізму є те, що він дозволяє вам маніпулювати об'єктами різної міри складності шляхом створення загального для них стандартного інтерфейсу для реалізації схожих дій. Приклад. Клас геометричних фігур (еліпс, багатокутник) може мати методи для геометрі-чеських трансформацій (зсув, поворот, масштабування). У об'єктно-орієнтованих мовах клас є типом даних. Поліморфізм реалізується за допомогою спадкоємства класів. Клас-нащадок успадковує сигнатури методів класу-батька, але реалізація цих методів може бути іншій, відповідній специфіці класу-нащадка. Це називається перевизначенням методу. Інші функції можуть працювати з об'єктом класу-батька, при цьому замість нього під час виконання підставлятиметься один з класів-нащадків. Це називається пізнім скріпленням. Залежно від того, які дії відбуваються при виклику, методи діляться на три групи. У першу групу віднесемо статичні методи, в другу - віртуальні (virtual) і динамічні (dynamic) і, нарешті, в третю - перенавантажувані (overload) методи. Методи першої групи повністю перекриваються в класах-нащадках при їх перевизначенні. При цьому можна повністю змінити оголошення методу. Методи другої групи при спадкоємстві повинні зберігати найменування і тип. Перевантажені методи доповнюють механізм спадкоємства можливістю використовувати потрібний варіант методу (власний або батьківський) залежно від умов вживання. Абстрактні методи не мають реалізації взагалі. Вони спеціально призначені для спадкоємства. Їх реалізація має бути визначена в класах-нащадках. Віртуальні методи – займають більше місця, але швидше обробляються. Динамічні – менше місця, але повільніше обробляються. Класові методи (class) – Класові методі можна віклікаті без створення екземпляру класу, а через посилання на клас. Хоча класові методі можна викликати також з екземпляра об'єкту, але реалізація класових методів не може посилатися на конкретне полі, або інший некласовій метод. На конструктор та на інші класові методі посилатися можна. Класові методі, зазвичай, модификують глобальні дані або відають інформацію про клас. Коли з класу-нащадку необхідно викликати одноімений метод предка, що був заміщеній (або перекритий) цим нащадком. Для цього використовується спеціальна директива inherited. Загальній опис використання такий: inherited < ім’я методу предка>.

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

В Pascal параметризованих функцій і класів немає. У С++ це родові функції і класи. Родова функція визначає базовий набір операцій, кіт будуть застосуються до різних типів даних. Родова функція оперує з тим типом даннях, який вона отримує як параметра. За допомогою цього механізму одна і та ж процедура може застосуються до самих різних типів даннях. Завдяки створенню родовий функції ми можемо не залежно від типа даннях визначити суть алгоритму. Після того, як це зроблено, компілятор автоматично генерує правильний код для фактично використовуваного при виконанні функції типа даних. По суті, при створенні родової функції ви створюєте функцію, котра може автоматично перевантажуватися сама. Родова функція створюється за допомогою ключового слова template. Воно призначене для створення шаблону, який описує те, що робитиме функція, при цьому компілятору залишається доповнити шаблон необхідними деталями. На додаток до родових функції визначені родові класи(класи-шаблони). При цьому створюється клас, в якому визначені всі необхідні алгоритми, а фактичні типи оброблюваних даних задаються як параметри пізніші, при створенні об'єктів цього класу. За допомогою родового класу можна створити клас, що реалізовує чергу, зв’язані списки т.д. для будь-яких типів даних. Компілятор автоматично генеруватиме правильного типа об'єкту на основі типа, заданого при створенні об'єкту. Бібліотека стандартних шаблонів (STL). Ядро STL образу ют 3 елементи: контейнери (об'єкти призначені для зберігання інших об'єктів), алгоритми і ітератори. Контейнери бувають різних типів. Наприклад в класі-контейнері vector (вектор) визначається динамічний масив. У класі тap – асоціативний список для зберігання пар ключ/значення, де з кожним ключем пов'язано лише одне значення. У класі stek – визначається стек. У разі, коли функція виконуватиме різні алгоритми, коли до неї на вхід подаватимуться змінні різних типів – використовуємо переобтяжені функції, якщо ж функція не дивлячись на те який тип змінної подається їй на вхід виконує один і той же алгоритм, то використовуємо функцію, що параметризується.

Ім’я класу

Поля

Методи

 

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

Абстракция выделяет существенные характеристики некоторого объекта, отличающие его от всех других видов объектов и, таким образом, четко определяет его концептуальные границы с точки зрения наблюдателя.

Абстрагирование концентрирует внимание на внешних особенностях объекта и позволяет отделить самые существенные особенности поведения от несущественных. Назвали такое разделение смысла и реализации барьером абстракции, который основывается на принципе минимизации связей, когда интерфейс объекта содержит только существенные аспекты поведения и ничего больше. Мы считаем полезным еще один дополнительный принцип, называемый принципом наименьшего удивления, согласно которому абстракция должна охватывать все поведение объекта, но не больше и не меньше, и не привносить сюрпризов или побочных эффектов, лежащих вне ее сферы применимости.

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

Мы стараемся строить абстракции сущности, так как они прямо соответствуют сущностям предметной области.

Центральной идеей абстракции является понятие инварианта. Инвариант - это некоторое логическое условие, значение которого (истина или ложь) должно сохраняться. Для каждой операции объекта можно задать предусловия (инварианты предполагаемые операцией) и постусловия (инварианты, которым удовлетворяет операция). Изменение инварианта нарушает контракт, связанный с абстракцией. В частности, если нарушено предусловие, то клиент не соблюдает свои обязательства и сервер не может выполнить свою задачу правильно. Если же нарушено постусловие, то свои обязательства нарушил сервер, и клиент не может более ему доверять. В случае нарушения какого-либо условия возбуждается исключительная ситуация. Как мы увидим далее, некоторые языки имеют средства для работы с исключительными ситуациями: объекты могут возбуждать исключения, чтобы запретить дальнейшую обработку и предупредить о проблеме другие объекты, которые в свою очередь могут принять на себя перехват исключения и справиться с проблемой..

Идея контрактного программирования приводит нас к разграничению внешнего облика, то есть интерфейса, и внутреннего устройства класса, реализации. Главное в интерфейсе - объявление операций, поддерживаемых экземплярами класса. К нему можно добавить объявления других классов, переменных, констант и исключительных ситуаций, уточняющих абстракцию, которую класс должен выражать. Напротив, реализация класса никому, кроме него самого, не интересна. По большей части реализация состоит в определении операций, объявленных в интерфейсе класса.

Мы можем разделить интерфейс класса на три части:

· открытую (public) - видимую всем клиентам;

· защищенную (protected) - видимую самому классу, его подклассам и друзьям (friends);

· закрытую (private) - видимую только самому классу и его друзьям.

Квантор видимости может принимать одно из трех возможных значений и, соответственно, отображается при помощи специальных символов:

· Символ "+" обозначает атрибут с областью видимости типа общедоступный (public). Атрибут с этой областью видимости доступен или виден из любого другого класса пакета, в котором определена диаграмма.

· Символ "#" обозначает атрибут с областью видимости типа защищенный (protected). Атрибут с этой областью видимости недоступен или невиден для всех классов, за исключением подклассов данного класса.

· И, наконец, знак "-" обозначает атрибут с областью видимости типа закрытый (private). Атрибут с этой областью видимости недоступен или невиден для всех классов без исключения.

Охарактеризуйте поняття раннього та пізнього зв’язування методів. Для яких методів об’єкта застосовується раннє, а для яких пізнє зв’язування? Чим відрізняється виклик перекритих методів від виклику віртуальних(динамічних) методів? Чим відрізняється виклик віртуальних та динамічних методів між собою?

Раннє зв’язування виконується для статичних методів, пізнє зв’язування – для заміщуваних. Раннє зв’язування -компілятор визначає адресу і передає її об’єкту. Таким чином зв'язок об’єктів зі своїм статичним методом відбувається на етапі компіляції. Пізнє зв’язування – настроювання об’єкта на заміщуваний метод класу відб-ся під час ініціалізації об’єкта. Коли компілятор зустрічає звернення до заміщуваного метода, він підставляє замість звернення до конкретної адреси код, який звертається до спец. таблиці (VMT, DMT), звідки потім витягається потрібна адреса. Отже, для заміщуваних методів звязування відбувається під час виконання (ініціалізації об’єкта - пізнє зв’язування.

Різниця між заміщ. І статичн. Методами:

1)при описі у класі-предку ЗМ описуються директивою virtual або dynamic. У класі-нащадку – override.

2)ЗМ дають можливість об’єктам-батькам викликати методи об’єктів-нащадків.

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

Призначення та правила побудови концептуальної моделі предметної області UML-нотації. Що таке сутність? Правила вибору сутностей. Види зв’язків між сутностями, назви зв’язків, потужність зв’язків. Що таке атрибути сутностей?

 ООА связан с созданием спецификации предметной области проблемы, с определением требований с точки зрения классификации объектов, а также с формированием терминов, используемых в предметной области. Декомпозиция предметной области задачи состоит в идентификации понятий (сущностей), атрибутов и соотношений из предметной области, имеющих важное значение для решения задачи. Результат анализа отображается с помощью концептуальной модели, которая иллюстрируется с помощью диаграмм понятий (объектов).

Концептуальная модель – это не описание программных компонентов. Это представление понятия в терминах предметной области.

Сущность – нечто, описанное набором данных.

Не рекомендуется считать сущностью то, что описывается значением – числом или строкой.

Нельзя в концептуальную модель вносить 2 функциональных использования одной и той же сущности (не вносится список должников так как это тот же список студентов);

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

Виды связей:

- part of (агрегация) – «целое» ß «часть» («самолет» ß «крыло» - без крыла это уже не самолет);

- is a (наследование) - «предок» ß «потомок»;

- ассоциация – определяет степень отношения, воздействия («интерьер» ß «диван» - без дивана это все еще интерьер)

Мощность отношений:

- 1..1

- 1.. n

- 1..0

- n.. n

На концептуальной модели для каждой сущности указываются ее атрибуты – данные, которыми она описывается. Атрибут – это абстрактное свойство объекта. В концептуальную модель включаются те атрибуты, для которых определены соответствующие требования (например, прецеденты) или для которых предполагается, что необходимо хранить определенную информацию. Например, в товарном чеке указывается время и дата. Следовательно, для сущности «Продажа» (Sale) требуются атрибуты «Дата» (Date) и «Время» (Time).

 

Які інструментальні програмні засоби використовуються для розробки та подання результатів аналізу та проектування програмного забезпечення? Які з цих засобів надають можливості кодогенерації та реінженірінга програмного забезпечення?

 Для анализа требований и проектирования на основе структурной методологии могут быть применены следующие системы:

o Silverrun ModelSphere (компании magma solutions GmbH) – поддерживает методы DATARUN, Гейна-Сарсона, Йордона, Мартина и др.;

o Oracle Designer (компании Oracle) – поддерживает CASE-Method Бфркера.

o CASE.Аналитик (компании Эйтекс) – поддерживает подход Гейна-Сарсона. Ситема работает с иерархией диаграмм, последоватьльно детализирующих модель.

В состав системы CASE.Аналитик входят:

- база данных проекта;

- графические редакторы потоковых диаграмм и структурограмм;

- средства ввода экранных и печатных форм;

- документатор;

- верификатор, позволяющий вести автоматический контроль выполнения формальный правил построения модели при вводе и редактировании.

Системы для анализа требований и проектирования на основе объектно-ориентированной методологии:

- Rational Rose;

- Together Control Center.

Основные достоинства и возможности системы Rational Rose:

- Система прошла достаточно долгий путь развития и совершенствования. Она поддерживает язык UML и ряд ранних языковых нотаций;

- Система реализована на обеих наиболее распространенных операционных системах (Unix, Windows);

- Система имеет 3 основные модификации:

- Enterprise – с возможностью генерации кода на языках Visual C++, Visual BASIC, Java, COBRA IDL.

- Professional – возможность генерации кода на одном из перечисленных языков;

- Modeler – без языковой поддержки.

- система поддерживает восстановление спецификации из кода;

- система поддерживает генерацию проектной документации.

 

Призначення та правила побудови діаграми класів UML. Як позначаються класи, поля(атрибути) та методи(операції) класів? Як на діаграмі класів позначаються зв’язки між класами(типи зв’язків з прикладами, кратність зв’язку). У яких випадках на діаграмі класів позначаються атрибути зв’язку?

Диаграмма классов иллюстрирует спецификации программных классов и интерфейсов в приложении.

Обычно на такую диаграмму выносится следующая информация:

1. Классы, отношения и атрибуты;

2. Интерфейсы со своими операциями и константами;

3. Методы;

4. Информация о типах атрибутов;

5. Способы навигации;

6. Зависимости.

В отличие от концептуальной модели диаграммы классов отображают определения программных сущностей, а не понятия предметной области.

Класс в языке UML является абстрактным описанием или представлением свойств множества объектов, которые обладают одинаковой структурой, поведением и отношениями с объектами из других классов. Графически класс в нотации языка UML изображается в виде прямоугольника, который дополнительно может быть разделен горизонтальными линиями на разделы или секции. В этих секциях могут указываться имя класса, атрибуты, методы.

Атрибут класса служит для представления отдельного свойства или признака, который является общим для всех объектов данного класса. Атрибуты класса записываются во второй сверху секции прямоугольника класса, поэтому эту секцию часто называют секцией атрибутов.

Метод (операция) класса – это некоторый сервис, который предоставляет каждый экземпляр или объект класса по требованию своих клиентов (других объектов, в том числе и экземпляров данного класса). Операция класса записывается в третьей сверху секции прямоугольника класса, поэтому эту секцию называют секцией операций.

Базовыми отношениями или взаимосвязями, которые могут изображаться на диаграммах классов, являются:

- отношение ассоциации (association) – соответствует наличию произвольной отношения или взаимосвязи между классами;

- отношение обобщения (generalization) – отношение между более общим элементом (родительским или предком) и более частным или специальным элементом (дочерним или потомком);

- отношение агрегации (aggregation) – имеет месту между несколькими классами, если один из классов представляет собой некоторую сущность, которая включает в себя в качестве составных частей другие сущности.

- отношение композиции (composition) – является частным случаем отношения агрегации. Это отношение служит для спецификации более сильной формы отношения «часть-целое», при которой составляющие части тесно взаимосвязаны с целым (части не могут выступать в отрыве от целого);

- отношение зависимости (dependency) – указывает некоторое семантическое отношение между двумя элементами модели, которое не является отношением ассоциации или обобщения.

 

Різновид діаграм взаємодії. Що спільного і в чому різниця в UML діаграмах послідовності та кооперації? Як на цих діаграмах позначаються об’єкти та класи; передача повідомлень між класами, розгалужені та циклічні повідомлення?

Диаграмма взаимодействий (Interaction diagram) описывает взаимодействия, состоящие из множества объектов и отношений между ними, включая сообщения, которыми они обмениваются.  

Диаграммой последовательностей (Sequence diagram) называется диаграмма взаимодействий, акцентирующая внимание на временной упорядоченности сообщений.

Графически такая диаграмма представляет собой таблицу, объекты в которой располагаются вдоль оси X, а сообщения в порядке возрастания времени - вдоль оси Y.

Диаграммы последовательностей характеризуются двумя особенностями, отличающими их от диаграмм кооперации.

Во-первых, на них показана линия жизни объекта. Это вертикальная пунктирная линия, отражающая существование объекта во времени. Большая часть объектов, представленных на диаграмме взаимодействий, существует на протяжении всего взаимодействия, поэтому их изображают в верхней части диаграммы, а их линии жизни прорисованы сверху донизу. Объекты могут создаваться и во время взаимодействий. Линии жизни таких объектов начинаются с получения сообщения со стереотипом create. Объекты могут также уничтожаться во время взаимодействий; в таком случае их линии жизни заканчиваются получением сообщения со стереотипом destroy, а в качестве визуального образа используется большая буква X, обозначающая конец жизни объекта.

Диаграммой кооперации (Collaboration diagram) называется диаграмма взаимодействий, основное внимание в которой уделяется структурной организации объектов, принимающих и