Автоматизированная система складского учета в ЗАО "Белгородский бройлер"

Оглавление

Введение

Глава 1: Выбор методологии разработки

Глава 2: Исследование

Глава 3: Проектирование

3.1 Платформа .NET

3.2. Обзор ASP.NET

3.2 Проектирование базы данных

3.2.1 Логическое проектирование

3.2.2 Физическое проектирование

Глава 4: Разработка

4.1 Borland Delphi 2005

4.2 Архитектура

4.3 HTML прототипы

4.4 Бизнес логика

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

Глава 5: Экономический эффект

5.1 План анализа экономической эффективности

5.2 Технико-экономическое обоснование разработки ПО

5.3 Расчет затрат на разработку ПО

5.4 Стоимость внедрения ПО Заказчиком

5.5 Расходы заказчика при эксплуатации ПО

5.6 Эффективность внедрения для Заказчика ПО

5.7 Правовые аспекты

Заключение

Список использованной литературы

 

Введение

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

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

В данной работе будут показаны преимущества разработки и внедрения собственного программного продукта в дополнение к имеющемуся типовому решению "1С Предприятие: Торговля и склад".

ЗАО "Белгородский бройлер" было основано в 2000 году. Цель деятельности компании – производство и реализация мяса птицы и сопутствующих товаров. В процессе своего роста, компания стала больше внимания уделять сбыту продукции конечному потребителю. Для этого за несколько лет была создана розничная сеть магазинов, специализирующихся на продаже продукции ЗАО "Белгородский бройлер" и сторонних компаний. Ассортимент продукции компании постоянно расширялся, поэтому и управлять товарно-материальными потоками становилось все сложнее и сложнее. Среди прочих проблем все острее вставал вопрос складского учёта – от производства продукции до ее реализации конечному потребителю.

В отделе сбыта и розничных продаж ЗАО "Белгородский бройлер" используется пакет программ "1С Предприятие". Пока количество филиалов (розничных магазинов) ограничивалось двумя и ассортимент продукции состоял из нескольких наименований особых проблем не было. Но с развитием филиальной сети магазинов (сейчас их семь) появились новые требования к ПО складского учета.

Рисунок 1

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

·                    высокий человеческий фактор – так как передача данных производится либо вербально, либо с помощью заполненных вручную документов высока вероятность ошибок;

·                    низкая актуальность данных – обновление данных происходит не чаще 1 раза в день;

·                    двойной ввод данных – первый раз – при продаже\поступлении товара, второй раз – при учете этой же операции в системе "1С: Предприятие";

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

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

Рисунок 2

Новая модель позволит достигнуть основной бизнес цели, сформулированной менеджментом компании:

Снижение затрат на сбор данных о движении товаров в розничных магазинах компании.

Для достижения этой цели необходимо:

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

·                    Увеличить скорость сбора данных о товарообороте;

·                    Создать единую картину товарооборота всех филиалов.

Также для компании немаловажным будет являться побочный эффект от проекта:

·                    Повышение имиджа компании как IT ориентированной.

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

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

По ряду причин для решения поставленных задач заказчику не подошло клиент-серверное решение в формате "1С: Предприятие":

·                    высокая стоимость решения при росте числа магазинов;

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

·                    излишний функционал, приводящий к сложностям в восприятии системы рядовыми пользователями;

·                    отсутствие web-интерфейса.

Было решено, что разработка некоего простого (с точки зрения пользовательского интерфейса) и легкого (с точки зрения системных требований и требований к каналам связи) web-ориентированного приложения с функцией конвертации данных в "1С: Предприятие" будет лучшим решением сложившейся ситуации.

Глава 1: Выбор методологии разработки

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

Существует множество различных методологий. Среди них выделяют тяжеловесные и гибкие методологии. Для тяжеловесных методологий необходимо детальное планирование большого объема разработок, большой объем документации, и такой подход работает - однако до тех пор, пока не начнутся изменения. Следовательно, для этих методологий сопротивляться всяким изменениям совершенно естественно. Гибкие же методологии, напротив, изменения приветствуют. В отличие от тяжеловесных, они были задуманы как процессы, которые адаптируют изменения и только выигрывают от них, даже в том случае, когда изменения происходят в них самих. Наиболее известными и популярными гибкими методологиями в настоящее время является RUP (Rational Unified Process) и XP (eXtreme Programming).

RUP и XP исходят из различных философских основ. RUP - это система процессных компонент, методов и техник, которые вы можете применить в любом конкретном программном проекте. Предполагается, что пользователь будет адаптировать RUP. С другой стороны XP - более ограниченный процесс, требующий дополнений для того, чтобы соответствовать полному циклу разработки проекта. Эта разница объясняет предпочтения в сообществе разработчиков программного обеспечения. Разработчики крупных систем рассматривают RUP в качестве решения своих проблем, в то время как сообщество разработчиков малых систем решение своих проблем видит в XP. XP это упрощенный, ориентированный на кодирование процесс, для небольших проектов. Эта технология основана на итерациях, объединяющих некоторые приемы, такие как небольшие релизы, простое проектирование, тестирование и постоянная интеграция. RUP – это итеративная методология, основанная на шести признанных в отрасли лучших технологиях. Основной целью RUP является сокращение рисков. Методология RUP уточнялась в ходе тысяч проектов, выполненных тысячами клиентов и партнеров компании Rational.

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

Учитывая сложность разрабатываемой системы, а также требования к адаптивности, мы выбрали в качестве методологии разработки RUP. Создатели RUP определяют его как итеративный, архитектурно-ориентированный и управляемый прецедентами использования процесс разработки программного обеспечения [9]. Основа RUP: разработка концепции; управление по плану; снижение рисков и отслеживание их последствий; тщательная проверка экономического обоснования; использование компонентной архитектуры; прототипирование, инкрементное создание и тестирование продукта; регулярные оценки результатов; управление изменениями; создание продукта, пригодного к употреблению; адаптация RUP под нужды своего проекта.

