Министерство науки и высшего образования Российской Федерации ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ «ОРЕНБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ» Факультет математики и информационных технологий Кафедра информатики КУРСОВАЯ РАБОТА по дисциплине «Методы и средства проектирования информационных систем и технологий» Проектирование компонентов информационной системы Пояснительная записка ОГУ 09.03.02 3022. 573 ПЗ Руководитель канд. техн. наук, доцент В. В. Извозчикова « » 2022 г. Студент группы: 19ИСТ (ба)ОП В.Е. Поляков « » 2022 г. Оренбург 2022 Утверждаю Заведующий кафедрой информатики _________________Токарева М.А. «_____»______________20_____г. ЗАДАНИЕ на выполнение курсовой работы студенту Полякоову Вадиму Евгеньевичу по направлению подготовки 09.03.02 Информационные системы и технологии по дисциплине «Методы и средства проектирования информационных систем и технологий» 1 Тема работы: Проектирование компонентов информационной системы 2 Срок сдачи студентом работы «06» июня 2022 г. 3 Цель и задачи работы Цель: проектирование компонентов информационной системы «Библиотека вуза» с помощью современных средств и методов Задачи: – составление плана проекта; – анализ предметной области; – анализ и выбор метода и средства проектирования; – разработка концептуальной модели области; – разработка логической модель области; – разработка физической модели области. 4 Исходные данные краткое описание предметной области «Информационная система библиотеки вуза» 5 Перечень вопросов, подлежащих разработке: – составление плана проектирования; – анализ предметной области; – выбор методологии проектирования; – моделирование бизнес-процессов в организации (IDEF0); – моделирование потоков данных (DFD); – создание диаграмм вариантов использования, взаимодействия, деятельности, классов, компонентов, размещения. Дата выдачи и получения задания Руководитель Студент «07» февраля 2022г. _____________ Извозчикова В.В. «07» февраля 2022г. _____________ Поляков В.Е. Аннотация Данная курсовая работа посвящена проектированию информационной системы по выбранной предметной области «Информационная система библиотеки вуза» При создании курсовой работы первым этапом был разработан план написания курсовой работы. Далее произведен анализ предметной области и выявление основных структур. И выбор методологии проектирования ИС. Следующие два этапа были направлены на конкретное создание диаграмм, для описания процессов информационной системы. Для проектирования информационной системы были использованы средства как структурнофункционального, так и объектно-ориентированного моделирования. С помощью методологии IDEF0 была построена контекстная диаграмма и проведена декомпозиция до первого уровня. Также разработана схема информационных потоков данных (DFD). Используя объектно-ориентированный подход была построена диаграмма прецедентов, диаграмма взаимодействия, диаграмма компонентов, диаграмма активности, диаграмма классов, диаграмма размещения, физическая модель базы данных. Полученная модель является достаточной для перехода к физической реализации системы управления. Для построения всех диаграмм и написания данной курсовой работы были использованы программы специально для этого предназначенные. А именно IBM Rational Rose, MySQL Workbench, CASE-средство AllFusion Process Modeler. Работа содержит 30 листов текста, в том числе 17 рисунков. Изм Лист Разраб. Пров. № документа Подп. Дата ОГУ 09.03.02.3022.223 ПЗ Чернышов В.К. Извозчикова В.В. Н. Контр Зав. каф. Токарева М.А. Лит. Проектирование компонентов информационной системы К Лист Листов 3 30 19ИСТ(ба)ОП Содержание Введение ........................................................................................................................... 5 1 Разработка плана проекта автоматизированной информационной системы ........ 6 2 Анализ предметной области........................................................................................ 8 3 Выбор методологии проектирования ИС ................................................................ 10 4 Структурное (функциональное) моделирование ИС.............................................. 12 4.1 Моделирование бизнес-процессов в методологии IDEF0 .............................. 12 4.2 Моделирование потоков данных (DFD) ........................................................... 15 5 Объектно-ориентированное проектирование информационной системы .......... 18 5.1 Построение диаграммы прецедентов ................................................................ 18 5.2 Построение диаграммы взаимодействия .......................................................... 20 5.3 Построение диаграммы активностей ................................................................ 21 5.4 Построение диаграммы классов ........................................................................ 22 5.5 Построение физической модели базы данных ................................................. 23 5.6 Построение диаграммы компонентов ............................................................... 24 5.7 Построение диаграммы размещения ................................................................. 25 Заключение .................................................................................................................... 28 Список используемых источников .............................................................................. 29 Лист 4 4 Введение В современном мире все организации начиная от самой маленькой до гигантов в своей индустрии используют самые лучшие способы для оптимизации и улучшения работы. Одним из самых лучших способов улучшения функционирования организации является наличие автоматизированной информационной системы (АИС). Системы, которые можно назвать АИС, в большей степени выполняют следующие функции, реализуют автоматизированный сбор, обработку и манипулирование данными и включающие технические средства обработки данных, программное обеспечение и обслуживающий персонал. Для создания хорошей АИС требуется немало усилий. Необходимо грамотно проанализировать всю структуру компании и составить множество диаграмм и бизнес проектов для улучшения автоматизированной составляющей. Реализация же автоматизированной информационной системы выполняется множеством инструментов. Для примера можно рассмотреть CASE (ComputerAidedSoftware/SystemEngineering) технологиям и инструментальным CASEсредствам, позволяющим максимально систематизировать и автоматизировать все этапы разработки программного обеспечения. Созданная таким образом АИС позволяет разработчикам сосредоточиться именно на реализации специфики конкретной системы и избавляет от рутины проектирования и программирования базовых операций. Все это, увеличивает скорость разработки, снижает себестоимость выполняемых работ, дает возможность создавать большие системы маленькими командами, а простые, учётные системы создавать в считанные часы и дни усилиями одного - двух разработчиков. Так же одним из самых популярных средств для разработки АИС является Unified Modeling Language - унифицированный язык моделирования. UML – это язык для визуализации, специфицирования, конструирования и документирования артефактов программных систем. Целью курсовой работы является проектирование компонентов информационной системы «Библиотека вуза» с помощью современных средств и методов. А так же закрепление и углубление знаний, получение практических навыков использования методов и средств проектирования информационных систем и технологий Лист 55 1 Разработка плана информационной системы проекта автоматизированной При создании любого проекта следует грамотно спланировать, когда именно следует начать проект, узнать какие сроки есть и правильно распределить время между началом и концом. Такая простая последовательность действий и называется разработкой плана проекта, но данный процесс не всегда легко сделать, так как грамотный план по созданию, в нашем случае курсовой работы, очень упростит её написание. При формировании плана проекты, необходимо грамотно организовывать все этапы и визуализировать их начало и конец. Так же необходимо учитывать все тонкости той организации или проекта для которой строится план. Необходимо учитывать множество факторов для реализации сложных планов больших компаний таких, например, как взаимодействия различных фирм: заказчиков, подрядчиков, поставщиков, исполнителей, инвесторов и т.д. Самым важным фактором является учет времени или других ресурсов для разработки плана [1]. Из всего вышеописанного необходимо выбрать самый подходящий инструмент для реализации плана проекта автоматизированной информационной системы. К такому инструменту можно отнести программу «Microsoft Project» (или MSP) — программа управления проектами, разработанная и продаваемая корпорацией Microsoft. Программа «Microsoft Project» создана, чтобы помочь менеджеру проекта в разработке планов, распределении ресурсов по задачам, отслеживании прогресса и анализе объёмов работ. Одна из основных функций данной программы − создание расписания критического пути. Расписания могут быть составлены с учётом используемых ресурсов. Цепочка визуализируется в диаграмме Ганта. Управление проектом заключается в отслеживании состояния работ и определении, выполняются ли они в соответствии с планом. Если выполнение отстает от плана, то следует либо изменить план, либо принять меры для ликвидации задержки. Microsoft Project автоматически откорректирует план в соответствии с внесенными вами изменениями. Программа также предоставит информацию о том, какие ресурсы перегружены, и какие работы не могут быть выполнены в срок [2]. Плюсы «MS Project»: 1) простота установки в простейшем варианте; 2) начиная с версии 2007, улучшены возможности по интеграции c бухгалтериями, финансовыми системами, ERP-комплексами, сняты многие технологические и логические ограничения; 3) начиная с версии 2007, программа улучшена в области задач для бюджетирования, а также сбора фактических данных об исполнении проектов; 4) система табелирования отвечает нетривиальным задачам по подаче отчётов о затратах рабочего времени в рамках учётных политик; 5) быстрое заполнение отчётов; 6) эффективное решение многих задач анализа использования ресурсов и бюджетирования проектов; Лист 66 7) возможность координации большого числа групп пользователей, работающих над одним проектом, через управление результатами между группами. Минусы «MS Project»: 1) установка в полном рабочем варианте достаточно нетривиальна и требует опытного инженера; 2) система табелирования на «двойной бухгалтерии» рабочего времени неочевидна в использовании и может искажать результаты в отчётах при неверном использовании. Требуется опытный консультант для постановки и контроля процесса; 3) программа достаточно стабильна и проработана именно на полном цикле учёта рабочего времени, но на укороченном цикле можно встретить существенные ограничения в web-интерфейсе системы; 4) качественную интеграцию может выполнить только эксперт. Учитывая все плюс и минусы MS Project можно сделать простой вывод, что для нашей задачи данный программный продукт подходит. Разработаем план проектирования автоматизированной информационной системы в MS Project рисунок 1.1. Рисунок 1.1 – Разработка плана проектирования АИС в MS Project (часть 1) Рисунок 1.2 – Разработка плана проектирования АИС в MS Project (часть 2) Лист 77 2 Анализ предметной области Перед началом создания любой АИС необходимо провести анализ области проектирования. Необходимо определить актуальность выбранной предметной области, этапы функционирования, входные и выходные данные, влияющие на проектирование и разработку информационной подсистемы с целью удовлетворения потребностей данной автоматизированной системы. Темой данной курсовой работы является автоматизированная информационная система библиотеки вуза. Библиотека включает в себя абонементы, читальные залы и справочную систему каталогов и карточек. Читателями библиотеки вуза могут быть: студенты всех форм обучения, профессорско-преподавательский состав университета, аспиранты, ассистенты и другие сотрудники подразделений вуза, слушатели подготовительного отделения, факультета повышения квалификации (ФПК), стажеры, абитуриенты. Различные категории читателей обладают уникальными характеристиками: для студентов – это название факультета, номер группы, для преподавателя – название кафедры, степень, звание и т.д. Слушатели ФПК, абитуриенты, стажеры – разовые читатели – могут пользоваться только читальными залами и обращаться в справочную систему для поиска. Читатели библиотеки могут получать библиотечные материалы во всех пунктах выдачи библиотеки (абонементах и читальных залах). За нарушение правил пользования библиотеки читатели лишаются доступа к библиотеке на установленные администрацией сроки. В библиотеке имеется материальная база, которая включает в себя оборудование, библиотечные материалы и т.д. Бухгалтерская система, отвечающая за работу отчетов и мониторинга запросов, а также персонал, работающий в соответствии с нормативными актами. При создании приложения по ранее описанному анализу и более детальному построению диаграмм и моделей стоит рассмотреть функции, которые будут выполнять различные пользователи приложения. А именно клиенты и персонал. Клиенты данного приложения смогут: 1) получить перечень и общее число читателей для данного читального зала или абонемента по всей библиотеке, по признаку принадлежности к кафедре, факультету, курсу, группе; 2) получить список и общее число всех читателей-должников, задолжников со сроком более 10 дней на данном абоненте, по всей библиотеке, по признаку принадлежности к кафедре, факультету, курсу, группе, по категориям читателей; 3) получить количество экземпляров книги для данного читального зала или абонента, во всей библиотеке, всех изданий; 4) получить перечень и общее число книг, заказанных данным читателем за последний месяц, семестр, год, список книг у него на руках; 5) определить есть ли данная книга в наличии и в каком количестве; Лист 88 6) получить перечень читателей, у которых на руках некоторая книга и читателя, который раньше всех ее должен сдать; 7) выдать полную информацию о читателе по его фамилии: группу, курс, факультет или кафедру, нарушения правил библиотеки, их количество и т.п. После анализа всех пунктов для предметной области можно перейти к проектированию диаграмм и модулей для построения конкретных процессов. Лист 99 3 Выбор методологии проектирования ИС Важной частью разработки информационной системы является рассмотрение и обдумывание методологического подхода. Методология создания информационных систем заключается в организации процесса построения информационной системы и обеспечении управления этим процессом для того, чтобы гарантировать выполнение требований как к самой системе, так и к характеристикам процесса разработки [3]. Методология проектирования обычно включает три следующих аспекта: 1) основные концепции и понятия, используемые при проектировании и реализации систем; 2) технологию, организацию и управление процессом проектирования; 3) инструментальные средства. Современные методологии проектирования ИС должны обеспечивать представление следующей информации: 1) описание объекта автоматизации, а также места разрабатываемой информационной системы и целей, которые должны быть достигнуты в процессе разработки системы; 2) описание функциональных возможностей ИС, достаточное для решения вопроса о том, что поставленные цели автоматизации достижимы; 3) спецификации проекта, гарантирующие достижение заданных технических характеристик системы; 4) описание реализации предлагаемой системы, достаточное для оценки времени ее разработки и необходимых для этого трудозатрат; 5) детальный план создания системы с оценкой сроков ее разработки. Основными задачами, решение которых должна обеспечивать методология создания информационных систем, являются следующие: 1) обеспечение создания информационных систем, отвечающих целям и задачам предприятия и соответствующих предъявляемым к ним требованиям по автоматизации деловых процессов; 2) гарантия создания системы с заданными параметрами в течение заданного времени в рамках заранее оговоренного бюджета; 3) простота сопровождения, модификации и расширения системы для обеспечения ее соответствия изменяющимся условиям работы предприятия; 4) возможность использования в создаваемой системе разработанных ранее и уже применяемых на предприятии средств информационных технологий (программного обеспечения, баз данных, средств вычислительной техники, телекоммуникаций) [4]. Методология проектирования ИС реализуется через конкретные технологии и поддерживающие их стандарты, методики и инструментальные средства, которые обеспечивают выполнение процессов жизненного цикла информационных систем. Основное содержание технологии проектирования составляют технологические инструкции, состоящие из описания последовательности технологических Лист 10 10 операций, условий, в зависимости от которых выполняется та или иная операция, и описаний самих этих операций. Обычно для реализации той или иной задачи выделяют два подхода (структурный и объектно-ориентированный) и более трех десятков методологий, ориентированных на создание систем комплексной автоматизации или проведения информационных проектов. Методология структурного программирования появилась как следствие возрастания сложности решаемых на компьютерах задач, и соответственно, усложнения программного обеспечения. В 1970-е годы объёмы и сложность программ достигли такого уровня, что традиционная (неструктурированная) разработка программ перестала удовлетворять потребностям практики. Структурное программирование — парадигма программирования, в основе которой лежит представление программы в виде иерархической структуры блоков. Программы становились слишком сложными, чтобы их можно было нормально сопровождать. Поэтому потребовалась систематизация процесса разработки и структуры программ. Методология структурной разработки программного обеспечения была признана «самой сильной формализацией 70-х годов» [5]. Методология объектно-ориентированного программирования — это подход, использующий объектную декомпозицию, при которой статическая структура системы описывается в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщениями между объектами. На возникновение объектного мышления оказали влияние моделирование и представление данных, графические пользовательские интерфейсы и системное программирование (с понятием "процесс"). Исследования в области хеширования реальных систем привели к необходимости создания средств описания сущностей, которые в них встречаются: объектов и событий. Позже оказалось, что такие концепции, как инкапсуляция (абстрактные типы данных), наследование и полиморфизм являются достаточно полезным дополнением к традиционному структурному программированию. Возможность их достаточно эффективной реализации привела к созданию широко распространенных в наши дни объектно-ориентированных языков [6]. Главное во всех этих методологиях – единая дисциплина работы на всех этапах жизненного цикла системы, учет критических задач и контроль их решения, применение развитых инструментальных средств поддержки процессов анализа, проектирования и реализации ИС. Очевидно, что решение этих задач – сложная проблема, которая не может быть выполнена интуитивным путем. Поэтому, при решении поставленных задач, в первую очередь, необходимо выбрать методологические основания, в соответствии с которыми будут выполняться работы. Поэтому для получения полной картины был выбран гибридный подход, т.е. сочетание преимуществ как структурного, так и объектно-ориентированного [7]. Лист 11 11 4 Структурное (функциональное) моделирование ИС 4.1 Моделирование бизнес-процессов в методологии IDEF0 Методология IDEF0 представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель IDEF0 отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями. IDEF0 может быть использована для моделирования широкого класса систем. Для новых систем применение IDEF0 имеет своей целью определение требований и указание функций для последующей разработки системы, отвечающей поставленным требованиям и реализующей выделенные функции. Применительно к уже существующим системам IDEF0 может быть использована для анализа функций, выполняемых системой, и отображения механизмов, посредством которых эти функции выполняются. Модель в IDEF0 представлена совокупностью иерархически упорядоченных и логически связанных диаграмм, а также текста документации и словарей, связанных друг с другом с помощью перекрестных ссылок [8]. Основу методологии IDEF0 составляет графический язык описания бизнеспроцессов. Модель в нотации IDEF0 представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм. Каждая диаграмма является единицей описания системы и располагается на отдельном листе. Можно выделить четыре типа диаграмм: 1) контекстную диаграмму Аз0 (в каждой модели может быть только одна контекстная диаграмма); 2) диаграммы декомпозиции (в том числе диаграмма первого уровня декомпозиции А0, раскрывающая контекстную); 3) диаграммы дерева узлов; 4) диаграммы только для экспозиции (FEO) [9]. Контекстная диаграмма представляет собой самое общее описание системы и ее взаимодействия с внешней средой. После описания системы в целом проводится разбиение ее на подсистемы. Этот процесс называется функциональной декомпозицией, а диаграммы, которые описывают каждый фрагмент, называются диаграммами декомпозиции. Каждый компонент модели может быть декомпозирован на другой диаграмме. Каждая диаграмма иллюстрирует "внутреннее строение" блока на родительской диаграмме. После декомпозиции контекстной диаграммы (т.е. получения диаграммы А0) проводится декомпозиция каждого блока диаграммы А0 на более мелкие фрагменты и так далее, до достижения нужного уровня подробности описания. После каждого сеанса декомпозиции проводятся сеансы экспертизы: эксперты предметной области (обычно это интервьюируемые аналитиками сотрудники предприятий) указывают на соответствие реальных бизнес-процессов созданным диаграммам. Найденные несоответствия исправляются, Лист 12 12 и только после прохождения экспертизы без замечаний можно приступать к следующему сеансу декомпозиции. Так достигается соответствие модели реальным бизнес-процессам на любом и каждом уровне модели. Синтаксис описания системы в целом и каждого ее фрагмента одинаков во всей модели. Диаграмма дерева узлов показывает иерархическую зависимость работ, но не взаимосвязи между работами. Диаграмм деревьев узлов может быть в модели сколько угодно, поскольку дерево может быть построено на произвольную глубину и не обязательно с корня. Диаграммы для экспозиции (FEO) строятся для иллюстрации отдельных фрагментов модели, для иллюстрации альтернативной точки зрения, либо для специальных целей. Правила IDEF0 включают: 1) ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков); 2) связность диаграмм (номера блоков); 3) уникальность меток и наименований (отсутствие повторяющихся имен); 4) синтаксические правила для графики (блоков и дуг); 5) разделение входов и управлений (правило определения роли данных); 6) отделение организации от функции, т.е. исключение влияния организационной структуры на функциональную модель [10]. Контекстный уровень диаграммы информационной системы бизнеспроцессов «Библиотека вуза» представлена на рисунке 4.1. Рисунок 4.1 – Контекстная функциональная модель в методологии IDEF0 Далее этот блок детализируется на другой диаграмме с помощью нескольких блоков, соединенных интерфейсными дугами. Декомпозиция - разделение Лист 13 13 моделируемой функции на функции компоненты. Диаграмма декомпозиции представлена на рисунке 4.2. Рисунок 4.2 – Диаграмма декомпозиции А0 Т.к. основная деятельность — это поиск библиотечных материалов и само оформление заказа, то именно это и покажем в качестве диаграммы декомпозиции второго уровня рисунок 4.3. Рисунок 4.3 – Декомпозиция функционального блока А2 «Абонемент» Запись деятельности библиотеки будет фиксироваться в справочной системе, что показано на рисунке 4.4. Лист 14 14 Рисунок 4.4 – Декомпозиция функционального блока А4 «Справочная система каталогов и карточек» На рисунке 4.5 покажем иерархическую зависимость блоков. Рисунок 4.5 – Декомпозиция дерева узлов 4.2 Моделирование потоков данных (DFD) Диаграммы потоков данных (DFD - Data Flow Diagram) - основные средства моделирования функциональных требований проектируемой системы. С их помощью эти требования разбиваются на функциональные компоненты (процессы) и представляются в виде сети, связанной потоками данных. Главная цель таких Лист 15 15 средств - продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами [11]. DFD – это нотация, предназначенная для моделирования информационный систем с точки зрения хранения, обработки и передачи данных [12]. В соответствии с методологией модель системы определяется как иерархия диаграмм потоков данных, описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи пользователю. Диаграммы верхних уровней иерархии (контекстные диаграммы) определяют основные процессы или подсистемы АИС с внешними входами и выходами. Они детализируются с помощью диаграмм нижнего уровня. Декомпозиция, создавая многоуровневую иерархию диаграмм, продолжается до тех пор, пока не будет достигнут такой уровень, на котором процессы становятся элементарными и детализировать их далее невозможно [13]. Основные компоненты синтаксиса данного вида диаграммы представлены на рисунке 4.6 Рисунок 4.6 – Таблица синтаксиса DFD Подробная нотация синтаксиса DFD: 1) процесс (англ. Process), т.е. функция или последовательность действий, которые нужно предпринять, чтобы данные были обработаны. Это может быть создание заказа, регистрация клиента и т.д. В названиях процессов принято использовать глаголы, т.е. «Создать клиента» (а не «создание клиента») или «обработать заказ» (а не «проведение заказа»). Здесь нет строгой системы требований, как, например, в IDEF0 или BPMN, где нотации имеют жестко определенный синтаксис, так как они могут быть исполняемыми. Но все же определенных правил стоит придерживаться, чтобы не вносить путаницу при чтении DFD другими людьми; Лист 16 16 2) внешние сущности (англ. External Entity). Это любые объекты, которые не входят в саму систему, но являются для нее источником информации либо получателями какой-либо информации из системы после обработки данных. Это может быть человек, внешняя система, какие-либо носители информации и хранилища данных; 3) хранилище данных (англ. Data store). Внутреннее хранилище данных для процессов в системе. Поступившие данные перед обработкой и результат после обработки, а также промежуточные значения должны где-то храниться. Это и есть базы данных, таблицы или любой другой вариант организации и хранения данных. Здесь будут храниться данные о клиентах, заявки клиентов, расходные накладные и любые другие данные, которые поступили в систему или являются результатом обработки процессов; 4) поток данных (англ. Data flow). В нотации отображается в виде стрелок, которые показывают, какая информация входит, а какая исходит из того или иного блока на диаграмме [14]. Пример схемы информационных потоков в виде диаграммы потоков данных (DFD) представлен на рисунке 4.7. Рисунок 4.7 – Диаграмма потока данных Лист 17 17 5 Объектно-ориентированное проектирование информационной системы Проектирование каких-либо систем уделяет основное внимание правильному и эффективному структурированию сложных систем. Объектноориентированное проектирование (ООП) можно определить следующим образом. ООП – это методология проектирования, соединяющая в себе процесс объектной декомпозиции и приемы представления логической и физической, а также статической и динамической моделей проектируемой системы [15]. Из данного определения следует, что ООП основывается на объектной декомпозиции и использует многообразие приемов представления моделей, отражающих логическую (классы и объекты) и физическую (модули и процессы) структуры системы, а также статические и динамические аспекты. Именно объектно-ориентированная декомпозиция является основополагающим принципом ООП. При этом требования к проектируемой системе представляются с точки зрения классов и объектов, выявленных в предметной области. Логическая структура системы также отображается абстракциями в виде классов и объектов [16]. Объектно-ориентированная разработка программного обеспечения связана с применением объектно-ориентированных технологий. Обычно эти объектноориентированные методологии поддерживаются инструментальными программными средствами, но и без таких средств они полезны, так как позволяют хорошо понять различные аспекты и свойства разрабатываемой программной системы, что в последующем существенно облегчает ее реализацию, тестирование, сопровождение, разработку новых версий и более существенную модификацию [17]. Можно выделить следующие объектно-ориентированные методологии разработки программного обеспечения: 1) RUP (Rational Unified Process); 2) OMT (Object Modeling Technique); 3) SA/SD (Structured Analysis/Structured Design); 4) JSD (Jackson Structured Development); 5) OSA (Object-Oriented System Analysis). 5.1 Построение диаграммы прецедентов Диаграммы прецедентов составляют модель прецедентов (вариантов использования, use-cases). Прецедент — это функциональность системы, позволяющая пользователю получить некий значимый для него, ощутимый и измеримый результат. Каждый прецедент соответствует отдельному сервису, предоставляемому моделируемой системой в ответ на запрос пользователя, т. е. определяет способ использования этой системы. Именно по этой причине use cases, или прецеденты, часто в русской терминологии фигурируют как варианты использования. Варианты использования чаще всего применяются для спецификации внешних Лист 18 18 требований к проектируемой системе или для спецификации функционального поведения уже существующей системы. Кроме этого, варианты использования неявно описывают типичные способы взаимодействия пользователя с системой, позволяющие корректно работать с предоставляемыми системой сервисами. Сущность концепции прецедентов подразумевает несколько важных пунктов: 1) прецедент представляет собой завершенный фрагмент функциональных возможностей (включая основной поток логики управления, его любые вариации (под потоки) и исключительные условия (альтернативные потоки)); 2) фрагмент внешне наблюдаемых функций (отличных от внутренних функций); 3) ортогональный фрагмент функциональных возможностей (прецеденты могут при выполнении совместно использовать объекты, но выполнение каждого прецедента независимо от других прецедентов); 4) фрагмент функциональных возможностей, инициируемый субъектом. Будучи инициирован, прецедент может взаимодействовать с другими субъектами. При этом возможно, что субъект окажется только на принимающем конце прецедента, опосредованно инициированного другим субъектом [18]. Диаграмма прецедентов для выбранной нами информационной системы «Библиотека вуза», выполнена в программе Rational Rose и представлена на рисунке 5.1. Рисунок 5.1 – Диаграмма прецедентов Лист 19 19 На данной диаграмме видно, что читатель, который может быть 3 видов, участвует в большей части процессов, он может узнать справочную информацию о библиотечных материалах и о себе, при помощи персонала библиотеки оформить заказ или вернуть взятые материалы. 5.2 Построение диаграммы взаимодействия Целью диаграмм взаимодействия является визуализация интерактивного поведения системы. Визуализация взаимодействия — сложная задача. Следовательно, решение состоит в том, чтобы использовать различные типы моделей, чтобы охватить различные аспекты взаимодействия. Диаграмма взаимодействия наглядно отображает временной аспект взаимодействия. Она имеет два измерения. Одно измерение (слева-направо) указывает на порядок вовлечения экземпляров сущностей во взаимодействие. Крайним слева на диаграмме отображается экземпляр актера или объект, который является инициатором взаимодействия. Правее отображается другой экземпляр сущности, который непосредственно взаимодействует с первым и т.д. Второе измерение (сверху-вниз) указывает на порядок обмена сообщениями. Начальному моменту времени соответствует самая верхняя часть диаграммы. Так же диаграмму взаимодействий можно назвать UML диаграммой в нотации, которой взаимодействие элементов рассматривается в информационном аспекте их коммуникации. Другими словами, взаимодействующие объекты обмениваются между собой некоторой информацией. При этом информация представляет собой законченные сообщения. На рисунке 5.2 изображена диаграмма взаимодействия «Получение книги» Лист 20 20 Рисунок 5.2 - Диаграмма взаимодействия 5.3 Построение диаграммы активностей Диаграмма активностей – отражает динамические аспекты поведения системы, то есть отображает потоки работ во взаимосвязанных вариантах использования. По существу, эта диаграмма представляет собой блок – схему, которая наглядно показывает, как поток управления переходит от одной деятельности к другой. Диаграммы активностей позволяют реализовать в языке UML особенности процедурного и синхронного управления, обусловленного завершением внутренних действий и деятельности. Данная диаграмма была выполнена в программе Rational Rose на рисунке 5.3. Лист 21 21 Рисунок 5.3 - Диаграмма действий бизнес-процесса 5.4 Построение диаграммы классов Целью создания диаграммы классов является графическое представление статической структуры декларативных элементов системы (классов, типов и т. п.) Она содержит в себе также некоторые элементы поведения (например — операции), однако их динамика должна быть отражена на диаграммах других видов (диаграммах коммуникации, диаграммах состояний). Для удобства восприятия диаграмму классов можно также дополнить представлением пакетов, включая вложенные. При представлении сущностей реального мира разработчику требуется отразить их текущее состояние, их поведение и их взаимные отношения. На каждом этапе осуществляется абстрагирование от маловажных деталей и концепций, которые не должны относиться к реальной разработке и составлению диаграммы (производительность, инкапсуляция, видимость и т. п.). Классы можно рассматривать с позиции различных уровней. Как правило, их выделяют три основных: аналитический уровень, уровень проектирования и уровень реализации: 1) на уровне анализа класс содержит в себе только набросок общих контуров системы и работает как логическая концепция предметной области или программного продукта. Лист 22 22 2) на уровне проектирования класс отражает основные проектные решения касательно распределения информации и планируемой функциональности, объединяя в себе сведения о состоянии и операциях. 3) на уровне реализации класс дорабатывается до такого вида, в каком он максимально удобен для воплощения в выбранной среде разработки; при этом не воспрещается опустить в нём те общие свойства, которые не применяются на выбранном языке программирования [19]. При создании диаграммы классов важным моментом является реализация правильных связей между компонентами диаграммы. В каждом классе должен иметься первичный и вторичный ключ и стрелкой показана связь между классами. Связи могу быть следующих видов ассоциация, агрегация, наследование. Пример реализации диаграммы классов представлен на рисунке 5.4. Диаграмма была сделана в программе Rational Rose. Рисунок 5.4 - Диаграмма классов 5.5 Построение физической модели базы данных Для построения физической модели базы данных за основу была взята диаграмма классов, построенная в приложении Rational Rose по аналогии с представленной выше. После с помощью встроенных средств переноса данных программы Rational Rose, была произведена нормализация данных из построенной системы классов в понятный для СУБД MySQL Workbench вид. В конце было произведено создание базы данных на основе нормализированных данных и построение соответствующей диаграммы [20]. Лист 23 23 На рисунке 5.5 изображена физическая модель базы данных. Рисунок 5.5 – Физическая модель базы данных библиотеки вуза (часть 1) Рисунок 5.6 – Физическая модель базы данных библиотеки вуза (часть 2) 5.6 Построение диаграммы компонентов Лист 24 24 Диаграммы компонентов используются для визуализации организации компонентов системы и зависимостей между ними. Они позволяют получить высокоуровневое представление о компонентах системы. Компонентами могут быть программные компоненты, такие как база данных или пользовательский интерфейс; или аппаратные компоненты, такие как схема, микросхема или устройство; или бизнес-подразделение, такое как поставщик, платежная ведомость или доставка. Компонентные диаграммы: 1) Используются в компонентно-ориентированных разработках для описания систем с сервис-ориентированной архитектурой; 2) Показать структуру самого кода; 3) Может использоваться для фокусировки на отношениях между компонентами, скрывая при этом детализацию спецификации; 4) Помощь в информировании и разъяснении функций создаваемой системы заинтересованным сторонам. На рисунке 5.6 изображена диаграмма компонентов. Рисунок 5.6 – Диаграмма компонентов 5.7 Построение диаграммы размещения Диаграммы размещения используются для визуализации аппаратных процессоров/узлов/устройств системы, каналов связи между ними и размещения программных файлов на этом аппаратном обеспечении. Диаграммы размещения обычно включают в себя узлы, а также связи зависимости и ассоциации; подобно всем прочим диаграммам, могут содержать при- Лист 25 25 мечания и ограничения. На диаграммах размещения бывают представлены артефакты, каждый из которых должен располагаться на каком-нибудь узле, а кроме того, пакеты или подсистемы, – и те, и другие используются для группирования элементов модели в крупные блоки. Иногда бывает полезно поместить в диаграмму объектов еще и экземпляры, особенно если вы хотите визуализировать один экземпляр из семейства топологии аппаратных средств. Во многих отношениях диаграмма размещения является разновидностью диаграмм классов, фокусирующей внимание прежде всего на системных узлах. Диаграммы размещения используются для моделирования статического вида системы с точки зрения размещения. Это представление в первую очередь обращено на распределение, поставку и установку частей, из которых состоит физическая система. При моделировании статического представления системы с точки зрения размещения диаграммы размещения используются, как правило, в трех случаях: 1) Для моделирования встроенных систем. Встроенной (embedded) системой называется аппаратный комплекс, взаимодействующий с физическим миром, в котором велика роль программного обеспечения. Встроенные системы управляют двигателями, приводами и дисплеями, а сами управляются внешними воздействиями, например, датчиками температуры и перемещения. Диаграмму размещения можно использовать для моделирования устройств и процессоров, из которых состоит встроенная система. 2) Моделирование клиент-серверных систем. Клиент-серверная (client/server) система – это типичный пример архитектуры, где основное внимание уделяется четкому распределению обязанностей между интерфейсом пользователя, существующим на клиенте, и хранимыми данными системы, существующими на сервере. Клиент-серверные системы находятся на одном конце спектра распределенных систем и требуют от вас принятия решений о том, как связать клиенты и серверы сетью, а также о том, как физически распределены программные артефакты между узлами. Диаграммы размещения позволяют моделировать топологию такой системы. 3) Моделирование полностью распределенных систем. На другом конце спектра распределенных систем находятся те из них, которые распределены широко или даже глобально (fully distributed) и охватывают серверы различных уровней. Часто на таких системах устанавливаются разные версии программных компонентов, часть которых даже мигрирует с одного узла на другой. Проектирование подобной системы требует решений, которые допускают непрерывное изменение системной топологии. Диаграммы размещения можно использовать для визуализации текущей топологии и распределения артефактов системы, чтобы можно было осмысленно говорить о влиянии на нее различных изменений. Диаграмма размещения для информационной системы библиотеки вуза представлена на рисунке 5.7. Лист 26 26 Рисунок 5.7 – Диаграмма размещения Лист 27 27 Заключение При выполнении данной курсовой работы были созданы основные компоненты автоматизированной информационно системы «Библиотека вуза» при помощи современных средств и методов. Пере началом работы был составлен грамотный план выполнения курсовой с распределением времени, далее мы провели анализ предметной области, а также изучены и закреплены навыки проектирования и создания диаграмм системы с использованием современных CASE- средств необходимых для реализации построения всех видов диаграмм и схем. Далее мы приступили к созданию всех необходимых диаграмм. Для выполнения всех необходимых компонентов информационной системы были изучены основные принципы необходимых диаграмм, а также построены их реальные примеры. А именно следующие диаграммы: прецедентов, взаимодействия, активностей, классов, физическая модель базы данных, компонентов, размещения. Так же было проведено моделирование потоков данных, моделирование бизнес-процессов в методологии IDEF0. Так как целью данной курсовой работы как раз и заключалась во всем вышесказанном, можно считать, что все пункты были выполнены. Для построения всех видов диаграмм были использованы самые популярные и востребованные средства разработки, а именно такие программы как: IBM Rational Rose, MySQL Workbench, CASE-средство AllFusion Process Modeler. Лист 28 28 Список используемых источников 1. Афонин, А.М. Управление проектами: Учебное пособие. / А.М. Афонин, Ю.Н. Царегородцев, С.А. Петрова. - М.: Форум, 2010. - 184 c. 2. Марка, Д. Методология структурного анализа и проектирования. / Д. Марка. – М.: Мир, 2008 г. – 304 с. 3. Вендров, А. М. CASE-технологии. Современные методы и средства проектирования информационных систем. / А. М. Вендров. – М.: Финансы и статистика, 2009 г. – 758 с. Режим доступа: https://lib.samtuit.uz/uploads/files/61b76b19cd4526.72428427.pdf 4. Стасышин, В. М. Проектирование информационных систем и баз данных. / В.М. Стасышин. – Новосиб.: НГТУ, 2012. – 100 с. Режим доступа: https://znanium.com/catalog/document?id=132855 5. Заботина, Н. Н. Выбор методологии проектирования информационной системы: Учебное пособие / Н.Н. Заботина. – М.: НИЦ ИНФРА-М, 2015. – 154 с.: Режим доступа https://studbooks.net/2274489/informatika/vybor_metodologii_provana 6. Марка, Д. Методология структурного анализа и проектирования. / Д. Марка. – М.: Мир, 2008 г. – 304 с. Режим доступа: https://pqmonline.com/assets/files/lib/books/marka.pdf. 7. Калянов, Г.Н. CASE: структурный системный анализ (автоматизация и применение). / Г.Н. Калянов. - М.: ЛОРИ. 1996. 8. Михеев, Ростислав MS SQL Server 2005 для администраторов. / Р. Михеев; БХВ-Петербург М., 2007. 534 c. Режим доступа: https://www.labirint.ru/books/268213 9. Морган, С. Проектирование и оптимизация доступа к базам данных Microsoft SQL Server 2005. Учебный курс Microsoft (+ CD-ROM). / С. Морган Русская Редакция М., 2008. 445 c. Режим доступа: https://avidreaders.ru/book/proektirovanie-i-optimizaciya-dostupa-k-bazam.html 10. Нордфальт, Йенс Ритейл-маркетинг: Практики и исследования; Альпина Диджитал. / Йенс Нордфальт - М., 2015. - 224 c. Режим доступа: https://www.labirint.ru/books/481671 11. Похилько, А. Ф. CASE-технология моделирования процессов с использованием средств BPWin и ERWin: учебное пособие. / А. Ф. Похилько, И. В. Горбачев. – Ульяновск : УлГТУ, 2008. – 120 с. 12. Грехэм, И. Объектно-ориентированные методы. Принципы и практика. / И. Грехэм. - М.: «Вильямс», 2004. – 1024с. 13. Марка, Д. Методология структурного анализа и проектирования. / Д. Марка. – М. : Мир, 2008 г. – 304 с. 14. Похилько, А. Ф. CASE-технология моделирования процессов с использованием средств BPWin и ERWin: учебное пособие. / А. Ф. Похилько, И. В. Горбачев. – Ульяновск : УлГТУ, 2008. – 120 с. – ISBN 978-5-9795-0398-1. Режим доступа: https://scholar.google.com/citations?user=jvWa9J8AAAAJ&hl=en 15. Болодурина, И. П. Проектирование компонентов распределенных информационных систем : учеб. пособие для магистров. / И. П. Болодурина, Т. В. Лист 29 29 Волкова - М-во образования и науки Рос. Федерации, Федер. гос. бюджет. образоват. учреждение высш. проф. образования "Оренбург. гос. ун -т". – Оренбург : Университет, 2012. – 216 с. Режим доступа: https://www.iprbookshop.ru/30122 16. Леоненков, А. В. Объектно-ориентированный анализ и проектирование с использованием UML и IBM Rational Rose [Текст] : учебное пособие. / А. В. Леоненков. - Москва : Интернет-Ун-т Информ. Технологий : БИНОМ. Лаборатория знаний, 2013. - 320 с. : ил. - (Основы информационных технологий). - Библиогр.: с. 317-318. - ISBN 978-5-9556-0043-7. - ISBN 978-5-94774-408-8. 17. Соловьев, И.В. Проектирование информационных систем. Фундаментальный курс: Учебное пособие для высшей школы. / И.В. Соловьев, А.А. Майоров; под ред. В.П. Савиных. - М.: Академический проспект, 2009. - 398 c. 18. Дубенецкий, Б.Я. Проектирование информационных систем. / Б. Я. Дубенецкий. – Л. : ЛЭТИ, 2008 г. – 675 с. Режим доступа: https://etu.ru/sveden/files/RP/7909013/RPD_SpecVoprIsslModKIUS-17z.pdf 19. Бен-Ган, Ицик Microsoft SQL Server 2012. Основы T-SQL. / Ицик БенГан. - М.: Эксмо, 2012. - 167 c. Режим доступа: https://www.labirint.ru/books/471025 20. Мартишин, С.А. Проектирование и реализация баз данных в СУБД MySQL с использованием MySQL Workbench: Методы и средства проектирования информационных систем и технологий. Инструментальные средства информационных систем: Учебное пособие. / С.А. Мартишин, В.Л. Симонов, - М.: ИД ФОРУМ, НИЦ ИНФРА-М, 2012. - 160 c. Лист 30 30
