Язык UML. Руководство пользователя Г. Буч

23.02.2015 Никодим 1 комментариев

У нас вы можете скачать книгу Язык UML. Руководство пользователя Г. Буч в fb2, txt, PDF, EPUB, doc, rtf, jar, djvu, lrf!

Наконец, реализация Realization - это семантическое отношение между классификаторами, при котором один классификатор определяет "контракт", а другой гарантирует его выполнение см.

Отношения реализации встречаются в двух случаях: Отношение реализации изображается в виде пунктирной линии с незакрашенной стрелкой, как нечто среднее между отношениями обобщения и зависимости см. Четыре описанных элемента являются основными типами отношений, которые можно включать в модели UML. Существуют также их вариации, например уточнение Refinement , трассировка Trace , включение и расширение для зависимостей.

Диаграмма в UML - это графическое представление набора элементов, изображаемое чаще всего в виде связанного графа с вершинами сущностями и ребрами отношениями. Диаграммы рисуют для визуализации системы с разных точек зрения.

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

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

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

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

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

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

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

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

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

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

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

Они связаны с диаграммами компонентов, поскольку в узле обычно размещаются один или несколько компонентов. Здесь приведен неполный список диаграмм, применяемых в UML. Инструментальные средства позволяют генерировать и другие диаграммы, но девять перечисленных встречаются на практике чаще всего. Строительные блоки UML нельзя произвольно объединять друг с другом.

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

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

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

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

Таким образом, допустимо строить модель инкрементно, то есть пошаговым образом - сначала нарисовать диаграмму, а потом добавить семантику в спецификацию модели, или наоборот - начать со спецификации возможно, применив обратное проектирование к существующей системе , а потом на ее основе создавать диаграммы.

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

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

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

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

Класс - это абстракция, объект - конкретная материализация этой абстракции см. В языке UML можно моделировать и классы, и объекты, как показано на рис. На этом рисунке показан один класс Customer Клиент и три объекта: Jan явно определенный как объект данного класса ,: Customer анонимный объект класса Customer и Elyse спецификация которого относит его к классу Customer, хотя это и не выражено явно.

Так, имеются прецеденты и экземпляры прецедентов, компоненты и экземпляры компонентов, узлы и экземпляры узлов и т. В графическом представлении для объекта принято использовать тот же символ, что и для его класса, а название объекта подчеркивать. Еще одним вариантом членения является деление на интерфейс и его реализацию. Интерфейс декларирует контракт см.

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

Поэтому UML является открытым языком, то есть допускает контролируемые расширения. Механизмы расширения UML см. Стереотип Stereotype расширяет словарь UML, позволяя на основе существующих блоков языка создавать новые, специфичные для решения конкретной проблемы. Обычно требуется, чтобы исключения можно было возбуждать и перехватывать, и ничего больше. Если пометить исключения соответствующим стереотипом, то с ними можно будет обращаться как с обычными строительными блоками языка; на рис.

Помеченное значение Tagged value расширяет свойства строительных блоков UML, позволяя включать новую информацию в спецификацию элемента. Скажем, если вы работаете над "коробочным" продуктом и выпускаете много его версий, то зачастую необходимо отслеживать версию и автора какой-нибудь важной абстракции.

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

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

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

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

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

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

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

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

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

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

Вид с точки зрения развертывания Deployment view охватывает узлы, формирующие топологию аппаратных средств системы, на которой она выполняется. В первую очередь он связан с распределением, поставкой и установкой частей, составляющих физическую систему. Его статические аспекты описываются диаграммами развертывания, а динамические - диаграммами взаимодействия, состояний и действий.

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

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

Используя UML, вы практически не зависите от организации процесса разработки; он не привязан к какому-либо конкретному циклу изготовления программного продукта. Тем не менее, если вы хотите извлечь из этого языка наибольшую пользу, лучше всего применять процесс, который:.

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

Процесс называют основанным на архитектуре Architecture-centric , когда системная архитектура является решающим фактором при разработке концепций, конструировании, управлении и развитии создаваемой системы. Итеративным Iterative называется процесс, который предполагает управление потоком исполняемых версий системы.

Инкрементный Incremental процесс подразумевает постоянное развитие системной архитектуры при выпуске новых версий, причем каждая следующая версия усовершенствована в сравнении с предыдущей. Процесс, являющийся одновременно итеративным и инкрементным, называется управляемым рисками Risk-driven , поскольку при этом в каждой новой версии серьезное внимание уделяется выявлению факторов, представляющих наибольший риск для успешного завершения проекта, и сведению их до минимума.

Управляемый прецедентами, основанный на архитектуре, итеративный и ин-крементный процесс может быть разбит на фазы. Фазами Phase называют промежутки времени между двумя опорными точками процесса, в которых выполнены хорошо определенные цели, завершено создание артефактов и принимается решение, стоит ли переходить к следующей фазе.

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