Прежде чем приступать к разработке, необходимо определиться с программными продуктами, которые будут использоваться в ходе построения системы. По мере повышения сложности программных проектов резко возрастают требования к эффективности их реализации. Это тем более важно сегодня, когда разработчики ПО вовлечены практически во все аспекты работы предприятий и число таких специалистов растет. В то же время данные исследований в этой области говорят о том, что результаты как минимум половины "внутренних" проектов разработки программных средств не оправдывают возложенных на них надежд. В этих условиях становится особенно актуальной задача оптимизации всего процесса создания программных средств с охватом всех его участников - проектировщиков, разработчиков, тестеров, служб сопровождения и менеджеров. Управление жизненным циклом приложений (Application Lifecycle Management, ALM) рассматривает процесс выпуска программных средств как постоянно повторяющийся цикл взаимосвязанных этапов:

·                     определение требований (Requirements);

·                     проектирование и анализ (Design & Analysis);

·                     разработка (Development);

·                     тестирование (Testing);

·                     развертывание и сопровождение (Deployment & Operations).

Каждый из этих этапов должен тщательно отслеживаться и контролироваться. Правильно организованная ALM-система позволяет:

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

·                     повысить качество, гарантируя при этом, что приложение будет соответствовать потребностям и ожиданиям пользователей;

·                     повысить производительность труда (разработчики получают возможность делиться передовым опытом разработки и внедрения);

·                     ускорить разработку благодаря интеграции инструментов;

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

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

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

Рис. 1.1 Этапы жизненного цикла ALM Borland

Реализация ALM-стратегии в исполнении Borland заключается в предоставлении комплекса взаимосвязанных инструментов для всех этапов жизненного цикла приложений, таких, как определение требований, анализ и проектирование, разработка, тестирование, развертывание и управление [13]. Этапы жизненного цикла изображены на рисунке 1.1. Данная стратегия компании Borland достаточно гибкая и адаптируются под любую методологию, в том числе и выбранную нами RUP. В рамках данной стратегии компания выпустила ряд продуктов, которые мы собираемся использовать в своей работе, главным преимуществом которых является тесная интеграция друг с другом:

·                   Borland CaliberRM 2005;

·                   Borland Together Designer 2005;

·                   Borland StartTeam 2005;

·                   Borland Delphi 2005.

Rational Unified Process (RUP) - одна из наиболее совершенных технологий, претендующих на роль мирового корпоративного стандарта. RUP в значительной степени соответствует стандартам и нормативным документам, связанным с процессами жизненного цикла ПО и оценкой технологической зрелости организаций-разработчиков (ISO 12207, ISO 9000, CMM и др.). Ее основными принципами являются:

1.                 Итерационный и инкрементный (наращиваемый) подход к созданию ПО.

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

3.                 Построение системы на базе архитектуры ПО.

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

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

На рисунке 1.2 показано общее представление RUP в двух измерениях. Горизонтальное измерение представляет время, отражает динамические аспекты процессов и оперирует такими понятиями, как стадии, итерации и контрольные точки. Вертикальное измерение отражает статические аспекты процессов и оперирует такими понятиями, как виды деятельности (технологические операции), рабочие продукты, исполнители и дисциплины (технологические процессы).

Согласно RUP, жизненный цикл ПО разбивается на отдельные циклы, в каждом из которых создается новое поколение продукта [5]. Каждый цикл, в свою очередь, разбивается на четыре последовательные фазы, каждая из которых преследует свои цели:

·                   Фаза Исследование (inception), предназначена для создания модели предметной области;

·                   Фаза Проработка (elaboration), предназначена для создания базовой архитектуры;

·                   Создание (construction), преследует цель создания продукта путем последовательного выпуска версий с постепенно расширяющимися функциональными возможностями;

·                   Фаза Переходный период (transition), необходима для проверки готовности продукта к эксплуатации;

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

Рис. 1.2 Представление стадий и работ RUP

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

Статический аспект RUP представлен четырьмя основными элементами:

·                   роли;

·                   виды деятельности;

·                   рабочие продукты;

·                   дисциплины.

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

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

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

В рамках RUP определены шесть основных дисциплин:

·                   построение бизнес-моделей;

·                   определение требований;

·                   анализ и проектирование;

·                   реализация;

·                   тестирование;

·                   развертывание.

и три вспомогательных:

·                   управление конфигурацией и изменениями;

·                   управление проектом;

·                   создание инфраструктуры.

RUP основывается на шести лучших практиках (best practices):

·                     Итеративная разработка;

·                     Управление требованиями;

·                     Использование модульных архитектур;

·                     Визуальное моделирование;

·                     Проверка качества;

·                     Отслеживание изменений.

Они не являются непосредственной частью RUP, но их рекомендуется соблюдать при настройке процесса.

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

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

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

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

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

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

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

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

В рамках применения объектно-ориентированного подхода мы собираемся использовать UML. UML представляет собой язык визуального моделирования, который разработан для спецификации, визуализации, проектирования и документирования компонентов программного обеспечения, бизнес-процессов и других систем. Язык UML одновременно является простым и мощным средством моделирования, который может быть эффективно использован для построения концептуальных, логических и графических моделей сложных систем самого различного целевого назначения. Этот язык вобрал в себя наилучшие качества методов программной инженерии, которые с успехом использовались на протяжении последних лет при моделировании больших и сложных систем. Конструктивное использование языка UML основывается на понимании общих принципов моделирования сложных систем и особенностей процесса объектно-ориентированного анализа и проектирования в частности. Выбор средств для построения моделей сложных систем предопределяет те задачи, которые могут быть решены с использованием данных моделей. При этом одним из основных принципов построения моделей сложных систем является принцип абстрагирования, который предписывает включать в модель только те аспекты проектируемой системы, которые имеют непосредственное отношение к выполнению системой своих функций или своего целевого предназначения. При этом все второстепенные детали опускаются, чтобы чрезмерно не усложнять процесс анализа и исследования полученной модели [19].

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

 
Глава 2: Исследование

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

·                    выделяется предметная область действия системы, то есть определяются границы применения приложения и его взаимоотношение с другими системами;

·                    предлагается предварительная архитектура, в частности, уточняются новые, сложные и рискованные элементы приложения;

·                    выявляются основные риски;

Фаза завершается формулировкой целей проекта.

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

Продавец – лицо, работающее на контрольно-кассовом аппарате.

