Докладніше

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

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

26. Діаграма кооперації. Кооперація. Структурні елементи. Рівні кооперації.

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

Кооперація може бути представлена ​​на двох рівнях:

На рівні специфікації - показує ролі класифікаторів і ролі асоціацій в розглянутому взаємодії.
На рівні прикладів - вказує екземпляри і зв'язку, що утворюють окремі ролі в кооперації.

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

Діаграма кооперації рівня прикладів представляється сукупністю об'єктів (екземпляри класів) і зв'язків (примірники асоціацій). При цьому зв'язки доповнюються стрілками повідомлень. На даному рівні показуються тільки релевантні об'єкти, т. е. мають безпосереднє відношення до реалізації операції або класифікатора.

27. Архітектура програмного забезпечення (англ. software architecture) — це структура програми або обчислювальної системи, яка містить програмні компоненти, видимі зовні властивості цих компонентів, а також відносини між ними. Цей термін також відноситься до документування архітектури програмного забезпечення. Документування архітектури ПЗ спрощує процес комунікації між зацікавленими особами (англ. stakeholders), дозволяє зафіксувати прийняті на ранніх етапах проектування рішення про високорівневий дизайн системи і дозволяє використовувати компоненти(рос.)укр. цього дизайну і шаблони повторно в інших проектах.

Стандартизований підхід Тривалий час в Україні та СРСР розроблення програмних систем виконувалась на основі стандарту ГОСТ 34.601–90[2], що регламентує стадії й етапи процесу розробки ПС.

Об’єктний підхід. Проектування системи може здійснюватися на основі об'єкто-орієнтованого моделювання ПрО методом UML, який дозволяє враховувати аспекти, властиві діючим особам (акторам) системи, створювати сценарії виконання системи тощо[3].

Загальносистемний підхід Один зі шляхів архітектурного проектування — традиційний неформальний підхід до визначення архітектури системи, її компонентів, способів їхнього подання й об’єднання в систему, який можна назвати загальносистемним. Фактично архітектура, що створюється згідно з таким підходом, є чотирирівневою і містить у собі: Перший рівень — системні компоненти. Вони здійснюють взаємодію з периферійними пристроями комп’ютерів (принтери, клавіатура, сканери, маніпулятори і т.п.), використовуються при побудові операційних систем. Другий рівень — загальносистемні компоненти. Вони забезпечують взаємодію з універсальними сервісними системами середовища роботи прикладної системи, такими як операційні системи, СКБД, системи баз знань, системи керування мережами і т.п. Третій рівень — специфічні компоненти певної прикладної області, що входять до складу компонентів програмної системи і призначені для розв’язання задач в межах означеної області (наприклад, бізнес-задачі). Четвертий рівень — прикладні програмні системи, що призначені для виконання завдань з обробки інформації, які постають перед окремими групами споживачів інформації з різних предметних областей (офісні системи, системи бухгалтерського обліку й ін.) і можуть використовувати компоненти нижчих рівнів. Компоненти кожного з виділених рівнів використовуються, як правило, на своєму або вищому рівні. Кожен рівень відбиває відповідний набір знань, умінь і навичок фахівців, що створюють або використовують компоненти. Цей набір визначає відповідний розподіл фахівців програмної інженерії на аналітиків, системщиків, прикладників, програмістів й ін. При проектуванні архітектури програмна система розглядається як композиція компонентів третього рівня з доступом до компонентів першого і другого рівнів. Тобто архітектурне проектування — це розроблення компонентів третього рівня, визначення вхідних і вихідних даних рівнів ієрархії компонентів і їхніх зв’язків. Результат проектування — архітектура й інфраструктура, що містять у собі набір об’єктів, з яких можна формувати деякий конкретний вид архітектурної схеми для конкретного середовища виконання системи, а також набір елементів керування і контролю. Проектування архітектури системи завершується створенням опису, в якому відображені зафіксовані проектні рішення, логічна і фізична структура системи, а також способи взаємодії об’єктів.

28. Об’єктний підхід

