Подякувати Студентському архіву довільною сумою
Admin
26.02.2023 12:38
Дякуємо, що користуєтесь нашим архівом!
Інформація про навчальний заклад
ВУЗ:
Національний університет Львівська політехніка
Інститут:
Не вказано
Факультет:
Комп'ютерні науки
Кафедра:
Не вказано
Інформація про роботу
Рік:
2009
Тип роботи:
Інші
Предмет:
Інші
Частина тексту файла (без зображень, графіків і формул):
МІНІСТЕРСТВО ОСВІТИ ТА НАУКИ УКРАЇНИ
НАЦІОНАЛЬНИЙ УНІВЕРСИТЕТ “ЛЬВІВСЬКА ПОЛІТЕХНІКА”
Кафедра ПЗ
Взаємодія об’єктів: діаграми послідовності дій та кооперації в Rational Rose
Методичні матеріали
до лабораторної роботи № 6 з курсу:
“Основи проектування інформаційних систем”
для студентів базового напрямку
6.0804 “Комп’ютерні науки”
ЗАТВЕРДЖЕНО
на засіданні кафедри
“Програмне забезпечення”
Протокол №
від
ЛЬВІВ 2009
Взаємодія об’єктів: діаграми послідовності дій та кооперації в Rational Rose. Методичні матеріали до лабораторної роботи № 6 з курсу: “ Основи проектування інформаційних систем ” для студентів базового напрямку 6.0804 “Комп’ю тер ні науки”.
Укладачі:
Макар В.М., доцент, к.т.н.
Муха Т.О., асистент.
Відповідальний за випуск:
Рецензенти:
1. МЕТА РОБОТИ
Ознайомитися з основними поняттями, які використовуються для опису взаємодії між об’єктами в рамках заданого прецеденту (варіанту використання). Ознайомитися з основними принципами і прийомами побудови діаграм послідовності дій та діаграм кооперації за допомогою програмного засобу Rational Rose. Навчитися застосовувати на практиці знання таких понять як сценарій прецеденту, повідомлення та об’єкт.
2.ОСНОВНІ ТЕОРЕТИЧНІ ВІДОМОСТІ
2.1 Постановка модельної задачі
Основним прикладом, що буде розглядатися є реєстрація курсів в університеті ESU (Eastern State University). Після того, як викладачі ESU вирішать, які курси вони будуть вести протягом семестру, служба реєстрації курсів введе інформацію в комп’ютерну систему. Потім для викладачів видрукують сумарний звіт по курсах, які вони читатимуть, а для студентів – каталог курсів.
На цьому етапі студенти заповнюють спеціальну реєстраційну форму, де вказують вибрані курси і віддають її в службу реєстрації. Зазвичай студент підписується на чотири курси, після чого інформація заноситься в комп’ютер. Після цього запускається нічна пакетна програма, яка розподіляє студентів по курсах. При виникненні конфліктної ситуації служба реєстрації уточнює дані студента. Після вдалого розподілення студенту висилається розклад для провірки. Зазвичай, процес реєстрації на курси займає близько тижня, проте в ряді випадків може бути потрібно до двох тижнів, щоб залагодити всі питання. Після цього викладачі отримують список студентів для кожного курсу, який вони будуть читати.
Постановка задачі реєстрації курсів:
На початку кожного семестру студенти можуть запросити каталог курсів, в який включений список предметів, навчання по яких пропонується в даному семестрі. Інформація про курси повинна містити прізвище викладача, назву факультету і короткий опис, який допоможе студентам зробити вибір.
Нова система дозволить студенту здійснити вибір чотирьох курсів, із тих що пропонуються в наступаючому семестрі. Крім того студенту потрібно вказати ще два варіанта на випадок якщо курс буде відмінений або переповнений. На курс не повинно бути записано більше десяти і менше трьох студентів. Курс, на який запишеться менше трьох студентів буде відмінений. Після закінчення реєстрації система реєстрації направляє інформацію в систему оплати для виставлення рахунків студентам.
Викладачі повинні мати можливість он-лайнового доступу до системи для вказання курсів, які вони будуть читати, і для перегляду списку студентів, що записалися. В кожному семестрі виділяється визначений час, протягом якого студенти можуть міняти свій розклад і отримувати доступ до системи для додавання і видалення вибраних курсів.
2.2. Сценарії прецедентів та їх документування
Діаграми варіантів використання описують зовнішній вигляд системи. Виконання прецедентів відображається за допомогою потоку подій. А для опису того, як, шляхом взаємодії між об’єктами, реалізуються прецеденти використовуються сценарії.
Сценарій (scenario) – це елемент прецедента, який являє собою одиничний прохід потоком подій для варіанта використання. Сценарії допомагають виділити об’єкти, класи та взаємодії між ними, які є необхідни ми для виконання одиничної дії заданої прецедентом. Сценарії описують порядок розподілу обов’язків прецеденту між класами та об’єктами системи. Якщо потік подій для випадку використання описується словесно, то сценарії зображаються графічно у вигляді діаграм взаємодій (interaction diagrams). Існує два типи діаграм взаємодій:
діаграми послідовності дій (sequence diagrams), які відображають порядковану в часі послідовність подій (повідомлень) в рамках заданого варіанту використання;
діаграми кооперації (collaboration diagrams), які дають загальну картину сценарію шляхом відображення взаємодії між пов’я за ни ми один з одним об’єктами.
2.3. Діаграма послідовності дій
Діаграма послідовності дій відображає впорядковану в часі взає мо дію між об’єктами. Даний тип діаграми UML містить об’єкти і класи, які вико рис товуються в сценарії, разом з послідовністю повідомлень, якими обміню ють ся об’єкти для виконання сценарію. Об’єкт на діаграмі послідовності дій в мові UML зображається у вигляді прямокутника, а його назва пишеться з підкресленням. Назва об’єкту може складатися тільки з імені об’єкту, з імен об’єкту і його класу та тільки з імені класу (анонімний об’єкт) (див. рис.1). Анонімний об’єкт використовується для представлення довільного об’єкту даного класу.
Кожний об’єкт має свою часову лінію (timeline), яка зображаться пунктиром під самим об’єктом. Повідомлення, що передаються між об’єкта ми позначаються лініями з стрілкою в напрямку від клієнта (відправника повідомлення) до споживача (отримувача повідомлення). Повідомлення – це засіб, за допомогою якого клієнт робить запит до споживача на виконання певної його операції. Розрізняють інформаційні (informative), імперативні (imperative) повідомлення та повідомлення-запити (interrogative).
Рис.1. Нотація мови UML для об’єкту
Інформаційні повідомлення – це повідомлення за допомогою яких об’єкт-споживач отримує інформацію необхідну йому для зміни його стану.
Імперативні повідомлення – це повідомлення, які вказують об’єкту-отримувачу на виконання певних операцій.
Повідомлення-запити – це повідомлення призначені для запиту певної інформації про об’єкт-отримувач повідомлення.
Можливі також випадки, коли об’єкт посилає повідомлення самому собі, які називаються самоделегуванням (self-delegation). В таких випадках стрілка повідомлення вказує на timeline самого об’єкту. Також, можна, при потребі додавати аргументи та деяку керуючу інформацію для повідомлень.
Створити нову діаграму послідовності дій в програмі Rational Rose можна за допомогою команди New→Sequence Diagram з контекстно-залеж ного меню розділу Logical View (Логічне представлення) у вікні броузера.
Для створення об’єктів та повідомлень на діаграмі послідовності дій в Rational Rose потрібно виконати такі кроки:
Відкрити вікно діаграми двічі клікнувши по ній у вікні броузера проекту.
Вибрати потрібного актора зі списку в представленні Use Case.
Перетягнути актора на діаграму послідовності дій.
За допомогою кнопки Object на панелі інструментів створити на діаграмі новий об’єкт з потрібною назвою.
Повторити кроки 1-4 для всіх акторів та об’єктів, які беруть участь в заданому сценарію.
За допомогою кнопки Object Message на панелі інструментів створити нове повідомлення між клієнтом та споживачем та надати змістовну назву цьому повідомленню.
Повторити крок 6 для усіх потрібних повідомлень.
Приклад діаграми послідовності дій для сценарію створення навчального предмету зображено на рис.2.
Рис.2. Приклад діаграми послідовності дій
Для того щоб присвоїти об’єкту відповідний клас достатньо просто перетягнути потрібний клас з вікна броузера на об’єкт на діаграмі послідовності дій. Програма Rational Rose автоматично додасть до назви об’єкту ім’я класу, а якщо об’єкт не має імені, то назва об’єкту буде складатися лише з імені класу. Якщо клас має певний стереотип, то значок цього стереотипу буде використаний також і для зображення об’єкту на діаграмі послідовності дій. Діаграму послідовності дій з об’єктом предмет, якому присвоєно клас Предмет зображено на рис.2.
Рис.3. Діаграми послідовності дій з об’єктом, якому присвоєно клас
2.4. Діаграма кооперації
Діаграма кооперації (collaboration diagrams) – це альтернативний спосіб зображення сценаріїв. Вона також показує взаємодію об’єктів, але концентрує увагу на відношеннях між об’єктами в процесі цієї взаємодії. Діаграма кооперації містить:
об’єкти у вигляді прямокутників;
зв’язки між об’єктами, зображені у вигляді ліній;
повідомлення між об’єктами у вигляді стрілки та тексту направленої від клієнта до споживача.
На діаграмі кооперації представлена та ж інформація, що і на діаграмі послідовності дій, але вона по-іншому описує потік подій сценарія. З неї легше зрозуміти відношення між об’єктами, але важче вияснити послідов ність, в якій виконуються події.
Діаграма кооперації створюється на основі діаграми послідовності дій. Для цього потрібно відкрити вже створену діаграму послідовності дій і вибрати команду Browse→Create collaboration diagram з головного меню або натиснути клавішу F5. При необхідності, для покращення читабельності, можна розташувати об’єкти та повідомлення на створеній діаграмі кооперації так як потрібно. Виконавши вказані дії, діаграму послідовності дій з рис.3 можна перетворити на відповідну діаграму кооперації, яка зображена на рис.4.
Рис.4. Діаграма кооперації для сценарію створення навчального предмету
Можна спочатку створити діаграму кооперації, і потім на її основі, відповідно за допомогою команди Browse→Create sequence diagram з головного меню, створити діаграму послідовності дій.
Таким чином, діаграми послідовності дій та діаграми кооперації є ізоморфними та взаємозамінними. Логічно може виникнути питання: для чого потрібні дві різні діаграми, які, по суті, служать одній і тій же меті? Справа в тому, що, по-перше, вони хоч і відображають одну і ту ж інформацію, але з різних точок зору. А, по-друге, діаграми послідовності дій використовуються в основному на стадії аналізу, коли важливо зрозуміти що відбувається спочатку, а що пізніше, тоді як діаграми кооперації особливо корисні на стадії проектування коли планується реалізація відношень між об’єктами, що взаємодіють між собою.
Розглянемо інший приклад, а саме випадок використання додавання навчального курсу. Реалізація цього прецеденту вимагає використання таких об’єктів: Викладач, Параметри курсу викладача, Додавання навчального курсу, Менеджер курсів викладача, Предмет та Навчальний курс. Опис взаємодії цих об’єктів можна здійснити за допомогою діаграми послідовності дій, яка зображена на рис.5.
Рис.5. Діаграми послідовності дій для сценарію прецедента додавання навчального курсу
3.КОНТРОЛЬНІ ЗАПИТАННЯ
Що таке сценарій?
Для чого призначені діаграми взаємодій?
Які види діаграм взаємодій Ви знаєте?
Для чого призначена діаграма послідовності дій?
Для чого призначена діаграма кооперації? Чим вона відрізняється від діаграми послідовності дій?
Що таке повідомлення? Як вони відображаються на діаграмах взаємодії?
Чи є діаграми послідовності дій та діаграми кооперації ізоморфними? Чому?
Як створити діаграму послідовності дій в Rational Rose?
4.ЛАБОРАТОРНЕ ЗАВДАННЯ
Ознайомитися з теоретичними відомостями.
Провести аналіз завдання (індивідуальні завдання наведені в Додатку). Визначити два прецеденти опис яких буде проводитися за допомогою сценарія.
Побудувати діаграми послідовності дій та кооперації для вибраних варіантів використання.
Оформити і здати звіт про виконання лабораторної роботи.
5.ЗМІСТ ЗВІТУ
Мета роботи.
Короткі теоретичні відомості.
Постановка задачі індивідуального завдання.
Оформлені належним чином (з коментарями та поясненнями) варіанти використання та їх сценарії, а також відповідні діаграми послідовності дій та кооперації.
Аналіз результатів та висновки.
6.СПИСОК РЕКОМЕНДОВАНОЇ ЛІТЕРАТУРИ
Т.Кватрани. Rational Rose 2000 и UML. Визуальное моделирование.- М.: ДМК Пресс, 2001. - 176 с.
С.А. Трофимов. Case-технологии: практическая робота в Rational Rose. Изд. 2-е. – М.: Бином-Пресс, 2002. – 288 с.
http://www.intuit.ru/department/se/ibmrrose/3/1.html
ДОДАТОК
1. Інформаційна система автоматизації роботи лікарняного закладу. Лікар має можливість проглянути лікарняну картку конкретного пацієнта і добавити туди дані. Лікар може направити пацієнта для вияснення діагнозу на аналізи, результати яких повинні бути видані лікареві. Пацієнт має можливість проглянути розклад прийому лікарів.
2. Інформаційна система фірми, яка займається торгівлею. Система повинна розрізняти великий гурт, дрібно гуртових і роздрібних покупців. Замовник має мати можливість проглянути наявність товарів і їх ціни. В системі повинні реєструватися поступлення товарів і продаж товарів. Система має давати можливість менеджеру фірми перевірити наявність товару і замовити його у відділу постачання, якщо його немає. Система має видавати інформацію касиру про те, яка ціна на даний товар.
3. Інформаційна система бібліотеки університету. В системі повинен бути організований доступ для читачів до електронних каталогів. Для студентів і працівників університету повинен бути доступним і електронний варіант текстів книг. Читачі бібліотеки повинні мати змогу оформити за допомогою системи замовлення на книгу. Система повинна вести облік книг виданих в читальний зал і на абонемент.
4. Інформаційна система автомобільного салону. Покупець повинен мати змогу переглянути каталог автомобілів, що продаються, і їх характеристики. Менеджер повинен мати інформацію про наявність відповідних автомобілів і можливість їх замовити у постачальника. Салон повинен надавати гарантійне сервісне обслуговування автомобілям, купленим у них. Страхова компанія оформляє страховку для купленого автомобіля.
5. Система зрошування поля. Після збору інформації про температуру, вологість, швидкість вітру, робиться аналіз і визначається кількість води, яка повинна бути подана для зрошення зрошувальною системою. Для кожного виду рослин повинен бути визначений відповідний режим зрошування агрономом.
6. Інформаційна система зоопарку. Система постачання по замовленню системи контролю повинна постачати відповідну кількість корму для тварин. Адміністрація зоопарку може придбати або продати ту чи іншу тварину. Система контролю повинна вести облік тварин, контролювати стан їхнього здоров’я. Вразі захворювання повинен бути викликаний ветеринар, який лікуватиме тварину.
7. Інформаційна система житлового будинку. Адміністрація будинку повинна вести облік людей, що проживають у будинку, а також висилати рахунок і отримувати кошти за послуги від тих, хто проживає у будинку. В разі виникнення поломок, адміністрація повинна викликати майстрів, які б усунули поломку. Майстри отримають гроші за роботу від адміністрації. Ті хто проживають у будинку повинні інформувати адміністрацію про поломки.
8. Інформаційна система обліку працівників заводу. Адміністрація повинна мати можливість переглядати результати роботи робітників. Повинна мати можливість звільняти і набирати на роботу робітників. Адміністрація отримує зарплату від відділу бухгалтерії. Робітники теж отримують зарплату. Адміністрація може давати вказівки бухгалтерії преміювати тих чи інших робітників. Робітник може звільнитися з роботи написавши заяву у відділі кадрів.
9. Інформаційна система редакції газети. Повинна зберігатися інформація про видані газети. Не видані газети спочатку подаються у відділ редагування, де вони редагуються. Матеріали отримуються від журналістів і від дописувачів. Журналісти отримують зарплату, дописувачі ні. Газета після редагування подається на друк у видавництво.
10. Інформаційна система банку. Банк надає кредити фізичним і юридичним особам. Система повинна відслідковувати і інформувати банк про тих, хто не сплатив у відповідний термін місячної плати за кредит. Клієнти мають мати можливість переглянути стан свого рахунку, зняти з нього кошти, або покласти кошти на рахунок. Банк подає в суд, якщо боржник не сплачує кредиту у відповідні терміни.
11. Інформаційна система реєстрації автомобілів та дорожнього руху ДАІ. Система повинна дозволяти вести як облік транспортних засобів, так дані про порушників, ДТП, водіїв і т.д.
12. Інформаційна система аеропорту. Пасажир має мати можливість переглянути розклад рейсів і ціну квитка. Він має мати можливість замовити і оплатити квиток. В систему реєстрації аеропорту має поступати інформація про польоти і екіпаж і вона має формувати розклад польотів. Для кожного літака повинен бути список членів екіпажу. Для кожного рейсу повинна бути можливість перевірити наявність непроданих квитків і їх кількість та місця.
13. Інформаційна система автоматизованого укладання розкладу учбового закладу. Викладачі подають інформацію про предмети, які вони будуть читати. Кафедри подають інформацію про те, які аудиторії і скільки аудиторій в них є, і які групи закріплені за кафедрою. Повинна бути можливість переглянути розклад для конкретної групи. Повинна бути можливість переглянути список пар для конкретних викладачів. З вхідної інформації повинен бути сформований розклад. Повинна бути можливість корегувати розклад, а також отримати список пар (група, дисципліна, дата, час) для конкретної аудиторії.
14. Інформаційна система обліку поселень та бронювань у готелі. Клієнт готелю має мати змогу переглянути список вільних номерів і їх характеристики, теж повинен мати змогу забронювати місце на відповідне число, якщо номер вільний, та замовити список послуг. Для конкретного номеру на конкретне число повинна відображатися ціна найму. Реєстратор повинен мати змогу проглянути таблицю вільних місць на відповідне число. Також він повинен мати змогу забронювати відповідне місце, або здійснити поселення у відповідний номер. Система обслуговування (ресторан, та інші служби) повинні отримувати інформацію про те, які послуги замовлені, і в якому номері зупинився замовник.
15. Інформаційна система для автоматизації діяльності фірми-ріелтора. Для клієнта повинна бути можливість проглянути інформацію про квартири, що продаються чи здаються в оренду. Для працівника фірми повинна бути доступна контактна інформація власника, та ціна тої чи іншої квартири або її оренди. Для квартир, які здаються в оренду, повинен бути орієнтовний час, на який здається квартира. Повинна бути змога отримати квартири за ціною на них.
16. Інформаційна система для апарату поповнення рахунку. Користувач повинен мати можливість подати в апарат суму, на яку він хоче поповнити рахунок, обрати оператора зв’язку і ввести свій номер. Система поповнення рахунку повинна перерахувати гроші відповідному оператору зв’язку. Система поповнення рахунку повинна видати клієнту чек – підтвердження поповнення рахунку.
17. Інформаційна система обліку абонентів оператора мобільного зв’язку. Абонент має мати можливість здійснювати розмови, відсилати СМС, ММС, а система оплати повинна тарифікувати дзвінки і знімати з рахунку кошти. Абонент має мати змогу поповнити рахунок. Оператор забороняє здійснення вихідних дзвінків, якщо система оплати повідомляє його про те, що в абонента недостатньо грошей. Оператор повідомляє абонента про малу суму коштів на рахунку, якщо сума на рахунку менша зазначеного значення. Інформація про абонентів повинна зберігатися (зокрема номер абонента і сума на рахунку).
18. Інформаційна система підприємства постачання води. Система обліку користувачів отримує, зберігає та подає в систему оплати інформацію про споживання води. Користувачі послугою, які мають лічильник повинні самі повідомляти покази лічильника в систему обліку користувачів. Для користувачів, які не мають лічильника система обліку направляє інформацію по стандартному тарифу, відповідно до кількості проживаючих, у відділ оплати. Відділ оплати згідно з інформацією, яка подається відділом обліку, направляє рахунки на оплату користувачам з лічильником та без лічильника. Користувачі повинні здійснити оплату. Користувачі повідомляють систему обслуговування про поломки мережі водопостачання. Система обслуговування повинна усунути несправність і повідомити про це відділ обліку.
19. Інформаційна система тролейбусного парку. Служба відповідальна за встановлення графіку руху повинна отримувати інформацію від завідуючого рухомим складом про кількість тролейбусів. На основі інформації про кількість тролейбусів та інформації про маршрут (вважається що вона відома) встановити графік руху тролейбусів. Кожен водій повинен отримати графік роботи від служби відповідальної за розклад руху. Повинна бути можливість отримати графік руху і водіїв для конкретного тролейбуса в конкретний день. Служба відповідальна за ремонт повинна бути проінформована в разі поломки.
20. Інформаційна система форуму. Адміністратор керує правами користувачів форуму. Він може блокувати користувачів, які шкодять роботі форуму. Він повинен мати змогу отримати графік відвідуваності форуму його користувачами, має права для зміни і видалення повідомлень і тем. Система повинна реєструвати нових користувачів. Модератори теж мають права на редагування повідомлень і їх видалення. Звичайні користувачі можуть лише створювати повідомлення і теми, але не можуть редагувати повідомлення, крім своїх повідомлень.
21. Інформаційна система обліку користувачів провайдера Інтернету. Для доступу в Інтернет є три різних тарифних плани на трьох різних швидкостях. Система по логіну користувача повинна визначати, який тарифний план він замовив і відповідно до того провайдер надає йому доступ на замовленій швидкості. Система повинна реагувати на те, чи заплатив за послугу той чи інший користувач. Для того повинен бути перевірено чи приходили перерахування від цього користувача. Якщо він не заплатив за послугу, то доступ повинен бути заблокований.
22. Інформаційна система електронного телефонного довідника. Система повинна зберігати інформацію про адреси та телефони фізичних та юридичних осіб. Користувач повинен мати змогу отримати інформацію по запиту по адресі, по прізвищі, імені, по-батькові. Адміністратор повинен мати можливість вносити зміни, якщо міняється адреса, чи телефон тої чи іншої особи, додати новий запис до бази даних при появі нового абонента з новим номером. Система повинна надавати змогу користувачам інформувати адміністратора при знайденні ними помилки в даних системи.
23. Інформаційна система комп’ютерної системи кафедри. До системи повинні мати доступ студенти та викладачі, та інженери з різними правами (абстрагуватимемся та не будемо уточнювати), які надає адміністратор. При порушенні правил користувачами адміністратор має право їх заблокувати. Адміністратор повинен мати змогу переглянути дані про те хто, на якому комп’ютері і коли заходив у систему. Адміністратор має змогу створити новий обліковий запис для нового користувача.
24. Інформаційна система торгової фірми. Служба постачання вносить інформацію про прибуття товару і його кількість. Менеджер має можливість замовляти товар і переглядати його наявність і кількість на складі. Торговий агент повинен мати можливість доступатися до інформації про наявність і кількість товару на складі і відправляти замовлення на постачання в службу дистрибуції. Дистрибуція повинна мати можливість переглядати інформацію про замовлення, що поступили і виконувати доставку товару.
25. Інформаційна система підтримання мікроклімату в приміщенні. Значення температури та відносної вологості в приміщенні поступає з відповідних датчиків. Користувач системи має змогу встановити значення температури та відносної вологості, які потрібно підтримувати. Система проаналізувавши дані дає команду пристроям, які керують відносною вологістю та температурою.
26. Інформаційна система обліку використаної електроенергії. Відділ збору показів лічильників збирає і вносить інформацію про покази лічильників користувачів послугою. Система зберігає інформацію про тарифікацію світла та пільги користувачів. Відповідно до тарифів нараховується плата за електроенергію, яка направляється в фінансовий відділ. Фінансовий відділ відслідковує злісних боржників і направляє інформацію про них у відділ, який займається відключенням злісних боржників. Відділ контролю здійснює контроль за несанкціонованим підключенням до електромережі і вносить в систему дані про порушників. Ця інформація надходить у відділ, який займається відключенням, який відключає цих користувачів.
27. Інформаційна система торгової фірми. Служба постачання вносить інформацію про отриманий товар. Менеджер повинен мати можливість переглянути інформацію про наявність і кількість товару і здійснити замовлення. При здійсненні замовлення інформація про замовлення повинна поступати в бухгалтерію і бухгалтерія повинна оплатити замовлення. При відсутності коштів бухгалтерія може відмінити замовлення. Бухгалтерія повинна мати можливість переглянути неоплачені замовлення, які зробив менеджер. Товар продається безпосередньо на фірмі через касу, де оператори продають товар при цьому система відзначає відповідну кількість як продану. Оператор повинен мати змогу переглянути наявність товару і його кількість.
Ділись своїми роботами та отримуй миттєві бонуси!
0%
Оголошення від адміністратора