Администратор – лицо, ведущее количественный учет товаров.

Менеджер – управляющий компанией.

Затем были выделены функции каждого пользователя:

Пользователь	Функция	Описание
Продавец	Авторизация	Вход в Систему по своему логину и паролю
	Запрос помощи	Обращение к сетевому администратору в случае технических неполадок
	Расход	Создание и изменение расходной накладной
Администратор	Авторизация	Вход в Систему по своему логину и паролю
	Запрос помощи	Обращение к сетевому администратору в случае технических неполадок
	Приход	Создание и изменение приходной накладной
	Редактирование накладных	Управление уже сохранёнными расходными и приходными накладынми
	Редактирование списка "Поставщики"
	Редактирование списка "Каталог"
	Редактирование списка "Магазины"
Менеджер	Авторизация	Вход в Систему по своему логину и паролю
	Запрос помощи	Обращение к сетевому администратору в случае технических неполадок
	Создание отчета об остатках	Просмотр количественной информации по остаткам на складах
	Создание отчета об оборотах	Просмотр финансовой информации по оборотам компании

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

 
Глава 3: Проектирование

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

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

·                    выявление основных рисков, включая план, стоимость и график управления ими на следующих стадиях;

·                    сбор схем использования, покрывающих минимум 80% функциональных возможностей системы;

На этой фазе основное внимание уделяется этапам анализа и проектирования. На этапе анализа требования к приложению анализируются и формулируются на языке разработчиков. Этап "анализ" - промежуточный между сбором требований и проектированием приложения.

Принципиальное отличие RUP от многих других итеративных подходов состоит в большом внимании к разработке архитектуры системы. Архитектура в RUP включает в себя тип организации системы и используемые типовые решения. Кроме того, архитектура в RUP — это еще и ключевая часть кода (обычно, до 20% общего объема), которая позволяет продемонстрировать соответствие системы основным функциональным и нефункциональным требованиям. Поэтому в RUP часто говорится о понятии "архитектурный каркас" [10]. Ориентация на архитектуру означает, что разработку программного обеспечения начинают с разработки архитектурного каркаса, а затем наращивают дополнительную функциональность, максимально используя отработанные при создании каркаса типовые решения. Это дает возможность использовать RUP для решения таких заведомо сложных задач, как разработка систем с использованием новых технологий (например, языков программирования или платформ), а также снижает трудоемкость разработки, позволяя избегать многократного решения схожих задач.

Основным инструментом разработчика на данном этапе выступает Together Designer 2005. Проектирование ведется на языке UML с использованием минимально необходимого набора диаграмм для упрощения дальнейшего процесса разработки, а именно: диаграмм классов, диаграмм последовательностей, диаграмм компонентов и диаграмм развертывания.

3.1 Платформа .NET

13 февраля 2002 года состоялся официальный старт новой платформы Microsoft .NET — на грандиозной презентации в Сан-Франциско были представлены рабочие версии двух главных ее элементов: операционной среды .NET Framework и инструментального набора Visual Studio .NET. Что нового предлагают эти средства, что они сулят разработчикам и пользователям?

К сожалению, несмотря на обилие публикаций о данных продуктах, многое остается весьма туманным. Самое удивительное, что "дымовую завесу" активно поддерживает и сама Microsoft. Например, в официальном пресс-релизе по поводу выхода новинок написано, что это "краеугольные камни в реализации стратегии Microsoft в отношении XML Web Services". Хотя даже при поверхностном взгляде видно, что .NET Framework и VS.NET никак явно не связаны с этими сервисами.

Не говоря уже о том, что технология XML Web Services базируется на отрытых стандартах и является платформно-независимой. В этой связи представляется полезным внимательнее разобраться с архитектурными решениями, лежащими в основе одного из базовых элементов Microsoft .NET, — операционной среды .NET Framework.

Новая операционная среда

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

Хотелось бы отметить, что термин "платформа" мы обычно применяем в двух разных смыслах. С одной стороны, это "концепция" (идеи, спецификации и т. д.), с другой — набор вполне конкретных объектов (файлов, документации и пр.). Эта двойственность в полной мере относится к .NET Framework.

Рис. 1. Структурная схема .NET Framework

В настоящее время поставляется программный набор .NET Framework SDK 1.0, в который кроме собственно модулей операционной среды входят документация, а также ряд автономных компиляторов — VB, C# (т. е. разработку простых .NET-приложений можно вести и без визуальной среды Visual Studio .NET). Пакет устанавливается поверх Windows NT 4.0, 2000 или XP в подкаталог WINNT\Microsoft.NET\Framework\ v1.0.XXX. Он распространяется бесплатно (его можно загрузить с Web-сайта Microsoft) или в составе VS.NET.

.NET Framework состоит из двух главных компонентов: библиотеки базовых классов и CLR (Common Language Runtime — общая для языков среда исполнения NET-приложений), которые соответственно предназначены для решения следующих задач:

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

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

В этой среде ведется разработка и исполнение программ. Главным инструментом создания приложений является конечно же Visual Studio .NET, в котором каждый из языков программирования взаимодействует с .NET Framework через общий интерфейс. В состав VS.NET входит несколько языков Microsoft, среди которых важнейшая роль отводится C/C++, C# и VB.

В саму среду разработки вошли средства, ранее реализованные в виде пакета Visual InterDev. VS.NET позволяет создавать .NET-приложения различных типов, но все они являются теми или иными модификациями трех базовых вариантов — Console Application, Windows Application и Class Library.

Создание универсальной среды разработки и общих базовых функций предопределило то, что отныне все языки программирования Microsoft поставляются в виде единого пакета (например, отдельного продукта VB.NET уже нет). Кроме того, это сильно упрощает подключение к ней (в виде дополнительных модулей Add-Ins) других языков программирования. В настоящее время о создании таких средств (Cobol, Fortran, Perl и пр.) объявили многие разработчики. Кроме того, некоторые поставщики (в частности, Borland) предлагают собственные интегрированные средства программирования для .NET.

