Объектно-ориентированная модель системы

Использование объектно-ориентированных принципов позволяет создать описание (модель) предметной области в «естественном» виде – в виде совокупности взаимодействующих объектов – сущностей, объединяющих данные и методы (процедуры) обработки этих данных. Каждый объект здесь обладает собственным поведением и моделирует некоторый объект реального мира. Одновременно при объектно-ориентированном подходе к моделированию можно объединить все почти независимые представления системы в единое целое. Данные особенности наиболее ярко проявились в процессе исторического развития методов и технологий программирования. При разработке программного обеспечения также существует несколько подходов, отображающих различия используемых концепций и методологий. Важнейшими из них являются алгоритмический (процедурный) подход и объектно-ориентированный подход.

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

В этом плане наиболее современным подходом к разработке программного обеспечения является объектно-ориентированный подход. Здесь в качестве основного строительного блока выступает объект или класс. В самом общем смысле объект – это сущность, обычно извлекаемая из словаря предметной области или программного решения, а класс является описанием множества однотипных объектов. Каждый объект обладает идентичностью (его можно поименовать или как-то по-другому отличить от прочих объектов), состоянием (обычно с объектом бывают связаны некоторые данные) и поведением (с ним можно что-то делать или он сам может что-то делать с другими объектами). В области разработки объектный подход в полной мере обнаруживает свои преимущества: естественность и наглядность процесса программирования, первичность данных по отношению к процессам и их соединение с методами обработки этих данных (процедурами) и главное – легкость сопровождения и дальнейшей модификации программы, если система претерпевает изменения.

Объектно-ориентированный подход к разработке программного обеспечения является сейчас преобладающим потому, что он продемонстрировал свою полезность при построении систем в самых разных областях любого размера и сложности. Кроме того, большинство современных языков программирования, инструментальных средств и операционных систем являются в той или иной мере объектно-ориентированными, а это дает веские основания судить о мире в терминах объектов. Широкое распространение объектно-ориентированное моделирование и программирование получили с появлением средств визуального программирования, которые обеспечивают слияние (инкапсуляцию) данных с процедурами, описывающими поведение реальных объектов, в объекты прикладных программ, которые могут быть отображены в графической пользовательской среде. Это позволяет создавать программные системы, с одной стороны, максимально похожие на реальные и, с другой стороны, добиваться высокого уровня абстракции.

В настоящее время в качестве базового визуального языка при реализации объектно-ориентированного подхода используется UML (Unified Modeling Language) – универсальный многоцелевой язык моделирования, разработанный для спецификации, визуализации, проектирования и документирования компонентов программного обеспечения. Начиная работу по созданию UML его авторы (Г. Буч, Д. Рамбо, А. Джекобсон) сформулировали исходные требования к универсальному языку моделирования:

− язык должен позволять моделировать не только программное обеспечение, но и широкий перечень систем различного назначения, а также бизнес-процессов, с использованием объектно-ориентированных понятий;

− необходимо явным образом реализовать взаимосвязь между базовыми понятиями концептуального и физического уровней создаваемых моделей;

− требуется обеспечить масштабируемость моделей для описания сложных многоцелевых систем;

− язык должен быть понятен аналитикам и программистам, а также поддерживаться инструментальными средствами на различных компьютерных платформах.

Современный UML является достаточно мощным средством моделирования, который может быть использован для построения концептуальных, функциональных, логических моделей систем и, далее, для автоматизации проектирования программного обеспечения с использованием различных программных продуктов. UML – это графический язык и его изучение следует начинать с изучения применяемых в нем графических образов или нотаций. Конструктивное использование UML базируется на понимании общих принципов моделирования сложных систем, в явном или неявном виде нами уже рассмотренных, и особенностей объектно-ориентированного подхода.

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

Другой известный принцип прикладного системного анализа, реализованный в UML – это принцип иерархического построения моделей. Он, как нам уже известно, предписывает рассматривать процесс построения модели на разных уровнях абстрагирования или детализации в рамках фиксированных представлений. Исходная или первоначальная модель имеет наиболее общее (концептуальное) представление системы и может не содержать многих деталей и аспектов, выявляемых на поздних стадиях описания системы.

Наконец, важнейшим принципом, реализованным в UML, является принцип многомодельности. Он реализует утверждение о том, что никакая единственная модель не может с достаточной степенью адекватности описывать различные аспекты сложной системы: нельзя ограничиваться созданием только одной модели; наилучший подход при разработке любой нетривиальной системы – использовать совокупность нескольких моделей, почти независимых друг от друга. Ключевым здесь является термин «почти независимые». В данном контексте он означает, что модели могут создаваться и изучаться по отдельности, но вместе с тем должны оставаться взаимосвязанными. Поэтому в UML полная модель имеет некоторое количество взаимосвязанных представлений, каждое из которых отражает некоторый поведенческий аспект или структурные характеристики системы. При этом наиболее общими представлениями сложной системы принято считать статическое и динамическое представления, которые, в свою очередь, могут подразделяться на другие, более частные представления. Напомним, что феномен сложной системы как раз и состоит в том, что никакое единственное ее представление (формализованное описание) не является достаточным для адекватного выражения всех особенностей и свойств.

