Разработка информационной системы на примере студенческого общежитии

Автор: Пользователь скрыл имя, 16 Ноября 2011 в 02:05, курсовая работа

Описание работы

Целью данной курсовой работы является разработка модели автоматизированной системы «Общежитие», в которой требуется выполнить моделирование предметной области студенческого общежития, используя язык UML, подготовить техническую документацию для разработки программного продукта.
Объектом данной курсовой работы является студенческое общежитие г. Покров.

Содержание

Введение 3
Глава 1. Проектирование информационной системы 4
1.1 Построение UML-диаграмм 4
1.1.1 Диаграмма прецедентов 15
1.1.2 Диаграмма классов 16
1.1.3 Диаграмма видов деятельности 18
1.1.4 Диаграммы состояний 20
1.1.5 Диаграмма последовательностей 21
1.1.6 Диаграмма пакетов 23
1.1.7 Диаграмма компонентов и развертывания 24
1.2 Структура базы данных 25
Глава 2. Технико-экономическое обоснование проекта 28
2.1 Расчет стоимости разработки системы автоматизации 29
2.2 Расчет стоимости выполнения процесса до автоматизации 34
2.3 Расчет стоимости выполнения процесса после автоматизации 37
2.4 Расчет экономического эффекта 41
Заключение 43
Список используемой литературы 44
Приложение 45

Работа содержит 1 файл

курсовая маше.doc

— 1.11 Мб (Скачать)

    1. Правила проживания;

    2. НПА

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

    - Администратор;

    - Комендант;

    - Вахтер;

    - Проживающий.

     После формирования контекста системы  производится построение иерархии диаграмм, при этом дочерняя диаграмма содержит более подробное описание по сравнению  с родительской диаграммой. В результате декомпозиции функционального блока контекстной диаграммы получен набор функций, являющихся субпроцессами моделируемого процесса. Диаграмма А0 состоит из шести блоков – по одному для каждого субпроцесса (рис. 3).

Рис. 3 IDEF0-диаграмма «Управлять заселением и проживанием в общежитии» («как есть»)

      Исходя  из описания данного бизнес-процесса можно выделить следующие блоки:

    1. Ввести данные;

    2. Зарегистрировать студента;

    3. Определить комнату;

    4. Совершить выписку студента.

     В то же время субпроцесс «Зарегистрировать студента» имеет в свою очередь свое разделение на субпроцессы. Диаграмма IDEF0 данного субпроцесса состоит из четырех блоков (рис. 4):

    1. Проверить данные;

    2. Оформить договор;

    3. Проверить информацию о состоянии здоровья;

    4. Выдать квитанцию.

Рис. 4 IDEF0-диаграмма «Зарегистрировать студента» («как есть»)

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

      В отличие от IDEF0, где система рассматривается  как взаимосвязанные работы, DFD рассматривает систему как совокупность предметов. Контекстная диаграмма часто включает работы и внешние ссылки. Работы обычно именуются по названию системы. Включение внешних ссылок в контекстную диаграмму не отменяет требования методологии четко определить цель, область и единую точку зрения на моделируемую систему.

      Используемая  в нашей системе DFD-модель по управлению заселением и проживанием в общежитии, представлена на рисунке 5.

Рис. 5 DFD-модель управления заселением и проживанием в общежитии

      На  диаграмме показаны следующие процессы: проверка и внесение данных о студентах, комнатах в общежитии, а также внесение этой информации в базу данных.

      Сущностями в данной модели являются: Заселение студента и Выселение студента.

      Накопители: Данные о студенте в БД, Данные о комнатах в БД и Правила проживания.

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

      Используемые  в диаграмме двунаправленные стрелки между работами, между работой и внешней сущностью и между внешними сущностями (между процессами и накопителями) применяются для описания диалогов типа «команда-ответ».

 

      1.1.1 Диаграмма прецедентов

      Диаграмма прецедентов является исходным концептуальным представлением или концептуальной моделью системы в процессе ее проектирования и разработки.

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

Диаграмма прецедентов представлена на рисунке  6:

Рис. 6 Диаграмма прецедентов

 

       Субъектами (паспортист, комендант, вахтер) в данном случае выступают: студент. Прецедентами являются: Занести студента в БД, Предоставить прописку и место жительства, Установить оплату, Посмотреть свободные места.

      1.1.2 Диаграмма классов

      Диаграмма классов (class diagram) служит для представления статистической структуры модели системы в терминологии классов объектно-ориентированного программирования. Диаграмма классов может отражать, в частности, различные отношения между отдельными сущностями предметной области.

      Диаграмма классов для управления заселением и проживанием в общежитии выглядит следующим образом:

Рис. 7 Диаграмма классов 

      Объекты, отраженные в диаграмме классов  объектов, связаны статистическими  отношениями, которые отражают постоянные связи между объектами. К статистическим отношениям относятся:

    - зависимости (dependency relationship);

    - ассоциации (association relationship);

    - обобщения (generalization relationship) .

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

     Отношение зависимости графически изображается пунктирной линией между соответствующими элементами со стрелкой, направленной от класса-клиента зависимости к независимому классу или классу-источнику.

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

      В прямоугольниках в верхней части  даны имена классов объектов, в средней части – имена атрибутов, в нижней части – имена методов.

      Отношения между сущностями различаются по следующим типам:

 один  к одному(1:1) – это когда один  экземпляр первого объекта может  соответствовать только одному  экземпляру второго объекта;

один  ко многим (1:n) – это когда один экземпляр первого объекта может соответствовать более чем одному экземпляру второго объекта;

 многие к  одному (n:1) – это когда более чем один экземпляр первого объекта может соответствовать только одному экземпляру второго объекта.

     Диаграмма классов дает обобщенное визуальное представление обо всех элементах  модели классов.

      1.1.3 Диаграмма видов деятельности

     Диаграмма видов деятельности (activity diagram) отражает динамику системы и особенно полезна при описании поведения, включающего в себя большое количество параллельных процессов, а также для моделирования поведения системы в самом общем виде на этапе анализа (рис. 8).

      Рис. 8 Диаграмма видов деятельности

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

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

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

      Действия, показанные на модели, можно сгруппировать в разделы. Можно выделить три раздела: «Студент», «Деканат», «Комендант», «Паспортист».

Рис. 9 Диаграмма видов деятельности (с разделами)

      1.1.4 Диаграммы состояний

      Диаграмма состояний (рис. 10) отображает поведение объектов класса «Размещение» в динамике, связь состояний объектов с событиями определяет:

- типичные  состояния, которые проходит объект;

- события,  которые ведут к состоянию  объекта;

- действия, выполняемые объектом после получения  сообщения об изменении состояние;

- входные  и выходные точки диаграммы.

      Рис. 10 Диаграмма состояний класса «Размещение»

      Также с помощью диаграммы состояний  можно показать состояние класса «Поиск помещения» (рис. 11):

      Рис. 11 Диаграмма состояний класса «Поиск помещения»

      1.1.5 Диаграмма последовательностей

      Диаграмма последовательностей отражает поток событий, происходящих при реализации прецедента «Занесение студента в БД общежития» (рис. 12).

Рис. 12 Диаграмма последовательностей прецедента «Занесение студента в БД общежития»

      Также можно проследить и поток событий происходящих при реализации прецедента «Занесение студента в БД общежития» (рис. 13).

Рис. 13 Диаграмма последовательностей прецедента «Поиск свободного места»

         От каждого объекта вниз отходит штриховая линия, называемая линией жизни (Lifeline) объекта. На ней показано все, что происходит с объектом с момента его создания и до разрушения.

      Сообщения, передающиеся от одного объекта к  другому, представляются стрелками  между линиями жизни этих объектов. Порядок следования сообщений устанавливается сверху вниз.

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

      1.1.6 Диаграмма пакетов

      Пакетная  технология группирования классов  объектов позволяет упростить:

    1. разработку и эксплуатацию ИС;

  1. гибкую адаптацию типовых компонентов с позиции их повторного использования;
  2. оптимизацию клиент-серверной архитектуры ИС.

      Обыч но информационная система разбивается на функциональные и обеспечивающие  пакеты (рис.14).  Функциональные  пакеты, соответствующие решаемым проблемам (задачам), объединяются в общий пакет «Проблемная область». «Проблемная область» данной диаграммы содержит пакеты: «Список студентов», «Список свободных мест» и «Заселение». В свою очередь в нашем случае также присутствует пакет «Пользовательский интерфейс», включающий пакет «Регистрации пользователя», и отдельные связанные между собою пакеты: «Платформа», «Интерфейс БД» и «Access».

Информация о работе Разработка информационной системы на примере студенческого общежитии