Представители Microsoft, сравнивая .NET с конкурирующей Java 2 Platform, часто подчеркивают, что корпорация вовсе не стремится доминировать в области языков программирования, предоставляя всем разработчикам равные возможности (прозрачный намек на Sun). В какой-то степени это справедливо (хотя "льготные" условия для Microsoft заложены в .NET изначально), но самое важное заключается совсем в другом: все независимые инструменты будут только в среде .NET Framework.

Библиотека базовых классов

.NET Framework Class Library — библиотека базовых функций, на основе которых строятся все .NET-приложения. Принципиальная новизна заключается в том, что если ранее подобный набор создавался для каждого языка программирования, то теперь он — один для всех средств.

Впрочем, говорить о разных наборах функций для различных языков в "до .NET-овские" времена можно с большой долей условности. Та же Microsoft для QuickBasic и QuickC использовала единые внутренние конструкции и библиотеки подпрограмм еще в конце 80-х годов. А компиляторы VB изначально были реализованы с помощью промежуточного кода на Си.

Такая унификация системы разработки автоматически нивелирует функциональные возможности разных языков, поэтому выбор инструмента в значительной степени зависит от пристрастия конкретного программиста к тому или иному синтаксису. Это сегодня особенно хорошо видно на примере VB.NET и C#. Однако тут стоит отметить, что Microsoft осталась верна принципу "разделяй и властвуй" — в ее языках сохранены искусственные различия, предопределяющие необходимость применения различных средств для решения разных задач.

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

Кроме того, базовые функции перестали быть принадлежностью пользовательских приложений и превратились в неотъемлемый компонент операционной системы (ранее принадлежностью ОС были только API-функции).

Например, библиотеки MFC VC++ — это набор статических объектных модулей, которые подключаются к приложению на этапе компоновки исполняемого модуля программы и становятся при этом его составной частью. А .NET Class Library — динамические библиотеки классов, являющиеся компонентом .NET Framework.

Рис. 2. Состав библиотек базовых классов

О достоинствах применения объектных библиотек (LIB) и библиотек классов (DLL) отныне можно говорить лишь с точки зрения академического интереса. Ведь разработчики .NET лишены возможности выбора (за исключением тех, кто пишет на C/C++, которые занимают особое положение в средствах разработки .NET). Очевидно, что привязка прикладной программы к платформе .NET существенно возросла по сравнению с традиционной Windows.

Библиотека классов .NET реализована в виде набора DLL (сейчас их 20), имена которых начинаются с идентификатора System (рис. 2). Кстати, из рисунка хорошо видно, что за поддержку технологии Web Services отвечает лишь одна из DLL.

Сразу нужно подчеркнуть, что хотя данные файлы имеют расширение DLL, — речь идет о новом типе библиотек, отличном от обычных DLL и ActiveX (COM) DLL (непонятно, зачем нужно использовать одно расширение для файлов разных типов — это приводит к путанице).

.NET и COM-объекты

Class Library — лишь базовый набор функций, который можно расширять за счет дополнительных библиотек .NET-объектов, создаваемых независимыми разработчиками. В несколько упрощенной форме различие между системными и дополнительными библиотеками заключается в том, что первые автоматически доступны для приложений (как часть ОС!), а вторые нужно подключать индивидуально.

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

В отличие от плоского идентификатора типа "ИмяПриложения.ИмяКласса" в COM, теперь можно использовать "ИмяПриложения.Имя1.Имя2....ИмяКласса". Если ранее, например в VB 6.0, модуль класса мог содержать только один класс, то теперь (VB.NET) один модуль может включать иерархию классов:

Public Class Class0 ‘объект нулевого уровня

‘код класса

End Class

Namespace Name1 ‘объекты первого уровня

Public Class Class1

End Class

Public Class Class2

End Class

Namespace Name2 ‘объекты второго уровня

Public Class Class2

End Class

End Namespace

End Namespace

Соответственно полные имена объектов для этого модуля, включенного в MyClass.dll, будут выглядеть следующим образом:

MyClass.Class0

MyClass.Name1.Class1

MyClass.Name1.Class2

MyClass.Name1.Name2.Class2

Для использования сокращенных имен объектов допускается импорт пространств имен:

Imports MyClass

Imports MyClass.Name1

Тогда в программе к объектам можно обращаться с такими именами: Class0, Class1, Class2, Name2.Class2. Понятно, что использовать импорт пространств имен нужно очень аккуратно, чтобы не возникло противоречий идентификаторов классов.

В приведенном выше примере мы не можем импортировать MyClass.Name1.Name2, так как возникнет неопределенность для имени Class2 (оно встречается дважды в разных пространствах имен).

Объединение отдельных .NET-компонентов в одно приложение непосредственно связано с новым понятием "сборка" (Assembly). Как известно, с контролем версий в COM дело обстояло, мягко говоря, не самым лучшим образом. Фактически поддержка совместимости версий была полностью возложена на разработчика COM-объектов.

Технология .NET Assembly призвана решить все эти проблемы, известные под названием DLL Hell (ад DLL). В упрощенном виде идея заключается в переносе процедур регистрации объектов из системного Реестра на уровень отдельных приложений.

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

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

Что касается решения проблем DLL Hell, то, помимо жесткого контроля за используемыми версиями, оно включает также простое создание локальных копий внешних компонентов внутри каталога с данным приложением (т. е. сборка будет включать не ссылку на компонент, а сам компонент).

Common Language Runtime

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

Фактически CLR исполняет программы, написанные только на одном стандартном языке Microsoft Intermediate Language (MSIL), который в свою очередь соответствует спецификациям Common Language Specification. Кстати, MSIL — это вполне реальный язык программирования (с использованием синтаксиса в стиле "Си"), на нем можно писать исходные модули и транслировать их с помощью автономного компилятора, который входит в состав .NET Framework SDK*.

* На самом деле точным аналогом Java (с точки зрения его роли для платформы) является именно MSIL — язык платформы .NET нижнего уровня, ".NET-Assembler".

Все же остальные языки, в том числе и C#, — это языки верхнего уровня, платформно-независимые. Можно было бы легко включить MSIL в визуальную среду Visual Studio .NET, но, видимо, Microsoft решила не дразнить гусей, чтобы иметь возможность говорить о "равных правах для всех поставщиков средств программирования".

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

