Проектирование автоматизированной системы обеспечения работы редакции

Размещено на http://www.allbest.ru/

43

Размещено на http://www.allbest.ru/

Министерство высшего образования Российской Федерации

Государственное бюджетное образовательное учреждение высшего

профессионального образования Московской области «Международный

университет природы, общества и человека «Дубна»

(университет «Дубна»)

Филиал Протвино

Курсовая работа

по дисциплине: «Проектирование экономических информационных систем»

на тему

Проектирование автоматизированной системы обеспечения работы редакции

Выполнила: студентка V курса

Группы ПИ-071

Гиренко К.

Протвино - 2011

Содержание

• 1. Разработка проекта системы
• 1.1 Определение концепции системы
• 1.2 Глоссарий проекта системы
• 1.3 Дополнительная спецификация системы
• 1.4 Способ реализации системы
• 2. Реализация проекта
• 2.1 Разработка модели системы
• 2.2 Анализ модели
• 2.2.1 Архитектурный анализ
• 2.2.2 Анализ вариантов использования
• 2.3 Проектирование системы
• 2.3.1 Проектирование архитектуры системы
• 2.3.2 Проектирование элементов системы
• 2.3.3 Проектирование физической реализации системы
• 2.4 Реализация системы
• Заключение
• Список используемой литературы
• 1. Разработка проекта системы
• Для повышения эффективности работы отдела редакции издательства руководством было принято решение о необходимости разработки и внедрения автоматизированной системы поддержки работы сотрудников отдела редакции.
• Разрабатываемая автоматизированная система должна обеспечить возможность обмена и согласования данных между сотрудниками редакции путем создания единой системы обработки и распределения информации и требований между сотрудниками редакции. Главное требование предъявляемое к разрабатываемой системе - поддержка обмена и согласования данных без непосредственного контакта между участниками.
• Цель разработки автоматизированной системы - повышение эффективности работы редакции издательства за счет сокращения времени на обмен информацией, согласование макетов полос и газеты, распределение заданий между сотрудниками системы.
• 1.1 Определение концепции системы
• Для повышения эффективности работы отдела редакции издательства руководством было принято решение о необходимости разработки и внедрения автоматизированной системы поддержки работы сотрудников отдела редакции.
• Разрабатываемая автоматизированная система должна обеспечить возможность обмена и согласования данных между сотрудниками редакции путем создания единой системы обработки и распределения информации и требований между сотрудниками редакции.
• Автоматизированная система обеспечения работы отдела редакции предполагает наличие нескольких хранилищ данных, доступ к которым разграничен в соответствии с компетенцией сотрудника. Работа в автоматизированной системе организована следующим образом:
• 1. Главный редактор определяет концепцию номера газеты, которая вносится в базу временного хранения файлов.
• 2. На основании плана газеты главный редактор распределят задания между журналистами и фотографами на подготовку информации для написания полос газеты.
• 3. Статьи журналистов и фотографии вносятся в базу данных, предназначенную для временного хранения файлов ( статьи и фотографии после выхода номера газеты перемещаются в архив).
• 4. Наборщик на основании информации, собранной в базе статей и фотографий, производит компоновку полос газеты, которые вносятся в каталог заготовок полос.
• 5. Литературный редактор проводит литературную редактуру полос в каталоге заготовок полос.
• 6. Главный редактор проводит утверждение полос для номера газеты в соответствии с концепцией газеты.
• 7. Ответственный секретарь разрабатывает макет газеты на основании утвержденных главным редактором полос. Макет газеты утверждается главным редактором, после чего ответственный секретарь отправляет макет на верстку.
• Особенностью проектируемой системы является то, что в составе системы существуют три базы данных, предназначенные для краткосрочного хранения файлов -файлов, связанных с номером газеты, готовящимся к выпуску. После выпуска номера газеты, все материалы из баз данных перемещаются в архив- базу данных для постоянного хранения файлов.
• Работа в такой автоматизированной системе предполагает работу каждого сотрудника только с информацией в каталогах, т.е. каждый участник проводит корректировку информации в рамках своей компетенции, таким образом создается конечный макет газеты, который утверждается и отправляется в печать.
• Создание автоматизированной системы обеспечения работы отдела редакции должно обеспечить минимальное время на обработку информации, поскольку согласование полос, макетов, статей осуществляется непосредственно на рабочем месте специалиста.
• 1.2 Глоссарий проекта системы
• В ходе анализа предметной области разрабатываемой информационной системы был разработан перечень терминов будущей системы. Глоссарий проекта позволяет выделить основные понятия данной системы и в дальнейшем может быть использован как словарь данных системы.
• Исходя из анализа предметной области в качестве данных для автоматизированной системы обеспечения работы редакции можно выделить следующие понятия:
• v Главный редактор - лицо, ответственное за разработку плана газеты:
• · Определение концепции газеты;
• · Определение набора полос и их состава в соответствии с концепцией газеты
• · Утверждение плана газеты;
• На основании утвержденного плана газеты главный редактор распределяет задания по сбору материала, подготовке полос и разработке макета газеты между сотрудниками редакции. Кроме того, главный редактор утверждает состав и структуру полос, включаемых в макет газеты, а также утверждает макет газеты, которая затем направляется на верстку.
• v Журналист - штатный сотрудник газеты. На основании полученного задания с указанием тематики и сроков подготовки материала, производит сбор необходимой информации и написание статьи к текущему номеру газеты.
• v Фотограф - штатный сотрудник отдела редакции. В соответствии с тематикой задания главного редактора формирует фотографии.
• v Рабочие файлы - база данных для временного хранения статей и фотографий к создаваемом номеру газеты. Все статьи и фотографии в базе хранятся до даты выпуска номера в продажу, после чего и статьи и фотографии перемещаются в архив.
• v Архив - база данных для хранения рабочих файлов, проектных документов и заготовок статей. Данные хранятся в базе в течение 5 лет, после чего удаляются.
• v Наборщик - сотрудник редакции. Наполняет полосы газеты информацией, выбирая данные из базы временных файлов: «рабочих файлов». Сформированные полосы направляются в базу данных заготовок полос.
• v Заготовки полос - база данных для временного хранения подготовленных и скорректированных заготовок полос, которые затем утверждаются главным и редактором и включаются в разрабатываемый макет газеты.
• v Литературный редактор - сотрудник организации, проводящий литературную обработку заготовок полос в базе данных заготовок полос.
• v Ответственный секретарь - сотрудник редакции, разрабатывающий макет газеты на основе утвержденных главным редактором полос из каталога заготовок полос. Макет газеты утверждается главным редактором, после чего макет передается на верстку в следующий отдел редакции.
• v Газета - печатное периодическое издание, в котором публикуются материалы определенной тематики ( в случае тематической газеты), сведения о текущих событиях.
• v Полоса - раздел газеты, представляющий собой оттиск страницы газеты.
• v Статья - информационное сообщение определенной тематики.
• v Макет газеты - предварительный образец газеты, которая будет выпущена в тираж.
• v Концепция газеты - определение содержания номера газеты, тем статей, включаемых в газету, состава колонок и полос.
• Перечисленные понятия предметной области затем будут использованы для определения структуры будущей системы, выделения основных ее компонентов.
• Основное требование, предъявляемое к системе - поддержка многоуровневой обработки информации путем создания каталогов рабочих документов, рассмотрение, корректировка и утверждение которых не требует контакта между сотрудниками редакции. Декомпозиция функционального требования предполагает распределение задач между сотрудниками редакции. В конечно итоге, набор функций выполняемых каждым сотрудником и составит перечень функциональных требований, которые будут заложены в модель системы.
• Однако, при разработке проекта автоматизированной системы необходимо выделить определенный набор нефункциональных требований, предъявляемых к системе.
• 1.3 Дополнительная спецификация системы
• Целью выделения нефункциональных требований (спецификаций), предъявляемых к системе является определение параметров ее функционирования, соблюдение которых должно обеспечить выполнений всех базовых функций системы с определенным уровнем качества.
• Разобьем нефункциональные требования, предъявляемые к автоматизированной системе на несколько групп:
• I. Функциональные возможности:
• Ш Разрабатываемая система должна поддерживать возможность работы с базами данных одновременно множества пользователей.
• Ш При редактировании заготовок полос литературным редактором, редактируемые полосы должны быть недоступны для всех остальных пользователей базы данных;
• Ш При обращении главного редактора к базе данных заголовок полос система должна выводить только те заготовки, которые уже были отредактированы литературным редактором. В том случае если заготовки полос, относящиеся к подготавливаемому номеру газеты еще не были отредактированы, то система должна оповещать главного редактора об отсутствии в базе данных отредактированных заготовок полос.
• Ш Система должна устанавливать пометки утвержденных главным редактором полос в базе данных, для адекватного отбора заготовок при разработке макета газеты;
• Ш Система должна отслеживать наличие пометки « утверждено» на макете газеты при передаче макета на верстку.
• II. Удобство:
• Ш Пользовательский интерфейс системы должен быть совместим с операционными системами: Windows и Linux.
• Ш В системе должен поддерживаться диалоговый режим взаимодействия.
• III. Производительность:
• Ш Система должна поддерживать одновременную работу с ней до 20 человек.
• Ш Среднее время передачи данных между компонентами сети должно составлять не более 0,5 мин.
• Ш Система должна обеспечивать хранение больших объемов данных в базе данных «архив».
• IV. Надежность.
• Ш В системе должно поддерживаться разграничение доступа к информационным ресурсам: Журналист не имеет доступа к возможности редактирования заготовок полос, так же как и ответственный секретарь.
• Ш Система должна отслеживать наличие меток на заготовках полос для предоставления доступа к их использованию.
• Ш Система должна поддерживать работу 24 часа в сутки 7 дней в неделю.
• Ш Система должна выполнять резервное копирование файлов в базах данных.
• 1.4 Способ реализации системы
• В качестве среды построения модели автоматизированной системы поддержки работы отдела редакции будем использовать программный продукт фирмы Rational Software Corporation - Rational Rose Modeler Edition, относящийся к объектно-ориентированным подходам проектирования программного обеспечения. В основе данной среды лежит использование языка UMLметода разработки программного обеспечения для проектируемой автоматизированной системы будет использован объектно-ориентированный подход. Объектно-ориентированный подход к разработке сложный систем позволяет построить объектную декомпозицию, т.е. описать структуру системы в терминах объектов и связей между ними, а поведение системы - в терминах обмена сообщениями между объектами. Основным инструментом объектно-ориентированного подхода являются CASE- средства или так называемые «средства быстрой разработки программного обеспечения». В целом CASE-технология представляет собой совокупность методов проектирования программного обеспечения, а также набор инструментальных средств, позволяющих в наглядной форме моделировать предметную область, анализировать эту модель на всех стадиях разработки и сопровождения программного обеспечения и разрабатывать приложения в соответствии с информационными потребностями пользователей
• В среде проектирования программного обеспечения Rational Rose реализовано визуальное моделирование - способ восприятия проблем с помощью зримых абстракций, воспроизводящих понятия и объекты реального мира Графические средства визуального проектирования позволяют строить визуальные модели архитектуры системы. Кроме того, использование среды выизуального проектирования Rational Rose Modeler Edition позволяет в итоге получить работающие приложения ( программный код), на основе диаграмм . А использование унифицированного языка моделирования UML позволяет предусмотреть механизмы расширяемости и специализации модели для расширения базовых концепций, обеспечить независимость от конкретных языков программирования и процессов разработки.
• В процессе моделирования автоматизируемой системы поддержки работы отдела редакции в среде моделирования Rational rose Modeler Edition предполагается разработать ряд диаграмм, отображающих информационные процессы в системе, взаимодействие между ее компонентами , и, в итоге, получить готовый программный код на языке С++, скомпилированный на базе разработанных диаграмм.
• 2. Реализация проекта
• Моделирование информационной системы среде Rational Rose Modeler Edition предполагает выполнение ряда последовательных этапов:
• - разработка модели системы;
• - анализ модели;
• - проектирование системы;
• - реализация модели.
• Каждый последующий этап является детализацией предыдущего и может включать в себя несколько отдельных этапов. Конечным результатом процесса моделирования является компиляции я и отладка программного кода.
• 2.1 Разработка модели системы
• Создание модели системы в среде визуального моделирования Rational Rose Modeler Edition связано с понятием диаграмм вариантов использования. Диаграмма вариантов использования - общее описание модели, отображающее компоненты системы и функциональные требования, предъявляемые к ней.
• При разработке диаграмм вариантов использования выделяют два основных понятия модели: «действующее лицо» и «вариант использования». Под действующим лицом понимается роль, которую пользователь играет по отношению к системе. действующие роли представляют собой роли, а не конкретных людей или наименования работ. Определение действующих ролей системы зависит от специфики создаваемой системы, в качестве роли могут выделяться и рабочие места, и целые отделы, и аппаратно-программные комплексы. «вариант использования» - это определенная последовательность действий (транзакций), выполняемых системой в ответ на событие, инициируемое некоторым действующим лицом. То есть вариант использования описывает те состояния системы, которые должны обеспечивать выполнение функций данной системы.
• Диаграмма вариантов использования представляет собой общую модель системы, представленную в виде совокупности действующих лиц и действий (вариантов использования). Для построения модели автоматизированной системы поддержки отдела редакции на основании анализа предметной области (глоссария проекта) выделим действующих лиц, участвующих в функционировании системы:
• 1) Главный редактор;
• 2) Журналист;
• 3) Фотограф;
• 4) Наборщик;
• 5) Литературный редактор;
• 6) Ответственный секретарь;
• 7) Рабочие файлы - база данных;
• 8) Заготовки полос - база данных;
• 9) Проектные документы.
• Варианты использования определяются исходя из функций каждого действующего лица в системе и общих функций системы. Действующее лицо может как инициировать какой либо действие - «Вариант использования», так и принимать в нем участие. Приведем перечень вариантов использования для указанных действующих лиц:
• Таб.1. Варианты использования и их отношение к действующим лицам

