образец общежитие. Проектирование информационной системы
 Скачать 63.39 Kb.
|
|
Введение Данная работа ориентирована на разработку автоматизированной системы, предназначенной для автоматизации операций в студенческом общежитии, предназначенной для организации регистрации, заселения и выселения студентов, соответствующего данным процессам документооборота, а также обработки произведенной студентами оплаты. Целью данной курсовой работы является разработка модели автоматизированной системы «Общежитие», в которой требуется выполнить моделирование предметной области студенческого общежития, используя язык UML, подготовить техническую документацию для разработки программного продукта. Объектом данной курсовой работы является студенческое общежитие г. Покров. Предметом исследования является система учета информации о проживающих в студенческом общежитии, о начисление платежей за проживанию. В соответствии с поставленной целью в работе решаются следующие задачи: - анализ предметной области; - создание UML-проекта информационной системы с использованием CASE-средств; - проектирование базы данных; - обоснование экономической целесообразности внедрения разрабатываемой информационной системы. Глава 1. Проектирование информационной системы 1.1 Построение UML-диаграмм Разрабатываемая нами автоматизированная система «Общежитие» предполагает автоматизацию следующих процедур: Процесс поселения - подача заявки, формирование договора, формирование проекта приказа, подписание приказа, распределение по комнатам; Процесс выселения; Процесс переселения в другое помещение; Процесс начисления оплаты за проживание - начисление оплаты и печать памятки для оплаты; Процесс приема платежей; Функции анализа - поиск свободных мест, поиск свободных помещений, поиск задолженностей по оплате, формирование оборотных ведомостей. Система «Общежитие» обеспечивает поддержку и бухгалтерского сопровождения производимых процессов. Бухгалтерия по «Общежитию» подразумевает: - составление договора на поселение (договоры бывают типовые и льготные); - выполнение начислений; - формирование памятки для оплаты; - импорт платежей за проживание из системы бухгалтерского учета внесение информации о платежах за общежитие; - контроль платежей за проживание внесение, удаление, редактирование информации о платежах за проживание в общежитии; - формирование расходных ордеров на возврат денежных средств; - формирование оборотной ведомости по оплате за проживание в общежитии; - предоставление информации по задолженности. Работа с проживающими в автоматизированной системе «Общежитие» подразумевает следующие моменты: - формирование приказов на поселение и выселение; - установление комфортности помещений, состояния (ремонт/требует ремонта/нормальное); - установление вместимости (максимального числа проживающих); - управление заселением, переселением, выселением проведение операций по поселению, переселению, выселению студентов из общежития; - осмотр анкетных данных проживающих в общежитии; - подготовка документов для обеспечения деятельности комендатуры, бухгалтерии, службы охраны в общежитии обеспечивать формирование и вывод в MS Excel или MS Word документов установленного образца; - предоставление актуальной информации о проживании в общежитии и задолженности по оплате за общежитие формирование отчетных данных о проживающих в общежитии, задолженностях, свободных и занятых местах; - ведение журнала (истории) проживания и внесения платежей просмотр записей в журнале проживания; - разграничение прав доступа для различных категорий пользователей системы; - система назначения прав работы в КПО «Общежитие-2003» на основе системы прав доступа. Разрабатываемое нами программное обеспечение «Общежитие» предполагает выполнение следующих функции: прием заявления на поселение; заключение договоров на предоставление места в общежитие а); типовые договора; б); договора со льготами заключение договоров на проживание в общежитиях ВГУЭС, занесение информации о договоре в корпоративную базу данных, печать договоров; назначение оплаты за проживание определение и указание размера сумм, которые должен заплатить проживающий за указанный период (формируется из установленной платы за комфортность, с учетом льгот, и полученных платежей); импорт платежей за проживание из системы бухгалтерского учета импорт информации о платежах за проживание в общежитии из системы бухгалтерского учета «Интегратор» в корпоративную базу данных; переселение в другую комнату реализовать перевод проживающего из комнаты в комнату, при этом должна сохраняться вся информация о проживании студента в предыдущей комнате (должен вестись «журнал проживания»); выбор проживающих по набору условий выполнять операцию выбора проживающих по критериям: номер общежития, этаж, учебные группы, имеющие долг по проживанию, имеющие резерв по оплате (для сужения круга видимых оператору записей, что увеличит удобство использования); ведение справочников системы просмотр и редактирование таблиц, используемых в системе в соответствии с правами пользователей. Таблицы, предназначенные для заполнения другим ПО, не редактируются; просмотр анкетных данных формирование личной карточки проживающего на основании сведений из корпоративных БД;. просмотр сведений о состоянии оплаты и о проживании формирование отчетов по дебету, кредиту, размеру оплаты, даты внесения платежей для выбранных студентов; формирование отчетов по студентам с указанием комнаты проживания, общежития, даты поселения, уровнем комфорта комнаты; просмотр истории оплаты и проживания формирование отчетных документов, содержащих информацию об истории проживания и оплаты за любой период времени; просмотр состояния жилищного фонда формирование отчетных документов, содержащих информацию о текущем состоянии жилищного фонда: вакантные и занятые комнаты. Разрабатываемая нами система также позволяет формировать следующие печатные документы: заявление о поселении. Если заявление пишет студент, то он заходит под своим логином/паролем и основные данные уже берутся из базы данных. Если заявление пишет сотрудник, то тоже самое. Если заявление пишет абитуриент, то ему следует выбрать себя из абитуриентов, ввести свой номер документа (для идентификации). Иностранные студенты - если они есть в базе данных, то им следует зарегистрироваться и далее по схеме. Если их нет, то они относятся к прочим лицам. Прочие лица - те, которых нет ни в какой базе данных. Для них создается отдельная база и поэтому заявление должно содержать подробные данные человека. договор о взаимной ответственности (договор на проживание) подписывается обеими сторонами и служит документом, дающим право на проживание в общежитии ВГУЭС. памятка для оплаты в кассу выдается проживающему в общежитии или написавшему заявление, заключившему договор перед поселением; содержит сумму, которую проживающий или желающий проживать должен оплатить за проживание; памятка содержит указание (шифр) договора. расходный кассовый ордер выдается проживающему, служит основанием для выдачи ему денежных средств из кассы (возврат оплаты за проживание). оборотная ведомость. личная карточка студента сводные данные о проживающем в общежитии, могут быть занесены данные о родственниках. приказы на: поселение, переселение, выселение служат для утверждения списков поселяющихся, выселяющихся и переселяющихся в общежитии ВГУЭС. аналитические: - свободные и занятые комнаты; - история проживания студента (по комнатам); - задолженность по оплате; сводные данные по заселению студентов Предметной областью реализуемой задачи является такая информационная сущность как студенческое общежитие, включающая в себя информационные потоки о студентах, комнатах и соответствующих этим процессам документах. На рисунке 1 представлена организационная структура исследуемого нами студенческого общежития. Рис. 1 Организационная структура общежития Основным субъектом в организационной структуре студенческого общежития является комендант. Он осуществляет контроль над студентами, проживающими в общежитии, отслеживает процессы, связанные с их поселением и выселением, а так же следит за исполнением их обязанностей и условий, указанных в договоре, посредством связи со студентами через педагогический персонал. Остальной же персонал (обслуживающий), так же находиться в подчинении у коменданта, следит за порядком в самом общежитии, работой всех технических и прочих средств, и проводит регистрацию студентов. Показать, как осуществляется управление за заселением и проживанием студентов в общежитии можно с помощью наглядного графического языка IDEF0. Модель «как есть» («ai-is») позволяет понять, как функционирует данная система, а также выявить ряд ошибок и сформулировать ряд предложений по улучшению работы данного ресурса. Первая диаграмма в иерархии диаграмм IDEF0 всегда изображает систему в целом. Она представляет собой общее описание бизнес-процесса и называется – контекстной. В качестве вершины древовидной структуры будет служить функция – «Управлять заселением и проживанием в общежитии» (рис. 2). Входы и выходы контекстной диаграммы являются границами бизнес-процесса. Определив название главного функционального блока диаграммы, необходимо описать объекты, которые использует и преобразует функция. Рис. 2 Контекстная диаграмма бизнес-процесса «Управлять заселением и проживанием в общежитии» («как есть») Результаты выполнения процесса, которые в свою очередь являются выходами контекстного блока, перечислены ниже: - Выселенный студент; - Студент, не нуждающийся в проживании. Выходы функции являются результатом преобразования входных объектов. Входными данными для процесса закупок являются: - Студент на заселение; Для выполнения процесса необходима информация, которая будет управлять выполнением функции (работы). В качестве управляющей информации могут быть правила, стратегии, процедуры или стандарты, которыми руководствуется работа, а также законы утвержденные законодательством Российской Федерации. Процессом управления заселением и проживанием в общежитии управляет также следующая информация: 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. разработку и эксплуатацию ИС; гибкую адаптацию типовых компонентов с позиции их повторного использования; оптимизацию клиент-серверной архитектуры ИС. Обыч но информационная система разбивается на функциональные и обеспечивающие пакеты (рис.14). Функциональные пакеты, соответствующие решаемым проблемам (задачам), объединяются в общий пакет «Проблемная область». «Проблемная область» данной диаграммы содержит пакеты: «Список студентов», «Список свободных мест» и «Заселение». В свою очередь в нашем случае также присутствует пакет «Пользовательский интерфейс», включающий пакет «Регистрации пользователя», и отдельные связанные между собою пакеты: «Платформа», «Интерфейс БД» и «Access». 1.1.7 Диаграмма компонентов и развертывания Диаграмма компонентов отображает зависимости программных компонентов, которые представляются в виде исходных, откомпилированных и исполняемых программных кодов объектов. Один компонент, как правило, соответствует программному коду одного пакета классов объектов. Компонент в своем составе имеет интерфейсный класс объектов, через который осуществляется доступ к остальным классам объектов компонента. На рисунке 15 интерфейс обозначен кружком, присоединенным к пиктограмме компонента. С помощью интерфейса объекты других компонентов обращаются не к конкретным объектам рассматриваемого компонента, а к его интерфейсному объекту. Таким образом, упрощается взаимодействие компонентов между собой, когда при доступе к компоненту их других компонентов не требуется знать внутреннюю структуру этого компонента. Рис. 15 Диаграмма компонентов и развертывания В модели развертывания отображается топология расположения компонентов по узлам вычислительной сети. Отдельный компонент всегда располагается на одном компьютере-сервере. На одном компьютере-сервере может располагаться несколько компонентов. 1.2 Структура базы данных (Скрипт для данной структуры БД представлен в приложении 1.) База данных для организации и контроля заселения и проживания студентов в общежитии, спроектирована с помощью программного средства ERwin Data Modeler. ERwin Data Modeler реализует стандартную методологию моделирования данных и генерирует описание БД для таких СУБД, как Oracle, Informix, Ingres, Sybase, DB/2, Microsoft SQL Server, Borland Interbase и др. При проектировании логической модели данных с помощью вышеуказанного продукта она будет иметь следующий вид (рис. 16): Рис. 16 Логическая модель данных На данной модели представлены следующие сущности: Очное отделение, Заочное отделение, Студент, Инвентарь, Прописка и Комната. В каждой сущности определен первичный ключ. Отношения между сущностями различаются по следующим типам: один к одному(1:1) – это когда один экземпляр первого объекта может соответствовать только одному экземпляру второго объекта; один ко многим (1:n) – это когда один экземпляр первого объекта может соответствовать более чем одному экземпляру второго объекта; многие к одному (n:1) – это когда более чем один экземпляр первого объекта может соответствовать только одному экземпляру второго объекта. Физическая модель данных выглядит следующим образом (рис. 17): Рис. 17 Физическая модель данных Физическая модель представляет собой единую базу данных, где каждый объект логической модели преобразован в таблицу, а на основании отношений формируются вторичные или первичные ключи таблиц. |