База данных Рекламного агентства

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

На рисунках 16 и 17 приведены различные диаграммы состояний.

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

Рисунок 17 - диаграмма состояний оформления договора

 

4 Физическое представление информационной  системы

4.1 Диаграмма компонентов

 

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

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

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

визуализации общей структуры  исходного кода программной системы;

спецификации исполняемого варианта программной системы;

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

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

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

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

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

 

 

Рисунок 15- Обобщенная диаграмма компонентов  системы

 

Отдельный компонент может быть представлен на уровне типа или на уровне экземпляра. Графическое изображение в обоих случаях одинаковое, но правила записи имени компонента отличаются. Если компонент представляется на уровне типа, то в качестве его имени записывается только имя типа с заглавной буквы. Если же компонент представляется на уровне экземпляра, то в качестве его имени записывается <имя компонента>':'<имя типаХ>. При этом вся строка имени подчеркивается.

В качестве простых имен принято  использовать имена исполняемых  файлов (с указанием расширения ехе  после точки-разделителя), динамических библиотек (расширение dll), Web-страниц (расширение html), текстовых файлов (расширения txt или doc) или файлов справки (hip), файлов баз данных (DB) или файлов с исходными текстами программ (расширения h, cpp для языка C++, расширение java для языка Java), скрипты (pi, asp) и другие.

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

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

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

 

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

 

В языке UML выделяют три вида компонентов:

развертывания, которые обеспечивают непосредственное выполнение системой своих функций. Такими компонентами могут быть динамически подключаемые библиотеки с расширением dll, Web-страницы на языке разметки гипертекста с расширением html и файлы справки с расширением hlp;

рабочие продукты. Как правило, это  файлы с исходными текстами программ, например, с расширениями h или срр для языка C++;

исполнения, представляющие собой  исполняемые модули - файлы с расширением  ехе.

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

4.1.2 Диаграмма развертывания

 

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

 

 

Рисунок 17 – Диаграмма развертывания

 

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

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

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

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

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

показать физические связи между  всеми узлами реализации системы  на этапе ее исполнения;

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

Диаграммы развертывания разрабатываются  совместно системными аналитиками, сетевыми инженерами и системотехниками.

 На рисунке 17 изображена диаграмма развертывания нашей системы.

4.1.3 Генерация программного кода

 

Одним из наиболее важных свойств  программы IBM Rational Rose 2003 является возможность  генерации программного кода на нескольких языках программирования, которая может  быть использована разработчиком после построения модели. Для этой цели в среде IBM Rational Rose 2003 присутствует достаточно большой выбор языков программирования и схем баз данных. Однако возможность генерации текста программы на том или ином языке программирования зависит от установленной версии IBM Rational Rose 2003.

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

Заключение

В ходе выполнения данной курсовой работы мы выполнили несколько задач. А именно:

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

- выделили основные структурные элементы управления предприятием, а также описали информационные потоки между ними;

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

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

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

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

сгенерировали программный код  для будущей информационной системы  на языке C++.

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

Список используемых источников

1. Буч Г., Рамбо Д., Джекобсон А. Язык UML. Руководство пользователя: Пер. с англ. Слинкин А.А. – Учебное пособие – М.: ДМК Пресс, 2000. - 432 с.
2. Вендров А.М. Проектирование программного обеспечения экономических информационных систем. – М.:Финансы и статистика, 2000.-187с.
3. Калянов Г.Н. CASE-технологии. Консалтинг при автоматизации предприятий.-М.:СИНТЕГ, 1997.-276с.
4. Леонтьев А.В. Самоучитель UML – Учебное пособие – СПб.: БХВ-Петербург, 2001. – 304с.
5. Фаулер М., Скотт К. UML в кратком изложении. Применение стандартного языка объектного моделирования; Пер.с.англ. – М.:Мир, 1999.-236с.
6. Шлеер С., Меллор С. Объектно-ориентированный анализ: моделирование мира в состояниях. – Киев: Диалектика, 1993.-193с.

Приложение А

(обязательное)

 

Параметры заказа на рекламу.cpp

#include "Параметры заказа на  рекламу.h"

 

//##ModelId=4DDA97E1032C

Integer Параметры заказа на рекламу::Ввод()

