21292

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

Лекция

Информатика, кибернетика и программирование

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

Украинкский

2013-08-02

571.5 KB

69 чел.

Лекція 7. Діаграма послідовності

Вступ

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

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

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

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

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

1. Об'єкти

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

  Примітка

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

Рис. 8.1. Різні графічні примітиви діаграми послідовності

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

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

  Лінія життя об'єкта

  Лінія життя об'єкта (object lifeline) зображується пунктирною вертикальною лінією, асоційованої з єдиним об'єктом на діаграмі послідовності. Лінія життя служить для позначення періоду часу, протягом якого об'єкт існує в системі і, отже, може потенційно брати участь у всіх її взаємодіях. Якщо об'єкт існує в системі постійно, то і його лінія життя повинна продовжуватися по всій площині діаграми послідовності від самої верхньої її частини до самої нижньої (об'єкти 1 і 2 на рис. 8.1).

  Окремі об'єкти, виконавши свою роль у системі, можуть бути знищені (зруйновані), щоб звільнити займані ними ресурси. Для таких об'єктів лінія життя обривається в момент його знищення. Для позначення моменту знищення об'єкта в мові UML використовується спеціальний символ у формі латинської букви "X" (об'єкт 3 на рис. 8.1). Нижче цього символу пунктирна лінія не зображується, оскільки відповідного об'єкта в системі вже немає, і цей об'єкт повинен бути виключений з усіх наступних взаємодій.

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

Рис. 8.2. Графічне зображення різних варіантів ліній життя і фокусів управління об'єктів

  Фокус управління

  У процесі функціонування об'єктно-орієнтованих систем одні об'єкти можуть перебувати в активному стані, безпосередньо виконуючи певні дії або у стані пасивного очікування повідомлень від інших об'єктів. Щоб явно виділити таку активність об'єктів, у мові UML застосовується спеціальне поняття, що отримало назву фокусу управління (focus of control). Фокус управління зображується у формі витягнутого вузького прямокутника (див. об'єкт 1 на рис. 8.1), верхня сторона якого позначає початок отримання фокусу управління об'єкта (початок активності), а її нижня сторона - закінчення фокусу управління (закінчення активності). Цей прямокутник розташовується нижче позначення відповідного об'єкта і може замінювати його лінію життя (об'єкт 4 на рис. 8.2), якщо на всьому її протязі він є активним.

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

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

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

Рис. 8.3. Графічне зображення актора, рекурсії та рефлексивного повідомлення на діаграмі послідовності

2. Повідомлення

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

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

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

Рис. 8.4. Графічне зображення різних видів повідомлень між об'єктами на діаграмі послідовності

  В UML можуть зустрічатися декілька різновидів повідомлень, кожне з яких має своє графічне зображення (рис. 8.4).

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

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

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

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

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

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

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

  Галуження потоку управління

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

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

Рис. 8.5. Графічне зображення бінарного розгалуження потоку керування на діаграмі послідовності

Рис. 8.6. Графічне зображення тернарного розгалуження потоку керування на діаграмі послідовності

  Умовою розгалуження може служити сума знімаються клієнтом коштів зі свого поточного рахунку. Якщо ця сума перевищує $ 1000, то можуть знадобитися додаткові дії, пов'язані зі створенням і подальшим руйнуванням об'єкта 4. Якщо ж сума перевищує $ 50, але не перевищує $ 1000, то управління передається об'єкту 3. І, нарешті, якщо сума не перевищує $ 50, то управління отримує об'єкт 2. При цьому об'єкти 1, 2 і 3 постійно існують в системі. Об'єкт 4 створюється, тільки якщо справедливо перше з альтернативних умов. В іншому випадку він може бути ніколи не створений. Після виконання необхідних дій об'єкти 2 і 3 просто інформують об'єкт 1 про завершення відповідних операцій, не вимагаючи від нього ніяких дій (пунктирна стрілка). Об'єкт 4 після завершення своїх дій знищується, передаючи управління об'єкту 3, роблячи його активним (фокус управління).

  Стереотипи повідомлень

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

• "call" (викликати) - повідомлення, що вимагає виклику операції або процедури приймає об'єкта. Якщо повідомлення з цим стереотипом рефлексивне, то воно ініціює локальний виклик операції у самого послав це повідомлення об'єкта;

• "return" (повернути) - повідомлення, яке повертає значення виконаної операції або процедури викликав її об'єкту. Значення результату може ініціювати розгалуження потоку управління;

• "create" (створити) - повідомлення, що вимагає створення іншого об'єкта для виконання певних дій. Створений об'єкт може отримати фокус управління, а може і не отримати його;

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

