21290

Діаграма станів

Лекция

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

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

Украинкский

2013-08-02

479.5 KB

38 чел.

Лекція 5. Діаграма станів

Вступ

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

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

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

  Раніше, ми відзначали, що кожна інформаційна система характеризується не тільки структурою складових її елементів, але і деяким поведінкою або функціональністю. Для загального уявлення функціональності модельованої системи призначені діаграми варіантів використання, які на концептуальному рівні описують поведінку системи в цілому. Але на даному етапі моделювання наступне завдання полягає в тому, щоб представити поведінку більш детально на логічному рівні, тим самим розкрити сутність відповіді на запитання: «В процесі якої поведінки система забезпечує необхідну функціональність?».

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

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

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

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

1. Автомати в UML

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

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

Рис. 7.1 Найпростіший приклад діаграми станів для технічного пристрою типу комп'ютер

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

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

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

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

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

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

  Формалізм звичайного автомата заснований на виконанні таких обов'язкових умов:

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

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

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

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

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

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

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

2. Стан

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

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

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

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

Рис. 7.2 Графічне зображення станів на діаграмі станів

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

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

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

  <Мітка-дії '/' вираз-дії>

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

  Перелік міток дії має фіксовані значення в мові UML, які не можуть бути використані в якості імен подій. Ці значення наступні:

Entry [Ентре] - ця позначка вказує на дію, специфіковану наступним за нею вираженням дії, що виконується в момент входу в даний стан (вхідний дія);

Exit [Екзит] - ця позначка вказує на дію, специфіковану наступним за нею вираженням дії, що виконується в момент виходу з цього стану (вихідна дія);

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

Include [інклюд] - ця позначка використовується для звернення до подавтомату, при цьому наступне за нею вираз дії містить ім'я цього подавтомата.

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

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

Рис. 7.3 Приклад стану з непорожній секцією внутрішніх дій

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

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

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

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

3. Перехід

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

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

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

  <Сигнатура події >'['< сторожове умова> ']' <вираз дії>.

  При цьому сигнатура події описує деяка подія з необхідними аргументами:

  <Назва події >'('< список параметрів, розділених комами >')'.

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

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

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

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

  Сторожеве умова

  Сторожеве умова (guard condition), якщо воно є, завжди записується в прямих дужках після події-тригера і являє собою деяке булеве вираз. Нагадаємо, що булеве вираз повинен приймати одне з двох взаємно виключають значень: "істина" або "брехня". З контексту діаграми станів повинна явно слідувати семантика цього виразу, а для запису виразу може використовуватися синтаксис мови об'єктних обмежень, основи якого викладені в додатку.

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

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

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

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

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

Рис. 6.5. Діаграма станів для моделювання поштової програми-клієнта

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

  Примітка

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

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

  Вираз дії

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

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

  Як приклад вираження дії (див. рис. 6.5) може служити "розірвати телефонне з'єднання (телефонний номер), яке повинно бути виконано відразу після встановлення істинності (" істина ") сторожового умови" поштову скриньку на сервері порожній ".

  Іншим прикладом може служити очевидна ситуація з виділенням графічних об'єктів на екрані монітора при одноразовому натисненні лівої кнопки миші. Мається на увазі обробка сигналів від користувача при виділенні тих або інших графічних примітивів (піктограм). У цьому випадку відповідний перехід може мати наступний рядок тексту: "натиснута і відпущена ліва кнопка миші (координати) [координати в області графічного об'єкта] / виділити об'єкт (колір). Результатом цього тригерній переходу може бути, наприклад, активізація деяких властивостей об'єкта (розмір файлу в рядку стану) або подальше його видалення в кошик.

  Примітка

  Іноді після вираження дії може бути записано повідомлення у форматі: 'Л' <ім'я об'єкта приймача повідомлення> '.' <Ім'я посилається повідомлення> '(' <параметр >':'< тип >,')'. При цьому повідомлення має суто інформаційний характер і не передає управління на об'єкт-приймач повідомлення.

4. Складений стан і підстан

  Складений стан (composite state) - такий складний стан, який складається з інших вкладених у нього станів. Останні будуть виступати по відношенню до першого як підстани (substate). Хоча між ними має місце відношення композиції, графічно всі вершини діаграми, які відповідають вкладеним станам, зображуються усередині символу складеного стану (рис. 6.6). У цьому випадку розміри графічного символу складеного стану збільшуються, так щоб вмістити в себе всі підстани.

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

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

  Послідовні підстани

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

  Для прикладу розглянемо як модельованого об'єкта звичайний телефонний апарат. Він може перебувати в різних станах, одним з яких є стан дозвону до абонента. Очевидно, для того щоб зателефонувати, необхідно зняти телефонну трубку, почути тоновий сигнал, після чого набрати потрібний номер телефону. Таким чином, стан дозвону до абонента є складовим і складається з двох послідовних підстанів: "підняти телефонну трубку" і "набрати телефонний номер". Фрагмент діаграми станів для цього прикладу містить одне складне стан і два послідовних підстанів (рис. 6.7).

