Разработка и внедрение сайта транспортной компании ООО «ТрансЭнергоСервис»

Введение

ГЛАВА 1. ИССЛЕДОВАНИЕ ОРГАНИЗАЦИОННОЙ СТРУКТУРЫ ООО «ТРАНСЭНЕРГОСЕРВИС»

1.1 Организация работы ООО «ТрансЭнергоСервис»

1.2 Анализ функционирования интернет-сайтов по предоставлению услуг

ГЛАВА 2. МЕТОДОЛОГИЯ ПРОЕКТИРОВАНИЯ ИНТЕРНЕТ — САЙТА

2.1 Обзор методологий проектирования интернет-представительства

2.2 IDEF0

2.3 UML

2.4 DFD

2.5 ER-модель «сущность-связь»

ГЛАВА 3. РАЗРАБОТКА ИНТЕРНЕТ-САЙТА ДЛЯ ООО «ТРАНСЭНЕРГОСЕРВИС»

3.1 Инструментальные средства разработки и реализации системы управления сайтом

3.2 Разработка интерфейса пользователя

3.3 Реализация интерфейса web-сайта

Заключение

Приложение

Введение

интернет сайт интерфейс пользователь

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

В сайт, как инструмент маркетинга, заложены огромные возможности.

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

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

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

Объектом исследования в дипломной работе является веб-сайт ООО «ТрансЭнергоСервис».

Целью дипломной работы является разработка и внедрение сайта транспортной компании ООО «ТрансЭнергоСервис». Для достижения поставленной цели мы решим другие, более частные задачи:

— в первой главе мы рассмотрим организацию работы ООО «ТрансЭнергоСервис»;

— во второй будет описана методология разработки сайта;

— в третьей будет исследована разработка сайта ООО «ТрансЭнергоСервис».

Теоретической и методической основой дипломной работы послужили работы ведущих отечественных специалистов в проектирования Интернет-сайтов: Калиновский А. И., Монахов М. Ю., Воронин А. А., и многих других.

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

Список использованных источников

насчитывает 22 источника.

ГлаВа 1. ИсследоВание организационной струКтуры ООО «ТрансэнергосерВис»

1.1 Организация работы ООО «ТрансЭнергоСервис»

Общество с ограниченной ответственностью «ТрансЭнергоСервис» создается с целью организации производства и реализации услуг по перевозке грузов в г. Волгоград.

Виды услуг:

— услуги по квартирным переездам, перевозу мебели (в том числе пианино), перевозка других хозяйственных грузов (дрова, уголь, сено и т. д.); розничная цена одной условной единицы услуги (3 часа работы автомобиля + 3 часа работы четырех грузчиков) 4,0 — 5,5 тыс. руб.; планируемый годовой объем производства услуг порядка 600 единиц;

— услуги по перевозке коммерческих грузов; розничная цена (6 часов работы автомобиля + лебедка + 6 часов работы четырех грузчиков) 11,0 -18,0 тыс. руб.; планируемый объем выпуска в год — 96 единиц;

— услуги антикоррозийной обработки кузовных элементов автомобилей по технологии RUST-STOP (Canada); стоимость обработки одного автомобиля — 0,9 тыс. руб.; планируемый годовой объем работ — 3600 единиц.

Производственно-хозяйственная деятельность:

— производственно-хозяйственная деятельность производится на основе договоров;

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

Для организации деятельности предприятие располагает как собственными, так и арендованными площадями:

Собственные площади: гараж 220 кв. м (г. Волгоград).

Арендуемые площади: цех по антикоррозийной обработке автомобилей 90 кв.м. (г. Волгоград).

На момент начала реализации инвестиционного проекта (предположительно август 2007 г.) предприятие имеет всю необходимую для организации производства техническую документацию и лицензии.

Закуплена технологическая документация для организации специализированного участка (цеха) антикоррозийной обработки автомобилей RUST-STOP (Canada).

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

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

В последние годы в г. Волгограде успешно развивается организация и открытие всевозможных предприятий, работающих с населением и предлагающих услуги по перевозкам грузов по приемлемых ценам. в условиях снижения и стабилизации покупательской способности населения эта форма производства все же способствует развитию спроса. Большую роль в данном деле играет ООО «ТрансЭнергоСервис». Доля рынка, занимаемая предприятием на начальном этапе деятельности составит примерно 15%.