Однако, в отличие от классической схемы интерпретатора, используемой в том числе и в Java, CLR выполняет байт-код путем предварительной компиляции в машинный код отдельных фрагментов программы или приложения целиком (рис. 3).

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

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

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

Программы на языке MSIL создают так называемый "управляемый код" (managed code). Это означает, что CLR не просто преобразует MSIL в машинные инструкции, а выполняет эти действия с учетом внешних установок.

Например, Модуль1 может задать собственный набор прав, предоставляемый вызываемому им Модулю 2, запретив, в частности, любые операции коррекции файлов. То есть в CLR мы видим реализацию идей Интернет-браузеров, которые предоставляют промежуточную среду выполнения программ, но только с более высоким уровнем управляемости правами по сравнению с обычной OC.

Microsoft предлагает три языка программирования в составе Visual Studio .NET для формирования "управляемого кода" (создания .NET-приложений) — VB, C# и специальный вариант С++ With Managed Extensions. Как видно из этого списка, Visual C+ занимает совершенно особую позицию в средствах разработки Microsoft: с его помощью можно писать как традиционные Windows-приложения с "неуправляемым кодом" (unmanaged code), так и .NET-приложения, исполняемые в среде CLR.

Что касается платформной независимости, то вроде бы CLR имеет все предпосылки для этого, ведь нужен лишь JIT-компилятор (как это делается для Java). Но я не разделяю оптимизма некоторых экспертов, считающих возможным появление в ближайшее время подобных средств, например, для Linux. Во-первых, в CLR изначально задействованы базовые службы Windows.

Во-вторых, Microsoft совершенно иначе, чем Java-сообщество, трактует понятие многоплатформности: JIT-компиляторы появятся для разных типов аппаратуры (карманные ПК, сотовые телефоны и пр.), но работать они будут только в среде Windows .NET!

Что впереди

Сегодня .NET Framework — это некая дополнительная операционная среда, устанавливаемая в Windows в качестве автономного программного компонента. Нет сомнений, что она станет неотъемлемой частью будущей версии Windows. Тем не менее еще несколько лет пользователи Windows будут иметь возможность работать как в режиме "Win API + COM", так и .NET. Но потом им придется забыть о "старом, добром Windows" и работать исключительно в режиме "управляемого кода" в среде CLR. Это произойдет гораздо быстрее, чем в период "от DOS к Windows".

3.2. Обзор ASP.NET

Летом 2001го года Microsoft представила новую прогрессивную платформу .NET, а с ней несколько очень привлекательных технологий, в том числе ASP.NET, также называемую ASP+. Данная статья посвящена обзору этой серверной технологии Microsoft. Возможности ASP.NET настолько впечатляют, что ее сложно назвать следующей версией ASP. ASP 3.0 было выпущено не очень давно, но ASP.NET построена на других принципах. В ее основе лежит другая платформа, и основными языками программирования для нее выбраны C# и VB, вместо бывших скриптинг языков. В то же время, новая технология позволяет писать ASP страницы на вашем любимом языке. Мы будем придерживаться C# в примерах. На нашем сайте вы можете найти статьи и учебники, посвященные этому языку программирования.

В ASP.NET заложено все, для того, чтобы сделать весь цикл разработки веб-приложения более быстрым, а поддержку проще. Итак, подробнее.

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

Возможности.

Компилирование кода.

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

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

Библиотеки

Теперь при написании кода вы можете использовать набор компонентов, поставляемых с .NET, а он, надо заметить, не мал. Ну вот, например, использование System.Web.Util. Правда, милый пример? А использование Common Language Runtime библиотеки классов, API которой специфицировано, влечет за собой уменьшение кода, который нужно писать разработчику, ускорение процесса разработки, упрощается установка и перенос приложения.

ADO+

В ASP.NET коде, как и в любом другом коде под .NET, вы можете использовать ADO+. Здесь можно упомянуть, например, возможность сохранения датасета в XML и загрузки его из XML, что упрощает разработку распределенных приложений на основе ASP.NET, в частности полезно при передаче данных между веб-сервисами ASP.NET.

Поддержка средств разработки

Visual Studio.NET предоставляет возможность WYSWYG создания и редактирования, включает в себя средства, упрощающие создание и портирование приложений. Также упрощает отладку скриптов. Но несомненно, никто не отнимет у вас возможность написания кода в любимом редакторе, будь то CodeWright, EditPlus или NotePad.

Языковая независимость

ASP.NET работает в рамках Common Language Runtime, что позволяет писать ваш код на любом языке, для которого написан компилятор, поддерживающий эту технологию. Уже в preview версии была поддержка VB и С#, сейчас работает поддержка JScript.

Возможности расширения решения

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

Обработка ошибок.

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

Объектно-ориентированная разработка.

Использование C# позволяет в полной мере использовать концепции, методы и паттерны объектно-ориентированной разработки.

Повторное использование.

Помимо возможностей объектно-ориентированного программирования, ASP.NET представляет новые технологии, такие как пейджлеты (pagelets), новую концепцию установки (bin) и другие возможности.

Набор серверных ASP.NET компонент.

В комплект ASP.NET оболочки входят серверные компоненты. Это такие компоненты, как валидаторы, листовые компоненты, rich контролы (например, календарь).

Обзор ASP.NET Framework

Как отражение глобальных изменений в технологии, не могла не поменяться и внутренняя структура ASP. Если ASP представляла из себя ISAPI DLL, с набором компонент и несколькими системными файлами, то ASP.NET - часть глобальной платформы .NET. Эта платформа - часть новой стратегии Microsoft и соответствует всем современным стандартам разработки как распределенных систем, так и настольных приложений.

Язык .NET - C# сейчас стандартизуется, как и его среда выполнения, что даст возможность портировать платформу на различные системы.

.NET Framework предоставляет интерфейс приложениям, сама непосредственно взаимодействуя с операционной системой. Выше лежит интерфейс ASP.NET приложений, на котором в свою очередь базируются вебформы (ASP.NET страницы) и веб-сервисы. Интерфейс .NET Framework позволяет стандартизировать обращение к системным вызовам и предоставляет среду для более быстрой и удобной разработки.