Вариант использования	Инициирует	Участвует
Разработать концепцию номера	Главный редактор	Проектные документы
Распределить задания	Главный редактор	Журналист; Фотограф;
Утвердить полосы	Главный редактор	Заготовки полос
Утвердить макет	Главный редактор	Ответственный секретарь
Собрать информацию	Журналист	-
Написать статью	Журналист	Рабочие файлы
Печатать фотографии	Фотограф	Рабочие файлы
Наполнить полосы	Наборщик	Рабочие файлы; Заготовки полос
Корректировать полосы	Литературный редактор	Заготовки полос
Разработать макет номера	Ответственный секретарь	Главный редактор
Отправить номер макет на верстку	Ответственный секретарь	-

• Диаграмма вариантов использования представляет собой средство визуального отображения распределения вариантов использования между действующими лицами.
• Рис.1 Диаграмма вариантов использования
• Цель диаграммы вариантов использования -документирование функциональных требований к системе в самом общем виде. Эти требования отображаются в сценарии каждого варианта использования. Целью формирования сценария является подробное документирование процесса взаимодействия действующего лица с системой, реализуемого в рамках варианта использования, т.е. цель сценария - описать, что будет делать система при наступлении определенного события.
• Например, сценарий варианта использования « Утвердить полосы»
• Краткое описание:
• Вариант использования «Утвердить полосы» позволяет главному редактору просмотреть отредактированные заготовки полос, предназначенных для подготавливаемого номера газеты и утвердить их для последующего их включения в макет газеты. Утверждение полос главным редактором происходит путем установления специальной пометки «утверждено» на полосе в базе данных заготовок полос.
• Предусловие:
• Утверждение полос, выбираемых из базы данных заготовок возможно только при наличии откорректированных полос в базе данных. В случае, если заготовки полос еще не готовы (не написаны, не отредактированы), главному редактору выводится сообщение об отсутствии заготовок полос в каталоге.
• Основной поток событий:
• 1) Вариант использования начинается тогда, когда главный редактор запрашивает данные из базы данных заготовок полос.
• 2) Система управления процессами выводит на экран монитора главного редактора список готовых (отредактированных литературным редактором) заготовок полос, находящихся в каталоге. Все полосы находятся в колонке «Неутвержденные»
• 3) Главный редактор открывает одну из заготовок полос для просмотра.
• 4) Главный редактор посылает запрос к базе данных «проектные документы» для получения информации об утвержденной концепции номера.
• 5) Главный редактор проводит анализ на соответствие заготовки полосы концепции номера газеты.
• 6) Главный редактор утверждает полосу, выбрав на экране системы управления кнопку формы « утвердить».
• 7) Система помечает заготовку полосы как утвержденную в каталоге заготовок полос.
• 8) Система управления процессами передает утвержденную полосу для подготовки задания на ее включение в макет номера газеты.
• 9) Текст заготовки полосы закрывается и на экран выводится перечень заготовок полос, разбитый на 2 колонки: «утвержденные» и «неутвержденные».утвержденная полоса находится в колонке «Утвержденные».
• Альтернативные потоки событий:
• 1.Полоса исключена из номера:
• 6а) Главный редактор не утверждает полосу и принимает решение о исключении данной полосы из номера газеты. Главный редактор выбирает кнопку «отклонить» на экранной форме системы управления.
• 7а)Система помечает заготовку полосы как не утвержденную.
• 8а) Заготовка полосы перемещается из базы данных заготовок полос в архив.
• 9а) Рабочие файлы, связанные с подготовкой полосы также перемещаются в архив.
• 10а) Текст заготовки полосы закрывается и на экран выводится перечень заготовок полос, разбитый на 2 колонки: «утвержденные» и «неутвержденные».Неутвержденная полоса удаляется из перечня.
• 2.Корректировать заготовку полосы:
• 2.1. Переписать статью.
• 6б) Главный редактор принимает решение о необходимости корректировки заготовки полосы. Выбирает кнопку экранной форму «редактировать».
• 7б) Система запрашивает объект корректировки ( статья, фотографии);
• 8б) главный редактор выбирает объект корректировки : статья.
• 9б) На экран выводится текстовое поле для заполнения, в котором главный редактор указывает требования перепечатыванию статьи/написанию новой полосы.
• 10б) Система помечает полосу в базе данных заготовок полос, как не утвержденную.
• 11б) Формируется задание на перепечатывание статьи на основании требований введены главным редактором. Задание прикрепляется к неутвержденной полосе в заготовке полос с указанием адресата - журналиста.
• 12б) Система посылает сообщение наборщику и журналисту о новом задании.
• 12б) Открывается экранная форма, содержащая перечень заготовок полос. Статья, подлежащая корректировке удалена из списка неутвержденных полос.
• 2.2. Перепечатать фотографии:
• 6в) Главный редактор принимает решение о необходимости изменения набора фотографий, включенных в полосу. Выбирает кнопку экранной формы « Корректировать полосу».
• 7в) Система запрашивает объект корректировки.
• 8в) Главный редактор указывает в качестве объекта корректировки - набор фотографий.
• 9в) Открывается экранная форма для ввода требований к новому набору фотографий.
• 10в) Полоса помечается в каталоге заготовок полос как неутвержденная.
• 11в) На основании требований, введенных главным редактором формируется задание к перенабору полосы.
• 12 в) задание прикрепляется к полосе в базе данных заготовок.
• 13в) Отправляются сообщения о поступившем задании наборщику и фотографу.
• 14в) Открывается экранная форма, содержащая перечень заготовок полос. Статья, подлежащая корректировке удалена из списка неутвержденных полос.
• Послесловие:
• Все утвержденные полосы становятся недоступными для редактирования в каталоге «Заготовки полос».
• Необходимость описания сценария для варианта использования связана с тем, что некоторые варианты событий могут иметь несколько возможных сценариев исполнения в зависимости от действий лица, инициирующего этот вариант использования, или в зависимости от действий, осуществляемых в ходе выполнения сценария.
• Использовании описания сценария реализации варианта использования позволяет проектировщикам в дальнейшем определится с моделирование состояний и действий каждого варианта использования, а также определить набор классов, необходимых для реализации всех потоков событий каждого варианта.
• 2.2 Анализ модели
• В процессе построения модели автоматизированной системы поддержки отдела редакции были определены:
• - пользователи системы;
• - функции, выполнение которых должно поддерживаться в рамках реализации общих задач системы;
• -границы будущей системы
• Дальнейшая реализация проекта системы заключается в более глубокой детализации построенной модели с помощью анализа общей модели, выраженной с помощью диаграммы вариантов использования. Анализ модели принято разделять на 2 последовательных этапа:
• Ш Архитектурный анализ
• Ш Анализ вариантов использования;
• В процессе анализа механизмы реализации ее задач и компоненты, обеспечивающие эти механизмы.
• 2.2.1 Архитектурный анализ
• Архитектурный анализ модели связан с определением механизмов реализации построенной модели. Он, как правило, включает в себя:
• 1. утверждение общих стандартов моделирования и документирования системы;
• 2. предварительное выявление архитектурных механизмов (механизмов анализа);
• 3. формирование набора основных абстракций предметной области;
• 4. формирование начального представления архитектурных уровней.
• Соглашения моделирования определяют используемые диаграммы и элементы модели, правила из применения, с организацию модели.
• Архитектурные механизмы отражают нефункциональные требования к системе (надежность, безопасность и т.д.) и их реализацию в архитектуре системы.
• Под идентификацией ключевых абстракций понимают определение набора классов системы на основе описания предметной области и требований к системе.
• Для моделируемой системы поддержки отдела редакции установим соглашения моделирования, согласно которым:
• Ш Все классы и диаграммы, описывающие предварительный системный проект помещаются в пакет с именем Model$
• Ш Для каждого варианта использования, отображенного на диаграмме вариантов использования создается кооперация с именем Use-Case_Realithation, куда помещаются диаграммы классов, отображающие реализацию вариантов использования.
• Так, например, для совокупности вариантов использования, инициируемых действующим лицом «главный редактор» в пакете «Model» совокупность коопераций будет иметь вид:
• Рис.2. Пакет «Model» с совокупность коопераций.
• Связь между вариантом использования и его реализацией отображается на специальной диаграмме трассировки. Такая диаграмма может, как создаваться для каждого варианта отдельно, так и в общем виде.
• Рис.3. Общая диаграмма трассировки для коопераций пакета «Model»
• На этапе архитектурного анализа также определяется набор классов, необходимых для реализации конкретного варианта использования. Класс - это множество объектов, связанных общностью свойств, поведения, связей и семантики. Класс объединяет в себе атрибуты и операции. Класс является абстрактным представлением объекта и служит в качестве шаблона для создания объектов.
• Набор классов определяется для каждого варианта использования. Определение варианта использования - определение элементов будущей системы, которые должны обеспечить реализацию данного варианта.
• В процессе анализа модели автоматизированной системы поддержки отдела редакции для варианта использования «утвердить полосу» был определен следующий набор классов:
• Ш Интерфейс управления;
• Ш Контроллер данных;
• Ш Заготовки полос;
• Ш Рабочие файлы;
• Ш Архив;
• Ш Фотограф;
• Ш Журналист;
• Ш Планировщик;
• Ш Проектные документы;
• Ш Наборщик;
• Ш Ответственный секретарь.
• Набор классов, необходимых для реализации определяется совокупность действий, выполняемых в процессе основного и альтернативного потока событий в рамках сценария класса.
• Классы «Заготовки полос», «Рабочие файлы», «Архив» и « Проектные документы» представляют собой абстрактное представление баз данных системы.