Рисунок 1.1 — Доля рынка ООО «ТрансЭнергоСервис» -15%

На самом деле серьезных прямых конкурентов у ООО «ТрансЭнергоСервис» много.

Таблица 1.1 — Оценка собственной фирмы и фирм конкурентов, баллы

В таблице 1.1 приведены оценки достоинств и недостатков как собственной фирмы, так и фирм-конкурентов. Оценки выставлялись в баллах от 0 до + 10.

Если посчитать сумму баллов каждой «фирмы», то получим следующие результаты:

ООО «ТрансЭнергоСервис»: 37 баллов.

Небольшие фирмы: 36 баллов.

Перевозочные предприятия: 35 баллов.

Еще раз нужно уточнить, что оценка производилась, исходя из предположения: предприятия уже существуют. Соответственно, большой вклад в баллах внесла такая характеристика, как месторасположение объекта. Что касается ООО «ТрансЭнергоСервис», то ассортимент данного грузоперевозочного предприятия имеет достаточную ширину и глубину. Достаточно взглянуть на таблицу 1.1.

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

1.2 Анализ функционирования интернет-сайтов по предоставлению услуг

Виртуальным хостингом называют предоставление веб-сервера в пользование с оказанием различных видов услуг на таких условиях, чтобы клиентам (организациям, предприятиям или частным лицам) не было нужды приобретать и поддерживать (обслуживать, ремонтировать) свой собственный хост Термин «хост» (англ. host — хозяин) означает любой? омпьютер, имеющий полный д? усторонний доступ? другим? омпьютерам? Интернете. ?аждый хост имеет специальный номер, ?оторый ?месте с сете? ым номером формирует его уни? альный адрес IP (Internet Protocol). Виртуальный хостинг-провайдера иногда еще называют пространственным провайдером (space provider).

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

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

Совместный хостинг позволяет клиентам размещать свои веб-сайты на совместно используемом сервере хостинг-провайдера: дисковое пространство сервера разделяется на множество «пакетов», каждый из которых содержит определенное количество пространства, измеряемое в мегабайтах.

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

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

Если в договоре хостинга (счетах, актах) операции, составляющие хостинг, разделены, и оплата за данные составляющие производится также раздельно, то в налоговом учете такие суммы отражаются так, как это представлено в таблице 1.1. Но чаще хостинг-провайдеры предлагают оплатить свои услуги одним платежом. В этом случае бухгалтеры стоят перед дилеммой, как отражать операцию хостинга в налоговом учете: как получение услуги или как арендную операцию (аренду материального объекта — сервера).

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

Поскольку в РФ еще не сложилась единая электронная терминология, то провайдеры часто называют хостингом как классический хостинг, так и аренду дискового пространства, и даже виртуальный сервер. Поэтому при отражении операции хостинга в налоговом учете следует ориентироваться на аналогию, приведенную выше. Если пакет услуг, предоставляемых хостинг-провайдером, настолько широк, что невозможно выделить из общей суммы оплаты стоимость аренды дискового пространства, то такой виртуальный хостинг считается услугой и отражается в налоговом учете согласно п. 5.1 и пп. 5.2.1 Закона о прибыли. Но если хостинг включает в себя только аренду дискового пространства и еще, может быть, копеечную регистрацию почтового ящика, то такая операция отражается как арендная с соблюдением условий пп. 7.9.6 Закона о прибыли и других норм налогового законодательства об оперативном лизинге (аренде).

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

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

1) плата за право пользования программным обеспечением;

2) плата за хранение программного обеспечения на чужом жестком диске.

Так как второй элемент относится к хостингу, то получается, что в общем операция рассматривается как пользование программным обеспечением по лицензионному соглашению с элементами услуги. После долгих споров в марте 2000 г. бухгалтеры США достигли консенсуса, который воплотился в выпуске 00−3 EITF Emerging Issues Task Force — рабочая группа по? озни?ающим проблемам. «Договоры, включающие право пользования программным обеспечением, хранящемся на жестком диске другого предприятия», приложению к SOP Statement of Position — зая? ление о позиции. 97−2. Данный документ устанавливает, что если в операции хостинга присутствует элемент пользования программным обеспечением провайдера, то все равно хостинг считается услугой. Но только в том случае, если в договоре отсутствует условие, согласно которому клиент имеет право в течение договора хостинга приобрести программное обеспечение без значительных преград. Если такое условие присутствует, то доход хостинг-провайдера должен быть разбит на составляющие (приобретение программного обеспечения и услуги хостинга) в оценке их справедливой стоимости. Тогда доход признается:

1) по программному обеспечению — на дату поставки программного обеспечения;

2) по услугам хостинга — на дату предоставления услуг.

Собственно, подобная трактовка вполне применима и в украинском бухгалтерском учете. Пользование компьютерной программой удаленно, когда программа хранится на чужом жестком диске, считается услугой хостинга (если провайдер обслуживает, модернизирует и улучшает эту программу). Но если клиент имеет право получить такую программу в собственность в течение срока действия договора, то в бухгалтерском учете признание дохода отражается в момент передачи покупателю рисков и выгод, связанных с правом собственности на компьютерную программу (ст. 8 П (С)БУ 15). Следовательно, доход провайдера, продавшего программу, отразится в бухгалтерском учете в тот момент, когда право собственности на компьютерную программу перейдет к покупателю, при этом доход отражается по справедливой стоимости компьютерной программы (ст. 21 П (С)БУ 15). А услуги по хранению программы и ее обслуживанию относятся к услугам хостинга и отражаются в соответствии со статьями 10 и 21 П (С)БУ 15.

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

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

Очень важно понимать разницу между виртуальным хостингом и виртуальным сервером (см. таблицу 1.2).

Уак видим, услуги виртуального сервера сводятся только лишь к аренде дискового пространства сервера у провайдера. Оказание услуг провайдером или отсутствует вообще, или сведено до минимума. Поэтому операция виртуального сервера отражается в налоговом учете как арендная с учетом требований пп. 7.9.6 Закона о прибыли.

Складирование данных Складированием данных (data warehousing) называется перенос данных на серверы меньшего размера, где их (данные) можно быстро и легко проанализировать.

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

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

Операции по складированию данных относятся к услугам по хранению. Расходы на услуги по хранению увеличивают валовые расходы налогоплательщика согласно п. 5.1 и пп. 5.2.1 Закона о прибыли.

Роялти и договоры хостинга В электронном мире уже сейчас очень много нематериальных активов, и число их неуклонно растет. В РФ, как и во многих других странах, выплаты роялти в денежной форме или в виде ценных бумаг освобождены от начисления НДС (пп. 3.2.7 Закона о НДС). Поэтому проблема правильного определения того, какие платежи относятся к роялти, а какие — к компенсационным, актуальны во всем мире. Росийское законодательство не регулирует таких вопросов, поэтому представим как информацию к размышлению видение данной проблемы с точки зрения Технической консультативной Группы (TAG Technical Advisory Group.) Организации за экономическое сотрудничество и развитие (OECD Organisation for Economic Co-operation and Development). TAG выпустила документ под названием «Основные характеристики проблем, возникающих в электронной коммерции», в котором эксперты определили свой взгляд на вопрос, какие платежи в электронной коммерции являются роялти, а какие основаны на компенсационных платежах. выводы TAG представлены в таблице 1.3.

Виды услуг при осуществлении виртуального хостинга:

· содействие в регистрации доменного имени;

· размещение файлового запоминающего устройства;

· предоставление почтового адреса;

· оказание услуг по созданию веб-сайта;

· административные услуги и поддержка;

· мониторинг сетевого порта, оперативной системы, Интернета;

· выравнивание (балансирование) нагрузки,

· управление базой данных и др.

Таблица 1.1

Составляющие виртуального хостинга

Таблица 1.2

Отличительные характеристики между виртуальным хостингом и виртуальным сервером

Таблица 1.3

Характеристика платежей в операциях хостинга по TAG OECD

ГлаВа 2. Методология проеКтироВания интернет — сайта

2.1 Обзор методологий проектирования интернет-представительства

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

Итак, под методами создания интернет-сайтов понимается совокупность приемов и инструментов разработки. Самыми распространенными методами можно назвать:

1. Шаблоны. Шаблон представляет собой написанный один раз «движок» — программную часть сайта, отвечающую за его функциональность, и растиражированный дизайн — то есть внешнюю, видимую часть сайта. Из несомненных достоинств данного метода можно отметить простоту создания: ресурс может создать школьник, который уложиться в рекордно короткий срок — час, не более (большая часть времени уйдет на поиск шаблона). Главный же недостаток — растиражированность.

