Розробка UML-моделі інформаційної системи 'Овочева база'
Зміст
Вступ
1. Загальна частина. проектування автоматизованої
інформаційної системи
1.1 Опис предметної області
.2 Проблеми предметної області та пропозиції щодо
автоматизації інформаційної системи
1.2.1 Опис проблем предметної області
1.2.2 Функціональні вимоги
1.2.3 Нефункціональні вимоги
2. Спеціальна частина. Розробка канонічних uml-діаграм
автоматизованої інформаційної системи у середовищі case-засобу
2.1 Концептуальна модель предметної області
2.1.1 Діаграма прецедентів
.1.2 Діаграма станів
.1.3 Діаграма класів
2.2 Логічна модель предметної області
2.2.1 Діаграма діяльності
2.2.2 Діаграма послідовності
2.2.3 Діаграма кооперації
2.3 Фізична
модель предметної області
.3.1 Діаграма класів
2.3.2 Діаграма компонентів
2.3.3 Діаграма розгортання
2.4 Реалізація моделі в середовищі CASE-засобу
.5 Реалізація моделі в середовищі CASE-засобу
Висновки
Перелік посилань
Додаток
Вступ
Ця курсова робота присвячена питанням. Подібна технологія набуває все більшого поширення при створенні
сучасного програмного забезпечення. Підходи і методи, які використовуються на
різних етапах створення об'єктно-орієнтованих систем і є предметом обговорення
в даному посібнику. Основна увага приділяється початковим етапам розробки:
постановці завдання, формалізації предметної області, проектування структури
систем з використанням об'єктно-орієнтованої методолгіі. Розглядаються питання
застосування об'єктів-орієнтованого аналізу, проектування, викладаються основи
універсальної мови моделювання UML. Також наводиться інформація про тестування
об'єктно-орієнтованих систем та огляд інструментальних засобів розробки.
Посібник містить приклади практичного використання даних методологій.
Сучасні CASE-засоби охоплюють велику область підтримки
численних технологій проектування ІС: від простих засобів аналізу і
документування до повномасштабних засобів автоматизації, що покривають весь
життєвий цикл. Найбільш трудомісткими етапами розробки ІС є етапи аналізу та
проектування, у процесі яких CASE-засоби забезпечують якість прийнятих
технічних рішень та підготовку проектної документації. При цьому велику роль
відіграють методи візуального представлення інформації. Це передбачає побудову
структурних чи інших діаграм у реальному масштабі часу, використання різній
кольорової палітри, наскрізну перевірку синтаксичних правил. Графічні засоби
моделювання предметної області дозволяють розробникам в наочному вигляді
вивчати існуючу ІВ, перебудовувати їх у відповідність з поставленими цілями та
наявними обмеженнями.
У розряд CASE-засобів потрапляють як відносно дешеві системи
для персональних комп'ютерів з дуже обмеженими можливостями, так і дорогі
системи для неоднорідних обчислювальних платформ і операційних середовищ. UML -
уніфікована мова моделювання для опису, візуалізації та документування
об'єктно-орієнтованих систем і бізнес-процесів в ході розробки програмних
додатків. Докладно описуються базові поняття UML, необхідні для побудови
об'єктно-орієнтованої моделі системи з використанням графічної нотації. Виклад
супроводжується прикладами розробки окремих діаграм, які необхідні для подання
інформаційної моделі системи. Мета електронної книги - допомогти програмістам
освоїти нову методологію розробки корпоративних програмних додатків для
подальшого застосування отриманих знань з використанням відповідних CASE-інструментів.
Якщо спробувати охарактеризувати сучасний рівень розвитку комп'ютерних та
інформаційних технологій, то перше, на що слід звернути увагу - це зростаюча
складність не тільки окремих фізичних та програмних компонентів, але і лежать в
основі цих технологій концепцій та ідей. Здається, ще зовсім недавно
професійному програмістові було достатньо досконало володіти однією-двома
мовами програмування, щоб розробляти серйозні програмні додатки. Вибір
платформи та операційної системи, як правило, не був серйозною проблемою. А
супровід програми, хоча і було пов'язане з об'єктивними труднощами, могло бути
реалізовано простим додаванням або зміною коду вихідної програми.
Представлена курсова робота з теми "Розробка UML-моделі
інформаційної системи "Овочева база"" розглядає процес створення програмного продукту від задуму
до виконуваного коду. Для розробки використовуються UML-діаграми, які
побудовані за допомогою популярного CASE-засобу StarUML.
1. Загальна частина. Проектування автоматизованої
інформаційної системи
1.1
Опис предметної області
Метою даної курсової роботи є розробка моделі програми,
призначеної для автоматизації роботи овочевої бази, яка дозволить значно
підвищити продуктивність праці за рахунок автоматизації функцій, які раніше
виконувалися вручну.
У проектуванні використовується мова UML. Система призначена для
підтримки роботи
невеликої
овочевої бази, основним видом діяльності якого є продаж та закупівля продуктів
(овочів). Так як на базі вибір овочів досить широкий, то часто дуже важко вручну, розглядаючи вітрини або вивчаючи каталоги, знайти порідний продукт, внести інформацію про новоприбулих клієнтів.
· Дозволяє автоматизувати замовлення;
· Формує довідники необхідні для
роботи: з замовником, постачальником, товаром (продуктами);
· Дозволяє автоматизувати створення
документації підприємства;
· Автоматизує складський облік.
.2 Проблеми
предметної області та пропозиції щодо автоматизації інформаційної системи
1.2.1
Опис проблем предметної
області
Процес створення автоматизованих інформаційних систем (далі,
АІС) Овочевої Бази - це сукупність робіт, що починаються формуванням вхідних
вимог до цієї системи, а закінчуються введенням її в дію. Такий процес
передбачає або способи індивідуального розроблення проектної документації, або
способи індустріального розроблення із застосуванням засобів автоматизованого
проектування. Сучасні засоби автоматизованого проектування поділяються на два
типи:
v такі, що базуються на методах
типового проектування;
v такі, що базуються на методах
модельного проектування;
У свою чергу, типове проектування передбачає застосування
типових проектних рішень (ТПР), пакетів прикладних програм (ППП) або
орієнтоване на об'єкт проектування в цілому. ТПР і ППП будуються за
компонентами, а об'єктний підхід охоплює всю систему, тобто АІС овочевої бази.
При типовому проектуванні постає потреба пристосовувати
("прив'язувати") ТПР або ППП до конкретного об'єкта управління. Такий
спосіб організації АІС дає змогу створювати уніфіковані елементи АІС і
мінімізувати витрати на них. При створенні комп'ютерних інформаційних систем
обліку, як правило, використовуються методи типового проектування.
1.2.2 Функціональні вимоги
Метою створення АІС овочевої бази є вдосконалення системи
бухгалтерського обліку на конкретному економічному об'єкті завдяки застосуванню
засобів обчислювальної техніки.
Проектування АІС овочевої бази - тривалий, трудомісткий і
динамічний процес, в якому на різних етапах беруть участь фахівці різних
напрямків і кваліфікації. Одним із головних завдань
управління розробленням є чіткий поділ і координація робіт за групами фахівців
у часі для успішного закінчення проектних робіт у директивне встановлені
терміни.
Організації, причетні до створення комп'ютерних інформаційних
систем овочевої бази, за своїми юридичними повноваженнями поділяються на дві
категорії: замовники і виконавці. Замовником може бути кожна господарська
організація, що потребує розроблення і впровадження АІС. Виконавцями, як
правило, є спеціалізовані проектні організації (науково-дослідні та проектні інститути,
проектні бюро і т. ін.), пов'язані із замовником договірними зобов'язаннями.
Процес створення комп'ютерної інформаційної системи овочевої
бази являє собою сукупність упорядкованих у часі, взаємопов'язаних, об'єднаних
у стадії та етапи робіт, виконати які необхідно і достатньо для створення АІС.
1.2.3
Нефункціональні вимоги
1 Зручність використання − інтерфейс користувача
повинен бути Windows-сумісним.
Надійність − система повинна бути в
працездатному стані двадцять чотири години на добу сім днів на тиждень, час
простою − не більше десяти процентів.
Продуктивність − система повинна підтримувати
можливість подальшого поєднання з технологічним обладнанням, яке
використовується у приймальні та на складі.
Безпека − система повинна дозволяти працівникам
корегувати інформацію лише в межах своєї компетентності шляхом встановлення
паролів щодо запобігання розголошення комерційної таємниці.
Проектні обмеження:
o система не містить розрахунку фонду
заробітної плати в повному обсязі;
o система не враховує механізми
оподаткування;
o система не враховує вартість
упаковки;
2. Спеціальна
частина. Розробка канонічних
uml-діаграм автоматизованої інформаційної системи у середовищі case-засобу
2.1 Концептуальна модель предметної
області
Візуальне моделювання в UML можна представити як деякий
процес ступеневого спуску від найбільш загальній і абстрактній концептуальної
моделі вихідної системи до логічної, а потім і до фізичної моделі відповідної
інформаційної системи. Для досягнення цих цілей з автоматизації Овочевої бази,
спочатку будується модель у формі діаграми прецедентів тобто варіантів
використання, яка описує функціональне призначення системи або, іншими словами,
те, що система буде робити в процесі свого функціонування.
Таким чином, діаграма варіантів використання є вихідним
концептуальним уявленням або концептуальною моделлю системи в процесі її
проектування і розробки.
Далі слід врахувати, що кожен прецедент системи має певну
поведінку, може знаходитись в певних станах, а також переходити з одного стану
в інший. Тобто, він моделює всі зміни станів певного варіанту використання як
його реакцію на зовнішні впливи.
В разі чого, для специфікації функціональності прецеденту, що
має складну модель поведінки, програмну систему з автоматизації
ремонтно-будівельної компанії представляється з точки зору теорії кінцевих
автоматів, тобто у формі діаграми станів.
2.1.1 Діаграма прецедентів
У результаті аналізу вимог виділяються такі актори:
"Замовник":
· Замовляє товар на складі;
2 "Працівник складського приміщення":
· Стежить за товаром (продуктами) на складі;
· Стежить за місцями на складі та
товаром в них;
· Відповідає за строки зберігання
товару та зміни їх у разі необхідності;
"Знищувач"
· Стежить за товаром, який буде знищено або знищується;
4 "Постачальник"
· Постачає продукти (товар) на овочеву базу;
5 "Секретар"
· Формує катового асортименту товару и редагує його;
6 "Бухгалтер"
· Стежить за фінансами підприємства та їх своєчасний
прихід;
· Формує знижки;
Виходячи з потреб дійових осіб, виділяються наступні варіанти
використання з переліком специфікацій:
"Складське приміщення":
· Короткий опис - приміщення, де
зберігається товари;
· Основний потік подій - починає
виконуватись, коли товар приходить на склад;
· Альтернативні потоки - відсутні.
· Передумови - передбачає наявність
товару, місця де його будуть зберігати та слідкувати за його станом.
2 Постумови - при успішному виконанні товар відправляють
до замовника. Інакше товар буде знищено.
3 "Замовлення":
· Короткий опис - замовляння товару;
· Основний потік подій - починає
виконуватись коли проходить замовник;
· Альтернативні потоки - відсутній.
· Передумови - Прихід замовника.
· Постумови - при успішному виконанні
замовник отримує товар в своє повне розпорядження.
4 "Товар":
· Короткий опис - товар який повинен
прийти на склад;
· Основний потік подій - починає
виконуватись коли організація замовляє у постачальника, при цьому беручи дані
про товар із асортименту постачальника.
· Альтернативні потоки - відсутній.
· Передумови - коли із сформованих
довідників Списку постачальників та довідника Асортименту закуплених товарів
надійдуть дані;
· Постумови - при успішному виконанні
закуплені товари відправляють на склад;
5 "Асортимент":
· Короткий опис - довідник в якому
зберігається інформація про товар який є у постачальників. Ці товари можуть
бути закуплені на даний період;
· Основний потік подій - від
постачальника, який знаходиться у списку постачальників з якими організація
веде справи надходить інформація:
які товари можуть надати.(формується довідник з товарами які
можна закупити на даний проміжок часу)
· Альтернативні потоки -відсутні;
· Передумови - формується на підставі
каталогу постачальників товарів.
· Постумови - при успішному виконанні
передасть дані про товар який можна закупити в результаті чого товар буде
закуплений.
6 "Термін зберігання":
· Короткий опис - Містить дані про
товар: стан та час зберігання на складі;
· Основний потік подій - формується
довідник про товар.
· Альтернативні потоки - відсутні.
· Передумови - немає;
· Постумови - при успішному виконанні
передає дані про зберігання товару та час його зберігання;
7 "Бухгалтерія":
· Короткий опис - Містить дані про
рахунки клієнтів, виплату за товар, кредитні рахунки;
· Основний потік подій - формується
довідник про грошові операції на підприємстві.
· Альтернативні потоки - відсутні.
· Передумови - передбачає наявність
замовлення.
· Постумови -немає;
8 "Знижки":
· Короткий опис - Містить дані про
знижки які будуть представленні постійним клієнтам;
· Основний потік подій - формується
довідник про знижки які підприємство буде давати своїм постійним клієнтам.
· Альтернативні потоки - відсутні.
· Передумови - немає;
· Постумови - при успішному виконанні
передає замовник отримує знижки.
9 "місце":
· Короткий опис - Містить дані про
зберігання товару його стан та спосіб зберігання;
· Основний потік подій - формується
довідник про товар який на даний момент зберігається на складі.
· Альтернативні потоки - відсутні.
· Передумови - немає;
· Постумови - при успішному виконанні
передає на склад характеристику товару та місце його перебування.
10 "Акт списання":
· Короткий опис - Довідник, який
містить дані про товар, що не відповідає стандартам або терміну зберігання.
· Основний потік подій - відсутній.
· Альтернативні потоки - товар який не
відповідає стандартам якості підлягає знищенню.
· Передумови - формується довідник про
товар який був знищений;
· Постумови - при успішному виконанні
товар знищується
та передається
документ про витрати в бухгалтерію.
Поведінка акторів і прецедентів системи відображаються їх відносинами,
які показані на рисунку 2.1.
Діаграма прецедентів. Рисунок 2.1
2.1.2 Діаграма станів
Діаграма станів на концептуальному рівні дозволяє описувати
можливі послідовності станів і переходів окремого прецеденту, які
характеризують його динамічну поведінку. Тому, в рамках завдання автоматизації
овочевої бази, виділяються прецеденти, що володіють неоднозначною поведінкою.
Діаграма стану. Рисунок 2.2
Спочатку йде пошук товарів на складі. При знаходженні товар
рахується і порівнюється з початковими
даними. Якщо дані не співпадають, йде запит на його списання. Списаний товар
перевіряють при знаходженні недостачі програма йде на вихід. Якщо ні, запит
поступає в бухгалтерію, де витягуються дані про продажу товару при знаходженні
недостачі програма йде на вихід. Якщо по документам дані не співпадають
винуватця чекає догану або штраф на суму
недостачі.
2.1.3 Діаграма класів
На концептуальному рівні класи використовуються в процесі
аналізу предметної області для складання словника системи, що розробляється.
При розробці даної форми діаграми класів виникають наступні
основні завдання:
. Виділення класів і визначення їх внутрішньої
структури на основі аналізу функціональних вимог до автоматизованої системи.
. Встановлення взаємозв'язків між класами, що
забезпечують ефективність функціонування системи.
Замовник (zakazchik):
Ø FIO - містить дані про замовника: Прізвище Ім’я По-батькові.
Ø Telephone - містить дані які дозволяють
зв’язатися з замовником.
Ø C4e4ik - рахує кількість замовлень
зробленими цією людиною при наявності n-ї кількості замовлень пререводиться із
замовника в постійні клієнти.
Бухгалтерія(bugalteria):
Ø Oplata - Містить дані про нарахування
грошей за надані послуги.
Ø data oplaty - дата оплати товару
Замовлення (zakaz):
Ø 4yslo- дата прийому замовлення.
Ø Number - номер замовлення.
Ø Stoimost - Ціна замовлення.
Ø vypla4eno - Скільки грошей переказано
на рахунок бази.
Строка замовлення (stroka_zakaza)
Ø kol-vo - Скільки було замовлено
товару.
Ø Cena - Ціна за кількість замовленого.
Складське примішення (sklad)
Ø № zony - номер зони, знаходиться
товар.
Ø Vmestitelnost - кількість товару.
Ø Osobenosti - особливості товару.
Ø data postuplenia - дата коли товар
прибув на склад.
Товар (Tovar)
Ø vremia prybytia - дата прибуття
товару.
Ø kol-vo - кількість товару.
Асортимент (Аsortiment)
Ø name tovar - назва товару.
Постачальник (Postovshik)
Ø fio/name ordonization - дані про
постачальника або організацію.
Каталог постачальників (spisok postavshikov)
Ø FIO/name organization - дані про
постачальника або організацію
Ø Telephon - номер
телефона/факса/пейджера за яким можна зв’язатися з постачальником.
Ø nomer scheta - номер рахунку на який
поступають гроші за товар.
Час зберігання (srok hranenia)
Ø sostoianie - містить опис товару в
момент його прибуття на склад.
Ø vrema hranenia - містить дані про час
зберігання товару на складі.
Працівник складу (rabotnik sklada)
Ø fio - Дані про працівника.
Бухгалтер (Buhgalner)
Ø fio - дані про бухгалтера.
Акт списання (act)
Ø sostoenia tovara - містить дані про
стан товару після його перебування на складі деякий час.
Ø kol-vo - кількість цього товару.
Місце (Mesto)
Ø haracterictika - містить дані про
товар.
Ø № sclada - номер складу, де перебуває
товар.
Сорт товару (Sort)
Ø Name sorta - назва сорту продута.
Секретар (Sekretar)
Ø FIO - інформація про секретаря.
Знищувач (Znyshuvach)
Ø FIO - інформація про знищувача.
Діаграма класів. Рисунок 2.3
2.2 Логічна модель предметної області
Оскільки логічна модель містить абстракції, які вже можуть
бути незрозумілі експертам предметної області − ця модель служить для
уточнення інформації про предметну область у тому вигляді, який зручний для
подальшої реалізації інформаційної системи.
Таким чином, логічна модель дозволяє повністю задати
структуру даних, проте без "прив'язки" до конкретної платформі
реалізації. Такий опис, з одного боку, виходить компактніше, ніж фізична модель
і дозволяє поглянути на схему даних в цілому, без зайвих деталей. З іншого
боку, така специфікація може бути в подальшому реалізована за допомогою різних
мов програмування.
2.2.1 Діаграма діяльності
При моделюванні поведінки проектованої або аналізованої
системи виникає необхідність не тільки уявити процес зміни її станів, але і
деталізувати особливості алгоритмічної і логічної реалізації виконуваних
системою операцій. Традиційно для цієї мети використовувалися блок-схеми або
структурні схеми алгоритмів.
Для моделювання процесу виконання операцій в UML
використовуються діаграми діяльності. Кожна така схема акцентує увагу на
послідовності виконання певних дій або елементарних операцій, які в сукупності
призводять до отримання бажаного результату. Причому перехід в наступний стан
спрацьовує тільки при завершення цієї операції в попередньому стані.
Для уточнення концептуальної діаграми класів, яка була
розглянута на рисунку 2.3, побудуємо діаграму, яка відображає сценарій "Прихід
товару на склад".
На діаграмі діяльності на рисунку 2.4 та відображається
логіка або послідовність переходу від однієї діяльності до іншої, при цьому
увага фіксується на результаті діяльності. Сам же результат може призвести до
зміни стану системи або повернення деякого значення.
Діаграма діяльності на рисунку 2.4
Продукти(товар) поступає до відділу прийому товару. Там товар
проходить огляд. При успішному проходженні товар відправляється на склад, де
сортується, розраховується кількість и т. д. У протилежному випадку товар
знищується, а дані про знищення надходять в бухгалтерію, де заносяться до
відповідного документу.
2.2.2
Діаграма послідовності
У мові UML взаємодія елементів розглядається в інформаційному
аспекті їх взаємодії, тобто взаємодіючі об'єкти обмінюються між собою деякою
інформацією. При цьому інформація приймає форму закінчених повідомлень. Іншими
словами, хоча повідомлення і має інформаційний зміст, воно набуває додаткової
властивості надавати направлений вплив на свого одержувача.
Ключовим моментом для діаграми послідовності є динаміка
взаємодії об'єктів у часі. При цьому на діаграмі послідовності зображуються
тільки об'єкти, які безпосередньо беруть участь у взаємодії, і ніякі статичні
зв'язки з іншими об'єктами не візуалізуються.
Оскільки ініціатором виникнення ланцюжка подій в більшості
випадків є деяка зовнішня сутність, то для виконання даної функції при
вирішенні задачі автоматизації овочевої бази вибирається головний актор
"Працівник складу", описаний раніше і наведений на діаграмі
прецедентів на малюнку 2.1. Послідовність провокується "Працівником
складу", коли завершено окремий вид робіт по даному об'єкту. При цьому,
послідовність вступає у взаємодію з класами "Sklad", "Stoka hranenia", "Act".
Під час взаємодії формуються операції, які належать наступним
класам:
· "Sklad"
o Peresmotr tovara() - Працівник складу приходить на склад и проводить огляд товару,
який провів на складі деякий час ;
· "Sklad"
o Smena sroka hr. Tovara() - Після перегляду товару
змінюється час зберігання.
· "Srok hranenia"
o peresmotr sroka hranenia() - якщо
товар не відповідає вимогам його знову переглядають и пере заносять, вписуючи
новий час зберігання.
· "sklad"
o vozvrat sroka hr. Tovara() - Товар
якому змінили час зберігання знову повертається на склад.
· "act"
o spisanie porchenogo tovara() - Якщо
товар не відповідає вимогам і після перегляду його заносять до акту знищення.
· "sklad"
o otche o spisanom tovare() -
відправляється звіт про товар, який був знищений.
o Vybor() - товар знову переглядається
и перераховується.
· "Працівник складу"
o Otchet() - виводиться кінцевий звіт.
Діаграма, на якій показані взаємодії об'єктів, впорядкованих
за часом їх прояви, представлена на рисунку 2.5.
Діаграма послідовності на рисунку 2.5
2.2.3
Діаграма кооперації
Діаграми кооперації використовуються для характеристики
динаміки поведінки систем, хоча час в явному вигляді в них відсутній.
Цей тип діаграм дозволяє описати взаємодії об'єктів, абстрагуючись
від послідовності передачі повідомлень. На діаграмі в компактному вигляді
відбиваються всі прийняті і передані повідомлення певного об'єкта і типи цих
повідомлень. автоматизація діаграма інформаційний case
В якості центрального об'єкту при побудові UML-моделі
інформаційної системи овочевої бази обирається об’єкт класу "Zakaz", який приймає наступні
повідомлення:
· Stvorenia_zakazu ()
o короткий опис - створюється замовлення;
o ініціатор - актор
"Замовник"
o вхідні параметри - id_zk (час
виконання)
o результат - список товарів
замовлення.
В якості центрального об'єкту при побудові UML-моделі
інформаційної системи овочевої бази обирається об’єкт класу "Zakaz", який генерує наступні
повідомлення:
· st_vartosti_tv ()
o короткий опис - створює вартість товару;
o ініціатор - анонімний об'єкт класу
"Zakaz";
o вхідні параметри - id_zr (ціна n-ї к-ті товару);
o результат - створення ціни.
· na_rozrahunok ()
o короткий опис - передає дані про надходження грошей в
касу;
o ініціатор - анонімний об'єкт класу
"Zakaz";
o вхідні параметри - id_buh (Розраховано за товар);
o результат - розрахунок за замовлений
товар.
Для передачі деяких повідомлень необхідно виконання операцій,
що не стосуються центрального класу "Zakaz", але являються невід'ємною
часткою його поведінки:
· naiavnist_tovaru_na_skladi():
o короткий опис - перевірка на складі
потрібної к-ті товару;
o ініціатор - анонімний об'єкт класу
"Zakaz";
o власник - об’єкт класу
"Stroka_zakaza";
o вхідні параметри - відсутні.
o результат - новий запис.
Порядок виникнення повідомлень, які відображають взаємодії
наведених об'єктів, зазначений на діаграмі кооперації на рисунку 2.6.
Діаграма кооперації. Рисунок 2.6.
2.2.3
Діаграма класів
Діаграма класів. Рисунок 2.7
2.3 Фізична модель
предметної області
Фізична модель інформаційної системи визначає способи
розміщення даних в середовищі зберігання і способи доступу до цих даних, які
підтримуються на фізичному рівні. Іншими словами, у мові UML фізична модель
відображає компонентний склад проектованої системи з точки зору її реалізації
на деякій технічній базі та обчислювальних платформах конкретних виробників.
2.3.1
Діаграма класів
Фізична модель діаграми класів є описом структури даних в
термінах платформи реалізації − конкретної СУБД. Вона фактично є
діаграмним поданням частини програмного коду, що визначає схему даних. Модель
класів на фізичному рівні містить інформацію про різні деталі реалізації −
індекси, ключі, типи атрибутів, межі видимості, які визначені в термінах
цільової мови програмування С #.
Діаграма класів. рисунок 2.8
2.3.2
Діаграма компонентів
Діаграми компонентів застосовуються для моделювання статичного
вигляду системи з точки зору реалізації. Сюди відноситься моделювання фізичних
сутностей, розгорнутих у вузлі, таких як виконувані програми, бібліотеки,
таблиці, файли і документи. По суті, діаграми компонентів − це не що
інше, як діаграми класів, сфокусовані на системних компонентах.
Представлена на рисунку 2.9 діаграма компонентів містить у
собі набір компонентів розв'язуваної задачі із встановленими для них
відносинами.
Головна програма я містить у собі такі класи:
"Buhgalteria", "otdel postashikov", "sklad",
"Priemnia".
"Priemnia"- має класи "Zakazchik",
"zakaz";
"sklad" - має класи "srok hranenia",
"mesto", "Tovar";
"Buhgalteria" - має класи "Act";
"otdel postashikov"-має класи
"asortiment", "Postovshik", "spisok
postavshikov", "Tovar";
Діаграма компонентів. Рисунок 2.9
2.3.3
Діаграма
розгортання
Фізичне подання програмної системи не може бути повним, якщо
відсутня інформація про те, на якій платформі і на яких обчислювальних засобах
вона реалізована. Якщо розробляється програма, що виконується локально на
комп'ютері користувача і не використовує периферійних пристроїв і ресурсів, то
в розробці додаткових діаграм немає необхідності. Інакше, для представлення
загальної конфігурації і топології розподіленої програмної системи, створюються
фізично існуючі елементи.
Діаграма розгортання. Рис. 2.10
Головним комп’ютером (Server), на якому зберігаються дані з усіх
підлеглих комп’ютерів, які розміщені в різних відділах овочевої бази.-
комп’ютер, який знаходиться в бухгалтерії. Передає дані на Server.
. 3in1_print - для полегшення роботи працівникам
бухгалтерії (роздрукування потрібної інформації)..- комп’ютер, який знаходиться
в складському приміщенні, веде складський облік. Передає дані на Server.
. Shtrihcode - для полегшення роботи працівникам
складу(занесення інформації про товар).postashikov - комп’ютер, який
знаходиться у відділі роботи з постачальниками, містить у собі дані про
постачальника. Передає дані на Server.
. Print - для полегшення роботи працівникам відділу
роботи з постачальниками (роздрукування потрібної інформації).- комп’ютер, який
знаходиться у відділі роботи з замовниками, містить у собі дані про замовника,
а також замовлений товар. Передає дані на Server.
. Print - для полегшення роботи працівникам відділу роботи з замовниками
(роздрукування потрібної інформації).
2.4
Реалізація
моделі в середовищі CASE-засобу
Одним з найбільш важливих властивостей програми StarUml є можливість генерації
програмного коду на декількох мовах програмування, яка може бути використана
розробником після побудови моделі. Для цієї мети в середовищі StarUml присутній досить великий
вибір мов програмування і схем баз даних.
2.5 Реалізація моделі в середовищі CASE-засобу
Генерація програмного коду яка після побудови моделі може
бути використана розробником у програмі StarUml на декількох мовах програмування.
Використовуючи інформацію, що міститься в моделі проекту, генератор кодів на С# формує файли заголовків і файли
реалізацій класів. Створювана структура програми може бути уточнена шляхом
прямого програмування мовою С # При
повторній генерації внесені зміни зберігаються.
Базуючись на обраних властивостях генерації, StarUml генерує наступні елементи
коду:
· для кожного модуля:
o файл заголовка та файл реалізації для
модуля;
o #include директиви, явно чи неявно
визначені в моделі.
· для кожного класу:
o визначення класу;
o оголошення атрибутів і відносин;
o get і set функції для доступу до
атрибутів;
o оголошення для стандартних операцій
із заготовками визначень.
o оголошення для операцій, визначених
користувачем.
Всі поля документування із специфікацій діаграм переносяться
до коду як коментарі. Отриманий код наведено у додатку 1.
Висновки
Робота овочевої бази автоматизована. Проведено
повний і детальний опис предметної області, виявлені межі розроблюваної
системи.
Діаграми різних видів показали систему з різних точок зору. В
результаті розроблена модель відобразила структуру задачі, що автоматизується,
її дійових осіб, автоматизованих функцій, інших сутностей, сценаріїв реалізації
операцій і станів сутностей. Модель використовується для визначення вимог до
системи, що розробляється, та виявлення всіх зв'язків між її частинами, що
беруть участь у вирішенні конкретних завдань.
Результати моделювання в CASE StarUml легко можуть бути перетворені в
документацію відповідну промисловим стандартам розробки програмних систем.
Повний і детальний опис предметної області вкрай зручно
проводити в CASE засобі, що підтримує універсальну мову моделювання UML, яка
добре сприймається експертами предметної області і не вимагає від них ніякої
спеціальної підготовки для розуміння поданих ним на розгляд моделей.
Перелік
посилань
1.
Крег
Ларман, Застосування UML 2.0 і шаблонів проектування. 3-є вид. - М.:
"Вільямс", 2006. - 736 с.
2.
Джозеф
Шмуллер, Освоюй самостійно UML 2 за 24 години. Практичний посібник. - М.:
"Вільямс", 2005. - 416 с.
3.
Грейда
Буч, Джеймс Рамбо, Айвар Джекобсон, Мова UML. Керівництво користувача. 2. - М.,
СПб.: ДМК Пресс, Пітер, 2004. - 432 с.
4.
Буч Г.,
Якобсон А., Рамбо Дж., UML. Класика CS. 2-е вид. / Пер. з англ.; Під загальною
редакцією проф. С. Орлова - СПб.: Пітер, 2006. - 736 с.
5.
Леоненко
А.В. Об'єктно-орієнтований аналіз та проектування з використанням UML і IBM
Rational Rose - БІНОМ. Лабораторія знань, Інтернет-університет інформаційних
технологій - ІНТУІТ.ру, 2006
6.
Грекул
В.І., Денищенко Г.М., Коровкін Н.Л. Проектування інформаційних систем -
Інтернет-університет інформаційних технологій - ІНТУІТ.ру, 2008
7.
С. Орлов,
Технології розробки програмного забезпечення. Підручник - СПб.: Пітер, 2002. -
464 с.
8.
Лешек А.
Мацяшек, Аналіз та проектування інформаційних систем за допомогою UML 2.0. 3
вид.: - М.: Вільямс, 2004. - 816с.
9.
Кендалл
Скотт, UML. Основні концепції: - М.: Вільямс, 2002. - 144с.
10.Боггс, UML і StarUml: - М.: Лорі, 2007. - 286с.
Додаток
//
//
// Generated by StarUML(tm) C# Add-In
//
// @ Project : оващебаза
// @ File Name : Znyshuvach.cs
// @ Date : 26.12.2010
// @ Author :
//
//class Znyshuvach {object id_zn ;String FIO ;
}
//
//
// Generated by StarUML(tm) C# Add-In
//
// @ Project : оващебаза
// @ File Name : Zakazchik.cs
// @ Date : 26.12.2010
// @ Author :
//
//class Zakazchik {object id_zz ;String fio ;String telephone
;Integer c4et4ik ;
}
//
//
// Generated by StarUML(tm) C# Add-In
//
// @ Project : оващебаза
// @ File Name : zakaz.cs
// @ Date : 26.12.2010
// @ Author :
//
//class zakaz {object id_zk ;Integer 4yslo ;Integer number
;decimal stoimost ;decimal vypla4eno ;object id_sk ;object id_zr ;void
stvorenia zakazu(){
}void stvorenia_zakazu(){
}void Za_tv_rozrahovano(){
}void pov_ceny_za_tovar(){
}
}
//
//
// Generated by StarUML(tm) C# Add-In
//
// @ Project : оващебаза
// @ File Name : Tovar.cs
// @ Date : 26.12.2010
//
//class Tovar {object id_pz ;object id_a ;Integer vremia
prybytia ;Integer kol-vo ;object id_p ;object id_s ;
}
//
//
// Generated by StarUML(tm) C# Add-In
//
// @ Project : оващебаза
// @ File Name : stroka_zakaza.cs
// @ Date : 26.12.2010
// @ Author :
//
//class stroka_zakaza {object id_szr ;object id_zk ;Float
kol-vo ;decimal cena ;object id_z ;void st_vartosti_tv(){
}void povernenia_tovaru(){
}
}
//
//
// Generated by StarUML(tm) C# Add-In
//
// @ Project : оващебаза
// @ File Name : srok hranenia.cs
// @ Date : 26.12.2010
// @ Author :
//
//class srok hranenia {object id_sr ;String sostoianie
;Integer vrema hranenia ;object id_rab ;
}
//
//
// Generated by StarUML(tm) C# Add-In
//
// @ Project : оващебаза
// @ File Name : spisok postavshikov.cs
// @ Date : 26.12.2010
// @ Author :
//
//class spisok postavshikov {object id_p ;String FIO/name
organization ;String Adress ;String telephon ;Integer nomer scheta ;
}
//
//
// Generated by StarUML(tm) C# Add-In
//
// @ Project : оващебаза
// @ File Name : sort.cs
// @ Date : 26.12.2010
// @ Author :
//
//class sort {object id_s ;String name sorta ;
}
//
//
// Generated by StarUML(tm) C# Add-In
//
// @ Project : оващебаза
// @ File Name : sklad.cs
// @ Date : 26.12.2010
// @ Author :
//
//class sklad {object id_z ;Integer № zony ;Integer
Vmestitelnost ;Integer data postuplenia ;object id_pa ;object id_m ;void
naiavnist_tovaru_na_skladi(){
}
}
//
//
// Generated by StarUML(tm) C# Add-In
//
// @ Project : оващебаза
// @ File Name : skidki.cs
// @ Date : 26.12.2010
// @ Author :
//
//class skidki {object id_sk ;double % skidki ;double max
;double min ;object id_b ;
}
//
//
// Generated by StarUML(tm) C# Add-In
//
// @ Project : оващебаза
// @ File Name : sekretar.cs
// @ Date : 26.12.2010
// @ Author :
//
//class sekretar {String FIO ;object id_sek ;
}
//
//
// Generated by StarUML(tm) C# Add-In
//
// @ Project : оващебаза
// @ File Name : rabotnik sklada.cs
// @ Date : 26.12.2010
// @ Author :
//
//class rabotnik sklada {object id_rab ;String fio ;
}
//
//
// Generated by StarUML(tm) C# Add-In
//
// @ Project : оващебаза
// @ File Name : Postovshik.cs
// @ Date : 26.12.2010
// @ Author :
//
//class Postovshik {object id_t ;Integer kol-vo tovara
;object id_p ;
}
//
//
// Generated by StarUML(tm) C# Add-In
//
// @ Project : оващебаза
// @ File Name : mesto.cs
// @ Date : 26.12.2010
// @ Author :
//
//class mesto {object id_m ;String haracterictika ;Integer №
sclada ;object id_rab ;
}
//
//
// Generated by StarUML(tm) C# Add-In
//
// @ Project : оващебаза
// @ File Name : buhgalner.cs
// @ Date : 26.12.2010
// @ Author :
//
//class buhgalner {object id_b ;String fio ;
}
//
//
// Generated by StarUML(tm) C# Add-In
//
// @ Project : оващебаза
// @ File Name : bugalteria.cs
// @ Date : 26.12.2010
// @ Author :
//
//class bugalteria {decimal oplata ;Integer data oplaty
;object id_b ;object id_zk ;void zapyt_rozrahuvania(){
}
}
//
//
// Generated by StarUML(tm) C# Add-In
//
// @ Project : оващебаза
// @ File Name : asortiment.cs
// @ Date : 26.12.2010
// @ Author :
//
//class asortiment {object id_a ;String name tovar ;object
id_sek ;
}
//
//
// Generated by StarUML(tm) C# Add-In
//
// @ Project : оващебаза
// @ File Name : act.cs
// @ Date : 26.12.2010
// @ Author :
//
//class act {String sostoenia tovara ;Integer kol-vo ;object
id_z ;object id_zn ;
}