Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
PAGE 4
ГБОУ СПО СО
Баранчинский электромеханический техникум
Специальность: Прикладная информатика
Реферат по курсу: Разработка и внедрения программного обеспечения
На тему: IDEF0, Язык UML, ER – диаграмма(erlang).
Выполнил: Студент второго курса,
ГОУ СПО СО БЭМТ
Специальность ‘’Прикладная информатика ‘’
Абдураимов Данил Валерьевич
пос. Баранчинский
2012г.
Оглавление:
Введение:
Моделирование — исследование объектов познания на их моделях; построение и изучение моделей реально существующих объектов, процессов или явлений с целью получения объяснений этих явлений, а также для предсказания явлений, интересующих исследователя.
Процесс моделирования включает три элемента:
субъект (исследователь),
объект исследования,
модель, определяющую (отражающую) отношения познающего субъекта и познаваемого объекта.
Первый этап построения модели предполагает наличие некоторых знаний об объекте-оригинале. Познавательные возможности модели обусловливаются тем, что модель отображает (воспроизводит, имитирует) какие-либо существенные черты объекта-оригинала. Вопрос о необходимой и достаточной мере сходства оригинала и модели требует конкретного анализа. Очевидно, модель утрачивает свой смысл как в случае тождества с оригиналом (тогда она перестает быть моделью), так и в случае чрезмерного во всех существенных отношениях отличия от оригинала. Таким образом, изучение одних сторон моделируемого объекта осуществляется ценой отказа от исследования других сторон. Поэтому любая модель замещает оригинал лишь в строго ограниченном смысле. Из этого следует, что для одного объекта может быть построено несколько «специализированных» моделей, концентрирующих внимание на определенных сторонах исследуемого объекта или же характеризующих объект с разной степенью детализации.
На втором этапе модель выступает как самостоятельный объект исследования. Одной из форм такого исследования является проведение «модельных» экспериментов, при которых сознательно изменяются условия функционирования модели и систематизируются данные о её «поведении». Конечным результатом этого этапа является множество (совокупность) знаний о модели.
На третьем этапе осуществляется перенос знаний с модели на оригинал — формирование множества знаний. Одновременно происходит переход с «языка» модели на «язык» оригинала. Процесс переноса знаний проводится по определенным правилам. Знания о модели должны быть скорректированы с учетом тех свойств объекта-оригинала, которые не нашли отражения или были изменены при построении модели.
Четвёртый этап — практическая проверка получаемых с помощью моделей знаний и их использование для построения обобщающей теории объекта, его преобразования или управления им.
Моделирование — циклический процесс. Это означает, что за первым четырёхэтапным циклом может последовать второй, третий и т. д. При этом знания об исследуемом объекте расширяются и уточняются, а исходная модель постепенно совершенствуется. Недостатки, обнаруженные после первого цикла моделирования, обусловленные малым знанием объекта или ошибками в построении модели, можно исправить в последующих циклах.
Сейчас трудно указать область человеческой деятельности, где не применялось бы моделирование. Разработаны, например, модели производства автомобилей, выращивания пшеницы, функционирования отдельных органов человека, жизнедеятельности Азовского моря, последствий атомной войны. В перспективе для каждой системы могут быть созданы свои модели, перед реализацией каждого технического или организационного проекта должно проводиться моделирование.
Для полного описания системы требуется набор IDEF0-диаграмм, образующих IDEF0-модель.
Каждая модель должна иметь контекстную диаграмму верхнего уровня, на которой объект описания представлен одиночным блоком, окруженным дугами. Дуги на этой диаграмме связывают объект описания с окружающей средой (внешними объектами). Контекстная диаграмма устанавливает область или границы моделирования. Так как контекстная диаграмма представляет весь объект, то ее блок должен иметь самое общее имя. То же относится и к именам интерфейсных дуг. На контекстной диаграмме должны быть указаны точка зрения модели и цель ее создания.
Наиболее важные особенности системы представлены в иерархии, поскольку функция верхнего уровня декомпозируется на подфункции.
Разделение объекта на его структурные части (блоки и дуги, составляющие диаграмму) называется декомпозицией.
Подфункции, в свою очередь, декомпозируются далее, пока не будут показаны все детали, важные с данной точки зрения. Каждая подфункция изображается отдельным блоком, который является дочерней детализацией родительского блока на следующем (более низком) уровне. Области описания дочерними диаграммами не должны выходить за пределы описания контекстной диаграммы верхнего уровня.
Узловые номера используются для того, чтобы указать положение диаграммы в иерархии модели. Например, диаграмма с узловым номером А21 детализирует блок 1 на диаграмме А2. Подобным же образом, А2 детализирует блок 2 на диаграмме АО, которая является самой полной диаграммой модели.
Все узловые номера графических диаграмм начинаются с буквы "A". Исходная для данной модели контекстная диаграмма имеет узловой номер А-0. Если создается более укрупненная контекстная диаграмма, в которую описываемая система входит в качестве подсистемы, то она нумеруется как А-1. Этот процесс может, если необходимо, продолжаться вверх по иерархии и дальше, однако А-0 остается вершиной конкретной модели.
Для дополнений к графическим диаграммам используются другие узловые номера. Номера для текстовых диаграмм содержат букву "Т" и соответствуют узловому номеру диаграммы, с которой они связаны (например, А2Т текстовая диаграмма для графической диаграммы А2). Узловые номера для глоссария содержат букву "G" (например, A1G). Узловые номера FEO-диаграмм содержат букву "F" (например, A2F).
IDEF0 требует, чтобы все внешние дуги диаграммы были согласованы по числу и наименованию (но не обязательно по расположению) с дугами, касающимися декомпозированного блока родительской диаграммы. Для этих целей принята система обозначений. Схема кодирования дуг ICOM (от слов: Input, Control, Output, Mechanism) позволяет точно идентифицировать и проверить связи по дугам между диаграммами.
Код дуги состоит из буквы и цифры. Для входных дуг рекомендуется использовать букву I, для связей между дугами управления С, для связей между выходными дугами О, для связей между дугами механизма М. После каждой буквы добавляется цифра, соответствующая положению данной дуги среди других дуг того же типа, касающихся родительского блока. Причем входные и выходные дуги пересчитываются сверху вниз, а дуги управления и механизмов слева направо.
В IDEF0 кроме обычных дуг, имеются так называемые дуги, "помещенные в тоннель". Потенциально все дуги на диаграмме, независимо от их содержания, могут быть "помещены в тоннель", что является способом скрытия их источника или приемника. Начало проходящих через тоннель дуг появляется из неизвестного источника, заключенного в скобки, что указывает на появление этих дуг из некоторой другой части модели или непосредственно извне. Конец входящих в тоннель дуг с неизвестным приемником заключается в скобки для указания на то, что эти дуги либо идут в другую часть модели, либо непосредственно выходят из модели, либо более не рассматриваются. "Тоннельные" обозначения используются для того, чтобы избежать хаотичного заполнения нежелательными подробностями диаграмм высокого уровня. Кроме того, "тоннельные" обозначения помогают скрывать сведения, необходимые только для верхних уровней модели. Это минимизирует вероятность загромождения диаграмм-декомпозиций необязательной информацией. Дуги с заключенными в скобки концами выполняют эти задачи, поскольку они не рассматриваются как часть границы при касании ими блока и, следовательно, не переносятся на диаграмму, декомпозирующую этот блок.
Дуги могут быть пропущены на одном или нескольких уровнях диаграмм, а затем появиться на другом уровне в одном или нескольких местах.
В процессе создания IDEF0-модели одну и ту же диаграмму приходится перечерчивать несколько раз. Для различения полученных вариантов одной и той же диаграммы в IDEF0 используется схема идентификации версий, основанная на так называемых С-номерах. С-номер образуется из инициалов автора и номера. Если диаграмма является новой версией имеющейся диаграммы, то указывается очередной С-номер, а предыдущий пишется в скобках.
Пример. Сообщение о том, что третий вариант автор с инициалами КВВ заменяет шестым, будет записано в виде С-номера в правом нижнем углу диаграммы: КВВ006 (КВВ00З).
Для ведения системы С-номеров создается так называемый реестр, в котором приводится последовательный список С-номеров (начиная с номера 000) и соответствующие им имена диаграмм.
Диаграмма является основным рабочим элементом при создании моделей. Разработчик диаграмм и моделей обычно называется аналитиком, или, в терминологии IDEFO, автором. Каждой IDEFO-диаграмме дается название. Название, а также стандартно идентифицирующая информация (автор диаграммы, частью какого проекта является работа, дата создания или последнего пересмотра диаграммы, ее статус) располагаются на специальном бланке. Диаграммы следует оформлять с учетом следующих синтаксических правил:
Контекстные диаграммы должны иметь номер узла вида А-п, где п больше или равен нулю.
Модель должна включать контекстную диаграмму А-0, содержащую только один блок, имеющий номер 0.
Неконтекстная диаграмма должна иметь не менее трех (но не более шести) блоков.
Каждый блок на неконтекстной диаграмме следует пронумеровать внутри в нижнем правом углу (от 1 до 6)
Каждый блок, который был детализирован, должен иметь подробное ссылочное выражение (например, номер узла или страницы, С-номер) его дочерней (порожденной) диаграммы, написанной ниже правого угла блока.
Каждый блок должен иметь как минимум одну дугу управления и одну дугу вывода. Дуги управления накладывают ограничения и включают или выключают функции системы. Без них система не может работать.
Блок должен иметь ноль или большее количество входных дуг.
Блок должен иметь ноль или большее количество дуг механизма (не ссылочных).
Блок должен иметь ноль или одну дугу ссылки.
Если данные служат и для управления, и для входа, следует вычертить только дугу управления, что способствует уменьшению степени сложности общей картины и делает очевидным управляющий характер данных.
Рекомендуется максимально увеличить расстояние между параллельными дугами, оставляя больше места для меток. Это помогает зрительно определять количество дуг и прослеживать их пути.
Следует максимально увеличить расстояние между блоками и поворотами дуг, а также между блоками и пересечениями дуг, чтобы облегчить процесс чтения и не перепутать две разные дуги.
Необходимо объединять дуги, источники которых не указаны на диаграмме, если они представляют одни и те же данные. Этим вы графически покажете единый источник сходных данных
Нужно рисовать циклические обратные связи для одного и того же блока только с целью их выделения. Обычно обратную связь изображают на диаграмме, декомпозирующей блок. Однако иногда требуется выделить буферы и повторно используемые объекты.
Рекомендуется объединять дуги с общими источником или приемником, если они представляют связанные данные. Общее название лучше описывает суть данных
Необходимо минимизировать число дуг, касающихся каждой стороны блока, если, конечно, природа данных не слишком разнородна.
Следует минимизировать число петель и поворотов каждой дуги
Обратные связи по управлению рекомендуется рисовать "вверх и над". Таким образом вы покажете ограничивающие обратные связи при минимальном числе линий и пересечений, а также соберете все дуги управления в верхней правой части диаграммы
Обратные связи по входу следует рисовать "вниз и под". Это позволит показать обратные потоки данных при минимальном числе линий и пересечений, а также собрать все входные дуги в нижней левой части диаграммы
При соединении большого числа блоков необходимо избегать необязательных пересечений дуг.
Несвязанный конец граничной дуги должен или иметь надлежащий ICOM-код, определяющий его подключение к родительскому блоку, или быть дугой, "помещенной в туннель".
Открытые граничные дуги, которые представляют одни и те же данные (объекты), должны быть связаны через ветвление. Множественные источники, которые представляют одни и те же данные (объекты), должны объединиться, чтобы формировать единую дугу вывода.
Названия блока и метки дуг не должны состоять исключительно из следующих слов: "Функция", "Действие", "Процесс", "Ввод", "Вывод", "Управляет" или "Механизм". Желательно эти слова не использовать в названиях или метках дуг.
Длинную дугу следует помечать дважды.
Как говорилось ранее, основными диаграммами IDEF0-модели являются графические. Для уточнения они могут быть дополнены информацией в виде текстов, глоссариев и рисунков. Поскольку дополнительная информация формально не является частью модели, рекомендуется помещать такие материалы на отдельных страницах. Дополнительные диаграммы записываются или представляются на стандартных IDEF0-бланках с использованием принятой нумерации узлов.
Текстовые диаграммы пишут обычно для того, чтобы изложить основное содержание графической диаграммы и описать, как функции самого нижнего уровня модели преобразуют свои входы в выходы под влиянием управлений.
Текст рекомендуется писать, когда диаграмма перестает подвергаться изменениям. Хороший текст должен быть кратким. Несколько тщательно подобранных слов могут прояснить диаграмму, в то время как избыточное их количество может совершенно затуманить ее смысл. Обычно все, что нужно для пояснения диаграммы, можно изложить на одной странице текста. Превышение одной страницы снижает качество за счет лишних деталей.
Текст может быть использован для сообщения о том, почему выбрана именно эта декомпозиция или точка зрения, как осуществляются сложные операции, а также для описания допущений, сделанных автором при создании диаграммы. Однако ни при каких обстоятельствах текст не должен описывать то, что можно прочесть на диаграмме, уточнять уже декомпозированный блок, идентифицировать компоненты декомпозированной дуги, описывать функции блоков или определять названия блоков и дуг (эти названия содержатся на странице глоссария).
Глоссарий набор определений объектов (данных) и функций, представленных на диаграмме.
Глоссарий определяет слова в модели для правильной интерпретации ее содержания. Он используется для того, чтобы собрать вместе и определить новые понятия (аббревиатуры, сокращения, ключевые слова и фразы), которые вводятся диаграммой, декомпозирующей блок, особенно если это первая декомпозиция родительского блока. Эти определения важны, потому что терминология, используемая в модели, может иметь различное значение в разных организациях и учреждениях. Более того, терминология часто отличается среди подразделений или дисциплин в пределах одной и той же организации.
Поясняющие диаграммы FEO в виде рисунков применяемые с целью дополнительных пояснений к модели.
Для описания обычно используются текстовые диаграммы. Но для пояснения тонких моментов и в тех случаях, когда содержание трудно выразить словами, желательно использовать, где это возможно, рисунки. В IDEF0-модели любое изображение, которое не является строго диаграммой, считается дополнительным рисунком. IDEF0-рисунки это обычно либо картинки, либо диаграммы с дополнительными изображениями, связанные с конкретной диаграммой модели.
IDEF0-модель представляет собой согласованный и упорядоченный комплект документов, что обеспечивается организацией диаграмм в соответствии с порядком нумерации узлов: первый узел А-0, второй А0, третий А1, четвертый All и т.д. Полная IDEF0-модель обычно читается двумя способами:
обзорное чтение, когда читаются все диаграммы верхнего уровня, прежде чем перейти к диаграммам следующего. Это называется чтением "в ширину";
детальное чтение, когда читают отдельную ветвь дерева вплоть до диаграмм самого нижнего уровня. Это называется чтением "в глубину".
Чтобы помочь читателям правильно двигаться по древовидному набору диаграмм, разработаны дополнительные средства, в частности, указатели диаграмм и узлов. Они представляют собой списки узлов или диаграмм (по типу оглавления), определяющих содержание модели. В указателе диаграмм перечисляются все диаграммы модели, приводятся в отдельной строке название и номер узла каждой диаграммы. Указатель узлов содержит перечень всех блоков модели, причем в каждой отдельной строке записываются название и номер узла соответствующего блока. Соответствующая диаграмма имеет узловой номер с буквой "N", например, AON.
Процесс моделирования в IDEF0 включает в себя:
сбор информации об исследуемом объекте;
документирование полученной информации и представление ее в виде модели;
уточнение модели посредством итеративного рецензирования.
Сбор информации об исследуемом объекте
Сбор и изучение информации должны проводиться на всех этапах исследования объекта.
Можно назвать следующие способы получения сведений об изучаемой системе:
чтение документации;
наблюдение за работой системы; н
опрос с помощью анкет большой группы специалистов;
беседа с экспертами, обладающими соответствующим опытом и необходимыми сведениями о системе;
использование той информации, которой уже владеет автор;
построение гипотетического описания с последующим обращением к экспертам с просьбой помочь приблизить полученное описание к действительности.
Анкетирование является начальным этапом обследования. Анкеты позволяют составить поверхностное представление о деятельности предприятия, что помогает спланировать первоначальное распределение работ группы аналитиков.
Анкеты рассылаются руководителям структурных подразделений и должны содержать графы для фамилии и должности анкетируемого. Отдельно излагается просьба приложить шаблоны документов, с которыми работают сотрудники соответствующего подразделения. Список вопросов необходимо ограничить (не более 15 - 20), а вся анкета не должна занимать более двух листов.
Пример анкеты.
Наименование подразделения.
ФИО руководителя подразделения, номер его телефона.
Координаты контактного лица (к кому в отсутствие или при занятости руководителя можно обращаться).
Основные функции подразделения.
Информация, поступающая из других подразделений (заявки, запросы, отчеты и т.п.).
Информация, передаваемая в другие подразделения.
Какая информация формируется ("рождается") в подразделении?
С какими внешними предприятиями (банк, заказчик, поставщик и т.п.) взаимодействует подразделение и какой информацией обменивается?
Физическое представление информационных потоков и хранилищ (документ, дискета, сеть, журнал, картотека и т.п.).
Документы, поступающие от руководства, готовящиеся для руководства.
Штатная структура и квалификация кадров.
Техническое оснащение подразделения (компьютеры, сеть, модем)
Подпись.
Просьба приложить:
Положение о подразделении.
Набор документальных форм (можно незаполненных), т.е. используемые формы, бланки и другие документы (например, карточка складского учета, отчет по форме N, наряд-задание, товарно-транспортная накладная).
Из всех путей сбора информации наиболее важный общение с экспертом, поскольку редко бывает так, чтобы вся необходимая информация была где-либо написана, а данные из анкет часто носят субъективный характер.
Интервью это беседа с каким-либо лицом с целью сбора информации по рассматриваемому вопросу.
Интервьюирование является важнейшим и необходимым методом исследования, только с его помощью возможно разобраться во всех тонкостях применяемых на предприятии технологий. Современное предприятие, даже небольшого размера, является сложной системой. Конечно, руководство представляет ситуацию в целом, отдельные работники досконально знают свою деятельность, но полной картины протекания всех бизнес-процессов не имеет никто. Поэтому интервьюирование представителей всех звеньев оргштатной структуры позволяет понять и формализовать исследуемую систему.
(Unified Modeling Language — унифицированный язык моделирования)
Язык UML имеет сложную иерархическую структуру, показанную на рис .
Как следует из рисунка, первый иерархический уровень языка UML составляют сущности, отношения между сущностями и наглядные диаграммы. Далее на следующем уровне показано, что понятие "структурные сущности" является именем семи видов пиктограмм (выразительных рисунков). Поведенческие сущности делятся на два вида диаграмм. Группирующие и аннотационные сущности имеют один вид пиктограмм, называемых примечаниями.
На рис 3.3 в качестве примеров показаны пять видов пиктограмм – класс, актер, прецедент, пакет и примечание.
Класс изображается прямоугольником, разделенным на три поля. В первом поле помещается имя класса, однозначно определяющее данный класс среди множества других классов. Во втором поле помещаются атрибуты (общие свойства) класса. В третьем поле располагаются типовые операции, выполняемые объектами, принадлежащими данному классу. На рис 3.3 показаны пиктограммы, изображающие класс "окно" и класс "экранный кадр".
Левая пиктограмма на рис 3.4 показывает класс с именем "окно" и основные свойства (характеристики) присущие объектам этого класса. Правая пиктограмма показывает класс "кадр (frame)"с его основными характеристиками и подробными характеристиками, детализирующими основные характеристики. Детальная нотация класса дает возможность программистам и аналитикам визуализировать, специфицировать, конструировать и документировать класс на любом желаемом уровне детализации свойств класса, достаточном для поддержки прямого и обратного проектирования моделей и кода.
Актер – это внешний по отношению к компьютерной системе объект, взаимодействующий с ней. Графически актер изображается в виде пиктограммы, представляющей человека, поскольку актер это человек или группа людей, использующих данные, предоставляемые компьютерной системой. Например, в системе регистрации учебных курсов, актером являются студенты, записывающиеся на курсы преподавателей через автоматизированную систему регистрации курсов.
Прецедент - это описание множества последовательных событий, выполняемых компьютерной системой, которые приводят к наблюдаемому актером результату. Графически прецедент изображается в виде ограниченного непрерывной линией эллипса, обычно содержащего только имя прецедента. На UML диаграммах пиктограммы прецедента и актера обычно располагаются рядом.
Пакет - это единственная в языке UML первичная группирующая сущность. В пакет можно поместить структурные и поведенческие сущности и даже другие пакеты. Изображается пакет в виде папки с закладкой.
Примечание изображается в виде прямоугольника с загнутым краем. На UML диаграмме примечание присоединяется к одному или нескольким элементам диаграммы. Внутри прямоугольника-примечания помещаются комментарии или ограничения, относящиеся к элементу (или нескольким элементам) диаграммы. Комментарий может быть текстовым или графическим.
Рассмотрим теперь пиктограммы отношений, используемых в UML диаграммах. Однонаправленные отношения представляются на UML диаграммах стрелками различных видов, а двунаправленное отношение представляется линией (рис 3.5).
Показанное на рисунке однонаправленное отношение зависимость - это семантическое отношение между двумя сущностями, такое при котором изменение одной (первичной) сущности вызывает изменение семантики другой, зависимой сущности.
Ассоциация – это структурное двунаправленное отношение, описывающее совокупность взаимоотношений между объектами. Пометка единица (1) на левом конце линии ассоциации означает, что в двунаправленном отношении, наряду с многими работниками участвует один работодатель. Единица и звездочка на правом конце линии означает "единица или больше" (1..*). Если один конец линии ассоциации помечен единицей (1), то пометка на другом конце линий называется кратностью ассоциации. Кратность правого конца ассоциации, равна единице или больше. На линии ассоциации можно также задать кратность равную единице (1), можно указать диапазон кратности: ноль или единица (0..1), много (0..*). Разрешается также указывать кратность определенным числом (например 5). С помощью списков можно задавать и более сложные кратности. Например, список 0..1, 3..4, 6..* означает "любое число объектов кроме 2 и 5".Частным случаем ассоциации является отношение типа "часть/целое". Отношение такого типа называется агрегированием. В языке UML оно причислено к отношениям вида "имеет". Агрегирование изображается в виде ассоциации с незакрашенным ромбом со стороны целого, как показано на рис 3.6
Обобщение - это однонаправленное отношение, называемое "потомок/предок", в котором объект "потомок" может быть подставлен вместо объекта предка. Потомок наследует структуру и поведение своего предка. Стрелка всегда указывает на предка.
Реализация – это семантическое однонаправленное отношение, которое может устанавливаться, во-первых, между интерфейсами и реализующими их классами или компонентами, во-вторых, между прецедентами и реализующими их кооперациями. Интерфейсы, компоненты и кооперации это еще три вида пиктограмм, относящихся к структурным сущностям. Пиктограммы интерфейса, кооперации и компонента показаны на рис 3.7
Интерфейс – это совокупность операций, предоставляемых классом или компонентом. Следовательно, интерфейс описывает поведение класса или компонента, видимое извне. Интерфейс определяет только описание (спецификации) операций класса или компонента, но он никогда не определяет физические реализации операций. Графически интерфейс изображается небольшим кружочком под которым пишется его имя, как показано на рис 3.7
Кооперация определяет взаимодействие, например классов. Участвуя в кооперации классы совместно производят некоторый кооперативный результат. Один и тот же класс может принимать участие в нескольких кооперациях. Графически кооперация изображается в виде эллипса, ограниченного пунктирной линией.
Компонент – это физическая часть компьютерной или иной системы. Компонент соответствует некоторому набору интерфейсов и обеспечивает физическую реализацию этого набора. Компоненты могут быть разных видов. Например, одним из видов компонент, используемых для моделирования программного обеспечения компьютерной системы, могут быть файлы исходного кода. Компонент, как правило, представляет собой физическую упаковку логических элементов, таких как классы, интерфейсы и кооперации. Графически компонент изображается в виде прямоугольника с вкладками. Внутри прямоугольника обычно пишется только имя компонента.
С помощью комбинации пиктограмм строятся UML диаграммы. Девять основных видов диаграмм перечисленных в третьей ветви структурного дерева языка UML. Рассмотрим три из них: диаграммы прецедентов, диаграммы классов и диаграммы действий.
Диаграмма прецедентов - это графическое представление всех или части актеров, прецедентов и взаимодействий между ними. В каждой системе обычно есть главная диаграмма прецедентов, которая описывает внешнюю границу системы и основные внешние функции (внешнее поведение) системы. В качестве примера диаграммы прецедентов рассмотрим диаграмму, изображающую все прецеденты для одного актера, которым является регистратор учебных курсов:
Диаграммы классов применяются для моделирования объектно-ориентированных систем. На простых диаграммах показываются классы и отношения между классами. На сложных диаграммах показываются классы, интерфейсы, кооперации и отношения между ними. Диаграммы классов дают статический вид системы. Можно также сказать, что диаграммы классов представляют собой взгляды разработчиков на статические состояния проектируемых систем. С помощью диаграмм классов составляется словарь системы. Диаграммы классов являются основой для создания диаграмм компонентов и развертывания. Следует особо подчеркнуть, что диаграммы классов важны не только для визуализации, специфицирования и документирования структурных моделей, но также для прямого и обратного проектирования исполняемых кодов систем. На рис 3.9 приведен пример простой диаграммы классов, моделирующей объекты системы регистрации курсов и отношения между ними.
UML диаграммы классов включают в себя как частный случай диаграммы "сущность-связь", которые используются для логического проектирования реляционных, объектно-ориентированных и гибридных объектно-реляционных баз данных.
2.2 Программы поддержки языка UML
Мы рассмотрели лишь отдельные фрагменты языка UML. Они дают общее представление о языке и могут быть использованы как вспомогательный материал при его изучении по специальной литературе по языку UML. Однако если пользоваться только литературными источниками, то очень трудно усвоить синтаксис и семантику языка UML. Наилучший способ изучения языка UML заключается в создании UML диаграмм для конкретных систем с помощью инструментальных программ поддержки. Наиболее известной программой поддержки языка UML является пакет Rational Rose 2000. Однако, существуют решения других компаний, например Microsoft Visio и GentleWare Poseidon.
2.3 Основные понятия диаграмм классов UML
Диаграммой классов в терминологии UML называется диаграмма, на которой показан набор классов (и некоторых других сущностей, не имеющих явного отношения к проектированию БД), а также связей между этими классами (иногда термин relationship переводится на русский язык не как “связь”, а как “отношение”). Кроме того, диаграмма классов может включать комментарии и ограничения. Ограничения могут неформально задаваться на естественном языке или же могут формулироваться на языке OCL (Object Constraints Language), который является частью общей спецификации UML, но, в отличие от других частей языка, имеет не графическую, а линейную нотацию. Мы затронем эту тему ниже немного более подробно.
Классом называется именованное описание совокупности объектов с общими атрибутами, операциями, связями и семантикой.
Атрибутом класса называется именованное свойство класса, описывающее множество значений, которые могут принимать экземпляры этого свойства. Класс может иметь любое число атрибутов. Свойство, выражаемое атрибутом, является свойством моделируемой сущности, общим для всех объектов данного класса. Так что атрибут является абстракцией состояния объекта. Любой атрибут любого объекта класса должен иметь некоторое значение.
Операцией класса называется именованная услуга, которую можно запросить у любого объекта этого класса. Операция – это абстракция того, что можно делать с объектом. Класс может содержать любое число операций. Набор операций класса является общим для всех объектов данного класса. Операции класса определяются в разделе, расположенном ниже раздела с атрибутами. При этом можно ограничиться только указанием имен операций, оставив более детальную спецификацию выполнения операций на поздние этапы моделирования. Описание операции может также содержать ее сигнатуру, т.е. имена и типы всех параметров, а если операция является функцией, то и тип ее значения. Класс Человек с определенными операциями показан на рисунке:
В диаграмме классов могут участвовать связи трех разных категорий: зависимость, обобщение и ассоцирование. Для проектирования реляционных БД наиболее важны вторая и третья категории связей. Поэтому по поводу связей-зависимостей мы будет очень кратки.
Связь-зависимость - связь по использованию, когда изменение в спецификации одного класса может повлиять на поведение другого, использующего первый класса. Чаще всего зависимости применяются в диаграммах классов, чтобы отразить в сигнатуре операции одного класса тот факт, что параметром этой операции могут быть объекты другого класса. Понятно, что если интерфейс этого второго класса изменяется, то это влияет на поведение объектов первого класса. Простой пример диаграммы классов со связью-зависимостью показан на рисунке:
Легко видеть, что связи-зависимости существенны для объектно-ориентированных систем.
Связь-обобщение - связь между общей сущностью, называемой суперклассом, или родителем, и более специализированной разновидностью этой сущности, называемой подклассом, или потомком. Класс-потомок наследует все атрибуты и операции класса-предка, но в нем могут быть определены дополнительные атрибуты и операции.
Объекты класса-потомка могут использоваться везде, где могут использоваться объекты класса-предка. Это свойство называют полиморфизмом по включению, имея в виду, что объекты потомка можно считать включаемыми в класс-предок. Графически обобщения изображаются в виде сплошной линии с большой незакрашенной стрелкой, направленной к суперклассу. На рисунке показан пример иерархии одиночного наследования: у каждого подкласса имеется только один суперкласс.
Иерархия одиночного наследования классов
Одиночное наследование является достаточным в большинстве практических случаев применения связи-обобщения. Однако в UML допускается и множественное наследование, когда один подкласс определяется на основе нескольких суперклассов. В качестве одного из разумных примеров рассмотрим следующую диаграмму классов (для упрощения диаграммы не будем указывать имена атрибутов и операций).
Пример множественного наследования классов
На этой диаграмме классы Студент и Преподаватель порождены из одного суперкласса Человек из Университета. Но как это часто случается, многие студенты уже в студенческие годы начинают преподавать, так что могут существовать такие два объекта классов Студент и Преподаватель, которым соответствует один объект класса ЧеловекИзУниверситета. Итак, среди объектов класса Студент могут быть преподаватели, а некоторые преподаватели могут быть студентами. Мы можем определить класс Студент Преподаватель путем множественного наследования от суперклассов Студент и Преподаватель. Объект класса СтудентПреподаватель обладает всеми свойствами и операциями классов Студент и Преподаватель, и может быть использован везде, где могут использоваться объекты этих классов. Так что полиморфизм по включению продолжает работать.
Но множественное наследование, помимо того, что не слишком часто требуется на практике, порождает ряд проблем, из которых одной из наиболее известных является проблема именования атрибутов и операций в подклассе, полученном путем множественного наследования. Например, предположим, что при образовании подклассов Студент и Преподаватель в них обоих был создан атрибут с именем “номерКомнаты”. Очень вероятно, что для объектов класса Студент значениями этого атрибута будут номера комнат в студенческом общежитии, а для объектов класса Преподаватель – номера служебных кабинетов. Как быть с объектами класса Студент Преподаватель, для которых существенны оба одноименных атрибута? На практике применяется одно из следующих решений:
Ни одно из решений не является полностью удовлетворительным. Первое решение требует возврата к ранее определенному классу, имена атрибутов и операций которого, возможно, уже используются в приложениях. Второе решение нарушает логику наследования, не давая возможности на уровне подкласса использовать все свойства суперклассов. Наконец, третье решение заставляет использовать длинные имена атрибутов и операций, которые могут стать недопустимо длинными, если процесс множественного наследования будет продолжаться от полученного подкласса.
Но, конечно, сложность проблемы именования атрибутов и операций не идет ни в какое сравнение со сложностью реализации множественного наследования в реляционных БД. Поэтому при использовании UML для проектирования реляционных БД нужно очень осторожно использовать наследование классов и стараться вообще избегать множественного наследования.
Связи-ассоциации
Ассоциацией называется структурная связь, показывающая, что объекты одного класса некоторым образом связаны с объектами другого или того же самого класса. Допускается, чтобы оба конца ассоциации относились к одному классу. В ассоциации могут связываться два класса, и тогда она называется бинарной. Допускается создание ассоциаций, связывающих сразу n классов (они называются n-арными ассоциациями). Графически ассоциация изображается в виде линии, соединяющей класс сам с собой или с другими классами.
С понятием ассоциации связаны четыре важных дополнительных понятия: имя, роль, кратность и агрегация. Во-первых, ассоциации может быть присвоено имя, характеризующее природу связи. Смысл имени уточняется черным треугольником, располагаемым над линией связи справа или слева от имени ассоциации. Этот треугольник указывает направление, в котором должно читаться имя связи. Пример именованной ассоциации показан на рисунке. Треугольник означает, что именованная ассоциация должна читаться как “Студент учится в Университете”.
Пример именованной ассоциации
Другим способом именования ассоциации является указание роли каждого класса, участвующего в этой ассоциации. Роль класса задается именем, помещаемым под линией ассоциации ближе к данному классу. На следующем рисунке показаны две ассоциации между классами Человек и Университет, в которых эти классы играют разные роли. Как мы видим, объекты класса Человек могут выступать в роли РАБОТНИКОВ при участии в ассоциации, в которой объекты класса Университет играют роль НАНИМАТЕЛЯ. В другой ассоциации объекты класса Человек играют роль СТУДЕНТА, а объекты класса УНИВЕРСИТЕТ – в роли ОБУЧАЮЩЕГО.
Две ассоциации с разными ролями классов
В общем случае, для ассоциации может задаваться и ее собственное имя, и имена ролей классов. Это связано с тем, что класс может играть одну и ту же роль в разных ассоциациях, так что в общем случае пара имен ролей классов не идентифицирует ассоциацию. С другой стороны, в простых случаях, когда между двумя классами определяется только одна ассоциация, можно вообще не связывать с ней дополнительные имена.
Кратностью (multiplicity) роли ассоциации называется характеристика, указывающая, сколько объектов класса с данной ролью может или должно участвовать в каждом экземпляре ассоциации (в UML экземпляр ассоциации называется соединением – link). Наиболее распространенным способом задания кратности роли ассоциации является указание конкретного числа или диапазона. Например, указание “1” говорит о том, что все объекты класса с данной ролью должны участвовать в некотором экземпляре данной ассоциации, причем в каждом экземпляре ассоциации может участвовать ровно один объект класса с данной ролью. Указание диапазона “0..1” говорит о том, что не все объекты класса с данной ролью обязаны участвовать в каком-либо экземпляре данной ассоциации, но в каждом экземпляре ассоциации может участвовать только один объект. Аналогично, указание диапазона “1..*” говорит, что все объекты класса с данной ролью должны участвовать в некотором экземпляре данной ассоциации, и в каждом экземпляре ассоциации должен участвовать хотя бы один объект (верхняя граница не задана). Толкование диапазона “0..*” является очевидным расширением случая “0..1”.
В более сложных (но крайне редко встречающихся на практике) случаях определения кратности можно использовать списки диапазонов. Например, список “2, 4..6, 8..*” говорит, что все объекты класса с указанной ролью должны участвовать в некотором экземпляре данной ассоциации, и в каждом экземпляре ассоциации должны участвовать два, от четырех до шести или более восьми объектов класса с данной ролью.
Ассоциации с указанными кратностями ролей
На диаграмме классов с рисунка показано, что произвольное (может быть, нулевое) число людей являются работниками произвольного числа университетов. Каждый университет обучает произвольное (может быть, нулевое) число студентов, но каждый студент может быть студентом только одного университета.
Обычная ассоциация между двумя классами характеризует связь между равноправными сущностями: оба класса находятся на одном концептуальном уровне. Иногда в диаграмме классов требуется отразить тот факт, что ассоциация между двумя классами имеет специальный вид “часть-целое”. В этом случае класс “целое” имеет более высокий концептуальный уровень, чем класс “часть”. Ассоциация такого рода называется агрегатной. Графически агрегатные ассоциации изображаются в виде простой ассоциации с незакрашенным ромбом на стороне класса-“целого”. Простой пример агрегатной ассоциации показан на рисунке:
Пример агрегатной ассоциации
Объектами класса Аудитория являются студенческие аудитории, в которых проходят занятия. В каждой аудитории должны быть установлены парты. Поэтому в некотором смысле класс Парта является “частью” класса Аудитория. Мы умышленно сделали роль класса Парта необязательной, поскольку могут существовать аудитории без парт (например, класс для занятий танцами), и некоторые парты могут находиться на складе. Обратите внимание, что хотя аудитории, не оснащенные партами, как правило, непригодны для занятий, объекты классов Аудитория и Парта существуют независимо. Если некоторая аудитория ликвидируется, то находящиеся в ней парты не уничтожаются, а переносятся на склад.
Бывают случаи, когда связь “части” и “целого” настолько сильна, что уничтожение “целого” приводит к уничтожению всех его “частей”. Агрегатные ассоциации, обладающие таким свойством, называются композитными, или просто композициями. При наличии композиции объект-часть может быть частью только одного объекта-целого (композита). При обычной агрегатной ассоциации “часть” может одновременно принадлежать нескольким “целым”. Графически композиция изображается в виде простой ассоциации, дополненной закрашенным ромбом со стороны “целого”. Пример композитной агрегатной ассоциации показан на рисунке:
Пример композитной агрегатной ассоциации
Любой факультет является частью одного университета, и ликвидация университета приводит к ликвидации всех существующих в нем факультетов (хотя во время существования университета отдельные факультеты могут ликвидироваться и создаваться).
Заметим, что в контексте проектирования реляционных БД агрегатные и в особенности композитные ассоциации влияют только на способ поддержки ссылочной целостности. В частности, композитная связь является явным указанием того, что ссылочная целостность между “целым” и “частями” должна поддерживаться путем каскадного удаления частей при удалении целого. При наличии простой ассоциации между двумя классами предполагается возможность навигации между объектами, входящими в один экземпляр ассоциации. Если известен конкретный объект-студент, то должна обеспечиваться возможность узнать соответствующий объект-университет. Если известен конкретный объект-университет, то должна обеспечиваться возможность узнать все соответствующие объекты-студенты. Другими словами, если не оговорено противное, то навигация по ассоциации может проводиться в обоих направлениях. Однако бывают случаи, в которых желательно ограничить направление навигации для некоторых ассоциаций. В этом случае на линии ассоциации ставится стрелка, указывающая направление навигации. Возможный пример показан на рисунке:
Ассоциация с указанным направлением навигации
В библиотеке должно содержаться некоторое число книг, но каждая книга должна принадлежать некоторой библиотеке. С точки зрения библиотечного хозяйства разумно иметь возможность найти книгу в библиотеке, т.е. произвести навигацию от объекта-библиотеке к связанным с ним объектам-книгам. Однако вряд ли потребуется по данному экземпляру книги узнать, в какой библиотеке она находится.
Модель сущность - связь (ER-модель) (англ. entity-relationship model, ERM) — модель данных, позволяющая описывать концептуальные схемы предметной области.
ER-модель используется при высокоуровневом (концептуальном) проектировании баз данных. С её помощью можно выделить ключевые сущности и обозначить связи, которые могут устанавливаться между этими сущностями.
Во время проектирования баз данных происходит преобразование ER-модели в конкретную схему базы данных на основе выбранной модели данных (реляционной, объектной, сетевой или др.).
ER-модель представляет собой формальную конструкцию, которая сама по себе не предписывает никаких графических средств её визуализации. В качестве стандартной графической нотации, с помощью которой можно визуализировать ER-модель, была предложена (ER-диаграмма) (англ. entity-relationship diagram, ERD).
Понятия ER-модель и ER-диаграмма часто ошибочно не различают, хотя для визуализации ER-моделей предложены и другие графические нотации
Пример отношения между сущностями согласно нотации Crow's Foot
Данная нотация была предложена Гордоном Эверестом (англ. Gordon Everest) под названием Inverted Arrow («перевёрнутая стрелка»), однако сейчас чаще называемая Crow's Foot («воронья лапка») или Fork («вилка»).
Согласно данной нотации, сущность изображается в виде прямоугольника, содержащем её имя, выражаемое существительным. Имя сущности должно быть уникальным в рамках одной модели. При этом, имя сущности — это имя типа, а не конкретного экземпляра данного типа. Экземпляром сущности называется конкретный представитель данной сущности.
Связь изображается линией, которая связывает две сущности, участвующие в отношении. Степень конца связи указывается графически, множественность связи изображается в виде «вилки» на конце связи. Модальность связи так же изображается графически — необязательность связи помечается кружком на конце связи. Именование обычно выражается одним глаголом в изъявительном наклонении настоящего времени: «Имеет», «Принадлежит» и т. д.; или глаголом с поясняющими словами: «Включает в себя», и т.п. Наименование может быть одно для всей связи или два для каждого из концов связи. Во втором случае, название левого конца связи указывается над линией связи, а правого – под линией. Каждое из названий располагаются рядом с сущностью, к которой оно относится.
Атрибуты сущности записываются внутри прямоугольника, изображающего сущность и выражаются существительным в единственном числе (возможно, с уточняющими словами). Среди атрибутов выделяется ключ сущности — неизбыточный набор атрибутов, значения которых в совокупности являются уникальными для каждого экземпляра сущности.
В общем и целом, построение моделей и их оптимизация – главные
направления междисциплинарных работ, дающие возможность надежного
описания систем и процессов. Они являются предпосылками для
целенаправленного использования их свойств в интересах общества.
Модели способствуют плодотворному производству во всех сферах жизни так
как:
- сокращают издержки;
- показывают несостоятельность некоторых идей;
- экономят время ( модели доводятся до совершенства и лишь затем на их
основе начинается производство, строительство и т.д.)
Моделирование – одна из основных категорий научного познания, на идее
моделирования базируется любой, в частности теоретический или
практический, метод научного познания.