Первая страница
Наша команда
Контакты
О нас

    Головна сторінка



«Розробка програмного забезпечення»

«Розробка програмного забезпечення»




Сторінка1/3
Дата конвертації02.05.2017
Розмір0.51 Mb.
ТипПрактикум
  1   2   3



МЕТОДИЧНІ ВКАЗІВКИ


до виконання практичних робіт

з дисципліни:


«ПРОЕКТНИЙ ПРАКТИКУМ»
«Розробка програмного забезпечення»
Вимоги до оформлення:


  1. Практична робота має один варіант для усіх студентів, виконується на аркушах формату А4 в друкованому варіанті згідно ДСТУ 30008-95. Також допускається виконання роботи у письмовому вигляді в окремому зошиті.

  2. Практична робота складається з одного завдання, а саме – розробити специфікацію програмного забезпечення для обраної теми згідно варіанту.

  3. Практична робота повинна бути здана не пізніше ніж через два тижні від дати видачі завдання.

  4. Практична робота повинна містити в собі наступні розділи:

  • Титульний лист, на якому позначається назва дисципліни, ПІБ розробника, ПІБ викладача;

  • Тема;

  • Мета;

  • Завдання;

  • Хід виконання завдання;

  • Перелік використаної літератури та інформаційних джерел;

Практична робота № 1
Тема: Проектування проекту з використанням шаблону Façade.

Мета: Ознайомитись із шаблоном проектування, здобути навички проектування.

Завдання: Оберіть предметну область, розробіть програмне забезпечення з використанням шаблону Façade.
Шаблони проектування програмного забезпечення (англ. software design patterns) - ефектні способи вирішення задач проектування програмного забезпечення. Шаблон не є закінченим зразком, який можна безпосередньо транслювати в програмний код.
Предме́тна о́бласть (ПрО) - множина всіх предметів, властивості яких і відношення між якими розглядаються в науковій теорії. В логіці - гадана область можливих значень предметних змінних логічної мови.
Програ́мне забезпе́чення (програ́мні за́соби) (ПЗ; англ. software) - сукупність програм системи обробки інформації і програмних документів, необхідних для експлуатації цих програм.
Опишіть розроблене ПЗ згідно шаблону, розробіть необхідні функціональні блоки.
У книзі "банди чотирьох" призначення шаблону Facade (фасад) визначається наступним чином. Надання єдиного інтерфейсу для набору різних інтерфейсів в системі. Шаблон Facade визначає інтерфейс більш високого рівня, що упрощаетработу з системою. В основному цей шаблон використовується в тих випадках, коли необхідний новий спосіб взаємодії з системою - простіший порівняно з уже існуючим. Крім того, він може застосовуватися, коли потрібно використовувати систему деяким специфічним чином - наприклад, звертатися до програми тривимірної графіки для побудови двомірних зображень.
Триви́мірна гра́фіка (3D, 3 Dimensions, укр. 3 виміри) - розділ комп'ютерної графіки, сукупність прийомів та інструментів (як програмних, так і апаратних), призначених для зображення об'ємних об'єктів.
У цьому випадку нам буде потрібно спеціальний метод взаємодії з системою, оскільки використовуватиметься лише частина її функціональних можливостей.

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

Управління проектами - (англ. Project Management) область знань з планування, організації та управління ресурсами з метою успішного досягнення цілей та завершення завдань проекту. Іноді ототожнюється з управлінням програмами, але програма - це фактично вищий рівень: група пов'язаних та взаємозалежних проектів.
Компанія відмовлялася оплатити цей робочий день просто так, але ніхто не знав, яке завдання мені слід доручити. Вони хотіли, щоб я робив хоч чтонибудь, навіть якщо це не принесло б ніякої користі! Думаю, вам теж доводилося стикатися з чимось подібним. Зрештою, одна зі співробітниць знайшла для мене заняття. Вона сказала: "Вважаю, що рано чи пізно, але вам обов'язково потрібно вивчити ту САПР, яка використовується у нас в даний час, - так що ви можете приступити до цього прямо зараз ". Після цих слів дівчина вказала мені на стос документації, що займала на книжковій полиці майже 3 метри. Книги були надруковані дрібним шрифтом на аркушах формату А4, і вся ця гора паперу представляла собою технічний опис однієї єдиної, але дуже складною системи.

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

