Размещено на http://www.allbest.ru/

ЗМІСТ

• Перелік позначень та скорочень
• Вступ
• 1. ОГЛЯД ОСНОВНИХ ПРИНЦИПІВ СУЧАСНОЇ програмної інженерії. ПОСТАНОВКА ЗАВДАННЯ КУРСОВОЇ РОБОТИ
• 1.1 Вивчення основних положень сучасної програмної інженерії
• 1.1.1 Ядро знань SWEBOK
• 1.1.2 Стандарти ISO/IEC 12207, ISO/IEC 9126
• 1.1.3 Основи методології та технології RUP
• 1.1.4 Практика застосування еталонних СА і ПП
• 1.2 Критичний аналіз програмної реалізації курсової роботи по БД
• 1.3 Постановка задачі курсової роботи
• 2. РЕАЛІЗАЦІЯ ЕТАПУ RUP / INCEPTION
• 2.1 Розробка повної специфікації системних вимог
• 2.1.1 Розробка функціональних системних вимог
• 2.1.2 Розробка нефункціональних системних вимог
• 2.2 Розробка декількох варіантів СА для Про «» з застосуванням архітектурних патернів
• 2.3 Вибір цільового варіанту архітектури ПЗ на основі критеріїв якості ПЗ
• 3. РЕАЛІЗАЦІЯ ЕТАПУ RUP / ELABORATION
• 3.1 Розробка уточненої інформаційної моделі ПрО
• 3.2 Проектування компонентних програмних рішень для цільової СА з використанням патернів проектування з GoF колекції
• 3.3 Розробка статичних UML діаграм для логічного проектування компонентного програмного рішення
• 3.4 Розробка динамічних UML діаграм для логічного проектування компонентного програмного рішення
• 3.5 Розробка UML діаграм для фізичного проектування компонентного програмного рішення
• 4. ФОРМУВАННЯ повного комплекту проектної ДОКУМЕНТАЦІЇ ДЛЯ Програмної реалізації ЦІЛьової ВЕРСІЇ СИСТЕМИ
• 4.1 Формування електронного пакета UML документації
• 4.2 Застосування метрик якості UML-діаграм
• 4.3 Визначення специфікації необхідних ресурсів, апаратно-програмної конфігурації та програмного інструментарію для реалізації проекту на наступних RUP-етапах
• Висновок
• Список джерел інформації
• Перелік позначень та скорочень
• ЖЦ- життєвий цикл;
• ПЗ - програмне забезпечення;
• ПС - програмна система;
• ПІ - програмна інженерія;
• СА - системна архітектура;
• КПР - компонентні програмні рішення;
• ПП - патерни проектування;
• АП - архітектурний патерн;
• GoF (Gang of Four) - група чотирьох;
• MVC - Model-View-Controller;
• БД - база даних;
• СВ - системні вимоги;
• ІС - інформаційна система;
• ПрО - предметна область.

Вступ

Темою курсової роботи є проектування програмного забезпечення для Інтернет-магазину з продажу компакт-дисків.

Мета курсової роботи - вивчення методик проектування програмного забезпечення , що можуть бути використані під час розробки системи. Ознайомлення з можливостями нотації UML, методикою RUP, основними патернами проектування програмного забезпечення та їх використання

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

При проектуванні системи буде проаналізовано курсову роботу виконану в 4-му семестрі з курсу «Основи баз даних та знань» та на основі зауважень до цієї роботи будуть розроблені нові СВ. Відповідно новим СВ буде вибрана програмна архітектура системи, будуть розроблені UML діаграми концептуального, логічного та фізичного рівня.

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

1. ОГЛЯД ОСНОВНИХ ПРИНЦИПІВ СУЧАСНОЇ програмної інженерії. ПОСТАНОВКА ЗАВДАННЯ КУРСОВОЇ РОБОТИ

1.1 Вивчення основних положень сучасної програмної інженерії

1.1.1 Ядро знань SWEBOK

Ядро знань SWEBOK є основним науково-технічним документом, що відображає думку багатьох зарубіжних і вітчизняних фахівців у галузі програмної інженерії та узгоджується з сучасними регламентованими процесами ЖЦ ПЗ стандарту ISO / IEC 12207. У цьому ядрі знань міститься опис 10 областей, кожна з яких представлена відповідно до прийнятої всіма учасниками створення цього ядра загальної схеми опису, що включає визначення понятійного апарату, методів і засобів, а також інструментів підтримки інженерної діяльності. У кожній області описується певний запас знань, який повинен використовуватися практично у відповідних процесах ЖЦ.

