Программное обеспечение интернет-магазина

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

1

Программное обеспечение интернет-магазина



Введение

Требуется разработать средствами Rational Rose модель программного обеспечения Интернет-магазина.

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

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

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

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

клиентская Web-страница;

серверная Web-страница (например, CGI-скрипт);

HTML-форма;

объект JavaScript.

Дополнительные связи между классами Web-приложений:

link - ссылка с одной страницы на другую;

build - связь между CGI-скриптом и клиентской страницей, генерируемой при его выполнении;

submit - связь между формой и серверной Web-страницей, принимающей данные из формы.

Типичные компоненты:

Web-страница (HTML-файл),

Active Server Page (ASP),

Java Server Page (JSP),

сервлет,

библиотека скриптов (например, подключаемый файл с Javascript-функциями).



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

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

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

Актер	Краткое описание
Клиент	Физическое лицо, потенциальный покупатель интернет-магазина, выбирает товар по каталогу на сайте, делает заказ, оплачивает безналично через банк или наличными при доставке
Администратор интернет-магазина	Управляет каталогом товаров, отслеживает заказы клиентов, следит за наличием товара

Выделим следующие прецеденты:

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

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

2. Описание потока событий для одного прецедента

Поток событий для прецедента "Работа с заказами".

Предусловие

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

Главный поток

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

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

Под-потоки

Добавить новый заказ

Система отображает диалоговое окно, содержащее поля, в которые клиент должен ввести данные о заказе. Клиент заполняет поля. Система запоминает введенные данные. Затем прецедент начинается сначала.

Изменить заказ

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

Удалить заказ

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

Просмотреть заказ

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

Альтернативные потоки

Введено неправильное имя или пароль. Модератор должен повторить ввод или завершить прецедент.

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

Введен неправильный номер заказа. Модератор должен повторить ввод или завершить прецедент.

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

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

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

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



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

На основании данной диаграммы создадим диаграмму коопераций.

3. Диаграмма коопераций

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

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

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

На рис. 3 представлена диаграмма коопераций для варианта заказа товара клиентом на сайте интернет-магазина. На диаграмме представлены способы взаимодействия актеров и классов системы.

Рисунок 3. - Диаграмма коопераций.

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

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

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

На рис. 4 представлена диаграмма классов для интернет-магазина. На диаграмме представлены следующие классы:

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



5. Описание классов

Класс Catalog(представляет сущность) - Класс, представляющий собой каталог товаров на сайте

Атрибут

Id tovara (private): int - идентификационный номер товара;

Tovar: char - наименование товара;

col: long - количество товара на складе;

cena:long - цена за ед. товара

Все атрибуты имеют модификатор доступа - private

Операции

Find() - поиск товара в каталоге клиентом;

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

AddResume() - добавление отзыва клиентом;

CreateRanking() - составление рейтинга товаров администраторм;

Класс Sklad(представляет сущность) - Класс, представляющий собой склад товаров интернет-магазина

Атрибуты

Id tovar (private): int - идентификационный номер товара;

postavchik(private):char - поставщик товара:

Операции

ColTovar() - расчет количества товара с учетом купленного;

MinusTovar()- отнять от количества купленый товар;

PlusTovar()- добавить в количество поступивший товар

Все операции имеют модификатор доступа - public

Класс Shop(представляет сущность)- Класс, представляющий собой меню заказа, которое заполняет клиент

Атрибуты

FIO pokupatelia(private): char - ФИО покупателя:

№ tel(private): long - номер телефона покупателя для связи;

Id tovara (private): int - идентификационный номер товара;

kol-vo : int - количество заказанного товара;

Операции

AddZakaz() - добавление заказа клиентом;

DeleteZakaz() - удаление заказа клиентом

AddSumm() - при добавлении заказа расчет суммы заказа;

DeleteSumm() - при удалении заказа удаление суммы заказа;

Все операции имеют модификатор доступа - public

Класс Bank(представляет сущность)- Класс, представляющий собой оплату заказа клиентом через банк

Атрибуты

№ schet : long номер счета в банке для оплаты покупки;

Атрибуты имеет модификатор доступа - private

Операции

OpenTranzaktion() - открыть транзакцию перевода денег;

СloseTranzaktion() - закрыть транзакцию перевода денег;

OpenAccount() - открыть доступ для оплаты;

