История создания UML

Разработка UML началась в октябре 1994 года, когда Гради Буч и Jim Rumbaugh из Rational Software Corporation приступили к совместной работе по унифицированию методов Booch и OMT (Object Modeling Technique). Оба метода развивались независимо друг от друга и были по праву названы одними из лучших методов объектно-ориентированного подхода при разработке программных систем. Было принято решение об объединении этих двух методов, и в октябре 1995 вышла бета-версия, которая получила название Unified Method.

К концу 1996 года выяснилось, что ряд крупных компаний готовы рассмотреть UML в качестве основной стратегии своего бизнеса. Был создан некоммерческий консорциум OMG (Object Modeling Group), который объединил таких ведущих производителей ПО, как DEC, HP, IBM, Microsoft, Oracle, Rational Software и др. В январе 1997 был выдан UML 1.0. Вскоре к OMG примкнули такие компании, как IBM, Objectime, Platinum Technology и Softeam. Как результат этого сотрудничества появилась версия UML 1.1. В 2003 была принята версия 1.5. 2004 г. – принята версия 2.0

Структура UML

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

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

Прежде всего, UML наследует техники Booch, OMT и OOSE.

Во-вторых, перекрывает их.

В-третьих, надо отметить, что UML - это стандарт языка, а не стандарт процесса.

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

С самой общей точки зрения описание языка UML состоит из двух взаимодействующих частей, таких как:

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

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

Диаграммы UML

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

Проект, создаваемый с помощью языка UML 1.x, может включать в себя следующие диаграммы (сгруппированы в соответствии с их предназначением). Таких диаграмм насчитывается восемь :

· Диаграмма вариантов (прецедентов) использования (use case diagram)

· Диаграмма классов (class diagram)

· Диаграммы поведения (behavior diagrams)

o Диаграмма состояний (statechart diagram)

o Диаграмма активности (activity diagram)

o Диаграммы взаимодействия (interaction diagrams)

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

§ Диаграмма кооперации (collaboration diagram)

· Диаграммы реализации (implementation diagrams)

o Диаграмма компонентов (component diagram)

o Диаграмма размещения (развертывания) (deployment diagram)

3.1. Диаграмма вариантов (прецедентов) использования (use case diagram)

Диаграммы использования описывают функциональность ИС, которая будет видна пользователям системы. «Каждая функциональность» изображается в виде «прецедентов использования» (use case) или просто прецедентов. Прецедент - это типичное взаимодействие пользователя с системой, которое при этом:

описывает видимую пользователем функцию,

может представлять различные уровни детализации,

обеспечивает достижение конкретной цели, важной для пользователя.

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

На диаграммах прецедентов, кроме связей между действующими лицами и прецедентами, возможно использование еще двух видов связей между прецедентами: «использование» и «расширение» (рис. 3.1.1). Связь типа «расширение» применяется, когда один прецедент подобен другому, но несет несколько большую функциональную нагрузку. Ее следует применять при описании изменений в нормальном поведении системы. Связь типа «использование» позволяет выделить некий фрагмент поведения системы и включать его в различные прецеденты без повторного описания.

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

Чтобы разрешить эту сложную ситуацию, Стив Меллор (Steve Mellor) и Мартин Фаулер (Martin Fowler) независимо пришли к определению трех режимов использования UML разработчиками: режим эскиза , режим проектирования и режим языка программирования . Безусловно, самый главный из трех – это режим использования UML для эскизирования. В этом режиме разработчики используют UML для обмена информацией о различных аспектах системы. В режиме проектирования можно использовать эскизы при прямой и обратной разработке. При прямой разработке {forward-engineering) диаграммы рисуются до написания кода, а при обратной разработке (re verse-engineering) диаграммы строятся на основании исходного кода, чтобы лучше понять его.

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

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

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

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

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

При разработке моделей требуется более сложный инструментарий, чем при составлении эскизов, так как необходимо поддерживать детальность, соответствующую требованиям поставленной задачи. Специализированные CASE-средства (computer-aided software engineering - автоматизированная разработка программного обеспечения) попадают в эту категорию, хотя сам этот термин стал почти ругательным, и поставщики стараются его избегать. Инструменты прямой разработки поддерживают рисование диаграмм и копирование их в репозиторий с целью сохранения информации. Инструменты обратного проектирования читают исходный код, записывают его интерпретацию в репозиторий и генерируют диаграммы. Инструменты, позволяющие выполнять как прямую, так и обратную разработку, называются двухсторонними (round-trip).

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

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

