Под методом проектирования понимается процесс создания ряда моделей, которые описывают своими средствами различные стороны разрабатываемой системы. В настоящее время существуют различные подходы к этой проблеме, среди которых можно выделить три основные группы: метод структурного проектирования; метод организации потоков данных; объектно-ориентированное проектирование.
В системах управления бизнесом имеет смысл использовать все указанные методы, причем в два этапа. На первом этапе необходимо использование методов объектно-ориентированного проектирования для создания объектов, являющихся отражением реально существующих понятий предметной области и определения базовых механизмов взаимодействия между ними. На втором этапе применяются методы структурного проектирования и организации потоков данных как средств описания взаимодействия между объектами и документооборота на предприятиях. В силу специфики предметной области и, как уже отмечалось, различных требований к подобным системам, второй этап может считаться этапом непосредственного внедрения системы в кооператив.
Поэтому основной задачей при создании подобных систем является задача определения базовых объектов и механизмов взаимодействия между ними.
Наилучшей системой является та, которая наиболее точно и полно описывает производственные циклы, действующие на предприятии, и хранит отношения между субъектами хозяйственной деятельности в естественной для прикладной области форме. Использование объектно-ориентированного проектирования при этом приводит к необходимости выделения объектов, являющихся участниками процессов, происходящих на предприятии.
В связи с произвольностью выбора уровня абстракции имеет смысл учитывать все объекты, которые представляют интерес с точки зрения учета и анализа результатов деятельности. Объекты, используемые в системе управления бизнесом в качестве представителей реальных понятий предметной области должны удовлетворять ряду требований, без выполнения которых процесс настройки системы будет чрезвычайно затруднительным. Рассматриваемые объекты с точки зрения программной архитектуры должны обладать способностью владеть группами других объектов и одновременно быть членами различных групп. Используя различные способы группировки, пользователь системы получает возможность ведения различного вида учета на предприятии.
Определение типа объекта не обязательно в процессе работы системы. Он запрашивается на возможность выполнения какого-либо действия. В случае подтверждения объект-владелец группы имеет право скорректировать полученные результаты. При отказе возможны различные действия вплоть до игнорирования этого объекта при выполнении конкретной операции. В этом случае объект-владелец получает возможность пользоваться свойствами объектов группы и выполнять действия, которые не были заложены в нем на этапе создания. Например, завод может иметь склад хранения готовой продукции и цех по производству автомобилей. Объект-завод приобретает свойства объекта-склада и цеха как производственной единицы. К нему применимы все операции, которые можно выполнять с его составляющими.
Обычно этот принцип используется в множественном наследовании для порождения объектов-наследников, имеющих свойства их предков. Коренное отличие состоит в том, что при традиционном программировании это определяется на этапе создания программы. Объект может выглядеть как объект-предок в определенном контексте, но предок не существует независимо от самого объекта и не может принадлежать одновременно двум другим объектам. В предложенной схеме они существуют независимо друг от друга. Таким образом, необходимо, чтобы для удовлетворения потребностей пользователя все объекты рассматриваемой системы удовлетворяли принципу динамического наследования. Принцип динамического наследования является ключевым фактором, который может обеспечить успех систем такого рода. [3]
В качестве связующего компонента при построении систем предлагается использовать технологию OLE 2 фирмы Microsoft, так как:
- OLE - встроенное средство операционных систем Windows 95 и многоплатформной Windows NT;
- OLE - фактический стандарт отрасли и имеет сильную поддержку со стороны третьих производителей;
- в виде распределенного OLE в сети реализована возможность хранения объектов на различных компьютерах;
- совместимость с OLE является требованием спецификации CORBA.
Хранение информации.
Объектно-ориентированные БД. Одним из наиболее бурно развивающихся направлений в области хранения информации является разработка объектно-ориентированных систем управления базами данных. Они отличаются от реляционных БД тем, что позволяют хранить сложные данные и взаимосвязи между их элементами. Именно это привлекает к ним интерес как к новому способу хранения информации.
Гибридные БД. Они выступают в качестве связующего компонента между объектно-ориентированными и реляционными БД, заполняя возникшее пространство между двумя технологиями. В гибридных схемах используются несколько подходов (от промежуточного слоя ПО до чисто реляционного подхода с трансляцией запросов, поступающих от приложений в язык SQL).
Структурированные хранилища OLE. Технология OLE также предлагает свой подход к хранению информации в виде объектов. В основу положен принцип структурированных хранилищ, представляющих собой файловую систему, построенную поверх основной системы файлов. Она обладает такими преимуществами, как поддержка транзакций и двоичная совместимость между платформами. Автоматически поддерживается восстановление всех файлов, которые были изменены при откате транзакции. В случае практической реализации можно использовать все три подхода, так как операция загрузки и создания объектов должна проводиться прозрачно для функциональной части системы.
В связи с тем, что в системе с предлагаемой архитектурой данные могут храниться в различных форматах даже для объектов одного и того же типа, встает вопрос об отображении и представлении хранимой информации. В данном случае имеет смысл разграничить рассматриваемые объекты на две группы - объекты хозяйственной деятельности как элементы структуры предприятия и документы как инициаторы выполнения определенных действий. Аналогично имеет смысл разделить и способы представления информации - в виде управляющих элементов OLE (OCX) и составных документов. При этом один вид представления не обязательно отрицает использование другого способа.
Перед системой, которая должна охватывать все аспекты деятельности кооператива, ставится задача получения и обработки информации, поступающей из различных источников и имеющей различные форматы представления. Унифицированная передача данных позволяет не только обмениваться информацией между объектами OLE, но и передавать информацию в приложения, не поддерживающие эту технологию, но умеющие работать с буфером обмена данными Clipboard. Такая технология избавляет разработчика от необходимости знания того, как и откуда поступают данные. Основнымиметодамиявляются Query Get Data, Get Data, Set Data и Enum Format Etc. Методы Query Get Data и Enum Format Etc служат соответственно для определения того, поддерживает ли объект запрашиваемый формат данных, и для получения списка всех поддерживаемых объектом форматов.
Если множества поддерживаемых форматов данных у объектов не пересекаются, то имеется возможность использования объектов-трансляторов. Технически при этом происходит опрос реестра операционной системы в целях поиска объектов, поддерживающих необходимые типы данных, и организуется последовательный процесс вызова методов GetData и SetData. Используя этот механизм, объект 1 получает возможность хранить данные в формате объекта 2, т.е. в их первоначальном виде, а обрабатывать в своем собственном формате.
Таким образом, не существует ограничений на вид поступаемой информации при условии, что в системе есть соответствующие трансляторы в способ представления, поддерживаемый другими объектами. Это ключ к решению одной из основных проблем, возникающей при совместном использовании различных систем, - проблеме обмена информацией.
Говоря об обмене данными, нельзя не упомянуть о необходимости поддержки обновления данных в реальном времени средствами самой системы.
Для поддержки обновления данных целесообразно использовать метод D Advise интерфейса I Data Object объекта-сервера в совокупности с интерфейсом l Advise Sink объекта-клиента. В зависимости от необходимости существует возможность установления одного из трех типов связи между объектами: «холодной»;«теплой»;«горячей».
«Холодная» связь. Такие связи могут использоваться для обмена информацией по заранее определенным схемам. Использование только методов Get Data при обмене информацией между объектами может служить примером этого типа связи.
«Теплая» связь. Данный тип связи между объектами может использоваться, если для объекта важен сам факт изменения данных. В этом случае объект-клиент знает, что информация, которой он обладает, устарела и может инициировать процесс обновления через определенный промежуток времени, либо запросив подтверждение у оператора. При установлении «теплой» связи у объекта сервера вызывается метод D Advise и ему передается формат представления данных, в котором клиент хочет получить информацию, способ связи - только уведомление и интерфейс приема данных для того, чтобы можно было организовать обмен данными позднее.
«Горячая» связь. Метод соединения по способу «горячей» связи предполагает уведомление клиента об изменениях информации путем посылки ему обновленной информации. Этот метод необходимо использовать при изменениях курсов валют, биржевых котировок и другой информации, характер изменения которой является критической для бизнеса.