СloseAccount() - закрыть доступ для оплаты;

Summoper() - перевод суммы операции на счет;

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

Связи между классами

класс InterfaceSystem и Catalog - отношение агрегации. На странице интернет магазина отображается список всех товаров, поэтому кратность связи со стороны класса InterfaceSystem - 1, со стороны Catalog - 1..n;

класс InterfaceSystem и Sklad - отношение ассоциации, поскольку система автоматически уменьшает количество товара в базе склада при заказе. В один заказ может входить несколько строк товара, поэтому кратность связи со стороны InterfaceSystem - 1, со стороны Sklad - 1..n;

класс InterfaceSystem и Shop - отношение агрегации, поскольку данные заказа являются частями меню заказа В системе может быть зарегистрировано от 1 до n заказов, поэтому кратность связи со стороны InterfaceSystem - 1, со стороны Shop - 1..n.

класс InterfaceSystem и Bank - отношение ассоциации. Система фиксирует все оплаты клиентов, оплат может быть от 1 до n.

6. Диаграмма деятельности

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

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

7. Диаграмма состояния

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

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

На рис. 5 представлена диаграмма состояний для состояния классов при регистрации заказа через Интернет и основных действий всей системы интернет-магазина.

Рисунок 6. - Диаграмма состояния.

8. Диаграмма Компонентов

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

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

На рис. 7 представлена диаграмма компонентов для интернет-магазина. На ней показано физическое представление модели.

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

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

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

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

Те компоненты, которые не используются на этапе исполнения, на диаграмме развертывания не показываются. Так, компоненты с исходными текстами программ могут присутствовать только на диаграмме компонентов. На диаграмме развертывания они не указываются.

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

программный интернет сервер диаграмма

10. Программный код для классов системы

Этап кодогенерации

Выбираем класс

Указываем наполнение классов операциями:

Аналогично генерируем коды на С++ других классов

Автоматически сгенерированные тексты программ классов на языке С++, представленных на диаграмме классов:

Для класса Bank:

Файл Bank.h

#ifndef BANK1_H_HEADER_INCLUDED_B4090090

#define BANK1_H_HEADER_INCLUDED_B4090090

//##ModelId=4A25750A037A

class Bank

public:

//##ModelId=4A257BCD01C5

OpenTranzaktion();

//##ModelId=4A257BE502AF

CloseTransaction();

//##ModelId=4A257BF7036B

bool OpenAccount(long klient);

//##ModelId=4A257C12037A

bool CloseAccount(long klient);

//##ModelId=4A257C32037A

long SummOper(bool db_kr, long summ);

//##ModelId=4BF6AE5903BE

static void* operator new(size_t size);

//##ModelId=4BF6AE5A0024

static void operator delete(void* ptr);

//##ModelId=4BF6AE5A0063

long get_№ schet() const;

//##ModelId=4BF6AE5A0073

void set_№ schet(long left);

private:

//##ModelId=4BF692370034

long № schet;

};

#endif /* BANK1_H_HEADER_INCLUDED_B4090090 */Файл Bank.cpp

#include "Bank1.h"

//##ModelId=4A257BCD01C5

Bank::OpenTranzaktion()

{}

//##ModelId=4A257BE502AF

Bank::CloseTransaction()

{}

//##ModelId=4A257BF7036B

bool Bank::OpenAccount(long klient)

{}

//##ModelId=4A257C12037A

bool Bank::CloseAccount(long klient)

{}

//##ModelId=4A257C32037A

long Bank::SummOper(bool db_kr, long summ)

{}

//##ModelId=4BF6AE5903BE

void* Bank::operator new(size_t size)

{}

//##ModelId=4BF6AE5A0024

void Bank::operator delete(void* ptr)

{}

//##ModelId=4BF6AE5A0063

long Bank::get_№ schet() const

{ return № schet;}

//##ModelId=4BF6AE5A0073

void Bank::set_№ schet(long left)

{ № schet = left;}

Для класса Catalog:

Файл Catalog.h

#ifndef CATALOG_H_HEADER_INCLUDED_B4091969

#define CATALOG_H_HEADER_INCLUDED_B4091969

//##ModelId=4A257564036B

public:

//##ModelId=4A25768B008C

long Find(char name, char autor, char isbn, char key_chars);

//##ModelId=4A257B200213

Public();