Такой подход верен и в отношении объектно-ориентированных программных систем. Для понимания архитектуры подобной системы требуется несколько взаимодополняющих представлений: вид с точки зрения прецедентов, или вариантов использования (чтобы выявить внешние требования к системе); вид с точки зрения проектирования (чтобы построить словарь предметной области и области решения); вид с точки зрения процессов (чтобы смоделировать распределение процессов и потоков в системе); вид с точки зрения реализации, позволяющий рассмотреть физическую реализацию системы; с точки зрения развертывания, помогающей сосредоточиться на вопросах системного проектирования. Каждое из перечисленных представлений отражает множество структурных и поведенческих аспектов, которые в своей совокупности составляют детальный чертеж программной системы. В зависимости от природы системы некоторые модели могут быть важнее других. Так, при создании систем для обработки больших объемов данных более важны модели, обращающиеся к точке зрения статического проектирования. В приложениях, ориентированных на интерактивную работу пользователя, на первый план выходят представления с точки зрения статических и динамических прецедентов. В системах реального времени наиболее существенными будут представления с точки зрения динамических процессов. Наконец, в распределенных системах, таких как Web-приложения, основное внимание нужно уделять моделям реализации и развертывания.

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

− диаграмма вариантов использования (use case diagram);

− диаграмма классов (class diagram);

− диаграмма состояний (statechart diagram);

− диаграмма деятельности (activity diagram);

− диаграмма последовательности (sequence diagram);

− диаграмма кооперации (collaboration diagram);

− диаграмма компонентов (component diagram);

− диаграмма развертывания (deployment diagram).

Перечень этих диаграмм и их названия являются каноническими. Процесс проектирования системы неразрывно связан с процессом их построения. Каждая из диаграмм детализирует и конкретизирует различные представления о модели сложной системы в терминах языка UML.

Диаграмма вариантов использования представляет собой наиболее общую концептуальную модель системы и является исходной для построения всех остальных диаграмм.

Диаграмма классов является логической моделью, отражающей соответствующий статический вид системы с точки зрения проектирования. При моделировании объектно-ориентированных систем этот тип диаграмм используют чаще всего.

Диаграммы состояний, деятельности, последовательности, кооперации объединяются в большую группу называемую диаграммами поведения (behavior diagram). В рамках этой группы диаграммы последовательностей и кооперации получили также общее название диаграмм взаимодействия (interaction diagrams). Диаграммы поведения, соответственно, отражают динамические аспекты функционирования сложной системы.

На диаграммах состояний отображается конечный автомат, включающий в себя состояния, переходы, события и виды действий. Диаграммы состояний относятся к динамическому виду системы и акцентируют внимание на поведении объекта, зависящем от последовательности событий, что очень полезно для моделирования реактивных систем.

Диаграмма деятельности акцентирует внимание на последовательности выполнения определенных действий или элементарных операций в системе; на ней представлена логика переходов потока управления от одной деятельности к другой внутри системы. Диаграммы деятельности также относятся к динамическому представлению системы и, в определенном смысле, являются частным случаем диаграмм состояний. Они также важны при моделировании в плане отображения логики и динамики функционирования системы.

На диаграммах взаимодействия представлены связи между объектами и показаны, в частности, сообщения, которыми объекты могут обмениваться. Диаграммы взаимодействия также относятся к динамическому представлению системы. При этом диаграммы последовательности отражают временную упорядоченность сообщений и взаимодействия элементов системы, а диаграммы кооперации – структурную организацию обменивающихся сообщениями объектов. Эти диаграммы являются изоморфными, т. е. могут быть преобразованы друг в друга.

Диаграмма компонентов и диаграмма развертывания получили общее название диаграмм реализации (implementation diagrams). Они служат для отображения физических компонентов системы (ее физической реализации). На диаграмме компонентов представлена организация совокупности компонентов и существующие между ними зависимости. Диаграммы компонентов относятся к статическому отображению системы с точки зрения ее реализации. Они могут быть соотнесены с диаграммами классов, так как компонент обычно отображается на один или несколько классов, интерфейсов или коопераций. На диаграмме развертывания представлена конфигурация обрабатывающих узлов системы и распределение в них компонентов. Кроме того, она показывает наличие физических соединений – маршрутов передачи информации между физическими устройствами, используемыми при реализации системы. Диаграммы развертывания относятся к статическому представлению архитектуры системы с точки зрения развертывания. Они связаны с диаграммами компонентов, поскольку в каждом узле обычно размещаются один или несколько компонентов.

Таким образом, интегрированная модель сложной системы в нотациях UML представляется в виде, показанном на рисунке 7.1.

Рисунок 7.1 – Интегрированная модель сложной системы в нотации UML