У кожній області наведено ключові поняття, підходи та методи проектування різних типів ПС. Дане розбиття областей на основні та допоміжні відповідає структурі розбиття процесів стандарту ISO / IEC 12207, виконання яких визначається знаннями, що містяться в ядрі SWEBOK.

В ядрі знань SWEBOK міститься опис всіх основних процесів і областей діяльності сучасної програмної інженерії. Вони зображені на рисунку 1.1

Размещено на http://www.allbest.ru/

Рисунок 1.1 - основні області програмної інженерії SWEBOK

Для більшого уявлення наведемо огляд кожної області ядра знань SWEBOK.

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

– Проектування ПЗ - це процес визначення архітектури, компонентів, інтерфейсів, інших характеристик системи і кінцевого складу програмного продукту.

– Конструювання ПЗ - створення працюючого ПЗ з залученням методів верифікації, кодування і тестування компонентів. До інструментів конструювання ПО віднесені мови програмування і конструювання, а також програмні методи та інструментальні системи: компілятори, СУБД, генератори звітів, системи контролю версій, конфігурацією, тестуванням та ін.

– Тестування ПЗ - це процес перевірки готової програми в статиці (перегляди, інспекції, налагодження вихідного коду) і в динаміці шляхом прогону кінцевого набору тестових даних, які перевіряють різні шляхи виконання програми та порівнянні отриманих результатів із заздалегідь запланованими.

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

Також існують додаткові організаційні методи і підходи ядра знань SWEBOK. Які відображають інженерію управління проектуванням ПС, конфігурацією, проектами, якістю. Вони зображені на рисунку 1.2

Размещено на http://www.allbest.ru/

Рисунок 1.2 - організаційні області програмної інженерії SWEBOK

Для більшого уявлення наведемо огляд кожної організаційної області знань SWEBOK.

– Управління конфігурацією (Software Configuration Management - SCM) полягає в ідентифікації компонентів системи, визначення функціональних та фізичних характеристик апаратного та програмного забезпечення для контролю за внесенням змін і трасування конфігурації протягом ЖЦ. Це управління відповідає одному з допоміжних процесів ЖЦ (ISO / IEC 12207), виконується технічним і адміністративним керівництвом проекту; складаються звіти про зміни, внесені в конфігурацію, і ступеня їх реалізації, а також проводиться перевірка відповідності внесених змін заданим вимогам.

– Управління проектами (Software Engineering Management) - керівництво роботами команди розробників ПЗ в процесі виконання плану проекту, визначення критеріїв ефективності роботи команди та оцінка процесів і продуктів проекту з використанням загальних методів управління, планування і контролю робіт.

– Процес інженерії ПЗ (Software Engineering Process) - це рівень, який пов'язаний з визначенням, реалізацією, оцінкою, виміром, управлінням змінами та вдосконаленням самого процесу.

– Методи та засоби інженерії - забезпечують проектування, реалізацію та виконання ПЗ. Вони накладають певні обмеження на інженерію ПЗ в зв'язку з особливостями застосування їх нотацій і процедур, а також забезпечують оцінку і перевірку процесів і продуктів. Інструменти є програмною підтримкою окремих методів інженерії ПЗ та забезпечують автоматизоване виконання завдань процесів ЖЦ.

– Інженерія якості ПЗ - набір властивостей продукту (сервіс чи служби), які характеризують його здатність задовольнити встановлені або передбачувані потреби замовника. Поняття якості має різні інтерпретації в залежності від конкретної системи і вимог до програмного продукту.

1.1.2 Стандарти ISO/IEC 12207, ISO/IEC 9126

Крім ядра знань SWEBOK, яке об'єднує в собі як прикладні так і наукові погляди на розвиток програмної інженерії, в індустрії розробки ПЗ в даний час найбільш розповсюджений стандарт ISO/IEC 12207.

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

Размещено на http://www.allbest.ru/

Рисунок 1.3 - основні процеси стандарту ISO/IEC 12207

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

Таким чином, SWEBOK та ISO/IEC 12207, по суті, доповнюють один одного, знаходяться в постійному розвитку та їх положення використовуються на практиці.

