Файл: ПРИМЕНЕНИЕ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПОДХОДА ПРИ ПРОЕКТИРОВАНИИ ИНФОРМАЦИОННОЙ СИСТЕМЫ (CASE системы).pdf

На основе нового типа могут быть определены таблицы, например:

Create table Addresses of Address;

Новые типы допускается использовать и для определения столбцов (т.е. игнорируется требование атомарности атрибутов реляционной модели):

Сreate table People of new type Person (

name char (30),

address Address,

birthdate date,

);

Наследование определяется с помощью фразы under.

Create type Employee under Person (

empno char(10),

dept ref(Department)

);

В этом примере задана функция age, которая вычисляет текущий возраст объекта типа Person, хранимого в таблице People. К данной функции можно обращаться из оператора SELECT.

Рисунок 1.4. Модель ODL Базы данных магазина

ГЛАВА 2. ПРАКТИЧЕСКИЕ ПРИМЕРЫ ПРОЕКТИРОВАНИЯ ИС В РАЗЛИЧНЫХ РЕДАКТОРАХ

2.1. Проектирование ИС управления теплицей в RationalRose

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

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

При помощи диаграммы Use Case (вариантов использования) определим объекты системы и действия, которые эти объекты должны производить.

Разрабатываем UseCase диаграмму по указанному алгоритму

Рисунок 2.1. Разработанная диаграмма в редакторе

Устройства тепличного хозяйства

Рисунок 2.2.DeploymentDiagram

2. СозданиеStatechartдиаграммы

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

Рисунок 2.3. Диаграмма состояний

Рисунок 2.4. Настройка среды

Рисунок 2.5. Настройка состояний

Рисунок 2.6. Statechart Diagram в развернутом виде

Рисунок 2.7. Statechart Diagram в свернутом виде

Создание Activity Diagram

Строим диаграмму активности по указанному алгоритму

Рисунок 2.8. Диаграмма активности

Рисунок 2.9. Создание вложенной диаграммы по алгоритму

Создаем диаграмму Sequence Diagramпо предлагаемому сценарию

Рисунок 2.10. Sequence Diagram: Use case View / Progress

Строим диаграмму сотрудничества Collaborationпо алгоритму

Рисунок 2.11. Collaboration Diagram: Use Case View / Progress

Рисунок 2.12. Настройка диаграммы

Строим диаграмму компонент по алгоритму

Рисунок 2.13. Диаграмма компонент

Рисунок 2.14. Спецификация связей в диаграмме компонент

Диаграмма классов

Рисунок 2.15. ClassDiagram: Logical / Main

Рисунок 2.16. Установка спецификаций компонент

Рисунок 2.17. Установка спецификаций компонент

Определяем связи

Рисунок 2.18 Настройка операций

Рисунок 2.19. Связи

Рисунок 2.20. Спецификации связей

2.2. Проектирование ИС рекламного агентства в StarUML

Предметная область

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

Описание предметной области

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

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

Граничными классами будут AutorizationManager (Авторизация пользователя) – класс отвечает за авторизацию, аутентификацию менеджера в системе и переход его на страницу работы с системой, InputInformation (Ввод информации) – класс отвечает за ввод новой информации в систему, Change Information (Изменение информации) - класс отвечает за изменение и редактирование информации, которая расположена в базе данных системы, DeleteInformation (Удаление информации) – класс отвекчает за удаление информации из системы, ViewInformation (Просмотр информации) – класс содержит набор фильтров, которые позволяют просматривать различную информацию из базы данных.

Управляющими классами будут ActMeneger(Действия менеджера) – класс отвечает за выбор действий и сущностей на которые он будет направлен,

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

Рисунок. 2.21. UseCase рекламного агентства

Рисунок. 2.21. Диаграмма активности рекламного агантства

Manager–Менеджер, который работает с системой

System – Система

DataBase – База данных системы

InputManagerMenuPage Работу с системой начинает авторизованный менеджер, который заходит на свою страницу и видит меню с опциями:AddInformation (добавление информации), ChangeInformation (изменение информации), ViewInformation (просмотр информации), DeleteInformation (удаление информации)

Рисунок. 2.21. Диаграмма последовательности

Менеджер