Прикладни́й програ́мний інтерфе́йс (інтерфейс програмування застосунків, інтерфейс прикладного програмування) (англ. Application Programming Interface, API) - набір визначень взаємодії різнотипного програмного забезпечення.
Потім йому буде потрібно визначити новий клас (або класи), що надає необхідний інтерфейс. Це дозволить іншим членам групи просто звертатися до даного інтерфейсу, замість того, щоб витрачати час на детальне вивчення складної системи (рис. 6.2). Цей підхід застосовується, коли використовується тільки частина всіх можливостей системи або коли взаємодія з нею здійснюється деяким специфічним чином. Якщо ж необхідно використовувати абсолютно всі компоненти і функціональні можливості системи, то малоймовірно, що існує яка-небудь можливість створити для неї спрощений інтерфейс (якщо тільки розробники системи не отнеслісь до своєї роботи халатно).

Це і є шаблон проектування Facade. Він спрощує використання складної системи, окремої частини системи або забезпечує звернення до системи деяким специфічним чином. Ми маємо складну систему, і нам потрібно використовувати тільки якусь її частину (окремий модуль).

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

Основна частина роботи як і раніше буде виконуватися вихідною системою. Шаблон Facade надає лише колекцію методів, простих у розумінні та використанні. Ці методи звертаються до основної системи для реалізації знову певних функцій зовнішньої системи.


КОНТРОЛЬНІ ПИТАННЯ:


  1. Що таке шаблон проектування?

  2. Опишіть основні характеристики шаблону FAÇADE.

  3. Які переваги та недоліки, на Вашу думку, має шаблон проектування FACADE?


ЛІТЕРАТУРА:

1. ISO 10014. Управление качеством — Указания по получению финансовых и экономических выгод.

2. ISO/IEC 12207:1995 «Information Technology — Software Life Cycle Processes» (информационные технологии – жизненный цикл программного обеспечения), ГОСТ Р ИСО/МЭК 12207-99.

3. Буч Г. Коналлен Д. Максимчук Р.А. Хьюстон К. Энгл М. Янг Б. Объектно-ориентированный анализ и проектирование с примерами приложений. – 3-е изд. М.: Вильямс, 2008. – 720 с.

4. Гонтарев И.В., Нижегородцев Р.М., Новиков Д.А. Управление проектами. М.: Диброком, 2009. – 384 с.

5. ГОСТ Р ИСО/МЭК 15288-2005. Системная инженерия. Процессы жизненного цикла систем

6. ГОСТ Р ИСО/МЭК ТО 16326-2002. Программная инженерия. Руководство по применению ГОСТ Р ИСО/МЭК 12207 при управлении проектом

Практична робота № 2

Тема: Проектування проекту з використанням шаблону Adapter.

Мета: Ознайомитись із шаблоном проектування, здобути навички проектування.

Завдання: Оберіть предметну область, розробіть програмне забезпечення з використанням шаблону Adapter. Опишіть розроблене ПЗ згідно шаблону, розробіть необхідні функціональні блоки.
Найпростіший спосіб зрозуміти призначення шаблону Adapter - це розглянути його

застосування на прикладі. Припустимо, існують такі вимоги.

• Створити класи для представлення в системі точок, ліній і квадратів, кожен з яких матиме метод display (відобразити).

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

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

• При цьому включити готову підпрограму безпосередньо в створювану програму неможливо.

• Інтерфейс підпрограми або спосіб її виклику в коді не відповідають тим умовам, в яких вона буде використовуватися. Інакше кажучи, хоча в системі представлені точки, лінії і квадрати, нам потрібно, щоб все виглядало так, ніби в ній існують лише деякі