Одним із конкретних підходів, які використовуються при розробці ПЗ і відповідним цим стандартам є RUP. Він в повній мірі відповідає стандартам SWEBOK та ISO\IE 12207 та на даний час розвивається та підтримується міжнародним науковим консорціумом OMG (Object Management Group).

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

1.1.3 Основи методології та технології RUP

Rational Unified Process (RUP) - це методологія розробки програмного забезпечення, створена компанією Rational Software. В основі RUP лежать наступні основні принципи:

– Рання ідентифікація і безперервне (до закінчення проекту) усунення основних ризиків.

– Концентрація на виконанні вимог замовників, аналіз і побудова моделі прецедентів, а саме варіантів використання.

– Очікування змін у вимогах, проектних рішеннях і реалізації в процесі розробки.

– Компонентна архітектура, що реалізовується і тестується на ранніх стадіях проекту.

– Постійне забезпечення якості на всіх етапах розробки проекту (продукту).

– Робота над проектом в згуртованою командою, ключова роль у якій належить архітекторам.

RUP використовує ітеративну модель розробки. В кінці кожної ітерації (в ідеалі що триває від 2 до 6 тижнів) проектна команда повинна досягти запланованих на дану ітерацію цілей, створити або допрацювати проектні артефакти і отримати проміжну, але функціональну версію кінцевого продукту. Ітеративний підхід розробки дозволяє швидко реагувати на зміни вимог, виявляти і усувати ризики на ранніх стадіях проекту, а також ефективно контролювати якість створюваного продукту.

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

1 Початок (Inception). На цьому етапі:

– Формуються бачення і межі проекту;

– Створюється економічне обґрунтування (business case);

– Визначаються основні вимоги, обмеження і ключова функціональність продукту;

– Створюється базова версія моделі прецедентів;

– Оцінюються ризики.

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

2 Проектування (Elaboration). На етапі проектування здійснюється аналіз предметної області і побудова виконуваної архітектури. Це включає в себе:

– Документування вимог (включаючи детальний опис для більшості прецедентів);

– Оновлене економічне обґрунтування і точніші оцінки термінів і вартості;

– Знижені основні ризики.

Успішне виконання фази проектування означає досягнення віхи архітектури життєвого циклу.

3 Побудова (Construction). Під час цієї фази відбувається реалізація більшої частини функціональності продукту. Фаза Побудова завершується першим зовнішнім релізом системи і віхою початкової функціональної готовності.

4 Впровадження (Transition). Під час фази Впровадження створюється фінальна версія продукту і передається від розробника до замовника. Це включає в себе програму бета-тестування, навчання користувачів, а також визначення якості продукту. У випадку, якщо якість не відповідає очікуванням користувачів або критеріям, встановленим у фазі Початок, фаза Впровадження повторюється знову. Виконання всіх цілей означає досягнення віхи готового продукту та завершення повного циклу розробки.

1.1.4 Практика застосування еталонних СА і ПП

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

– Архітектурні патерни;

– Шаблони проектування;

– Патерни аналізу;

– Патерни тестування;

– Патерни реалізації.

1.2 Критичний аналіз програмної реалізації курсової роботи по БД

На попередньому етапі було проаналізовано курсову роботу четвертого семестру, темою цієї роботи було «розробка і реалізація бази даних для Інтернет - магазину з продажу компакт-дисків», та на основі зауважень отриманих в ході здачі цієї роботи були виявлені недоліки для подальшого їх усунення.

В ході критичного аналізу системи було виявлено:

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

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

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

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

– Не повна, або зовсім відсутня контекстна допомога, яка б координувала послідовність дії користувача.

1.3 Постановка задачі курсової роботи

Задачею курсової роботи є проектування та повне документування програмної системи. Проектуванням та документуванням включає розробку основних UML діаграм для даної предметної області.

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

Вибрати відповідні ПП з колекції GoF для проектування компонентних програмних рішень для вибраної цільової системної архітектури.

Після вибору патернів проектування необхідно розробити статичні UML-діаграми для логічного проектування компонентних програмних рішень. Тобто необхідно розробити повну діаграму класів на основі нової моделі даних та з використанням патернів проектування. Також для найбільш важливих класів розробити діаграми об'єктів, щоб зобразити стан екземпляра класу. Для наглядного представлення структури системи та розміщення її компонентів треба розробити діаграму пакетів.

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

Останнім етапом побудови діаграм є побудова UML-діаграм для фізичного проектування компонентних програмних рішень. На цьому етапі необхідно розробити діаграму розгортання та діаграму компонентів системи.

