Словник даних

Вступ

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

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

1. Загальна характеристика предметної області

1. Предметна область: Побудова інформаційної платформи

2. Галузь: будівництво

3. Бізнес-функція: Календарне планування

4. Мета: розробка системи оптимізації робіт та часу.

Логічне проектування інформаційної платформи.

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

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

В більшості складних календарних планів існують до 6 варіантів моментів початку, закінчення, тривалості робіт та резервів часу. Це – ранні, пізні, базові, планові і фактичні дати, реальний та вільний резерв часу. Методи розрахунку сіткових моделей дозволяють розраховувати тільки ранні та пізні дати. Базові та поточні планові дати необхідно вибирати з врахуванням інших факторів. Існує три варіанти вибору:

1. Календарний план за датою раннього початку. Використовується для стимулювання виконавців проекту;

2. Календарний план за датою пізнього завершення. Використовується для представлення виконання проекту в кращому вигляді для споживача;

3. Календарний план, який вибирається для згладжування ресурсів або для представлення замовнику найбільш ймовірного закінчення.

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

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

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

Робота з нульовим резервом часу називається критичною, її тривалість визначає тривалість реалізації проекту загалом. Критична тривалість – мінімальна тривалість, протягом якої може бути виконаний весь комплекс робіт проекту.

Словник даних

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

2. Архітектура

2.1. Цілі розробки проекту

Ми безпосередньо у нашій роботі розглядаємо процес Створення лінійного графіку робіт, в якому виконуються наступні функції (Таблиця 2.1.)

Рис.2.1. Приклад побудови дерева цілей

Розглянемо детальніше кожну функцію (опис функцій):

· Аналіз робіт – розгляд кожної роботи з визначенням витрат часу на роботу

· Мінімізація часу на будівництво - Визначення оптимального та мінімального часу виконання будівельних робіт

· Побудова лінійного графіку робіт – створення графіку на основі отриманих даних

2.2. Аналіз функції

Дана система створюється для виконання наступних цілей:

· Визначення ранніх термінів робіт;

· Визначення оптимального часу;

· Побудова графіку робіт

Рис.2.2. Дерево функцій

2.3. Моделі потоків

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

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

Будуємо чорну скриньку нашої предметної області за технологією IDF0

На вхід нам поступають:

· Робота

· Опис роботи

· Часовий параметр

· Ранні терміни

Зовнішні джерела інформації:

· Стандарти на будівництво

· БД

Управління:

· ЕОМ

· Люди

На виході:

· Лінійний графік робіт

· Аналіз робіт

· Мінімізація часу на будівництво

Рис.2.3. Модель чорної скриньки «Побудова інформаційної платформи»

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

Тепер робимо декомпозицію на основі чорної скриньки

Рис. 2.4. Декомпозиція головної функції «Побудова інформаційної платформи»

2.4. Об'єктно-орієнтований підхід

Опис прецедентів

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

Таблиця.2.1. Опис прецедентів

Типовий хід подій

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

Таблиця.2.2. Виконавець-система

Кожен прецедент повинен мати назву, що відповідає його призначенню і відрізняє цей прецедент від інших. Назва прецеденту має бути унікальною всередині пакета. В IBM Rational Rose назва прецеденту — це текстовий рядок, що складається з довільної кількості літер, цифр і деяких розділових знаків за винятком двокрапки, що відокремлює назву прецеденту від назви пакета. На практиці для пойменування прецедентів використовують стислі фрази з дієсловами або віддієслівними іменниками, що позначають деяку поведінку і використовуються у предметній області проектованої ІС. Текст починається з великої літери.

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

При визначенні прецедентів часто виникають проблеми, пов’язані з вибором рівня їх деталізації. Рекомендацією є включення до окремого прецеденту окремого елемента функціональності, що здійснюється від початку до кінця і приносить значущий для актора результат. Водночас різні дії, що ініціюються одним актором і виконуються з однією сутністю, наприклад, введення, коригування та знищення даних у певному довіднику, також доцільно об’єднати в один прецедент. Модель типової системи зазвичай містить від 20 до 50 прецедентів.

В IBM Rational Rose варіантам використання можуть бути присвоєні пріоритети (ранги), що визначатимуть порядок, у якому слід працювати над ними.

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

Актор (діюча особа) — це зовнішня стосовно ІС сутність, яка може взаємодіяти з системою. Акторами можуть бути люди, зовнішні ІС або пристрої. При цьому актор — це не конкретна особа чи пристрій, а логічно пов’язана між собою множина ролей, що їх відіграють користувачі прецедентів під час взаємодії з ними. Наприклад, як актор «Бухгалтер» може виступати весь штат бухгалтерії. Водночас одна особа може відігравати кілька ролей стосовно системи. Головний бухгалтер може виступати як актор з таким іменем, але може використовувати систему і як актор «бухгалтер». Кожен актор може використовувати систему по-різному, тобто ініціювати виконання різних прецедентів.

На основі таблиці прецедентів (Табл.2.1, табл..2.2.) будуємо UML- діаграму, де показуємо зв’язки та взаємодію між виконавцем та системою

Рис.2.3. UML-діаграма «Побудова інформаційної платформи»

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

У мові UML є кілька стандартних видів відношень між акторами і варіантами використання:

· асоціації;

· включення;

· розширення;

· узагальнення;

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

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

Включення у мові UML — це різновид відношення залежності між базовим варіантом використання і його спеціальним випадком. При цьому відношенням залежності є таке відношення між двома елементами моделі, при якому зміна одного елемента (незалежного) приводить до зміни іншого елемента (залежного).

Діаграма послідовності

Діаграма послідовності — в UML, діаграма послідовності відображає взаємодії об'єктів впорядкованих за часом. Зокрема, такі діаграми відображають задіяні об'єкти та послідовність відправлених повідомлень.

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

Визначені стандартом UML 2.0 діаграми послідовностей мають ті ж можливості що і визначені стандартом UML 1.x, та підтримують додаткові можливості зміни стандартного порядку повідомлень.

3. Інфологічна модель проблемної області

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

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

Модель «сутність-зв'язок» (ER-модель)— модельданих, яка дозволяє описувати концептуальні схеми за допомогою узагальнених конструкцій блоків. ER-модель — це мета-модель даних, тобто засіб опису моделей даних. Існує ряд моделей для представлення знань, але одним з найзручніших інструментів уніфікованого представлення даних, незалежного від реалізовуючого його програмного забезпечення, є модель «сутність-зв'язок». Важливим є той факт, що з моделі «сутність-зв'язок» можуть бути породжені всі існуючі моделі даних (ієрархічна, мережева, реляційна, об'єктна), тому вона є найбільш загальною.

4. Список використаної літератури

1. Ізмайлова О.В. Системний аналіз та проектування комп’ютерних інформаційних систем. Методичні вказівки до курсової роботи для студентів спеціальності 6.050101102 «Інформаційні технології проектування». - К.: КНУБА, 2012. –

2. Шарапов О.Д., Дербенцев В.Д., Семьонов Д.Є. Системний аналіз: Навчально-метод. посібник для самост. вивчення дисципліни / Київський національний економічний ун-т — К.: КНЕУ, 2003. — 154с.