Дипломная работа: Анализ информационной системы автосалона "Питер-Лада" и улучшение ее при помощи СУБД MySQL, PHP и HTML
На диаграмме состояний может быть одно и только одно начальное состояние. В то же время может быть столько конечных состояний, сколько вам нужно, или их может не быть вообще. Когда объект находится в каком-то конкретном состоянии, могут выполняться различные процессы.
Процессы, происходящие в этот момент, когда объект находится в определенном состоянии, называются действиями (actions).
С состоянием можно связывать следующие данные: деятельность, входное действие, выходное действие и событие.
Деятельность (activity) - это поведение, реализуемое объектом, пока он находится в данном состоянии. Деятельность изображают внутри самого состояния; ее обозначению должно предшествовать слово do (делать) и двоеточие.
Входное действие (entry action) - это поведение, которое выполняется, когда объект переходит в данное состояние. Входное действие также показывают внутри состояния, его обозначению предшествуют слово entry (вход) и двоеточие.
Выходное действие (exit action) подобно входному. Однако оно осуществляется как составная часть процесса выхода из данного состояния. Выходное действие изображают внутри состояния, его описанию предшествуют слово exit (выход) и двоеточие.
Переходом (transition) называется перемещение объекта из одного состояния в другое. На диаграмме все переходы изображают в виде стрелки, начинающейся на первоначальном состоянии и заканчивающейся последующим.
Переходы могут быть рефлексивными. Объект может перейти в то же состояние, в котором он в настоящий момент находится. Рефлексивные переходы изображают в виде стрелки, начинающейся и завершающейся на одном и том же состоянии. [1]
1.6.3 Диаграмма деятельности
Диаграммы активности (деятельности) частный случай диаграмм состояний. Каждое состояние есть выполнение некоторой операции и переход в следующее состояние. Диаграммы деятельности особенно полезны в описании поведения, включающего большое количество параллельных процессов. Самым большим достоинством диаграмм деятельностей является поддержка параллелизма. Благодаря этому они являются мощным средством моделирования потоков работ и, по существу, параллельного программирования. Самый большой их недостаток заключается в том, что связи между действиями и объектами просматриваются не слишком четко.
Средства Rational Rose позволяют для описания функциональной системы воспользоваться графическим редактором для построения Activity диаграмм (деятельности).
Таб. 1.3. Условные обозначения диаграммы деятельности
| Условное обозначение | Описание условного обозначения |
|
|
начальное состояние, не содержит никаких внутренних действий, в этом состоянии находится объект по умолчанию в начальный момент времени |
|
|
конечное состояние, которое также не содержит никаких внутренних действий. В этом состоянии будет находиться по умолчанию после завершения работы в конечный момент времени. Оно служит для указания графической области, в которой завершается процесс изменения состояния |
|
|
состояние действий с некоторым входным действием и, по крайней мере, одним выходящим из состояния перехода. Внутри этой фигурки записывается выражение действий, которое должно быть уникальным в пределах одной диаграммы деятельности |
|
|
ветвление, применяемое в случаях, когда последовательно выполняемая деятельность должна разделиться на альтернативные ветви в зависимости от значения некоторого промежуточного результата. В этот ромб может входить только одна стрелка от того состояния, после выполнения которого, поток управления должен быть продолжен по одной из взаимно исключающих ветвей. Выходящих стрелок может быть две или более, но для каждой из них явно указывается соответствующее условие |
|
|
переход, т. е. отношение между двумя последовательными состояниями, которое указывает на факт смены одного состояния другим |
|
|
распараллеливание вычислений. Может иметь один входящий переход и несколько выходящих, либо несколько входящих и один выходящий |
Диаграммы деятельностей предпочтительнее использовать в следующих ситуациях:
· анализ варианта использования. На этой стадии нас не интересует связь между действиями и объектами, а нужно только понять, какие действия должны иметь место и каковы зависимости в поведении системы. Связывание методов и объектов выполняется позднее с помощью диаграмм взаимодействия;
· анализ потоков работ (workflow) в различных вариантах использования. Когда варианты использования взаимодействуют друг с другом, диаграммы деятельностей являются мощным средством представления и анализа их поведения. [6]
1.6.4 Диаграммы взаимодействия
Диаграммы взаимодействия (interaction diagrams) описывают поведение взаимодействующих групп объектов. Каждая диаграмма описывает поведение объектов в рамках только одного прецедента. На диаграмме изображаются объекты и те сообщения, которыми они обмениваются между собой. Определяют три типа сообщений:
информационные (informative) – сообщения, снабжающие объект-получатель информацией для обновления его состояния;
сообщения – запросы (interrogative) – сообщения, запрашивающие выдачу информации об объекте-получателе;
императивные (imperative) – сообщения, запрашивающие у объекта-получателя выполнение действия.
Существует два вида диаграмм взаимодействия:
1. последовательности (sequence diagrams);
2. кооперативные (collaboration diagrams).
На диаграмме последовательности объект изображается в виде прямоугольника на вершине пунктирной вертикальной линии. Эта вертикальная линия называется линией жизни (lifeline) объекта. Она представляет собой фрагмент жизненного цикла объекта в процессе взаимодействия.
Каждое сообщение изображается в виде стрелки между линиями жизни двух объектов. Сообщения появляются в том порядке, как они показаны на странице, сверху вниз. Каждое сообщение помечается как минимум именем сообщения; при желании можно добавить также аргументы и некоторую управляющую информацию и, кроме того, показать самоделегирование (self-delegation) -сообщение, которое объект посылает самому себе, при этом стрелка сообщения указывает на ту же самую линию жизни.
Рис. 1.5. Диаграмма последовательности «заказ дополнительного оборудования»
Вторым видом диаграммы взаимодействия является кооперативная диаграмма. Подобно диаграммам последовательности, кооперативные диаграммы отображают поток событий через конкретный сценарий варианта использования. Диаграммы последовательности упорядочены по времени, а кооперативные диаграммы заостряют внимание на связях между объектами.
Рис. 1.6. Диаграмма кооперации «заказ дополнительного оборудования»
Как видно из рисунка, здесь представлена вся та информация, которая была и на диаграмме последовательности, но кооперативная диаграмма по-другому описывает поток событий. Из нее легче понять связи между объектами, однако труднее уяснить последовательность событий.
По этой причине часто для какого-либо сценария создают диаграммы обоих типов. Хотя они служат одной и той же цели и содержат одну и ту же информацию, но представляют ее с разных точек зрения.
На кооперативной диаграмме, так же как и на диаграмме последовательности, стрелки обозначают сообщения, обмен которыми осуществляется в рамках данного варианта использования.
1.7 Вывод по главе 1
По результатам предпроектного исследования, делается вывод о необходимости модификации существующей информационной системы учета автосалона «Питер-Лада». В качестве средства построения логической модели был выбран язык UML.
2. Проектирование автоматизированной информационной системы
2.1 Требования, предъявляемые к информационной системе
Целю данной дипломной работы является построение автоматизированной информационно системы для упрощения условий труда сотрудников автосалона «Питер-Лада». Проектируемая база данных является удобным средством решения перечисленных в предыдущей главе проблем и задач. Работа с данной базой данных не требует никакой специальной подготовки пользователей, благодаря удобному дружественному интерфейсу, а так же благодаря тому, что при авторизации пользователя (будь то менеджер, или руководитель СТО), последнему для работы предоставляется только та область базы данных, требуемая для выполнения служебных обязанностей. Например при работе с базой данных руководителя СТО, ему не требуется информация об автомобилях находящихся в наличии на складе автосалона, в то время как менеджмент компании не интересуют данные о автомобилях поступающих в рем-зону. Таким образом, при авторизации в данной базе данных, пользователю предоставляется минимально необходимый для работы набор данных, что позволяет избежать лишней путаницы и максимально упрощает пользовательский интерфейс.
База данных может быть организована различными способами, но она должна удовлетворять следующим требованиям:
ü Минимальная избыточность. Данные, хранимые в БД, могут содержать как "полезную", так и "вредную" избыточность. Последняя всегда имеет место при отсутствии концептуального представления данных, когда каждый пользователь создает для своих приложений отдельный набор данных. В этом случае, если нескольким пользователям требуются одни и те же данные, то они должны быть повторены в каждом наборе. Такая избыточность является неконтролируемой, поскольку, о ее существовании пользователи могут и не подозревать. Интеграция пользовательских представлений в единое концептуальное представление, как правило, устраняет эту избыточность данных. К "полезной" избыточности можно отнести периодические копии данных, хранящихся в БД. Эта избыточность легко контролируется. Более того, она является необходимой, например, для восстановления данных, разрушенных при случайных сбоях и непредвиденных ситуациях.
Таким образом, требование минимальной избыточности следует понимать как устранение "вредной"" (неконтролируемой) и сведение к минимуму "полезной" (контролируемой) избыточности данных;
ü Целостность данных. Означает, что в базе данных установлены и корректно поддерживаются взаимосвязи между записями разных таблиц при загрузке, добавлении и удалении записей в связанных таблицах, а также при изменении значений ключевых полей;
ü Независимость данных. Подразумевает возможность изменения структуры БД без изменения прикладных программ пользователей. Понимается в двух аспектах, а именно, как логическая и физическая независимость.
Логическая независимость предполагает возможность изменения концептуальной схемы БД без изменения прикладных программ пользователей.
Физическая независимость подразумевает возможность изменения способа размещения данных на физических носителях и (или) методов доступа к данным без изменения прикладных программ пользователей.
ü Производительность. Характеризуется временем ответа на запросы пользователей.
ü Гибкость и способность к расширению. Понимается как способность БД к наращиванию данных, а также увеличению количества возможных приложений и расширению функций в пределах каждого приложения.
2.2 Проектирование базы данных в Rational Rose Data Modeler
При создании программных систем процесс создания структуры данных (модели) является одним из важнейших этапов. Однако до недавнего времени аналитики-проектировщики, работающие с Rational Rose, должны были обращаться к другим CASE-средствам для автоматизации этого процесса, например, к ERwin компании PLATINUM. С появлением подключаемого модуля (Add-In) под названием Data Modeler у разработчиков появилась возможность не отказываться от своего любимого инструмента и использовать Rational Rose не только для создания логического представления системы, но и для моделирования физического представления данных.
Авторы Data Modeler прежде всего ориентировались на создание инструмента проектирования физической модели данных. При этом не произошло отказа от UML как от средства моделирования данных, а некоторым образом были смещены акценты: теперь UML предполагается использовать для построения логической модели. По сути, логическая модель - это та же объектная модель, состоящая из объектов - сущностей. Переход от логической модели к физической и наоборот в части моделирования данных обеспечивается Rational Rose автоматически. Для этого введено соответствие элементов моделей, приведенное в таблице 2.1.:
Таб. 2.1. Соответствие логической и физической модели
Стоит заметить, что для специфических элементов физической модели - триггеров и индексов - не нашлось достойного аналога UML, но в общем-то это не проблема.
Таким образом, концептуально модуль Data Modeler не является заменой UML в некотором его подмножестве, а всего лишь дает приверженцам объектных технологий мощное средство эффективного построения физических схем БД. Результатом работы Data Modeler будет являться построение диаграммы «сущность – связь» и последующая генерация описания базы данных на SQL. [6]
Подводя итог, к основным особенностям Data Modeler стоит отнести:
o Data Modeler поддерживает большинство возможностей структурных CASE-средств в плане физического моделирования данных;
o Data Modeler обеспечивает генерацию эффективной физической структуры БД, поддерживающей механизмы обеспечения ссылочной целостности;
o Data Modeler тесно интегрирован с Rational Rose, а диаграмма Data Model естественным образом вписывается в общую технологию разработки ПО с использованием линейки продуктов фирмы Rational Software Corporation;
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11
