VI Международная студенческая научная конференция Студенческий научный форум - 2014

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

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

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

Разнообразие задач, решаемых с помощью ИС, привело к появлению множества разнотипных систем, отличающихся принципами построения и заложенными в них правилами обработки информации.

Для успешной реализации проекта объект проектирования (ИС) должен быть прежде всего адекватно описан, должны быть построены полные и непротиворечивые функциональные и информационные модели ИС. Накопленный к настоящему времени опыт проектирования ИС показывает, что это логически сложная, трудоемкая и длительная по времени работа, требующая высокой квалификации участвующих в ней специалистов. Однако до недавнего времени проектирование ИС выполнялось в основном на интуитивном уровне с применением неформализованных методов, основанных на искусстве, практическом опыте, экспертных оценках и дорогостоящих экспериментальных проверках качества функционирования ИС. Кроме того, в процессе создания и функционирования ИС информационные потребности пользователей могут изменяться или уточняться, что еще более усложняет разработку и сопровождение таких систем. Процесс разработки таких ИСУ основывается на моделировании деятельности предприятия, описании организации и методов ведения их бизнеса, построении архитектуры системы и структуры баз данных, обосновании системы математических моделей и алгоритмов, реализации пользовательского интерфейса и выборе технических средств.

Целью работы является построение модели информационной системы на примере магазина.

1 ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ

1.1 Наименование и область применения

Наименование программного продукта – информационный ресурс для магазина «Бегемот». Данный интернет-ресурс предназначен для того, чтобы отображать достоверную информацию о магазине, связанного с продажей детских игрушек, о наличии товара, который доступен для продажи, о компании, о адресах магазинов и схеме проезда.

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

1.2 Технические требования

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

Выходные данные интернет-ресурса должны быть организованы в виде отдельных таблиц подключенной базы данных. Файлы должны размещаться (храниться) на локальных или съемных носителях, отформатированных согласно требованиям операционной системы. Интернет-ресурс должен обеспечивать взаимодействие с пользователем посредством графического пользовательского интерфейса, разработанного согласно рекомендациям компании-производителя операционной системы.

2 ВЫБОР МЕТОДОЛОГИИ ПРОЕКТИРОВАНИЯ

2.1 Методология SADT

Методология SADT представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, то есть производимые им действия и связи между этими действиями. Основные элементы этой методологии основываются на следующих концепциях:

- графическое представление блочного моделирования. Графика блоков и дуг SADT-диаграммы отображает функцию в виде блока, а интерфейсы входа/выхода представляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описываются посредством интерфейсных дуг, выражающих «ограничения», которые в свою очередь определяют, когда и каким образом функции выполняются и управляются;

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

- ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков);

- связность диаграмм (номера блоков);

- уникальность меток и наименований (отсутствие повторяющихся имен);

- синтаксические правила для графики (блоков и дуг);

- разделение входов и управлений (правило определения роли данных);

- отделение организации от функции, то есть исключение влияния организационной структуры на функциональную модель.

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

Результатом применения методологии SADT является модель, которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы – это главные компоненты модели, все функции информационной системы и интерфейсы на них представлены как блоки и дуги. Место соединения дуги с блоком определяет тип интерфейса. Управляющая информация входит в блок сверху, в то время как информация, которая подвергается обработке, показана с левой стороны блока, а результаты выхода показаны с правой стороны. Механизм (человек или автоматизированная система), который осуществляет операцию, представляется дугой, входящей в блок снизу.

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

2.2 Диаграммы потоков данных DFD (Data Flow Diagrams)

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

Основные символы и термины DFD:

- потоки данных;

- процесс;

- хранилище (накопитель) данных;

- внешняя сущность (или терминатор).

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

2.3 Методология объектного проектирования и анализа на языке UML

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

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

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

В UML используются следующие виды диаграмм:

1. структурные диаграммы:

- диаграмма классов;

- диаграмма компонентов;

- диаграмма композитной/составной структуры;

- диаграмма кооперации (UML 2.0);

- диаграмма развёртывания;

- диаграмма объектов;

- диаграмма пакетов;

