Система для автоматизации продаж в магазині

 

 

МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ

ПОЛТАВСЬКИЙ НАЦІОНАЛЬНИЙ ТЕХНІЧНИЙ УНІВЕРСИТЕТ

ІМЕНІ ЮРІЯ КОНДРАТЮКА

 

ФАКУЛЬТЕТ ІНФОРМАЦІЙНИХ ТА ТЕЛЕКОМУНІКАЦІЙНИХ ТЕЗНОЛОГІЙ ТА СИСТЕМ

 

КАФЕДРА КОМП’ЮТЕРНИХ ТА ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ І СИСТЕМ

 

 

 

 

 

 

 

 

Розрахунково-графічна робота

з навчальної дисципліни «Технології створення програмних продуктів»

на тему:

«Система для автоматизации продаж в магазині»

 

 

 

 

 

 

Виконала: студентка групи 301-ТН Ткаленко Інна Олександрівна Перевірили: Соловчук К. Ю. Захаров С. О.

 

 

 

 

 

Полтава

2014

 

Зміст

 

 

Вступ

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

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

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

2. Перевірка відповідності  реалізації проектної документації (верифікація) може бути виконана  тільки вручну.

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

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

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

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

 

Rational Rose - засіб візуального моделювання об'єктно-орієнтованих інформаційних систем. Робота продукту заснована на універсальній мові моделювання UML.

Уніфікована мова моделювання (UML):

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

- не залежить від використовуваної  методології розробки проекту.

Завдяки унікальному мови моделювання Rational Rose здатний вирішувати практично будь-які завдання в проектуванні інформаційних систем: від аналізу бізнес-процесів до кодогенерацію на певній мові програмування. Rational Rose дозволяє розробляти як високорівневі, так і низькорівневі моделі, здійснюючи тим самим або абстрактне проектування, або логічне. В залежності від поставки, в Rational Rose може бути розширений або звужений набір візуальних компонент (діаграм).

Rational Rose підтримує пряме і зворотне проектування на мовах багатьох мовах(ADA, Java, С, C + +, Basic), підтримує технології COM, DDL, XML та дозволяє генерувати схеми Oracle і SQL. Також має відкритий API, що дозволяє створювати власними силами модулі для конкретних мов програмування.

 

ПОСТАНОВКА ЗАДАЧІ

Варіант № 21

Побудувати систему для автоматизации продаж в магазині.

В середовищі Rational Rose побудувати наступні діаграми:

• Use case diagram (діаграми прецедентів);
• Class diagram (діаграми класів);
• Collaboration diagram (діаграми співпраці);
• Sequence diagram (діаграми послідовностей дій);
• Statechart diagram (діаграми станів);
• Activity diagram (діаграми активності);
• Deployment diagram (діаграми топології);
• Component diagram (діаграми компонентів).

 

Розв’язання задачі

Use case diagram (діаграми прецедентів)

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

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

Рисунок 1. Діаграма прецедентів.

Class diagram (діаграми класів)

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

 Діаграми класів можуть  застосовуватися і при прямому  проектуванні, тобто в процесі  розробки нової системи, і при  зворотному проектуванні - описі  існуючих і використовуваних  систем. Інформація з діаграми  класів безпосередньо відображається  у вихідний код програми - у  більшості існуючих інструментів UML-моделювання можлива кодогенераціі для певної мови програмування (зазвичай Java або C++). Таким чином, діаграма класів - кінцевий результат проектування і відправна точка процесу розробки.

Значки діаграми дозволяють відображати складну ієрархію систем, взаємозв'язку класів (Classes) і інтерфейсів (Interfaces).

Даний тип діаграм протилежний за змістом діаграмі Collaboration, на якому відображаються об'єкти системи. Rational Rose дозволяє створювати класи за допомогою даного типу діаграм у різних нотациях.

Рисунок 10. Діаграма класів.

Interaction diagram (діаграми взаємодії)

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

Collaboration diagram (діаграми співпраці)

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

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

Рисунок 8. Діаграма співпраці. 
 

Sequence diagram (діаграми послідовностей дій)

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

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

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

 

 

 

 

 

Рисунок 7. Діаграма послідовностей дій.

 

State Maсhine diagram (діаграмА станів)

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

Statechart diagram (діаграма станів)

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

Рисунок 3. Діаграма станів.

Activity diagram (діаграми активності)

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

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

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

Рисунок 4. Діаграма активності.

Deployment diagram (діаграмА топології)

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

Для кожної моделі створюється тільки одна така діаграма, що відображає процесори (Processor), пристрої (Device) та їх сполуки. 

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

Рисунок 2. Діаграма топологій.

Component diagram (діаграми компонентів)

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

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

Рисунок 11. Діаграма компонентів.

 

ВИСНОВОК

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

Головною перевагою використання програми Rational Rose є зворотне проектування, оскільки розробнику і проектувальнику важливо побачити перед змінами вже працюючу систему в нормальному графічному поданні. Як правило, візуально-графічний ряд надає куди більший вплив ніж гортання технічних завдань і програмних текстів. Тим більше, що проект, що піддався зворотного проектування, може бути доопрацьований і знову згенерований (а згодом і скомпільований). Rational Rose надає для цього всі необхідні засоби.