Исследование - это вторая фаза процесса; на этом этапе определяется видение продукта и его архитектура. Основное внимание уделяется конкретизации требований к системе и расстановке приоритетов.

Сами требования могут выражаться как в виде общих утверждений, так и в виде четких критериев оценки, каждый из которых определяет функциональное или нефункциональное поведение системы и закладывает основы для тестирования. Построение является третьей фазой процесса. Исполняемый архитектурный прототип приобретает форму, в которой он может быть представлен пользователям.

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

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

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

Документирование требований Чтобы требования, выявленные и описанные приняли силу соглашения между Заказчиком и Разработчиком, их необходимо оформит Документирование РФ Запад "Техническое задание", ТЗ.

Решение экономических задач на компьютере Москва, УДК К20 Решение экономических задач на компьютере. Полное руководство по русской версии. Широбокова Южно-Российский государственный политехнический. Осваиваем популярные системы управления сайтом CMS. Проектирование в архитектуре и строительстве. Инженерная графика для конструкторов в AutoCAD. Software Engineering I Объектно-ориентированный анализ и проектирование Раздел 1.

Санкт-Петербургский государственный политехнический университет План курса Введение Сложность, присущая. Золотов Сергей Юрьевич к. Требования к студентам Курс требует знаний по дисциплинам: Иерархия требований Use Case и ссылки на требования Диаграмма последовательности.

Введение Advanced Introduction Пышкин Е. Санкт-Петербургский государственный политехнический университет План курса. Моделирование, проектирование и расчет механических систем Москва, УДК Моделирование, проектирование и расчет. Сапир " " г. Но прежде чем обсуждать особенности языка,. Основы языка моделирования UML Материалы: Образовательные программы и курсы Курс: Аэрокосмический факультет, кафедра ФН "Вычислительной.

Программирование Основные понятия Разработка программного обеспечения Разработка и сопровождение ПО в наше время превратились в огромную сферу индустрии, в которой обращаются миллиардные денежные суммы.

Первые шаги в Creative Suite 4 М.: Сквозное проектирование в машиностроении. Основы теории и практикум Допущено учебно-методическим объединением вузов по образованию в области автоматизированного машиностроения. Проектирование архитектур программного обеспечения лекция 1 Зозуля А. Цель курса Приобретение студентами знаний, формирование умений и навыков в области использования современных технологий разработки программных средств ПС. Объектно-ориентированное моделирование При компьютерном моделировании сложных систем c успехом используются объектноориентированные языки.

Владение объектно-ориентированным языком программирования например,. Начинать показ со страницы:. Роман Апухтин 1 лет назад Просмотров: Управление конфигурацией программных средств. Модель бизнес-процесса помогает нам при определении Подробнее. Диаграммы вариантов использования Лекция 2.

Пример диаграммы вариантов использования Графическая Подробнее. Объектно-ориентированный анализ и дизайн Направление - Информатика и вычислительная Подробнее. Эта книга необходима всем Подробнее. Жизненный цикл ИС период времени, который начинается с момента принятия решения о необходимости Подробнее. Создание игр для мобильных телефонов М. Издательский дом ДМК-пресс, Подробнее. Технологии разработки ПО Для магистрантов: Промышленные технологии проектирования программного обеспечения 9-ый Подробнее.

Создаем чертежи на компьютере в AutoCAD Издание третье, переработанное Допущено УМО вузов по образованию в области дизайна, монументального и декоративного искусства в качестве учебного Подробнее. План главы Что такое UML? Документирование требований Документирование требований Чтобы требования, выявленные и описанные приняли силу соглашения между Заказчиком и Разработчиком, их необходимо оформит Документирование РФ Запад "Техническое задание", ТЗ Подробнее.

Решение экономических задач на компьютере Каплан А. К20 Решение экономических задач на компьютере Подробнее. Полное руководство по русской версии Кудрявцев Е. Широбокова Южно-Российский государственный политехнический Подробнее.

Санкт-Петербургский государственный политехнический университет План курса Введение Сложность, присущая Подробнее. Проектирование информационных систем Золотов Сергей Юрьевич к. Бернар Фигьера, Робер Кноэрp. Предисловие 19 Введение Объектно-ориентированный анализ и проектирование 29 Содержание Предисловие 19 Введение 21 Образовательные и Web-ресурсы 22 Для кого предназначена эта книга 22 Что необходимо знать 22 Примеры на языке Java 22 Структура книги 23 Об авторе 23 Контакты 24 Дополнения Подробнее.

Иерархия требований Use Case и ссылки на требования Диаграмма последовательности Подробнее. Санкт-Петербургский государственный политехнический университет План курса Подробнее. Моделирование, проектирование и расчет механических систем Кудрявцев Е. Моделирование, проектирование и расчет Подробнее. Что такое The UML. Но прежде чем обсуждать особенности языка, Подробнее.