1. Input Information aboutFirm – вводит информацию о фирме заказчике
2. Test fields – система проверяет правильность заполнения полей
3. Info Reclam – Менеджер вводит информацию о рекламе
4. Test Fields– система проверяет правильность заполнения полей
5. Desired Data/time – Вводит прогнозируемое время рекламы
6. Forminganinvoice – системаоплаты : PayManager проверяет данные и формирует счет
7. Invoicing payment – система оплаты выводит счет
8. Receipt of payment – переводит счет к оплате
9. Pay и производит оплату (через платежную систему
10. Reclam Order – Менеджер предоставляет договор о рекламном времени

Рисунок. 2.22. Уточненный вариант

Менеджер

1. Autorization – авторизуется
2. InputInformation – вводит информацию о заказе
3. Input Information aboutFirm – вводит информацию о фирме заказчике
4. Test fields – система проверяет правильность заполнения полей
5. Info Reclam – Менеджер вводит информацию о рекламе
6. Test Fields– система проверяет правильность заполнения полей
7. Desired Data/time – Вводит прогнозируемое время рекламы
8. Forminganinvoice – системаоплаты : PayManagerпроверяетданные и формирует счет
9. Invoicing payment – система оплаты выводит счет
10. Receipt of payment – переводит счет к оплате
11. Pay и производит оплату (через платежную систему
12. Reclam Order – Менеджер предоставляет договор о рекламном времени
13. ViewInformation – Менеджер просматривает информацию
14. ChangeInformation – Изменяет информацию
15. DeleteInformation- Удаляет информацию

Рисунок. 2.24.Диаграмма взаимодействия

Менеджер

1. Autorization – авторизуется
2. InputInformation – вводитинформациюозаказе
3. Input Information aboutFirm – вводитинформацию о фирме заказчике
4. Test fields – система проверяет правильность заполнения полей
5. Info Reclam – Менеджер вводит информацию о рекламе
6. Test Fields– система проверяет правильность заполнения полей
7. Desired Data/time – Вводит прогнозируемое время рекламы
8. Forminganinvoice – системаоплаты : PayManagerпроверяетданные и формирует счет
9. Invoicing payment – система оплаты выводит счет
10. Receipt of payment – переводит счет к оплате
11. Pay и производит оплату (через платежную систему
12. Reclam Order – Менеджер предоставляет договор о рекламном времени
13. ViewInformation – Менеджер просматривает информацию
14. ChangeInformation – Изменяет информацию
15. DeleteInformation- Удаляет информацию

На этапе разработки классов были определены следующие атрибуты классов

<<boundary>> InputInformation -Кодзаписи (idInput: String)

<<entity>> Reclam

• idReclam: String – Код рекламы
• nameFilm: String[1..*] – Название рекламного ролика
• productName: String[1] – Фирма изготовитель
• slogan: String[1..*] – Слоган, может быть несколько
• duration: Integer = 20 – продолжительность в секундах (по умолчанию 20
• description: String – описание содержания
• author: String – автор

<<entity>> Firm

• idFirm: String –код Фирмы
• firmName: String - Название
• adress: String – Юридический адрес
• contactPerson: String[1..*] – Ответственная персона (не менее одной)
• telephone: String[1..*] – контактный телефон ( не менее одного)
• e-mail: String[1..*] - электронный адрес ( не менее одного)

<<entity>> DateTime

• idZakaz: String – код заказа
• data: String – дата заказа
• Day: String[1..*] – какой день показа (может быть несколько)
• time: Integer[1..*] – время показа (может быть несколько)
• count: Integer = 1 – количество показав в передаче (по умолчанию 1)

<<entity>> Cash

• idPayment: String – код платежа
• sumPayment: Float – сумма платежа
• dataPayment: String[1..*] – дата оплаты, платеж может продолжаться, тогда дат будет несколько

Рисунок. 2.25. Диаграмма классов

Опишем операции классов

<<control>> ActManager

• Forming an invoice() – формирует счет на оплату
• Invoicing payment() – передает счет к оплате
• Receipt of payment() – фиксирует данные об оплате

<<boundary>> AuthorizationManager

Autorization()- авторизуетвсистеме

<<boundary>> InputInformation

• InputInformationaboutFirm() – вводитинформациюофирме (платежные документы)
• InfoInformation() – выводит формы для ввода информации
• Test fields() – тестирует поля с информацией

<<entity>> Reclam

• Info Reclam() – генерирует форму для ввда рекламной информации

<<entity>> Firm

• InfoFirm() – генерирует форму для ввода информации о фирме
• Test fields() – верифицирует фирму (постоянные клиенты)

<<entity>> DateTime

• DesiredData/time() – генерирует форму для ввода даты и времени, анализирует их доступность

<<entity>> Cash

• Info Cash() - генерирует платежный счет на основе даты и времени

Рисунок. 2.26. Определение атрибутов и методов

Рассмотрим связи между классами более подробно. Определим отношения между классами сценария Работа менеджера с системой.

Проанализировав диаграмму последовательности выясняем, что класс <boundary>> AuthorizationManager связан с <<control>> ActManager, а объект ActManager посылает сообщения объекту классам <<boundary>> InputInformation, <<boundary>> ChangeInformation, <<boundary>> DeleteInformation,<<boundary>> ViewInformation. Каждый из этих классов Связан имеет направленную связь с объектами классов Reclam, Firm, DateTime. Класс ViewInformation имеет направленную связь с Cash.