2. РЕАЛІЗАЦІЯ ЕТАПУ RUP / INCEPTION

2.1 Розробка повної специфікації системних вимог

При розробки програмного забезпечення основними умовами її успіху є повнота й документованість системних вимог.

Системні вимоги (СВ) - це деяка характеристика проектованої системи які виявляються в ході аналізу предметної задачі, а також повинні бути реалізовані в відповідності проектному рішенню ПрО. Збір і аналіз вимог представляє найбільш важкий й слабо формалізований етап при розробки будь якої ПС [1].

2.1.1 Розробка функціональних системних вимог

Функціональні СВ - це вимоги які відповідають на питання “ що робить програмна система ”. Це перечень всіх основних функцій обробки й представлення вихідних даних які повинні бути реалізовані в ПС.

Нижче представлений опис основних системних вимог ПС.

Опис розгорнутого сценарію прецеденту «».

1. Зацікавлені особи прецеденту та їх вимоги:

2. Користувач ПС тобто основний актор цього прецеденту:

3. Передумови прецеденту:

4. Основний успішний сценарій:

5. Розширення основного сценарію або альтернативні потоки:

6. Пост-умови:

7. Спеціальні СВ:

8. Список необхідних технологій та додаткових пристроїв:

Реєстрація в системі:

1. Зацікавлені особи прецеденту:

- Замовник: хоче зареєструватися для пошуку товарів та подальшого їх замовлення.

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

3. Передумови прецеденту:

- Система повинна бути активною;

- Постачальник повинен ввести коректні та реальні дані про себе в форму для реєстрації.

4. Основний успішний сценарій:

- Постачальник викликає форму реєстрації;

- Заповнює форму реєстрації;

- Погоджується з умовами користування системи;

- Успішно зареєстрований і автоматично авторизований.

5. Альтернативні потоки:

Невірні дані реєстрації:

1. Система повідомляє постачальника про помилку в внесених даних з пропозицією виправити їх;

2. Система повертає постачальника на форму реєстрації;

3. Система підсвічує поля з невірними даними;

4. Постачальник виправляє помилки згідно підказок и повторює процедуру реєстрації.

6. Пост-умови:

- Реєстрація успішно завершена;

- Авторизація пройшла успішно.

Авторизація в системі:

1. Зацікавлені особи:

- Замовник: хоче авторизуватися для управління своїм профілем та пошуку потрібних товарів;

- Адміністрація: хоче авторизуватися для управління клієнтами системи та товарами.

- Менеджер: хоче авторизуватися для управління замовленнями, зробленими постачальником.

2. Передумови прецеденту:

- Система повинна бути активною;

- Користувач повинен внести вірні дані для авторизації.

3. Основний успішний сценарій:

- Користувач вносить логін та пароль в відповідні поля;

- Користувач виконує процедуру авторизації.

4. Альтернативні потоки:

Невірні дані авторизації:

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

2. Система повертає користувача на форму авторизації;

3. Користувач вносить заново логін та пароль і повторює процедуру авторизації.

Вичерпаний ліміт спроб авторизації:

1. Система видає повідомлення про вичерпання ліміту спроб авторизації з наданням інформації про проміжок часу на який заблоковано авторизацію;

2. Користувач після розблокування авторизації вносить логін та пароль в відповідні поля та повторює процедуру авторизації;

5. Пост-умови: авторизація пройшла успішно.

Відновлення паролю:

1. Зацікавлені особи: адміністрація,менеджер або замовник, які бажають відновити пароль.

2. Передумови прецеденту:

- Система повинна бути активною;

- Користувач повинен викликати процедуру відновлення паролю.

3. Основний успішний сценарій:

- Користувач відповідає на ключове питання;

- Користувач виконує процедуру відновлення паролю;

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

4. Альтернативні потоки:

Невірна відповідь на ключове питання:

1. Система видає повідомлення про невірну відповідь на питання;

2. Система повертає користувача на форму відновлення паролю;

3. Користувач повторно відповідає на питання і повторює процедуру.

5. Пост-умови: процедура відновлення паролю пройшла успішно, на вашу почтову скриньку було надіслано пароль.

Редагування профілю користувача:

1. Зацікавлені особи прецеденту: адміністрація,менеджер або замовник, які хочуть змінити свій профіль.

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

3. Передумови прецеденту:

- Система повинна бути активною;

- Користувач повинен бути авторизований.