Проектування системи може здійснюватися на основі об'єкто-орієнтованого моделювання ПрО методом UML, який дозволяє враховувати аспекти, властиві діючим особам (акторам) системи, створювати сценарії виконання системи тощо[3]. Об’єктний стиль проектування — це декомпозиція майбутньої системи на окремі підсистеми (пакети), визначення функціональних і нефункціональних вимог і об’єктної моделі предметної області. Носіями інтересів, можливостей і дій в системі (або пакеті) є діючі особи — актори. Пакет може складатися з об’єктної моделі, варіантів використання, що визначають сценарії поведінки системи, склад об’єктів і методів їхньої взаємодії. Поведінка об’єктів відображується діаграмами, що задають послідовність взаємодії об’єктів (діаграми послідовностей, взаємодії), правилами переходу від стану до стану (діаграми станів), а також діаграмами кооперації, в яких діючі особи зображуються графічно. Об’єкти і відповідні їм діаграми варіантів використання задають загальну архітектурну схему системи, у рамках якої здійснюється реалізація структури і специфіки поведінки компонентів. Загальна концепція об’єктного проектування — це побудова всіх сценаріїв, екранних діаграм для керування ними і їх випробування в різних варіантах використання. На вибір варіантів використання впливають нефункціональні вимоги (наприклад, забезпечення конфіденційності, швидкодії й ін.). На основі моделі опису вимог і понять проводиться уточнення складу і змісту функцій системи, методів їхньої реалізації у вигляді сценаріїв і діаграм потоків даних, у яких відображається взаємодія об’єктів як обмін повідомленнями між елементами системи для передачі даних і одержання відповіді після виконання операцій. Моделі вимог визначають призначення і місце вимог у таких системах. Цьому сприяють розроблені національні, корпоративні і відомчі стандарти. Вони фіксують правила формування нефункціональних вимог, у яких відображаються відомості про взаємодію і захист даних у системі. При цьому поведінка об’єктів представляється діаграмами UML, вони можуть уточнюватися при перегляді моделей вимог і складу об’єктів системи. Перегляд починається з вимог і пошуку місць локалізації для внесення необхідних змін у модель. Зміни можуть стосуватися функціональних і нефункціональних вимог у зв’язку з уточненням замовником обмежень на структуру системи, використовувані ресурси й умови середовища її функціонування.

29 Загальносистемний підхід

Один зі шляхів архітектурного проектування — традиційний неформальний підхід до визначення архітектури системи, її компонентів, способів їхнього подання й об’єднання в систему, який можна назвати загальносистемним. Фактично архітектура, що створюється згідно з таким підходом, є чотирирівневою і містить у собі: Перший рівень — системні компоненти. Вони здійснюють взаємодію з периферійними пристроями комп’ютерів (принтери, клавіатура, сканери, маніпулятори і т.п.), використовуються при побудові операційних систем. Другий рівень — загальносистемні компоненти. Вони забезпечують взаємодію з універсальними сервісними системами середовища роботи прикладної системи, такими як операційні системи, СКБД, системи баз знань, системи керування мережами і т.п. Третій рівень — специфічні компоненти певної прикладної області, що входять до складу компонентів програмної системи і призначені для розв’язання задач в межах означеної області (наприклад, бізнес-задачі). Четвертий рівень — прикладні програмні системи, що призначені для виконання завдань з обробки інформації, які постають перед окремими групами споживачів інформації з різних предметних областей (офісні системи, системи бухгалтерського обліку й ін.) і можуть використовувати компоненти нижчих рівнів. Компоненти кожного з виділених рівнів використовуються, як правило, на своєму або вищому рівні. Кожен рівень відбиває відповідний набір знань, умінь і навичок фахівців, що створюють або використовують компоненти. Цей набір визначає відповідний розподіл фахівців програмної інженерії на аналітиків, системщиків, прикладників, програмістів й ін. При проектуванні архітектури програмна система розглядається як композиція компонентів третього рівня з доступом до компонентів першого і другого рівнів. Тобто архітектурне проектування — це розроблення компонентів третього рівня, визначення вхідних і вихідних даних рівнів ієрархії компонентів і їхніх зв’язків. Результат проектування — архітектура й інфраструктура, що містять у собі набір об’єктів, з яких можна формувати деякий конкретний вид архітектурної схеми для конкретного середовища виконання системи, а також набір елементів керування і контролю. Проектування архітектури системи завершується створенням опису, в якому відображені зафіксовані проектні рішення, логічна і фізична структура системи, а також способи взаємодії об’єктів..

30. Мови опису архітектури