В новую платформу встроены такие необходимые возможности, как контроль версий и важная для сетевых решений повышенная безопасность. Среда выполнения кода включает в себя сборщик мусора и набор библиотек, готовых к использованию.Код для .NET Framework компилируется в общий промежуточный язык (Intermediate Language-IL). В случае ASP.NET код компилируется при первом обращении к странице и сохраняется для последующих вызовов. При выполнении оболочка компилирует промежуточный код в бинарный и выполняет его. Кэширование готового бинарного кода позволяет улучшить эффективность.

Intermediate Language позволяет создавать ваши системы на любом удобном для вас языке. И независимо от того, используете вы C#, VB.NET, JScript.NET или Perl.NET, вы получаете код, готовый к выполнению.

.NET Framework предоставляет вам и общий интерфейс обращения к базам данных - ADO+. Он тесно интегрирован с XML, что дает вам дополнительные преимущества при разработке распределенных приложений.

Резюме

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

3.2 Проектирование базы данных 3.2.1 Логическое проектирование

Логическая модель данных описывает понятия предметной области и их взаимосвязи и является прототипом будущей базы данных. Логическая модель разрабатывается в терминах информационных понятий, но без какой-либо ориентации на конкретную СУБД. Наиболее широко используемым средством разработки логических моделей баз данных являются диаграммы "сущность-связь" - Entity-Relationship (ER-диаграммы). Следует заметить, что логическая модель данных, представленная ER-диаграммами, в принципе, может быть преобразована как в реляционную модель данных, так и в иерархическую, сетевую, постреляционную.

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

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

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

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

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

Товар – непосредственно сам перемещаемый объект. Эта сущность обладает следующими атрибутами:

Название (Name) – краткое наименование товара

Описание (Description) – полное наименвоание товара

Единица измерения (Edizm) – единица измерения товара: шука, упаковка, килограмм и т.д.

Цена (Price) – конечная розничная цена. Данная цена обозначается на соответствующем ценнике.

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

Название (Name) – краткое наименование поставщика

Описание (Description) – полное наименование поставщика

ФИО (FIO_contact) – ФИО контактного лица данного поставщика

Телефон (Tel) – номер контактного телефона поставщика

Факс (Fax) - номер контактного факса поставщика

Адрес (Address) – юридический адрес поставщика

Магазин – характеризует конкретный магазин розничной сети. Эта сущность обладает следующими атрибутами:

Название (Name) – официальное юридическое название магазина

Телефон (Tel) – номер контактного телефона магазина

Факс (Fax) – номер контактного факса магазина

Адрес (Address) – юридический адрес магазина

ФИО (FIO_contact) – ФИО контактного лица данного магазина

Склад – место хранения товара. Эта сущность обладает следующими атрибутами:

Название (Name) – общепринятое наименование склада

Телефон (Tel) – номер контактного телефона склада

Адрес (Address) – адрес склада

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

Для описания движения товара необходимо выделать такие сущности, как Приходная накладная и Расходная накладная:

Приходная накладная – документ, создаваемый при каждом движении товара "в" магазин, то есть при его покупке у поставщика. Это внутренний документ, необходимый для проводки факта движения товара. Как правило он составляется на основании расходной накладной поставщика. Эта сущность обладает следующими атрибутами:

Дата (Date) – дата проводки документа.

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

Список соответствующих количеств товаров – каждому товару в соответствие ставится его количество.

Список соответствующих цен товаров – каждому товару в соответствие ставится его цена, то есть цена покупки товара у поставщика.

Поставщик – в данном случае "продавец" товара.

Склад – склад, в который физически поставляется товар.

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

Дата (Date) – дата проводки документа.

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

Список соответствующих количеств товаров – каждому товару в соответствие ставится его количество.

Список соответствующих цен товаров – каждому товару в соответствие ставится его розничная цена, т.е. конечная цена для клиента.

Магазин – магазин, от имени которого поставляются указанные товары. Именно "от имени", а не непосредственно из магазина, так как один и тот же магазин может продавать товары с различных складов. А случай, когда магазин является складом – частный.

Склад – склад, из которого физически поставляется товар.

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

При обработке перечисленных сущностей получаем диаграмму "сущность-связь":

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

3.2.2 Физическое проектирование

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

Итак, нормализуем отношения логической модели данных, установив характер связей в разрабатываемой схеме базе данных:

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

"Приход" – "Поставщик": данная связь носит характер "один ко многим", так как одной приходной накладной может соответствовать только один поставщик, но одному поставщику могут соответствовать несколько приходных накладных.

"Приход" – "Склад": данная связь носит характер "один ко многим", так как одной приходной накладной может соответствовать только один склад, но одному складу могут соответствовать несколько приходных накладных.

"Расход" – "Товар": данная связь носит характер "многие ко многим", так как одной расходной накладной могут соответствовать несколько товаров и, в то же время, одному товару могут соответствовать несколько расходных накладных. Связь "многие ко многим" предполагает физическую реализацию в виде двух связей "один ко многим" (таблица "Расход_ Товар").

"Расход" – "Склад": данная связь носит характер "один ко многим", так как одной расходной накладной может соответствовать только один склад, но одному складу могут соответствовать несколько расходных накладных.

"Расход" – "Магазин": данная связь носит характер "один ко многим", так как одной расходной накладной может соответствовать только один магазин, но одному магазину могут соответствовать несколько расходных накладных.

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

Таким образом, агрегируя все результаты анализа диаграммы сущность-связь получаем следующую физическую схему БД:

Глава 4: Разработка

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

На фазе "Разработка":

·                   расширяется список схем использования, включая уточнение, детализацию и описание всех схем

·                   завершается выполнение первых трех этапов

·                   начинается тестирование (обычно на этой фазе выполняется примерно 15% этапа "Тестирование")

·                   поддерживается целостность приложения – все вносимые изменения не должны выходить за рамки утвержденной архитектуры

·                   ведется управление рисками, выявленными на предыдущих стадиях

Фаза "Разработка" завершается этапом "Готовность к опытной эксплуатации".

  4.1 Borland Delphi 2005

Delphi 2005, как и вся линейка ALM инструментов является новейшим решением Borland в своем сегменте.

