Курсовая работа по дисциплине: «Проектирование информационных систем». Курсовая работа Проектирование информационной системы магазина
 Скачать 235.04 Kb.
|
|
Курсовая работа «Проектирование информационной системы магазина» Выполнил Скориков А.С. Балаково 2013 2 СОДЕРЖАНИЕ Введение 3 1 Описание предметной области 5 1.1 Наименование и область применения 5 1.2 Технические требования 5 2 Выбор методологии проектирования 6 2.1 Методология SADT 6 2.2 Диаграммы потоков данных DFD (Data Flow Diagrams) 7 2.3 Методология объектного проектирования и анализа на языке UML 8 3 Реализация информационной системы с использованием выбранной методологии 10 3.1 Построение диаграммы вариантов использования (прецедентов) 10 3.2 Хранилище данных (ХД) 14 3.3 Построение диаграммы состояний 15 3.4 Построение диаграммы компонентов 17 3.5 Построение диаграммы размещения (развёртывания) 20 Заключение 21 Список использованных источников 22 Приложение А 23 3 ВВЕДЕНИЕ Развитие различных сфер человеческой деятельности на современном этапе невозможно без широкого применения вычислительной техники и созда- ния информационных систем различного направления. Обработка информации в подобных системах стала самостоятельным научно-техническим направлени- ем. После этапа построения информационной модели начинается проекти- рование системы. На этом этапе производится выбор технологических реше- ний, на основе которых будет построена информационная система. Информация в современном мире превратилась в один из наиболее важ- ных ресурсов, а информационные системы (ИС) стали необходимым инстру- ментом практически во всех сферах деятельности. В реальных условиях проек- тирование - это поиск способа, который удовлетворяет требованиям функцио- нальности системы средствами имеющихся технологий с учетом заданных ограничений. Разнообразие задач, решаемых с помощью ИС, привело к появлению множества разнотипных систем, отличающихся принципами построения и заложенными в них правилами обработки информации. Для успешной реализации проекта объект проектирования (ИС) должен быть прежде всего адекватно описан, должны быть построены полные и непро- тиворечивые функциональные и информационные модели ИС. Накопленный к настоящему времени опыт проектирования ИС показывает, что это логически сложная, трудоемкая и длительная по времени работа, требующая высокой квалификации участвующих в ней специалистов. Однако до недавнего времени проектирование ИС выполнялось в основном на интуитивном уровне с приме- нением неформализованных методов, основанных на искусстве, практическом опыте, экспертных оценках и дорогостоящих экспериментальных проверках качества функционирования ИС. Кроме того, в процессе создания и функцио- нирования ИС информационные потребности пользователей могут изменяться 4 или уточняться, что еще более усложняет разработку и сопровождение таких систем. Процесс разработки таких ИСУ основывается на моделировании дея- тельности предприятия, описании организации и методов ведения их бизнеса, построении архитектуры системы и структуры баз данных, обосновании систе- мы математических моделей и алгоритмов, реализации пользовательского ин- терфейса и выборе технических средств. Целью работы является построение модели информационной системы на примере магазина. 5 1 ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ 1.1 Наименование и область применения Наименование программного продукта – информационный ресурс для магазина «Бегемот». Данный интернет-ресурс предназначен для того, чтобы отображать достоверную информацию о магазине, связанного с продажей дет- ских игрушек, о наличии товара, который доступен для продажи, о компании, о адресах магазинов и схеме проезда. Пользователями информационного ресурса могут являться как сотрудни- ки магазина, так и обычные пользователи, которые хотят получить информа- цию и планируют посетить данный магазин. 1.2 Технические требования Информационный ресурс должен обеспечивать возможность выполнения функций авторизации администратора, загрузки существующего файла, про- смотра и редактирования содержимого сайта, считывания информации из базы данных (БД), а также отображения названия сайта, копирайта и комментариев разработчика. Выходные данные интернет-ресурса должны быть организованы в виде отдельных таблиц подключенной базы данных. Файлы должны размещаться (храниться) на локальных или съемных носителях, отформатированных соглас- но требованиям операционной системы. Интернет-ресурс должен обеспечивать взаимодействие с пользователем посредством графического пользовательского интерфейса, разработанного согласно рекомендациям компании-производителя операционной системы. 6 2 ВЫБОР МЕТОДОЛОГИИ ПРОЕКТИРОВАНИЯ 2.1 Методология SADT Методология SADT представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, то есть производимые им действия и связи между этими действиями. Основные элементы этой методологии основываются на следующих концепциях: - графическое представление блочного моделирования. Графика блоков и дуг SADT-диаграммы отображает функцию в виде блока, а интерфейсы входа/выхода представляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описываются посредством интерфейсных дуг, выражающих «ограничения», которые в свою очередь определяют, когда и каким образом функции выполняются и управляются; - строгость и точность. Выполнение правил SADT требует достаточной строгости и точности, не накладывая в то же время чрезмерных ограничений на действия аналитика. Правила SADT включают: - ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков); - связность диаграмм (номера блоков); - уникальность меток и наименований (отсутствие повторяющихся имен); - синтаксические правила для графики (блоков и дуг); - разделение входов и управлений (правило определения роли данных); - отделение организации от функции, то есть исключение влияния организационной структуры на функциональную модель. Методология SADT может использоваться для моделирования широкого круга систем и определения требований и функций, а затем для разработки системы, которая удовлетворяет этим требованиям и реализует эти функции. 7 Для уже существующих систем SADT может быть использована для анализа функций, выполняемых системой, а также для указания механизмов, посредством которых они осуществляются. Результатом применения методологии SADT является модель, которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы – это главные компоненты модели, все функции информационной системы и интерфейсы на них представлены как блоки и дуги. Место соединения дуги с блоком определяет тип интерфейса. Управляющая информация входит в блок сверху, в то время как информация, которая подвергается обработке, показана с левой стороны блока, а результаты выхода показаны с правой стороны. Механизм (человек или автоматизированная система), который осуществляет операцию, представляется дугой, входящей в блок снизу. Одной из наиболее важных особенностей методологии SADT является постепенное введение все больших уровней детализации по мере создания диаграмм, отображающих модель. 2.2 Диаграммы потоков данных DFD (Data Flow Diagrams) DFD-моделирование позволяет представить бизнес-процессы в виде формальных процедур описываемых стандартными средствами. Классическая DFD показывает внешние по отношению к системе источники и стоки (адресаты) данных, идентифицирует логические функции (процессы) и группы элементов данных, связывающие одну функцию с другой (потоки), а также идентифицирует хранилища (накопители) данных, к которым осуществляется доступ. Структуры потоков данных и определения их компонент хранятся и анализируются в словаре данных. Каждая логическая функция (процесс) может быть детализирована с помощью DFD нижнего уровня. Когда дальнейшая детализация перестает быть полезной, переходят к выражению логики функции при помощи спецификации процесса (мини-спецификации). 8 Основные символы и термины DFD: - потоки данных; - процесс; - хранилище (накопитель) данных; - внешняя сущность (или терминатор). Декомпозиция DFD осуществляется на основе декомпозиции процессов – каждый процесс может раскрываться с помощью DFD нижнего уровня. 2.3 Методология объектного проектирования и анализа на языке UML UML – это язык графического описания для объектного моделирования в области разработки программного обеспечения. UML является языком широкого профиля, это – открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML- моделью. UML был создан для определения, визуализации, проектирования и документирования, в основном, программных систем. UML не является языком программирования, но на основании UML-моделей возможна генерация кода. Использование UML не ограничивается моделированием программного обеспечения. Данный язык также используют для моделирования бизнес- процессов, системного проектирования и отображения организационных структур. UML позволяет разработчикам программного обеспечения достигнуть соглашения в графических обозначениях для представления общих понятий таких, как класс, компонент, обобщение, агрегация и поведение, а также больше сконцентрироваться на проектировании и архитектуре. В UML используются следующие виды диаграмм: 1) структурные диаграммы: - диаграмма классов; - диаграмма компонентов; - диаграмма композитной/составной структуры; 9 - диаграмма кооперации (UML 2.0); - диаграмма развёртывания; - диаграмма объектов; - диаграмма пакетов; - диаграмма профилей (UML 2.2). 2) диаграммы поведения: - диаграмма деятельности; - диаграмма состояний; - диаграмма вариантов использования. 3) диаграммы взаимодействия: - диаграмма коммуникации (UML 2.0); - диаграмма обзора взаимодействия (UML 2.0); - диаграмма последовательности; - диаграмма синхронизации (UML 2.0). Преимущества UML: 1) UML объектно-ориентирован, в результате чего методы описания результатов анализа и проектирования семантически близки к методам программирования на современных объектно-ориентированных языках; 2) UML позволяет описать систему практически со всех возможных точек зрения и разные аспекты поведения системы; 3) диаграммы UML сравнительно просты для чтения после достаточно быстрого ознакомления с его синтаксисом; 4) UML позволяет вводить собственные текстовые и графические стереотипы, а также применяется сфере программной инженерии; 5) UML получил широкое распространение и динамично развивается. 10 3 РЕАЛИЗАЦИЯ ИНФОРМАЦИОННОЙ СИСТЕМЫ С ИСПОЛЬЗОВАНИЕМ ВЫБРАННОЙ МЕТОДОЛОГИИ В данном курсовом проекте была использована методология объектного проектирования на языке UML для создания таких диаграмм, как: - диаграмма вариантов использования; - диаграмма состояний; - диаграмма компонентов; - диаграмма размещения. 3.1 Построение диаграммы вариантов использования (прецедентов) Для создания нового окна в IBM Rational Rose при запуске программы диалоговое окно появляется автоматически или при помощи вкладок «File – New», как показано на рисунке 1. Рисунок 1 – Окно создания новой модели Для создания действующего лица используется кнопка Actor, изображён- ная на рисунке 2. 11 Рисунок 2 – Создание действующего лица Двойным щелчком левой кнопки мыши по изображению действующего лица (актера) открывается меню «Спецификация», в котором в поле «Name» добавляется название актера, как показано на рисунке 3. Рисунок 3 – Присвоение имени действующему лицу Для создания варианта использования (прецедента) используется кнопка «Use Case», как показано на рисунке 4. Рисунок 4 – Создание прецедента 12 Двойным щелчком левой кнопки мыши по изображению прецедента при открытии меню «Спецификация» заполняем информацию во вкладках: - general – здесь задаются общие свойства варианта использования: имя (Name), стереотип (Stereotype), приоритет (Rank), является ли прецедент абст- рактным (Abstract) и текстовое описание прецедента (Documentation); - diagrams – здесь отображаются различные диаграммы, содержащие дан- ный прецедент; - relations – здесь отображаются все связи, в которых данный прецедент участвует; - files – добавление файлов, содержащих дополнительную информацию о классе. С помощью кнопки Unidirectional Association (однонаправленная ассоциация) панели инструментов создается ассоциация (связь) между актером и прецедентом, как показано на рисунке 5. Рисунок 5 – Создание связи между актером и прецедентом Для работы системы информационного ресурса магазина «Бегемот» на диаграмме вариантов использования были выделены следующие актёры: - пользователь системы – это как сотрудники магазина, так и обычные люди, которые просматривают информацию и получают сведения о магазине, а также имеющие ограничение доступа к системе; 13 - администратор системы – это человек, имеющий неограниченный дос- туп к системе, а также занимающейся поддержкой сайта. Далее рассмотрим, какие возможности должна предоставлять система: - актёр «Пользователь» использует систему для просмотра информацион- ного материала о данном магазине, а также для обратной связи; - актёр «Администратор» использует систему для авторизации при входе в администраторскую панель, а также для редактирования в ней различных компонентов, которые имеются в интернет-ресурсе. На основании вышеизложенного можно выделить следующие прецеден- ты: - выбор вкладки сайта – запускается пользователем системы. Позволяет выбрать любую вкладку при входе на главную страницу интернет-ресурса; - просмотр информационного материала – запускается пользователем системы. Позволяет просматривать информацию и получать сведения о данном магазине при входе на любую из вкладок, которые имеются на сайте; - обратная связь – запускается пользователем системы. Позволяет свя- заться с администратором сайта для получения прайс-листа, согласования оп- товых закупок или по другим вопросам сотрудничества; - авторизация – запускается администратором системы. Позволяет опре- делённому лицу при правильном наборе логина и пароля авторизоваться при входе в администраторскую панель; - редактирование интерфейса сайта – запускается администратором сис- темы. Позволяет внести изменения в интерфейс сайта; - редактирование содержимого сайта – запускается администратором сис- темы. Позволяет наполнить интернет-ресурс новым контентом, редактировать настройки публикации, создать новые и редактировать существующие типы материалов, просмотр всей информации на сайте, её редактирование и удаление и так далее; - редактирование базы данных (БД) – запускается администратором сис- темы. Позволяет изменять содержимое базы данных (БД); 14 - добавление и удаление страниц – запускается администратором систе- мы. Позволяет вносить изменения в страницы сайта, которые хранятся в базе данных (БД). Диаграмма вариантов использования изображена на рисунке 6. Рисунок 6 – Диаграмма вариантов использования, показывающая дейст- вия пользователей и администратора при входе на сайт 3.2 Хранилище данных Хранилище данных (Data warehouses) – это предметно-ориентированная информационная база данных или набор данных, предназначенный для поддержки принятия решений. Данные, поступающие в хранилище, как правило, доступны только для чтения. Хранилище данных информационного ресурса состоит из следующих таблиц: - таблица pages – в ней хранится информация о созданных страницах и тексте на сайте; - таблица images – в ней хранится информация о всех загруженных кар- тинках. Данные таблицы представлены на рисунках 7 и 8. 15 Рисунок 7 – Таблица pages Рисунок 8 – Таблица images 3.3 Построение диаграммы состояний Диаграммы состояний предназначены для моделирования различных со- стояний, в которых может находиться объект. В то время как диаграмма клас- сов показывает статическую картину классов и их связей, диаграммы состояний применяются при описании динамики поведения системы. Диаграммы состояний отображают поведение объекта. Построение диаграммы состояний в программном продукте IBM Rational Rose происходит следующим образом: - создание диаграммы состояний с помощью команд«New – Statechart Diagram»; - добавление таких компонентов как: State (состояния), Start State (нача- ло), End State (завершение), State Transition (состояние перехода). На диаграмме имеются два специальных состояния начальное и конечное. Начальное состояние выделяется черной точкой: оно соответствует состоянию объекта в момент его создания. Конечное состояние обозначается черной точкой в белом кружке: оно соответствует состоянию объекта непосредственно перед его уничтожением. На диаграмме состояний может быть одно и только одно начальное состояние. 16 Диаграмма состояний для вариантов использования, связанных с актёром «Администратор», показана на рисунке 9. Рисунок 9 – Диаграмма состояний для вариантов использования, связанных с актёром «Администратор» Диаграмма состояний для вариантов использования, связанных с актёром «Пользователь», показана на рисунке 10. 17 Рисунок 10 – Диаграмма состояний для вариантов использования, связан- ных с актёром «Пользователь» 3.4 Построение диаграммы компонентов Диаграмма компонентов показывает как выглядит модель на физическом уровне. На ней изображаются компоненты программного обеспечения системы и связи между ними. На диаграмме компонентов были выделены следующие объекты: База данных – организованная в соответствии с определёнными правила- ми и поддерживаемая в памяти компьютера совокупность данных, характери- зующая актуальное состояние некоторой предметной области и используемая для удовлетворения информационных потребностей пользователей. Данные, метаданные – содержат информацию о структуре данных (мета- данных). В реляционной СУБД метаданные включают в себя системные табли- 18 цы (отношения), имена отношений, имена атрибутов этих отношений и типы данных этих атрибутов. Компонента – некоторая абстрактная единица, которая обладает функ- циональностью, т. е. может выполнять определенные действия, связанные с решением поставленных задач. На основании вышеизложенного можно выде- лить следующие компоненты: - pages – таблица в базе данных, содержащая такие значения, как id, title и info. - images – таблица, содержащая id, photos и kind. - index.php – главный компонент информационного ресурса, объединяю- щий в себе остальные компоненты. - style.css – компонент, отвечающий за реализацию графического интер- фейса сайта. - dba.php – компонент, отвечающий за реализацию интерфейса с базой данных. - message.php – компонент, отвечающий за реализацию формы обратной связи. Добавление компонента на диаграмму осуществляется с помощью операции главного меню: «Tools – Create – Component» или с помощью операции контекстного меню: «New – Component». С помощью панели инструментов добавляем компоненты на диаграмму, как показано на рисунке 11 и 12. Рисунок 11 – Описание кнопок панели инструментов диаграммы компо- нентов в IBM Rational Rose 19 Рисунок 12 – Диаграмма компонентов после добавления компонента «Главная программа» Для каждого компонента можно определить различные свойства, такие как стереотип, язык программирования, декларации, реализуемые классы. Редактирование свойств компонента осуществляется с помощью диалогового окна спецификации свойств. Диаграмма компонентов информационного ресурса показана на рисунке 13. Рисунок 13 – Окончательный вид диаграммы компонентов информацион- ного ресурса 3.5 Построение диаграммы размещения (развёртывания) 20 Распределенная конфигурация системы моделируется с помощью диа- граммы размещения. Диаграмма размещения (развёртывания) отражает физические взаимосвя- зи между программными и аппаратными компонентами системы, а также явля- ется хорошим средством для того, чтобы показать маршруты перемещения объ- ектов и компонентов в распределенной системе. Каждый узел на диаграмме размещения представляет собой некоторый тип вычислительного устройства – в большинстве случаев часть аппаратуры. Данная аппаратура может быть простым устройством или датчиком, а может быть и большим компьютером. В целом диаграмму размещения (развёртывания) полезно применять, чтобы выделить особенные физические характеристики системы. Основные элементы отображены на рисунке 14. Рисунок 14 – Основные элементы для построения диаграммы размещения в IBM Rational Rose Диаграмма размещения (развёртывания) изображена на рисунке 15. На ней показано взаимодействие файлов. Файл *.css взаимодействует с клиентом на серверной стороне. Файлы *.php и *.sql также взаимодействуют на сервер- ной стороне, используя веб-сервер Apache и СУБД PHPMyAdmin соответствен- но. Рисунок 15 – Диаграмма размещения (развёртывания) 21 ЗАКЛЮЧЕНИЕ Проделав курсовой проект, были закреплены теоретические и практиче- ские знания, полученные на занятиях по дисциплине «Проектирование инфор- мационных систем». Процесс проектирования организационных систем основан на совмест- ном применении взаимодополняющих методов. Одной из важнейших задач управления на современном этапе является исследование и совершенствование методологии проектирования организационных систем в соответствии с изме- няющимися условиями. Проектирование – это деятельность человека или организации по созда- нию проекта, то есть прототипа, прообраза предполагаемого или возможного объекта, состояния; комплекта документации, предназначенной для создания определённого объекта, его эксплуатации, ремонта и ликвидации, а также для проверки или воспроизведения промежуточных и конечных решений, на основе которых был разработан данный объект. Проектирование может включать несколько этапов от подготовки техни- ческого задания до испытания опытных образцов. Объектом проектирования является проект материального предмета. Понятие проектирования не включает в себя стадию реализации проекта. Проектирование обладает своей методоло- гией, которая включает структуру деятельности, принципы и нормы деятельно- сти, субъектов, объект и его модели, методы и тому подобное. В данном курсо- вом проекте были выбраны наиболее подходящие методологии для создания диаграмм, отображающих основные компоненты и процессы программного продукта. 22 СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ 1. Буч, Г. UML: Руководство пользователя. / Г. Буч, Джекобсон И. и др. - М.: ДМК, 2008 г. – 356 с. 2. Фаулер, М. UML в кратком изложении. / М. Фаулер. - М.: Мир, 2009 г. – 204 с. 3. Марка, Д. Методология структурного анализа и проектирования. / Д. Мар- ка. - М.: Мир, 2008 г. – 304 с. 4. Вендров, А.М. CASE-технологии. Современные методы и средства проек- тирования информационных систем. / А.М. Вендров. - М.: Финансы и ста- тистика, 2009 г. – 758 с. 5. Калянов, Г.Н. CASE-технологии. / Г.Н. Калянов. - М.: Финансы и стати- стика, 2008 г. – 435 с. 6. Липаев, В.В. Системное проектирование сложных программных средств для информационных систем. / В.В. Липаев. - М.: Синтег, 2009 г. – 156 с. 7. Дубенецкий, Б.Я. Проектирование информационных систем. / Б.Я. Дубе- нецкий. - Л.: ЛЭТИ, 2008 г. – 675 с. 8. Грабер, М. Введение в SQL. / М. Грабер. - М.: ЛОРИ, 2008 г. – 568 с. 9. Шлеер, С. Объектно-ориентированный анализ: моделирование мира в со- стояниях. / С. Шлеер. - М.: Диалектика, 2008 г. – 476 с. 10. Зиндер, Е.З. Системное проектирование. / Е.З. Зиндер. - М.: Мир, 2009 г. – 535 с. |