Перевод семантических сетей в uml-диаграммы классов
Иван Барашев
Резюме
Чрезвычайная важность правильного определения архитектуры программного обеспечения очевидна, однако эта задача не из легких, особенно, в крупных проектах. Схема проекта должна быть четко структурирована и ясно визуализирована. Для этой цели, как правило, широко используются UML-диаграммы классов. Тем не менее, этот метод не достаточно гибкий и понятный, особенно, на начальном этапе создания, поэтому существует необходимость в более подходящем. Семантические сети не так широко используются для решения этих задач. Вместе с тем этот метод является приемлемым подходом для построения развиваемой архитектуры компьютерных систем. Кроме того, он может стать хорошим посредником для других форматов. А также, его инструменты могут стать достаточно мощными и актуальными.
Введение
Чем более продвинутыми становятся компьютерные системы, тем сложнее становится работать с ними. К тому же, программист не может удерживать в уме полную картину того, что он создает потому, что объем человеческой памяти не увеличивается, а остается неизменным. Следовательно, разработанные системы должны быть хорошо организованы, чтобы избежать дополнительного осмысления различных деталей. Кроме того, в конце концов, это позволит избежать множества проблем. Именно поэтому архитектура программного обеспечения настолько важна. Таким образом, инструменты для построения архитектуры программного обеспечения тоже крайне важны. Как писал Ривз: «Я бы сказал, что если нам нужна хорошая архитектура, то выбираем дизайн высшего уровня, если хорошая абстракция – дизайн классов, хорошая реализация – дизайн низшего уровня».
Ряд исследований и руководств по определению архитектуры программного обеспечения считают UML-диаграммы несовершенным инструментом и не рекомендуют использовать их в начале работы. Излишний формализм делает разработку больше сложной, чем легкой. Большинство других объектно-ориентированных инструментов имеют те же сложности: у них свои собственные строгие правила и жесткие рамки. Кроме того, не существует практически ни одного инструмента для связи одних форматов с другими. Таким образом, существует потребность в более гибком методе для построения архитектуры системных приложений. При этом, метод семантических сетей может быть использован для этого: он является достаточно гибким и любые другие методы можно описать с помощью него.
Предпосылки и похожие работы
Есть несколько известных видов диаграмм, которые используются для представления и описания объектно-ориентированных систем. Вот они:
Унифицированный язык моделирования (UML) диаграммы и, в частности, в данной работе – диаграммы классов. Ряд популярных IDE могут построить UML-диаграммы классов из существующего исходного кода для улучшения визуализации и документации. Некоторые специальные инструменты позволяют сделать диаграммы классов с помощью перетаскивания интерфейсов, а другие могут создавать шаблоны кода, используя приведенные диаграммы классов. Спецификация UML также предоставляет различные типы диаграмм с другими правилами, которые помогают описать системы с различных объектно-ориентированных взглядов. Кроме того, они широко используются в промышленности в течение длительного времени.
Модели сущность-связь (ER-модель). Они также используются для описания объектов некоторых систем, в основном реляционных баз данных. Они используются в некоторых популярных приложениях, в частности, "Microsoft Visio".
Онтологии. Такие приложения, как знаменитый "Protégé" и "OWLGrEd" позволяют разработать системы онтологий, которые, как правило, основываются на схемах. Схемы используются сейчас в искусственном интеллекте, чтобы описать отношения между объектами.
Эти методы широко используются в различных ситуациях малыми и крупными ИТ-командами. И они были востребованы на протяжении нескольких десятилетий. Тем не менее, у них есть несколько недостатков, которые нарушают процесс разработки программного обеспечения:
Эти формальные методы являются слишком строгими и сосредоточены на аспектах низкоуровневых понятий и ассоциаций. Таким образом, они не достаточно поддаются воздействию высокого уровня. Однако такие форматы не могут описать все аспекты применения, только код способен на это. По словам Ривза, "код является дизайном". По той же причине такие методы представления не являются масштабируемыми. Кроме того, крупные системы содержат десятки объектов, которые могут и должны быть объединены вместе в более высоком масштабе зрения.
Спецификации UML трудно изучить и использовать. Они содержат большое количество диаграмм различных видов со своими собственными правилами. С одной стороны, диаграммы классов UML описывают много деталей систем, которые не являются столь необходимым в начале создания архитектуры. Таким образом, это отнимает много времени. С другой стороны, в них отсутствует формальное определение, которое необходимо для больших проектов. Некоторые из этих и других сложностей UML обсуждаются Bachmann и Avgeriou, и др.
Там нет преобразователя между описанными форматами. Несмотря на то, что он используется довольно редко, бывают ситуации, когда это необходимо. Тем не менее, были сделаны некоторые попытки связать UML диаграммы с онтологий.
По этим причинам, некоторые разработчики пытаются создать и использовать новые методы для архитектуры построения и представления, которые являются более гибкими, понятными и пригодными.
Проект под названием "Structurizr" был разработан в качестве альтернативы UML-диаграммам и нескольким приложениям для описания программного обеспечения. У него есть свои собственные правила и приложения с перетаскиванием интерфейса для легкого построения архитектуры программного обеспечения. Необходимость этого приложения объяснял Браун. Однако, серверная его часть является платной и он не взаимодействует с другими методами.
Разработчики "Semantic Research Inc." создали "язык семантического объекта" (SOL), который основан на семантической сети. Главным преимуществом этого графического метода является представление всей системы по отношению к одному выбранному объекту. Хотя при использовании этого метода системы объекта представлены в очень читаемом образе, он не обеспечивает точности построения архитектуры. Таким образом, SOL не стал популярным.