50093 (Автоматизированная система торгового предприятия "МобилТел"), страница 4

Выводы по главе

В данной главе было рассмотрено понятие Интернет–магазина - это Интернет-витрина, где посетитель может выбрать товары, сформировать заявку, увидеть общую сумму заказа и отправить эту заявку менеджеру компании. Однако неоспоримы преимущества, которые дает Интернет – магазин:

• помогает быстро сориентироваться в ассортименте и найти нужный товар или услугу (по тематике, названию, цене и т.п.);

• рассмотреть товар "со всех сторон", сравнить его характеристики, цену, внешний вид с другими товарами;

• посмотреть информацию о скидках, подарков и подобного рода мероприятиях;

• рассчитать точную стоимость заказа;

• отобрать товар в корзину, оформить заказ on-line, оформить доставку на дом;

• поддерживать контакты продавец-покупатель.

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

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

Глава 2. Выбор средств разработки проекта. Решение задач проекта

2.1 Выбор и обоснование технологии проектирования и инструментальных средств разработки

2.1.1 Объектно–ориентированное проектирование

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

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

В своем дипломном проекте я использую методологию объектно–ориентированного проектирования, так как эта методология позволяет решить проблемы изменения функциональных требований заказчика, дает возможность "подстроиться" под внезапные перемены с наименьшими потерями. Модель проблемной области при объектно-ориентированном подходе рассматривается как совокупность взаимодействующих во времени объектов. Конкретный процесс обработки информации формируется в виде последовательности взаимодействия объектов. Так как этот подход предполагает совместное моделирование данных и процессов, то система объектно-ориентированных моделей последовательно направляется к модели динамического взаимодействия объектов, на основе которой могут быть сгенерированы классы объектов в конкретной программно-технической среде. [17]

Под моделью ПО в общем случае понимается формализованное описание системы ПО на определенном уровне абстракции. Каждая модель определяет конкретный аспект системы, использует набор диаграмм и документов заданного формата, а также отражает точку зрения и является объектом деятельности различных людей с конкретными интересами, ролями или задачами. Графические (визуальные) модели представляют собой средства для визуализации, описания, проектирования и документирования архитектуры системы.[15] Разработка модели системы ПО промышленного характера в такой же мере необходима, как и наличие проекта пристроительстве большого здания. Это утверждение справедливо как в случае разработки новой системы, так и при адаптации типовых продукт топ класса R/3 или BAAN, в составе которых также имеются собственные средства моделирования. Хорошие модели являются основой взаимодействия участников проекта и гарантируют корректность архитектуры. Поскольку сложность систем повышается, важно располагать хорошими методами моделирования. Хотя имеется много других факторов, от которых зависит успех проекта, но наличие строгого стандарта языка моделирования является весьма существенным. Состав моделей, используемых в каждом конкретном проекте, и степень их детальности в общем случае зависят от следующих факторов:

• сложности проектируемой системы;

• необходимой полноты ее описания;

• знаний и навыков участников проекта;

• времени, отведенного на проектирование.

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

Проанализировав, я пришел к выводу, что наиболее надежными средствами будут BPWin и Rational Rose.

2.1.2 BPWin и Rational Rose – инструментальные средства разработки

Визуальное моделирование оказало большое влияние на развитие ТС ПО вообще и CASEсредств в частности. Понятие CASE (Computer Aided Software Engineering) используется в настоящее время в весьма широком смысле. Первоначальное значение этого понятия, ограниченное только задачами автоматизации разработки ПО, в настоящее время приобрело новый смысл, охватывающий большинство процессов жизненного цикла ПО.[7] CASEтехнология представляет собой совокупность методов проектирования ПО, а так же набор инструментальных средств, позволяющих в наглядной форме моделировать предметную область, анализировать эту модель на всех стадиях разработки и сопровождения ПО и разрабатывать приложения в соответствии с информационными потребностями пользователей. Большинство существующих CASE - средств основано на методах структурного или объектно-ориентированного анализа и проектирования, использующих спецификации в виде диаграмм или текстов для описания внешних требований, связей между моделями системы, динамики поведения системы и архитектуры программных средств.[1]

BPWin.

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

• С точки зрения функциональности системы. В рамках методологии IDEF0(Integration Definition for Function Modeling) бизнес-процесс представляется в виде набора элементов-работ, которые взаимодействуют между собой, а также показывается информационные, людские и производственные ресурсы, потребляемые каждой работой.