• Рис.4. Классы, участвующие в реализации варианта использования «Утвердить полосу»
• Классы «Журналист», «Наборщик», «Фотограф», «Ответственный секретарь» - абстрактное представление действующих лиц модели.
• Класс «Интерфейс управления» предназначен для взаимодействия с пользователем. Инициирующим вариант использования - Главным редактором. В свой состав он включает как пользовательский интерфейс я ( экранная форма взаимодействия), так и механизмы передачи управляющих команд другим классам системы.
• Класс «Планировщик» - программный компонент системы, получающий команду от интерфейса управления и проводящий формирование задания и его отправку адресату на основании данных, получаемых от интерфейса управления.
• Класс «Контроллер данных» - класс, отвечающий за адекватность отображения информации в системе. проводит установление меток для полос в базе данных, контролирует управление файлами в базе данных (перемещение, вызов и пр.)
• Кроме того, на этапе архитектурного анализа предварительно выделяются архитектурные уровни, т.е. уровни, представляющие собой иерархию системы. Количество и структура ровней зависят от сложности предметной области и среды реализации. В рамках архитектурного анализа определяется начальная структура модели (набор пакетов и их зависимостей) и рассматриваются только верхние уровни модели.
• Каждый уровень иерархии представляется в виде пакета, объединяющего в себе определенные классы. Критерий разделения классов на пакеты может быть разным: это могут быть и общность выполняемых функций, и принадлежность к определенному стереотипу и т.д.На основании выделенных классов их функций предварительно определим следующие уровни иерархии для системы:
• v Бизнес-логика - уровень иерархии, объединяющий в себе классы, непосредственно участвующие в процессе реализации действий потока событий. Этот уровень иерархии будет включать в себя три подуровня:
• Ш Процессоры - пакет объединяющий в себе классы, осуществляющие контроль данных и управление их перемещением - классы «Контроллер данных», «Планировщик»
• Ш Хранилища информации - абстрактные представления баз данных, принимающих запросы и передающих информацию. Этот уровень включает в себя: класс « Рабочие файлы», класс «Проектные документы», класс « Заготовки полос» и класс «Архив».
• Ш Интерфейс-пакет включающий в себя только один класс «Интерфейс управления». Причиной выделения его в отдельный уровень иерархии стала его сложность и многофункциональность. Кроме того, только данный класс предназначен для непосредственного взаимодействия пользователя со всеми остальными компонентами.
• v Исполнители - уровень иерархии, предназначенный для отображения тех классов, которые не выполняют никаких действий в рамках данного варианта использования, но подразумеваеют получение информации в результате его исполнения. Это пакет объединяет в себе классы: «Наборщик», «Ответственный секретарь», «Журналист», «Фотограф».
• Таким образом, иерархия системы будет иметь вид:

• Рис.5 Иерархия системы
• Следующий этап, относимый к анализу модели - анализ вариантов использования. Он подразумевает дальнейшую детализацию модели, включающую детализацию выделенных классов.
• 2.2.2 Анализ вариантов использования
• Анализ вариантов использования включает в себя:
• Ш Идентификацию классов, участвующих в реализации потоков событий варианта использования;
• Ш Распределение поведения, реализуемого вариантом использования, между классами;
• Ш Определение атрибутов и ассоциаций классов;
• Ш Унификацию классов анализа.
• Под идентификацией классов понимают отнесение каждого класса к конкретному типу. Как правило, выделяют 3 типа классов:
• 1. Граничные классы. Они отвечают за взаимодействие с внешней средой системы (действующими лицами);
• 2. Классы-сущности - отвечают за хранение и манипулирование данными;
• 3. Управляющие классы - координируют потоки событий варианта использования.
• Исходя из такой классификации, определим типы классов, участвующих в реализации варианта использования «Утвердить полосу».
• · Классы-сущности:
• Ш Заготовки полос;
• Ш Рабочие файлы;
• Ш Проектные документы;
• Ш Планировщик;
• Ш Наборщик;
• Ш Журналист;
• Ш Ответственный секретарь;
• Ш Фотограф;
• Ш Архив.
• · Граничные классы:
• Ш Интерфейс управления.
• · Управляющие классы:
• Ш Контроллер данных
• Каждый класс системы характеризуется набором атрибутов, операций и связей.
• Атрибут класса - поименованное свойство класса, определяющее диапазон допустимых значений, которые могут принимать экземпляры данного свойства. Атрибут - это элемент информации, связанный с классом. Так класс анализа «рабочие файлы», представляющий собой прототип объекта будет характеризоваться следующим набором атрибутов:
• - Идентификационный номер статьи;
• Идентификационный номер фотографии;
• - автор статьи;
• - фотограф;
• - дата внесения в базу данных;
• - срок хранения в базе рабочих файлов;
• - идентификационный номер полосы, для которой предназначена статья ( фотография);
• - тема статьи/фотографии.
• Совокупность всех атрибутов класса, отображается на диаграмме классов:
• Рис.6. Атрибуты классов.
• Операции классов определяются на основании тех действий, которые они выполняют в рамках реализации варианта использования. Описание действий каждого класса отображается в виде диаграмм взаимодействия. На такой диаграмме отображается ряд объектов и те сообщения, которыми они обмениваются между собой. Сообщение - средство с помощью которого объект-отправитель запрашивает у объекта-получателя выполнение одной из его операций. Существует два вида диаграмм взаимодействия: диаграммы последовательности и кооперативные диаграммы.
• Диаграммы последовательности отражают временную последовательность событий, происходящих в рамках варианта использования. Как правило, диаграммы последовательности строятся для всех потоков событий, происходящих в рамках данного варианта использования, т.е. и для основного потока событий и для альтернативного.
• Кооперативные диаграммы также как и диаграммы последовательности отображают потоки событий, однако диаграммы последовательности упорядочены на времени, т.е. в них определяется последовательность обмена сообщениями между классами. А кооперативные диаграммы концентрируют внимание на связях между объектами, из них легче понять связь между объектами, но труднее уяснить последовательность событий.
• Поскольку сценарий варианта использования включает в себя 4 потока событий (один основной и три альтернативных), то построим диаграммы последовательности для каждого потока событий и, кроме того, диаграмму последовательности, отображающую все потоки событий м время их возникновения. Для каждой диаграммы последовательности приведем соответствующую ей кооперативную диаграмму, чтобы отобразить реализацию варианта использования как в разрезе последовательности выполнения действий классами, так и связей между объектами, участвующими в реализации данного варианта использования.
• Рис.7. Общая диаграмма последовательности