- диаграмма профилей (UML 2.2).

1. диаграммы поведения:

- диаграмма деятельности;

- диаграмма состояний;

- диаграмма вариантов использования.

1. диаграммы взаимодействия:

- диаграмма коммуникации (UML 2.0);

- диаграмма обзора взаимодействия (UML 2.0);

- диаграмма последовательности;

- диаграмма синхронизации (UML 2.0).

Преимущества UML:

1. UML объектно-ориентирован, в результате чего методы описания результатов анализа и проектирования семантически близки к методам программирования на современных объектно-ориентированных языках;

2. UML позволяет описать систему практически со всех возможных точек зрения и разные аспекты поведения системы;

3. диаграммы UML сравнительно просты для чтения после достаточно быстрого ознакомления с его синтаксисом;

4. UML позволяет вводить собственные текстовые и графические стереотипы, а также применяется сфере программной инженерии;

5. UML получил широкое распространение и динамично развивается.

3 РЕАЛИЗАЦИЯ ИНФОРМАЦИОННОЙ СИСТЕМЫ

с использованием выбранной методологии

В данном курсовом проекте была использована методология объектного проектирования на языке UML для создания таких диаграмм, как:

- диаграмма вариантов использования;

- диаграмма состояний;

- диаграмма компонентов;

- диаграмма размещения.

3.1 Построение диаграммы вариантов использования (прецедентов)

Для создания нового окна в IBM Rational Rose при запуске программы диалоговое окно появляется автоматически или при помощи вкладок «File – New», как показано на рисунке 1.

Рисунок 1 – Окно создания новой модели

Для создания действующего лица используется кнопка Actor, изображённая на рисунке 2.

Рисунок 2 – Создание действующего лица

Двойным щелчком левой кнопки мыши по изображению действующего лица (актера) открывается меню «Спецификация», в котором в поле «Name» добавляется название актера, как показано на рисунке 3.

Рисунок 3 – Присвоение имени действующему лицу

Для создания варианта использования (прецедента) используется кнопка «Use Case», как показано на рисунке 4.

Рисунок 4 – Создание прецедента

Двойным щелчком левой кнопки мыши по изображению прецедента при открытии меню «Спецификация» заполняем информацию во вкладках:

- general – здесь задаются общие свойства варианта использования: имя (Name), стереотип (Stereotype), приоритет (Rank), является ли прецедент абстрактным (Abstract) и текстовое описание прецедента (Documentation);

- diagrams – здесь отображаются различные диаграммы, содержащие данный прецедент;

- relations – здесь отображаются все связи, в которых данный прецедент участвует;

- files – добавление файлов, содержащих дополнительную информацию о классе.

С помощью кнопки Unidirectional Association (однонаправленная ассоциация) панели инструментов создается ассоциация (связь) между актером и прецедентом, как показано на рисунке 5.

Рисунок 5 – Создание связи между актером и прецедентом

Для работы системы информационного ресурса магазина «Бегемот» на диаграмме вариантов использования были выделены следующие актёры:

- пользователь системы – это как сотрудники магазина, так и обычные люди, которые просматривают информацию и получают сведения о магазине, а также имеющие ограничение доступа к системе;

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

Далее рассмотрим, какие возможности должна предоставлять система:

- актёр «Пользователь» использует систему для просмотра информационного материала о данном магазине, а также для обратной связи;

- актёр «Администратор» использует систему для авторизации при входе в администраторскую панель, а также для редактирования в ней различных компонентов, которые имеются в интернет-ресурсе.

На основании вышеизложенного можно выделить следующие прецеденты:

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

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

- обратная связь – запускается пользователем системы. Позволяет связаться с администратором сайта для получения прайс-листа, согласования оптовых закупок или по другим вопросам сотрудничества;

- авторизация – запускается администратором системы. Позволяет определённому лицу при правильном наборе логина и пароля авторизоваться при входе в администраторскую панель;

- редактирование интерфейса сайта – запускается администратором системы. Позволяет внести изменения в интерфейс сайта;