Среди главных новшеств этого продукта (ранее данная версия носила кодовое название Diamondback) нужно отметить два: в нем впервые реализована возможность использования двух языков — собственно Delphi (диалект Pascal) и C#, а также возможность создания приложений для Win32 (на Delphi) и .NET (Delphi и C#).

Появление Delphi 2005 сдало важным шагом в эволюционном процессе развития инструментальных средств Borland для архитектуры Win32 и .NET.

Как известно, корпорация Borland еще в 2001 году одной из первых среди независимых поставщиков подключалась к программе Visual Studio .NET Integration Partner и, более того, первой получила лицензию на SDK .NET Framework, объявив о намерении создания собственных средств разработки для новой по тем временам платформы Microsoft .NET.

В 2003 г. Borland представила C#Builder и Delphi 8 — первые два инструмента для создания .NET-приложений, реализованные на базе нового ядра IDE для Windows, поддерживающего несколько различных систем разработки для Win32 и .NET (проект с кодовым названием Gallileo). Теперь на смену им пришел новый пакет Delphi 2005, объединивший оба средства (для .NET) с возможностями Delphi 7 (Win32).

По мнению представителей Borland, нынешний вариант инструмента — это самое значительное обновление Delphi за последние годы, выполненное в полном соответствии со стратегией оптимизации процесса создания программного обеспечения Software Delivery Optimization, разработанной корпорацией.

Среда Delphi 2005 не только поддерживает несколько языков, SDK Win32 и .NET, но и обладает целым рядом принципиально новых усовершенствований. В ее состав входит большое количество принципиально новых функциональных возможностей IDE, призванных упростить выполнение разработчиками своих повседневных задач, повысить производительность их труда и оптимизировать работу с исходными текстами программ.

В числе этих возможностей — прогрессивные средства рефакторинга текстов программ, развитая справочная система, подробные сообщения об ошибках (Help Insights и Error Insights), SyncEdit, History Management и новые расширения языка Delphi.

Особо нужно выделить новую платформу ECO II (Enterprise Core Objects), предназначенную для создания программных средств корпоративного класса для .NET с использованием архитектуры Model Driven Architecture (MDA), что позволяет ускорить разработку и повысить качество сложных приложений, а также улучшить возможности их сопровождения.

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

Кроме того, Delphi 2005 помогает группам разработчиков осуществлять сопровождение и доработку уже выпущенных ими приложений для Windows с использованием новых технологий и возможностей.

Продукт позволяет работать с языками программирования для Windows с применением Win32 и .NET SDK, интегрируется с другими решениями Borland, обеспечивающими управление жизненным циклом приложений, в первую очередь StarTeam и Optimizeit.

Задача интеграции с системой StarTeam — упростить управление ресурсами исходных текстов программ и улучшить взаимодействие между участниками групп разработчиков, а подключение Optimizeit Profiler для .NET может помочь автоматизировать тестирование программных модулей и улучшить качество и эксплуатационные характеристики приложения в целом.

По оценкам экспертов, Delphi 2005 в его нынешнем виде уже догнал по функциональным возможностям создания решений корпоративного уровня Java-инструмент Borland — JBuilder.

Существует три выпуска Delphi 2005:

·                    Architect для разработки приложений на основе моделей;

·                    Enterprise для групп разработчиков, которые создают приложения корпоративного класса, работающие с базами данных;

·                    Professional для отдельных программистов, занятых построением приложений для Web и написанием программ с графическим пользовательским интерфейсом.

Разработчик Системы использовал версию Delphi 2005 Professional. Ее возможностей вполне хватает для реализации всех поставленных задач. Разработчик Системы имеет опыт работы в среде Delphi начиная с версии 5. Переход на 2005ую версию не вызвал практически никаких проблем. Более того, порадовала интеграция с StarTeam 2005. В остальном всё осталось прежним: отличный объектно-ориентированный подход, мощнейшая поддержка библиотек компонентов, прекрасная справочная система.

Следует отдельно отметить, какую неоценимую помощь при создании Системы оказали литературные источники 2, 3, 4, 6.

4.2 Архитектура

Данные, полученные на этапе "Исследование", были проанализированы, в результате чего была составлена предварительная схема архитектуры будущей системы. В системе четко выделились две части: Клиент и Сервер. В данном контексте клиент отвечает за предоставление интерфейса для работы с Системой. Сама же бизнес-логика реализуется на Сервере. Таким образом, наш Клиент является тонким – а именно, веб-браузером. Сервер же делится на SQL Сервер и Сервер приложений. SQL Сервер хранит данные, а Сервер приложений обеспечивает бизнес логику Системы. Таким образом, образуется трехзвенная архитекрура Системы:

Преимущества трехзвенной архитектуры

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

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

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

4.3 HTML прототипы

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

Для данной Системы прототипы разрабатывались в среде интегрированной разработки Delphi 2006. Дело в том, что к моменту реализации Системы вышла новая версия Delphi, немного более удобная предыдущей в отношении проектирования ASP.NET страниц.

На данном рисунке представлен прототип окна входа в систему (авторизации):

На данном рисунке представлен прототип окна просмотра Приходных накладных:

Для конечного пользователя прототипы компилировались в HTML страницы:

4.4 Бизнес логика

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

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

Бизнес логика реализовывалась на языке Delphi в одноименной среде разработки. Для соединения с базой данных использовались компоненты SqlConnection, SqlDataAdapter, DataSet, SqlCommand:

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

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

 
Глава 5: Экономический эффект   5.1 План анализа экономической эффективности

После завершения работ по созданию и успешного завершения бета-тестирования Система готова к внедрению в реальных условиях предприятия. Для дальнейшего развития Системы необходимо рассчитать экономическую эффективность проекта. Для этого необходимо выбрать направление распространения Системы. Заказчиком системы выступало закрытое акционерное общество "Белгородский бройлер". Произведем расчет экономической эффективности проекта с точки зрения заказного проекта. Структура экономической части при создании программного обеспечения по заказу фирмы следующая:

1.                Технико-экономическое обоснование разработки ПО;

2.                Расчет затрат на разработку ПО;

3.                Стоимость внедрения ПО Заказчиком;