• Рис.8. Общая кооперативная диаграмма
• В соответствии со сценарием варианта использования, основной поток событий - «принять полосу». Для этого потока событий диаграмма последовательности будет иметь вид:
• Рис.9. Диаграмма последовательности «Принять полосу»
• То есть, после того, как полоса утверждена интерфейс управления передает соответствующую команду контроллеру данных, который помечает в базе данных заготовок полос полосу как утвержденную и открывает доступ к ей ответственного секретарю. После чего интерфейс управления передает управляющую команду планировщику на подготовку задания ответственному секретарю. Планировщик посылает уведомление ответственному секретарю, что задание для него сформировано.
• Кооперативная диаграмма для этого потока событий:
• Рис.10. Кооперативная диаграмма «принять полосу»
• Далее разрабатываются диаграммы для каждого альтернативного потока событий.
• Рис.11. Диаграмма последовательности «Исключить полосу из номера»

• Рис.12. Кооперативная диаграмма «Исключить полосу из номера»
• Рис.13. Диаграмма последовательности «Переписать статью»

• Рис.14. Кооперативная диаграмма «Переписать статью»
• Рис.15. Диаграмма последовательности «Изменить набор фотографий»
• После того, как будут определены все сообщения, передаваемые между классами - будет определен и набор операций, присущих каждому классу. Операция класса - это та совокупность действий, выполнение которых возложено на данный класс. Операции класса, как и его атрибуты отображаются на диаграмме классов:
• Связи между классами отображаются на диаграмме классов. Диаграмма классов определяет типы классов системы и различного рода статические связи, которые существуют между ними. Как правило, диаграмма классов строится на основе анализа кооперативных диаграмм - связи между объектами на кооперативных диаграммах переносятся на диаграмму классов.
• Рис.18. Диаграмма классов:
• Таким образом, в ходе анализа разработанной на основе проекта модели мы определили набор необходимых объектов, подлежащих проектированию и программированию для реализации автоматизированной системы поддержки работы отдела редакции. Анализ модели позволил выделить базовые компоненты модели ( на примере реализации одного варианта использования), определить общую совокупность действий внутри этих объектов и их последовательность, а также выделить связи между объектами.
• На основании результатов анализа модели производится дальнейшее проектирование системы.
• 2.3 Проектирование системы
• Главная задача проектирования системы - предварительное формирование ее архитектуры с учетом всех функциональных и нефункциональных требований, сформированных как на стадии построения модели, так и стадии ее анализа.
• Проектирование системы, как и анализ модели подразумевает реализации ряда этапов:
• Ш Проектирование архитектуры системы;
• Ш Проектирование элементов системы.
• 2.3.1 Проектирование архитектуры системы
• Этот этап подразумевает детализацию архитектурных уровней, выделенных на стадии архитектурного анализа модели. В соответствии с выделенными уровнями иерархии, классы группируются по пакетам. Пакет - это общий механизм для организации элементов модели в группы. Причем, каждый элемент модели может входить в состав только одного пакета. Пакет является средством организации модели в процессе разработки, повышения ее управляемости и читаемости, а также единицей управления конфигурацией.
• Если между двумя классами, находящимися в разных пакетах существует связь, то и между этими пакетами существует связь. Для отображения связей между пакетами (уровнями иерархии системы) строится диаграмма пакетов.
• Диаграмму пакетов можно считать основным средство управления общей структурой системы. Пакеты также используются для представления подсистем (модулей) системы. Подсистема - это комбинация пакета и класса. Подсистема является более сложным уровнем иерархии по сравнению с пакетом.
• Следующим этапом проектирования системы является выделение уже структурных компонентов системы.
• 2.3.2 Проектирование элементов системы
• На этапе проектирования элементов системы проводится уточнение вариантов использования, проектирование классов и баз данных.
• Под проектированием классов подразумевается:
• Ш Детализация уже созданных классов;
• Ш Уточнение их операций и атрибутов;
• Ш Моделирование состояний для классов;
• Ш Уточнение связей между классами.
• В процессе детализации классов каждый граничный класс преобразуется в некоторый набор классов. Это может быть набор элементов пользовательского интерфейса или набор классов, реализующих системный или аппаратный интерфейс. Классы -сущности с учетом соображений производительности и защиты данных могут разбиваться на ряд классов. Основанием для разбиения является наличие в классе атрибутов с различной частотой использования или видимостью. Полученные в результате детализации классы подлежать реализации в коде системы.
• Важную часть в проектировании элементов системы занимает моделирование состояний для уточненных классов. Если некоторый объект всегда одинаково реагирует на событие, то он считается независимым от состояния по отношению к этому событию. В отличие от него зависимые от состояния объекты по-разному реагируют на одно и то же событие в зависимости от своего состояния. Если в системе присутствуют зависимые от состояния объекты со сложной динамикой поведения, то для них целесообразно построить модель, описывающую состояние объекта и переходы между ними.
• В среде визуального моделирования Modeler Edition такие модели состояний объекта описываются в виде диаграмм состояний. Диаграммы состояний определяют все возможные состояния,в которых может находится конкретный объект, а также процесс смены состояний объекта в результате наступления некоторых событий.
• Рис.20 .Диаграмма состояний для объекта «Интерфейс управления»
• На такой диаграмме выделяют начальное и конечное состояние. Начальное состояние соответствует объекту, когда он только начинает работу, а конечное - состоянию объекта непосредственно перед завершением его работы. Причем, начальное состояние может быть только одно, а конечных - сколько угодно с состоянием объекта связывают 5 типов данных:
• · Деятельность - поведение, реализуемое объектом, пока он находится в данном состоянии;
• · Входное действие - поведение, которое выполняется, когда объект переходит в данное состояние;
• · Выходное действие - поведение, которое выполняется как составная часть процесса выхода из данного состояния;
• · Переход - перемещение объекта из одного состояния в другое;
• · Событие - вызывает переход из одного состояния в другое;
• · Ограничивающие условия - условия, определяющие направление перехода.
• Вся совокупность действий, условий и переходов и формирует диаграмму состояний для объекта.
• Таким образом, для объекта «интерфейс управления» начальным состоянием будет - обращение главного редактора. После чего и реализуются возможные состояния объекта. Первое состояние объекта « Интерфейс открыт». Событие, выполняемое в данном состоянии - это обращение главного редактора к каталогу заготовок полос для просмотра. Поэтому следующее состояние объекта - «Действие», входное действие для этого состояния - это вывод главному ректору заготовок полос, а событие, осуществляемое в процессе реализации состояния - вывод возможных вариантов решения. Однако, существует и другой возможный переход от состояния «Интерфейс открыт»: в том случае, если при обращении к какталогу заготовок полос, обнаружится что полос, готовых к просмотру нет, то объект переходит в состояние «Ошибка»,в ходе которого выполняемое событие - вывод сообщения об отсутствии полос главному редактору. После чего объект переходит в конечно состояние. То есть ограничивающим условием наступления данного события будет отсутствие отредактированных полос в каталоге.
• Однако, в том случае если наступает событие «Действие», событие которого - выбор варианта решения главным редактором, а выходное действие - формирование команды планировщику в зависимости от выбранного решения, то поскольку вариантов решения три (исходя из возможных потоков событий), то и возможных дальнейших состояний объекта тоже три.
• 1) Состояние «Утвердить». Условием перехода объекта в данное состояния является выбор главным редактором на панели интерфейса управления кнопки «утвердить». Событие, выполняемое в ходе этого состояния - передача команды планировщику. Результатом, т.е. выходным действие будет - завершение работы интерфейса и, следовательно, переход в конечное состояние.
• 2) Состояние « Исключить». Условие перехода -выбор кнопки интерфейса «исключить полосу». Событие состояния - передача команды на удаление файлов, связанных с данной полосой и удаление самой полосы. Выходное действие - завершение работы интерфейса.
• 3) Состояние «Корректировать». Наступает в том случае, когда выбрана кнопка « корректировать полосу». Причем объект переходит в данное состояние независимо от того, какой объект корректировки выбран (статья или фотография). Событие, выполняемое в процессе наступления этого состояния - ввод требований главным редактором в открытое текстовое поле. Выходное действие - отправка команды вместе с требованиями планировщику. После чего объект завершает работу.
• Таким образом объект «Интерфейс управления» может иметь 6 состояний, три из которых являются вариантами одного события.
• Диаграмма вариантов использования позволяет предопределить все возможные состояния объекта и условия возникновения каждого состояния. Затем каждое состояние и условия его возникновения представляются в виде программного кода, однако использование диаграммы состояний позволяет значительно упростить понимание программистами всех особенностей проектируемого объекта при его программном представлении.
• 2.3.3 Проектирование физической реализации системы
• Своеобразным видом архитектурного проектирования является и проектирование конфигурации системы. Под конфигурацией системы понимают - модель физического размещения компонентов системы между вычислительными ресурсами системы. Как правило, конфигурация системы моделируется в том случае, если создаваемая система будет распределенной, т.е. ее функции и элементы будут разделены физически. Распределенная конфигурация системы моделируется с помощью диаграмм размещения, отображающих распределение процессов между вычислительными ресурсами системы. При этом проектирование распределения процессов необходимо производить с учетом факторов:
• Ш Используемые образцы распределения;
• Ш Время отклика;
• Ш Минимизация сетевого трафика;
• Ш Мощность узла;
• Ш Надежность оборудования.
• Под узлами конфигурации понимают процессор или другое устройство, на которое возложены те или иные функции. Конфигурация системы для разработанной модели будет иметь вид:
• Рис.21. Диаграмма размещений системы.
• То есть, в составе распределенной системы будут выделены 5 вычислительных узлов, каждый из которых реализует функции определенного типа. Наиболее мощный узел системы - сервер управления данными, на который возложена функция передачи и обработки данных между базами данных и приложениями подразделений отдела.
• Узел « Пользовательские приложения» - представляет собой комплекс аппаратно-программных средств, предназначенных для поддержки обмена сообщениями между пользователями системы (журналистом, фотографом, наборщиком, главным редактором, ответственным секретарем), обеспечения поддержки интерфейсов взаимодействия с базами данных, системами проектирования и обработки даны. Взаимодействие с другими узлами системы осуществляет через центральный узел - сервер управления данными.
• Узел « Приложения проектирования» - компонент распределенной системы, объединяющий в себе набор приложений по проектирования заготовок полос, макетов газет, плановых документов, шаблонов и т.п. в виду того, что приложения проектирования неразрывно связаны с информацией в базах данных, то между этими узлами существует соединение. Кроме того, этот узел связан с центральным сервером, для обеспечения функций последнего по контролированию состояний данных в базах.
• Узел « Приложения обработки информации»- комплекс средств, реализующих управление потоками информации между базами данных, пользователями системы. В его задачи входит также и контроль адекватности данных, как находящихся в базах, так и передаваемых между пользователями. Он осуществляет контроль за соблюдением правил разграничения доступа пользователей к базам данных.
• Таким образом, из диаграммы размещений можно узнать физическое размещение системы, определить тип требуемых линий коммуникаций, выделить наиболее оптимальную физическую структуру системы, обеспечивающей выполнение своих задач с наибольшей производительностью и эффективностью. Диаграмма размещений необходима в первую очередь архитектору проекта.
• Разработка физической архитектуры системы завершает этап проектирования. Все предыдущие этапы были подготовкой к главному этапу - реализации системы- разработки программных приложений, внедрение которых должно обеспечить выполнение задач, указанных в проекте.
• 2.4 Реализация системы
• Этап реализации системы связан с проектирование уже не компонентов модели, а компонентов будущего программного обеспечения на основе результатов всех предыдущих этапов. На данном этапе основные работы возлагаются на программистов. Именно они, суммирую результаты различного рода анализов, проектирований определяют прототип программных приложений.
• В ходе реализации проектирования программного обеспечения основная роль отводится определения набора компонентов программного обеспечения. Именно на данном этапе определяются функциональные элементы программ, связи между ними, закладываются функции каждого компонента. Для отображения компонентов программного обеспечения используют диаграммы компонентов, которые моделируют физический уровень системы. Каждый класс системы преобразуется в компонент, и, так же как и между классами, указываются связи между компонентами. Для системы диаграмм компонентов может быть несколько, в зависимости от числа подсистем или исполняемых файлов. Эти диаграммы необходимы при компиляции программного кода.
• После завершения работ по выделению компонентов переходят к генерации программного кода - результату всей проделанной работы. Среда Rational Rose Modeler Edition поддерживает генерацию кода на основании построенных диаграмм на различных языках программирования. В результате компиляции программного кода получают не полностью готовый программный продукт, а его прототип. Доработка такого прототипа осуществляется специалистами -программистами. Однако базовые функциональные компоненты программного кода закладываются именно в результате генерации кода в среде Rational Rose.
• Заключение
• Таким образом, в ходе всей проделанной работы мы получили заготовки программного кода для последующей разработки приложений, обеспечивающих выполнение поставленных на этапе проектирования задач. Выполнение ряда последовательных этапов: моделирование системы, анализ созданной модели, проектирование системы на основе анализа позволило учесть все требования, предъявленные к системе, как функциональные, так и не функциональные. Построение процесса моделирования в виде иерархической структуры, где каждый последующий этап проектирования является детализацией предыдущих этапов обеспечило максимально возможную подготовку к разработке полноценного программного кода системы.
• Использование средств визуального проектирования, то есть, различного рода диаграмм существенно упрощает понимание процессов, реализуемых на каждом уровне системы, начиная от уровня ее общих функций и заканчивая процессами, существующими между компонентами программного обеспечения каждого ее элемента.
• Дальнейшая работа по создания автоматизированной системы поддержки работы отдела редакции связана с наполнением заготовок программного кода, сформированных в среде Modeler Edition.
• В ходе выполнения поставленной задачи - разработки системы, обеспечивающей поддержку отдела редакции был сделан вывод, о том, что эффективность проектирования системы и оптимальность полученных результатов зависят от:
• Ш Четко поставленных целей разработки системы;
• Ш Наличия сформированного комплекса задач, на решение которых она направлена;
• Ш Разработки оптимальной модели системы, детализация которой будет производится;
• Ш Четком определении функций каждого элемента системы и его состояний;
• Ш Правильного подбора группы проектировщиков, архитекторов, программистов.
• Немаловажную роль в проектировании систем различного рода играет совокупность выбранных средств проектирования. Использование средств визуального проектирования программного продукта IBM Rational Rose Modeler Edition дает ряд преимуществ по сравнению с другими средствами объектно-ориентированного подхода:
• v поддержка генерации кода - обеспечивает подготовку базы для дальнейшей работы программистов.
• v обратное проектирование, позволяющее «видеть» каким образом внесение изменений в модель изменит состав программного кода.
• v ускорение разработки баз данных благодаря гибкому взаимному преобразованию логической и физической модели.
• v поддержка визуального объектно-ориентированного моделирования, упрощающего процесс взаимодействия между проектировщиками и разработчиками программного обеспечения.
• v поддержка генерации кода на разных языках программирования, обеспечивающее совместимость разрабатываемой системы с уже существующим программным обеспечением.
• Таким образом, среда моделирования Ratioanl Rose Modeler Edition является не единственным, но, пожалуй, одним из самых оптимальных и эффективный средств «быстрого» проектирования систем, а использование языка UML позволяет адаптировать язык моделирования к конкретным нуждам, не меняя при этом его метамодель.