4. Основний успішний сценарій:

- Користувач викликає форму редагування;

- Користувач редагує дані;

- Користувач зберігає зміни.

5. Альтернативні потоки:

Помилка в даних при редагуванні:

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

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

3. Система підсвічує поля з помилками;

4. Користувач виправляє помилки і повторює процедуру збереження змін.

6. Пост-умови: дані успішно змінено.

Редагування товарів:

1. Зацікавлені особи прецеденту:

2. Адміністрація: хоче змінювати інформацію стосовно товарів.

3. Основні актори прецеденту: адміністрація, що прагне пропонувати на ринку товари свого складу комп'ютерної техніки ,через систему.

4. Передумови прецеденту:

- Система повинна бути активною;

- Адміністрація повинна бути авторизований.

5. Основний успішний сценарій:

- Адміністрація викликає форму управління товарами;

- Адміністрація редагує інформацію стосовно товару;

- Погоджується з зробленими змінами.

6. Альтернативні потоки:

Невірна інформацію:

1. Система повідомляє адмінстрацію про помилку в внесених даних з пропозицією виправити їх;

2. Система повертає адміністрацію на форму редагування товару;

3. Система підсвічує поля з невірними даними;

4. Адміністрація виправляє помилки згідно підказок і повторю процедуру збереження змін.

7. Пост-умови: дані успішно змінено.

Видалення товарів:

1. Зацікавлені особи прецеденту:

2. Адміністрація: хоче видаляти товари

3. Основні актори прецеденту: адміністрація, що прагне пропонувати на ринку товари свого складу комп'ютерної техніки ,через систему.

4. Передумови прецеденту:

- Система повинна бути активною;

- Адміністрація повинна бути авторизований.

5. Основний успішний сценарій:

- Адміністрація викликає форму управління товарами;

- Адміністрація видаляє товар;

- Погоджується з зробленими змінами.

6. Пост-умови: зміни успішно внесені.

Додавання компакт-дисків:

1. Зацікавлені особи прецеденту:Адміністрація: хоче додавати товари.

2. Основні актори прецеденту: адміністрація, що прагне пропонувати на ринку товари свого складу комп'ютерної техніки ,через систему.

3. Передумови прецеденту:

- Система повинна бути активною;

- Адміністрація повинна бути авторизований.

4. Основний успішний сценарій:

- Адміністрація викликає форму створення товару;

- Адміністрація заповнює інформацію стосовна товару;

- Погоджується з зробленими змінами.

5. Альтернативні потоки:

Невірна інформацію:

1. Система повідомляє адмінстрацію про помилку в внесених даних з пропозицією виправити їх;

2. Система повертає адміністрацію на форму створення товару;

3. Система підсвічує поля з невірними даними;

4. Адміністрація виправляє помилки згідно підказок і повторю процедуру створення товарі.

6. Пост-умови: Товар успішно створено.

Зміна рівня доступа користувачів:

1. Зацікавлені особи прецеденту: Адміністрація: хоче мати можливість назначати рівні доступу певному користувачеві.

2. Основні актори прецеденту: Адміністрація.

3. Передумови прецеденту:

- Система повинна бути активною;

- Адміністратор повинен бути авторизований.

4. Основний успішний сценарій:

- Адміністратор викликає форму управління користувачами;

- Адміністратор змінює рівень доступу певного користувача;

- Погоджується з зробленими змінами.

5. Пост-умови: зміни успішно внесені;

Видалення користувачами:

1. Зацікавлені особи прецеденту: Адміністрація: хоче мати можливість видалення з бази користувачів які не більше не користуються системою.

2. Основні актори прецеденту: Адміністрація.

3. Передумови прецеденту:

- Система повинна бути активною;

- Адміністратор повинен бути авторизований.

4. Основний успішний сценарій:

- Адміністратор викликає форму управління користувачами;

- Адміністратор видаляє користувача користувачами;

- Погоджується зі змінами.

5. Пост-умови: зміни успішно внесені;

Оформлення замовлення:

1. Зацікавлені особи прецеденту: Замовник: бажає замовити певні товари.

2. Основні актори прецеденту: замовник, що шукає товари та прагне їх замовити.

3. Передумови прецеденту:

- Система повинна бути активною;

- Замовник повинен бути авторизований.

4. Основний успішний сценарій:

- Замовник відкриває повну інформацію про товар , який його цікавить;

- Замовник додає до кошику товар;