абстрактні фігури.

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

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




Тут використовується принцип поліморфізму; тобто в системі присутні об'єкти-дані різних типів, але використовують їх об'єкти-клієнти повинні взаємодіяти з ними одним і тим же чином. У результаті об'єкт-клієнт може просто вказати об'єкту-даному (незалежно від того, представляє він точку, лінію або квадрат), що необхідно виконати ту чи іншу дію - наприклад, відобразити себе на екрані або, навпаки, видалити з екрану своє зображення. У цьому випадку кожен об'єкт, що представляє точку, лінію або квадрат, повинен буде нести повну відповідальність за коректне виконання необхідних операцій в повній відповідності зі своїм типом. Для вирішення поставленого завдання створимо клас Shape (фігура), а потім визначимо похідні від нього класи, що представляють точки (Point), лінії (Line) і квадрати

(Square) - як показано на рис. 7.2.



Насамперед необхідно визначити специфічну поведінку, яке повинен демонструвати клас Shape. Для вирішення цього завдання слід описати у ньому інтерфейс виклику методів, відповідальних за поведінку, а потім реалізувати ці методи в кожному з породжених класів. Поведінка, яка має демонструвати клас Shape, передбачає наступні методи (рис. 7.3).

• Отримати дані про становище об'єкта Shape (метод setLocation).

• Повідомити дані про становище об'єкта Shape (метод getLocation).

• Показати представлену об'єктом фігуру на екрані (метод display).

• Зафарбувати зображення фігури вказаним кольором (метод fill).

• Встановити колір зафарбовування фігури (метод setColor).

• Видалити зображення фігури з екрана (метод undisplay).

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

Тепер необхідно написати методи display, fill і Undisplay для класу Circle. Це завдання може виявитися досить складною. На щастя, після недовгих пошуків альтернативних рішень (що завжди повинен робити кожен хороший програміст), з'ясувалося, що один з моїх колег вже описав в системі клас XXCircle, призначений для роботи з колами (рис. 7.4). На жаль, він попередньо не порадився зі мною, як краще назвати методи цього класу, тому вони отримали такі імена:

• displayIt

• fillIt

• undisplayIt

В результаті, безпосередньо використовувати клас XXCircle не можна, оскільки бажано зберегти поліморфну ​​поведінку, реалізоване в класі Shape, але цьому перешкоджають наступні моменти.

• Клас Shape і клас XXCircle включають методи з різними іменами і різними списками параметрів.

• Клас XXCircle повинен не тільки мати співпадаючі імена методів, а й обов'язково бути похідним від класу Shape.




КОНТРОЛЬНІ ПИТАННЯ:

  1. Що таке шаблон проектування?

  2. Опишіть основні характеристики шаблону Adapter.

  3. Які переваги та недоліки, на Вашу думку, має шаблон проектування Adapter?


ЛІТЕРАТУРА:

1. ISO 10014. Управление качеством — Указания по получению финансовых и экономических выгод.

2. ISO/IEC 12207:1995 «Information Technology — Software Life Cycle Processes» (информационные технологии – жизненный цикл программного обеспечения), ГОСТ Р ИСО/МЭК 12207-99.

3. Буч Г. Коналлен Д. Максимчук Р.А. Хьюстон К. Энгл М. Янг Б. Объектно-ориентированный анализ и проектирование с примерами приложений. – 3-е изд. М.: Вильямс, 2008. – 720 с.

4. Гонтарев И.В., Нижегородцев Р.М., Новиков Д.А. Управление проектами. М.: Диброком, 2009. – 384 с.

5. ГОСТ Р ИСО/МЭК 15288-2005. Системная инженерия. Процессы жизненного цикла систем



Практична робота № 3

Тема: Проектування проекту з використанням шаблону Bridge.

Мета: Ознайомитись із шаблоном проектування, здобути навички проектування.

