Подякувати Студентському архіву довільною сумою
Admin
26.02.2023 12:38
Дякуємо, що користуєтесь нашим архівом!
Салон пошиття одягу.
Інформація про навчальний заклад
ВУЗ:
Національний університет Львівська політехніка
Інститут:
Не вказано
Факультет:
Не вказано
Кафедра:
Кафедра САПР
Інформація про роботу
Рік:
2008
Тип роботи:
Розрахункова робота
Предмет:
Системний аналіз
Група:
КН-2
Частина тексту файла (без зображень, графіків і формул):
Міністерство освіти і науки України
Національний університет „ Львівська політехніка “
Кафедра САПР
Розрахункова робота
з курсу «Системний аналіз»
на тему:
«Салон пошиття одягу»
Виконала
ст. групи КН-2
Прийняв
Львів-2008
Зміст
Розділ І: Опис системи «Салон пошиття одягу»;
Розділ ІІ: Створення IDEF0 для системи;
Розділ ІІІ: Створення діаграми потоків даних;
Розділ IV: ER-діаграма;
Розділ V: Мережа Петрі для системи;
Розділ VI: Економічна оцінка програмного продукту.
Розділ І: Опис системи «Салон пошиття одягу»
Замовник приходить до директора з документами, які підтверджують особу, та обговорює умови, деталі договору (який тип одягу необхідно пошити, ціна, термін виконання замовлення і т.д.).
Договір, який замовник укладає з директором салону, містить:
оформлення та реєстрацію замовлення, де необхідно вказати дані про замовника;
номер замовлення;
дату;
номер рахунку, який замовнику потрібно буде сплатити.
Якщо клієнт не правильно, не правдиво оформив документи, то салон має право відмовити йому в наданні послуг.
Спочатку потрібно здійснити закупівлю тканини, ниток та інших необхідних для пошиття матеріалів. Для цього потрібно зв’язатися з постачальником і здійснити замовлення.
При замовленні тканини нас цікавлять такі основні параметри як країна-постачальник, колір, тип тканини.
У виробничий відділ передають інформацію (замовлення), згідно якого виготовляють креслення викройки майбутнього одягу, який потрібно пошити. Воно містить дані про те, яка тканина буде використовуватись, тип одягу, розмір тощо.
Попередньо знявши виміри (загальну довжина виробу, плеча, спини тощо) або використовуючи стандартні розміри, обчислюють невідомі довжини частин виробів. Згідно отриманих даних виготовляють креслення (викройку) і передають у наступний відділ, де згідно нього проводять розкрій тканини.
На наступному етапі переходять до зшивання окремих частин (комір, рукав і т.д.), отриманих в результаті розкрою. Після цього пришивають окремі деталі одягу (гудзики, замки і т.д.).
Після цього вже готовий одяг передають до наступного відділі, де йому надають належний вигляд (хімчистка, прасування тощо).
Замовник предявляє документи, які ідентифікують його особу, та копію документа про оплату та забирає виготовлене замовлення.
Відділ збуту готової продукції виписує товарно-транспортну накладну, яку підписують (у разі сплати) бухгалтер та керівник відділу збуту.
Розділ ІІ: Створення IDEF0 для системи
IDEF - методології створювалися в рамках запропонованої ВПС США програми комп'ютеризації промисловості - ICAM, у ході реалізації якої з’явилася потреба в розробці методів аналізу процесів взаємодії у виробничих системах. Принциповою вимогою при розробці розглянутого сімейства методологій була можливість ефективного обміну інформацією між усіма фахівцями – учасниками програми ICAM (звідси назва: Icam DEFinition - IDEF). Після опублікування стандарту, він був успішно застосований у різних сферах бізнесу, зарекомендувавши себе ефективним засобом аналізу, конструювання і відображення бізнес-процесів, включаючи і процес бюджетування.
Методологія IDEF0 може використовуватися для моделювання різноманітних систем, де під системою розуміється будь-яка комбінація засобів апаратного і програмного забезпечення, а також людей. Результатом її застосування є модель функціонування об’єкту дослідження.
В основі методології IDEF0 лежать чотири основні поняття:
1. Поняття функціонального блоку. Функціональний блок графічно зображається у вигляді прямокутника і позначає конкретну функцію або операцію. При цьому кожна функція або операція повинна мати індивідуальну назву і має бути сформульована в дієслівному нахиленні, наприклад, «сформувати бюджет допоміжного підрозділу» або «контролювати виконання бюджету».
Кожна із чотирьох сторін функціонального блоку має своє визначене значення (роль), при цьому:
верхня сторона має значення “Управління”;
ліва сторона має значення “Вхід”;
права сторона має значення “Вихід”;
нижня сторона має значення “Механізм”.
Кожний функціональний блок у рамках єдиної системи, що розглядається, повинен мати свій унікальний ідентифікаційний номер.
2. Поняття інтерфейсної дуги. Інтерфейсна дуга, або стрілка, відображає потік інформації або ресурс, що необхідний для виконання функції, або відображає результат виконання функції. Кожна інтерфейсна дуга повинна мати своє унікальне найменування. Згідно із вимогою стандарту, найменування повинне бути оборотом іменника. У такий спосіб ми можемо сформувати будь-яку послідовність дій, використовуючи функціональні блоки, і зв'язати їх за допомогою інтерфейсних дуг. У методології IDEF0 під стрілкою «Вхід» мається на увазі вся вхідна інформація та ресурси, що необхідні для виконання конкретної функції або підготовки інформації. Наприклад, для виконання функції «Сформувати бюджет продаж» необхідна інформація про ринок. Під стрілкою «Вихід» мається на увазі вихідна інформація або ресурси, що є результатом виконаної функції, наприклад «Бюджет продаж». Стрілка «Управління» передбачає позначення різних нормативних документів, які безпосередньо регламентують виконання даної функції, та цією ж стрілкою позначають керівника або відповідального за контроль даної функції. Стрілка «Механізм» показує, хто конкретно відповідає за виконання даної функції або операції, і яке устаткування або програмне забезпечення йому для цього необхідне. Наприклад, для формування бюджету продажу конкретного виду продукції маркетологу Іванову І. І. знадобляться програмне забезпечення «Експерт з продажу», комп'ютер, принтер та інше обладнання. У такий спосіб за виконанням кожної функції закріплюється конкретна посадова особа, визначаються необхідні для цього ресурси, інформація та результати діяльності цієї посадової особи. До того ж функція розглядається не окремо, а в конкретному потоці робіт, що дозволяє бачити логіку процесу.
3. Мета і точка зору моделі. Кожна модель повинна мати чітко сформульовані мету і точку зору. Мета пояснює навіщо формується ця модель і для чого вона призначена. Точка зору ж розповідає про те, у якому ракурсі ми будемо розглядати модель. Наприклад, метою формування моделі «Бюджетування» може бути розробка регламенту цього процесу або проведення робіт з автоматизації системи бюджетування. При цьому може вибиратися точка зору керівника підприємства або системного аналітика і це вплине на ракурс розроблювальної моделі.
4. Глосарій. Для кожного з елементів IDEF0 – діаграм, функціональних блоків, інтерфейсних дуг – існуючий стандарт має на увазі створення і підтримку набору відповідних визначень, ключових слів, розповідних (пояснювальних) викладів тощо, що характеризують об'єкт, який відображається даним елементом. Цей набір називається глосарієм і є описом сутності даного елементу. Наприклад, для керуючої інтерфейсної дуги “розпорядження про оплату” глосарій може містити перелік полів документа, необхідний набір віз та інше. Глосарій гармонійно доповнює наочну графічну мову діаграми необхідною додатковою інформацією, що є величезною перевагою при постановці систем бюджетування, коли за допомогою глосарію виробляється спільний сленг і всі служби підприємства спілкуються однією мовою.
Розділ ІІІ: Створення діаграми потоків даних
Діаграма потоків даних (англ. Data Flow Diagram) — графічне представлення «потоків» даних в інформаційній системі. Діаграма потоків даних також може використовуватись для представлення обробки даних (структурна розробка). Вважається звичайним, для розробника, з початку креслити ДПД рівня контексту, завдяки чому буде показано взаємодію системи із зовнішніми модулями. Ця ДПД рівня контексту, потім розширюється, для того, щоб показати розроблювану систему детальніше.Діаграми потоків даних містять чотири типи графічних елементів: процеси, що представляють собою трансформацію даних в рамках системи, що описується, репозиторії (сховище даних), зовнішні по відношенню до системи сутності та потоки даних між елементами трьох попередніх типів.
Таким чином, основними компонентами діаграм потоків даних є:
зовнішні сутності;
системи/підсистеми;
процеси;
нагромаджувачі даних;
потоки даних.
Зовнішні сутності. Зовнішня сутність є матеріальним предметом або фізичною особою, яка виступає джерелом або приймачем інформації, наприклад, замовники, персонал, постачальники, клієнти, склад тощо. Визначення деякого об'єкту або системи як зовнішня сутність вказує на те, що вона знаходиться за межами аналізованої ІС. У процесі аналізу деякі зовнішні сутності можуть бути перенесені всередину діаграми аналізованої ІС, якщо це необхідно, або, навпаки, частина процесів ІС може бути винесена за межі діаграми і представлені як зовнішні сутності.
Системи і підсистеми. При побудові моделі складної ІС вона може бути представлена у найзагальнішому вигляді на так званій контекстній діаграмі у вигляді однієї системи як єдиного цілого, або може бути декомпонована на низку підсистем.
Процеси. Процес є перетворенням вхідних потоків даних у вихідні відповідно до певного алгоритму. Фізично процес може бути реалізований різними способами: це може бути підрозділ організації (відділ), що виконує обробку вхідних документів і випуск звітів, програма, апаратно реалізований логічний пристрій тощо.
Нагромаджувачі даних. Нагромаджувач даних є абстрактним пристроєм для зберігання інформації, яку можна у будь-який момент помістити у нагромаджувач і через деякий час витягнути, причому способи розміщення і витягання можуть бути будь-якими.
Розділ IV: ER-діаграма
ER-діаграма предметної області представляється множиною сутностей, атрибутів та зв’язків. Елементи кожної з цих множин представляються вузлами графа для яких ми використовуємо спеціальні форми для визначення їхнього виду:
Множина сутностей представляється прямокутниками.
Атрибути представляються овалами.
Зв’язки представляються ромбами.
Розгляд степенів особливо корисно для бінарних зв'язків. Можуть існувати наступні степені бінарних зв'язків:
один до одного (позначається 1:1). Це означає, що в такому зв'язку сутності з однією роллю завжди відповідає не більше однієї сутності з іншою роллю. У розглянутому прикладі це зв'язок "керує", оскільки у кожному відділі може бути лише один начальник, а співробітник може керувати лише в одному відділі. Прямокутники позначають сутності, а ромб - зв'язок. Оскільки степінь зв'язку для кожної сутності дорівнює 1, то вони з'єднуються однією лінією.
один до багатьох (1:n). У даному випадку сутності з однією роллю може відповідати будь-яка кількість сутностей з іншою роллю. Таким є зв'язок ВІДДІЛ-СПІВРОБІТНИК. У кожному відділі може працювати довільна кількість співробітників, але співробітник може працювати лише в одному відділі. Графічно степінь зв'язку n відображається "деревоподібною” лінією.
багато до одного (n:1). Цей зв'язок аналогічний відображенню 1:n. Припустимо, що представлення нами підприємство будує свою діяльність на підставі контрактів, що підприємство, яке ми розглядаємо, будує свою діяльність на основі контрактів, які укладаються із замовниками.
багато до багатьох (n:n). У цьому випадку кожне з асоційованих сутностей може бути представлена будь-якою кількістю екземплярів. Нехай на підприємстві для виконання кожного контракту створюється робоча група, у яку входять співробітники різних відділів. Оскільки кожний співробітник може входити в кілька (у тому числі і в жодну) робочих груп, а кожна група повинна включати не менше одного співробітника.
Розділ V: Мережа Петрі для системи
Мережі Петрі (МП) це інструмент для математичного моделювання і дослідження складних систем. Мета представлення системи у вигляді мережі Петрі і подальшого аналізу цієї мережі полягає в отриманні важливої інформації про структуру і динамічну поведінку модельованої системи. Ця інформація може використовуватися для оцінки модельованої системи і вироблення пропозицій по її удосконаленню. Вперше мережі Петрі запропонував німецький математик Карл Адам Петрі.
Мережі Петрі призначені для моделювання систем, які складаються з безлічі компонент, які взаєодіють між собою. При цьому компонента сама може бути системою. Діям різних компонент системи властивий паралелізм. Прикладами таких систем можуть бути обчислювальні системи, у тому числі і паралельні, комп'ютерні мережі, програмні системи, що забезпечують їх функціонування, а також економічні системи, системи управління дорожнім рухом, хімічні системи тощо.
Мережі Петрі притаманні такі риси:
МП використовується для опису модельованої системи, і це може бути застосовано для специфікацій (для побудови систем) або опису системи.
Поведінку МП можна проаналізувати як моделюванням (що еквівалентно виконанню програми та її налагодженню), так і формальнішими методами аналізу (що відповідає програмній перевірці).
Процес створення опису та виконання аналізу допомагає краще зро зуміти модельовану систему самому моделювальнику.
Мережі Петрі використовуються, як допоміжний інструмент аналізу в одному з підходів до проектування і аналізу систем. Тут для побудови системи використовуються загальноприйняті методи проектування. Потім побудована система моделюється за допомогою мереж Петрі, і модель аналізується. Якщо в ході аналізу у проекті знайдені недоліки, то з метою їх усунення проект модифікується. Модифікований проект потім знову моделюється і аналізується. Даний цикл повторюється доти, доки аналіз, що проводиться, не приведе до успіху.
Інший підхід передбачає побудову проекту одразу у вигляді мереж Петрі. Методи аналізу застосовуються мережі для створення проекту, що не мережі помилок. Потім мережі Петрі перетвориться в реальну робочу систему.
У першому випадку необхідна розробка методів моделювання систем мережами Петрі, а у другому випадку повинні бути розроблені методи реалізації мереж Петрі системами.
Ділись своїми роботами та отримуй миттєві бонуси!
0%
Оголошення від адміністратора