Курсовая Проектирование информационных систем 2. Разработка концептуальной модели информационной системы управления библиотекой 4
 Скачать 115.19 Kb.
|
ОглавлениеВведение 3 Глава 1. Разработка концептуальной модели информационной системы управления библиотекой 4 1.1 Идентификация предметной области автоматизации 4 1.2 Обоснование выбора методологии и технологии концептуального моделирования ИСУ 4 1.3 Разработка и анализ модели бизнес-процесса «КАК ЕСТЬ» 6 1.4 Выявление недостатков существующего бизнес-процесса и рекомендации по его усовершенствованию с помощью ИТ 6 1.5 Разработка модели бизнес-процесса «КАК ДОЛЖНО БЫТЬ» и формулировка требований к внедряемой ИСУ 10 1.6 Анализ известных ИТ-решений ИСУ 11 1.7 Обоснование и постановка задачи на разработку новой ИСУ 11 Глава 2. Разработка логической модели информационной системы управления библиотекой 13 2.1 Обоснование выбора методологии и технологии логического моделирования ИСУ 13 2.2 Разработка объектной модели ИСУ 14 2.3 Разработка логической модели данных ИСУ 20 Заключение 23 Список использованных источников 24 Введение Тема курсовой работы: «Разработка концептуальной и логической моделей информационной системы управления библиотекой». Необходимо разработать информационную систему управления (ИСУ) библиотекой, которая будет предназначена для автоматизации рабочего места работника библиотеки. ИСУ должна обеспечивать просмотр, обработку, ввод новых данных, поиск данных по определенной категории, и вывод данных на печать. Актуальность данной темы обусловлена тем, что на сегоднешний деньмногие библиотеки не используют в своей работе автоматизированные средства обработки информации. Хотя перевод от бумажного ведения к автоматизированным средствам позволит сократить время на ведение книг, читателей на поиск необходимой информации, а так же на формирование и заполнение документации. Целью данной работы является разработка концептуальной и логической моделей информационной системы библиотекой. Для достижения поставленной цели необходимо решить следующие задачи: - идентифицировать предметную область автоматизации. -обосновать выбор методологии и технологии концептуального моделирования ИСУ. - разработать и проанализировать модель бизнесс-процесса «Как есть». -Выявить недостатки существующего бизнесс-процесса и сформировать рекомендации по его усовершенствованию при помощи ИТ. -разработать модель бизнесс-процесс «Как должно быть» и сформировать требования к внедряемой ИСУ. -проанализировать известные ИТ-решений ИСУ -внедрение бизнесс-процесса в систему. -проанализировать работу внедренного бизнесс-процесса. Глава 1. Разработка концептуальной модели информационной системы управления библиотекой Идентификация предметной области автоматизации Объектом автоматизации является библиотека, которая работает с поситителями, предоставляя услуги о выдаче книг. Основная задача работы библиотеки – хранение, сбор, и выдача книг поситителям (читателям) библиотеки. Основными задачами библиотеки являются: - Оперативное библиотечное и информационно-библиографическое обслуживание поситителей в соответствии с поступающими запросами на книги. -Ведение справочно-поискового аппарата: каталогов и картотек литературных источников и статей. -Улучшение работы библиотеки на основании ведения современных технологий и компьютеризации библиотечно-информационных процессов. Работа с читателями организована следующим образом: у каждого посетителя, который использует услуги библиотеки, имеется читательный билет. Посетитель поясняет, какая именно книга ему нужна, после чего идет проверка, имеется ли она в наличии. Если книга имеется в наличии, то библиотекарь оговаривает сроки, в которые книга должна быть возвращена обратно в библиотеку. Обоснование выбора методологии и технологии концептуального моделирования ИСУ Основные нотации концептуального моделирования: нотация IDEF0/ IDEF3, нотация ARIS, и нотация UML -Нотация IDEF0- это натация, применяемая для моделирования широкого класса систем. Так же обладает автоматизацией тем самым является вседоступным и простым в эксплуатации. Согласно этой методологии анализируемый процесс представляется в виде совокупности взаимосвязанных действий, которые имеют четко определенный алгоритм и взаимодействуют между собой на основе определенных правил и с учетом потребляемых информационных, человеческих и производственных ресурсов. Нотация IDEF0 упрощает сложные бизнесс-процессы разделяя их на более простые блоки. - Нотация EPC EPC это упорядоченный график событий и бизнес-функций. Начальные и конечные узлы на диаграммах EPC всегда являются событиями. Одно событие может инициировать выполнение одновременно нескольких бизнес-функций, и наоборот, в результате выполнения функции могут наступить нескольких событий. Тем самым под собития размещается информация о книгах и читателях данной библиотеки. -Нотация UML Для описания бизнес-процессов в UML применяются диаграммы деятельности. Диаграммы деятельности - это частный случай диаграммы состояний; на ней представлены переходы потока управления от одной деятельности к другой внутри системы. Диаграммы деятельности относятся к динамическому виду системы; они наиболее важны при моделировании ее функционирования и отражают поток управления между объектами. Диаграмма деятельности может использоваться также для определения подразделений и функций участников бизнес-процесса, описания документооборота. При описании бизнес-процессов диаграммы деятельности используются для описания последовательности различных действий субъектов и объектов. Разработка и анализ модели бизнес-процесса «КАК ЕСТЬ» Разработка «КАК ЕСТЬ?» Построение модели «как есть». Построение функциональной модели «как есть» позволяет четко определить, какие бизнес-процессы имеют место в компании и какие информационные объекты используются при выполнении процессов и отдельных операций. Определение бизнес-правил. Функциональная модель бизнес-процессов позволяет выявить и точно сформулировать бизнес-правила, используемые в деятельности компании. При выполнении операции «сортировать книги» используется бизнес-правило: «регистрации не подлежат: любые типы документов, присланные в копии для сведения, телеграммы и письма о разрешении командировок и отпусков…». Это правило зафиксировано в инструкции по обороту. Функциональная модель позволяет не только идентифицировать существование этого правила, но также определить, при выполнении какой операции и на каком рабочем месте оно должно применяться. Если при автоматизации процесса это бизнес-правило не будет учтено, то информационная система будет функционировать некорректно. Выявление недостатков существующего бизнес-процесса и рекомендации по его усовершенствованию с помощью ИТ Преимущества и недостатки нотации IDEF0
Преимущества и недостатки нотации Aris
Преимущества и недостатки нотации UML
Разработка модели бизнес-процесса «КАК ДОЛЖНО БЫТЬ» и формулировка требований к внедряемой ИСУ Построение модели «как должно быть». Данная модель описывает бизнес-процессы, полученные в результате реинжиниринга или скорректированные в ответ на изменения условий работы компании или выполнения отдельных операций. Распределение ресурсов. Функциональная модель позволяет четко определить распределение ресурсов между операциями бизнес-процесса, что дает возможность оценить эффективность использования ресурсов. Особенно эта задача актуальна при создании новых бизнес-процессов на предприятии. Например, оператор, специализировавшийся на транзите трафика, принял решение создать собственный отдел продаж и предоставлять услуги конечному потребителю. Функциональная модель бизнес-процесса по продаже услуг связи позволит руководству компании четко определить, какие ресурсы необходимо выделить для того, чтобы обеспечить функционирование отдела продаж, сколько сотрудников необходимо привлечь для работы в новом подразделении, какие функциональные обязанности эти сотрудники должны выполнять и т. д. Анализ известных ИТ-решений ИСУ Система автоматизирует основные бизнес-направления: управление персоналом для облегчения их работы, скорость работы для быстрого поиска необходимой литературы (не затрачивать много время читателя). Каждому из этих направлении соответствуют определенные приложения системы. Опишем вкратце некоторые из них.Управление в системе обеспечивают удобство и экономия времени . При разработке системы был учтен принцип соответствия международным стандартам. Тем самым данная библиотека будет проходить в своем развитии различные стадии, что получило отражение в дальнейшей работе библиотеки. Это принципиально новый программный подход, вобравший в себя весь накопленный ранее и тщательно проанализированный опыт.Автоматизация управления деятельностью предприятия как комплексное решение, поддерживаемое разработчиком на всех этапах жизненного цикла Системы.Полная и оперативная информация для достижения конечного результата - повышения эффективности функционирования данного объекта.Избавление от рутинной работы, возможность сосредоточиться на удобство пользование системой библиотеки. Обоснование и постановка задачи на разработку новой ИСУ Главные задачи ИСУ - это организация хранения документов в электронном виде, а также работы с ними. В ИСУ должны автоматически отслеживаться изменения в документах, сроки исполнения документов, движение документов, а также контролироваться все их версии документа и его редакции. Для создания системы необходимо решить следующие задачи: Анализ требований технического задания с точки зрения выбранной технологии и уточнение требований к информационной системе: техническим средствам, внешним интерфейсам. Выбор подхода, технологии, методов, стандартов и средств разработки. Определение архитектуры информационной системы: разработка ее структуры; определение набора необходимого оборудования и программного обеспечения. Исследование предметной области – выбор методов решения этих задач. Анализ требований технического задания и разработка спецификаций проектируемого программного обеспечения. Проектирование компонентов программного продукта: сервер, клиент, базы данных. Разработка структуры программного обеспечения и определение спецификаций его компонентов. Реализация компонентов с использованием выбранных средств и их автономное тестирование. Сборка программного обеспечения и его комплексное тестирование. Требования к программному обеспечению: Авторизация пользователей Разграничение прав доступа Управление документацией Управление работниками отдела Исходные данные: Требования к управлению документацией Результаты: Оперативное согласование новых документов и изменений Шаблонизация форм документов. Выводы по первой главе В ходе написания первой главы были изучены структура центра инжиниринга, его задачи и цели, методологии и технологии концептуального моделирования. Были разработаны модели бизнес процессов «КАК ЕСТЬ» и «КАК ДОЛЖНО БЫТЬ», выявлены проблемы существующей автоматизированной системы и поставлены задачи по ее улучшению. Глава 2. Разработка логической модели информационной системы управления библиотекой 2.1 Обоснование выбора методологии и технологии логического моделирования ИСУ Логическое моделирование- это операция проверки функционирования логической системы при помощи компьютера. Основная цель логического моделирования- проверка функции проектируемой логической системы внесение изменений в нее при современной технологии сделать будет дорого и сложно. Для построения логической модели данных могут применяться следующие нотации : IDEF1X и IE. Осуществим сравнение данных нотаций и представим результаты сравнения в таблицу:
Как видно из таблицы наиболее подходящей является нотацией IDEF1X, поскольку данная нотация достаточно проста в освоении. В настоящее время существует множество средств, поддерживающих логическое моделирование в нотации IDEF1X. Однако наиболее популярной и легкой в понимании является ERWin. 2.2 Разработка объектной модели ИСУ Классический структурный подход к созданию ИСУ предполагает последовательную реализацию этапов анализа, проектирования, создания модулей, объединения модулей в единую систему, тестирования и внедрения. Применение CASE-технологий и CASE-средств, подобных ERwin и BPwin, позволяет в несколько раз сократить время разработки ИС и значительно снизить вероятность появления .ошибок за счет автоматизации начальных этапов разработки (а как следствие - более качественного планирования и проектирования) и автоматической; генерации структуры сервера БД и кода клиентского приложения. Однако эта технология не лишена недостатков. Код клиентского приложения генерируется на основе информации о структуре БД. К структуре БД предъявляются определенные требования (нормализации), в результате чего данные хранятся в таблицах БД не всегда в той же форме, в которой они должны представляться на экранных формах. Другими словами, если код приложения генерируется не на основе описания предметной области, невозможно построить эффективное приложение со сложной бизнес-логикой. Кроме того, при структурном подходе к разработке ИС риск остается большим на всех этапах создания системы вплоть до этапа тестирования, когда мы можем обнаружить допущенные ошибки и оценить состоятельность системы. В случае обнаружения ошибки необходимо вернуться на тот этап разработки, на котором допущена ошибка, и заново пройти последующие этапы. Снижение риска в объектной технологии достигается за счет реализации технологии итерационной разработки (так называемая спиральная модель жизненного цикла разработки). Разработка состоит из ряда итераций, которые в дальнейшем приводят к созданию ИС. Каждая итерация может приводить к созданию фрагмента или новой версии и включает этапы выработки требований, анализа, проектирования, реализации и тестирования. Поскольку тестирование проводится на каждой итерации, риск снижается уже на начальных этапах жизненного цикла разработки. Модель представляет собой совокупность диаграмм, описывающих различные аспекты структуры и поведения ИСУ. В дальнейшем в качестве примера будет описана объектная модель, построенная в Rational Rose for Java (version 4.0). Для просмотра модели в Rational Rose используется иерархический навигатор модели - Browser (рис. 4.1).  Рис. 4.1. Навигатор модели в Rational Rose - Browser Рассмотрим в общих чертах некоторые диаграммы UML. Диаграммы использования системы (Use Cases) показывают, какая функциональность должна быть реализована в системе, основные функции, которые должны быть включены в систему (use case), их окружение (actors) и взаимодействие функций с окружением (рис. 4.2). Воздействующие объекты (actors) не являются частью системы - это конечные пользователи или другие программы, взаимодействующие с проектируемой ИС. Функциональность (use case) - последовательность действий, выполняемых системой, которые приводят к определенным результатам, необходимым для конкретного воздействующего объекта.  Рис. 4.2. Диаграмма Use Cases. Здесь Customer, Salespeople - Actors; Register for Order, Validate User - Use case Диаграммы Use Cases включают отношения и ассоциации, показывающие взаимодействие между воздействующими объектами и функциями (изображаются в виде стрелок), и примечания (note), которые могут быть привязаны к любому объекту диаграммы Use Cases. Для создания новой диаграммы Use Cases следует правой кнопкой мыши щелкнуть в навигаторе модели по закладке Use Case View и выбрать во всплывающем меню пункты New/Use Case. Для внесения в диаграмму Use Case и установления связей между ними следует использовать кнопки палитры инструментов Rational Rose:  Диаграммы классов. Под объектом в UML понимается некоторое абстрактное представление конкретного объекта предметной области. Каждый объект имеет состояние, поведение и индивидуальность. Например, объект "Проект" может иметь два состояния - "открыт" и "закрыт". Поведение объекта определяет, как объект взаимодействует с другими объектами. Индивидуальность означает, что каждый объект уникален и отличается от Других объектов. Под классом понимается описание объектов, обладающих общими свойствами (атрибутами), поведением, общими взаимоотношениями с другими объектами и общей семантикой. Класс является шаблоном для создания новых объектов. Для внесения нового класса в диаграмму классов нужно использовать кнопку !!! в палитре инструментов. Если система содержит большое количество классов, они могут быть объединены в пакеты (package). Каждый класс может иметь атрибуты (свойства). Так, на рис. 4.3 класс Customer Information (информация о клиенте) имеет атрибуты CustomerID (идентификатор клиента), Name (имя) и Account (счет). Кроме того, каждый класс может иметь методы (operations) - некоторые действия, которые описывают поведение объектов класса. На рис. 4.3 класс Customer Information имеет метод Check Account. Для внесения свойств класса следует правой кнопкой мыши щелкнуть по классу и выбрать во всплывающем меню пункт Specification.  Рис. 4.3. Диаграмма классов Классы могут иметь взаимосвязи (relationship), называемые отношениями. В нотации UML имеется несколько типов отношений. Отношение использования (associations, кнопка !!! палитры инструментов) показывает, что объект одного класса связан с одним или несколькими объектами другого класса. Отношение включения (aggregation, кнопка !!! является частным случаем отношения использования. Оно показывает, что один объект является частью другого. При воздействии на один объект, связанный отношением включения, некоторые операции автоматически могут затронуть другой объект. Например, на рис. 4.3 класс Customer Information связан отношением включения с классом Contract. При удалении объекта класса Customer Information (информация о клиенте) должны удаляться все объекты класса Contract (относящиеся к данному клиенту контракты). Каждая связь может быть охарактеризована определенной фразой, называемой именем роли. Связь между классами Customer Information и Contract имеет имя negotiates. Каждая связь может иметь индикатор множественности, который показывает, сколько объектов одного класса соответствует объекту другого класса. На рис. 4.3 связь negotiates имеет индикатор 1..* (один или много). Наследование (inheritance) описывает взаимосвязь между классами, когда один класс (называется подклассом, subclass) наследует структуру и/или поведение одного или нескольких классов. На рис. 4.3 подкласс VIP наследует свойства и поведение класса Customer Information. Связь классов в иерархии наследования называется отношением наследования (generalization, кнопка !!!). Временная диаграмма (Sequences) демонстрирует поведение объектов во времени. Она показывает объекты и последовательность сообщений, посылаемых объектами. Сообщения на диаграмме сценариев изображаются в виде стрелок (рис. 4.4).  Рис. 4.4. Временная диаграмма (Sequence) Архитектура приложения описывается в диаграммах компонентов (Component Diagram) и диаграммах развертывания (Deployment Diagram). На диаграммах компонентов изображается вхождение классов и объектов в программные компоненты системы (модули, библиотеки и т. д.). При помощи диаграмм развертывания документируется размещение программных модулей на узлах (физических и логических устройствах) системы. Генерация кода осуществляется на основе диаграмм классов. Для генерации необходимо в Rational Rose выбрать пункт меню Tools/Java/Generate Java. 2.3 Разработка логической модели данных ИСУ Различают три уровня логической модели, отличающихся по глубине представления информации о данных: диаграмма сущность-связь (Entity Relationship Diagram, ERD); модель данных, основанная на ключах (Key Based model, KB); полная атрибутивная модель (Fully Attributed model, FA). Диаграмма сущность-связь представляет собой модель данных верхнего уровня. Она включает сущности и взаимосвязи, отражающие основные бизнес-правила предметной области. Такая диаграмма не слишком детализирована, в нее включаются основные сущности и связи между ними, которые удовлетворяют основным требованиям, предъявляемым к ИС. Диаграмма сущность-связь может включать связи многие-ко-многим и не включать описание ключей. Как правило, ERD используется для презентаций и обсуждения структуры данных с экспертами предметной области. Модель данных, основанная на ключах, - более подробное представление данных. Она включает описание всех сущностей и первичных ключей и предназначена для представления структуры данных и ключей, которые соответствуют предметной области. Полная атрибутивная модель - наиболее детальное представление структуры данных: представляет данные в третьей нормальной форме и включает все сущности, атрибуты и связи. Рекомендации по разработке Необходимо определить, зачем нам нужна логическая модель. На какие вопросы она должна нам в конце концов ответить? Почему она повлияет на качество выполнения анализа и как поможет решению поставленной перед нами задачи? Без ответов на эти вопросы разработка модели теряет всякий смысл, поскольку мы будем делать что-то, от чего особо ничего не ожидаем. Соответствующим будет и результат. Ответы на эти вопросы дают нам требования к модели, а в ходе разработки позволят принимать решения о ее развитии и судить о ее качестве. Необходимо определить границы моделирования — какую часть исследуемой предметной области модель должна охватить. Как правило, ответ на этот вопрос вытекает из понимания стоящей перед бизнес-аналитиком задачи. В большинстве случаев границы моделирования определяются либо исследуемыми бизнес-процессами, либо фрагментом информационного пространства компании, попадающим под решаемую задачу. Разработка логической модели должна начинаться в момент начала исследования предметной области и заканчиваться тогда, когда завершается выполнение задачи. Это едва ли не единственный артефакт, который разрабатывается на протяжении всего анализа предметной области и определения требований к системе. Разработка логической модели – итеративный процесс. Она должна последовательно, по мере проработки предметной области и поставленной задачи, уточняться и детализироваться. В ходе анализа осуществляется выявление и отображение на модели сущностей и связей. Логическую модель надо строить так, чтобы сущности назывались именами существительными, связи — глаголами, а чтение диаграммы рождало бы пусть и корявые, но предложения, описывающие то, что происходит в предметной области. Если этого удалось добиться, то модель вышла замечательная. Если не удалось такое, то разработчику модели еще есть над чем поработать. По мере проработки модели уточняется состав сущностей и связей, а также определяются атрибуты сущностей. Выводы по второй главе: Важно помнить, что логическая модель — это не про структуру базы данных, это про логическую структуру предметной области твоей задачи. Исключая ее из разрабатываемых атрибутов, ты лишаешь себя эффективного инструмента анализа и проектирования, позволяющего очень точно учесть аспекты бизнеса, не иллюстрируемые динамическими моделями. И наоборот — своевременное и грамотное использование логической модели делает ее очень сильным инструментов в руках бизнес- или системного аналитика. Заключение В результате выполнения данной курсовой работы разработаны концептуальная и логическая модели ИСУ библиотекой. Так же в данной работе были решены следующие задачи: -Разработана концептуальная модель ИСУ Идентифицирована предметная область автоматизации Обоснован выбор методологии и технологии концептуального меделирования ИСУ Разработана и проанализирована модель бизнесс-процесса «КАК ЕСТЬ» Выявлены недостатки существующего бизнесс процесса и сформированы рекомендации по его усовершенствованию с помощью IT Разработана модель «КАК ДОЛЖНО БЫТЬ» и сформированы требования к внедряемому ИСУ Проанализированы известные IT решения ИСУ Обоснована и сформирована постановка задачи на разработку новой ИСУ - Разработана логическая модель ИСУ Обоснован выбор методологии и технологии логического моделирования ИСУ Разработана объектная модель ИСУ Разработана логическая модель ИСУ В результате достигнутв цель курсовой работы и выполнены поставленные задачи. Разработанная информационная система управления библиотекой позволит сократить время поиска и оформления выдачи необходимой книги читателю. Список использованных источников 1. Моделирование бизнес-процессов: методика, нотация, инструмент [Электронный ресурс]. – Режим доступа: http://emirs.miet.ru/oroks-miet/upload/ftp/pub/2015/11_0/563778e6738ac/Lecture2.pdf 2. Бугай, О.В. САПР программного обеспечения издательско-полиграфического комплекса: учеб. пособ. / О.В. Бугай, В.С. Юденков. – Минск: БГТУ, 2008. – 174с. 3. Быков, С.Ю. МЕТОДЫ МОДЕЛИРОВАНИЯ БИЗНЕС-ПРОЦЕССОВ / С.Ю. Быков. - Компания TEM consulting, 2016. - 16с. 4. Фаулер, М. UML. Основы, 3-е издание / М. Фаулер. – СПб.: Символ-Плюс, 2004. – 192с. 5. Программа компьютерного моделирования BPwin [Электронный ресурс]. – Режим доступа: http://bourabai.kz/cm/bpwin.htm 6. Автоматизированная система Библиотека – учет книг [Электронный ресурс]. – Режим доступа: https://континент свободы.рф/офис/прочее/ автоматизированная-система-библиотека-учет-книг.html 7. Библиотекарь [Электронный ресурс]. – Режим доступа: http://freesoft.ru/bibliotekar_v01b 8. Учет книг [Электронный ресурс]. – Режим доступа: https://www.bes tfree.ru/soft/office/accounting-books.php 9. Логическое моделирование [Электронный ресурс]. – Режим доступа: https://www.intuit.ru/studies/courses/3440/682/lecture/14036 10. Построение диаграммы прецедентов [Электронный ресурс]. –Режим доступа: http://life-prog.ru/1_16788_ postroenie-diagrammi-pretsedentov.html 11. Разработка объектной модели [Электронный ресурс]. –Режим доступа: https://it.wikireading.ru/39373 |