Мови опису архітектури (ADLS) використовуються для опису архітектури програмного забезпечення. Різними організаціями було розроблено декілька різних ADLS, в тому числі AADL (стандарт SAE), Wright (розроблений в університеті Carnegie Mellon), Acme (розроблений в університеті Carnegie Mellon), xADL (розроблений в UCI), Darwin (розроблений в Imperial College в Лондоні), DAOP-ADL (розроблений в Університеті Малаги), а також ByADL (Університет L'Aquila, Італія). Спільними елементами для всіх цих мов є поняття компонента, коннектора і конфігурації.

3.2. Види (views)

Архітектура ПЗ зазвичай містить кілька видів, які аналогічні різним типам креслень в будівництві будинків. В онтології, встановленої ANSI / IEEE 1471-2000, види є екземплярами точки зору, де точка зору існує для опису архітектури з точки зору заданої множини зацікавлених осіб.

Приклади видів:

* Функціональний / логічний вигляд * Вид код / ​​модуль * Вид розробки (development) / структурний * Вид паралельності виконання / процес / потік * Фізичний вигляд / вид розгортання * Вид з точки зору дій користувача * Вид з точки зору даних

Хоча було розроблено кілька мов для опису архітектури програмного забезпечення, але в даний момент немає згоди з приводу того, який набір видів повинен бути прийнятий в якості еталону. В якості стандарту "для моделювання програмних систем (і не тільки)" був створений мова UML.

3.3. Базові фреймворки для архітектури ПЗ (software architecture frameworks)

Існують наступні фреймворки, що відносяться до галузі архітектури ПЗ:

4 +1

RM-ODP (Reference Model of Open Distributed Processing)

Service-Oriented Modeling Framework (SOMF)

Такі приклади архітектур як фреймворк Захмана (Zachman Framework), DODAF і TOGAF відносяться до галузі архітектури підприємства (enterprise architectures).

31. Шаблони проектування програмного забезпечення (англ. software design patterns) — ефективні способи вирішення задач проектування програмного забезпечення. Шаблон не є закінченим зразком, який можна безпосередньо транслювати в програмний код. Об'єктно-орієнтований шаблон найчастіше є зразком вирішення проблеми і відображає відношення між класами та об'єктами, без вказівки на те, як буде зрештою реалізоване це відношення.

Твірні шаблони …… Шаблони, що породжують (англ. Creational patterns) — це шаблони проектування, що абстрагують процес інстанціювання. Вони допоможуть зробити систему незалежною від способу створення, композиції та представлення її об'єктів.

Шаблон, який породжує класи, використовує спадкування, щоб варіювати створюваний клас, а шаблон, що створює об'єкти, делегує інстанціювання іншому об'єктові.

Ці шаблони важливі, коли система більше залежить від композиції об'єктів, ніж від спадкування класів.

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

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

Шаблони, що породжують, інкапсулюють знання про конкретні класи, які застосовуються у системі та приховують деталі того, як ці класи створюються і стикуються між собою.

Єдина інформація про об'єкти, що відома системі — їхні інтерфейси.

32. Шаблони проектування програмного забезпечення (англ. software design patterns) — ефективні способи вирішення задач проектування програмного забезпечення. Шаблон не є закінченим зразком, який можна безпосередньо транслювати в програмний код. Об'єктно-орієнтований шаблон найчастіше є зразком вирішення проблеми і відображає відношення між класами та об'єктами, без вказівки на те, як буде зрештою реалізоване це відношення.

Структурні шаблони (англ. structural patterns) — шаблони проектування, у яких розглядається питання про те, як із класів та об'єктів утворюються більші за розмірами структури.

Структурні шаблони рівня класу використовують спадковість для утворення композицій із інтерфейсів та реалізацій.

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

33. Шаблони проектування програмного забезпечення (англ. software design patterns) — ефективні способи вирішення задач проектування програмного забезпечення. Шаблон не є закінченим зразком, який можна безпосередньо транслювати в програмний код. Об'єктно-орієнтований шаблон найчастіше є зразком вирішення проблеми і відображає відношення між класами та об'єктами, без вказівки на те, як буде зрештою реалізоване це відношення.

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

У шаблонах поведінки рівня класу використовується спадкування — щоб розподілити поведінку поміж різних класів.

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

34. Тестування програмного забезпечення (Software Testing) — це процес технічного дослідження, призначений для виявлення інформації про якість продукту відносно контексту, в якому він має використовуватись.

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

За ступенем автоматизації:

Ручне тестування (manual testing) Автоматизоване тестування (automated testing)

Напівавтоматизоване тестування (semiautomated testing) За ступенем підготовленості до тестування: Тестування по документації (formal testing)

Тестування ad hoc або інтуїтивне тестування (ad hoc testing) — тестування без тест плану та документації, що базується на методиці передбачення помилки та власному досвіді тестера.

За знанням системи: Тестування чорного ящика (black box)

Тестування білого ящика (white box) Тестування сірого ящика (grey box)

За ступенем ізольованості компонентів: Компонентне (модульне) тестування (component/unit testing)

Інтеграційне тестування (integration testing) Системне тестування (system/end-to-end testing)

За часом проведення тестування: Альфа-тестування (alpha testing)

Тестування при прийманні або Димове тестування(smoke testing)

Тестування нової функціональності (new feature testing)

Регресивне тестування (regression testing) Тестування при здачі (acceptance testing)

Бета-тестування(beta testing) За об'єктом тестування:

Функціональне тестування (functional testing) Тестування продуктивності (performance testing)

Навантажувальне тестування (load testing) Стрес-тестування (stress testing)

Тестування стабільності (stability/endurance/soak testing)

Тестування зручності використання або Юзабіліті-тестування (usability testing)

Тестування інтерфейсу користувача (UI testing) Тестування безпеки (security testing)

Тестування локалізації (localization testing) Тестування сумісності (compatibility testing)

За ознакою позитивності сценаріїв:

Позитивне тестування (positive testing)

Негативне тестування (negative testing)

35. Тестування програмного забезпечення (Software Testing) — це процес технічного дослідження, призначений для виявлення інформації про якість продукту відносно контексту, в якому він має використовуватись.

Рівні тестування

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

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

Системне тестування тестує інтегровану систему для перевірки відповідності всім вимогам.

Системне інтеграційне тестування перевіряє, чи система інтегрується в будь-яку зовнішню систему (або системи) відповідно до системних вимог.

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

альфа-тестування — це симульоване або реальне операційне тестування потенційними користувачами/замовником або командою тестувальників на боці розробника.

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

36. Модульне тестування (англ. Unit testing) — це метод тестування програмного забезпечення, який полягає в окремому тестуванні кожного модуля коду програми. Модулем називають найменшу частину програми, яку може бути протестованою. У процедурному програмуванні модулем вважають окрему функцію або процедуру. В об'єктно-орієнтованому програмуванні — інтерфейс, клас. Модульні тести, або unit-тести, розробляються в процесі розробки програмістами та, іноді, тестувальниками білої скриньки (white-box testers).

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

37. Супроводження програмного забезпечення — процесс покращення, оптимізації та виправленні дефектів в програмному забезпеченні після його вводу до експлуатації.

Цей процес стандартизовано організацією ISO — ISO/IEC 14764[1]. Супровід ПЗ – сукупність дій із забезпечення його роботи, внесення змін при виявленні помилок, адаптації ПЗ до нового середовища функціонування, а також підвищення продуктивності або поліпшення деяких характеристик ПЗ. У зв'язку з вирішенням так званої проблеми 2000 року (пов’язаної з кодуванням дат у новому тисячолітті, зокрема, у двохсимвольному форматі) супроводження почав розглядатися, як більш важливий процес, що здійснюють розробники. Після змін система має вирішувати ті самі задачі, а також мати план перенесення інформації в інші БД. Супровід відповідно до стандартів ISO/IEC 12207 і ISO/IEC 14764 проводиться з метою виконання і модифікації програмного продукту в процесі експлуатації за умови збереження його цілісності.

Область знань «Супровід ПЗ (Software Maintenance)» складається з таких розділів:

– основні концепції (Basic Concepts), – процес супроводження (Process Maintenance),

– ключові питання супроводу ПЗ (key Issue in Software Maintenance),

– техніки супроводу (Techniques for Maintenance).

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

Основні концепції – це базові визначення і термінологія, підходи до еволюції і супроводу ПЗ, до оцінки вартості супроводу тощо. До основних концепцій можна віднести ЖЦ ПЗ (стандарт ISO/IEC 12207) і складання документації. Головне призначення цієї області знань полягає у виконанні готової програмної системи, фіксації помилок, що виникають при виконанні, дослідженні їх причин, аналізі необхідності модифікації системи з метою усунення помилок, оцінці вартості робіт із проведення змін функцій і системи в цілому. Розглядаються проблеми, пов'язані з ускладненістю продукту при великій кількості змін, і методи її подолання.

Процес супроводження містить у собі моделі процесу супроводу і планування діяльності людей, що проводять запуск ПЗ, перевірку правильності його виконання і внесення в нього змін. Цей процес згідно з стандартом ISO/IEC 14764 проводиться шляхом:

– коригування, тобто зміни продукту для усунення виявлених помилок або нереалізованих задач;

– адаптації, тобто настроювання продукту в умовах експлуатації, що змінилися, або в новому середовищі виконання;

– поліпшення, тобто еволюційної зміни продукту для підвищення продуктивності або рівня супроводу;

– перевірки ПЗ, пошуку і виправлення помилок при експлуатації системи.

Дата добавления: 2015-10-21