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

ВВЕДЕНИЕ

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

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

проектирование объектов данных, которые будут реализованы в базе данных;

проектирование программ, экранных форм, отчетов, которые будут обеспечивать выполнение запросов к данным;

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

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

Целью данной курсового проекта является изучение возможностей IBM rational rose, проектирование информационно-справочной системы для предприятия с поддержкой веб-интерфейса.

1 АНАЛИЗ МЕТОДОВ ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННО-СПРАВОЧНОЙ СИСТЕМЫ

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

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

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

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

CASE-технология обеспечивает автоматическую верификацию и контроль проекта на полноту и состоятельность на ранних этапах разработки, что влияет на успех разработки в целом - по статистическим данным анализа пяти крупных проектов фирмы TRW (США) ошибки проектирования и кодирования составляют соответственно 64% и 32% от общего числа ошибок, а ошибки проектирования в сто раз труднее обнаружить на этапе сопровождения ПО, чем на этапе анализа требований.

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

Для реализации модели созданной при использований CASE технологий будут использованы средства языка UML.

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

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

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

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

Разработка объектно-ориентированной модели ИСС начинается с выбора необходимого программного продукта. В данном случае эти продуктом является IBM Rational Rose.

IBM Rational Rose - популярное средство визуального моделирования, которое считается стандартом де-факто среди средств визуального проектирования приложений. Этот продукт входит в состав пакета IBM Rational Suite и предназначен для моделирования программных систем с использованием широкого круга инструментальных средств и платформ. Инструментальное средство IBM Rational Rose расширяет возможности моделирования программных систем, выходящих за рамки платформы J2EE и инструментальных средств моделирования в составе IBM Rational Professional Bundle.

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

Для проектирования информационно-справочной системы для предприятия «Волга-строй М» используются несколько видов диаграмм: вариантов использования, последовательностей, компонентов, состояний.

Диаграмма вариантов использования или диаграммами (use-case) прецедентов предложена фирмой Rational и входит в стандарт языка UML. Вариант использования представляет собой типичное взаимодействие пользователя и проектируемой системы. Варианты использования характеризуются рядом свойств: охватывают некоторую очевидную для пользователей функцию; могут быть как небольшими, так и достаточно крупными; решают некоторую дискретную задачу пользователя.

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

Для описания поведения ИСС использована диаграмма состояний, которая определяет все возможные состояния, в которых может находиться конкретный объект, а также процесс смены состояний объекта в результате влияния некоторых событий. Основной единицей, связывающей несколько состояний, является переход. Переход может содержать метку. Синтаксически метка перехода состоит из трех частей, каждая из которых является необязательной: [< Условие>]/< Действие >. Если метка перехода не содержит никакого события, это означает, что переход происходит, как только завершается какая-либо деятельность, связанная с данным состоянием.

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

Существует два особых состояния: вход и выход. Любое действие, связанное с событием входа, выполняется, когда объект входит в данное состояние. Событие выхода выполняется в том случае, когда объект выходит из данного состояния.

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

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

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

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

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

2 ФУНКЦИОНАЛЬНЫЙ АНАЛИЗ ДЕЯТЕЛЬНОСТИ ПРЕДПРИЯТИЯ

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

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

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

Для анализа планирования работы на предприятии, необходимо рассмотреть основные принципы планирования деятельности предприятия.

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

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

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

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

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

3 РАЗРАБОТКА UML ДИАГРАММ

Для создания вышеописанных диаграмм будет использована программная среда IBM rational rose enterprise edition. На рисунке 1 приведена диаграмма вариантов использования проектируемой ИСС.

Рисунок 1 - Диаграмма вариантов использования

На диаграмме вариантов использования присутствуют два действующих лица: «Пользователь» и «Администратор». Пользователей может быть много, но с точки зрения системы они выполняют одну и ту же роль. На данной диаграмме присутствуют так же семь вариантов использования: «Регистрация», «Авторизация», «Редактирование базы данных», «Добавление в базу данных» «Запрос требований (по критериям)», «Получение результатов», «Сохранение базы данных».

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

Для действующего лица «Преподаватель» в системе реализовано три варианта использования: «Авторизация», «Заполнение базы данных (рабочие программы дисциплин)» и «Редактирование базы данных». Вариант использования «Авторизация» предполагает ввод логина и пароля пользователями, зарегистрированным в системе.

В свою очередь, для действующего лица «Пользователь» в системе реализовано четыре варианта использования: «Регистрация», «Авторизация», «Запрос требований (по критериям)», а так же «Получение результатов». Вариант использования «Авторизация», так же как и у действующего лица «Программист» предполагает ввод логина и пароля, зарегистрированного в системе.

Вариант использования «Запрос требований (по критериям)» реализует возможность создания запроса с одним или несколькими критериями.

Вариант использования «Получения результатов» реализует возможность вывода результатов варианта использования «Запрос требований (по критериям)».

На рисунке 2 приведена диаграмма последовательности для группы вариантов использования, ассоциированных с актером «Пользователь» для проектируемой ИСС.

Рисунок 2 - Диаграмма последовательности для группы вариантов использования, ассоциированных с актером «Пользователь»

На рисунке 3 приведена диаграмма последовательности для группы вариантов использования, ассоциированных с актером «Администратор» для проектируемой ИСС.

Рисунок 3 - Диаграмма последовательности для группы вариантов использования, ассоциированных с актером «Администратор»