2. Конструктор сайта. Почти то же самое, что и шаблон. Главное отличие — возможность подключения определенных модулей (допустим, можно добавить поиск по сайту и, в то же время, избавиться от каталога). конструктор позволяет выбрать и элементы дизайна, и даже переработать их. Но ключевые элементы, по-прежнему, будут занимать свои места. Минусы и плюсы конструктора аналогичны положительным и отрицательным чертам шаблонов.

3. WYSIWYG-редакторы — (What You See Is What You Get — дословно — «что ты видишь, то и получаешь», англ.) специальные программные среды разработки сайтов, такие как Dream Weaver или Front Page. Сочетание среды разработки сайта, графических редакторов (Adobe Photoshop, Corel Photopaint и пр.) позволяет создавать сайт и сразу видеть конечный результат, который сразу же можно протестировать. Из плюсов отмечается скорость разработки и возможность написания ресурса всего лишь одним человеком, так как подобный метод не предполагает необходимость познаний в языках программирования (Java, PHP и пр.), поскольку ядро пишется автоматически средой разработки. к недостаткам стоит отнести низкий уровень защиты от вирусных атак, от проникновения злоумышлеников (так как методы обхода защиты программной части такого сайта известны многим хакерам и вирусописателям). Также стоит добавить, что полученные скрипты не всегда работают так, как задумывалось, и функциональность оказывается чуть «ущербной». Кроме того, такой сайт «тяжел» для загрузки при медленном подключении к сети интернет, его код не оптимизирован, что вызывает «подвисания» браузера.

4. Сочетание WYSIWYG-редактора и программирования. в данном случае создание сайта происходит в той же среде разработки, но впоследствии над программным кодом работает программист, переписывая или корректируя созданные скрипты. Специалист усиливает защиту сайта, которая будет противостоять вирусным и хакерским атакам, отлаживает «движок», выстраивает функциональность. качественный сайт можно получить только применив подобный метод. Единственным его недостатком считается высокая цена разработки.

2.2 IDEF0

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

Наиболее удобным языком моделирования бизнес-процессов является IDEF0, предложенный более 20 лет назад Дугласом Россом (SoftTech, Inc.) и называвшийся первоначально SADT — Structured Analysis and Design Technique. (Подробно методология SADT излагается в книге Дэвида А. Марка и клемента Мак-Гоуэна «Методология структурного анализа и проектирования SADT» M.:Meтaтexнoлoгия, 1993.) В начале 70-х годов вооруженные силы США применили подмножество SADT, касающееся моделирования процессов, для реализации проектов в рамках программы ICAM (Integrated Computer-Aided Manufacturing). В дальнейшем это подмножество SADT было принято в качестве федерального стандарта США под наименованием IDEF0. Подробные спецификации на стандарты IDEF можно найти на сайте http://www.idef.com .

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

Под моделью в IDEF0 понимают описание системы (текстовое и графическое), которое должно дать ответ на некоторые заранее определенные вопросы.

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

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

Под субъектом понимается сама система, при этом необходимо точно установить, что входит в систему, а что лежит за ее пределами, другими словами, мы должны определить, что мы будем в дальнейшем рассматривать как компоненты системы, а что как внешнее воздействие. На определение субъекта системы будет существенно влиять позиция, с которой рассматривается система, и цель моделирования — вопросы, на которые построенная модель должна дать ответ. Другими словами, первоначально необходимо определить область (Scope) моделирования. Описание области как системы в целом, так и ее компонентов является основой построения модели. Хотя предполагается, что в течение моделирования область может корректироваться, она должна быть в основном сформулирована изначально, поскольку именно область определяет направление моделирования и когда должна быть закончена модель. При формулировании области необходимо учитывать два компонента — широту и глубину. Широта подразумевает определение границ модели — мы определяем, что будет рассматриваться внутри системы, а что снаружи. Глубина определяет, на каком уровне детализации модель является завершенной. При определении глубины системы необходимо не забывать об ограничениях времени — трудоемкость построения модели растет в геометрической прогрессии от глубины декомпозиции. После определения границ модели предполагается, что новые объекты не должны вноситься в моделируемую систему; поскольку все объекты модели взаимосвязаны, внесение нового объекта может быть не просто арифметической добавкой, но в состоянии изменить существующие взаимосвязи. внесение таких изменений в готовую модель является, как правило, очень трудоемким процессом (так называемая проблема «плавающей области»).