- Замовник відправляє своє замовлення;

5. Пост-умови: замовлення успішно надіслано;

Перегляд інформації про замовлення:

1. Зацікавлені особи прецеденту: Замовник: бажає проглянути інформацію про замовлення.

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

3. Передумови прецеденту:

- Система повинна бути активною;

- Замовник повинен бути авторизований.

4. Основний успішний сценарій:

- Замовник відкриває форму ,на якій відображаються зробленні ним замовлення;

- Замовник переглядає інформацію ,яка йому цікава;

Перегляд інформації про компакт-диски:

1. Зацікавлені особи прецеденту: Замовник: бажає проглянути інформацію про диск.

2. Основні актори прецеденту: замовник, який хоче дізнатися інформацію стосовно диск,який його цікавить .

3. Передумови прецеденту:

- Система повинна бути активною;

4. Основний успішний сценарій:

- Замовник відкриває категорію ,в якій відображаються диски;

- Замовник натискає на диск,щоб переглянути його повну інформацію.

- Замовник переглядає інформацію ,яка йому цікава;

Управління замовленнями:

1. Зацікавлені особи прецеденту: Адміністрація та менеджер: хочуть мати можливість змінювати інформацію ,стосовно замовлень.

2. Основні актори прецеденту: Адміністрація та менеджер.

3. Передумови прецеденту:

- Система повинна бути активною;

- Користувач повинен бути авторизований.

4. Основний успішний сценарій:

- Користувач викликає форму управління замовленнями;

- Користувач виконує певні операції над замовленнями;

- Погоджується з зробленими змінами.

5. Пост-умови: зміни успішно внесені;

Видалення замовленнями:

1. Зацікавлені особи прецеденту: Адміністрація та менеджер: хочуть мати можливість видаляти застарілі замовлення.

2. Основні актори прецеденту: Адміністрація та менеджер.

3. Передумови прецеденту:

- Система повинна бути активною;

- Користувач повинен бути авторизований.

4. Основний успішний сценарій:

- Користувач викликає форму перегляду замовлень;

- Користувач видаляє замовлення;

5. Пост-умови: зміни успішно внесені;

програмний забезпечення системний специфікація

2.1.2 Розробка нефункціональних системних вимог

Нефункціональні СВ - це група СВ яка об'єднує в себе ті з них які відповідають на питання “як” та чи інша ПС реалізує відповідні СВ. К цим СВ відносять 6 атрибутів якості ПЗ які зафіксовані в стандарті SWIBOK [10].

– Продуктивність - це здатність ПС виконувати задані функції в певний інтервал часу;

– Надійність - це можливість ПС обробляти дані з заданим рівнем ймовірності відмов і помилок;

– Масштабованість - це здатність системи зберігати свої характеристики продуктивності й надійності в заданих межах при умовах значного зросту числа користувачів;

– Зручність використання - ця характеристика показує на скільки дана ПС відповідає критеріям як: зрозумілість функцій й інтерфейсу, можливість вивчення системи, ергономічність інтерфейсу;

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

– Переносимість - це свойство ПС коректно функціонувати не тільки на ісходной апаратній платформі й мати можливість працювати на інших альтернативних операційних платформах.

Для розробляємої ПС на основі нових сформульованих функціональних СВ та стандартах описаних в п.п. 1.1 були виявлені нижче перечисленні нефункціональні вимоги для проектуємої системи:

1. Доступність сторінки. Сервер з розміщеною на ньому сторінкою має бути доступним в будь-який час та повинен без збоїв обробляти всі необхідні запити до системи.

2. Обробка запиту не більше ніж 5 секунд.

3. Зручність використання інтерфейсу користувача. Інтерфейс має бути інтуїтивно зрозумілим та зручним у використанні.

4. Супроводжуваність коду. В програмному коді повинні бути коментарі, що пояснюють його структуру. Також необхідна наявність документації щодо побудови програмного коду.

2.2 Розробка декількох варіантів СА для Про «Інтернет-магазин з продажу компакт-дисків» з застосуванням архітектурних патернів

Разработка нескольких вариантов СА (candidate architectures) для своей ПрО с использованием архитектурных паттернов

Thin Web Client,

Thick Web Client

та Web Delivery

…. etc……

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

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

– Продуктивність

– Надійність

– Захищеність

– Можливість ефективної підтримки та супроводу

Системну архітектуру також можна представити у вигляді кортежу трьох множин :