4.                Расходы заказчика при эксплуатации ПО;

5.                Эффективность внедрения для Заказчика ПО;

6.                Правовые аспекты.

5.2 Технико-экономическое обоснование разработки ПО.

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

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

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

·                    неприемлемая политика лицензирования аналогов – с ростом количества пользователей растёт стоимость системы. Думая о своей web-системе, заказчик понимал, что при росте пользователей в разумных рамках она не потребует никаких доработок.

·                    слабые каналы связи – в большинстве магазинов доступ в сеть Интернет осуществляется через модемное подключение и заказчик не имел намерений тратить средства на повышение скорости каналов передачи данных.

5.3 Расчет затрат на разработку ПО

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

Затраты на разработку

Поскольку Система разрабатывалась полностью по методологии RUP, было решено отказаться от традиционной системы оценки затрат (ТЗ, эскизный проект, технический проект, рабочий проект, внедрение) в пользу более приемлемой методики. Фазы и содержание работ представлены в таблице 6.1:

Таблица № 6.1

Фаза RUP	Содержание работ	Трудоемкость
		дни	%
1.       Исследование	сбор информации, анализ требований, определение образа проекта в целом	9	10
2.       Проработка	анализ требований и проектирование системы, планирование необходимых действий и ресурсов, спецификация функций и особенностей дизайна;	23	25
3.       Создание	низкоуровневая разработка и кодирование	51	55
4.       Переходный период	создание бета-версии продукта, поставка продукта конкретному пользователю, создание документации	9	10
Итого		92	100

На создание Системы было потрачено 92 рабочих дня или 4 полных месяца.

Оценка затрат включает 3 основных пункта:

·                    фонд оплаты труда

·                    приобретение инструментария

·                    использование Интернет

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

Фонд оплаты труда

В проекте был задействован 2 разработчика. Месячная зарплата установлена в размере 10 тысяч рублей. В их обязанности входили все фазы разработки: от исследования до документации. Затраты на оплату труда составили:

2 * 4мес. * 10000руб. = 80000руб.

Приобретение инструментария

Согласно методологии Borland ALM использовался программный пакет, состоящий из следующих приложений, представленных в таблице 6.2:

Таблица 6.2

Продукт	Стоимость (у.е.)	Стоимость (руб.)
Borland CaliberRM 2005	800(*)	22400
Borland Estimate 2005	500(*)	14000
Borland Together Solo 2005	900(*)	25200
Borland Delphi 2005	1090	30520
Borland StarTeam 2005	1000(*)	28000
Итого	4290	120120

(*) примерная цена, т.к.официально продукт еще не продается

Перечисленные продукты дают возможность создания некоммерческих проектов. Этот фактор использовался при внедрении бета-версии Системы в МЭСИ. В случае же коммерческого внедрения придется потратить на программные средства примерно 120120 рублей.

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

Месячная абонентская плата за использование Интернет составила (таблица 6.3):

Таблица № 6.3

Месяц	Компьютер 1 (руб.)	Компьютер 2 (руб.)
1ый	724	920
2ой	481	512
3ий	598	610
4ый	146	205
Итого	1949	2247

Суммарные затраты обоих разработчиков на Интернет – 4196 рублей.

Агрегация

Теперь объединим единовременные затраты на разработку (таблица 6.4):

Таблица № 6.4

Вид затрат	Затраты (руб.)
Фонд оплаты труда	80000
Приобретение инструментария	120120
Использование Интернет	4196
Итого	204316

Таким образом, в случае коммерческого использования Системы совокупные затраты на разработку составят 204316 рубелей.

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

5.4 Стоимость внедрения ПО Заказчиком

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

1.                Стоимость программного обеспечения специально разработанного для заказчика. В этом случае стоимость равна себестоимости плюс прибыль разработчика (на практике обычно составляет 20-30% от себестоимости), а также налог на добавленную стоимость 20%. Для расчета можно использовать следующую формулу , где - себестоимость ПО,  - прибыль разработчика,  - налог на добавленную стоимость. Стоимость, рассчитанная по такой формуле становиться слишком высока, поэтому было принято решение распространять созданную систем как тиражируемое ПО. После расчетов, сделанных другим разработчиком было определено, что стоимость лицензии на один компьютер будет составлять 2000 рублей. Итого за 18 компьютеров стоимость покупки программного обеспечения будет составлять 36000.

2.                Стоимость инструментальных средств, необходимых для функционирования системы. В их состав обычно входят операционные системы, а также прикладное программное обеспечение. Разработанная нами система работает на операционных системах семейства Windows (начиная с Windows 2000). На предприятия заказчика уже установлены и используются эти операционные системы. Также система не предъявляет требований к дополнительному платному прикладному программному обеспечению. Поэтому при внедрении не предусматривается расходов по данным статьям.

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

4.                Стоимость обучения персонала организации на освоение ПО и обучение персонала работе с программой. Расчет производиться по следующей формуле: , где  - численность персонала на обучение,  - стоимость обучения одного человека в день, - время обучения. Предполагается, что в организации заказчика системой будут пользоваться 4 человека: 3 менеджера и 1 администратор. Время необходимое для обучения предположительно оценивается в два рабочих дня. Стоимость обучения одного человека в день 500 рублей. Итого получается затраты на обучение персонала 4000 рублей.

5.                Стоимость первоначальной настройки Системы. Для этого требуется один рабочий день администратора. Исходя из его однодневного заработка затраты будут оцениваться в 320 рублей.

5.5 Расходы заказчика при эксплуатации ПО

Расходы Заказчика по эксплуатации системы в год определяются исходя из следующего (в данном случае не учитываются амортизационные затраты оборудования, электроэнергия, ремонт оборудования и так далее, так как доля этих затрат, связанных непосредственно с функционированием Системы, достаточно мала):

1.                Расходы, связанные с заработной платой менеджерам и администраторам за дополнительную нагрузку, связанную с эксплуатацией Системы. Будем считать, что менеджер будет тратить на работу 1 час в неделю, администратор – 3 часа в неделю. Заработная плата менеджера в час оценивается 80 рублей, администратора – 45 рублей. После расчетов эксплуатация Системы в год будет обходиться в 13680 рублей.