Концептуальная модель предметной области

Размещено на http://www.allbest.ru/

Министерство науки и высшего образования Российской Федерации

Федеральное государственное бюджетное образовательное учреждение высшего образования

«Саратовский государственный технический университет

Имени Гагарина Ю.А.»

Институт машиностроения, материаловедения и транспорта

Кафедра «Технология и системы управления в машиностроении»

Контрольная работа

По дисциплине

«Интеллектуальные технологии в машиностроении»

Саратов 2022



Заданиена контрольную работу по дисциплине

Министерство науки и высшего образования Российской Федерации

Федеральное государственное бюджетное образовательное учреждение высшего образования

«Саратовский государственный технический университет имени Гагарина Ю.А.»

Институт машиностроения, материаловедения и транспорта

Кафедра «Технология и системы управления в машиностроении»

«Утверждаю»:

Зав. кафедрой ТСУ

Захарченко М.Ю._______

«___» ____________2022 г.

«Интеллектуальные технологии в машиностроении» студента ИММТ группы б-АТППипу41.

Выполнить работу:

Концептуальные модели описания предметных областей

Дата выдачи задания: 28.09.2021 г.

Срок выполнения: 17.06.2022г.

Преподаватель:

Студент:

Текстовая часть выполнена в редакторе MicrosoftWord 2010

Саратов 2022



Содержание

Введение

1. Концептуальная модель предметной области



Введение

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



1. Концептуальная модель предметной области

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

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

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

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

Центральное место в объектно ориентированном подходе к проектированию ПС занимает разработка логической модели системы в виде диаграммы классов. Диаграмма классов определяет типы объектов системы и различного рода статические связи, которые существуют между ними. Класс в языке UML служит для обозначения множества объектов, которые имеют одинаковую структуру, поведение и отношения с объектами из других классов. На диаграмме класс изображается в виде прямоугольника, который дополнительно может быть разделен горизонтальными линиями на две или три секции (рис. 1). В этих разделах могут указываться имя класса, атрибуты (переменные) и операции (методы). Иногда добавляется четвертая секция, которая содержит описание исключительных ситуаций. Чтобы отличить класс от других элементов языка иМЬ, секции атрибутов и операций выделяют горизонтальными линиями, даже если они пустые (см. рис. 1).

Рис. 1 Варианты изображения классов

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

Во второй секции прямоугольника записываются атрибуты класса или свойства. Стандартная запись атрибута в языке UML выглядит следующим образом: < квантор видимости > < имя атрибута > [кратность]:

< тип атрибута > = < исходное значение > {строка свойств}.

Квантор видимости может быть опущен - это означает, что видимость атрибута не указывается либо же должна принимать одно из трех возможных значений:

* общедоступный (public) - обозначается «+»;

* защищенный (protected) - обозначается «#»;

* закрытый (private) - обозначается «-».

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

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

[нижняя_граница1 ... верхняя_граница1, нижняя_граница2 ... верх-няя_граница2, ... нижняя_ границак ... верхняя границак], где нижняя_граница и верхняя_граница являются положительными целыми числами, каждая пара которых служит для обозначения отдельного замкнутого интервала целых чисел. В качестве верхней границы может использоваться специальный символ «*», который означает произвольное положительное целое число, т.е. не ограниченное сверху значение кратности соответствующего атрибута. Если указывается единственный знак «*», то это означает, что кратность атрибута может быть произвольным положительным целым числом или нулем. Если кратность атрибута не указана, то по умолчанию она равна нулю.

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

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

В третьей секции класса прямоугольника, обозначающего некоторый класс, указывается операция (или операции) класса. Часто понятия «операция» и «метод класса» отождествляют. Однако эти понятия в UML различаются. Операция - это сервис, который может быть запрошен у любого объекта класса для реализации поведения, а метод -реализация операции [6]. Каждой неабстрактной операции класса должен быть сопоставлен метод, который содержит исполняемый алгоритм в виде тела класса.

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

< квантор видимости > < имя операции > (список параметров):

< выражение типа возвращаемого значения >{строка свойств}.

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

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

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

< направление > < имя параметра > : < выражение типа> --

