Дипломная работа: Разработка системы автоматизации управления фермой СХПК "Алматы"
Одним из основных недостатков больших программных систем является тот факт, что в основу их функционирования уже заложен механизм взаимодействия между составными частями предприятия. Поэтому для успешного внедрения системы обычно оказывается недостаточно настройки системы на конкретных пользователей, а требуются изменения установленного порядка ведения учета. В случае применения, например, системы R/3 может потребоваться даже частичная или полная реорганизация предприятия. Это расширяет поле деятельности консультационных фирм, но является негативным фактором для компании, в которой внедряется система, так как увеличиваются и без того немалые затраты на приобретение ПО.
Очевидно, что основы всех перечисленных недостатков лежат в архитектуре, заложенной при создании систем. Как уже отмечалось, крупные системы управления бизнесом имеют достаточно длинную историю, поэтому в них зачастую используются устаревшие технические решения, мешающие развитию систем и их адаптации к нуждам конкретных пользователей.
Методика построения крупных программных систем в качестве одного из первых шагов предусматривает предварительное определение структуры рассматриваемой области с точки зрения взаимодействия составляющих ее частей. [5]
2.2 Методы проектирования программных систем
Под методом проектирования понимается процесс создания ряда моделей, которые описывают своими средствами различные стороны разрабатываемой системы. В настоящее время существуют различные подходы к этой проблеме, среди которых можно выделить три основные группы: метод структурного проектирования; метод организации потоков данных; объектно-ориентированное проектирование.
В системах управления бизнесом имеет смысл использовать все указанные методы, причем в два этапа. На первом этапе необходимо использование методов объектно-ориентированного проектирования для создания объектов, являющихся отражением реально существующих понятий предметной области и определения базовых механизмов взаимодействия между ними. На втором этапе применяются методы структурного проектирования и организации потоков данных как средств описания взаимодействия между объектами и документооборота на предприятиях. В силу специфики предметной области и, как уже отмечалось, различных требований к подобным системам, второй этап может считаться этапом непосредственного внедрения системы в кооператив.
Поэтому основной задачей при создании подобных систем является задача определения базовых объектов и механизмов взаимодействия между ними.
Наилучшей системой является та, которая наиболее точно и полно описывает производственные циклы, действующие на предприятии, и хранит отношения между субъектами хозяйственной деятельности в естественной для прикладной области форме. Использование объектно-ориентированного проектирования при этом приводит к необходимости выделения объектов, являющихся участниками процессов, происходящих на предприятии.
В связи с произвольностью выбора уровня абстракции имеет смысл учитывать все объекты, которые представляют интерес с точки зрения учета и анализа результатов деятельности. Объекты, используемые в системе управления бизнесом в качестве представителей реальных понятий предметной области должны удовлетворять ряду требований, без выполнения которых процесс настройки системы будет чрезвычайно затруднительным. Рассматриваемые объекты с точки зрения программной архитектуры должны обладать способностью владеть группами других объектов и одновременно быть членами различных групп. Используя различные способы группировки, пользователь системы получает возможность ведения различного вида учета на предприятии.
Определение типа объекта не обязательно в процессе работы системы. Он запрашивается на возможность выполнения какого-либо действия. В случае подтверждения объект-владелец группы имеет право скорректировать полученные результаты. При отказе возможны различные действия вплоть до игнорирования этого объекта при выполнении конкретной операции. В этом случае объект-владелец получает возможность пользоваться свойствами объектов группы и выполнять действия, которые не были заложены в нем на этапе создания. Например, завод может иметь склад хранения готовой продукции и цех по производству автомобилей. Объект-завод приобретает свойства объекта-склада и цеха как производственной единицы. К нему применимы все операции, которые можно выполнять с его составляющими.
Обычно этот принцип используется в множественном наследовании для порождения объектов-наследников, имеющих свойства их предков. Коренное отличие состоит в том, что при традиционном программировании это определяется на этапе создания программы. Объект может выглядеть как объект-предок в определенном контексте, но предок не существует независимо от самого объекта и не может принадлежать одновременно двум другим объектам. В предложенной схеме они существуют независимо друг от друга. Таким образом, необходимо, чтобы для удовлетворения потребностей пользователя все объекты рассматриваемой системы удовлетворяли принципу динамического наследования. Принцип динамического наследования является ключевым фактором, который может обеспечить успех систем такого рода. [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 служат соответственно для определения того, поддерживает ли объект запрашиваемый формат данных, и для получения списка всех поддерживаемых объектом форматов.
Если множества поддерживаемых форматов данных у объектов не пересекаются, то имеется возможность использования объектов-трансляторов. Технически при этом происходит опрос реестра операционной системы в целях поиска объектов, поддерживающих необходимые типы данных, и организуется последовательный процесс вызова методов Get Data и Set Data. Используя этот механизм, объект 1 получает возможность хранить данные в формате объекта 2, т.е. в их первоначальном виде, а обрабатывать в своем собственном формате.
Таким образом, не существует ограничений на вид поступаемой информации при условии, что в системе есть соответствующие трансляторы в способ представления, поддерживаемый другими объектами. Это ключ к решению одной из основных проблем, возникающей при совместном использовании различных систем, - проблеме обмена информацией.
Говоря об обмене данными, нельзя не упомянуть о необходимости поддержки обновления данных в реальном времени средствами самой системы.
Для поддержки обновления данных целесообразно использовать метод D Advise интерфейса I Data Object объекта-сервера в совокупности с интерфейсом l Advise Sink объекта-клиента. В зависимости от необходимости существует возможность установления одного из трех типов связи между объектами: «холодной»;«теплой»;«горячей».
«Холодная» связь. Такие связи могут использоваться для обмена информацией по заранее определенным схемам. Использование только методов Get Data при обмене информацией между объектами может служить примером этого типа связи.
«Теплая» связь. Данный тип связи между объектами может использоваться, если для объекта важен сам факт изменения данных. В этом случае объект-клиент знает, что информация, которой он обладает, устарела и может инициировать процесс обновления через определенный промежуток времени, либо запросив подтверждение у оператора. При установлении «теплой» связи у объекта сервера вызывается метод D Advise и ему передается формат представления данных, в котором клиент хочет получить информацию, способ связи - только уведомление и интерфейс приема данных для того, чтобы можно было организовать обмен данными позднее.
«Горячая» связь. Метод соединения по способу «горячей» связи предполагает уведомление клиента об изменениях информации путем посылки ему обновленной информации. Этот метод необходимо использовать при изменениях курсов валют, биржевых котировок и другой информации, характер изменения которой является критической для бизнеса.
При «горячей» и «теплой» связи существует возможность использования разового уведомления, когда после первой посылки информации связь между объектами разрывается. [3]
2.3 Управление объектами
После определения характера взаимодействия между объектами системы встает вопрос о необходимости описания с их помощью конкретной структуры кооператива. Как отмечалось, такая операция является завершающей и может выполняться на этапе внедрения системы в кооперативе. Очевидно, что данная операция должна выполняться сравнительно легко и позволять гибко модифицировать связи между компонентами системы. В этом случае можно использовать такие средства, предоставляемые OLE, как OLE Automation и автоматные контроллеры. Если до этого момента рассматривался обмен данными между объектами, то с использованием Automation объекты получают возможность управлять действиями друг друга. Обмен информацией происходит через интерфейс IDispatch посредством вызова метода Invoke для активизации действий, выполняемых данным объектом. В системе управления кооперативом имеет смысл определить, например, расдача корма животным, ленточным способом, посредством компьютера, который будет инициатором создания документов для отражения в документообороте движения материальных ценностей. Список поддерживаемых объектом методов возвращается путем вызова метода Get Type lnfo интерфейса I Dispatch аналогично тому, как запрашивается список поддерживаемых форматов через интерфейс I Data Object. Благодаря этому существует возможность добавления на этапе функционирования системы новых объектов, отражающих изменения в реальной жизни и их интеграции в систему. Необходимо заметить, что это не требует изменений в уже существующих объектах.
2.4 Распределенная обработка данных
Перед системой управления кооператива встает задача определения рабочих мест пользователей информации и обмена информацией между ними. Одним из преимуществ технологии OLE является то, что факт запроса объекта с другой машины проходит «прозрачно» для локальных объектов. Это позволяет масштабировать существующее приложение в рамках всего предприятия без изменения характера взаимодействия между объектами.
Таким образом, предлагаемый способ построения моделей сложных систем, в основе которого лежит создание среды функционирования объектов предметной области, может быть использован и в других плохо формализуемых областях деятельности. Управление производственными процессами, имитация работы сложных механизмов, проектирование новых устройств - вот лишь некоторые из многих возможных областей применения. Поддержка свойств динамического наследования является основным требованием при анализе и управлении системой на различных уровнях детализации.
Предлагаемая архитектура позволяет создавать модульные, хорошо масштабируемые системы, которые могут приспосабливаться к изменениям, происходящим в реальной жизни. Процедуры добавления новых объектов, установление новых и модификация существующих связей может выполняться в процессе работы системы. Появляется возможность использования объектов, разработанных другими производителями с применением различных программных инструментов. Гибкая структура взаимодействия между объектами позволяет осуществлять интеграцию с уже существующими системами, что позволяет сохранить значительные инвестиции, сделанные в программное обеспечение.
2.5 Требования к интерфейсу
Графический интерфейс пользователя является средой работы пользователя с его данными, поэтому его разработка является одним из важнейших моментов написания хорошей конкурентоспособной системы. В настоящее время основные элементы интерфейса унифицированы и подчиняются общему стилю работы операционной системы.
Поскольку наша система разрабатывается для работы в графической системе Windows 9x, то имеет смысл рассмотреть коммерческий стандарт на приложения, предложенный Microsoft, который дает право ставить на программный продукт логотип “Designed for Windows 9x/NT”.
Этот логотип требует соблюдения следующих принципов при разработке программ:
Командует пользователь:
- пользователь должен быть инициатором всех операций;
- он всегда должен иметь возможность вмешаться в автоматический процесс;
- следует учесть возможность “персонификации” приложения;
- быстрое реагирование приложения на команды пользователя;
- интерактивность.
Наглядность:
- образное представление операций, действий – “рисунок стоит тысячи слов”;
- манипулирование объектами в среде приложения;
- метафоры” для объектов действий.
Единообразие:
- Единообразие методов работы с операционной системой;
- единообразие внутри приложения;
- единообразие метафор.
Терпимость к пользователю:
- Обратимость или исправимость всех действий.
Обратная связь:
- обратная информация о ходе процесса или режиме работы.