Данные диаграммы последовательности описывают последовательности, в которых объекты: «Администратор», «Пользователь», «Окно регистрации», «Окно авторизации», «Окно поиска», «Список результатов», «БД» отправляют и получают сообщения. Диаграмма последовательностей считается более понятным и более выразительным способом моделирования взаимодействий.

На рисунке 4 представлена диаграмма состояний проектируемой ИСС

Рисунок 4 - Диаграмма состояний

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

Процесс начинается с начальной точки, затем следует самый первый переход в состояние «Загрузка страницы». Далее система переходит в состояние «Ожидание авторизации» Из состояния «Ожидание авторизации» система переходит в (состояние) условие «Поиск пользователя в БД». Из этого состояния возможны два перехода: 1) если пользователь не найден, то происходит переход в состояние «Загрузка страницы регистрации», затем система переходит в состояние «Заполнение регистрационных данных», после заполнения система переходит в состояние «Регистрация пользователя в БД», после этого система вновь возвращается к состоянию «Ожидание авторизации», где новый зарегистрированный пользователь может войти в систему под своим логином и паролем; 2) если пользователь найден, то система переходит в (состояние) условие «определение уровня доступа», которое в свою очередь имеет два перехода: а1) Состояние «авторизирован администратор», из которого следует переход в состояние «Загрузка страницы администратора», далее система переходит в состояние «ожидание действий администратора», после этого система вновь переходит в (условие) состояние «Выбор редактирования БД», которое имеет два перехода: б1) Состояние «Редактирование существующих данных», после которого следует состояние «Ожидание запроса редактирования БД», после этого система переходит в состояние «Редактирование БД», следующим состоянием этого перехода (ветки) является «сохранение изменений БД», затем следует предпоследнее состояние системы «Завершение сеанса», после этого система переходит к концу; б2) Состояние «Ввод новых данных», после этого система переходит в состояние «Внесение новых данных в БД», следующим состоянием этого перехода (ветки) является «сохранение изменений БД», затем следует предпоследнее состояние системы «Завершение сеанса», после этого система переходит к концу; а2) Состояние «Авторизирован пользователь», из этого состояние система переходит в «Ожидание запроса просмотра БД», следующие состояние системы «Заполнение формы запроса», далее система переходит в состояние «Вывод результатов запроса» затем следует предпоследнее состояние системы «Завершение сеанса», после этого система переходит к концу.

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

На рисунке 5 приведена диаграмма компонентов для проектируемой ИСС

Рисунок 5 - Диаграмма компонентов

Для представления физических сущностей в языке UML применяется специальный термин - компонент. Компонент реализует некоторый набор интерфейсов и служит для общего обозначения элементов физического представления модели. Для графического представления компонентов «Интерфейс пользователя», «Интерфейс администратора» используется специальный символ - прямоугольник со вставленными слева двумя более мелкими прямоугольниками. Внутри большого прямоугольника записывается имя компонента и, при необходимости, некоторая дополнительная информация.

Спецификация задачи графически представлена как параллелограмм с вставленными слева тремя мелкими прямоугольниками. Он содержит в себе операцию «Работа с БД», которая предполагает использоваться в независимом потоке управления.

Спецификация подпрограммы графически представляется в виде прямоугольника и содержит описание переменных «ИСС».

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

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

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

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

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

ЗАКЛЮЧЕНИЕ

В ходе работы над данным курсовым проектом были проанализированы теоретические основы проектирования информационно-справочных систем. В результате анализа было определено значение информационно-справочных компонентов в корпоративных информационных системах и рассмотрены этапы проектирования информационно-справочных систем. Также были изучены основы работы в IBM rational rose enterprise edition и определена предметная область, основные сущности БД, информация о которых должна содержаться в базе данных.

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

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

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

1. Арлоу Д., Нейштадт И. UML 2 и Унифицированный процесс / Д. Арлоу, И. Нейштадт. - СПб.: Символ-Плюс, 2007. - 624 с.

2. Баласянов В.С. Концепция внедрения информационной системы предприятия // Открытые системы - 2008.

3. Блюмин А. М. Проектирование систем информационного, консультационного и инновационного обслуживания/ Блюмин А. М., Печеная Л. Т., Феоктистов Н. А. -М.: Издательский дом Дашков и К, 2009 - 352 с.

4. Гвоздева Т. Проектирование информационных систем /Т.Гвоздева - М.: Феникс, 2009, - 354 с.

5. Заботина Н.Н. Проектирование информационных систем: Учебное пособие / Заботина Н.Н. -Братск: Филиал ГОУВПО «БГУЭП», 2007.-Ч.1 - 146 с.

6. Заботина Н.Н. Проектирование информационных систем: Учебное пособие / Заботина Н.Н. -Братск: Филиал ГОУВПО «БГУЭП», 2007.-Ч.2 - 132 с.

7. Сорокин А.А. Проектирование экономических информационных систем: Учебник для/ Смирнова Г.Н., Сорокин А.А., Тельнов Ю.Ф.- М: Финансы и статистика, - 2003. - 512 с.

8. CA Erwin Process Modeler [Электронный ресурс]: [справочный листок]. - Информационно-справочные системы, 2011. - Режим доступа: http:// www.v8.1c.ru/

9. ITru [Электронный ресурс]: [справочный листок]. - Моделирование ИС, 2011. - Режим доступа: http:// www.it.ru/

10. Крылович А.В. [Электронный ресурс]: [справочный листок].- Информационные технологии в управлении предприятии.// Открытые системы, 2009. Режим доступа http://www.osp.ru/cio/2008/07/38319/

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