Проектирование автоматической информационной системы преобразования сигнала нагрузки на элементы подвески автомобиля в ОММиР
Проектирование информационной системы (ИС) преобразования данных с помощью математических и алгоритмических подходов. Автоматизированная ИС преобразования измеренных значений сил и моментов в расчетные случаи для виртуальной модели автомобиля для ОММиР.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | курсовая работа |
| Язык | русский |
| Дата добавления | 25.12.2011 |
| Размер файла | 2,6 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Филиал федерального государственного бюджетного образовательного учреждения
Высшего профессионального образования
"Самарский государственный аэрокосмический университет имени академика С.П. Королева (национальный исследовательский университет)"
в городе Тольятти Самарской области
Кафедра радиоэлектроники и системотехники.
Проектирование АИС преобразования сигнала нагрузки на элементы подвески автомобиля в ОММиР
Пояснительная записка к курсовому проекту
по курсу "Проектирование АСОИУ"
Руководитель проекта,
Исполнитель,
Тольятти 2011
Реферат
Курсовой проект.
Пояснительная записка 31 с., 12 рисунков, 2 таблицы, 8 источников.
WEB-ПРИЛОЖЕНИЕ, SQL-СЕРВЕР, МНОГОЗВЕННАЯ АРХИТЕКТУРА, HTML-СТРАНИЦА, СЕРВЛЕТ, КОНТЕЙНЕР СЕРВЛЕТОВ, JSP-СТРАНИЦА, СЕРВЕР ПРИЛОЖЕНИЙ, WEB-СЕРВЕР, ИНТЕРФЕЙС, ПРЕОБРАЗОВАНИЕ СИГНАЛА НАГРУЗКИ.
Объектом исследования является автоматизированная информационная система отдела математического моделирования и расчетов научного технического центра ОАО "АвтоВАЗ". Целью работы является проектирование АИС расчета долговечности кузова.
В процессе исследования проведен анализ существующей информационной системы предприятия, выявлены ее недостатки, снижающие эффективность работы организации. На основании определенных недостатков сформулированы требования к проектируемой информационной системе.
В процессе работы будет спроектировано приложение, разработаны алгоритмы преобразования, а также схемы и модели БД.
Содержание
- Реферат
- Введение
- Описание и моделирование предметной области
- Описание объекта автоматизации
- Формализация существующих бизнес-процессов
- Обоснование технологии проектирования
- Проектирование ИС
- Обоснование технологии проектирования
- Разработка модели ИС
- Проектирование базы данных ИС
- Инфологическое (концептуальное) проектирование
- Обоснование логической модели БД
- Построение логической модели БД
- Заключение
- Список использованной литературы
- Приложение 1
- Приложение 2
Введение
Вопрос надежности и безопасности является основополагающим при создании автомобиля, так как от этого зависят здоровье и жизни людей. Именно от разработки показателей надежности авто будет зависеть свойство снижения вероятности столкновения автомобиля, а также свойство уменьшения последствий столкновений. Рассматриваемая организация - отдел математического моделирования и расчетов НТЦ ОАО "АвтоВАЗ". Естественно, на данном предприятии используются различные подходы и ИС по разработке показателей надежности и безопасности. Однако некоторые процессы являются не автоматизированными или вовсе не введены в производство.
Рассматриваемая тема является актуальной, так как расчет долговечности кузова в настоящее время является длительным, неточным и дорогостоящим процессом. Это вызвано большим количеством процессов, выполняемых на реальном автомобиле.
Новизна заключается в том, что проектируемая АИС еще не использовалась в рамках рассматриваемой организации ОММиР НТЦ ОАО "АвтоВАЗ".
Предметом исследования является процесс расчета долговечности кузова.
Объектом исследования является автоматизированная информационная система преобразования измеренных значений сил и моментов в расчетные случаи для виртуальной модели автомобиля для ОММиР.
Целью данной работы является проектирование информационной системы преобразования данных с помощью математических и алгоритмических подходов.
Для достижения поставленной цели необходимо решить следующие задачи:
1. Описать предметную область и объект автоматизации.
2. Спроектировать модель текущего состояния информационной системы заказчика "как есть" и выявить недостатки, сформировать требования, определить основной функционал разрабатываемого продукта.
3. Спроектировать модель предлагаемого состояния информационной системы заказчика "как должно быть".
4. Определить основной функционал разрабатываемого продукта.
5. Составить логическую и физическую модели БД.
6. Составить диаграмму компонентов АИС.
7. Провести оценку проделанной работы и выявить дальнейшие пути улучшения АИС.
Пояснительная записка состоит из введения, трех глав и заключения.
Во введении описываются актуальность выполняемого курсового проекта, его новизна, цели и задачи. Задачи определяют основные шаги и этапы, необходимые для выполнения цели курсового проекта.
В первой главе рассмотрена предметная область, а именно описание объекта автоматизации - ОММиР НТЦ ОАО "АвтоВАЗ", формализация существующих бизнес-процессов и анализ их "узких" мест. Кроме того, здесь будет выбран метод и технология проектирования.
Во второй главе реализовано непосредственное проектирование ИС, сравнительный анализ, выбор и разработка архитектуры.
В третьей главе выполнено проектирование БД ИС, обзор современных моделей, используемых для логического моделирования и выбор необходимой на основе сравнительного анализа.
Описание и моделирование предметной области
Описание объекта автоматизации
Научный технический центр - инжиниринговый центр Волжского автомобильного завода, который начал ведет свою деятельность 25 лет и включает в себя следующие основные мощности: инженерный корпус, дизайн-центр, комплекс подготовки автомобилей к испытаниям, комплекс исследований электромагнитной совместимости, прочности, шумов и вибраций, аэроклиматический комплекс, корпуса опытно-промышленного и экспериментального производств. В комплексе исследований прочности автомобилей находится отдел, который и будет рассматриваться далее как заказчик. Данный структура несет название отдел математического моделирования и расчетов, в котором ведутся работы по следующим направлениям:
- прочностные расчеты;
- виброакустический комфорт;
- пассивная безопасность;
- общая динамика автомобиля (шасси, подвеска, плавность хода);
- внешняя и внутренняя аэродинамика.
Заказчик имеет организационно-штатную структуру, представленную на следующем рисунке (цветом выделены структурные единицы, принимающие участие в расчете долговечности кузова):
Рисунок 1 Организационно-штатная структура рассматриваемой организации
Расчет долговечности кузова производится в управлении функциональных свойств автомобиля. При этом в нем участвует два отдела, входящих в его состав: отдел математического моделирования и расчетов и отдел динамики автомобиля. В отделе динамики автомобиля проводят испытания автомобиля на специализированном треке, и результаты испытания отправляют в отдел ММиР. Взаимосвязь отделов происходит с помощью начальников отдела и их заместителей. Отдел математического моделирования включает в себя следующий бюро:
- бюро прочностных расчетов;
- бюро общей динамики автомобиля;
- бюро виброакустического комфорта;
- бюро пассивной безопасности;
- бюро внешней и внутренней аэродинамики.
Проектируемая АИС направлена на решение задачи, которой занимаются бюро прочностных расчетов в ОММиР и бюро испытания автомобиля в отделе динамики автомобиля. При этом процесс улучшения кузова начинается с проведения испытания автомобиля на специализированном треке в отделе динамики автомобиля. Результаты испытания передаются в бюро прочностных расчетов отдела ММиР. После анализа повреждений текущего кузова ищутся решения для их предотвращения и передаются в отдел динамики автомобиля, в котором изменяют конструкцию кузова в соответствие с решениями ОММиР и снова проводят испытания. Данный подход требует больших затрат времени, а также значительных материальных затрат для постоянного изменения конструкции кузова автомобиля и проведения испытаний.
Проектируемая АИС должна сократить материальные и временные затраты процесса улучшения прочностных характеристик кузова автомобиля, а также позволять получать более точную информацию о деформациях кузова после проведения испытания.
Необходимо описать действующую систему расчета долговечности кузова, что и будет сделано в следующем параграфе.
Формализация существующих бизнес-процессов
На сегодняшний день у заказчика существует следующая модель проведения процесса улучшения прочностных характеристик кузова автомобиля:
автоматизированная информационная система автомобиль
Рисунок 2 Существующая технология расчета долговечности кузова
На представленной диаграмме описывается текущий процесс улучшения характеристик кузова автомобиля перед передачей итогового варианта кузова на производство. При этом на первый вариант кузова устанавливают датчики на автомобиль: тензо-ступицы на колеса автомобиля и датчики напряжения на различные элементы кузова автомобиля. Данные датчики собирают информации о нагрузках по трем направлениям (x, y и z) и моменты вокруг этих осей на четырех колесах, на всех местах расположения остальных датчиков, а также в центре масс всего автомобиля. Проводят испытания на специализированном треке, на котором расположены все возможные элементы неровностей на реальной дороге. Испытание на данном треке проводят до достижения пробега 33 000 км, что соответствует 400 000 км пробега на реальной дороге городского пользования. После этого производят полную разборку автомобиля и поиск видимых деформаций. Данная информация вместе со сведениями, полученными с датчиков, поступает к инженерам расчетчикам в бюро прочностных расчетов. В данном бюро занимаются анализом полученных сведений и поиском решения по предотвращению текущих повреждений, найденных на кузове. При этом проводят виртуальные испытания для отдельного элемента, на котором были найдены повреждения. После этого измененную конструкцию кузова со всеми параметрами изменений отправляют на сборку и снова проводят испытания.
Проанализировав существующую технологию расчета долговечности кузова видны основные проблемы текущей системы:
- длительность испытания (для достижения пробега 33 000 км необходимо около двух недель);
- длительность всего процесса расчета за счет повторения некоторых операций (сборка, проведения испытания, разборка);
- нахождение только видимых повреждений на кузове;
- значительные материальные затраты на проведение испытаний.
Путем решения большинства данных проблем является создание АИС для проведения расчета долговечности кузова и повышения качества продукции. Предлагаемая АИС позволит после проведения первого испытания кузова и получения необходимых данных использовать полученные сведения для дальнейших виртуальных испытаний кузова. Данный подход позволит сократить время создания качественного кузова, позволит находить элементы кузова, которые подвержены высокой нагрузке, но не были повреждены, а также сократить материальные затраты на проведения процесса расчета долговечности кузова.
В результате анализа существующей системы расчета долговечности кузова было принято решение о создании системы, позволяющей сократить временные и материальные затраты на процесс расчета, а также повысить качество итоговой продукции.
Предлагаемая система позволит устранить найденные недостатки за счет изменения большинства этапов общей технологии расчета долговечности кузова. В новой системе последовательность этапов будет следующей:
1. Подготовка автомобиля к испытанию (установка тензо-ступиц и тензо-датчиков).
2. Проведение испытания автомобиля на специализированном треке.
3. Выполнение двух параллельных этапов:
3.1. разбор автомобиля и поиск видимых повреждений;
3.2. анализ полученных с датчиков данных и преобразование в сигнал более простого вида, который будет соответствовать реальным значениям нагрузки (17 расчетных случаев).
4. Анализ деформаций и поиск решения для их предотвращения.
5. Изменение конструкции модели кузова.
6. Виртуальное испытание автомобиля в соответствии с упрощенными значениями нагрузки и значениями предельной нагрузки для заданных материалов.
Дальнейшие проверка кузова происходит повторением 4, 5 и 6 этапов без проведения испытания реального автомобиля.
Выбор и обоснование CASE средств, метода и технологии проектирования и будет рассмотрен в следующем параграфе.
Обоснование технологии проектирования
Для проектирования АИС необходимо определить архитектуру, которая будет использоваться при ее построении. Критериями для определения выбора будут являться:
1. Производительность - критерий, определяющий насколько хорошо, система будет справляться с высокими нагрузками.
2. Стоимость - должна быть как можно меньше, чтобы повысить экономическую эффективность проекта в целом.
3. Отказоустойчивость - система должна продолжать работу при отказе некоторых ее компонентов.
4. Масштабируемость - способность системы справляться с увеличением рабочей нагрузки (увеличивать свою производительность) при добавлении новых ресурсов.
В результате анализа рассматриваемой структурной единицы организации может быть представлена общая архитектура проектируемой информационной системы:
Рисунок 3. Архитектура проектируемой информационной системы
Как видно из представленного выше рисунка, архитектура информационной системы будет состоять из 4 основных компонентов:
1. Датчики, установленные на испытуемом автомобиле.
2. Внешняя система, позволяющая получать сведения с датчиков непосредственно в отделе динамики автомобиля.
3. Сервер базы данных, на котором будет храниться вся информация с датчиков о нагрузках на определенные элементы кузова.
4. Сервер проектируемой системы, на которой будет происходить преобразование данных, полученных в результате испытания.
Таким образом, в рамках данной главы был проведен анализ предметной области, определены основные бизнес-процессы, протекающие при расчете долговечности кузова, выявлены проблемы, связанные с текущим состоянием системы. На основании изложенных проблем было принято решение о модернизации системы, и первым шагом стала разработка архитектуры будущей информационной системы.
Проектирование ИС
Обоснование технологии проектирования
В настоящее время используется большое количество подходов, которые позволяют, создавать модели бизнес-процессов предприятий. Особенно выделяют: структурный (функциональный), объектно-ориентированный, отдельно выделяется методология ARIS. Описание каждого подхода и его нотаций описано в источнике [3].
При проектировании данной системы будет использоваться объектно-ориентированный подход. Это объясняется тем, что нотация данного подхода (UML) позволяет достаточно полно и наглядно описать предметную область и позволяет легко изменять проект (при изменении одного объекта или процесса не надо изменять все остальные, как, например, в структурном подходе). Также UML является достаточным для проектирования данной системы, следовательно, методология ARIS, включающая UML и другие методологии, будет избыточна.
Далее необходимо выбрать конкретный подход проектирования для рассматриваемой информационной системы. Выбор будет осуществляться среди следующих подходов:
1. Microsoft Solutions Framework.
2. Rapid Applications Development.
3. Extreme Programming.
Microsoft Solutions Framework - методология разработки программного обеспечения по эффективному проектированию, разработке, внедрению и сопровождению программных решений, которая состоит из принципов, моделей и дисциплин по управлению персоналом, процессами, технологическими элементами и связями между ними. Данный подход используется для создания крупных проектов и включает в себя такие направления деятельности как управление рисками, управление проектами и управление подготовкой.
Rapid Applications Development - концепция создания средств разработки программных продуктов, уделяющая особое внимание быстроте и удобству программирования, созданию технологического процесса, позволяющего программисту максимально быстро создавать компьютерные программы. RAD имеет три основных преимущества:
- высокая скорость разработки;
- низкая стоимость;
- высокое качество.
Последнее из указанных свойств подразумевает полное выполнение требований заказчика как функциональных, так и нефункциональных, с учетом их возможных изменений в период разработки системы.
Extreme Programming - методология организации разработки программного продукта в условиях неясных или быстро меняющихся требований. В XP разработка программного обеспечения производится средними группами работников, в которых каждый сотрудник должен быть высококвалифицированным. Риск разработки снижается только в команде, которой XP подходит идеально, во всех остальных случаях XP - это процесс разработки с наиболее высокой степенью риска, поскольку другие методы снижения коммерческих рисков, кроме человеческого фактора, в XP просто отсутствуют.
В результате анализа основных подходов к проектированию был выбран подход RAD, который является наиболее подходящим для проектирования рассматриваемого программного продукта.
Далее произведем выбор CASE-средств для проектирования. Существуют следующие средства для проектирования с помощью UML:
ѕ Visual Paradigm 6.1 Enterprise;
ѕ Rational Rose;
ѕ Borland Together;
ѕ ArgoUML;
ѕ Netbeans UML Plugin;
ѕ Eclipse Omondo Plugin;
ѕ Enterprise Architect.
Для выбора наиболее подходящего будут использоваться следующие критерии:
1. Возможность производить реверс кода.
2. Поддержка ОС Windows.
3. Стоимость приобретения.
4. Опыт успешного использования (отзывы).
5. Простота освоения и использования.
Все критерии кроме стоимостного оценивается следующими балами:
0 - не удовлетворят требованию
5 - частично удовлетворяет требованию
10 - полностью удовлетворяет требованию
Стоимостный критерий является наиболее важным, поэтому его баллы выше:
0 - высокая стоимость;
10 - средняя стоимость;
20 - бесплатно
Таблица 1 Исходные данные для выбора CASE-средства
|
Visual Paradigm 6.1 Enterprise |
Rational Rose |
Borland Together |
ArgoUML |
Netbeans UML Plugin |
Eclipse Omondo Plugin |
Enterprise Architect |
||
|
Возможность производить реверс кода |
10 |
0 |
0 |
10 |
0 |
10 |
10 |
|
|
Поддержка ОС Windows |
10 |
10 |
10 |
10 |
10 |
10 |
10 |
|
|
Стоимость приобретения |
20 |
0 |
10 |
20 |
20 |
10 |
10 |
|
|
Опыт успешного использования (отзывы) |
10 |
10 |
10 |
10 |
0 |
5 |
10 |
|
|
Простота освоения и использования |
10 |
5 |
10 |
10 |
10 |
5 |
10 |
|
|
ИТОГ: |
60 |
25 |
40 |
60 |
40 |
40 |
50 |
Анализ показал, что наиболее подходящие для проектирования CASE-средства это Visual Paradigm и Enterprise Architect. При проектировании будет использоваться Visual Paradigm, так как имеется опыт работы в данной программе.
Для проектирования системы будет использоваться методология RAD. Согласно этой методологии результатом фазы проектирования должны быть:
ѕ общая информационная модель системы;
ѕ функциональные модели системы в целом и подсистем, реализуемых отдельными командами разработчиков;
ѕ точно определенные с помощью CASE-средства интерфейсы между автономно разрабатываемыми подсистемами;
ѕ построенные прототипы экранов, отчетов, диалогов.
В итоге должна получиться схема базы данных, удовлетворяющая требованиям новой технологии и включающая все необходимые таблицы, для реализации заданного функционала.
Разработка модели ИС
Исходя из выбранного метода проектирования необходимо в определенной последовательности выполнить построение диаграмм, отражающих основные процессы, протекающие при использовании системы.
Первым шагом будет являться построение диаграммы вариантов использования, отображающей основные функции системы (Рисунок 4).
Рисунок 4 Диаграмма вариантов использования проектируемой АИС
После определения основных функций системы необходимо отразить последовательность действий при выполнении каждой из них.
Процесс получения данных с датчиков, сбор которых осуществляется внешней системой, представлен на следующей диаграмме последовательности (Рисунок 5).
Рисунок 5. Диаграмма последовательности процесса получения данных из внешней системы
Получение данных о процессе проведения испытания автомобиля представляет собой загрузку сведений о силах и моментах, действующих на определенные точки на кузове. Результат получения данных из внешней системы на форме пользовательского интерфейса проектируемой АИС представлен в Приложении 1 (Рисунок 10).
Следующим шагом будет рассмотрение функции непосредственного проведения расчета. Для преобразования сигнала необходимы следующие параметры:
1. Матрицы сил и моментов по всем осям (x, y и z) для всех точек крепления подвески автомобиля к кузову;
2. Матрица распределения масс на колеса автомобиля;
3. Тип подвески, который определяет количество точек и места их крепления к кузову.
Алгоритм работы программы при преобразовании представлен на следующей схеме:
Рисунок 6 Алгоритм преобразования сигнала в проектируемой АИС
При работе алгоритма первый цикл определяет количество точек крепления подвески к кузову, которое определяется типом подвески. Второй цикл определяет количество параметров для расчета у каждой точки. Таких параметров 6: 3 группы значений силы по осям и 3 группы значений момента по осям. Далее для каждого параметра определяются нормальные границы, по которым происходит нахождение 17 равноудаленных друг от друга точек на границах на все протяжении ряда значений (ряд значений представлен по отношению ко времени).
Следующим шагом является нахождение 17 средних значений нагрузки по всей точке в целом. После нахождения данных значений для всех точек происходит определение 17 значений нагрузки для всей модели в целом. Это осуществляется с помощью матрицы распределения массы на колеса автомобиля.
Завершающим этапом работы системы преобразования сигналов является экспорт полученных статических расчетных случаев в файлы, которые будут использоваться в расчетной программе на следующем этапе расчета долговечности кузова. Результаты расчетного процесса в системе преобразования сигнала на форме пользовательского интерфейса представлены в Приложении 1 (Рисунок 11).
Также необходимо определить диаграмму классов, которая показывает основные поля и методы классов, используемых в системе:
Рисунок 7. Диаграмма классов для проектируемой АИС
Диаграмма классов отображает классы, информация по которым используется в системе. Основные данные для дальнейшего расчета берутся из класса Sensor. Данный класс позволяет создать параметры, которые сможет передать датчик после проведения испытания.
Также для процесса преобразования входного сигнала необходимы данные о модели испытуемого автомобиля. Для этого также присутствует класс ModelAuto, который позволяет задать параметры по двум направлениям:
- тип подвески (SuspensionType);
- распределение массы на колеса автомобиля (DistributionMass).
Класс Reporting позволяет вывести информацию по датчику, либо по параметрам модели автомобиля в зависимости от отправляемого запроса.
Проектирование базы данных ИС
Инфологическое (концептуальное) проектирование
На основе моделирования предметной области были выявлены основные сущности проектируемой АИС. Опишем их взаимодействие с помощью нотации Чена на рисунке 8.
Рисунок 8. Общая инфологическая модель проектируемой системы
Основной сущностью является "Датчики". Через данную сущность взаимодействуют остальные сущности, а именно:
1. Расчетчик.
2. Внешняя система.
3. Параметр (является зависимой сущностью, то есть существует только вместе с сущностью "Датчик").
Связь сущностей "Датчик - Внешняя система" в соответствии с диаграммой вариантов использования, представленной на рисунке 4, описывает функцию внешней системы получать информацию с датчиков во время испытания автомобиля.
Связь сущностей "Внешняя система - Параметр" в соответствии с диаграммой вариантов использования, представленной на рисунке 4, описывает функцию внешней системы выделять из полученных сведений с датчиков и впоследствии сохранять параметры их текущей работы.
Связь сущностей "Расчетчик - Параметр" в соответствии с диаграммой вариантов использования, представленной на рисунке 4, описывает функцию получения оператором сведений по значениям параметров, запрошенного оборудования.
Каждая сущность имеет свой набор атрибутов, описывающих ее.
Расширенная инфологическая модель приведена в Приложении 2.
Обоснование логической модели БД
На сегодняшний день существует большое число разных видов моделей данных, обрабатываемых в информационной системе. На сегодняшний день основными моделями данных являются:
иерархическая модель - состоит из упорядоченного набора экземпляров в виде дерева без множественного наследования;
сетевая модель - состоит из упорядоченного набора экземпляров в виде дерева с множественным наследованием;
реляционная модель - состоит из отношений и элементов отношений (кортеж);
объектная модель - состоит из данных, оформленных в виде моделей объектов произвольного типа.
Оценивание будет выполняться по 3-бальной шкале, где наивысший бал будет означать удовлетворение вида модели выдвинутому критерию, а наименьший - не удовлетворение. Основными критериями будут являться:
простота физической реализации;
личный опыт работы с моделью;
"понятность" для пользователя.
Сведем сравнительный анализ моделей данных в таблицу.
Таблица 2 - критическая оценка моделей данных проектируемой АИС
|
Критерий оценки |
Иерархическая |
Сетевая |
Реляционная |
Объектная |
|
|
Простота физической реализации |
2 |
2 |
3 |
3 |
|
|
Личный опыт работы |
1 |
1 |
3 |
1 |
|
|
"Понятность" для пользователя |
3 |
3 |
2 |
1 |
|
|
ИТОГО |
6 |
6 |
8 |
5 |
В ходе проведенного сравнительного анализа мною была выбрана реляционная модель представления данных.
Для построения данной модели будет использоваться Erwin Data Modeler. Данное CASE-средство удовлетворяет следующим требованиям:
возможность генерирования физической модели БД на основе имеющейся логической модели;
бесплатное распространение программного продукта;
личный опыт работы с программным продуктом.
Наконец, определив тип модели данных, а также CASE-средство, с помощью которого данная модель будет реализовываться, можно приступить к построению самой модели БД.
Построение логической модели БД
В пункте 3.1 были определены следующие сущности модели данных информационной системы:
1. Датчик;
2. Расчетчик;
3. Внешняя система;
4. Параметр.
Кроме этого в данном пункте был определен набор основных атрибутов данных сущностей.
Каждая сущность имеет свой уникальный идентификатор, который позволяет получить доступ к любой произвольной записи таблицы. Данный идентификатор является первичным ключом (простой ключ) для соответствующей сущности.
Каждая сущность имеет связи с другими сущностями, при этом каждая связь имеет свои свойства, например "Датчик - параметр" - один ко многим.
На основе данной информации становится возможным произвести построение логической модели проектируемой АИС с использованием CASE-средства, определенного в пункте 3.2.
Рисунок 9. Логическая модель информационной системы
Заключение
В данном курсовом проекте был рассмотрен отдел математического моделирования и расчетов научно-технического центра ОАО "АвтоВАЗ".
В ходе анализа предметной области был рассмотрен текущий процесс расчета долговечности кузова и выявлены основные недостатки, на основе которых было принято решение о проектировании собственной АИС. Затем был рассмотрен предлагаемый вариант данного процесса и выделена задача на проектирование. Далее были определены требования к проектируемой системе, выбраны CASE-средства, с помощью которых будет осуществлен процесс ее проектирования и разработки.
После этого были смоделированы UML-диаграммы, описывающие бизнес процессы, а также диаграмма классов, на основе которой были определены основные сущности системы, их атрибуты. Для их визуального отображения была использована нотация Чена.
Также были рассмотрены основные функции системы и описаны алгоритмы их действия. Результаты работы основных функций были отображены на формах пользовательского интерфейса приложения.
Наконец, было проведено описание сущностей системы, свойства их связей, нормализация, а также наличие первичных, вторичных, что позволило построить логическую модель БД проектируемой информационной системы.
Список использованной литературы
1. Орлов С.А. Технологии разработки программного обеспечения: Учебник / С. Орлов - СПб.: Питер, 2002. - 464 с.: ил.
2. Лешек А. Мацяшек. Разработка ИС с использованием UML / Мацяшек Лешек А. - М.: Вильямс, 2002. - 432 с.
3. Хетагуров Я.А. Проектирование АСОиУ / Я.А. Хетагуров - М.: Высшая школа, 2006. - 224 с.
4. Вязовик Н.А. Программирование на Java: Учебный курс. / Н.А. Вязовик - М.: Craftway Computers, 2003. - 592с.
5. Дейтел Х.М. Технологии программирования на Java 2, корпоративные системы, сервлеты, JSP, Web-сервисы: Учебный курс. / Х.М. Дейтел - М.: Бином-пресс, 2003. - 672с.: ил.
6. Кузнецов С.Д. Базы данных. Модели и языки: Учебный курс. / С.Д. Кузнецов - М.: Бином-пресс, 2008. - 692с.
Приложение 1
Рисунок 10. Основная форма приложения с отображением загруженных данных
Рисунок 11. Форма просмотра результатов выполнения преобразования
Приложение 2
Рисунок 12 Расширенная инфологическая модель проектируемой системы.
Размещено на Allbest.ru
Подобные документы
Разработка информационно-логической модели проектируемой информационной системы. Алгоритм функционирования информационной системы. Описание базы данных. Описание входной, промежуточной и выходной информации. Техническое и программное обеспечение.
реферат [28,1 K], добавлен 09.01.2009Варианты использования информационной системы: заказ билета, просмотр каталога фильмов и списка кинотеатров. Проектирование реляционной модели базы данных, ее мапирование в метамодель, логическая и физическая реализация. Результаты работы программы.
курсовая работа [673,9 K], добавлен 20.11.2011Проектирование модели информационной системы "Склад" с помощью AllFusion Process Modeler 4.1 (Bpwin4.1). Диаграмма дерева узлов AS-TO-BE и AS-IS. ER-диаграмма потоков данных "Сущность-связь". Физическо-логическая модель базы данных в нотации IDEF1X.
курсовая работа [2,4 M], добавлен 25.06.2014Проблемы, связанные с отсутствием информационной системы. Проектирование логической схемы данных для выбранной предметной области на основе методологии IDEF1X. Разработка информационной системы с использованием MS SQL Server 2008 и MS Visual Studio 2010.
курсовая работа [3,0 M], добавлен 07.08.2013Технические средства обеспечения функционирования информационной системы. Проектирование базы данных информационной системы. Разработка веб-приложения – справочно-информационной системы для предприятия. Организация записи информации в базу данных.
дипломная работа [4,4 M], добавлен 16.05.2022Проектирование информационной системы программными средствами AllFusion Process Modeler и AllFusion Erwin Data Modeler. Диаграмма потоков данных DFD. Проектирование информационной системы с использованием UML, RationalRose. Модель вариантов использования.
курсовая работа [604,1 K], добавлен 17.12.2015Создание информационной системы для автоматизации проведения анкетирования среди студентов и преподавателей учебных заведений. Требования к структуре и функционированию системы, программному обеспечению. Проектирование логической модели базы данных.
курсовая работа [2,4 M], добавлен 08.03.2016Анализ предметной области. Логическая и физическая модели информационной системы. Средства реализации диаграмм потоков данных. Заполнение форм ввода. Проверка регистрационных данных, работа с форумом. Требования к функционированию компонентов системы.
курсовая работа [2,3 M], добавлен 14.01.2018Анализ предметной области. Разработка генетического алгоритма для оптимизации инвестиций. Спецификация требований и прецедентов. Проектирование пользовательского интерфейса информационной системы. Модели данных, используемые в системе и их взаимодействие.
дипломная работа [2,1 M], добавлен 24.08.2017Исследование методов и способов разработки информационных систем. Автоматизация деятельности продовольственного магазина. Проектирование логической схемы информационной системы. Разработка модели базы данных и структуры вычислительно-локальной сети.
курсовая работа [389,2 K], добавлен 16.03.2017
