Головна

шаблони моделювання

  1. TChart для візуалізації результатів моделювання
  2. TListView для візуалізації результатів моделювання
  3. Алгоритм моделювання.
  4. Аналіз можливостей мережі Петрі для моделювання процесів розвитку сучасного авіапідприємства.
  5. Аналіз основних пакетів для комп'ютерних розрахунків і моделювання електричних, електронних і електроенергетичних пристроїв і систем
  6. Вплив 2-го уровеня: шаблони установок гучності.
  7. ГЛАВА 1. НАВАНТАЖЕННЯ І МЕТОДИ ЇХ МОДЕЛЮВАННЯ

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

1 Моделювання сімейного стану.Ситуацію предметної області, описану наступними пропозиціями: «кожне ФІЗИЧНА ОСОБА (чоловічої статі) може бути чоловіком іншого ФІЗИЧНОЇ ОСОБИ (жіночої статі)» і, зі зворотного боку, «кожне ФІЗИЧНА ОСОБА (жіночої статі) може бути дружиною іншого ФІЗИЧНОЇ ОСОБИ (чоловічої статі) », можна змоделювати, використовуючи рекурсивную зв'язок. Це зв'язок між об'єктами одного класу об'єктів. Такий зв'язок може мати всі властивості, притаманні будь-якій іншій зв'язку. Приклад наведено на малюнку 8. На малюнку зображена рекурсивна зв'язок, що має з обох сторін однаковий тип - «один», і опціонально «необов'язкова». на представленій ER-діаграмме відображені і назви зв'язків, розглянута методологія зображення ER-діаграм дозволяє це зробити.



Малюнок 8 - Приклад рекурсивної зв'язку

2 Моделювання ієрархії даних. Ієрархія даних спостерігається, якщо в моделі предметної області присутній:

- Довільне число ієрархій класів об'єктів;

- Однакові властивості у класів об'єктів, що входять в ієрархію;

- Зв'язку між такими класами об'єктів однакові.

На малюнку 9 представлений фрагмент ER-діаграмми, виконаний за методологією Річарда Баркера і відображає приклад ієрархії даних.

 
 

Малюнок 9 - Приклад ієрархії даних

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

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

Заміна ієрархії даних рекурсивної зв'язком здійснюється за наступним алгоритмом:

- Створюється один клас об'єктів, що містить властивості, характерні для кожного класу об'єктів в ієрархії даних;

- Класу об'єктів присвоюється загальне ім'я (в ієрархії підпорядкування підрозділів підприємства це може бути, наприклад, клас об'єктів з ім'ям «СТРУКТУРНА ОДИНИЦЯ ПІДПРИЄМСТВА»);

- Створюється додатковий клас об'єктів, який буде відображати назву для відмінності кожного вузла ієрархії даних, наприклад, клас об'єктів «ТИП СТРУКТУРНОЇ ОДИНИЦІ ПІДПРИЄМСТВА».

Як висновок, необхідно зробити наступні зауваження:

- Шаблон має один недолік: класи об'єктів, що знаходяться на всіх рівнях ієрархії повинні мати однакові властивості;

- Ієрархія, змодельована як рекурсивна зв'язок, повинна бути необов'язковою в обох напрямках. Обов'язкова гілка, спрямована вгору або вниз, створює нескінченну ієрархію, яка не має застосування в реальному світі;

- Якщо при перетворенні моделі предметної області відбувається злиття частин діаграми в одну, то необхідно знайти в предметної області клас об'єктів «ТИП», який дозволить відобразити унікальність кожної частини

Приклад використання шаблону, що моделює ієрархію даних, наведено на малюнку 10.

 
 

Малюнок 10 - Приклад використання шаблону для моделювання ієрархії даних.


3 Розрив зв'язків M: M. Наявність зв'язку M: M в ER - Діаграмі допустимо, але необхідно пам'ятати, що це ознака не адекватного відображення предметної області, вона не дообследоваться. Треба намагатися знайти клас об'єктів (сутність), який розірве такий зв'язок. Як правило, це якийсь документ, або позиція документа. Наприклад, зв'язок «багато до багатьох» між класами об'єктів «ПОСТАЧАЛЬНИК» і «ТОВАР» («кожен ПОСТАЧАЛЬНИК може постачати багато ТОВАРІВ» та «кожен ТОВАР може поставлятися різними постачальниками») може бути розірвана за допомогою таких класів об'єктів, як «ПОЗИЦІЯ НАКЛАДНОЇ »,« ПОЗИЦІЯ ПРАЙС - ЛИСТА »,« ПОЗИЦІЯ ДОГОВОРУ »та інші. На малюнку 11 наведено приклад розриву зв'язку М: М. В ролі постачальника в прикладі виступає юридична особа.

 
 

Малюнок 11 - Розрив зв'язку М: М

Необхідно відзначити, що класи об'єктів, що розривають зв'язок М: М, як правило, містять властивості, значення яких динамічно змінюється. Це такі властивості, як «кількість», «ціна».