Чем дольше вы работаете с UML, а программирование становится все более механическим, тем очевиднее становится необходимость перехода к автоматизированному созданию программ. Действительно многие CASE-средства так или иначе генерируют код, что позволяет автоматизировать построение значительной части системы. В конце концов, вы достигнете такой точки, когда сможете описать с помощью UML всю систему и перейдете в режим использования UML в качестве языка программирования . В такой среде разработчики рисуют диаграммы, которые компилируются прямо в исполняемый код, а UML становится исходным кодом. Очевидно, что такое применение UML требует особенно сложных инструментов. (Кроме того, нотации прямой и обратной разработки теряют всякий смысл, поскольку UML и исходный код становятся одним и тем же.)

Один из интересных вопросов, касающихся UML как языка программирования, - это вопрос о моделировании логики поведения. UML 2 предлагает три способа моделирования поведения: диаграммы взаимодействия, диаграммы состояний и диаграммы деятельности. Все они имеют своих сторонников в сфере программирования.

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

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

Нет строгих правил выбора точки зрения. Поскольку проблему можно рассматривать под разными углами зрения, то и способов применения существует довольно много. Некоторые инструменты автоматически преобразуют исходный код в диаграммы, трактуя UML как альтернативный вид исходного кода. Это в большей степени программный ракурс. Если же диаграммы UML применяются для того, чтобы проверить и понять различные значения терминов “пул активов” (asset pool) с группой бухгалтеров, то следует принять точку зрения значительно более близкую к концептуальной.

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

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

Резюме: было выделено 3 режима использования UML.

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

2 - режим проектирования. Цель - полнота. Составляется детальная модель, которая потом будет реализована (причём программист не должен особо задумываться над реализацией, его работа сводится к простым механическим действиям). Можно моделировать полностью, можно часть.

3 - режим языка программирования. Графические диаграммы компилируются в код, UML становится исходным кодом.

Ответ прошлых лет (Ден)

Язык Unified Modelling Language (UML) можно считать результатом довольно длинной и еще не завершившейся эволюции методологий моделирования и дизайна.

Данная унификация преследовала три основные цели:

· моделирование системы, начиная с концепции и заканчивая исполняемым модулем, с применением объектно-ориентированных методик;

· разрешение проблем масштабирования в сложных системах;

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

Для чего применяется UML

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

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

UML - это язык спецификаций и точных определений. В этом смысле моделирование на UML означает построение моделей, которые точны, недвусмысленны и полны.

UML - это язык документирования.

Диаграммы UML

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

Ниже приведены определения диаграмм:

· диаграмма классов (Class diagram) - структурная диаграмма, на которой показано множество классов, интерфейсов, коопераций и отношений между ними;

· диаграмма объектов (Object diagram) - структурная диаграмма, на которой показано множество объектов и отношений между ними. Ее можно считать особым случаем диаграммы классов. Инструментам моделирования не нужно поддерживать отдельный формат для диаграмм объектов. На них изображены объекты, поэтому диаграмма классов, на которой нет классов, но есть принадлежащие им объекты, может считаться диаграммой объектов;

· диаграмма прецедентов (Use case diagram) - диаграмма поведения, на которой показано множество прецедентов и актеров, а также отношений между ними;

· диаграммы взаимодействий (Interaction diagram) :

o диаграмма последовательностей (Sequence diagram) - диаграмма поведения, на которой показано взаимодействие и подчеркнута временная последовательность событий;

o диаграмма кооперации (Collaboration diagram) - диаграмма поведения, на которой показано взаимодействие и подчеркнута структурная организация объектов, посылающих и принимающих сообщения;

· диаграмма состояний (Statechart diagram) - диаграмма поведения, на которой показан автомат и подчеркнуто поведение объектов с точки зрения порядка получения событий;

· диаграмма активности (Activity diagram) - диаграмма поведения, на которой показан автомат и подчеркнуты переходы потока управления от одной деятельности к другой;

· диаграмма компонентов (Component diagram) - диаграмма, на которой изображена организация некоторого множества компонентов и зависимости между ними, - относится к статистическому виду системы;

