UML-язык объектного моделирования и пример его практического применения

ВВЕДЕНИЕ 3 1 ПАРАДИГМЫ ООП И СИСТЕМНОГО МОДЕЛИРОВАНИЯ 5 1.1 Методология ООП 6 1.2 Методология системного анализа и моделирования 7 2 UML – УНИФИЦИРОВАННЫЙ ЯЗЫК МОДЕЛИРОВАНИЯ 11 2.1 Назначение UML 11 2.2 Основные понятия и концепции 14 2.3 Общая структура 15 2.4 Основные пакеты UML 18 3 ПРИМЕНЕНИЕ UML 27 ЗАКЛЮЧЕНИЕ 31 СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ И ИСТОЧНИКОВ 32 ВВЕДЕНИЕ Современное развитие информационных технологий включает в себя не только развитие в области программно-аппартных средств, но и развитие различных uses-case для решения различных задач, например, задачи моделирования. Если охарактеризовать современный уровень развития информационных технологий в данном направлении, то можно обратить внимание на то, что возрастает сложность не только отдельных физических и программных компонентов, например, усложнение математической модели программных компонент или повышение технологического уровня цифровых схем, но и лежащих в основе этих технологий концепций и идей, например, использование конечных или временных автоматов для описания поведения и функционирования устройства по заданной спецификации. Казалось бы, что недавно профессиональному программисту или разработчику было достаточно в совершенстве владеть одним или двумя языками программирования, наиболее распространенных в тот или иной период развития информационных технологий, чтобы разрабатывать высокой сложности программно- аппаратный комплекс программ или же просто программу. Выбор платформы программирования, операционной системы и языка программирования, как правило, не являлся серьезной проблемой для программиста. Ибо он руководствуется, как правило, своими возможностями и знаниями в той или иной области разработки программирования. А сопровождение программы, хотя и было сопряжено с объективными трудностями, такими как, тестирование и верификация программного кода на поиск ошибок и уязвимостей, могло быть реализовано простым добавлением или изменением кода исходной программы. Но заметим, что такое добавление или изменение осуществлялось, как правило, сами разработчиком этой программы, т.к. на анализ кода другим специалистом уходит больше времени. Это связано с тем, что каждый человек, решая одну и ту же задачу, для ее решения использует различные инструменты и походит к ее решению с различных сторон. В данной работе нами будет рассмотрен один из языков моделирования UML, который получил широкое распространение при решении различных задач. В первой главе представленной работы описаны основные концепции объектно- ориентированного программирования, системного моделирования и анализа. Во второй главе подробно рассмотрен сам унифицированный язык моделирования UML, описаны его основные концепции и понятия, его структура и назначение. В последней главе рассмотрен вопрос практического применения такого языка на практике. 1 ПАРАДИГМЫ ООП И СИСТЕМНОГО МОДЕЛИРОВАНИЯ ООП возникло в результате развития идеологии процедурного программирования, где данные и подпрограммы (процедуры, функции) их обработки формально не связаны [1]. ООП – технология, возникшая как реакция на очередную фазу кризиса программного обеспечения, когда методы структурного программирования уже не позволяли справляться с растущей сложностью промышленного программного обеспечения. Следствие этого – срыв сроков проектов, перерасход бюджета, урезанная функциональность и множество ошибок. Существенная черта промышленной программы – ее сложность: один разработчик не в состоянии охватить все аспекты системы, поэтому в ее создании участвует целый коллектив. Следовательно, к первичной сложности самой задачи, вытекающей из предметной области, добавляется управление процессом разработки с учетом необходимости координации действий в команде разработчиков. Так как сложные системы разрабатываются в расчете на длительную эксплуатацию, то появляются еще две проблемы: сопровождение системы (устранение обнаруженных ошибок, тестирование и верификация) и ее модификация, поскольку у заказчика постоянно появляются новые требования и пожелания. Иногда затраты на сопровождение и модификацию сопоставимы с затратами на собственную разработку системы. Способ управления сложными системами был еще известен с древности – «разделяй и властвуй». Т.е. выходом служит декомпозиция – представлении сложной системы в виде суперпозиции более простых систем [2]. Каждую из таких систем можно совершенствовать независимо и параллельно, что существенно сокращается время оптимизации программного комплекса. Но заметим, что в рамках структурного подхода декомпозиция понимается как разбиение алгоритма, когда каждый модуль системы выполняет один их этапов общего процесса, то ООП предлагает совершенно другой подход. ООП – парадигма программирования, основными фундаментальными понятиями которой являются понятия класса и объекта [3]. При этом под классом понимают некоторую абстракцию совокупности объектов, которые имеют общий набор свойств и обладают одинаковым поведением [4]. Каждый объект в этом случае рассматривается как экземпляр соответствующего класса [5]. 1.1 Методология ООП Основными принципами ООП являются наследование, инкапсуляция и полиморфизм [6]. Принцип, в соответствии с которым знание о более общей категории разрешается применять для более узкой категории, называется наследованием. Наследование тесно связано с иерархией классов, которая определяет, какие классы следует считать наиболее абстрактными и общими по отношению к другим классам. При этом, если некоторый более общий или родительский класс (предок) обладает фиксированным набором свойств и поведением, то производный от него класс (потомок) должен содержать этот же набор свойств и поведение, а также дополнительные, которые будут характеризовать уникальность полученного таким образом класса. В этом случае говорят, что производный класс наследует свойства и поведение родительского класса. Для иллюстрации принципа наследования рассмотрим пример, где в качестве общего класса представлен класс "Автомобиль". Данный класс определяется как некоторая абстракция свойств и поведения всех реально существующих автомобилей. При этом свойствами класса "Автомобиль" могут быть такие общие свойства, как наличие двигателя, трансмиссии, колес, рулевого управления. Если в качестве производного класса рассмотреть класс "Легковой автомобиль", то все выделенные выше свойства будут присущи и этому классу. Можно сказать, что класс "Легковой автомобиль" наследует свойства родительского класса "Автомобиль". Однако, кроме перечисленных свойств, класс-потомок будет содержать дополнительные свойства, например такое, как наличие салона с количеством посадочных мест 2-5. Следующий принцип ООП - инкапсуляция. Этот термин характеризует сокрытие отдельных деталей внутреннего устройства классов от внешних по отношению к нему объектов или пользователей [7]. Действительно, взаимодействующему с классом субъекту или клиенту нет необходимости знать, каким образом реализован тот или иной метод класса, услугами которого он решил воспользоваться. Конкретная реализация присущих классу свойств и методов, которые определяют поведение этого класса, является собственным делом данного класса. Более того, отдельные свойства и методы класса вообще могут быть невидимы за пределами этого класса, что является базовой идеей введения различных категорий видимости для компонентов класса. Третьим принципом ООП является полиморфизм. Под полиморфизмом («многоформенность») понимают свойство объектов принимать различные внешние формы в зависимости от обстоятельств [7]. Применительно к ООП полиморфизм означает, что действия, выполняемые одноименными методами, могут отличаться в зависимости от того, какому из классов относится тот или иной метод. Полиморфизм объектно-ориентированных языков связан с перегрузкой функций, но не тождествен ей. Широкое распространение методологии ООП оказало влияние на процесс разработки программ. В частности, процедурно-ориентированная декомпозиция программ уступила место объектно-ориентированной декомпозиции, при которой отдельными структурными единицами программы стали являться не процедуры и функции, а классы и объекты с соответствующими свойствами и методами.