Цель моделирования (Purpose). Модель не может быть построена без четко сформулированной цели. Цель должна отвечать на следующие вопросы:

* Почему этот процесс должен быть замоделирован?

* Что должна показывать модель?

* Что может получить читатель?

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

Точка зрения (Viewpoint). Хотя при построении модели учитываются мнения различных людей, модель должна строиться с единой точки зрения. Точку зрения можно представить как взгляд человека, который видит систему в нужном для моделирования аспекте. Точка зрения должна соответствовать цели моделирования. Очевидно, что описание работы предприятия с точки зрения финансиста и технолога будет выглядеть совершенно по-разному, поэтому в течение моделирования важно оставаться на выбранной точке зрения. Как правило, выбирается точка зрения человека, ответственного за моделируемую работу в целом. Часто при выборе точки зрения на модель важно задокументировать дополнительные альтернативные точки зрения. Для этой цели обычно используют диаграммы FEO (For Exposition Only), которые будут описаны в дальнейшем.

IDEF0-модель предполагает наличие четко сформулированной цели, единственного субъекта моделирования и одной точки зрения. Для внесения области, цели и точки зрения в модели IDEF0 в BPwin следует выбрать пункт меню Edit/Model Properties, вызывающий диалог Model Properties (рис. 1.3). В закладке Purpose следует внести цель и точку зрения, а в закладку Definition — определение модели и описание области.

Рис. 1.1. Диалог задания свойств модели В закладке Status того же диалога можно описать статус модели (черновой вариант, рабочий, окончательный и т. д.), время создания и последнего редактирования (отслеживается в дальнейшем автоматически по системной дате). В закладке Source описываются источники информации для построения модели (например, «Опрос экспертов предметной области и анализ документации»). Закладка General служит для внесения имени проекта и модели, имени и инициалов автора и временных рамок модели — AS-IS и ТО-ВЕ.

Модели AS-IS и ТО-ВЕ. Обычно сначала строится модель существующей организации работы — AS-IS (как есть). На основе модели AS-IS достигается консенсус между различными единицами бизнеса по тому, «кто что сделал» и что каждая единица бизнеса добавляет в процесс. Модель AS-IS позволяет выяснить, «что мы делаем сегодня» перед тем, как перепрыгнуть на то, «что мы будем делать завтра». Анализ функциональной модели позволяет понять, где находятся наиболее слабые места, в чем буду г состоять преимущества новых бизнес-процессов и насколько глубоким изменениям подвергнется существующая структура организации бизнеса. Детализация бизнес-процессов позволяет выявить недостатки организации даже там, где функциональность на первый взгляд кажется очевидной. Признаками неэффективной деятельности могут быть бесполезные, неуправляемые и дублирующиеся работы, неэффективный документооборот (нужный документ не оказывается в нужном месте в нужное время), отсутствие обратных связей по управлению (на проведение работы не оказывает влияния ее результат), входу (объекты или информация используются нерационально) и т. д. Найденные в модели AS-IS недостатки можно исправить при создании модели ТО-ВЕ (как будет) — модели новой организации бизнес-процессов. Модель нужна ТО-ВЕ для анализа альтернативных/лучших путей выполнения работы и документирования того, как компания будет делать бизнес в будущем.

Следует указать на распространенную ошибку при создании модели AS-IS — это создание идеализированной модели. Примером может служить создание модели на основе знаний руководителя, а не конкретного исполнителя работ. Руководитель знаком с тем, как предполагается выполнение работы по руководствам и должностным инструкциям и часто не знает, как на самом деле подчиненные выполняют рутинные работы. В результате получается приукрашенная, искаженная модель, которая несет ложную информацию и которую невозможно в дальнейшем использовать для анализа. Такая модель называется SHOULD_BE (как должно бы быть).

Технология проектирования ИС подразумевает сначала создание модели AS-IS, ее анализ и улучшение бизнес-процессов, т. е. создание модели ТО-ВЕ, и только на основе модели ТО-ВЕ строится модель данных, прототип и затем окончательный вариант ИС. Построение системы на основе модели AS-IS приводит к автоматизации предприятия по принципу «все оставить как есть, только чтобы компьютеры стояли», т. е. ИС автоматизирует несовершенные бизнес-процессы и дублирует, а не заменяет существующий документооборот. в результате внедрение и эксплуатация такой системы приводит лишь к дополнительным издержкам на закупку оборудования, создание программного обеспечения и сопровождение того и другого.