Завдання: Оберіть предметну область, розробіть програмне забезпечення з використанням шаблону Bridge. Опишіть розроблене ПЗ згідно шаблону, розробіть необхідні функціональні блоки.
Щоб краще зрозуміти ідею побудови шаблону Bridge і принципи його роботи, розглянемо конкретний приклад поетапно. Спочатку обговоримо встановлені вимоги, а потім проаналізуємо висновок основної ідеї шаблону і способи його застосування. Можливо, цей приклад може здатися занадто простим. Однак придивіться до обговорюваних в ньому концепціям, іям, а потім спробуйте згадати аналогічні ситуації, з якими нам доводилося стикатися раніше. Зверніть особливу увагу на наступне.

• Наявність варіацій в абстрактному представленні концепцій.

• Наявність варіацій в тому, як ці концепції реалізуються.

Гадаю, у вас не з'явиться сумнівів, що наведений нижче приклад має багато спільного з обговорювалася вище завданням підтримки декількох версій САПР. Однак ми не станемо попередньо обговорювати всі пропоновані вимоги. Як правило, приступаючи до вирішення завдання, не вдається відразу побачити всі існуючі варіації. Рекомендація. Формулюючи вимоги до проекту, намагайтеся якомога раніше і якомога частіше обмірковувати, що в ньому може змінюватися надалі. Припустимо, що нам потрібно написати програму, яка буде виводити зображення прямокутників за допомогою однієї з двох наявних графічних програм.

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

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

І чому. Такий підхід перегукується з філософією шаблонів Александера: "Кожен шаблон описує проблему, яка виникає в даному середовищі знову і знову, а потім пропонує принцип її вирішення таким способом.

Спробуємо застосувати даний підхід до нашого випадку і сформулюємо задачу, для вирішення якої призначений шаблон Bridge. Шаблон Bridge корисний тоді, коли є деяка абстракція і існує не ¬ скільки різних варіантів її реалізації. Шаблон дозволяє абстракції та реалі ¬ зації змінюватися незалежно один від одного. Зазначені характеристики якнайкраще відповідають нашій ситуації. Тому можна зробити висновок, що шаблон Bridge слід використовувати, навіть ще не знаючи до пуття, як він реалізується на практиці. Те, що абстракцію можна буде міняти незалежно від її реалізації, означає, що нові елементи абстракції можна буде додавати, не вносячи яких змін на рівні реалізації і навпаки. Існуюче у нас рішення не забезпечує подібної незалежності змін. Не викликає сумніву, що проект був би набагато краще, якби вдалося знайти рішення, що надає таку можливість. Зауваження. Зверніть особливу увагу на те, що, навіть не знаючи конкретних способів реалізації шаблону Bridge, ми змогли прийти до висновку про можливість і корисності його застосування в нашому проекті. Пізніше ви зрозумієте, що це зауваження справедливо щодо практично всіх шаблонів проектування. Іншими словами, завжди можна встановити, що застосування того чи іншого шаблону в даній предметній області буде можливо і полезн про, навіть не маючи точного уявлення про те, як саме він може бути реалізований.

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



Для того щоб вивчити шаблон Bridge, ми розглянули проблему, при якій в предметній області присутні дві варіації - геометричних фігур і графічних програм.

Геоме́трія (від дав.-гр. γη - Земля і μετρέω - вимірюю; землеміряння) - розділ математики, наука про просторові форми, відносини і їхні узагальнення.
У заданій предметній області кожна варіація змінюється незалежно. Труднощі з'явилися при спробі скористатися рішенням, побудованим на обліку всіх можливих конкретних ситуацій взаємодії. Подібне рішення, примітивним чином використовує механізм успадкування, призводить до створення громіздкого проекту, характеризується сильною пов'язаністю і слабкою зв'язністю, а отже, вкрай незручного в супроводі. При обговоренні шаблону Bridge ми слідували наступним стратегіям роботи сваріаціямі.

