p align="left">Сразу нужно подчеркнуть, что хотя данные файлы имеют расширение 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

Соответственно полные имена объектов для этого модуля, включенного в 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 рублей.

2. Расходы, связанные с сопровождением системы. Стоимость сопровождения оценивается в 5000 рублей в год.

Данные по расходам эксплуатации ПО представлены в таблице 6.5:

Таблица № 6.5

Вид затрат	Кол. человек	Стоимость	Всего в год
Дополнительная нагрузка на персонал:
- менеджер	3	80 р/ч	11520
- администратор	1	45 р/ч	2160
Сопровождение
- работник группы сопровождения	1	5000 р/г	5000
Итого			18680

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

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

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

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

3. Повышения качества обслуживания клиентов за счет увеличения скорости работы.

4. Повышение уровня маркетинговых мероприятий

5. Общее повышение организации труда в коллективе.

Суммарные затраты для заказчика представлены в таблице 6.6

Таблица 6.6

Затраты	Стоимость
Стоимость ПО (разовая)	36000
Стоимость внедрения (разовая):
обучение персонала	4000
первоначальная настройка	320
Стоимость эксплуатации (в год)
зарплата персоналу	13680
сопровождение	5000
Итого	59000

Будем условно считать, что за счет достижения результатов по всем вышеуказанным направлениям прирост прибыли предприятия оценивается на уровне 5-10 процентов. Ели брать в расчет среднюю прибыль предприятия в 277000 рублей в месяц прирост даст дополнительно 27700 рублей в месяц, а значит около 332400 тысяч в год. Дополнительная прибыль предприятия за счет внедрения системы составит 273400 рублей. Внедренная система уже в первый год эксплуатации окупит себя.

Как было сказано, многое зависит от политики руководства при внедрении данной Системы. Можно рассчитать еще один показатель, который будет точкой безубыточности проекта. Стоимость внедрения составляет 59000 рублей, прибыль предприятия в год составляет 3324000 рублей. Рассчитаем необходимый прирост прибыли для самоокупаемости (таблица 6.7).

Таблица № 6.7

Затраты на внедрение	59000
Прибыль предприятия	3324000
Прирост прибыли	0,0177497

Отсюда видно, что прирост прибыли должен быть на уровне 1.7 процента, чтобы внедрение было безубыточным:

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

Легальность инструментария

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

Лицензионное соглашение

Понятие лицензионного соглашения пришло с Запада. End user license agreement (EULA) - документ как правило существующий в электронной форме, подписание которого является необходимым условием использования программы на ЭВМ. EULA разработанной системы содержит следующие пункты:

· общие положения

· авторские права на программу

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

· защита ответственности разработчика (принцип "как есть")

· защита целостности и тиражирования (копирование, дизассемблирование, декомпилирование и т.п.)

Защита авторских прав

При создании Системы разработчики руководствовались Федеральным Законом РФ от 23 сентября 1992 г. N 3523-I (в ред. Федерального закона от 24.12.2002 N 177-ФЗ) "О правовой охране программ для электронных вычислительных машин и баз данных". Статья 4 Закона содержит описание условий признания авторского права. Согласно статье, "для признания и осуществления авторского права на программу для ЭВМ или базу данных не требуется депонирования, регистрации или соблюдения иных формальностей. Правообладатель для оповещения о своих правах может, начиная с первого выпуска в свет программы для ЭВМ или базы данных, использовать знак охраны авторского права, состоящий из трех элементов:

- буквы С в окружности или в круглых скобках;

- наименования (имени) правообладателя;

- года первого выпуска программы для ЭВМ или базы данных в свет.

Заключение

В результате всей проделанной работы был получен готовый к работе программный комплекс торгово-складской автоматизации, предназначенный для розничных предприятий заказчика - ЗАО "Белгородский бройлер". В процессе разработки и поиска технологий удалось сохранить главную отличительную особенность программы - её простоту для конечного пользователя. Понятный и стильный интерфейс создает приятную и удобную атмосферу работы с программой.

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

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

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

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

1. Федеральный Закон РФ от 23.09.1992 г. № 3523-I (в редакции от 24.12.2002 № 177-ФЗ) О правовой охране программ для электронных вычислительных машин и баз данных.

2. Delphi 7 в подлиннике. А. Хомоненко. СПб: BHV, 2003 - 1216 стр.

3. Delphi. Советы программистов (2-е издание): В.Озеров. - СПб: Символ-Плюс, 2002. - 976 стр.

4. Borland Delphi 6. Руководство разработчика: С.Тейксейра, К.Пачеко. - М: Вильямс, 2002. - 1120 стр.

5. Принципы проектирования и разработки программного обеспечения. Учебный курс MCSD: Скотт Ф. Уилсон, Брюс Мэйплс, Тим Лэндгрейв. - М: Русская редакция, 2002. - 736стр.

6. Проектирование экономических информационных систем: Учебник/Г.Н.Смирнова, А.А.Сорокин, Ю.Ф.Тельнов. - М: Финансы и статистика, 2003. - 512стр.

7. Теория и практика построения баз данных: Д. Крёнке. - Питер, 2003. - 800стр.

8. Самоучитель UML. Эффективный инструмент моделирования информационных систем: А. Леоненков. - СПб: BHV, 2001. - 304стр.

9. Унифицированный процесс разработки программного обеспечения: А. Якобсон, Г. Буч, Дж. Рембо. - СПб.: Питер, 2002. - 496стр.

10. Открытые системы (№ 10). Как добиться успеха в безнадежных проектах.: К.Берлинский. - М:, 2002.

11. Калифорнийский Университет (University of California, Los Angeles, UCLA). WWW: http://www.ucla.edu

12. Borland AML Portal. WWW: http://www.almportal.ru

13. Компания Borland. WWW: http://www.borland.com

14. Компания Harris Interactive. WWW: http://www.harrisinteractive.com

15. Компания IDC. WWW: http://www.idc.com

16. Международная организация по стандартизации объектных технологий OMG. WWW: http://www.omg.com

17. Онлайн газета PC Week. WWW: http://www.pcweek.ru

18. Русскоязычный сайт компании Borland. WWW: http://www.borland.ru

Страницы: 1, 2