Cetus Group
Cetus Logo
Информационные системы и программное обеспечение



Поддержка

 
Статьи
Размещено 06.12.2005 : Редакция 20.02.2006
А.Г. © Реалізація моделі переходів станів

Одним з видів моделей (програмних систем) є математичні моделі, а математичне моделювання системи розглядається як вища форма дослідження, бо дозволяє найбільше загальним чином в простій символьній формі визначити відношення між елементами системи. Л. Берталанфі сказав "... объект, в частности система, может быть охарактеризован только через свои связи в широком смысле слова, т. е. через взаимодействие составляющих элементов" [1]. Не зважаючи на це, рівень висвітлення проблем математичного моделювання програмних систем в літературі з питань проектування програмого забезпечення - в тому числі, інформаційних і інформаційно-управляючих систем - не відповідає важливості цього питання. Наприклад, в [2,3] ([4]) розглядаються методи проектування програмних систем, але аспекти, пов'язані з математичним моделюванням не висвітлені. Проблемою звичайно є не відсутність математичних моделей програмних систем у вказаних роботах, а той факт, що проектанти програмних систем в більшості випадків прямо запозичують описані в цих роботах методології проектування. Як наслідок, використання математичних моделей при розробці програмного забезпечення значно частіше буває пов'язане з предметною галуззю проектуємої системи ніж з програмним кодом.

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

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

В той же час функціональна залежність між подією, станом і реакцією системи може бути представлена у вигляді функціонала r=f(e,s) (де r - реакція, e - подія, s - поточний стан), або, в програмному коді, у вигляді структури, що описує таку залежність. Для ілюстрації нижче наведено текст програми мовою Python. Власне, в якості математичної моделі системи можна розглядати масив 'stat' з рядків, кількість яких має відповідати кількості переходів на граіф. Кожен рядок включає:
-- "поточний стан",
-- "подію",
-- "тригер блокування переходу",
-- "функцію, що забезпечує перехід",
-- "новий стан".
Клас 'Automat', що включає всього десять рядків програмного коду, лише забезпечує інтерпретацію цієї моделі у відповідності до поточних подій. Для спрощення моделі прийняті однакові назви для подій, що подаються на вхід системи (поле 2 масиву 'stat'), і функцій, що забезпечують зміну станів в системі (поле 4).

import sys

class Automat:
    def __init__(self,status):
	self.status = status
	self.currentStatus = status[0][0]
    def Event(self,eventTrigger):
        for i in self.status:
    	    if(self.currentStatus == i[0] and eventTrigger == i[1] and i[2]):
		i[3]()
		self.currentStatus = i[4]
		break
				    
def SetFull():
    print "Set Full"
def SetEmpty():
    print "Set Empty"
def Put():
    print "Put"
def Get():
    print "Get"
def Exit():
    print "Exit"
    sys.exit()

stat = (
    ["LoadState","SetFull",1,SetFull,"Full"],
    ["LoadState","SetEmpty",1,SetEmpty,"Empty"],
    ["Full","Get",1,Get,"Empty"],
    ["Empty","Put",1,Put,"Full"],
    ["Full","Exit",1,Exit,"SaveState"],
    ["Empty","Exit",1,Exit,"SaveState"],
)

automat = Automat(stat)

automat.Event("SetFull")
automat.Event("Get")
automat.Event("Exit")

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

Література:
1.Берталанфи Л. фон. История и статус общей теории систем // Системные исследования. Ежегодник. 1973. М., 1973. С. 20-36
2.Брукс Ф. Мифический человеко-месяц или как создаются программные системы. - М.: Символ Плюс, 1999. - 304 с.
3.Буч, Гради. Объектно-ориентированный анализ и проектирование с примерами приложений на С++, 2-е изд. – М.: «Издательство БИНОМ», СПб.: «Невский Диалект», 1999. – 560 с.
4.Буч, Грейди. Рамбо, Джеймс. Джекобсон, Айвар. Язык UML. Руководство пользователя. - М.: ДМК, 2000. - 432с.


Copyright©2005, Cetus Group . All rights reserved.