//##ModelId=4A2580390251

AddResume(char text);

//##ModelId=4A258052029F

CreateRanking();

//##ModelId=4BF6B03F0332

static void* operator new(size_t size);

//##ModelId=4BF6B03F0370

static void operator delete(void* ptr);

//##ModelId=4BF6B03F03BE

long get_cena() const;

//##ModelId=4BF6B03F03CF

void set_cena(long left);

//##ModelId=4BF6B0400024

long get_col() const;

//##ModelId=4BF6B0400035

void set_col(long left);

//##ModelId=4BF6B0400082

int get_id tovara() const;

//##ModelId=4BF6B0400093

void set_id tovara(int left);

//##ModelId=4BF6B04000D0

char get_tovar() const;

//##ModelId=4BF6B04000F0

void set_tovar(char left);

//##ModelId=4A25764202CE

char tovar;

//##ModelId=4A25765C0213

long col;

//##ModelId=4A25766801A5

long cena;

private:

//##ModelId=4BF691DC0005

int id tovara;};

#endif /* CATALOG_H_HEADER_INCLUDED_B4091969 */

Файл Catalog.cpp

#include "Catalog.h"

//##ModelId=4A25768B008C

long Catalog::Find(char name, char autor, char isbn, char key_chars)

{}

//##ModelId=4A257B200213

Catalog::Public()

{}

//##ModelId=4A2580390251

Catalog::AddResume(char text)

{}

//##ModelId=4A258052029F

Catalog::CreateRanking()

{}

//##ModelId=4BF6B03F0332

void* Catalog::operator new(size_t size)

{}

//##ModelId=4BF6B03F0370

void Catalog::operator delete(void* ptr)

{}

//##ModelId=4BF6B03F03BE

long Catalog::get_cena() const

{ return cena;}

//##ModelId=4BF6B03F03CF

void Catalog::set_cena(long left)

{ cena = left;}

//##ModelId=4BF6B0400024

long Catalog::get_col() const

{ return col;}

//##ModelId=4BF6B0400035

void Catalog::set_col(long left)

{col = left;}

//##ModelId=4BF6B0400082

int Catalog::get_id tovara() const

{ return id tovara;}

//##ModelId=4BF6B0400093

void Catalog::set_id tovara(int left)

{ id tovara = left;}

//##ModelId=4BF6B04000D0

char Catalog::get_tovar() const

{ return tovar;}

//##ModelId=4BF6B04000F0

void Catalog::set_tovar(char left)

{ tovar = left;}

Для класса Shop:

Файл Shop.h

#ifndef SHOP_H_HEADER_INCLUDED_B4092442

#define SHOP_H_HEADER_INCLUDED_B4092442

//##ModelId=4A2574F8030D

class Shop

public:

//##ModelId=4A25784501A5

long AddZakaz();

//##ModelId=4A257853006D

bool DeleteZakaz(long num);

//##ModelId=4A257FD202EE

long AddSumm();

//##ModelId=4A257FE603D8

long DeleteSumm();

//##ModelId=4BF6B1090370

static void* operator new(size_t size);

//##ModelId=4BF6B109039F

static void operator delete(void* ptr);

//##ModelId=4BF6B10903DD

char get_FIO pokupatelia() const;

//##ModelId=4BF6B10A0005

void set_FIO pokupatelia(char left);

//##ModelId=4BF6B10A0044

int get_id tovara() const;

//##ModelId=4BF6B10A0054

void set_id tovara(int left);

//##ModelId=4BF6B10A0092

int get_kol-vo() const;

//##ModelId=4BF6B10A00B2

void set_kol-vo(int left);

//##ModelId=4BF6B10A00EF

long get_№ tel() const;

//##ModelId=4BF6B10A010F

void set_№ tel(long left);

private:

//##ModelId=4BF69176019B

char FIO pokupatelia;

//##ModelId=4BF691B10015

long № tel;

//##ModelId=4BF691CB01CA

int id tovara;

//##ModelId=4BF6A95801CA

int kol-vo;};

#endif /* SHOP_H_HEADER_INCLUDED_B4092442 */

Файл Shop.cpp

#include "Shop.h"

//##ModelId=4A25784501A5

long Shop::AddZakaz()

{}

//##ModelId=4A257853006D

bool Shop::DeleteZakaz(long num)

{}

//##ModelId=4A257FD202EE