· диаграмма топологии системы (Deployment diagram) - структурная диаграмма, на которой показаны узлы и отношения между ними.

Ответ прошлых лет (Мадина)

Вариант 1

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

Унифицированный язык моделирования (Unified Modeling Language - UML) - это язык для специфицирования, визуализации, конструирования и документирования на основе объектно-ориентированный подхода разные виды систем: программных, аппаратных, программно-аппаратных, смешанных, явно включающие деятельность людей и т. д.

Помимо прочего, язык UML применяется для проектирования реляционных БД. Для этого используется небольшая часть языка (диаграммы классов), да и то не в полном объеме. С точки зрения проектирования реляционных БД модельные возможности не слишком отличаются от возможностей ER-диаграмм

Диаграммой классов в терминологии UML называется диаграмма, на которой показан набор классов (и некоторых других сущностей), не имеющих явного отношения к проектированию БД), а также связей между этими классами. Ограничения могут неформально задаваться на естественном языке или формулироваться на языке объектных ограничений OCL (Object Constraints Language).

Классом называется именованное описание совокупности объектов с общими атрибутами, операциями, связями и семантикой. Графически класс изображается в виде прямоугольника. Имя (текстовая строка), служит для идентификации класса.

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

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

В диаграмме классов могут участвовать связи трех разных категорий: зависимость (dependency), обобщение (generalization) и ассоциация (association).

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

Связью-обобщением называется связь между общей сущностью, называемой суперклассом , или родителем, и более специализированной разновидностью этой сущности, называемой подклассом , или потомком. Обобщения иногда называют связями "is a" , имея в виду, что класс-потомок является частным случаем класса-предка. Класс-потомок наследует все атрибуты и операции класса-предка, но в нем могут быть определены дополнительные атрибуты и операции.

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

На этой диаграмме классы Студент и Исследователь порождены из одного суперкласса ЧеловекИзУниверситета . К классу Студент относятся те объекты класса ЧеловекИзУниверситета , которые соответствуют студентам, а к классу Исследователь - объекты класса ЧеловекИзУниверситета , соответствующие исследователям. Часто случается, многие студенты уже в студенческие годы начинают участвовать в исследовательских проектах, так что могут существовать такие два объекта классов Студент и Исследователь , которым соответствует один объект класса ЧеловекИзУниверситета . Таким образом среди объектов класса Студент могут быть исследователи, а некоторые исследователи могут быть студентами. Тогда можно определить класс СтудентИсследователь путем множественного наследования от суперклассов Студент и Исследователь . Объект класса СтудентИсследователь обладает всеми свойствами и операциями классов Студент и Исследователь и может быть использован везде, где могут применяться объекты этих классов. Так что полиморфизм по включению продолжает работать. Однако это влечет за собой ряд проблем. Например, при образовании подклассов Студент и Исследователь в них обоих может быть определен атрибут с именем Ip_адресКомпьютера . Для объектов класса Студент значениями этого атрибута будут ip-адрес компьютера терминального класса, а для объектов класса Исследователь - ip-адрес компьютера исследовательской лаборатории. При этом для объекта класса СтудентИсследователь могут быть существенны оба одноименных атрибута (у студента-исследователя могут иметься и ip-адрес компьютера терминального класса и ip-адрес компьютера исследовательской лаборатории). На практике применяется одно из следующих решений:

• запретить образование подкласса СтудентИсследователь , пока в одном из суперклассов не будет произведено переименование атрибута Ip_адресКомпьютера ;
• наследовать это свойство только от одного из суперклассов, так что, например, значением атрибута Ip_адресКомпьютера у объектов класса СтудентИсследователь всегда будут ip-адресом компьютера исследовательской лаборатории;
• унаследовать в подклассе оба свойства, но автоматически переименовать оба атрибута, чтобы прояснить их смысл; назвать их, например, Ip_адресКомпьютераСтудента и Ip_адресКомпьютераИсследователя .

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

Ассоциацией называется структурная связь, показывающая, что объекты одного класса некоторым образом связаны с объектами другого или того же самого класса. Допускается, чтобы оба конца ассоциации относились к одному классу. В ассоциации могут связываться два класса, и тогда она называется бинарной. Допускается создание ассоциаций, связывающих сразу n классов (они называются n-арными ассоциациями).1) Графически ассоциация изображается в виде линии, соединяющей класс сам с собой или с другими классами.

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

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

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

