CC BY
39
ООБД обеспечивают более естественный переход от концептуальной структуры БД к логической. В отличие от реляционных БД в ООБД не происходит декомпозиции объектов, выделенных на этапе моделирования, они представляются в том же виде. ООБД определяют возможность создания и использования данных сложных типов. При этом для создания нового типа необходимо унаследовать характеристики любого имеющегося типа, наиболее подходящего по своему поведению и состоянию, расширить недостающие операции и атрибуты и переопределить уже имеющиеся. Полученные объектно-ориентированные структуры обладают высокой степенью модульности, что позволяет вносить в них изменения наиболее простым способом. При этом изменения влияют на один класс (или связанную подсистему классов) и могут эффективно управляться и проверяться.
Каждая из рассмотренных технологий имеет свои преимущества и недостатки, какой подход выбрать - зависит от поставленных задач. Если на предприятии оперируют сложными типами данных, занимающими большой объем, целесообразнее использовать объектно-ориентированный подход или подумать о выборе объектных надстроек. Если данные простого типа, вероятнее нужно принять решение в пользу современных реализаций РСУБД.
Кроме того, производители ОСУБД, в том числе фирмы Versant и Objectivity, предлагают продукты, которые связывают объектные БД и существующие реляционные. Такие БД, получившие название гибридных, расширяют реляционные БД и обеспечивают поддержку объектов, которые воспринимаются как данные особого типа.
В любом случае сначала нужно взвесить все «за» и «против» для каждого подхода. Думаю, что еще достаточно длительное время предпочтения будут в пользу реляционных технологий, хотя объектно-ориентированные СУБД уже сейчас играют весьма значительную роль во многих сферах и эта роль становится все более заметной.
Литература
1. Андреев А. М., Березкин Д. В. Выбор СУБД для построения информационных систем корпоративного уровня на основе объектной парадигмы. НПЦ “ИНТЕЛТЕК ПЛЮС” http://www.inteltec.ru/publish/articles/objtech/4kx4 9.shtml
2. Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений на C++. М.: Бином, 1998. - 560с.
УДК 681.3
ПРОЦЕСС ПРОЕКТИРОВАНИЯ СИСТЕМЫ УПРАВЛЕНИЯ СВЯЗЬЮ КАК ВЕРОЯТНОСТНАЯ МНОГОФАЗНАЯ СИСТЕМА
Тебекин Юрий Борисович, ст. преподаватель, Воронежский институт правительственной связи (филиал Академии федеральной службы охраны Российской Федерации), [email protected] Авсеева Ольга Владимировна, к.т.н., доцент, Воронежская государственная технологическая академия, Россия, Воронеж, [email protected] Кравец Олег Яковлевич, д.т.н., проф., Воронежский государственный технический университет,
Процесс проектирования системы управления связью, как и любой другой сложный процесс, состоящий из многих стадий и этапов, выполняемых различными подразделениями фирмы, должен быть тщательно скоординирован и увязан во времени.
График процесса проектирования должен отражать существенные в отношении достижения конечных целей работы (этапы, фазы и т.д.), а также учитывать возможные состояния комплекса соответствующих работ, сроки их выполнения, возможные нарушения этих сроков и последствия нарушений.
113
Простейшие методы планирования позволяют использовать модели типа ленточных графиков. Линейные графики применяются и в настоящее время для относительно простых объектов планирования. Однако они имеют целый ряд существенных недостатков [1]:
• не показывают взаимосвязь отдельных работ, из-за чего трудно оценить значимость каждой отдельной работы для выполнения промежуточных и конечных целей;
• не отражают динамичность разработок;
• не позволяют периодически производить корректировки графика в связи с изменением сроков выполнения работ;
• не дают четких точек совмещения и сопряжения смежных этапов;
• не позволяют применить математически обоснованный расчет выполнения планируемого комплекса работ;
• не дают возможность оптимизировать использование имеющихся ресурсов и сроки выполнения разработки в целом.
Планирование и управление комплексом работ представляет собой сложную и, как правило, противоречивую задачу. Оценка временных и стоимостных параметров функционирования системы, осуществляемая в рамках этой задачи, может быть произведена методом сетевого планирования и управления (СПУ).
Основным плановым документом в системе СПУ является сетевой график (сетевая модель или сеть), представляющий собой информационно-динамическую модель, в которой отражаются взаимосвязи и результаты всех работ, необходимых для достижения конечной цели разработки.
Этапы разработки и управления ходом работ с помощью сетевого графика имеют следующую последовательность основных операций [1]:
1. составление перечня всех действий и промежуточных результатов (событий) при выполнении комплекса работ и графическое их отражение;
2. оценка времени выполнения каждой работы, а затем расчет сетевого графика для определения срока достижения поставленной цели;
3. оптимизация рассчитанных сроков и необходимых затрат;
4. оперативное управление ходом работ путем периодического контроля и анализа получаемой информации о выполнении заданий и выработка корректирующих решений.
Экономическая эффективность от внедрения СПУ определяется в первую очередь возможностями уменьшения общего цикла работ и сокращением затрат за счет более рационального использования трудовых, материальных и денежных ресурсов. Уменьшение длительности комплекса работ обеспечивает сокращение сроков окупаемости инвестиций, более ранний вывод товара на рынок, что способствует конкурентному успеху фирмы.
При создании модели управления проектированием необходимо, помимо основных целей проектирования, учесть возможности управления ресурсами и управления качеством.
Ресурсы — один из основных рычагов управления. На базе анализа ресурсов принимаются решения о необходимости корректировки плана работ и применения корректирующих воздействий для устранения или уменьшения нежелательных последствий возникших отклонений, т. е. осуществляется оперативное воздействие на управление.
Рассматривая процедуру управления качеством, необходимо заметить, что процесс проектирования системы управления связью представляет собой многофазную вероятностную систему. Каждый этап процесса проектирования может завершиться с той или иной степенью соответствия идеальному результату. Иными словами, каждый этап имеет свою вероятность качественного завершения.
Широко применяемые до последнего времени в организации, экономике, управлении детерминированные методы, как и много лет назад, однозначно определяют события начальными условиями. Отсутствие учета вероятностного, стохастического характера процесса проектирования привело к неадекватности моделей, к ненадежности большинства организационно-технологических, экономических, управленческих решений.
114
Основой вероятностного подхода является представление о распределениях, которыми опосредуются зависимости между свойствами исследуемых объектов. При детерминированном подходе эти зависимости выражаются как прямые функциональные связи. Понятие о распределениях непосредственно связано с понятием о случайных величинах, неопределенным образом меняющих свое значение которое, однако, имеет устойчивую относительную частоту появления.
Вероятностные системы - это системы, поведение которых описывается законами теории вероятностей. Для вероятностной системы знание текущего состояния и особенностей взаимной связи элементов недостаточно для предсказания будущего поведения системы со всей определенностью. Для такой системы имеется ряд направлений возможных переходов из одних состояний в другие, т. е. имеется группа сценариев преобразования состояний системы, и каждому сценарию поставлена в соответствие своя вероятность.
Многостадийность рассматриваемой системы позволяет рассматривать процесс управления качеством проектирования с точки зрения раздельного управления качеством каждой из стадий проектирования.
Раздельное управление качеством на каждом этапе позволяет не только более гибко распределять ресурсы, необходимые для проведения организационно-технических мероприятий, но и выделить приоритетные направления развития проекта, реализация которых позволит существенно улучшить одну или несколько вышеобозначенных вероятностей.
Вложение огромных ресурсов во всю технологическую цепочку может приблизить искомую вероятность практически к единице, однако целесообразность такого вложения может оказаться сомнительной вследствие невыгодного соответствия стоимости проводимых мероприятий средне- и долгосрочному прогнозу прибыли. Следовательно, необходимо опираться на экономически обоснованные ограничения по затратам на мероприятия по повышению вероятности отдельных стадий проектирования.
Авторами предложена математическая модель оптимизации проектирования систем управления связью [2, 3].
Пусть процесс проектирования включает в себя N стадий. Для каждой стадии известно начальное значение вероятности, с которой мы получаем качественное завершение i -й операции проектирования, pi, i = 1,..., N. Пусть для каждой i-й операции имеется ni мероприятий, проведение каждого из которых повышает вероятность pi на некоторое
значение Apj, i = 1,..., N, j = 1,...,ni. Увеличение текущей вероятности на ApiJ влечет за собой некоторые материальные Cj и временные tjj затраты на осуществление
соответствующего мероприятия. Таким образом, для каждой i -й операции заданы nt -мерные вектор вероятностей Apt = (Apn,Apt2,...,Apin ), вектор стоимостей ct = (сп,ct2,...,cin ) и
вектор длительностей tt = (tn, tt2,..., tin ). Введем для i -й операции вектор zt
(z,1
) , каждая компонента которого может
принимать значение 0 или 1.
' 1, если i - е мероприятие проводится для j - й операции,
j [0, в противном случае
(1)
Управление вероятностями осуществляется при помощи проведения ряда мероприятий, повышающих качество выполнения операции.
Необходимо определить набор мероприятий с минимальной суммарной стоимостью, который обеспечивает требуемый уровень качества проектирования. При этом, если общее время, затраченное на проведение мероприятий, превышает некоторую допустимую величину Ат, на которую может быть увеличено общее время проектирования без
115
финансовых потерь, то налагается штраф, зависящий от времени просрочки g(T), где
N ni
T=ZZ v, •
i=i j=1
Таким образом, задача состоит в том, чтобы выбрать такой набор мероприятий для каждой операции, чтобы их проведение обеспечило достаточный уровень pA вероятности всего многостадийного процесса проектирования, при условии минимума затрат на проведение данного комплекса мероприятий и соблюдения технических требований и временных ограничений.
N ni ZZ j, „ G ' min i=1 j=1 (2)
N Щ П (pi „Z Zj APj ) > PA i=1 j=1 (3)
z,j > 0, j = 1,...,nt, i = 1,..., N (4)
' 0, если T < At, G = \ [g (T), в противном случае. (5)
Литература
1. Ребрин, Ю. И. Основы экономики и управления производством: Конспект лекций / Ю. И. Ребрин. - Таганрог: Изд-во ТРТУ, 2000. - 145 с.
2. Авсеева, О. В. К постановке задачи оптимизации проектирования систем специальной связи / О. В. Авсеева, А. Э. Говорский, Ю. Б. Тебекин, О. Я. Кравец // Информационные технологии моделирования и управления, № 7 (59), 2009. - Воронеж : Научная книга. - С. 945-949.
3. Авсеева, О. В Управление качеством системы специальной связи при автоматизированном
проектировании / О. В. Авсеева, Ю. Б. Тебекин, О. Я. Кравец // Труды всероссийской конференции «Новые технологии в научных исследованиях, проектировании, управлении, производстве». - Воронеж: ГОУВПО «Воронежский государственный технический
университет», 2010. - С. 64-66.
УДК 004.4.242
РАЗРАБОТКА ВЕБ-ПРИЛОЖЕНИЯ С ИСПОЛЬЗОВАНИЕМ МОДЕЛЬНООРИЕНТИРОВАННОГО ПОДХОДА
Пупыкина Анна Александровна, ведущий программист, Филиал Российского государственного гуманитарного университета в г. Тольятти, Россия, Тольятти, [email protected]
Введение
При разработке сложного программного продукта в настоящее время необходимо использовать средства автоматизации проектирования и разработки. Для того, чтобы сосредоточиться на бизнес-логике приложения, а не на реализации низкоуровневого функционала, применяется модельно-ориентированный подход (Model-Driven Development, MDD) разработки приложения. MDD относится к семейству подходов разработки, основанных на использовании модели в качестве первичного артефакта в жизненном цикле программного продукта. Разработчики используют модели для целого ряда задач: создания технического задания, анализа требований, генерации кода, тестирования, и многого другого.
Разработка пользовательского интерфейса часто становится неотъемлемой частью создания программного продукта. Инструменты MDD позволяют автоматически транслировать высокоуровневые спецификации в качественный код и документацию, что
116