long Shop::AddSumm()

{}

//##ModelId=4A257FE603D8

long Shop::DeleteSumm()

{}

//##ModelId=4BF6B1090370

void* Shop::operator new(size_t size)

{}

//##ModelId=4BF6B109039F

void Shop::operator delete(void* ptr)

{}

//##ModelId=4BF6B10903DD

char Shop::get_FIO pokupatelia() const

{ return FIO pokupatelia;}

//##ModelId=4BF6B10A0005

void Shop::set_FIO pokupatelia(char left)

{ FIO pokupatelia = left;}

//##ModelId=4BF6B10A0044

int Shop::get_id tovara() const

{ return id tovara;}

//##ModelId=4BF6B10A0054

void Shop::set_id tovara(int left)

{ id tovara = left;}

//##ModelId=4BF6B10A0092

int Shop::get_kol-vo() const

{ return kol-vo;}

//##ModelId=4BF6B10A00B2

void Shop::set_kol-vo(int left)

{ kol-vo = left;}

//##ModelId=4BF6B10A00EF

long Shop::get_№ tel() const

{ return № tel;}

//##ModelId=4BF6B10A010F

void Shop::set_№ tel(long left)

{ № tel = left;}

Для класса Sklad:

Файл Sklad.h

#ifndef SKLAD_H_HEADER_INCLUDED_B409790D

#define SKLAD_H_HEADER_INCLUDED_B409790D

//##ModelId=4A25752A0119

class Sklad

public:

//##ModelId=4A25789400CB

long ColTovar(long tovar);

//##ModelId=4A2578D60109

CreateCatalog();

//##ModelId=4A257B4C036B

bool MinusTovar(long tovar);

//##ModelId=4A257BA50242

bool PlusTovar(long tovar);

//##ModelId=4BF6B1BD015D

static void* operator new(size_t size);

//##ModelId=4BF6B1BD018C

static void operator delete(void* ptr);

//##ModelId=4BF6B1BD01BB

int get_id tovar() const;

//##ModelId=4BF6B1BD01CB

void set_id tovar(int left);

//##ModelId=4BF6B1BD0218

char get_postavchik() const;

//##ModelId=4BF6B1BD0238

void set_postavchik(char left);

private:

//##ModelId=4BF691F6038F

int id tovar;

//##ModelId=4BF691FE019B

char postavchik;};

#endif /* SKLAD_H_HEADER_INCLUDED_B409790D */

Файл Sklad.cpp

#include "Sklad.h"

//##ModelId=4A25789400CB

long Sklad::ColTovar(long tovar)

//##ModelId=4A2578D60109

Sklad::CreateCatalog()

{}

//##ModelId=4A257B4C036B

bool Sklad::MinusTovar(long tovar)

{}

//##ModelId=4A257BA50242

bool Sklad::PlusTovar(long tovar)

{}

//##ModelId=4BF6B1BD015D

void* Sklad::operator new(size_t size)

{}

//##ModelId=4BF6B1BD018C

void Sklad::operator delete(void* ptr)

{}

//##ModelId=4BF6B1BD01BB

int Sklad::get_id tovar() const

{ return id tovar;}

//##ModelId=4BF6B1BD01CB

void Sklad::set_id tovar(int left)

{ id tovar = left;}

//##ModelId=4BF6B1BD0218

char Sklad::get_postavchik() const

{ return postavchik;}

//##ModelId=4BF6B1BD0238

void Sklad::set_postavchik(char left)

{ postavchik = left;}



Вывод

В ходе анализа поставленной задачи - разработка модели системы интернет-магазина была спроектирована данная система в в среде Rational Rose, а именно разработаны диаграммы основных действий со стороны клиента и администратора сайта в данной системе.

Литература

1. М. Фаулер, К.Скотт. UML в кратком изложении. М. Мир. 1999. 191 с.

2. Грейди Буч, Джеймс Рамбо, Айвар Джекобсон. UML. Руководство пользователя. М. ДМК 2000. 432 с.

3. Фаулер М., Скотт К. UML. Основы. - Пер. с англ. - СПб: Символ-Плюс, 2002. - 192с., ил.

4. Уэнди Боггс, Майкл Боггс "UML и Rational Rose 2002" /Пер. с англ. - М. "Лори", 2004.

Размещено на Allbest.ru

...