Наиболее распространенным способом задания кратности роли ассоциации является указание конкретного числа или диапазона. Указание "1" говорит о том, что каждый объект класса с данной ролью должен участвовать в некотором экземпляре данной ассоциации, причем в каждом экземпляре ассоциации может участвовать только один объект класса с данной ролью. Указание диапазона "0..1" говорит о том, что не все объекты класса с данной ролью обязаны участвовать в каком-либо экземпляре данной ассоциации, но в каждом экземпляре ассоциации может участвовать только один объект. Аналогично, указание диапазона "1..*" говорит о том, что все объекты класса с данной ролью должны участвовать в некотором экземпляре данной ассоциации, и в каждом экземпляре ассоциации должен участвовать хотя бы один объект (верхняя граница не задана). В более сложных случаях определения кратности можно использовать списки диапазонов.

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

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

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

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

В диаграммах классов могут указываться ограничения целостности, которые должны поддерживаться в проектируемой БД. В UML допускаются два способа определения ограничений: на естественном языке и на языке OCL (Object Constraints Language).

С точки зрения определения ограничений целостности баз данных более важны средства определения инвариантов классов.

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

Ниже приведены примеры инвариантов для задания ограничений на языке OCL.

1. Выразить на языке OCL ограничение, в соответствии с которым в отделах с номерами больше 5 должны работать сотрудники старше 30 лет

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

3. Условие четвертого инварианта ограничивает максимально возможное количество сотрудников компании числом 1000

Вариант 2

1. Модель RUP. Основные диаграммы модели RUP.

Рациональный унифицированный процесс (Rational Unified Process, RUP) - одна из спиральных методологий разработки программного обеспечения. Методология поддерживается компанией Rational Software, обновление продукта происходит примерно дважды в год. В качестве языка моделирования в общей базе знаний используется язык Unified Modelling Language (UML).

Итерационная разработка программного обеспечения в RUP предполагает разделение проекта на несколько мелких проектов, которые выполняются последовательно, и каждая итерация разработки четко определена набором целей, которые должны быть достигнуты в конце итерации. Конечная итерация предполагает, что набор целей итерации должен в точности совпадать с набором целей, указанных заказчиком продукта, то есть все требования должны быть выполнены. RUP предоставляет структурированный подход к итерационной разработке программного обеспечения, подразделяя процесс на четыре основные фазы во времени (milestones): Inception (исследование, начало), Elaboration (уточнение плана), Construction (конструирование, построение) и Transition (переход, развертывание). В RUP рекомендовано следовать шести практикам, позволяющим успешно разрабатывать проект:

Итеративная разработка;

Управление требованиями;

Использование модульных архитектур;

Визуальное моделирование;

Проверка качества;

Отслеживание изменений.

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

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

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

· диаграммы поведения (behavior diagrams)

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

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

· диаграммы взаимодействия (interaction diagrams)

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

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

· диаграммы реализации (implementation diagrams)

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

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

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

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

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

· связи , которые представляются различными линиями на плоскости;

· текст , содержащийся внутри границ отдельных геометрических фигур;

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

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

· представленные на диаграмме сущности модели должны быть одного концептуального уровня;

· вся информация о сущностях должна быть явно представлена на диаграмме;

· диаграммы не должны содержать противоречивой информации;

· диаграммы не следует перегружать текстовой информацией;

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

· количество типов диаграмм, необходимых для описания конкретной системы, не является строго фиксированным и определяется разработчиком;

· модели системы должны содержать только те элементы, которые определен

22. Проектирование ИС [J]

Готовый ответ Тони

Дополнены ответы Дениса Ковалевича

Стадия внедрения

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

· недостаток поддержки основного персонала, особенно когда надо уделить достаточно времени и энергии на критических стадиях;

· слишком амбициозные планы вместо пошагового, мудрого подхода;

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

Стадия эксплуатации

o повседневная эксплуатация;

Утилизация

Ответ прошлых лет (Мадина)

Внедрение.

2.1. Составление технических проектов (ТП).

консультанты исполнителя и ИТ-специалисты заказчика составляют ТП;

Заказчик утверждает ТП.

Уточняются объемы работ, сроки и стоимость.

Материалы ТП используются при планировании и документировании работ.

Состав ТП:

структура хранимых данных;

алгоритмы;

