Разработка и внедрение собственного программного продукта

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

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

     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) – адрес склада

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

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

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