• С точки зрения потоков информации (документооборота) в системе. Диаграммы DFD (Data Flow Diagramming) могут дополнить то, что уже отражено в модели IDEF3, поскольку они описывают потоки данных, позволяя проследить, каким образом происходит обмен информацией между бизнес-функциями внутри системы. В тоже время диаграммы DFD оставляют без внимания взаимодействие между бизнес-функциями.

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

Bpwin умеет проверять создаваемые модели с точки зрения синтаксиса выбранной методологии, проверяет ссылочную целостность между диаграммами, а также выполняет ряд других проверок, чтобы помочь вам создать правильную модель, а не просто рисунок. При этом сохраняются главные преимущества рисунка – простота создания и наглядность. [1]

Rational Rose.

Среди всех фирм-производителей CASE-средств именно компания Rational Software Corp. одна из первых осознала стратегическую перспективность развития объектно-ориентированных технологий анализа и проектирования программных систем. Эта компания выступила инициатором унификации языка визуального моделирования в рамках консорциума OMG, что, в конечном итоге, привело к появлению первых версий языка UML. И эта же компания первой разработала инструментальное объектно-ориентированное CASE-средство, в котором был реализован язык UML как базовая нотация визуального моделирования. [20]

Rational Rose - CASE-средство фирмы Rational Software Corporation (США) - предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации. Rational Rose использует синтез-методологию объектно-ориентированного анализа и проектирования, основанную на подходах трех ведущих специалистов в данной области: Буча, Рамбо и Джекобсона. Разработанная ими универсальная нотация для моделирования объектов (UML - Unified Modeling Language) претендует на роль стандарта в области объектно-ориентированного анализа и проектирования. Конкретный вариант Rational Rose определяется языком, на котором генерируются коды программ (C++, Smalltalk, PowerBuilder, Ada, SQLWindows и ObjectPro). Основной вариант - Rational Rose/C++ - позволяет разрабатывать проектную документацию в виде диаграмм и спецификаций, а также генерировать программные коды на С++. Кроме того, Rational Rose содержит средства реинжиниринга программ, обеспечивающие повторное использование программных компонент в новых проектах.

Унифицированный язык моделирования UML (Unified Modeling Language) представляет собой язык для определения, представления, проектирования и документирования программных систем, организационно-экономических систем, технических систем и других систем различной природы. UML содержит стандартный набор диаграмм и нотаций самых разнообразных видов.UML – это преемник того поколения методов ООАП, которые появились в конце 1980х и начале 1990х годов. Создание UML фактически началось в конце 1994 г., когда Гради Буч и Джеймс Рамбо начали работу по объединению их методов Booch и OMT (Object Modeling Technique) под эгидой компании Rational Software. К концу 1995 г. они создали первую спецификацию объединенного метода, названного ими Unified Method, версия 0.8. Тогда же в 1995 г. к ним присоединился создатель метода OOSE (ObjectOriented Software Engineering) Ивар Якобсон. Таким образом, UML является прямым объединением и унификацией методов Буча, Рамбо и Якобсона, однако дополняет их новыми возможностями. Главными в разработке UML были следующие цели:

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

• предусмотреть механизмы расширяемости и специализации для расширения базовых концепций;

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

• обеспечить формальную основу для понимания этого языка моделирования (язык должен быть одновременно точным и доступным для понимания, без лишнего формализма);

• стимулировать рост рынка объектно-ориентированных инструментальных средств;

• интегрировать лучший практический опыт.

UML находится в процессе стандартизации, проводимом OMG (Object Management Group) – организацией по стандартизации в области объектноориентированных методов и технологий, в настоящее время принят в качестве стандартного языка моделирования и получил широкую поддержку в индустрии ПО. UML принят на вооружение практически всеми крупнейшими компаниями – производителями ПО (Microsoft, Oracle, IBM, HewlettPackard, Sybase и др.). Кроме того, практически все мировые производители CASEсредств, помимо IBM Rational Software, поддерживают UML в своих продуктах (Oracle Designer, Together Control Center (Borland), AllFusion Component Modeler (Computer Associates), Microsoft Visual Modeler и др.). [20]

В результате разработки проекта с помощью CASE-средства Rational Rose формируются следующие документы:

• диаграммы классов;

• диаграммы состояний;

• диаграммы сценариев;

• диаграммы модулей;

• диаграммы процессов;

• спецификации классов, объектов, атрибутов и операций

• заготовки текстов программ;

• модель разрабатываемой программной системы.

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

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

2.2 Схема работы Интернет-магазина

2.2.1 Функциональные требования

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

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