Лекция
Привет, Вы узнаете о том , что такое uml, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое uml, объектно-ориентированне системы , настоятельно рекомендую прочитать все из категории Анализ и реинжиниринг бизнес процессов.
Унифицированный язык моделирования (UML) является стандартным инструментом для создания «чертежей» информационных систем (ИС). С помощью UML можно визуализировать, специфицировать, конструировать и документировать элементы этих систем.
UML пригоден для моделирования любых систем: от информационных систем масштаба предприятия до распределенных Web-приложений и даже встроенных систем реального времени. Это очень выразительный язык, позволяющий рассмотреть систему со всех точек зрения, имеющих отношение к ее разработке и последующему развертыванию. Несмотря на обилие выразительных возможностей, этот язык прост для понимания и использования. Изучение UML удобнее всего начинать с его концептуальной модели, которая включает в себя три основных элемента: базовые строительные блоки, правила, определяющие, как эти блоки могут сочетаться между собой, и некоторые общие механизмы языка.
UML является одной из составляющих процесса разработки ИС. Хотя UML не зависит от моделируемой реальности, лучше всего применять его, когда процесс моделирования основан на рассмотрении прецедентов использования, является итеративным и пошаговым, а сама система имеет четко выраженную архитектуру.
UML — это язык для визуализации, специфицирования, конструирования и документирования элементов программных систем. Язык состоит из словаря и правил, позволяющих комбинировать входящие в него слова и получать осмысленные конструкции. В языке моделирования словарь и правила ориентированы на концептуальное и физическое представление системы. Язык моделирования, подобный UML, является стандартным средством для составления «чертежей» ИС.
А зачем нам UML ? Может придумаем свой язык моделирования ?
Представьте себе такую ситуацию: аналитик Вася занялся разработкой технической документации по новому проекту, он использует для описания процессов свои собственно-придуманные диаграммы.
После составления документации Вася презентует результаты разработчику Коле, но Коля ничего не понимают в написанном. Васе приходится объяснять то, что он нарисовал в своей документации и тратить на это много времени.
А что, если у нас не один разработчик, а 10 ? Или 100 ?
В таком случае нам нужен универсальный язык моделирования, который будут понимать все участники процесса разработки программного обеспечения. Таким универсальным языком выступает UML, то есть UML - это некий стандарт для описания различных процессов. Его используют разработчики, аналитики, архитектор, с его помощью можно понятно доносить мысли и общаться между собой. Такой подход с использованием универсального языка значительно сократит время коммуникаций между сотрудниками и уменьшит время для поставки конечного продукта пользователю.
Плюсы UML:
Упрощает сложности при разработке ПО
Автоматизирует производство программного обеспечения и процессов
Помогает решить постоянные проблемы с архитектурой
Улучшает качество работы
Сокращает затраты и время выхода на рынок
Минусы UML:
трата времени на составление диаграмм :)
необходимо знать различные диаграммы и их нотации
При создании ИС любой сложности проводиться моделирование будущей системы, однако во многих случаях это делается неформально, без разработки какого-либо документа. Однако такой подход чреват неприятностями. Во-первых, обмен мнениями по поводу концептуальной модели возможен только тогда, когда все участники дискуссии говорят на одном языке. Во-вторых, нельзя получить представление об определенных аспектах информационных систем без модели, выходящей за границы текстового языка программирования. В-третьих, если автор кода никогда не воплощал в явной форме задуманные им модели, эта информация будет навсегда утрачена, если он сменит место работы. В лучшем случае ее можно будет лишь частично воссоздать исходя из реализации.
Использование UML позволяет решить третью проблему: явная модель облегчает общение.
Некоторые особенности системы лучше всего моделировать в виде текста, другие — графически. На самом деле во всех интересных системах существуют структуры, которые невозможно представить с помощью одного лишь языка программирования. UML — графический язык, что позволяет решить вторую из обозначенных проблем.
UML — это не просто набор графических символов. За каждым из них стоит хорошо определенная семантика. Это значит, что модель, написанная одним разработчиком, может быть однозначно интерпретирована другим — или даже инструментальной программой. Так решается первая из перечисленных выше проблем.
В данном контексте специфицирование означает построение точных, недвусмысленных и полных моделей. UML позволяет специфицировать все существенные решения, касающиеся анализа, проектирования и реализации, которые должны приниматься в процессе разработки и развертывания информационной системы.
UML является языком визуального проектирования, а модели, созданные с его помощью, могут быть непосредственно переведены на различные языки программирования ИС.
При разработке ИС, создаются и такие элементы, как:
В зависимости от принятой методики разработки выполнение одних работ производится более формально, чем других. Упомянутые элементы — это не просто поставляемые составные части проекта; они необходимы для управления, для оценки результата, а также в качестве средства общения между членами коллектива во время разработки системы и после ее развертывания.
UML позволяет решить проблему документирования системной архитектуры и всех ее деталей, предлагает язык для формулирования требований к системе и определения тестов и, наконец, предоставляет средства для моделирования работ на этапе планирования проекта и управления версиями.
Где используется UML
Язык UML предназначен прежде всего для разработки информационных систем. Об этом говорит сайт https://intellect.icu . Его использование особенно эффективно в следующих областях:
Сфера применения UML не ограничивается моделированием программного обеспечения. Его выразительность позволяет моделировать, скажем, документооборот в юридических системах, структуру и функционирование системы обслуживания пациентов в больницах, осуществлять проектирование аппаратных средств.
Концептуальная модель UML
Для понимания UML необходимо усвоить его концептуальную модель, которая включает в себя три составные части: основные строительные блоки языка, правила их сочетания и некоторые общие для всего языка механизмы. Усвоив эти элементы, вы сумеете читать модели на UML и самостоятельно создавать их — начале, конечно, не очень сложные. По мере приобретения опыта в работе с языком вы научитесь пользоваться и более развитыми его возможностями.
Словарь языка UML включает три вида строительных блоков:
Сущности — это абстракции, являющиеся основными элементами модели. Отношения связывают различные сущности; диаграммы группируют представляющие интерес совокупности сущностей.
В UML имеется четыре типа сущностей:
Сущности являются основными объектно-ориентированными блоками языка. С их помощью можно создавать корректные модели. Существует семь разновидностей структурных сущностей:
Эти семь базовых элементов — классы, интерфейсы, кооперации, прецеденты, активные классы, компоненты и узлы — являются основными структурными сущностями, которые могут быть включены в модель UML. Существуют также разновидности этих сущностей: актеры, сигналы, утилиты (виды классов), процессы и нити (виды активных классов), приложения, документы, файлы, библиотеки, страницы и таблицы (виды компонентов).
Поведенческие сущности (Behavioral things) являются динамическими составляющими модели UML. Это глаголы языка: они описывают поведение модели во времени и пространстве. Существует всего два основных типа поведенческих сущностей:
Эти два элемента взаимодействия и автоматы являются основными поведенческими сущностями, входящими в модель UML. Семантически они часто бывают связаны с различными структурными элементами, в первую очередь — классами, кооперациями и объектами.
Группирующие сущности являются организующими частями модели UML. Это блоки, на которые можно разложить модель. Есть только одна первичная группирующая сущность, а именно пакет.
Пакеты — это основные группирующие сущности, с помощью которых можно организовать модель UML Существуют также вариации пакетов, например каркасы (Frameworks), модели и подсистемы.
Аннотационные сущности - пояснительные части модели UML. Это комментарии для дополнительного описания, разъяснения или замечания к любому элементу модели. Имеется только один базовый тип аннотационных элементов — примечание (Note). Примечание — это просто символ для изображения комментариев или ограничений, присоединенных к элементу или группе элементов. Графически примечание изображается в виде прямоугольника с загнутым краем, содержащим текстовый или графический комментарий.
В языке UML определены четыре типа отношений:
Эти отношения являются основными связующими строительными блоками в UML и применяются для создания корректных моделей.
Четыре описанных элемента являются основными типами отношений, которые можно включать в модели UML Существуют также их вариации, например уточнение (Refinement), трассировка (Trace), включение и расширение (для зависимостей).
Диаграмма в UML — это графическое представление набора элементов, изображаемое чаще всего в виде связанного графа с вершинами (сущностями) и ребрами (отношениями). Диаграммы рисуют для визуализации системы с разных точек зрения. Диаграмма в некотором смысле одна из проекций системы. Как правило, за исключением наиболее тривиальных случаев, диаграммы дают свернутое представление элементов, из которых составлена система. Один и тот же элемент может присутствовать во всех диаграммах, или только в нескольких (самый распространенный вариант), или не присутствовать ни в одной (очень редко). Теоретически диаграммы могут содержать любые комбинации сущностей и отношений. На практике, однако, применяется сравнительно небольшое количество типовых комбинаций, соответствующих пяти наиболее употребительным видам, которые составляют архитектуру информационной системы. Таким образом, в UML выделяют девять типов диаграмм:
Здесь приведен неполный список диаграмм, применяемых в UML. Инструментальные средства позволяют генерировать и другие диаграммы, но девять перечисленных встречаются на практике чаще всего.
Строительные блоки UML нельзя произвольно объединять друг с другом. Как и любой другой язык, UML характеризуется набором правил, определяющих, как должна выглядеть хорошо оформленная модель, то есть семантически самосогласованная и находящаяся в гармонии со всеми моделями, которые с нею связаны.
В языке UML имеются семантические правила, позволяющие корректно и однозначно определять:
Модели, создаваемые в процессе разработки информационных систем, эволюционируют со временем и могут неоднозначно рассматриваться разными участниками проекта в разное время. По этой причине создаются не только хорошо оформленные модели, но и такие, которые:
Появление не слишком хорошо оформленных моделей неизбежно в процессе разработки, пока не все детали системы прояснились в полной мере. Правила языка UML побуждают — хотя не требуют — в ходе работы над моделью решать наиболее важные вопросы анализа, проектирования и реализации, в результате чего модель со временем становится хорошо оформленной.
Строительство упрощается и ведется более эффективно, если придерживаться некоторых соглашений. Следуя определенным архитектурным образцам, можно оформить здание в викторианском или французском стиле. Тот же принцип применим и в отношении UML. Работу с этим языком существенно облегчает последовательное использование общих механизмов, перечисленных ниже:
Для визуализации, специфицирования, конструирования и документирования информационных систем необходимо рассматривать их с различных точек зрения. Все, кто имеет отношение к проекту, — конечные пользователи, аналитики, разработчики, системные интеграторы, тестировщики, технические писатели и менеджеры проектов — преследуют собственные интересы, и каждый смотрит на создаваемую систему по-разному в различные моменты ее жизни. Системная архитектура является, пожалуй, наиболее важным элементом, который используется для управления всевозможными точками зрения и тем самым способствует итеративной и инкрементной разработке системы на всем протяжении ее жизненного цикла.
Архитектура — это совокупность существенных решений касательно:
Архитектура программной системы охватывает не только се структурные и поведенческие аспекты, по и использование, функциональность, производительность, гибкость, возможности повторного применения, полноту, экономические и технологические ограничения и компромиссы, а также эстетические вопросы.
Вид с точки зрения прецедентов (Use case view) охватывает прецеденты, которые описывают поведение системы, наблюдаемое конечными пользователями, аналитиками и тестировщиками. Этот вид специфицирует не истинную организацию программной системы, а те движущие силы, от которых зависит формирование системной архитектуры. В языке UML статические аспекты этого вида передаются диаграммами прецедентов, а динамические — диаграммами взаимодействия, состояний и действий.
Вид с точки зрения проектирования (Design view) охватывает классы, интерфейсы и кооперации, формирующие словарь задачи и се решения. Этот вид поддерживает прежде всего функциональные требования, предъявляемые к системе, то есть те услуги, которые она должна предоставлять конечным пользователям. С помощью языка UML статические аспекты этого вида можно передавать диаграммами классов и объектов, а динамические — диаграммами взаимодействия, состояний и действий.
Вид с точки зрения процессов (Process view) охватывает нити и процессы, формирующие механизмы параллелизма и синхронизации в системе. Этот вид описывает главным образом производительность, масштабируемость и пропускную способность системы. В UML его статические и динамические аспекты визуализируются теми же диаграммами, что и для вида с точки зрения проектирования, но особое внимание при этом уделяется активным классам, которые представляют соответствующие нити и процессы.
Вид с точки зрения реализации (Implementation view) охватывает компоненты и файлы, используемые для сборки и выпуска конечного программного продукта. Этот вид предназначен в первую очередь для управления конфигурацией версий системы, составляемых из независимых (до некоторой степени) компонентов и файлов, которые могут по-разному объединяться между собой. В языке UML статические аспекты этого вида передают с помощью диаграмм компонентов, а динамические — с помощью диаграмм взаимодействия, состояний и действий.
Вид с точки зрения развертывания (Deployment view) охватывает узлы, формирующие топологию аппаратных средств системы, на которой она выполняется. В первую очередь он связан с распределением, поставкой и установкой частей, составляющих физическую систему. Его статические аспекты описываются диаграммами развертывания, а динамические -диаграммами взаимодействия, состояний и действий.
Каждый из перечисленных видов может считаться вполне самостоятельным, так что лица, имеющие отношение к разработке системы, могут сосредоточиться на изучении только тех аспектов архитектуры, которые непосредственно их касаются. Но нельзя забывать о том, что эти виды взаимодействуют друг с другом. Например, узлы вида с точки зрения развертывания содержат компоненты, описанные для вида с точки зрения реализации, а те, в свою очередь, представляют собой физическое воплощение классов, интерфейсов, коопераций и активных классов из видов с точки зрения проектирования и процессов. UML позволяет отобразить каждый из пяти перечисленных видов и их взаимодействия.
Информация, изложенная в данной статье про uml , подчеркивают роль современных технологий в обеспечении масштабируемости и доступности. Надеюсь, что теперь ты понял что такое uml, объектно-ориентированне системы и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Анализ и реинжиниринг бизнес процессов
Ответы на вопросы для самопроверки пишите в комментариях, мы проверим, или же задавайте свой вопрос по данной теме.
Комментарии
Оставить комментарий
Анализ и реинжиниринг бизнес процессов
Термины: Анализ и реинжиниринг бизнес процессов