Знайдіть те, що змінюється, і інкапсулює це.

• Віддавайте перевагу композиції, а не спадкоємства.


КОНТРОЛЬНІ ПИТАННЯ:

  1. Що таке шаблон проектування?

  2. Опишіть основні характеристики шаблону Bridge.

  3. Які переваги та недоліки, на Вашу думку, має шаблон проектування Bridge?


ЛІТЕРАТУРА:

1. ISO 10014. Управление качеством — Указания по получению финансовых и экономических выгод.

2. ISO/IEC 12207:1995 «Information Technology — Software Life Cycle Processes» (информационные технологии – жизненный цикл программного обеспечения), ГОСТ Р ИСО/МЭК 12207-99.

3. Буч Г. Коналлен Д. Максимчук Р.А. Хьюстон К. Энгл М. Янг Б. Объектно-ориентированный анализ и проектирование с примерами приложений. – 3-е изд. М.: Вильямс, 2008. – 720 с.

4. Гонтарев И.В., Нижегородцев Р.М., Новиков Д.А. Управление проектами. М.: Диброком, 2009. – 384 с.

5. ГОСТ Р ИСО/МЭК 15288-2005. Системная инженерия. Процессы жизненного цикла систем



Практична робота № 4

Тема: Розробка та проектування вимог при конструюванні програмного забезпечення

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

Завдання: Обрати будь-яку тему: це може бути інформаційна система, експертна система, автоматизоване робоче місце, тощо.
Вихідні́ відо́мості - відомості, що містять довідкову інформацію про друковане видання, ідентифікують і класифікують його. Залежно від характеру видання вони розташовані на обкладинці, палітурці, титульному аркуші, поєднаному титульному аркуші, першій сторінці, останній сторінці, кінцевий сторінці видання.
Експе́ртна систе́ма - це методологія адаптації алгоритму успішних рішень однієї сфери науково-практичної діяльності в іншу. З поширенням комп'ютерних технологій це тотожна (подібна, заснована на оптимізуючому алгоритмі чи евристиках) інтелектуальна комп'ютерна програма, що містить знання та аналітичні здібності одного або кількох експертів щодо деякої галузі застосування, і здатна робити логічні висновки на основі цих знань, тим самим забезпечуючи вирішення специфічних завдань (консультування, навчання, діагностування, тестування, проектування тощо) без участі експерта (фахівця в конкретній проблемній галузі). Також визначається як система, яка використовує базу знань для вирішення завдань (видачі рекомендацій) у деякій предметній галузі. Цей клас програмного забезпечення спочатку розроблявся дослідниками штучного інтелекту в 1960-ті та 1970-ті і здобув комерційне застосування, починаючи з 1980-х. Часто термін система, заснована на знаннях використовується як синонім експертної системи, однак можливості експертних систем ширші за можливості систем, заснованих на детермінованих (обмежених, реалізованих на поточний час) знаннях.
Інформацíйна систéма (англ. Information system) - сукупність організаційних і технічних засобів для збереження та обробки інформації з метою забезпечення інформаційних потреб користувачів.
Автоматизо́ване робо́че мі́сце (АРМ) - індивідуальний комплекс технічних і програмних засобів, що призначений для автоматизації професійної праці фахівця і забезпечує підготовку, редагування, пошук і видачу на екран і друк необхідних йому документів і даних.
Опишіть предметну область обраної теми, тобто як взагалі програма працює, які є аналоги, які загальні переваги та недоліки. Також зробіть постановку задачі гіпотетичного проекту.
Сучасний світ не стоїть на місці, він постійно рухається вперед, змінюється, вдосконалюється. Виникають нові технології, які дозволяють полегшити життя людини, прискорити процес виробництва і тісно вплітаються в повсякденне життєдіяльність. Деякі з таких технологій роблять наше життя більш комфортним та зручним. Йдеться про програми, які присвячені автоматизації процесу харчування в ресторані, з розрахунку вартості страв, з формування оптимального меню відповідно до індивідуальними потребами людини. На жаль, на даний момент у світі існує дуже мало розробників, здатних реалізувати окреслену ідею. Відповідних програмних продуктів практично не існує, а якщо такі і є - вони, як правило, представляють собою завантажуване платне програмне забезпечення, вартість якого може досягати великих значень.
Програ́мний проду́кт (англ. programming product) - це: програмний засіб, програмне забезпечення, які призначені для постачання користувачеві (покупцеві, замовникові). програма, яку може запускати, тестувати, виправляти та змінювати будь-яка людина.
Варто відзначити, що подібний напрямок автоматизації досить нове. У наслідок цього можна зробити висновок, що програмне забезпечення в даній предметній області ще знаходиться в стадії зародження. Надалі можлива поява не тільки спеціалізованих програмних продуктів, а й цілих інтернет-ресурсів, завдяки яким людина може скласти для себе найбільш оптимальне меню.