• "send" (надіслати) - позначає посилку іншому об'єкту деякого сигналу, який асинхронно ініціюється одним об'єктом і приймається (перехоплюється) іншим. Відмінність сигналу від повідомлення полягає в тому, що сигнал повинен бути явно описаний в тому класі, об'єкт якого ініціює його передачу.

  Нижче подано діаграму послідовності для розглянутого вище випадку розгалуження, доповнена стереотипними значеннями (рис. 8.7).

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

  Примітка

  Відповідно до прийнятої в мові UML системі позначень такі імена операцій записуються на англійському з малої букви і одним словом, можливо, складається з декількох скорочених слів, написаних без пропусків і без лапок. Якщо немає ніяких додаткових обмежень з боку інструментальних засобів візуалізації канонічних діаграм, то справа смаку вітчизняного розробника, які позначення йому використовувати в російськомовній транслітерації. Можливо, для цієї мети більше підходить варіант з нижньою рискою, що виключає прогалини в імені операції: "сделать_вводімий_текст_ невидимим ()", ніж варіант з великими літерами в середині імені операції: "сделатьВводимыйТекстНевидимым ()".

Рис. 8.7. Діаграма послідовності зі стереотипними значеннями повідомлень

  Тимчасові обмеження на діаграмах послідовності

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

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

  Прикладами таких обмежень на діаграмі послідовності можуть служити ситуація, коли необхідно явно специфікувати час, протягом якого допускається передача повідомлення від клієнта до сервера або обробка запиту клієнта сервером:

• {время_пріема_сообщенія время_отправкі_сообщенія <1 сек.}

• {время_ожіданія_ответа <5 сек.}

• {время_передачі_пакета <10 сек.}

• {об'ект_1. время_подачи_сигнала_тревоги> 30 сек.}

  Примітка

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

  Коментарі або примітки

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

3. Приклад побудови діаграми послідовності

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

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

Рис. 8.8. Початковий фрагмент діаграми послідовності для моделювання телефонної розмови

  Процес взаємодії у цій системі починається з підняття трубки телефонного апарату перші абонентом. Тим самим він посилає повідомлення телефонному апарату с, яке переводить цей апарат в активний стан і викликає дію - подачу тонового сигналу в телефонну трубку для першого абонента. Наступна дія також ініціюється перший абонентом - набір цифр телефонного номера. Це представлено у формі ітеративного повідомлення зі знаком "*" ліворуч від його імені.

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

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

Рис. 8.9. Доповнений фрагмент діаграми послідовності для моделювання телефонної розмови

Рис. 8.10. Остаточний варіант діаграми послідовності для моделювання телефонної розмови

  Примітка

  Доповнити діаграму послідовності для цього прикладу тимчасовими обмеженнями пропонується виконати самостійно як вправи.

4. Заключні рекомендації з побудови діаграм послідовності

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

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

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

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


 

А также другие работы, которые могут Вас заинтересовать

55846. Время 34.5 KB
  Специфика урока состоит в том что он готовит учащихся через повторение времени к следующему блоку Распорядок дня.
55847. Минералы и горные породы 31.5 KB
  Анализ целеполагания Анализ структуры урока Анализ содержания учебного материала Анализ деятельности учителя на уроке. Задачи урока реальны для выполнения.
55850. Самоосвіта – одна із акмеологічних умов професійного росту вчителя 51.5 KB
  Самоосвіта вчителя є необхідною умовою професійної діяльності педагога. Не секрет що багато батьків приводячи дитину до школи просяться в клас до конкретного вчителя предметника або класного керівника.
55851. Методичний супровід формування та розвитку компетентності педагога шляхом самоосвіти 657 KB
  Одним з найбільш ефективних засобів підвищення професійної компетентності педагога вбачаємо у самоосвітній діяльності. Самоосвіта педагога - свідома діяльність з удосконалення своєї особистості як фахівця...
55852. Классный час на тему: Самооценка 45.5 KB
  Обсуждение с учащимися основных понятий Как Вы думаете что такое самооценка Учащиеся дают свои ответы Какие виды самооценки вы знаете Самооценка -– оценка человеком собственных качеств достоинств и недостатков.
55853. Відомості із синтаксису і пунктуації 237.5 KB
  3 З досвіду роботи 4 Фотофрагменти уроків 14 Серія уроків з української мови в 5му класі за темою: Відомості із синтаксису і пунктуації. 70 Анотація Матеріали розкривають методи і прийоми роботи над науково – методичною проблемою:Самореалізація особистості учня у процесі вивчення української мови. За ці роки працювала вихователем групи продовженого дня учителем початкових класів а з 1997 року учителем української мови та літератури. Тому працюючи учителем української мови я обрала для...
55854. Дистанційне навчання як інструмент для розвитку та самовдосконалення особистості сучасного вчителя 175.5 KB
  Якісно новими характеристиками таких освітніх інформаційно-комунікаційних мережевих систем є: орієнтація на потреби професійної діяльності педагога серед яких пріоритетною є потреба у безперервному самовдосконаленні та самореалізації...