< значение параметра по умолчанию > .

Направление может принимать одно из следующих значений:

* in - входной параметр, который не может быть модифицирован;

* out - выходной параметр, который может быть модифицирован для передачи информации вызывающему коду;

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

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

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

Строка свойств служит для определения значений свойств операции. Она может отсутствовать, если никакие свойства не специфицированы. Операция, которая не может изменять наблюдаемое состояние класса, обозначается строкой-свойством {запрос} (query). Наблюдаемым состоянием объекта является состояние, которое можно определить посредством связанных с ним запросов. Ряд свойств операции предназначен для поддержки семантики параллелизма операций. К ним относятся sequential (последовательная), guarded (защищенная) и concurrent (параллельная). Эти свойства существенны только в присутствии активных объектов, процессов или потоков. Если какая-либо операция в некотором классе не выполняется, она может быть помечена как абстрактная {abstract}. Классы - наиболее важные строительные блоки любой объектно ориентированной системы. Однако они представляют лишь одну разновидность более общих строительных блоков UML - классификаторов. Классификатор - это механизм, описывающий структурные и поведенческие свойства. UML предоставляет множество других немаловажных для моделирования классификаторов [6]:

* интерфейс - набор операций, используемых для спецификации сервиса класса или компонента;

* тип данных - тип, значение которого неизменно (примеры: примитивные встроенные типы (числа, строки и др.), типы перечислений И др.);

* ассоциация - описание набора ссылок, каждая из которых соединяет ряд объектов;

* сигнал - спецификация асинхронного сообщения, передаваемого между экземплярами объектов;

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

* узел - физический элемент, существующий во время исполнения и представляющий вычислительный ресурс, который обычно наделен некоторой памятью и - частично - вычислительными возможностями;

* вариант использования - описание последовательности действий, осуществляемых системой и порождающих значимый результат для определенного действующего лица;

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

Графически UML представляет эти виды классификаторов так, как показано на рис. 2

класс

Shape

Origin

интерфейс	тип данных	сигнал
«interface» Tasteful		«type» Int		«signal» OffHook
set (v: Object) get (): Object		{values range from} -2**31-to 2**31

Вариант использования

Move () Resize () Display ()

Компонент

Call Handing

Узел



Рис. 2. Классификаторы иМЬ

подсистема

«subsystem»

Customer Service

Язык иМЬ предлагает использовать три уровня диаграмм классов в зависимости от степени их детализации.

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

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

3. Уровень реализации, на котором диаграммы классов непосредственно показывают поля и операции конкретных классов.

Каждую из перечисленных моделей используют на конкретном этапе разработки программных систем:

* концептуальную модель на - этапе анализа;

* диаграммы классов уровня спецификации - на этапе проектирования;

* диаграммы классов уровня реализации - на этапе реализации.

Диаграмма классов может отражать различные взаимосвязи между

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

* классы;

* интерфейсы;

* кооперации;

* отношения зависимости, обобщения и ассоциации.

В UML способы соединения сущностей друг с другом, логические либо физические, моделируются связями (рис. 5.26). В объектно ориентированном моделировании существует три типа наиболее важных связей: зависимости, обобщения и ассоциации [6].

1. Зависимость представляет собой связь использования. Это связь, которая устанавливает, что одна сущность, например класс Window (Окно), использует информацию и сервис (операцию или услугу), предоставляемые другой сущностью, например классом Event («Событие»), но необязательно наоборот. Зависимость изображается пунктирной линией со стрелкой, направленной на зависимую сущность. Чаще всего зависимость используется для того, чтобы показать, что один класс использует операции другого класса. концептуальный логический атрибут домен

2. Ассоциация - это структурная связь между экземплярами. Она показывает, что объекты одной сущности соединяются с объектами другой. Ассоциация изображается сплошной линией. Допустимо, чтобы оба конца ассоциации соединяли один и тот же класс, иными словами, один объект класса может связываться с другим объектом того же класса. Обычно ассоциация бинарна, т.е. связывает два класса, но бывают и парные ассоциации. Класс, участвующий в ассоциации, выполняет конкретную роль. Роль, которую играет класс, находящийся на конце ассоциации, называется конечным именем (в первой версии UML она называлась именем роли). Ассоциация может иметь параметр множественности. Он представляет собой диапазон целых чисел, указывающий количество связанных объектов (рис. 5.27). Множественность может быть определена как единица (1), ноль или один (0..1), много (0..* или *), один или несколько (1 ..*).