{

}

 

//##ModelId=4DDA97E1032C

Integer Параметры заказа на рекламу::Ввод()

{

}

 

Параметры заказа на рекламу.h

#ifndef ПАРАМЕТРЫ_ЗАКАЗА_НА_РЕКЛАМУ_H_HEADER_INCLUDED_B21CEE48

#define ПАРАМЕТРЫ_ЗАКАЗА_НА_РЕКЛАМУ_H_HEADER_INCLUDED_B21CEE48

 

//##ModelId=4DCADAE00261

class Параметры заказа на рекламу

{

  public:

    //##ModelId=4DDA97E1032C

    Integer Ввод();

 

  private:

    //##ModelId=4DDA979100CB

    String Вид;

    //##ModelId=4DDA97990186

    String Номере;

    //##ModelId=4DDA97A70157

    String Размещение;

};

 

 

 

//##ModelId=4DCADAE00261

class Параметры заказа на рекламу

{

  public:

    //##ModelId=4DDA97E1032C

    Integer Ввод();

 

  private:

    //##ModelId=4DDA979100CB

    String Вид;

    //##ModelId=4DDA97990186

    String Номере;

    //##ModelId=4DDA97A70157

    String Размещение;

};

 

#endif /* ПАРАМЕТРЫ_ЗАКАЗА_НА_РЕКЛАМУ_H_HEADER_INCLUDED_B21CEE48 */

 

информация о продукте.cpp

#include "информация о продукте.h"

 

//##ModelId=4DDA9B710177

String информация о продукте::Сбор()

{

}

 

информация о продукте.h

#ifndef ИНФОРМАЦИЯ_О_ПРОДУКТЕ_H_HEADER_INCLUDED_B21CCC7F

#define ИНФОРМАЦИЯ_О_ПРОДУКТЕ_H_HEADER_INCLUDED_B21CCC7F

 

//##ModelId=4DD8B7900232

class информация о продукте

{

  public:

    //##ModelId=4DDA9B710177

    String Сбор();

 

  private:

    //##ModelId=4DDA9B340177

    String Наименование;

    //##ModelId=4DDA9B3C01B5

    String Вид;

    //##ModelId=4DDA9B41034B

    String Особенности;

    //##ModelId=4DDA9B4E0128

    String Производство;

};

 

#endif /* ИНФОРМАЦИЯ_О_ПРОДУКТЕ_H_HEADER_INCLUDED_B21CCC7F */

 

бюджет.cpp

#include "бюджет.h"

 

//##ModelId=4DDA9C520242

String бюджет::Рсачет()

{

}

 

бюджет.h

#ifndef БЮДЖЕТ_H_HEADER_INCLUDED_B21CD34E

#define БЮДЖЕТ_H_HEADER_INCLUDED_B21CD34E

 

//##ModelId=4DD8B7CA034B

class бюджет

{

  public:

    //##ModelId=4DDA9C520242

    String Рсачет();

 

  private:

    //##ModelId=4DDA9C680290

    String Вид;

    //##ModelId=4DDA9C77003E

    String Размещение;

    //##ModelId=4DDA9C8300AB

    String Направление;

};

 

 

 

#endif /* БЮДЖЕТ_H_HEADER_INCLUDED_B21CD34E */

 

сроки выполнения заказа.cpp

#include "сроки выполнения заказа.h"

сроки выполнения заказа.h

#ifndef СРОКИ_ВЫПОЛНЕНИЯ_ЗАКАЗА_H_HEADER_INCLUDED_B21CBD6A

#define СРОКИ_ВЫПОЛНЕНИЯ_ЗАКАЗА_H_HEADER_INCLUDED_B21CBD6A

 

//##ModelId=4DD8BB7B01E4

class сроки выполнения заказа

{

    //##ModelId=4DDAA49002FD

    Date Дата сдачи материала;

    //##ModelId=4DDAA4A201A5

    Double Неустойка;

};

 

 

 

#endif /* СРОКИ_ВЫПОЛНЕНИЯ_ЗАКАЗА_H_HEADER_INCLUDED_B21CBD6A */

 

координатор.cpp

#include "координатор.h"

 

//##ModelId=4DDA9F5500BB