У ході аналізу предметної області було розглянуто кілька програмних продуктів, один з яких називається «Кафе-8». «Кафе-8» - багатофункціональне ПЗ для ведення бухгалтерського та виробничого обліку в ресторанах, барах, кафе та інших підприємствах громадського харчування.

Сфера ресторанного господарства - це сфера надання послуг. Послуга харчування - є результатом економічної діяльності ресторанного підприємства, спрямована на задоволення найрізноманітніших потреб гостей.
Особливістю всієї лінійки програм «Кафе» є їх сумісність з програмою 1С, т.к. вони побудовані на базі її конфігурацій.

Це є незаперечним плюсом, тому що більшості бухгалтерів знайома і зрозуміла програмна середа 1С.

Вашим співробітникам, вже працювали з 1С, не доведеться переучуватися, відповідно в роботі не буде збоїв і простоїв.

Інтерфейс програми розроблений за принципом «Все - під рукою», програмою зручно користуватися, а її освоєння займає у користувача не більше 5-10 хвилин. Програма «Кафе8» надає наступні можливості:

 автоматичне заповнення калькуляційних карт страв;

 випуск продукції на підставі заданих калькуляцій;

 автоматичне списання матеріалів по випущеної продукції;

 автоматичне заповнення документів на реалізацію готової продукції;

Гото́ва проду́кція - продукція (товар), вироблена з використанням давальницької сировини (крім тієї частини, що використовується для проведення розрахунків за її переробку) і визначена як кінцева у контракті між замовником і виконавцем.

 автоматичний облік уваркі компонентів.

У програмі реалізована друк реєстрів випуску продукції, витрати матеріалів, друк меню і забірного листа.

Що стосується бухгалтерського супроводу, то програма дозволяє:

 вести роздільний виробничий і бухгалтерський облік витрат матеріалів;

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

 проводити групову обробку калькуляцій;

 програма гарантовано оновлюється до нових релізів 1С;

 сумісна з квартальною звітністю, що випускається фірмою 1С.

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

Програма дозволяє повністю автоматизувати облік у вашому ресторані, кафе або барі. Якщо зараз ви тільки приблизно знаєте, яка величина ваших витрат і доходів, то «Кафе-8» дозволяє зробити облік 100% точним. Нечистий на руку кухар не матиме жодного шансу не доповісти продуктів в блюдо, всі його дії можна проконтролювати по калькуляційних картах.

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

Станом на січень 2013 року на R-Keeper працюють більше 27000 ресторанів в 34 країнах світу. Наші клієнти - провідні оператори індустрії гостинності.

R-Keeper ™ - зареєстрована торгова марка компанії UCS.

Знак для товарів і послуг, також товарний знак, торгова марка, торговельна марка, англ. trademark - позначення, знак за яким товари та послуги одних осіб відрізняються від товарів та послуг інших осіб.
Наш продукт реалізується виключно через офіційних дилерів і представництва компанії в різних країнах. Контакти даних компаній зазначені в розділі Дилери. Рекомендуємо Вам, перш ніж звертатися з питань придбання, встановлення, обслуговування системи R-Keeper в яку-небудь фірму, яка пропонує ці послуги через інтернет або іншим способом, перевірити, чи є вона офіційним дилером UCS. Остерігайтеся шахраїв, інакше Ви можете постраждати як морально, так і матеріально.

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

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

