
- •Основи програмної інженерії Тема 1. Поняття програмної інженерії. Вступ
- •Процес створення програмного забезпечення
- •Моделі технологічного процесу створення пз
- •Моделі процесу розробки по
- •Характеристики якісного пз
- •Тема 2. Види моделей систем. Поняття і класифікація вимог до програмної системи.
- •Способи запису специфікацій вимог.
- •Види моделей систем.
- •Мова моделювання uml.
- •Об'єктні моделі
- •Інструментальні case-засоби.
- •Тема 3. Поняття архітектурного проектування. Архітектурні моделі.
- •Архітектурний шаблон mvc.
- •Особливості шаблону mvc.
- •Модель проблемної сфери.
- •Тема 4. Важливі функціональні засоби мови c#. Автоматично реалізовані властивості.
- •Ініціалізатори об'єктів та колекцій.
- •Автоматичне виведення типу.
- •Анонімні типи.
- •Використання методів розширення Методи розширення
- •Застосування методів розширення до інтерфейсу
- •Створення фільтруючих методів розширення
- •Тема 5. Лямбда-вирази. Мова linq. Лямбда-вирази.
- •Мова linq.
- •Методи розширення linq.
- •Відкладені запити linq.
- •Тема 6. Створення слабо зв'язаних компонентів. Впровадження залежності.
- •Контейнери впровадження залежності.
- •Бібліотека Ninject.
- •Порядок роботи з Ninject.
- •Тема 7. Засоби доступу до даних. Технологія ado.Net.
- •Реалізація доступу до даних.
- •Робота з даними.
- •Тема 8. Тестування пз. Розробка через тестування. Автоматизоване тестування пз та його види.
- •Розробка через тестування. Робочий потік "червоний-зелений-рефакторинг".
- •Модель "організація.Дія.Твердження".
- •Використання бібліотеки Moq
- •Тема 9. Проектування інтерфейсу користувача. Інтерфейс користувача.
- •Переваги графічного інтерфейсу.
- •Процес проектування графічного інтерфейсу.
- •Принципи проектування інтерфейсів користувача.
- •Шаблони.
- •Тема 10. Основи інженерії вимог. Розробка вимог.
- •Формування і аналіз вимог.
- •Опорні точки зору.
- •Сценарії.
- •Атестація вимог.
- •Тема 11. Прототипування програмних систем. Поняття прототипування.
- •Переваги прототипування.
- •Види прототипування.
- •Технології швидкого прототипування.
- •Тема 12. Покомпонентна розробка. Компоненти і класи об'єктів.
- •Компоненти як постачальники послуг.
- •Рівні абстракції компонентів.
- •Вимоги до компонентів.
- •Тема 13. Шаблони проектування. Структурні шаблони.
- •Поняття шаблону проектування.
- •Основні елементи шаблону.
- •Механізми повторного використання.
- •Структурні шаблони проектування.
Об'єктні моделі
Об'єктно-орієнтований підхід широко використовується при розробці програмного забезпечення , особливо для розробки інтерактивних систем . У цьому випадку системні вимоги формуються иа основі об'єктної моделі , а програмування виконується за допомогою об'єктно мов, таких , як java або С++ .
Об'єктні моделі, розроблені для формування вимог , можуть використовуватися як для представлення даних , так і для процесів їх обробки. У цьому відношенні вони об'єднують моделі потоків даних і семантичні моделі даних . Вони також корисні для класифікації системних сутностей і можуть представляти сутності , що складаються з інших сутностей.
Для деяких класів систем об'єктні моделі - природний спосіб відображення реально існуючих об'єктів , які знаходяться під управлінням системи . Наприклад , для систем , що обробляють інформацію щодо конкретних об'єктів (таких , як автомобілі , літаки , книги і т.д. ) , які мають чітко визначені атрибути . Більш абстрактні високорівневі сутності , наприклад бібліотеки , медичні реєструючі системи або текстові редактори , важче моделювати у вигляді класів об'єктів , оскільки вони мають досить складний інтерфейс, що складається з незалежних атрибутів і методів.
Об'єктні моделі, розроблені під час аналізу вимог , безсумнівно , спрощують перехід до об'єктно-орієнтованого проектування та програмування . Однак кінцеві користувачі часто вважають об'єктні моделі неприродними і важкими для розуміння. Часто вони воліють функціональні представлення процесів обробки даних. Тому корисно доповнити їх моделями потоків даних , щоб показати наскрізну обробку даних в системі.
Клас об'єктів - це абстракція безлічі об'єктів , які визначаються загальними атрибутами (як у семантичній моделі даних) і сервісами або операціями , які забезпечуються кожним об'єктом . Об'єкти - це виконувані сутності з атрибутами і сервісами класу об'єктів. Об'єкти представляють собою реалізацію класу , на основі одного класу можна створити багато різних об'єктів. Зазвичай при розробці об'єктних моделей основна увага зосереджена на класах об'єктів і їхніх стосунках.
Моделі систем , що розробляються при формуванні вимог , повинні відображати реальні сутності , що належать класам об'єктів. Класи не повинні містити інформацію про окремі системних об'єктах. Можна розробити різні типи об'єктних моделей , що показують , як класи пов'язані один з одним, як об'єкти агрегуються з інших об'єктів , як об'єкти взаємодіють з іншими об'єктами і т.д. Ці моделі розширюють розуміння розроблюваної системи .
Ідентифікація об'єктів і класів об'єктів вважається найбільш складним завданням в процесі об'ектноюріентірованной розробки систем . Визначення об'єктів - це основа для аналізу та проектування системи.
Рис. 5 – частина ієрархії класів для бібліотечної системи
Інструментальні case-засоби.
Термін CASE (Computer Aided Software Engineering) дослівно переводиться як розробка програмного забезпечення за допомогою комп'ютера. В даний час цей термін отримав ширший зміст, який означає автоматизацію розробки інформаційних систем.
Інструментальні CASE-засоби – це пакет програмних засобів, який підтримує окремі етапи процесу розробки програмного забезпечення: проектування, написання програмного коду або тестування.
CASE-систему можна визначити як набір CASE-засобів, що мають певне функціональне призначення і виконаних в рамках єдиного програмного продукту.
Перевага групування CASE-засобів в інструментальний пакет полягає в тому , що , працюючи разом, вони забезпечують більш всебічну підтримку процесу розробки ПЗ , ніж можуть запропонувати окремі інструментальні засоби. Загальні сервіси можуть викликатися всіма засобами. Інструментальні засоби можна об'єднати в пакет за допомогою загальних файлів, репозиторію або загальної структури даних.
Основна мета CASE-систем і засобів полягає в тому, щоб відокремити проектування програмного забезпечення від його кодування і подальших етапів розробки (тестування, документування і ін.), а також автоматизувати весь процес створення програмних систем, або інжиніринг (від англ, engineering - розробка).
Останнім часом все частіше розробка програм починається з деякого попереднього варіанту системи. Як такий варіант може виступати спеціально для цього розроблений прототип, або застаріла і така, що не задовольняє новим вимогам система. У останньому випадку для відновлення знань про програмну систему з метою подальшого їх використання застосовують повторну розробку – реінжиніринг (reengineering).
Повторна розробка зводиться до побудови початкової моделі програмної системи шляхом дослідження її програмних кодів. Маючи модель, можна її удосконалити, а потім знов перейти до розробки. Так часто і поступають при проектуванні. Одним з найбільш відомих принципів такого типу є принцип «поворотного проектування» – Round Trip Engineering (RTE).
Сучасні CASE-системи не обмежуються тільки розробкою, а найчастіше забезпечують і повторну розробку. Це істотно прискорює розробку додатків і підвищує їх якість.
Інструментальні засоби аналізу і проектування ПЗ створені для підтримки моделювання систем на етапах аналізу і проектування процесу розробки програмного забезпечення. Вони підтримують створення , редагування та аналіз графічних нотацій , що використовуються в структурних методах. Інструментальні засоби аналізу і проектування часто підтримують тільки певні методи проектування та аналізу, наприклад об'єктно-орієнтовані. Інші інструментальні засоби є загальними системами редагування діаграм багатьох типів , які використовуються різними методами проектування і аналізу . Інструментальні засоби , орієнтовані на певні методи , звичайно автоматично підтримують правила і базові принципи цих методів , що дозволяє виконувати автоматичний контроль діаграм .
На рисунку 5 показана схема пакета інструментальних засобів підтримки аналізу та проектування ПЗ. Інструментальні засоби зазвичай об'єднуються через загальний репозиторій , структура якого є власністю розробника пакету інструментальних засобів. Пакети інструментальних засобів зазвичай закриті, тобто не розраховані на додання користувачами власних інструментів або на зміну засобів пакету.
Нижче перераховані засоби, які входять в пакет інструментальних засобів, показаний на рисунку.
Редактори діаграм призначені для створення діаграм потоків даних , ієрархій об'єктів , діаграм "сутність - зв'язок " і т.д. Ці редактори не тільки мають засоби малювання , але і підтримують різні типи об'єктів , використовувані в діаграмах.
Засоби проектування , аналізу та перевірки виконують проектування ПЗ і створюють звіт про помилки та дефекти в системній архітектурі . Вони можуть працювати спільно з системою редагування , тому виявлені помилки можна усунути на ранній стадії процесу проектування .
Центральний репозиторій дозволяє проектувальнику знайти потрібний проект і відповідну проектну інформацію.
Словник даних зберігає інформацію про об'єкти , які використовуються в структурі системи .
Засоби генерування звітів на основі інформації з центрального репозиторію автоматично генерують системну документацію.
Засоби створення форм визначають формати документів та екранних форм .
Засоби імпорту та експорту дозволяють обмінюватися інформацією з центрального репозиторію різним інструментальним засобам .
Генератори програмного коду автоматично генерують програми на основі проектів , що зберігаються в центральному репозиторії .
У деяких випадках можливо генерувати програми або фрагменти програм на основі інформації, представленої в системній моделі. Генератори коду , які включені у пакети інструментальних засобів , можуть генерувати код на таких мовах , як java , С++ або С. Оскільки в моделях не передбачена деталізація низького рівня, генератор програмного коду не в змозі згенерувати закінчену систему. Зазвичай необхідні програмісти для завершення автоматично згенерованих програм.
Деякі пакети інструментальних засобів аналізу і проектування призначені для підтримки методів розробки програмних додатків ділової сфери . Зазвичай для створення загального репозиторію інструментів вони використовують системи баз даних типу Sybase або Oracle . Ці пакети інструментальних засобів містять велику кількість засобів мов програмування четвертого покоління , призначених для генерування програмного коду на основі системної архітектури , вони також можуть генерувати бази даних з використанням мов програмування четвертого покоління.