Иногда текущая AS-IS и будущая ТО-ВЕ модели различаются очень сильно, так что переход от начального к конечному состоянию становится неочевидным. в этом случае необходима третья модель, описывающая процесс перехода от начального к конечному состояния системы, поскольку такой переход — это тоже бизнес-процесс.

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

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

Модель может содержать четыре типа диаграмм:

* контекстную диаграмму (в каждой модели может быть только одна контекстная диаграмма);

* диаграммы декомпозиции;

* диаграммы дерева узлов;

* диаграммы только для экспозиции (FEO).

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

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

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

2.3 UML

Унифицированный язык моделирования (Unified Modeling Language — UML) — это язык для специфицирования, визуализации, конструирования и документирования на основе объектно-ориентированный подхода разные виды систем: программных, аппаратных, программно-аппаратных, смешанных, явно включающие деятельность людей и т. д.

Помимо прочего, язык UML применяется для проектирования реляционных БД. Для этого используется небольшая часть языка (диаграммы классов), да и то не в полном объеме. С точки зрения проектирования реляционных БД модельные возможности не слишком отличаются от возможностей ER-диаграмм Диаграммой классов в терминологии UML называется диаграмма, на которой показан набор классов (и некоторых других сущностей), не имеющих явного отношения к проектированию БД), а также связей между этими классами. Ограничения могут неформально задаваться на естественном языке или формулироваться на языке объектных ограничений OCL (Object Constraints Language).

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

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

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

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

В диаграмме классов могут участвовать связи трех разных категорий: зависимость (dependency), обобщение (generalization) и ассоциация (association).

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

Рис. 2.4. Диаграмма зависимость Связью-обобщением называется связь между общей сущностью, называемой суперклассом, или родителем, и более специализированной разновидностью этой сущности, называемой подклассом, или потомком. Обобщения иногда называют связями «is a», имея в виду, что класс-потомок является частным случаем класса-предка. класс-потомок наследует все атрибуты и операции класса-предка, но в нем могут быть определены дополнительные атрибуты и операции.

Одиночное наследование, когда у каждого подкласса имеется только один суперкласс) является достаточным в большинстве случаев применения связи-обобщения. Однако в UML допускается и множественное наследование, когда один подкласс определяется на основе нескольких суперклассов.

2.4 DFD

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

DFD содержит процессы, которые преобразуют данные, потоки данных, которые переносят данные, активные объекты, которые производят и потребляют данные, и хранилища данных, которые пассивно хранят данные.

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

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

Активные объекты. Активным называется объект, который обеспечивает движение данных, поставляя или потребляя их. Активные объекты обычно бывают присоединены к входам и выходам DFD.

Рис. 2.6. Активные объекты Хранилища данных. Хранилище данных — это пассивный объект в составе DFD, в котором данные сохраняются для последующего доступа. Хранилище данных допускает доступ к хранимым в нем данным в порядке, отличном от того, в котором они были туда помещены. Агрегатные хранилища данных, как, например, списки и таблицы, обеспечивают доступ к данным в порядке их поступления, либо по ключам.

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

Рис. 2.8. Потоки управления

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

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

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

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

2.5 ER-модель «сущность-связь»

В реальном проектировании структуры базы данных применяются метод — так называемое, семантическое моделирование. Семантическое моделирование представляет собой моделирование структуры данных, опираясь на смысл этих данных. в качестве инструмента семантического моделирования используются различные варианты диаграмм сущность-связь (ER — Entity-Relationship).

Первый вариант модели сущность-связь был предложен в 1976 г. Питером Пин-Шэн Ченом. В дальнейшем многими авторами были разработаны свои варианты подобных моделей (нотация Мартина, нотация IDEF1X, нотация Баркера и др.). кроме того, различные программные средства, реализующие одну и ту же нотацию, могут отличаться своими возможностями. По сути, все варианты диаграмм сущность-связь исходят из одной идеи — рисунок всегда нагляднее текстового описания. все такие диаграммы используют графическое изображение сущностей предметной области, их свойств (атрибутов), и взаимосвязей между сущностями.

Мы опишем работу с ER-диаграммами близко к нотации Баркера, как довольно легкой в понимании основных идей. Данная глава является скорее иллюстрацией методов семантического моделирования, чем полноценным введением в эту область.

Основные понятия ER-диаграмм