Рис. 3. Способы соединения сущностей

1..*

Человек -

работник

* _

- Компания

работодатель

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

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

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

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

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

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

Одной из распространенных моделей концептуальной схемы является модель «сущность - связь». Основными конструкциями данной модели являются сущности и связи.

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

Экземпляр сущности - конкретный объект.

Например:

сущность (объект) - институт экземпляр сущности -СГУТиКД.

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

сущность студент

атрибуты: ФИО, Группа,

Пример. Спроектировать БД "Сессия". База данных должна выдавать оперативную информацию об успеваемости студентов на факультетах в семестре. Результатами сессии считать только экзамены.

По сути дела, в БД исходя из формулировки задания, можно выделить лишь одно приложение. Речь идет об успеваемости студентов разных факультетов по тем или иным дисциплинам. Более конкретно речь идет о выдаче справок по результатам сессии каждого студента, учебной группы, курса. (Факультета, а также об автоматизированном составлении ведомости.)

Выберем следующие сущности:

Университет, институт, студент, преподаватель, дисциплина.

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

Зададим каждую сущность набором атрибутов, например:

Университет (название, подчиненность, адрес, телефон, ФИО ректора).

Институт (название, код специальности, группы, декан).

Студент (ФИО, группа, курс, номер семестра).

Преподаватель (ФИО, должность, звание, институт, читаемые дисциплины).

Дисциплина (название, число часов, виды занятий, номер семестра, итоговая аттестация)

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

Название связи	Сущность 1	Сущность 2	Сущность 3
учится	студент	институт
изучает	студент	дисциплина
имеет	университет	институт
работает	преподаватель	институт
преподает	преподаватель	дисциплина
экзамен	студент	дисциплина	преподаватель

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

Рассмотрим некоторые ограничения в рассматриваемом примере:

1. Значение атрибута "курс" (сущность - студент) лежит в интервале 1-6.

4. Значение атрибута "семестр" (сущность - студент, дисциплина) в интервале 1-12.

5. Значение атрибута "число часов" (сущность - дисциплина) лежит в интервале 1-300.

6. Одному студенту может быть приписана только одна группа.

7. Один студент может учиться только на одном факультете.

8. Один студент в семестре сдает от 3 до 5 дисциплин.

9. Один студент изучает в семестре от 6 до 12 дисциплин.

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

11. Один студент может пересдавать одну дисциплину не более трех раз.

12. Ключи: название института, название университета, ФИО и группа студента, ФИО и преподавателя, название дисциплины.



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

Для уменьшения нежелательных характеристик БД к схемам отношений применяют процедуры нормализации. Рассмотрим понятие функциональной зависимости. Пусть R (A1, A2,...,Ai,...,An) - схема отношения R. Обозначим через Dom (Aj) множество возможных состояний атрибута Aj. Будем говорить, что атрибуты Ai и AJ отношения К связаны функциональной зависимостью, т.е. f: Dom (Ai) -> Dom (Aj), которую будем понимать как множество упорядоченных пар

{ <а, в> / а€ Dom (Ai), b€ Dom (Aj) },

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

При этом в каждый момент элементу а€ Dom (Ai) соответствует не более

одного элемента b€ Dom (Aj).

Функциональная связь доменов инвариантна по отношению к схеме конкретного отношения. Понятие функциональной зависимости позволяет определить ключ отношения. Пример 1.

Выявим функциональные зависимости в отношении БД "Учеба". R учеба (факультет, группа, дисциплина, вид занятий, преподаватель, квалификация преподавателя)

f: (дисциплина, вид занятий) -> квалификация преподавателя преподаватель -> квалификация преподавателя

группа -> факультет преподаватель -> факультет

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

Размещено на Allbest.ru

...