используемые ресурсы системы, их структура и связи;

пользовательский интерфейс.

2.2. Планирование работ.

В соответствии с утвержденным регламентом

менеджеры проекта исполнителя и заказчика составляют рабочие программы (РП);

заказчик и исполнитель утверждают РП.

Составляются индивидуальные планы участников рабочей команды.

Состав РП:

перечень работ: настройка, тестирование, приемка (в перечень работ могут входить ТЗ и ТП);

сроки выполнения работ;

ответственный за каждый пункт РП.

2.3. Заполнение основных справочников.

Особенности этапа:

может потребовать от 1 до 18 месяцев;

требует централизации ввода информации;

является необходимым условием работы системы.

Способы реализации:

конвертирование данных;

ручной ввод данных пользователями (операторами).

2.4. Настройка, тестирование, приемка.

Особенности этапа:

самый трудоемкий и ответственный;

существенно зависит от предварительной подготовки (регламенты, ТЗ, ТП, РП);

требует жесткой дисциплины как со стороны исполнителя, так и со стороны заказчика;

сопровождается появлением дополнительных заданий со стороны заказчика;

требует гибкости со стороны заказчика и Исполнителя для преодоления конфликтных ситуаций.

2.5. Опытная эксплуатация.

Особенности этапа:

требует оперативности и надежности отклика от исполнителя;

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

имеет значительную длительность (1-3 месяца);

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

2.6. Документирование.

оформление инструкций для пользователей;

оформление регламентов взаимодействия подразделений в рамках системы;

доработка технической документации;

формирование иных (заранее оговоренных) документов.

2.7. Завершение проекта.

юридическое закрытие договорных отношений;

окончательные финансовые расчеты;

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

Утилизации ИС – осушествляется кнопкой DELETE.

Ответ прошлых лет (Ден)

Стадия внедрения

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

Если на этой стадии возникают проблемы, то они связаны со следующими тремя основными причинами:

недостаток поддержки основного персонала, особенно когда надо уделить достаточно времени и энергии на критических стадиях;

слишком амбициозные планы вместо пошагового, мудрого подхода;

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

Стадия эксплуатации

· Ввод информационной системы в эксплуатацию

o ввод в опытную эксплуатацию технических средств;

o ввод в опытную эксплуатацию программных средств;

o обучение и сертифицирование персонала;

o проведение опытной эксплуатации компонентов и системы в целом;

o сдача в эксплуатацию и подписание актов приемки-сдачи работ.

· Эксплуатация информационной системы

o повседневная эксплуатация;

o сопровождение программных, технических средств и всего проекта.

Стадия поддержки (сопровождения)

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

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

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

· определение задач технического обслуживания и их разделение на внутренние, решаемые силами обслуживающего подразделения, и внешние, решаемые специализированными сервисными организациями (таким образом производится четкое определение круга исполняемых функций и разделение ответственности);

· проведение анализа имеющихся внутренних и внешних ресурсов, необходимых для организации технического обслуживания в рамках описанных задач и разделения компетенции (основные критерии для анализа: наличие гарантии на оборудование, состояние ремонтного фонда, квалификация персонала);

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

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

Утилизация

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

Очень подробно данная тема проработана на http://www.piter.com/attachment.php?barcode=978546900641&at=exc&n=0 и на http://www.rus-lib.ru/book/38/men/21/2.3.html

23. Проектирование ИС [J]

Похожая информация.

определение , подобное приведенному ниже.

Язык - система знаков, служащая:

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

Язык включает в себя набор знаков (словарь) и правила их употребления и интерпретации (грамматику).

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

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

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

К тому же примерно в это же время (начало 80-х) стартовала "объектно-ориентированная эра". Все началось с появлением семейства языков программирования SmallTalk, которые применяли некоторые понятия языка Simula-67, использовавшегося в 60-х годах. Появление объектно-ориентированного подхода в первую очередь было обусловлено увеличением сложности задач. Объектно-ориентированный подход внес достаточно радикальные изменения в сами принципы создания и функционирования программ, но, в то же время, позволил существенно повысить производительность труда программистов, по -иному взглянуть на проблемы и методы их решения, сделать программы более компактными и легко расширяемыми. Как результат, языки, первоначально ориентированные на традиционный подход к программированию, получили ряд объектноориентированных расширений. Одной из первых, в середине 80-х, была фирма Apple со своим проектом Object Pascal . Кроме этого, объектно-ориентированный подход породил мощную волну и абсолютно новых программных технологий, вершинами которой стали такие общепризнанные сегодня платформы, как Microsoft . NET Framework и Sun Java .