, де:

- System Architecture

- множина програмних компонентів(модулів), які реалізують функціональність даної системи .

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

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

Для предметної області «Інтернет-магазин з продажу компакт-дисків» було розроблено наступні варіанти системних архітектур.

2.3 Вибір цільового варіанту архітектури ПЗ на основі критеріїв якості ПЗ

// решается индивидуально для каждой ПрО

3. РЕАЛІЗАЦІЯ ЕТАПУ RUP / ELABORATION

3.1 Розробка уточненої інформаційної моделі ПрО

Виходячи з аналізу нових системних вимог було розроблено уточнену інформаційну модель предметної області «Інтернет-магазин з продажу компакт-дисків». Розроблена інформаційна модель даних відображає дані з погляду їхнього змісту та з погляду використання в предметній області . Дана модель зображена на рисунку 3.1

Рисунок 3.1 - уточнена інформаційна модель

3.2 Проектування компонентних програмних рішень для цільової СА з використанням патернів проектування з GoF колекції

(т.е мотивированный выбор соответствующих ПП)

3.3 Розробка статичних UML діаграм для логічного проектування компонентного програмного рішення

(class diagrams, object diagrams, package diagrams extension and refinering)

3.4 Розробка динамічних UML діаграм для логічного проектування компонентного програмного рішення

(activity, state, collaboration diagrams)

3.5 Розробка UML діаграм для фізичного проектування компонентного програмного рішення

(component and deployment diagrams)

4. ФОРМУВАННЯ повного комплекту проектної ДОКУМЕНТАЦІЇ ДЛЯ Програмної реалізації ЦІЛьової ВЕРСІЇ СИСТЕМИ

4.1 Формування електронного пакета UML документації

В результаті виконання курсової роботи з дисципліни основи проектування програмного забезпечення було отримано наступний набір UML діаграм:

– діаграма варіантів використання;

– діаграми стійкості;

– діаграми класів;

– діаграми діяльності;

– діаграми послідовності;

– діаграма станів;

– діаграма об'єктів;

– діаграма кооперації.

4.3 Визначення специфікації необхідних ресурсів, апаратно-програмної конфігурації та програмного інструментарію для реалізації проекту на наступних RUP-етапах

Для розгортання системи на ПК повинен бути встановлений один з браузерів версій Opera 11,Мozilla Firefox 3.5 та налаштоване підключення до мережі Інтернет. Якщо ж планується використовувати всю систему на одному ПК, то необхідно встановити крім браузеру наступне програмне забезпечення:

- Сервер MySQL версії 5.1.54 або вище

- Сервер Apache 2.2.17 з налаштованим PHP 5.3.4

У такому випадку систему можливо використовувати як систему Stand Alone.

Список джерел інформації

1 Леффингуэлл Д., Уидриг Д. Принципы работы с требованиями к программному обеспечению. Унифицированный подход: Пер. с англ. - М.: Вильямс, 2002. - 448 с..

2 Коналлен Дж. Разработка Web-приложений с использованием UML. / Пер. с англ. М.: Издательский дом «Вильямс», 2001. - 288 .с.

3 Архитектуры, модели и технологии программного обеспечения информационно-управляющих систем / Ткачук Н.В., Шеховцов В.А., Кукленко Д.В., Сокол В.Е. - Харьков: НТУ «ХПИ». - 2005.

4 Гради Буч, Роберт А. Максимчук, Майкл У. Энгл, Бобби Дж. Янг, Джим Коналлен, Келли А. Объектно-ориентированный анализ и проектирование с примерами приложений (UML 2). Третье издание.-М.: Вильямс, 2008.

5 Джеймс Рамбо, М. Блаха, UML 2.0. Объектно-ориентированное моделирование и разработка (2-е издание)-СПб.: Питер, 2006.

6 Опис шаблонів проектування, патернів на вільному ресурсі вікіпедіа http://ru.wikipedia.org/wiki/Шаблоны_проектирования.

7 Котеров Д.В., Костарев А.Ф., РНР 5. СПб.: БХВ-Пітер, 2005.

8 Стаття про глобальні системи бронювання http://ru.wikipedia.org/wiki/ Глобальная_дистрибьюторская_система.

9 Офіційний сайт компанії Amadeus в Росії http://www.amadeus.ru/.

10 Офіційний сайт SWEBOK http://www.computer.org/portal/web/swebok/.

Размещено на Allbest.ru