Основу роли 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
- Модель 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 не заканчивается на моделировании всевозможного ПО. Также данный язык активно сегодня используется для моделирования различных бизнес-процессов, ведения системного проектирования, а также отображения организационных структур.
С помощью UML разработчики программного обеспечения могут обеспечить полное соглашение в используемых графических обозначениях, чтобы представить общие понятия, такие как: компонент, обобщение, класс, поведение и агрегация. За счет этого достигается большая степень концентрации на архитектуре и проектировании.
Также стоит отметить, что есть несколько видов таких диаграмм.
Диаграмма классов
Диаграмма классов UML представляет собой статическую структурную диаграмму, предназначенную для описания структуры системы, а также демонстрации атрибутов, методов и зависимостей между несколькими различными классами.
Стоит отметить тот факт, что есть несколько точек зрения на построение таких диаграмм в зависимости от того, каким образом они будут использоваться:
- Концептуальная. В данном случае диаграмма классов UML осуществляет описание модели определенной предметной области, и в ней предусматриваются только классы прикладных объектов.
- Специфическая. Диаграмма используется в процессе проектирования различных информационных систем.
- Реализационная. Диаграмма классов включает в себя всевозможные классы, которые непосредственно используются в программном коде.
Диаграмма компонентов
Диаграмма компонентов UML представляет собой полностью статическую структурную диаграмму. Предназначается она для того, чтобы продемонстрировать разбиение определенной программной системы на разнообразные структурные компоненты, а также связи между ними. Диаграмма компонентов UML в качестве таковых может использовать всевозможные модели, библиотеки, файлы, пакеты, исполняемые файлы и еще множество других элементов.
Диаграмма композитной/составной структуры
UML диаграмма композитной/составной структуры также является статической структурной диаграммой, но используется она для того, чтобы показать внутреннюю структуру классов. По возможности данная диаграмма может продемонстрировать также взаимодействие элементов, находящихся во внутренней структуре класса.
Подвидом их является UML-диаграмма кооперации, которая используется для демонстрации ролей, а также взаимодействия различных классов в границах кооперации. Они являются достаточно удобными в том случае, если нужно моделировать шаблоны проектирования.
Стоит отметить, что одновременно могут использоваться виды диаграмм UML классов и композитной структуры.
Диаграмма развертывания
Данная диаграмма используется для того, чтобы моделировать работающие узлы, а также всевозможные артефакты, которые на них были развернуты. В UML 2 на различных узлах осуществляется разворачивание артефактов, в то время как в первой версии разворачивались исключительно компоненты. Таким образом, диаграмма развертывания UML используется преимущественно ко второй версии.
Между артефактом и тем компонентом, который он реализует, формируется зависимость манифестации.
Диаграмма объектов
Данный вид позволяет увидеть полноценный или же частичный снимок создаваемой системы в определенный момент времени. На ней полностью отображаются все экземпляры классов конкретной системы с указанием текущих значений их параметров, а также связей между ними.
Диаграмма пакетов
Эта диаграмма носит структурный характер, и основным ее содержанием являются всевозможные пакеты, а также отношения между ними. В данном случае нет никакого жесткого разделения между несколькими структурными диаграммами, вследствие чего их использование чаще всего встречается исключительно для удобства, и никакого семантического значения в себе не несет. Стоит отметить, что различные элементы могут предоставлять другие UML диаграммы (примеры: пакеты и сами диаграммы пакетов).
Их использование осуществляется для того, чтобы обеспечить организацию нескольких элементов в группы по определенному признаку, чтобы упростить структуру, а также организовать работу с моделью данной системы.
Диаграмма деятельности
Диаграмма деятельности UML отображает разложение определенной деятельности на несколько составных частей. В данном случае понятием «деятельность» называется спецификация определенного исполняемого поведения в виде параллельного, а также координированного последовательного выполнения различных подчиненных элементов - вложенных типов деятельности и различных действий, объединенных потоками, идущими от выходов определенного узла к входам другого.
Диаграмма деятельности UML достаточно часто используются для того, чтобы моделировать различные бизнес-процессы, параллельные и последовательные вычисления. Помимо всего прочего ими моделируются всевозможные технологические процедуры.
Диаграмма автомата
Этот вид называется и несколько иначе - диаграмма состояний UML. Имеет представленный конечный автомат с простыми и композитными состояниями, а также переходами.
Конечный автомат представляет собой спецификацию последовательности различных состояний, через которые проходит определенный объект, или же взаимодействие в ответ на некоторые события своей жизни, а также ответные действия объекта на такие события. Конечный автомат, который использует диаграмма состояний UML, закрепляется за исходным элементом и используется для того, чтобы определить поведение его экземпляров.
В качестве аналогов таких диаграмм могут использоваться так называемые дракон-схемы.
Диаграммы сценариев использования
Диаграмма вариантов использования UML отображает на себе все отношения, которые возникают между актерами, а также различными вариантами использования. Главная ее задача - осуществлять собой полноценное средство, при помощи которого заказчик, конечный пользователь или же какой-нибудь разработчик сможет совместно обсуждать поведение и функциональность определенной системы.
Если диаграмма вариантов использования UML используется в процессе моделирования системы, то аналитик собирается:
- Четко отделить моделируемую систему от ее окружения.
- Выявить действующих лиц, пути их взаимодействия с данной системой, а также ожидаемый ее функционал.
- Установить в глоссарии в качестве предметной области различные понятия, которые относятся к подробному описанию функционала данной системы.
Если разрабатывается в UML диаграмма использования, процедура начинается с текстового описания, которое получается при работе с заказчиком. При этом стоит отметить тот факт, что различные нефункциональные требования в процессе составления модели прецедентов полностью опускаются, и для них уже будет формироваться отдельный документ.
Коммуникации
Диаграмма коммуникации точно так же, как и диаграмма последовательности UML, является транзитивной, то есть выражает в себе взаимодействие, но при этом демонстрирует его разными способами, и при необходимости с нужной степенью точности можно преобразовать одну в другую.
Диаграмма коммуникации отображает в себе взаимодействия, которые происходят между различными элементами композитной структуры, а также ролями кооперации. Главным отличием ее от диаграммы последовательности является то, что на ней достаточно явно указываются отношения между несколькими элементами, а время не используется в качестве отдельного измерения.
Данный тип отличается абсолютно свободным форматом упорядочивания нескольких объектов и связей точно так же, как это осуществляется в диаграмме объектов. Если есть необходимость в том, чтобы поддерживать порядок сообщений при этом свободном формате, осуществляется их хронологическая нумерация. Чтение данной диаграммы начинается с изначального сообщения 1.0, и впоследствии продолжается по тому направлению, по которому осуществляется передача сообщений от одного объекта к другому.
В большинстве своем такие диаграммы демонстрируют точно такую же информацию, которую предоставляет нам диаграмма последовательности, однако из-за того, что здесь используется другой способ представления информации, определенные вещи на одной диаграмме становится гораздо проще определить, чем на другой. Также стоит отметить, что диаграмма коммуникаций более наглядно показывает, с какими элементами вступает во взаимодействие каждый отдельный элемент, в то время как диаграмма последовательности более ясно показывает, в каком порядке осуществляются взаимодействия.
Диаграмма последовательности
Диаграмма последовательности UML демонстрирует взаимодействия между несколькими объектами, которые упорядочиваются в соответствии с временем их проявления. На такой диаграмме отображается упорядоченное во времени взаимодействие между несколькими объектами. В частности, на ней отображаются все объекты, которые принимают участие во взаимодействии, а также полная последовательность обмениваемых ими сообщений.
Главными элементами в данном случае выступают обозначения различных объектов, а также вертикальные линии, отображающие течение времени и прямоугольники, предоставляющие деятельность определенного объекта или же выполнение им какой-либо функции.
Диаграмма сотрудничества
Данный тип диаграмм позволяет продемонстрировать взаимодействия между несколькими объектами, абстрагируясь от последовательности трансляции сообщений. Данный тип диаграмм в компактном виде отображает в себе абсолютно все передаваемые и принимаемые сообщения определенного объекта, а также форматы этих сообщений.
По причине того, что диаграммы последовательности и коммуникации представляют собой просто-напросто разный взгляд на одни и те же процедуры, Rational Rose предоставляет возможность создавать из диаграммы последовательности коммуникационную или же наоборот, а также осуществляет полностью автоматическую их синхронизацию.
Диаграммы обзора взаимодействия
Это диаграммы языка UML, которые относятся к разновидности диаграмм деятельности и включают в себя одновременно элементы Sequence и конструкции потока управления.
Стоит отметить тот факт, что данный формат объединяет в себе Collaboration и Sequence diagram, которые предоставляют возможность с разных точек зрения рассматривать взаимодействие между несколькими объектами в формируемой системе.
Диаграмма синхронизации
Представляет собой альтернативный вариант диаграммы последовательности, который явным образом демонстрирует изменение состояния на линии жизни с определенной шкалой времени. Может быть достаточно полезной в различных приложениях реального времени.
В чем преимущества?
Стоит отметить несколько преимуществ, которыми отличается UML диаграмма пользования и другие:
- Язык является объектно-ориентированным, вследствие чего технологии описания результатов проведенного анализа и проектирования являются семантически близкими к методам программирования на всевозможных объектно-ориентированных языках современного типа.
- При помощи данного языка система может быть описана практически с любых возможных точек зрения, и точно так же описываются различные аспекты ее поведения.
- Все диаграммы являются сравнительно простыми для чтения даже после относительно быстрого ознакомления с его синтаксисом.
- UML позволяет расширить, а также вводить собственные графические и текстовые стереотипы, что способствует его использованию не только в программной инженерии.
- Язык получил достаточно широкое распространение, а также довольно активно развивается.
Недостатки
Несмотря на то что построение UML-диаграмм отличается массой своих плюсов, довольно часто их и критикуют за следующие недостатки:
- Избыточность. В преимущественном большинстве случаев критики говорят о том, что UML является слишком большим и сложным, и зачастую это неоправданно. В него входит достаточно много избыточных или же практически бесполезных конструкций и диаграмм, причем наиболее часто подобная критика идет в адрес второй версии, а не первой, потому что в более новых ревизиях присутствует большее количество компромиссов «разработанных комитетом».
- Различные неточности в семантике. По той причине, что UML определяется комбинацией себя, английского и OCL, у него отсутствует скованность, которая является присущей для языков, точно определенных техникой формального описания. В определенных ситуациях абстрактный синтаксис OCL, UML и английский начинают друг другу противоречить, в то время как в других случаях они являются неполными. Неточность описания самого языка одинаково отражается как на пользователях, так и на поставщиках инструментов, что в конечном итоге приводит к несовместимости инструментов из-за уникального способа трактовки различных спецификаций.
- Проблемы в процессе внедрения и изучения. Все указанные выше проблемы создают определенные сложности в процессе внедрения и изучения UML, и в особенности это касается тех случаев, когда руководство заставляет инженеров насильно его использовать, в то время как у них отсутствуют предварительные навыки.
- Код отражает код. Еще одним мнением является то, что важность имеют не красивые и привлекательные модели, а непосредственно рабочие системы, то есть код и есть проект. В соответствии с данным мнением есть потребность в том, чтобы разработать более эффективный способ написания программного обеспечения. UML принято ценить при подходах, компилирующих модели для регенерирования выполнимого или же исходного кода. Но на самом деле этого может быть недостаточно, потому что в данном языке отсутствуют свойства полноты по Тьюрингу, и каждый сгенерированный код в конечном итоге будет ограничиваться тем, что может предположить или же определить интерпретирующий UML инструмент.
- Рассогласование нагрузки. Данный термин происходит из теории системного анализа для определения неспособности входа определенной системы воспринять выход иной. Как в любых стандартных системах обозначений, UML может представлять одни системы в более эффективном и кратком виде по сравнению с другими. Таким образом, разработчик больше склоняется к тем решениям, которые являются более комфортными для переплетения всех сильных сторон UML, а также других языков программирования. Данная проблема является более очевидной в том случае, если язык разработки не соответствует основным принципам объектно-ориентированной ортодоксальной доктрины, то есть не старается работать в соответствии с принципами ООП.
- Пытается быть универсальным. UML представляет собой язык моделирования общего назначения, который старается обеспечить совместимость с любым существующим на сегодняшний день языком обработки. В контексте определенного проекта, для того, чтобы команда проектировщиков смогла добиться конечной цели, нужно выбирать применимые возможности этого языка. Помимо этого возможные пути ограничения сферы использования UML в какой-то определенной области проходят через формализм, который является не полностью сформулированным, а который сам представляет собой объект критики.
Таким образом, использование данного языка является актуальным далеко не во всех ситуациях.
Большинство существующих методов объектно-ориентированного анализа и проектирования (ООАП) включают как язык моделирования, так и описание процесса моделирования. Язык моделирования – это нотация (в основном графическая), которая используется методом для описания проектов.
Нотация представляет собой совокупность графических объектов, которые используются в моделях; она является синтаксисом языка моделирования. Например, нотация диаграммы классов определяет, каким образом представляются такие элементы и понятия, как класс, ассоциация и множественность.
Процесс – это описание шагов, которые необходимо выполнить при разработке проекта.
Унифицированный язык моделирования UML (Unified Modeling Language) – это преемник того поколения методов ООАП, которые появились в конце 80-х и начале 90-х гг.
Язык UML представляет собой общецелевой язык визуального моделирования, который разработан для спецификации, визуализации, проектирования и документирования компонентов программного обеспечения, бизнес-процессов и других систем. Язык UML одновременно является простым и мощным средством моделирования, который может быть эффективно использован для построения концептуальных, логических и графических моделей сложных систем самого различного целевого назначения.
Конструктивное использование языка UML основывается на понимании общих принципов моделирования сложных систем и особенностей процесса объектно-ориентированного проектирования (ООП) в частности. Выбор выразительных средств для построения моделей сложных систем предопределяет те задачи, которые могут быть решены с использованием данных моделей. При этом одним из основных принципов построения моделей сложных систем является принцип абстрагирования, который предписывает включать в модель только те аспекты проектируемой системы, которые имеют непосредственное отношение к выполнению системой своих функций или своего целевого предназначения. При этом все второстепенные детали опускаются, чтобы чрезмерно не усложнять процесс анализа и исследования полученной модели.
Другим принципом построения моделей сложных систем является принцип многомодельности . Этот принцип представляет собой утверждение о том, что никакая единственная модель не может с достаточной степенью адекватности описывать различные аспекты сложной системы. Применительно к методологии ООП это означает, что достаточно полная модель сложной системы допускает некоторое число взаимосвязанных представлений (views), каждое из которых адекватно отражает некоторый аспект поведения или структуры системы. При этом наиболее общими представлениями сложной системы принято считать статическое и динамическое представления, которые в свою очередь могут подразделяться на другие более частные представления.) феномен сложной системы как раз и состоит в том, что никакое ее единственное представление не является достаточным для адекватного выражения всех особенностей моделируемой системы.
Еще одним принципом прикладного системного анализа является принцип иерархического построения моделей сложных систем. Этот принцип предписывает рассматривать процесс построения модели на разных уровнях абстрагирования или детализации в рамках фиксированных представлений. При этом исходная или первоначальная модель сложной системы имеет наиболее общее представление (метапредставление). Такая модель строится на начальном этапе проектирования и может не содержать многих деталей и аспектов моделируемой системы.
Создание UML фактически началось в конце 1994 г., когда Гради Б уч и Джеймс Рамбо начали работу по объединению методов Booch и ОМТ (Object Modeling Technique) под эгидой компании Rational Software. К концу 1995 г. они создали первую спецификацию объединенного метода, названного ими Unified Method, версия 0.8. Тогда же, в 1995 г., к ним присоединился создатель метода OOSE (Object-Oriented Software Engineering) Ивар Якобсон . Таким образом, UML является прямым объединением и унификацией методов Буча, Рамбо и Якобсона , однако дополняет их новыми возможностями.
Главными в разработке UML были следующие цели:
– предоставить пользователям готовый к использованию выразительный язык визуального моделирования, позволяющий разрабатывать осмысленные модели и обмениваться ими;
– предусмотреть механизмы расширяемости и специализации для расширения базовых концепций;
– обеспечить независимость от конкретных языков программирования и процессов разработки;
– обеспечить формальную основу для понимания этого языка моделирования (язык должен быть одновременно точным и доступным для понимания, без лишнего формализма);
– стимулировать рост рынка объектно-ориентированных инструментальных средств;
– интегрировать лучший практический опыт.
Язык UML находится в процессе стандартизации, проводимом OMG (Object Management Group) – организацией по стандартизации в области объектно-ориентированных методов и технологий, в настоящее время принят в качестве стандартного языка моделирования и получил широкую поддержку в индустрии ПО.
Язык UML принят на вооружение практически всеми крупнейшими компаниями – производителями ПО (Microsoft, IBM, Hewlett-Packard, Oracle, Sybase и др.). Кроме того, практически все мировые производители CASE-средств, помимо Rational Software (Rational Rose), поддерживают UML в своих продуктах (Paradigm Plus 3.6, System Architec, Microsoft Visual Modeler for Visual Basic, Delphi, PowerBuilder и др.). Полное описание UML можно найти на сайтах http://www.omg.urg, http://www.rational.com и http://uml.shl.com. Описание UML на русском языке содержится в книге М. Фаулера и К. Скотта, в дальнейшем изложении терминология языка соответствует данному переводу.
Создатели UML представляют его как язык для определения, представления, проектирования и документирования программных систем, организационно-экономических, технических и др.
UML содержит стандартный набор диаграмм и нотаций самых разнообразных видов.
Диаграмма в UML – это графическое представление набора элементов, изображаемое чаще всего в виде связанного графа с вершинами (сущностями) и ребрами (отношениями). Диаграммы рисуют для визуализации системы с разных точек зрения.
Диаграмма – в некотором смысле одна из проекций системы. Как правило, за исключением наиболее тривиальных случаев, диаграммы дают свернутое представление элементов, из которых составлена система. Один и тот же элемент может присутствовать во всех диаграммах, или только в нескольких (самый распространенный вариант), или не присутствовать ни в одной (очень редко).
Теоретически диаграммы могут содержать любые комбинации сущностей и отношений. На практике, однако, применяется сравнительно небольшое количество типовых комбинаций, соответствующих пяти наиболее употребительным видам, которые составляют архитектуру программной системы.
В UML выделяют следующие типы диаграмм:
– диаграммы вариантов использования (usecase diagrams) – для моделирования бизнес-процессов организации (требований к системе);
– диаграммы классов (class diagrams) – для моделирования статической структуры классов системы и связей между ними. На таких диаграммах показывают классы, интерфейсы, объекты и кооперации, а также их отношения. При моделировании объектно-ориентированных систем этот тип диаграмм используют чаще всего. Диаграммы классов соответствуют статическому виду системы с точки зрения проектирования;
– диаграммы поведения системы (behavior diagrams);
– диаграммы взаимодействия (interaction diagrams) – для моделирования процесса обмена сообщениями между объектами. Существуют два вида диаграмм взаимодействия: диаграммы последовательности (sequence diagrams) и кооперативные диаграммы (collaboration diagrams). На диаграммах взаимодействия представлены связи между объектами; показаны, в частности, сообщения, которыми объекты могут обмениваться. Диаграммы взаимодействия относятся к динамическому виду системы. При этом диаграммы последовательности отражают временную упорядоченность сообщений, а диаграммы кооперации – структурную организацию обменивающихся сообщениями объектов. Эти диаграммы являются изоморфными, то есть могут быть преобразованы друг в друга;
– диаграммы состояний (statechart diagrams) – для моделирования поведения объектов системы при переходе из одного состояния в другое. На них представлен автомат, включающий в себя состояния, переходы, события и виды действий. Диаграммы состояний относятся к динамическому виду системы; особенно они важны при моделировании поведения интерфейса, класса или кооперации. Они акцентируют внимание на поведении объекта, зависящем от последовательности событий, что очень полезно для моделирования реактивных систем;
– диаграммы деятельностей (activity diagrams) – для моделирования поведения системы в рамках различных вариантов использования или моделирования деятельностей. Это частный случай диаграммы состояний; на ней представлены переходы потока управления от одной деятельности к другой внутри системы. Диаграммы деятельности относятся к динамическому виду системы; они наиболее важны при моделировании ее функционирования и отражают поток управления между объектами;
– диаграммы реализации (implementation diagrams): диаграммы компонентов (component diagrams) – для моделирования иерархии компонентов (подсистем) системы; диаграммы размещения (deployment diagrams) – для моделирования физической архитектуры системы. На диаграмме компонентов представлена организация совокупности компонентов и существующие между ними зависимости. Диаграммы компонентов относятся к статическому виду системы с точки зрения реализации. Они могут быть соотнесены с диаграммами классов, так как компонент обычно отображается на один или несколько классов, интерфейсов или коопераций.Краткая история UML
Объектно-ориентированные языки моделирования появились в период с середины 70-х до конца 80-х годов, когда исследователи, поставленные перед необходимостью учитывать новые возможности объектно-ориентированных языков программирования и требования, предъявляемые все более сложными приложениями, вынуждены были начать разработку различных альтернативных подходов к анализу и проектированию.
С 1989 по 1994 год число различных объектно-ориентированных методов возросло с десяти более чем до пятидесяти. Тем не менее, многие пользователи испытывали затруднения при выборе языка моделирования, который бы полностью соответствовал их потребностям, что послужило причиной так называемой «войны методов». В результате этих войн появилось новое поколение методов, среди которых особое значение приобрели языки Booch , созданный Грейди Бучем (Grady Booch), OOSE (Object-Oriented Software Engineering), разработанный Айваром Джекобсоном (Ivar Jacobson) и ОМТ (Object Modeling Technique), автором которого является Джеймс Рамбо (James Rumbaugh). Кроме того, следует упомянуть языки Fusion, Шлаера-Меллора (Shlaer-Mellor) и Коада-Йордона (Coad-Yourdon). Каждый из этих методов можно считать вполне целостным и законченным, хотя любой из них имеет не только сильные, но и слабые стороны.
Выразительные возможности метода Буча особенно важны на этапах проектирования и конструирования модели. OOSE великолепно приспособлен для анализа и формулирования требований, а также для высокоуровневого проектирования. ОМТ-2 оказался особенно полезным для анализа и разработки информационных систем, ориентированных на обработку больших объемов данных.
Критическая масса новых идей начала формироваться к середине 90-х годов, когда Грейди Буч (компания Rational Software Corporation), Айвар Джекобсон (Objectory) и Джеймс Рамбо (General Electric) предприняли попытку объединить свои методы, уже получившие мировое признание как наиболее перспективные в данной области. Являясь основными авторами языков Booch, OOSE и ОМТ , партнеры попытались создать новый, унифицированный язык моделирования и руководствовались при этом тремя соображениями.
Во-первых, все три метода, независимо от желания разработчиков, уже развивались во встречном направлении. Разумно было продолжать эту эволюцию вместе, а не по отдельности, что помогло бы в будущем устранить нежелательные различия и, как следствие, неудобства для пользователей.
Во-вторых, унифицировав методы, проще было привнести стабильность на рынок инструментов объектно-ориентированного моделирования, что дало бы возможность положить в основу всех проектов единый зрелый язык, а создателям инструментальных средств позволило бы сосредоточиться на более продуктивной деятельности.
Наконец, следовало полагать, что подобное сотрудничество приведет к усовершенствованию всех трех методов и обеспечит решение задач, для которых любой из них, взятый в отдельности, был не слишком пригоден.
– моделировать системы целиком, от концепции до исполняемого артефакта, с помощью объектно-ориентированных методов;
– решить проблему масштабируемости, которая присуща сложным системам, предназначенным для выполнения ответственных задач;
– создать такой язык моделирования, который может использоваться не только людьми, но и компьютерами.
Изобретение языка для объектно-ориентированного анализа и проектирования не слишком отличается от разработки языка программирования. Во-первых , требовалось ограничить задачу. Следует ли включать в язык возможность спецификации требований? Должен ли язык позволять визуальное программирование? Во-вторых , было необходимо найти точку равновесия между выразительной мощью и простотой. Слишком простой язык ограничил бы круг решаемых с его помощью задач, а слишком сложный мог ошеломить неискушенного разработчика. Кроме того, при объединении существующих методов приходилось учитывать наличие уже разработанных с их помощью продуктов. Внесение слишком большого числа изменений могло бы оттолкнуть уже имевшихся пользователей, а сопротивляясь развитию языка, авторы потеряли бы возможность привлекать новых пользователей и делать язык более простым и удобным для применения. Создавая UML, разработчики старались найти оптимальное решение этих проблем.
Официально создание UML началось в октябре 1994 года , когда Рамбо перешел в компанию Rational Software, где работал Буч. Первоначальной целью было объединение методов Буча и ОМТ. Первая пробная версия 0.8 Унифицированного Метода (Unified Method), как его тогда называли, появилась в октябре 1995 года . Приблизительно в это же время в компанию Rational перешел Джекобсон, и проект UML был расширен с целью включить в него язык OOSE. В результате совместных усилий в июне 1996 года вышла версия 0.9 языка UML . На протяжении всего года создатели занимались сбором отзывов от основных компаний, работающих в области конструирования программного обеспечения. За это время стало ясно, что большинство таких компаний сочло UML языком, имеющим стратегическое значение для их бизнеса. В результате был основан консорциум UML, в который вошли организации, изъявившие желание предоставить ресурсы для работы, направленной на создание полного определения UML.
Версия 1.0 языка появилась в результате совместных усилий компаний Digital Equipment Corporation, Hewlett Packard, I-Logix, Intellicprp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational, Texas Instruments и Unisys. UML 1.0 оказался хорошо определенным, выразительным, мощным языком, применимым для решения большого количества разнообразных задач. В январе 1997 года он был представлен Группе по управлению объектами (Object Management Group, OMG) на конкурс по созданию стандартного языка моделирования.
Между январем и июнем 1997 года консорциум UML расширился, в него вошли практически все компании, откликнувшиеся на призыв OMG, а именно: Andersen Consulting, Ericsson, ObjecTime Limited, Platinum Technology, Ptech, Reich Technologies, Softeam, Sterling Software и Taskon. Чтобы формализовать спецификации UML и координировать работу с другими группами, занимающимися стандартизацией, под руководством Криса Кобрина (Cris Kobryn) из компании MCI Systemhouse и Эда Эйкхолта (Ed Eykholt) из Rational была организована семантическая группа. Пересмотренная версия UML (1.1) была снова представлена на рассмотрение OMG в июле 1997 года. В сентябре версия была утверждена на заседаниях Группы по анализу и проектированию и Комитета по архитектуре OMG, a 14 ноября 1997 года принята в качестве стандарта на общем собрании всех членов OMG.
Дальнейшая работа по развитию UML проводилась Группой по усовершенствованию (Revision Task Force, RTF) OMG под руководством Криса Кобрина. В июне 1998 года вышла версия UML 1.2, а осенью 1998 – UML 1.3.
Язык моделирования UML
UML (унифицированный язык моделирования) – язык графического описания для объектного моделирования в области разработки программного обеспечения. Он использует графические обозначения для создания модели системы. Данный язык был создан для определения, визуализации, проектирования и документирования программных систем, а также его используют для моделирования бизнес-процессов, системного проектирования.
Описание унифицированного языка моделирования UML
Краткая история UML (Создатели: Грейди Буч , Айвар Джекобсон и Джеймс Рамбо )
Концептуальная модель UML (концептуальную модель включает: основные строительные блоки языка; правила их сочетания; некоторые общие для всего языка механизмы)
Виды диаграмм для моделирования:
Диаграммы вариантов использования (они описывают функциональное назначение системы или то, что система должна делать)
Диаграммы классов (используются для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования; такие диаграммы могут отражать различные взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывать их внутреннюю структуру и типы отношений)
Диаграммы взаимодействия (описывают взаимодействие между объектами в системе и подразделяются на два основных типа диаграмм: диаграммы последовательности и кооперативные диаграммы)
Диаграммы состояний (используется для описания всех возможных состояний одного экземпляра определенного класса и возможные последовательности его переходов из одного состояния в другое, то есть моделирует все изменения состояний объекта как его реакцию на внешние воздействия)
Диаграммы деятельности (применяется для моделирования процесса выполнения операций)
Диаграммы реализации (служат для представления компонентов системы и относятся к ее физической модели)
Диаграммы компонентов (описывает особенности физического представления системы и позволяет определить архитектуру разрабатываемой системы, установив зависимости между программными компонентами, в роли которых может выступать исходный и исполняемый код)
Диаграммы размещения (отражают физические взаимосвязи между программными и аппаратными компонентами системы, а также используются для изображения маршрутов перемещения объектов в распределенной системе)
Все диаграммы UML можно условно разбить на две группы, первая из которых ‒ общие диаграммы. Общие диаграммы практически не зависят от предмета моделирования и могут применяться в любом программном проекте без оглядки на предметную область, область решений и т.д.
1.5.1. Диаграмма использования
Диаграмма использования (use case diagram) ‒ это наиболее общее представление функционального назначения системы.
Диаграмма использования призвана ответить на главный вопрос моделирования: что делает система во внешнем мире?
На диаграмме использования применяются два типа основных сущностей: варианты использования 1 и действующие лица 2 , между которыми устанавливаются следующие основные типы отношений:
- ассоциация между действующим лицом и вариантом использования 3 ;
- обобщение между действующими лицами 4 ;
- обобщение между вариантами использования 5 ;
- зависимости (различных типов) между вариантами использования 6 .
На диаграмме использования, как и на любой другой, могут присутствовать комментарии 7 . Более того, это настоятельно рекомендуется делать для улучшения читаемости диаграмм.
Основные элементы нотации, применяемые на диаграмме использования, показаны ниже. Детальное описание приведено в разделе 2.2 .
1.5.2. Диаграмма классов
Диаграмма классов (class diagram) ‒ основной способ описания структуры системы.
Это не удивительно, поскольку UML в первую очередь объектно-ориентированный язык, и классы являются основным (если не единственным) "строительным материалом".
На диаграмме классов применяется один основной тип сущностей: классы 1 (включая многочисленные частные случаи классов: интерфейсы, примитивные типы, классы-ассоциации и многие другие), между которыми устанавливаются следующие основные типы отношений:
- ассоциация между классами 2 (с множеством дополнительных подробностей);
- обобщение между классами 3 ;
- зависимости (различных типов) между классами 4 и между классами и интерфейсами.
Некоторые элементы нотации, применяемые на диаграмме классов, показаны ниже. Детальное описание приведено в главе 3 .
1.5.3. Диаграмма автомата
Диаграмма автомата (state machine diagram) ‒ это один из способов детального описания поведения в UML на основе явного выделения состояний и описания переходов между состояниями.
В сущности, диаграммы автомата, как это следует из названия, представляют собой граф переходов состояний (см. главу 4), нагруженный множеством дополнительных деталей и подробностей.
На диаграмме автомата применяют один основной тип сущностей ‒ состояния 1 , и один тип отношений ‒ переходы 2 , но и для тех и для других определено множество разновидностей, специальных случаев и дополнительных обозначений. Перечислять их все во вступительном обзоре не имеет смысла.
Детальное описание всех вариаций диаграмм автомата приведено в разделе 4.2 , а на следующем рисунке показаны только основные элементы нотации, применяемые на диаграмме автомата.
1.5.4. Диаграмма деятельности
Диаграмма деятельности (activity diagram) ‒ способ описания поведения на основе указания потоков управления и потоков данных.
Диаграмма деятельности ‒ еще один способ описания поведения, который визуально напоминает старую добрую блок-схему алгоритма. Однако за счет модернизированных обозначений, согласованных с объектно-ориентированным подходом, а главное, за счет новой семантической составляющей (свободная интерпретация сетей Петри), диаграмма деятельности UML является мощным средством для описания поведения системы.
На диаграмме деятельности применяют один основной тип сущностей ‒ действие 1 , и один тип отношений ‒ переходы 2 (передачи управления и данных). Также используются такие конструкции как развилки, слияния, соединения, ветвления 3 , которые похожи на сущности, но таковыми на самом деле не являются, а представляют собой графический способ изображения некоторых частных случаев многоместных отношений. Семантика элементов диаграмм деятельности подробно разобрана в главе 4 . Основные элементы нотации, применяемые на диаграмме деятельности, показаны ниже.
1.5.5. Диаграмма последовательности
Диаграмма последовательности (sequence diagram) ‒ это способ описания поведения системы на основе указания последовательности передаваемых сообщений.
Фактически, диаграмма последовательности ‒ это запись протокола конкретного сеанса работы системы (или фрагмента такого протокола). В объектно-ориентированном программировании самым существенным во время выполнения является пересылка сообщений между взаимодействующими объектами. Именно последовательность посылок сообщений отображается на данной диаграмме, отсюда и название.
На диаграмме последовательности применяют один основной тип сущностей ‒ экземпляры взаимодействующих классификаторов 1 (в основном классов, компонентов и действующих лиц), и один тип отношений ‒ связи 2 , по которым происходит обмен сообщениями 3 . Предусмотрено несколько способов посылки сообщений, которые в графической нотации различаются видом стрелки, соответствующей отношению.
Важным аспектом диаграммы последовательности является явное отображение течения времени. В отличие от других типов диаграмм, кроме разве что диаграмм синхронизации, на диаграмме последовательности имеет значение не только наличие графических связей между элементами, но и взаимное расположение элементов на диаграмме. А именно, считается, что имеется (невидимая) ось времени, по умолчанию направленная сверху вниз, и то сообщение, которое отправлено позже, нарисовано ниже.
Ось времени может быть направлена горизонтально, в этом случае считается, что время течет слева направо.
На следующем рисунке показаны основные элементы нотации, применяемые на диаграмме последовательности. Для обозначения самих взаимодействующих объектов применяется стандартная нотация ‒ прямоугольник с именем экземпляра классификатора. Пунктирная линия, выходящая из него, называется линией жизни (lifeline) 4 . Это не обозначение отношения в модели, а графический комментарий, призванный направить взгляд читателя диаграммы в правильном направлении. Фигуры в виде узких полосок, наложенных на линию жизни, также не являются изображениями моделируемых сущностей. Это графический комментарий, показывающий отрезки времени, в течении которых объект владеет потоком управления (execution occurrence) 5 или другими словами имеет место активация (activation) объекта. Составные шаги взаимодействия(combined fragment) 6 позволяют на диаграмме последовательности, отражать и алгоритмические аспекты протокола взаимодействия. Прочие детали нотации диаграммы последовательностей см. в главе 4 .
1.5.6. Диаграмма коммуникации
Диаграмма коммуникации (communication diagram) ‒ способ описания поведения, семантически эквивалентный диаграмме последовательности.
Фактически, это такое же описание последовательности обмена сообщениями взаимодействующих экземпляров классификаторов, только выраженное другими графическими средствами. Более того, большинство инструментов умеет автоматически преобразовывать диаграммы последовательности в диаграммы коммуникации и обратно.
Таким образом, на диаграмме коммуникации также как и на диаграмме последовательности применяют один основной тип сущностей ‒ экземпляры взаимодействующих классификаторов 1 и один тип отношений ‒ связи 2 . Однако здесь акцент делается не на времени, а на структуре связей между конкретными экземплярами.
На рисунке показаны основные элементы нотации, применяемые на диаграмме коммуникации. Для обозначения самих взаимодействующих объектов применяется стандартная нотация ‒ прямоугольник с именем экземпляра классификатора. Взаимное положение элементов на диаграмме кооперации не имеет значения ‒ важны только связи (чаще всего экземпляры ассоциаций), вдоль которых передаются сообщения 3 . Для отображения упорядоченности сообщений во времени применяется иерархическая десятичная нумерация.
1.5.7. Диаграмма компонентов
Диаграмма компонентов (component diagram) ‒ показывает взаимосвязи между модулями (логическими или физическими), из которых состоит моделируемая система.
Основной тип сущностей на диаграмме компонентов ‒ это сами компоненты 1 , а также интерфейсы 2 , посредством которых указывается взаимосвязь между компонентами. На диаграмме компонентов применяются следующие отношения:
- реализации между компонентами и интерфейсами (компонент реализует интерфейс);
- зависимости между компонентами и интерфейсами (компонент использует интерфейс) 3 .
На рисунке показаны основные элементы нотации, применяемые на диаграмме компонентов. Детальное описание приведено в главе 3 .
1.5.8. Диаграмма размещения
Диаграмма размещения (deployment diagram) наряду с отображением состава и связей элементов системы показывает, как они физически размещены на вычислительных ресурсах во время выполнения.
Таким образом, на диаграмме размещения, по сравнению с диаграммой компонентов, добавляется два типа сущностей: артефакт 1 , который является реализацией компонента 2 и узел 3 (может быть как классификатор, описывающий тип узла, так и конкретный экземпляр), а также отношение ассоциации между узлами 4 , показывающее, что узлы физически связаны во время выполнения.
На рисунке показаны основные элементы нотации, применяемые на диаграмме размещения. Для того чтобы показать, что одна сущность является частью другой, применяется либо отношение зависимости «deploy» 5 , либо фигура одной сущности помещается внутрь фигуры другой сущности 6 . Детальное описание диаграммы приведено в главе 3 .
Методология UML (англ. Unified Modeling Language - унифицированный язык моделирования) - язык графического описания для объектного моделирования в области разработки программного обеспечения. UML является языком широкого профиля, это открытый стандарт, использующий графические обозначения для создания абстрактной моделисистемы, называемой UML-моделью. UML был создан для определения, визуализации, проектирования и документирования в основном программных систем. UML не является языком программирования, но в средствах выполнения UML-моделей как интерпретируемого кода возможна кодогенерация. Использование UML не ограничивается моделированием программного обеспечения. Его также используют для моделирования бизнес-процессов, системного проектированияи отображения организационных структур.
Использование UML позволяет также разработчикам программного обеспечения достигнуть соглашения в графических обозначениях для представления общих понятий (таких как класс, компонент, обобщение (generalization), объединение (aggregation) и поведение), и больше сконцентрироваться на проектировании и архитектуре.
Диаграммы В UML используются следующие виды диаграмм (для исключения неоднозначности приведены также обозначения на английском языке):
Диаграмма классов (Class diagram) - статическая структурная диаграмма, описывающая структуру системы, она демонстрирует классы системы, их атрибуты, методы и зависимости между классами. Существуют разные точки зрения на построение диаграмм классов в зависимости от целей их применения: концептуальная точка зрения - диаграмма классов описывает модель предметной области, в ней присутствуют только классы прикладных объектов; точка зрения спецификации - диаграмма классов применяется при проектировании информационных систем; точка зрения реализации - диаграмма классов содержит классы, используемые непосредственно в программном коде (при использовании объектно-ориентированных языков программирования).
Диаграмма компонентов (Component diagram) - статическая структурная диаграмма, показывает разбиение программной системы на структурные компоненты и связи (зависимости) между компонентами. В качестве физических компонент могут выступать файлы, библиотеки, модули, исполняемые файлы, пакеты и т. п.
Диаграмма композитной/составной структуры (Composite structure diagram) - статическая структурная диаграмма, демонстрирует внутреннюю структуру классов и, по возможности, взаимодействие элементов (частей) внутренней структуры класса. Подвидом диаграмм композитной структуры являются диаграммы кооперации (Collaboration diagram, введены в UML 2.0), которые показывают роли и взаимодействие классов в рамках кооперации. Кооперации удобны при моделировании шаблонов проектирования. Диаграммы композитной структуры могут использоваться совместно с диаграммами классов.
Диаграмма развёртывания (Deployment diagram) - служит для моделирования работающих узлов (аппаратных средств, англ. node) иартефактов, развёрнутых на них. В UML 2 на узлах разворачиваются артефакты (англ. artifact), в то время как в UML 1 на узлах разворачивались компоненты. Между артефактом и логическим элементом (компонентом), который он реализует, устанавливается зависимость манифестации.
Диаграмма объектов (Object diagram) - демонстрирует полный или частичный снимок моделируемой системы в заданный момент времени. На диаграмме объектов отображаются экземпляры классов (объекты) системы с указанием текущих значений их атрибутов и связей между объектами.
Диаграмма пакетов (Package diagram) - структурная диаграмма, основным содержанием которой являются пакеты и отношения между ними. Жёсткого разделения между разными структурными диаграммами не проводится, поэтому данное название предлагается исключительно для удобства и не имеет семантического значения (пакеты и диаграммы пакетов могут присутствовать на других структурных диаграммах). Диаграммы пакетов служат, в первую очередь, для организации элементов в группы по какому-либо признаку с целью упрощения структуры и организации работы с моделью системы.
Диаграмма деятельности (Activity diagram) - диаграмма, на которой показано разложение некоторой деятельности на её составные части. Под деятельностью (англ. activity) понимается спецификация исполняемого поведения в виде координированного последовательного и параллельного выполнения подчинённых элементов - вложенных видов деятельности и отдельных действий (англ. action), соединённых между собой потоками, которые идут от выходов одного узла к входам другого. Диаграммы деятельности используются при моделировании бизнес-процессов, технологических процессов, последовательных и параллельных вычислений. Аналогом диаграмм деятельности являются схемы алгоритмов по ГОСТ 19.701-90.
Диаграмма автомата (State Machine diagram, диаграмма конечного автомата, диаграмма состояний) - диаграмма, на которой представлен конечный автомат с простыми состояниями, переходами и композитными состояниями. Конечный автомат (англ. State machine) - спецификация последовательности состояний, через которые проходит объект или взаимодействие в ответ на события своей жизни, а также ответные действия объекта на эти события. Конечный автомат прикреплён к исходному элементу (классу, кооперации или методу) и служит для определения поведения его экземпляров.
Диаграмма вариантов использования (Use case diagram) - диаграмма, на которой отражены отношения, существующие между акторами и вариантами использования. Основная задача - представлять собой единое средство, дающее возможность заказчику, конечному пользователю и разработчику совместно обсуждать функциональность и поведение системы.
Диаграммы коммуникации и последовательности транзитивны, выражают взаимодействие, но показывают его различными способами и с достаточной степенью точности могут быть преобразованы одна в другую. Диаграмма коммуникации (Communication diagram, в UML 1.x - диаграмма кооперации, collaboration diagram) - диаграмма, на которой изображаются взаимодействия между частями композитной структуры или ролями кооперации. В отличие от диаграммы последовательности, на диаграмме коммуникации явно указываются отношения между элементами (объектами), а время как отдельное измерение не используется (применяются порядковые номера вызовов). Диаграмма последовательности (Sequence diagram) - диаграмма, на которой изображено упорядоченное во времени взаимодействие объектов. В частности, на ней изображаются участвующие во взаимодействии объекты и последовательность сообщений, которыми они обмениваются. Диаграмма сотрудничества - Этот тип диаграмм позволяет описать взаимодействия объектов, абстрагируясь от последовательности передачи сообщений. На этом типе диаграмм в компактном виде отражаются все принимаемые и передаваемые сообщения конкретного объекта и типы этих сообщений. По причине того, что диаграммы Sequence и Collaboration являются разными взглядами на одни и те же процессы, Rational Rose позволяет создавать из Sequence диаграммы диаграмму Collaboration и наоборот, а также производит автоматическую синхронизацию этих диаграмм.
Диаграмма обзора взаимодействия (Interaction overview diagram) - разновидность диаграммы деятельности, включающая фрагменты диаграммы последовательности и конструкции потока управления. Этот тип диаграмм включает в себя диаграммы Sequence diagram (диаграммы последовательностей действий) и Collaboration diagram (диаграммы сотрудничества). Эти диаграммы позволяют с разных точек зрения рассмотреть взаимодействие объектов в создаваемой системе.
Диаграмма синхронизации (Timing diagram) - альтернативное представление диаграммы последовательности, явным образом показывающее изменения состояния на линии жизни с заданной шкалой времени. Может быть полезна в приложениях реального времени.
Помимо прочего, язык UML применяется для проектирования реляционных БД. Для этого используется небольшая часть языка (диаграммы классов), да и то не в полном объеме. С точки зрения проектирования реляционных БД модельные возможности не слишком отличаются от возможностей ER-диаграмм
Диаграммой классов в терминологии UML называется диаграмма, на которой показан набор классов (и некоторых других сущностей), не имеющих явного отношения к проектированию БД), а также связей между этими классами. Ограничения могут неформально задаваться на естественном языке или формулироваться на языке объектных ограничений OCL (Object Constraints Language).
Классом называется именованное описание совокупности объектов с общими атрибутами, операциями, связями и семантикой. Графически класс изображается в виде прямоугольника. Имя (текстовая строка), служит для идентификации класса.
Атрибутом класса называется именованное свойство класса, описывающее множество значений, которые могут принимать экземпляры этого свойства. Класс может иметь любое число атрибутов (в частности, не иметь ни одного атрибута).
Операцией класса называется именованная услуга, которую можно запросить у любого объекта этого класса. Операция - это абстракция того, что можно делать с объектом. Класс может содержать любое число операций (в частности, не содержать ни одной операции). Набор операций класса является общим для всех объектов данного класса.
В диаграмме классов могут участвовать связи трех разных категорий: зависимость (dependency), обобщение (generalization) и ассоциация (association).
Зависимостью называют связь по применению, когда изменение в спецификации одного класса может повлиять на поведение другого класса, использующего первый класс. Если интерфейс второго класса изменяется, это влияет на поведение объектов первого класса. Зависимость показывается прерывистой линией со стрелкой, направленной к классу, от которого имеется зависимость.
Связью-обобщением называется связь между общей сущностью, называемой суперклассом, или родителем, и более специализированной разновидностью этой сущности, называемой подклассом, или потомком. Обобщения иногда называют связями "is a", имея в виду, что класс-потомок является частным случаем класса-предка. Класс-потомок наследует все атрибуты и операции класса-предка, но в нем могут быть определены дополнительные атрибуты и операции.
Похожая информация.
Loading...