Дипломна робота "Контролер для розподілених інформаційно-управляючих систем" була виконана в рамках реалізованого на практиці проекту з модернізації експлуатується розподіленої інформаційно-керуючої системи потоці-С для філії ПТС (Петербурзькі Телефонні Мережі) ВАТ "Північно-Західний Телеком".

PSTN (англ. Public Switched Telephone Network, рос. Телефонная сеть общего пользования, ТСОП, ТфОП) - це планетарна телефонна мережа загального користування (ТМЗК), для доступу до якої використовуються звичайні проводові телефонні апарати, міні- АТС і обладнання передавання даних.

Фактично, виконана робота стосувалася всіх рівнів системи, так як

проект передбачав:

- Модернізацію апаратної частини контролера нижнього рівня;

- Оновлення

існуючого ПЗ нижнього рівня;

- Оновлення існуючого ПЗ верхнього рівня;

- Проведення необхідних експериментів з апробації пропонованих рішень;

- Виконання монтажно і пуско-налагоджувальних робіт.

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

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

2.1 Опис сучасного стану системи потоці-С

У 2005 р. в OAO ПТС [3], [4] запущено в дослідно-промислову експлуатацію розподілена інформаційно-керуюча система (РІУС) Поток-С, призначена для моніторингу режимів теплопостачання, комерційного обліку споживання тепла спорудами цієї організації, а також забезпечення ряду функцій з дистанційного управління режимами теплопостачання об'єктів. Структура системи представлена ​​на малюнку 2.1.

Верхній рівень системи представлений ДПС, в якому організовано декілька робочих місць: АРМи диспетчера, адміністратора, комерційного обліку та інженера. АРМи об'єднані в ЛОМ.

Нижній рівень системи утворюють більше 100 будинків АТС, розміщених в різних районах міста СПб. Ці будівлі опалюються з використанням міських ТЕЦ і обладнані засобами обліку та регулювання подачі гарячої води в опалювальну систему АТС.

Комунікаційна складова системи організована за допомогою модемного зв'язку з використанням телефонних ліній загального користування. При цьому кожній станції виділена тільки одна телефонна лінія.

В даний час об'єкти ПТС можна розділити на дві групи за ознакою наявності автономного контуру регулювання тепловим режимом станції: ПТС-1 і ПТС-2 (рисунок 2.2).

Вузли обліку ПТС-1 обладнані тільки теплолічильниками (малюнок 2.3), що дозволяють дистанційно зчитувати параметри системи теплопостачання, то:

- Температура і тиск води;

- Об'ємний або масова витрата води;

Ви́трати води́ (стік) - кількість води, яка протікає за одиницю часу через поперечний переріз водотоку, наприклад, через живий переріз річки.

- Перенесена теплова енергія в подавальному та зворотному трубопроводі (на вході і виході системи опалення АТС).

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

Дані з теплолічильників знімаються в ручному або автоматичному режимі (за розкладом) і використовуються для виявлення нештатних ситуацій, наприклад порушення температурного режиму АТС, порушення договірних показників опалення, прорив трубопроводу і т.д.

Автома́тика (грец. αύτόματος - самодіючий) - галузь науки і техніки, яка розробляє технічні засоби і методи для здійснення технологічних процесів без безпосередньої участі людини.

Вузли обліку ПТС-2 крім теплолічильника обладнані контролером ECL Comfort 300 (малюнок 2.4), який відповідно до заданими параметрами здійснює автономне регулювання тепловим режимом станції.