Но самое главное, что появление ООП требовало удобного инструмента для моделирования, единой нотации для описания сложных программных систем. И вот "три амиго", три крупнейших специалиста, три автора наиболее популярных методов решили объединить свои разработки. В 1991-м каждый из "трех амиго" начал с написания книги, в которой изложил свой метод ООАП. Каждая методология была

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

Краткая история UML

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

По запросу Object Management Group (OMG) – организации, ответственной за принятие стандартов в области объектных технологий и баз данных назревшая проблема унификации и стандартизации была решена авторами трех наиболее популярных ОО методов – Г.Бучем, Д.Рамбо и А.Джекобсоном, которые объединенными усилиями создали версию UML 1.1, утвержденную OMG в 1997 году в качестве стандарта.

UML – это язык

Любой язык состоит из словаря и правил комбинирования слов для получения осмысленных конструкций. Так, в частности, устроены языки программирования, таковым является и UML. Отличительной его особенностью является то, что словарь языка образуют графические элементы. Каждому графическому символу соответствует конкретная семантика, поэтому модель, созданная одним разработчиком, может однозначно быть понята другим, а также программным средством, интерпретирующим UML. Отсюда, в частности, следует, что модель ПС, представленная на UML, может автоматически быть переведена на ОО язык программирования (такой, как Java, C++, VisualBasic), то есть, при наличии хорошего инструментального средства визуального моделирования, поддерживающего UML, построив модель, мы получим и заготовку программного кода, соответствующего этой модели.

Следует подчеркнуть, что UML – это именно язык, а не метод. Он объясняет, из каких элементов создавать модели и как их читать, но ничего не говорит о том, какие модели и в каких случаях следует разрабатывать. Чтобы создать метод на базе UML, надо дополнить его описанием процесса разработки ПС. Примером такого процесса является Rational Unified Process, который будет рассматриваться в последующих статьях.

Словарь UML

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

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

Отношения показывают различные связи между сущностями. В UML определены следующие типы отношений:

• Зависимость показывает такую связь между двумя сущностями, когда изменение одной из них – независимой – может повлиять на семантику другой – зависимой. Зависимость изображается пунктирной стрелкой, направленной от зависимой сущности к независимой.
• Ассоциация – это структурное отношение, показывающее, что объекты одной сущности связаны с объектами другой. Графически ассоциация показывается в виде линии, соединяющей связываемые сущности. Ассоциации служат для осуществления навигации между объектами. Например, ассоциация между классами «Заказ» и «Товар» может быть использована для нахождения всех товаров, указанных в конкретном заказе – с одной стороны, или для нахождения всех заказов в которых есть данный товар, – с другой. Понятно, что в соответствующих программах должен быть реализован механизм, обеспечивающий такую навигацию. Если требуется навигация только в одном направлении, оно показывается стрелкой на конце ассоциации. Частным случаем ассоциации является агрегирование – отношение вида «целое» – «часть». Графически оно выделяется с помощью ромбика на конце около сущности-целого.
• Обобщение – это отношение между сущностью-родителем и сущностью-потомком. По существу, это отношение отражает свойство наследования для классов и объектов. Обобщение показывается в виде линии, заканчивающейся треугольничком направленным к родительской сущности. Потомок наследует структуру (атрибуты) и поведение (методы) родителя, но в то же время он может иметь новые элементы структуры и новые методы. UML допускает множественное наследование, когда сущность связана более чем с одной родительской сущностью.
• Реализация – отношение между сущностью, определяющей спецификацию поведения (интерфейс) с сущностью, определяющей реализацию этого поведения (класс, компонент). Это отношение обычно используется при моделировании компонент и будет подробнее описано в последующих статьях.

Диаграммы. В UML предусмотрены следующие диаграммы:

• Диаграммы, описывающие поведение системы:
• Диаграммы состояний (State diagrams),
• Диаграммы деятельностей (Activity diagrams),
• Диаграммы объектов (Object diagrams),
• Диаграммы последовательностей (Sequence diagrams),
• Диаграммы взаимодействия (Collaboration diagrams);
• Диаграммы, описывающие физическую реализацию системы:
• Диаграммы компонент (Component diagrams);
• Диаграммы развертывания (Deployment diagrams).

