Рис 1.3. Режим отладчика [источник: собственная разработка] 

     Систему «1С:Предприятие» относят к разряду  объектных систем. Что это значит?

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

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

Таким образом, объект - это инкапсуляция данных и алгоритмов их обработки. Другими  словами - это формальное описание совокупности понятий, характеризующих элементы данных с одинаковыми свойствами и предназначением, в котором  объединяются как свойства этих данных, так и методы обработки, характерные для типа данных ( Объект в системе «1С:Предприятие7.7»). В контексте баз данных объект - совокупность данных с одинаковыми свойствами и предназначением, имеющих общие структуры хранения и интерактивного представления, и методами их обработки.

Рис 1.4. Объект в системе «1С:Предприятие7.7» 

     От  классических объектных систем «1С:Предприятие» отличается тем, что в ней нельзя создать любой объект с заданными  свойствами. Эта система изначально содержит в себе типовые наборы свойств и методов объектов, называемые видами метаданных. В системе «1С:Предприятие» объекты можно создавать только используя эти типовые наборы. Это те «кирпичики» из которых создаются объекты системы.

     Благодаря такой структуре существенно  уменьшается время разработки базы данных. Экономится время на описание объектов: в «1С:Предприятии» связанный объект с двумя десятками реквизитов можно создать за пять минут. Основное время разработки при этом уделяется описанию алгоритмов управления данными и их обработки средствами системы. Используя реляционную структуру полученной базы, можно создавать всевозможные выборки для генерации отчетов.

     Таким образом, в системе 1С:Предприятие  создаются не любые объекты, а  объекты метаданных. Метаданные - это  «информация о данных», представляющая виды данных, характерные для системы «1С:Предприятие».

     Рис 1.5. Дерево метаданных

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

     Объект  метаданных - это объект определенного  в конфигурации вида метаданных.

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

     Примерами объектов метаданных являются конкретные объекты определенного вида метаданных, создаваемые пользователем в процессе конфигурирования, например, «справочник.должность», а также реквизиты агрегатных объектов метаданных, например, оклад в справочнике должность.

     Архитектура клиент-сервер (client-server) - логическое продолжение концепции модульного программирования. Модуль-клиент (программа), установленный на ПК пользователя, запрашивает сервис (например получение информации из базы данных) у модуля-сервера (программы), расположенного на другом компьютере. В результате деления информационной системы на независимые программы с четко определенными интерфейсами взаимодействия значительно упрощаются сопровождение и поддержка программного обеспечения. [1]

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

     Первоначально системы такого уровня базировались на классической двухуровневой клиент-серверной  архитектуре (рис. 1.1). 

     Рис. 1.6. Двухуровневая клиент-серверная архитектура

     Источник: [2] 

     Данная  клиент-серверная архитектура характеризуется наличием двух взаимодействующих самостоятельных модулей - автоматизированного рабочего места (АРМа) и сервера базы данных, в качестве которого может выступать Microsoft SQL Server, Oracle, Sybase и другие. Сервер БД отвечает за хранение, управление и целостность данных, а также обеспечивает возможность одновременного доступа нескольких пользователей. Клиентская часть представлена так называемым “толстым” клиентом, то есть приложением (АРМ) на котором сконцентрированы основные правила работы системы и расположен пользовательский интерфейс программы. При всей простоте построения такой архитектуры, она обладает множеством недостатков, наиболее существенные из которых - это высокие требования к сетевым ресурсам и пропускной способности сети компании, а также сложность обновления программного обеспечения из-за “размазанной” бизнес-логики между АРМом и сервером БД. Кроме того, при большом количестве АРМов возрастают требования к аппаратному обеспечению сервера БД, а это, как известно, самый дорогостоящий узел в любой информационной системе.

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

Рис. 1.7.Трехуровневая клиент-серверная архитектура

Источник: [2] 

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

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

      Существует еще один важный момент использования систем, построенных  на такой архитектуре. Самый верхний  уровень (АРМы), в целом обладающий огромной вычислительной мощностью, на самом деле простаивает, занимаясь лишь выводом информации на экран пользователя. Так почему бы не использовать этот потенциал в работе всей системы? Рассмотрим следующую архитектуру (рис. 1.3), которая позволяет решить эту задачу. 

Рис. 1.8. Распределенная архитектура системы

Источник: [2] 

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

     Более 95 % данных, используемых в управлении предприятием, могут быть размещены  на одном персональном компьютере, обеспечив возможность его независимой работы. Поток исправлений и дополнений, создаваемый на этом компьютере, ничтожен по сравнению с объемом данных, используемых при этом. Поэтому если хранить непрерывно используемые данные на самих компьютерах, и организовать обмен между ними исправлениями и дополнениями к хранящимся данным, то суммарный передаваемый трафик резко снизиться. Это позволяет понизить требования к каналам связи между компьютерами и чаще использовать асинхронную связь, и благодаря этому создавать надежно функционирующие распределенные информационные системы, использующие для связи отдельных элементов неустойчивую связь типа Интернета, мобильную связь, коммерческие спутниковые каналы. А минимизация трафика между элементами сделает вполне доступной стоимость эксплуатации такой связи. Конечно, реализация такой системы не элементарна, и требует решения ряда проблем, одна из которых своевременная синхронизация данных.

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

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

     Такая архитектура системы также позволяет  организовать распределенные вычисления между клиентскими машинами. Например, расчет какой-либо задачи, требующей больших вычислений, можно распределить между соседними АРМами благодаря тому, что они, как правило, обладают одной информацией в своих БД и, таким образом, добиться максимальной производительности системы.

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

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

1.4  Теория: «Анализ эффективности использования материалов»

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

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