- редактирование содержимого сайта – запускается администратором системы. Позволяет наполнить интернет-ресурс новым контентом, редактировать настройки публикации, создать новые и редактировать существующие типы материалов, просмотр всей информации на сайте, её редактирование и удаление и так далее;

- редактирование базы данных (БД) – запускается администратором системы. Позволяет изменять содержимое базы данных (БД);

- добавление и удаление страниц – запускается администратором системы. Позволяет вносить изменения в страницы сайта, которые хранятся в базе данных (БД).

Диаграмма вариантов использования изображена на рисунке 6.

Рисунок 6 – Диаграмма вариантов использования, показывающая действия пользователей и администратора при входе на сайт

3.2 Хранилище данных

Хранилище данных (Data warehouses) – это предметно-ориентированная информационная база данных или набор данных, предназначенный для поддержки принятия решений. Данные, поступающие в хранилище, как правило, доступны только для чтения.

Хранилище данных информационного ресурса состоит из следующих таблиц:

- таблица pages – в ней хранится информация о созданных страницах и тексте на сайте;

- таблица images – в ней хранится информация о всех загруженных картинках.

Данные таблицы представлены на рисунках 7 и 8.

Рисунок 7 – Таблица pages

Рисунок 8 – Таблица images

3.3 Построение диаграммы состояний

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

Диаграммы состояний отображают поведение объекта.

Построение диаграммы состояний в программном продукте IBM Rational Rose происходит следующим образом:

- создание диаграммы состояний с помощью команд«New – Statechart Diagram»;

- добавление таких компонентов как: State (состояния), Start State (начало), End State (завершение), State Transition (состояние перехода).

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

Диаграмма состояний для вариантов использования, связанных с актёром «Администратор», показана на рисунке 9.

Рисунок 9 – Диаграмма состояний для вариантов использования, связанных с актёром «Администратор»

Диаграмма состояний для вариантов использования, связанных с актёром «Пользователь», показана на рисунке 10.

Рисунок 10 – Диаграмма состояний для вариантов использования, связанных с актёром «Пользователь»

3.4 Построение диаграммы компонентов

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

На диаграмме компонентов были выделены следующие объекты:

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

Данные, метаданные – содержат информацию о структуре данных (метаданных). В реляционной СУБД метаданные включают в себя системные таблицы (отношения), имена отношений, имена атрибутов этих отношений и типы данных этих атрибутов.

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

- 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

Рисунок 12 – Диаграмма компонентов после добавления компонента «Главная программа»

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

Диаграмма компонентов информационного ресурса показана на рисунке 13.

Рисунок 13 – Окончательный вид диаграммы компонентов информационного ресурса

3.5 Построение диаграммы размещения (развёртывания)

Распределенная конфигурация системы моделируется с помощью диаграммы размещения.

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

Каждый узел на диаграмме размещения представляет собой некоторый тип вычислительного устройства – в большинстве случаев часть аппаратуры.

Данная аппаратура может быть простым устройством или датчиком, а может быть и большим компьютером.

В целом диаграмму размещения (развёртывания) полезно применять, чтобы выделить особенные физические характеристики системы.

Основные элементы отображены на рисунке 14.

Рисунок 14 – Основные элементы для построения диаграммы размещения в IBM Rational Rose

Диаграмма размещения (развёртывания) изображена на рисунке 15. На ней показано взаимодействие файлов. Файл *.css взаимодействует с клиентом на серверной стороне. Файлы *.php и *.sql также взаимодействуют на серверной стороне, используя веб-сервер Apache и СУБД PHPMyAdmin соответственно.

Рисунок 15 – Диаграмма размещения (развёртывания)

ЗАКЛЮЧЕНИЕ

Проделав курсовой проект, были закреплены теоретические и практические знания, полученные на занятиях по дисциплине «Проектирование информационных систем».

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

Проектирование – это деятельность человека или организации по созданию проекта, то есть прототипа, прообраза предполагаемого или возможного объекта, состояния; комплекта документации, предназначенной для создания определённого объекта, его эксплуатации, ремонта и ликвидации, а также для проверки или воспроизведения промежуточных и конечных решений, на основе которых был разработан данный объект.

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

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 с.

Код для цитирования: Скопировать