ОППО_КР_пример_содержан
.pdf2 Проектування або детальна розробка (Elaboration) - на етапі проектування здійснюється аналіз предметної області і побудова виконуваної архітектури. Це включає в себе:
Документування вимог (включаючи детальний опис для більшості прецедентів);
Спроектовану, реалізовану і протестовану виконувану архітектуру;
Оновлене економічне обґрунтування і точніші оцінки термінів і вартості;
Знижені основні ризики.
Успішне виконання фази проектування означає досягнення віхи архітектури життєвого циклу.
3 Конструювання (Construction) - під час цієї фази відбувається реалізація більшої частини функціональності продукту. Фаза побудови завершується першим зовнішнім релізом системи і віхою початкової функціональної готовності.
4 Впровадження (Transition) - під час фази впровадження створюється фінальна версія продукту і передається від розробника до замовника. Це включає в себе програму бета-тестування, навчання користувачів, а також визначення якості продукту. У випадку, якщо якість не відповідає очікуванням користувачів або критеріям, встановленим у фазі початку, фаза впровадження повторюється знову. Виконання всіх цілей означає досягнення віхи готового продукту і завершення повного циклу розробки.
1.5 Практика застосування патернів проектування
При реалізації проектів з розробки програмних систем і моделювання бізнес процесів зустрічаються ситуації, коли рішення проблем у різних проектах мають подібні структурні риси. Спроби виявити схожі схеми або структури в рамках об'єктно-орієнтованого аналізу і проектування призвели до появи поняття патерну, яке з абстрактної категорії перетворилося на неодмінний атрибут сучасних CASEзасобів. Патерни об’єктно-орієнтованого аналізу і програмування розрізняються ступенем деталізації і рівнем абстракції.
Пропонується наступна загальна класифікація патернів за категоріями їх застосування:
Архітектурні патерни;
Патерни проектування;
Патерни аналізу;
Патерни тестування;
Патерни реалізації.
Архітектурні патерни (Architectural patterns) – множина попередньо визначених підсистем зі специфікацією їх відповідальності, правил і базових принципів встановлення відносин між ними. Архітектурні патерни призначені для специфікації фундаментальних схем структуризації програмних систем. Найбільш відомими патернами цієї категорії є патерни GRASP (General Responsibility Assignment Software Pattern). Ці патерни ставляться до рівня системи і підсистем, але не до рівня класів. Як правило, формулюються в узагальненій формі, використовують звичайну термінологію і не залежать від галузі застосування. Патерни цієї категорії систематизував і описав К. Ларман [1].
Патерни проектування (Design patterns) – спеціальні схеми для уточнення структури підсистем або компонентів програмної системи і відносин між ними. Патерни проектування описують загальну структуру взаємодії елементів програмної системи, які реалізують вихідну проблему проектування в конкретному контексті. Найбільш відомими патернами цієї категорії є патерни GoF (Gang of Four), названі на честь Е. Гамми, Р. Хелма, Р. Джонсона і Дж. Вліссідеса [2], які систематизували їх і представили загальний опис.
Паттерни GoF включають в себе 23 патерни. Ці патерни не залежать від мови реалізації, але їх реалізація залежить від галузі застосування.
Паттерни аналізу (Analysis patterns) – спеціальні схеми для подання спільної організації процесу моделювання. Патерни аналізу відносяться до однієї або декількох предметних областей і описуються в термінах предметної області. Найбільш відомими патернами цієї групи є патерни бізнес-моделювання ARIS (Architecture of Integrated Information Systems), які характеризують абстрактний
рівень представлення бізнес-процесів. Надалі патерни аналізу конкретизуються у типових моделях з метою виконання аналітичних оцінок або імітаційного моделювання бізнес-процесів [6].
Патерни тестування (Test patterns) – спеціальні схеми для подання спільної організації процесу тестування програмних систем. До цієї категорії патернів відносяться такі патерни, як тестування чорного ящика, білого ящика, окремих класів, системи. Патерни цієї категорії систематизував і описав М. Гранд. Деякі з них реалізовані в інструментальних засобах, найбільш відомими з яких є IBM Test Studio. У зв'язку з цим патерни тестування іноді називають стратегіями або схемами тестування.
Патерни реалізації (Implementation patterns) – сукупність компонентів і інших елементів реалізації, що використовуються в структурі моделі при написанні програмного коду.
Ця категорія патернів ділиться на наступні підкатегорії: патерни організації програмного коду, патерни оптимізації програмного коду, патерни стійкості коду, патерни розробки графічного інтерфейсу користувача та ін патерни цієї категорії описані в роботах М. Гранда, К. Бека, Дж. Тідвелла та ін., деякі з них реалізовані в популярних інтегрованих середовищах програмування у формі шаблонів створюваних проектів. У цьому випадку вибір шаблону програмного продукту дозволяє отримати деяку заготівлю програмного коду.
Повний перелік паттернів проектування GoF та короткий опис призначення кожного з них:
1)Абстрактна фабрика (Abstract Factory) – надає інтерфейс для створення множини зв’язаних між собою або незалежних об’єктів, конкретних класів, котрі невідомі;
2)Адаптер (Adapter) – перетворює існуючий інтерфейс класу в інший інтерфейс, котрий зрозумілий клієнтам. При цьому забезпечує сумісну роботу класів, неможливу без даного патерну через несумісність інтерфейсів;
3)Міст (Bridge) – відділяє абстракцію класу від його реалізації, завдяки чому з’являється можливість незалежно змінювати те та інше;
4)Будівельник (Builder) – відділяє створення складного об’єкту від його уявлення, дозволяючи використовувати один і той же процес розробки для створення різних уявлень;
5)Ланцюжок обов’язків (Chain of Responsibility) – дозволяє уникнути жорсткої залежності відправника запиту від його одержувача, при цьому об’єктиодержувачі зв’язуються в ланцюг, а запит передається по ланцюгу, доки якийсь об’єкт не обробить його;
6)Команда (Command) – інкапсулює запит у вигляді об’єкту, забезпечуючи параметризацію клієнтів типом запиту, встановлення черговості запитів, протоколювання запитів і скасування виконання операцій;
7)Компонувальник (Composite) – групує об’єкти в ієрархічну структуру для уявлення відношень типу «частина-ціле», що дозволяє клієнтам працювати з одиничними об’єктами так само, як і з групами об’єктів;
8)Декоратор (Decorator) – застосовується для розширення наявної інформації і є альтернативою породження підкласів на основі динамічного призначення об’єктам нових операцій;
9)Фасад (Facade) – надає єдиний інтерфейс до множини операцій або інтерфейсів в системі на основі уніфікованого інтерфейсу для полегшення роботи
зсистемою;
10)Фабричний метод (Factory Method) – визначає інтерфейс для розробки об’єктів, при цьому об’єкти даного класу можуть бути створені його підкласами;
11)Пристосуванець (Flyweight) – використовує принцип розділення для ефективної підтримки великої кількості малих об’єктів;
12)Інтерпретатор (Interpreter) – для заданої мови визначає уявлення її граматики на основі інтерпретатора пропозицій мови, який використовує це уявлення;
13)Ітератор (Iterator) – надає можливість послідовно перебрати всі елементи складеного об’єкту, не розкриваючи його внутрішнього уявлення;
14)Посередник (Mediator) – визначає об’єкт, у котрому інкапсульовано знання про те, як взаємодіють об’єкти з деякої множини. Сприяє зменшенню
кількості зв’язків між об’єктами, дозволяючи їм працювати без явних посилань один на одного і незалежно змінювати схему взаємодії;
15)Зберігач (Memento) – надає можливість отримати й зберегти у зовнішній пам’яті внутрішній стан об’єкту, щоб пізніше об’єкт можна було відновити точно
утакому ж стані, не порушуючи принципу інкапсуляції;
16)Спостерігач (Observer) – специфікує залежність типу «один до багатьох» між різними об’єктами, так що при зміні стану одного об’єкту всі залежні від нього отримували повідомлення й автоматично обновлювались;
17)Прототип (Prototype) – описує види створюваних об’єктів за допомогою прототипу, що дозволяє створювати нові об’єкти шляхом копіювання цього прототипу;
18)Заступник (Proxy) – підміняє вибраний об’єкт іншим об’єктом для управління контролю доступу до вихідного об’єкту;
19)Одинак (Singleton) – для вибраного класу забезпечує виконання вимог одиничності екземпляру і надання до нього повного доступу;
20)Стан (State) – дозволяє вибраному об’єкту варіювати свою поведінку при зміні внутрішнього стану. При цьому складається враження, що змінився клас об’єкту;
21)Стратегія (Strategy) – визначає множину алгоритмів, інкапсулюючи їх усі
ідозволяючи підставляти один замість другого. При цьому можна змінювати алгоритм незалежно від клієнта, котрий ним користується;
22)Шаблонний метод (Template Method) – визначає структуру алгоритму, перерозподіляючи відповідальність за деякі його шаги на підкласи. При цьому підкласи можуть перевизначати шаги алгоритму, не змінюючи його загальної структури;
23)Відвідувач (Visitor) – дозволяє визначити нову операцію, не змінюючи описів класів, у об’єктів котрих вона викликається.
1.6 Критичний аналіз програмної реалізації курсової роботи по БД
Метою попередньої курсової роботи було розробка і реалізація бази даних для предметної області “ Інтернет магазин автозапчастин ”.
Програмна реалізація курсової роботи мала ряд недоліків, які були спричинені перш за все недостатньо якісним користувацьким інтерфейсом для основних користувачів програмної системи – клієнтів, через відсутність корзини для покупок, можливості пошуку деталей за різними критеріями, та адміністраторів – через відсутність зручного інтерфейсу для роботи з функціями адміністратора. А також програмне рішення було недостатньо захищеним від несанкціонованого доступу.
1.7 Постановка задачі курсової роботи
На основі критичного аналізу попередньої курсової роботи по розробці застосувань баз даних, а також використовуючи нові знання із курсу основ проектування ПЗ, необхідно спроектувати ПЗ для автоматизованої системи вирішення задач обліку продажів Інтернет-магазину автозапчастин, дотримуючись стандартів ISO 12207, ISO 9126.
Нове ПЗ має усунути недоліки попередньої курсової роботи, значно покращити інтерфейс користувача, розширити функціональні можливості програмної системи, додавши нові функції: «Прогнозування попиту на деталі», «Замовлення деталей, котрі відсутні на складі» та можливістю пошуку деталей за різними критеріям. Необхідно реалізувати фази Inception та Elaboration розробки програмного забезпечення за RUP стандартом і розробити повний набір UML діаграм.
2 РЕАЛІЗАЦІЯ ЕТАПУ RUP / INCEPTION
2.1 Текстовий формат специфікації СВ
В контексті методології RUP системні вимоги – це весь набір певних прецедентів використання ПЗ, тобто концептуальна модель функціонування системи та її оточення.
Прецедент (Use Case) – це набір взаємопов’язаних сценаріїв, який описує використання ПС певним актором для вирішення однієї із задач.
Актор (Actor) – сутність, яка має поведінку: напр., людина (користувач), окремий програмний компонент або інша програмна система.
Сценарій (Scenario) – послідовність дій або взаємодій між актором та ПС. Первинною формою опису прецедентів є текст, який має бути сформованим
у процесі виявлення СВ (шляхом спілкування із майбутніми користувачами, експертами із предметної області тощо). Для подальшої формалізації (структуризації) текстового опису прецедентів існує декілька форм:
вільна форма опису – неформальний стиль описання. Опис прецеденту займає кілька абзаців і охоплює різні можливі сценарії;
стислий опис – анотація у вигляді одного абзацу. Вона описує тільки головний успішний сценарій;
розгорнутий опис – при такому підході детально описуються всі шаги і варіанти розвитку сценарію.
Найбільш інформативним та корисним для подальшого використання СВ в проектуванні ПС є розгорнутий опис прецедентів.
2.2 Специфікація системних вимог для автоматизації вирішення задач обліку продажів Інтернет магазину автозапчастин
У процесі дослідження роботи Інтернет магазину автозапчастин, з урахуванням недоліків та нової функціональності, мною розроблена наступна специфікація вимог за стандартом RUP у форматі розгорнутого опису:
Реєстрація в системі:
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)Розширення основного сценарію або альтернативні потоки: користувач ввів некоректні дані, щодо кількості деталей або на складі відсутня введена кількість деталей:
ПС повідомляє користувача, що була введена некоректна кількість деталей або наявної кількості деталей на складі недостатньо і пропонує знов ввести коректну кількість, деталей, повідомляючи клієнта про максимально доступну кількість деталей;