Функції управління в підсистемі ПТС-2 реалізовані на базі спеціалізованого контролера ASK-Lab, розробленого в СКБ Державного Університету Аерокосмічного Приладобудування. Зовнішній вигляд контролера в підвалі ПТС представлений на рис. 2.5.

 

img_2849
Рисунок 2.5 - Контролер ASK-Lab в підвалі ПТС

Вузли теплопостачання, що входять в підсистему ПТС-2 забезпечені автоматизованими засувками (малюнок 2.6), управління якими може здійснюватися як теплорегулятор ECL COMFORT-300 в автономному режимі, так і в режимі ручного керування з АРМ інженера.

Автономний режим - режим роботи, за якого об'єкт, система, пристрій функціонують самостійно, без керування з боку верхнього рівня.



cut1_
Однією з головних функцій контролера ASK-Lab є забезпечення можливості прийняття екстрених заходів у разі виникнення аварійних ситуацій в опалювальній системі АТС. Виконавчими пристроями, підключеними до контролера, є два електроприводу і клапан зливу води. Так, у разі аварії в режимі ручного управління з АРМ інженера підсистеми ПТС-2 можна дистанційно перекрити воду в трубах, відкрити клапан для зливу води і таким чином запобігти псуванню дорогого устаткування.

  

2.2 Модернізація підсистеми ПТС-2



У такому вигляді (підрозділ 2.1) система експлуатувалася до вересня 2007 року. На підставі накопиченого досвіду у Замовника з'явилися вимоги до вдосконалення РІУС Поток-С.

У рамках дипломного проекту вирішувалися поставлені Замовником завдання з модернізації підсистеми ПТС-2, а саме:

1) Примусове вимикання електромоторів після закінчення тайм-ауту;

2) Забезпечення контролю положення засувок;

3) Підвищення надійності каналообразующей апаратури.

Модернізація ПТС-2 зажадала змін на декількох рівнях системи:

1) Апаратне забезпечення контролера ASK-Lab;

Дипло́мний прое́кт - кваліфікаційна робота, що призначена для об'єктивного контролю ступеня сформованості умінь вирішувати типові задачі діяльності, які, в основному, віднесені в освітньо-кваліфікаційних характеристиках до проектної (проектно-конструкторської) і виконавської (технологічної, операторської) робочим функціям.
Апара́тне забезпе́чення (англ. hardware; сленг. залі́зо) - комплекс технічних засобів, який включає електронний пристрій і, зокрема, ЕОМ: зовнішні пристрої, термінали, абонентські пункти тощо, які необхідні для функціонування тієї чи іншої системи; фізична частина ЕОМ.

2) Програмне забезпечення контролера ASK-Lab;

3) Програмне забезпечення АРМ інженера.

Роботи з модернізації підсистеми ПТС-2 велися в міжопалювальний сезон 2007 року і становлять суть дипломного проекту.


Примітка: До цієї практичної роботи не передбачені контрольні питання. Вони формуються на основі виконання завдання.
ЛІТЕРАТУРА:

1. ISO 10014. Управление качеством — Указания по получению финансовых и экономических выгод.

2. ISO/IEC 12207:1995 «Information Technology — Software Life Cycle Processes» (информационные технологии – жизненный цикл программного обеспечения), ГОСТ Р ИСО/МЭК 12207-99.

3. Буч Г. Коналлен Д. Максимчук Р.А. Хьюстон К. Энгл М. Янг Б. Объектно-ориентированный анализ и проектирование с примерами приложений. – 3-е изд. М.: Вильямс, 2008. – 720 с.

4. Гонтарев И.В., Нижегородцев Р.М., Новиков Д.А. Управление проектами. М.: Диброком, 2009. – 384 с.

5. ГОСТ Р ИСО/МЭК 15288-2005. Системная инженерия. Процессы жизненного цикла систем


Практична робота № 5

  1   2   3



  • Практична робота № 1 Тема
  • Завдання
  • Практична робота № 2 Тема
  • Практична робота № 3 Тема
  • Практична робота № 4 Тема