4 Моделювання ролей. Під ролями людини або організації в предметної області розуміють різні посади і обов'язки. Якщо ролі моделювати за допомогою класів об'єктів, то може виникнути ситуація, що об'єкти, що належать різним класам, дублюватимуть один одного. Наприклад, клас об'єктів «ЛІКАР» і клас об'єктів «ПАЦІЄНТ» створені для відображення різних ролей людини - один лікує, інший лікується. У разі якщо лікар стає пацієнтом, то інформація про нього повинна бути також відображена і в класі об'єктів «ПАЦІЄНТ». Виникає ситуація інформаційного дублювання. Правильне рішення - ролі повинні моделюватися за допомогою зв'язків, Необхідно створювати ситуацію, щоб об'єкт одного і того ж класу об'єктів міг виступати в кількох ролях.

Приклад неправильного моделювання ролей наведено на малюнку 12, правильного - на малюнку 13.


 
 

Малюнок 12 - Неправильне моделювання ролей

 
 

Малюнок 13 - Правильне моделювання ролей


На малюнку 12 класи об'єктів «ПОСТАЧАЛЬНИК» і «СПОЖИВАЧ» виділені окремо. При виникненні ситуації, що якась юридична особа стане виступати як в ролі постачальника, так і в ролі споживача, модель буде неадекватно відображати предметну область - інформація буде продубльована. Знову ж правильним моделюванням ситуації буде виділення одного класу об'єктів «ЮРИДИЧНА ОСОБА», а ролі «постачальник» і «споживач» відобразити у вигляді відповідних зв'язків (рисунок 13).

Приклади предметних областей, де необхідно моделювати ролі, наведені в таблиці 9.

Таблиця 9 - Приклади моделювання ролей.

 Предметна область  неправильне моделювання  правильне моделювання
 Купівля-продаж, поставка товару  Класи об'єктів: ПОКУПЕЦЬ, ПРОДАВЕЦЬ, ПОСТАЧАЛЬНИК  Класи об'єктів: ЮРИДИЧНА ОСОБА або ФИЗИЧЕСКОЕ ЛІЦО.Связі (ролі): купує, продає, постачає
 Освітня установа, навчання  Класи об'єктів: АБИТУРИЕНТ, СТУДЕНТ, ВИКЛАДАЧ, АСПІРАНТ  Класи об'єктів: ФІЗИЧНА ОСОБА, РОБОТА ФІЗИЧНОЇ ОСОБИ, НАВЧАННЯ ФІЗИЧНОЇ ОСОБИ, ТИП НАВЧАННЯ ФІЗИЧНОЇ ОСОБИ, ТИП ПЕРЕМІЩЕННЯ ФІЗИЧНОГО ЛІЦА.Связі (ролі): здає документи, працює, навчається.
 документообіг  Класи об'єктів: ВХІДНИЙ ДОКУМЕНТ, ВИХІДНИЙ ДОКУМЕНТ, накази, розпорядження  Класи об'єктів: ДОКУМЕНТ, ПОЗИЦІЯ ДОКУМЕНТА, ТИП ДОКУМЕНТА, ТИП ПЕРЕМІЩЕННЯ ДОКУМЕНТА.Связі (ролі): відноситься (до типу)

На малюнку 14 наведено фрагмент ER-діаграмми, що відображає предметну область «Управління персоналом». Клас об'єктів «ПОЗИЦІЯ НАКАЗУ ПРО ПЕРЕМІЩЕННЯ» відображає відомості про переміщення співробітників (фізичних осіб) на підприємстві, клас об'єктів «ВИД ПЕРЕМІЩЕННЯ» - види кадрових переміщень - прийом, переклад, звільнення тощо. Між класами об'єктів «НАКАЗ Про ПЕРЕМІЩЕННІ» і «ПОЗИЦІЯ НАКАЗУ ПРО ПЕРЕМІЩЕННЯ» присутні три зв'язку, дві з них - моделюють ролі:

- «Кожен НАКАЗ Про ПЕРЕМІЩЕННІ повинен бути підписаний одним співробітником, що є начальником відділу кадрів, про що є відповідна інформація в класі об'єктів ПОЗИЦІЯ НАКАЗУ ПРО ПЕРЕМІЩЕННЯ», начальник відділу кадрів може підписувати багато наказів »;


 
 

Малюнок 14 - Приклад моделювання ролей

- «Кожен НАКАЗ Про ПЕРЕМІЩЕННІ повинен бути підписаний одним співробітником, що є керівником підприємства, про що є відповідна інформація в класі об'єктів« ПОЗИЦІЯ НАКАЗУ ПРО ПЕРЕМІЩЕННЯ », керівник підприємства може підписувати багато наказів».

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

У розглянутому прикладі має підтримуватися наступне семантичне твердження: «дата підписується наказу повинна бути більш пізньої, ніж дата наказів, в яких визначені ролі підписують наказ осіб».




архітектура БД | моделі даних | Життєвий цикл БД | Методи проектування БД | Формування зовнішнього рівня БД | Структура підприємства. Інформаційні потоки | Функціональна структура АІС | класи об'єктів | Зв'язки між класами об'єктів | Рівні доступу користувачів |

© 2016-2022  um.co.ua - учбові матеріали та реферати