Представление управления моделью. Пакеты.

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

Что обеспечивает UML.

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

И последнее…

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

Унифицированный язык моделирования (UML) является стандартным инструментом для создания «чертежей» информационных систем (ИС). С помощью UML можно визуализировать, специфицировать, конструировать и документировать элементы этих систем.

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

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

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

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

Использование UML позволяет решить третью проблему: явная модель облегчает общение.

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

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

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

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

При разработке ИС, создаются и такие элементы, как:

• требования к системе;
• описание архитектуры;
• проект;
• исходный код;
• проектные планы;
• тесты;
• прототипы;
• версии, и др.

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

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

Где используется UML

Язык UML предназначен прежде всего для разработки информационных систем. Его использование особенно эффективно в следующих областях:

• информационные системы масштаба предприятия;
• банковские и финансовые услуги;
• телекоммуникации;
• транспорт;
• оборонная промышленность, авиация и космонавтика;
• розничная торговля;
• медицинская электроника;
• наука;
• распределенные Web-системы.

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

Концептуальная модель UML

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

Строительные блоки UML

Словарь языка UML включает три вида строительных блоков:

• сущности;
• отношения;
• диаграммы.

Сущности — это абстракции, являющиеся основными элементами модели. Отношения связывают различные сущности; диаграммы группируют представляющие интерес совокупности сущностей.

В UML имеется четыре типа сущностей:

• структурные;
• поведенческие;
• группирующие;
• аннотационные.

Сущности являются основными объектно-ориентированными блоками языка. С их помощью можно создавать корректные модели. Существует семь разновидностей структурных сущностей:

• Класс (Class)
• Интерфейс (Interface)
• Кооперация (Collaboration)
• Прецедент (Use case)
• Активным классом (Active class)
• Компонент (Component)
• Узел (Node)

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

Поведенческие сущности (Behavioral things) являются динамическими составляющими модели UML. Это глаголы языка: они описывают поведение модели во времени и пространстве. Существует всего два основных типа поведенческих сущностей:

• Взаимодействие (Interaction)
• Автомат (State machine)

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

Группирующие сущности являются организующими частями модели UML. Это блоки, на которые можно разложить модель . Есть только одна первичная группирующая сущность, а именно пакет .

Пакеты — это основные группирующие сущности, с помощью которых можно организовать модель UML Существуют также вариации пакетов, например каркасы (Frameworks), модели и подсистемы.

Аннотационные сущности — пояснительные части модели UML. Это комментарии для дополнительного описания, разъяснения или замечания к любому элементу модели. Имеется только один базовый тип аннотационных элементов — примечание (Note). Примечание — это просто символ для изображения комментариев или ограничений, присоединенных к элементу или группе элементов. Графически примечание изображается в виде прямоугольника с загнутым краем, содержащим текстовый или графический комментарий.

В языке UML определены четыре типа отношений:

• зависимость;
• ассоциация;
• обобщение;
• реализация.

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

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

• диаграммы классов;
• диаграммы объектов;
• диаграммы прецедентов;
• диаграммы последовательностей;
• диаграммы кооперации;
• диаграммы состояний;
• диаграммы действий;
• диаграммы компонентов;
• диаграммы развертывания.

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

Правила языка UML

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

В языке UML имеются семантические правила, позволяющие корректно и однозначно определять:

• имена , которые можно давать сущностям, отношениям и диаграммам;
• область действия (контекст, в котором имя имеет некоторое значение);
• видимость (когда имена видимы и могут использоваться другими элементами);
• целостность (как элементы должны правильно и согласованно соотноситься друг с другом);
• выполнение {что значит выполнить или имитировать некоторую динамическую модель).

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

• содержат скрытые элементы (ряд элементов не показывают, чтобы упростить восприятие);
• неполные (отдельные элементы пропущены);
• несогласованные (целостность модели не гарантируется).

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

Общие механизмы языка UML

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

• спецификации (Specifications);
• дополнения (Adornments);
• принятые деления (Common divisions);
• механизмы расширения (Extensibility mechanisms).

Архитектура

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

Архитектура — это совокупность существенных решений касательно:

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

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

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

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

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

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

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

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