CC BY
79
системы обработки заявок, система включает в себя модуль по работе с внутренними документами, модуль аналитического исследования и другие.
Литература
1. Technical support for the neighbours [Электронный ресурс] // BBC NEWS UK Magazine. Дата обновления: 28.05.2005. URL: http://news.bbc.co.uk/2/hi/uk news/magazine/4387525.stm (дата обращения: 23.02.2010)
2. Service Desk Objectives in ITIL Foundation [Электронный ресурс] // ITIL Portal: The only future for managing IT Services is ITIL. Дата обновления: 01.07.2008. URL: http://www.itilfoundation.org/Service-Desk-Obiectives-in-ITIL-Foundation 43.html (дата обращения 01.03.2010)
3. Gerard Blokdijk, Ivanka Menken. Help Desk, Service Desk Best Practice Handbook: Building, Running and Managing Effective Support — Ready to use supporting documents bringing ITIL Theory into Practice. Emereo Pty Ltd, 2008. 124 с.
4. Ю. В. Кривошеенко. Корпоративные информационные системы. Компания Спутник +, 2008. 106 с.
5. Larry Klosterboer. Implementing ITIL Configuration Management. IBM Press, 2008. 264 с.
УДК 004.053
ОСНОВНЫЕ РАЗНОВИДНОСТИ ПАТТЕРНОВ ПРОЕКТИРОВАНИЯ И ИХ
ПРИМЕНЕНИЕ
Градиль Максим Дмитриевич, студент, Пятигорский филиал Российского Государственного Торгово-Экономического Университета, Россия, Пятигорск, lvlax@rambler.ru Ганенок Александр Григорьевич, студент, Пятигорский филиал Российского Государственного Торгово-Экономического Университета, Россия, Пятигорск, greg7515@yandex.ru
Проектирование объектно-ориентированных программ не легкое дело. А если их нужно использовать повторно, то все становится еще сложнее. Необходимо подобрать подходящие объекты, отнести их к различным классам, соблюдая разумность их детализации, определить интерфейсы классов, иерархию наследования и установить существенные отношения между классами. Дизайн с одной стороны должен соответствовать решаемой задаче, а с другой быть общим. Чтобы удалось учесть все требования, которые могут возникнуть в будущем.
Опытному разработчику понятно, что не нужно решать каждую новую задачу с нуля. Вместо этого он старается повторно воспользоваться теми решениями, которые оказались удачными в прошлом. Отыскав хорошее решение один раз, он будет прибегать к нему снова и снова. Именно благодаря накопленному опыту проектировщик и становится экспертом в своей области. Во многих объектно-ориентированных системах вы встретите повторяющиеся паттерны, состоящие из классов и взаимодействующих объектов. С их помощью решаются конкретные задачи проектирования. В результате чего объектноориентированный дизайн становится более гибким, элегантным и им можно воспользоваться повторно. Проектировщик знакомый с паттернами может сразу же применять их к решению новой задачи, не пытаясь, каждый раз изобретать велосипед.
Паттерны проектирования упрощают повторное использование удачных проектных и архитектурных решений. Представление прошедших проверку временем методик, в виде паттерного проектирования, облегчает доступ к ним со стороны разработчиков новых систем. С помощью паттернов можно улучшить качество документации и сопровождение соответствующих систем, позволяя явно описать взаимодействие классов и объектов, а так же причины по которым система была построена так, а не иначе. Проще говоря, паттерное проектирование дает разработчику возможности быстрее найти правильный путь.
Существует 3 основных категории паттернов:
1. Порождающие;
103
2. Структурные;
3. Поведенческие;
Порождающие паттерны — паттерны проектирования, которые абстрагируют процесс инстанцирования. Они позволяют сделать систему независимой от способа создания, композиции и представления объектов. Паттерн, порождающий классы, использует наследование, чтобы изменять инстанцируемый класс, а паттерн, порождающий объекты, делегирует инстанцирование другому объекту. Примерами этих паттернов являются Абстрактная фабрика, Фабричный метод и Одиночка.
Абстрактная фабрика — порождающий паттерн проектирования, позволяющий изменять поведение системы, варьируя создаваемые объекты, при этом сохраняя интерфейсы. Он позволяет создавать целые группы взаимосвязанных объектов, которые, будучи созданными одной фабрикой, реализуют общее поведение. Паттерн реализуется созданием абстрактного класса Factory, который представляет собой интерфейс для создания компонентов системы (например, для оконного интерфейса он может создавать окна и кнопки). Затем пишутся наследующиеся от него классы, реализующие этот интерфейс.
Фабричный метод — предоставляет подклассам интерфейс для создания экземпляров некоторого класса. В момент создания наследники могут определить, какой класс инстанцировать. Иными словами, Фабрика делегирует создание объектов наследникам родительского класса. Это позволяет использовать в коде программы не специфические классы, а манипулировать абстрактными объектами на более высоком уровне. Также известен под названием виртуальный конструктор.
Одиночка гарантирует, что у класса есть только один экземпляр, и предоставляет к нему глобальную точку доступа. Существенно то, что можно пользоваться именно экземпляром класса, так как при этом во многих случаях становится доступной более широкая функциональность. Например, к описанным компонентам класса можно обращаться через интерфейс, если такая возможность поддерживается языком.
Паттерны поведения связаны с алгоритмами и распределением обязанностей между объектами. Речь идет не только о самих объектах и классах, но и о типичных способах взаимодействия между ними. Примерами этих паттернов являются Шаблонный метод и Стратегия.
Шаблонный метод — паттерн проектирования, определяющий основу алгоритма и позволяющий наследникам переопределять некоторые шаги алгоритма, не изменяя его структуру в целом.
Стратегия — поведенческий паттерн, предназначен для определения семейства алгоритмов, инкапсуляции каждого из них и обеспечения их взаимозаменяемости. Это позволяет выбирать алгоритм путем определения соответствующего класса. Паттерн Стратегия позволяет менять выбранный алгоритм независимо от объектов-клиентов, которые его используют.
Структурные паттерны — эти паттерны оказываются важны, когда система больше зависит от композиции объектов, чем от наследования классов. Получается так, что основной упор делается не на жестком кодировании фиксированного набора поведений, а на определении небольшого набора фундаментальных поведений, с помощью композиции которых можно получать любое число более сложных. Таким образом, для создания объектов с конкретным поведением требуется нечто большее, чем простое инстанцирование класса.
Структурные паттерны решают как из классов и объектов образуются боле крупные структуры. Вместо композиции интерфейсов или реализаций структурные паттерны уровня объекта компонуют объекты для получения новой функциональности. Дополнительная гибкость в этом случае связана с возможностью изменить композицию во время выполнения, что недопустимо при статической композиции объектов.
Примерами этих паттернов являются Компоновщик, Заместитель и Декоратор.
104
Компоновщик позволяет создавать произвольно сложные структуры из примитивных или других составных объектов.
Заместитель — объект берет на себя обязанности другого объекта. Он может действовать как локальный представитель объекта, находящегося в другом адресном пространстве. Или представлять большой объект загружаемый по требованию. Или ограничивать доступ к критически важному объекту.
Декоратор — объект описывает динамическое добавление объектам новых обязанностей. Он рекурсивно компонует объекты с целью реализации заранее неизвестного числа дополнительных функций.
Паттерны проектирования это не тоже самое что связанные списки и хэш-таблицы, которые можно реализовать в виде класса и повторно использовать без каких бы то ни было модификаций, но это и не сложные предметы, ориентированные решения для целого приложения или подсистемы. Паттерны проектирования это описание взаимодействия объектов и классов, адаптированных для решения общей задачи проектирования в конкретном контексте.
Паттерн проектирования именует, мотивирует и объясняет конкретный прием проектирования, который относится к задаче, часто возникающей при работе над объектноориентированными системами. Паттерн описывает задачу, ее решение, область применимости этого решения и результаты. Он так же содержит рекомендации по реализации и примеры. Под решение понимается схема организации объектов и классов, позволяющих справиться с этой проблемой. Паттерны адаптируются для работы в конкретных условиях и реализуются в заданном контексте.
Паттерны проектирования особенно полезны тогда, когда нужно преобразовать аналитическую модель в модель реализации. Вопреки многочисленным заявлениям о беспрепятственном переходе объектно-ориентированного анализа к проектированию на практике этот процесс никогда не происходит гладко. В гибком проекте, ориентированном на повторное использование, имеются объекты, которых нет в аналитической модели. На проект оказывается влияние выбранный язык программирования и библиотеки классов. Аналитические модели часто приходится пересматривать, чтобы обеспечить повторное использование.
Жизненный цикл объектно-ориентированной программы состоит из трех фаз: прототипирование, экстенсивного роста и консолидации. Фаза прототипирования
характеризуется высокой активностью проектировщиков, направленных на то чтобы программа начала работать. При этом быстро создается прототип, который последовательно изменяется до тех пор, пока не будут решены первоначальные задачи. Обычно на данном этапе программа представляет собой набор иерархий и классов, отражающих сущности предметной области. Основной вид повторного использования это прозрачный ящик и наследование. После ввода в эксплуатацию развитие программы определяется двумя противоречивыми факторами: программе необходимо отвечать все новым требованиям и одновременно должна повышаться степень ее повторной используемости. Новые требования диктуют необходимость добавления новых классов и операций, быть может, даже и целых иерархий классов. Эти требования могут удовлетворяться, когда начинается фаза экстенсивного роста программы. Но в данный период не может продолжаться долго. В конце концов, программа становится слишком не гибкой и не поддается последующим изменениям. Иерархия классов больше не соответствует одной предметной области. Напротив, они отражают множество разных предметных областей. А классы определяют совершенно разнородные операции и переменные экземпляров. Чтобы программа могла развиваться и дальше ее необходимо пересмотреть и реорганизовать. Именно в этот период часто создаются каркасы. При реорганизации класса, описывающие специализированные универсальные компоненты отделяются друг от друга. Операции перемещаются вверх и вниз по иерархии, интерфейсы класса становятся более рациональными. В фазе консолидации появляется много новых объектов. Часто в результате декомпозиции существующих и
105
использования композиции вместо наследования. Поэтому прозрачный ящик заменятся черным. В связи с непрекращающимся потоком новых требований и стремление к всё более высокой степени повторной используемости, объектно-ориентированная программа должна вновь и вновь проходить через фазы экстенсивного роста и консолидации. От этого цикла никуда не деться. но хороший проектировщик применит изменения которые могут потребовать реорганизации. Он знает такие структуры классов и объектов позволят избежать реорганизации его проектов. Требования проанализированы и выявлены из них те, которые по всей вероятности изменятся на протяжении жизненного цикла программы и в проекте это учтено.
В паттернах проектирования нашли свое применение многие структуры, появившиеся в результате реорганизации. Использование паттернов на ранних стадиях проекта предотвратит реорганизацию в будущем. Но даже если вы не увидели, как применить паттерн, пока не создали всю систему, он все равно подскажет, как ее можно изменить.
Литература
1. C++ для профессионалов. - Солтер, Николас А., Клепер, Скотт Дж.: Пер. с англ. - М. : ООО «И.Д. Вильямс», 2006.
2. Приемы объектно-ориентированного программирования. Паттерны проектирования. -СПб: Питер, 2009.
3. Мартин Фаулер - Архитектура корпоративных программных - М.: «Вильямс», 2007. — С. 544.
УДК 004.9
АЛГОРИТМ ПОСТРОЕНИЯ ОРТОГОНАЛЬНОГО ТЕЗАУРУСА ОБЪЕКТНООРИЕНТИРОВАННОЙ СУБД
Чубухчиев Борис Христофорович, к.т.н., с.н.с., доц., Магаданский филиал Российского государственного гуманитарного университета, Россия, Магадан, medecos@vandex.ru Логун Кристина Александровна, к.п.н., доц., Магаданский филиал Российского государственного гуманитарного университета, Россия, Магадан, krislog@mail.ru
1. Некоторые алгоритмы классификации состояния АИС
При исследовании систем различной степени сложности часто возникают проблемы, связанные с синтезом минимального числа информативных признаков с целью объективной идентификации их состояний для сокращения минимизации их описаний и поиска в СУБД.
Обычно такого рода задачи решаются методами теории распознавания образов и должны предшествовать задачам синтеза и анализа систем.
В соответствии с этим мы предложили и апробировали несколько процедур распознавания, которые на нашем материале по сравнению с классическим методом дискриминантного анализа дали несколько лучшие результаты при значительно меньшей сложности вычислительного алгоритма, доступного, кстати, для ручной реализации.
К таким процедурам распознавания мы относим процедуру оптимальной классификации состояния, которая включает в себя задачи минимизации описания эталонов посредством синтеза оптимальной по числу признаков (измерений) диагностической процедуры с использованием в качестве решающего правила критерия хеммингова расстояния. Для тех случаев, когда по исходному набору параметров все-таки не удается получить удовлетворительные результаты, можно использовать процедуру формирования «новых» понятий (комплексов исходных признаков), структура которых может быть ортогональна относительно заданного набора классов состояний.
2. Оптимальная классификация состояния АИС
106