Рис. 6.7. Приклад складеного стану з двома вкладеними послідовними підстани

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

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

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

  Паралельні підстани

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

  Однак окремі паралельні підстани можуть, у свою чергу, складатиметься з декількох послідовних підстанів (подавтомати 1 і 2 на рис. 6.8). У цьому випадку за визначенням об'єкт може знаходитися тільки в одному з послідовних підстанів подавтомата. Таким чином, для абстрактного прикладу (мал. 6.8) припустимо одночасне знаходження об'єкта в підстани (1, 3, 4), (2, 3, 4), (1, 3, 5), (2, 3, 5). Неприпустимо знаходження об'єкта одночасно в підстани (1, 2,3) або (3, 4, 5).

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

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

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

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

Рис. 6.9. Складений стан з прихованою внутрішньою структурою та спеціальної піктограмою

5. Історичне стан

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

  Історичне стан (history state) застосовується в контексті складеного стану. Воно використовується для запам'ятовування того з послідовних підстанів, яке було поточним в момент виходу з складного стану. При цьому існує два різновиди історичного стану: недавнє і давнє (рис. 6.10).

Рис. 6.10. Графічне зображення недавнього (а) і давнього (б) історичного стану

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

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

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

  З іншого боку, запам'ятоване стан, у свою чергу, також може бути складовим станом. Давнє історичний стан (deep history state) позначається у формі невеликої кола, в яку поміщена латинська літера "Н" з символом "*" (рис. 6.10, б) і служить для запам'ятовування всіх підстанів будь-якого рівня вкладеності для поточного подавтомата.

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

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

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

6. Складні переходи

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

  Переходи між паралельними станами

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

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

Рис. 6.11. Графічне зображення паралельного переходу з паралельних станів (а) і паралельного переходу в паралельні стану (б)

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

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

  Переходи між складовими станами

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

Рис. 6.12. Різні варіанти переходів в (з) складене стан

  Інколи бажано реалізувати ситуацію, коли вихід з окремого вкладеного стану відповідав би виходу і з складеного стану теж. У цьому випадку зображають перехід, який безпосередньо виходить із вкладеного підстани за кордон суперсостоянія (перехід з на рис. 6.12). Аналогічно, допускається зображення переходів, що входять ззовні складеного стану в окреме вкладене стан (перехід а на рис. 6.12).

  Синхронізуючі стану

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

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

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

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

Рис. 6.13. Діаграма станів для прикладу з будівництвом будинку

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

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

Рис. 6.14. Діаграма станів процесу функціонування телефонного апарату

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

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

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

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

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

  Примітка

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

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

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

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

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

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

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

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

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

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


 

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

8203. Мастерство педагогического взаимодействия 18.78 KB
  Мастерство педагогического взаимодействия. Деятельность учителя сложна, ответственна, трудоемка. Его иногда называют навечно вызванный к доске. Важнейшим инструментом деятельности педагога является общение. Можно выделить следующие функции общения...
8204. Воспитание в семье 35.59 KB
  Воспитание в семье План Семейное воспитание как одна из древнейших форм передачи жизненного опыта. Социальные процессы, определяющие характер современного семейного воспитания. Культура как цель и средство семейного воспитания. Проблемы семейного во...
8205. Проблемы семейного воспитания как аспект профессиональной деятельности культуролога 18.35 KB
  Проблемы семейного воспитания как аспект профессиональной деятельности культуролога. В своей профессиональной деятельности культурологи (в зависимости от специализации) выполняют функции преподавателя, педагога-консультанта, организатора досуга дете...
8206. Место педагогической профессии в социуме 27.71 KB
  Место педагогической профессии в социуме. Жрец или ремесленник? Место педагогической профессии в социуме (из истории вопроса). Профессия и должность воспитателя (учителя) появляются уже в эпоху древних цивилизаций. И уже в эту пору (III-II тысячел...
8207. Сущность и закономерности эстетического воспитания 25.01 KB
  Сущность и закономерности эстетического воспитания ПЛАН: Педагогическая сущность понятий эстетическое воспитание и художественное образование. Виды эстетической деятельности и их роль в эстетическом развитии личности. Своеобразие эстетической деятел...
8208. Сущность, движущие силы, противоречия и логика учебного процесса. Основные функции обучения: образовательная, воспитательная и развивающая 47.5 KB
  Сущность, движущие силы, противоречия и логика учебного процесса. Основные функции обучения: образовательная, воспитательная и развивающая. Обучение - это совместная целенаправленная деятельность учителя и учащихся, в ходе которой осуществляетс...
8209. Технология коллективной творческой деятельности. Методика КТД 38 KB
  Поскольку основной формой функционирования педагогического процесса является коллектив, то технология воспитательного мероприятия может рассматриваться в контексте общей технологии организации коллективной творческой деятельности.Технология коллекти...
8210. Система географических знаний учащихся средней школы. Этапы, методы и средства их формирования 25 KB
  Под системой знаний понимается комплекс взаимосвязанных знаний, образующих определенную целостность. В состав географических знаний о современном мире включают основные теории и учения, знания о процессах и явлениях, знания об объектах. Логика их фо...
8211. Особенности педагогической профессии: виды педагогической деятельности, структура, ценностные характеристики 27 KB
  Особенности педагогической профессии: виды педагогической деятельности, структура, ценностные характеристики. Традиционно основными видами педагогической деятельности являются преподавание и воспитательная работа, в профессиональной школе целесообраз...