Главная
страница 1страница 2страница 3страница 4

ГЛАВА 2: АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ


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



  • отправка заявки со стороны заказчика

  • ответное коммерческое предложение со стороны продавца.

  • переговоры по комплектации оборудования

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

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

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

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

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

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

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

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

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

ГЛАВА 3: АРХИТЕКТУРА СИСТЕМЫ



3.1 Выбор типа приложения

Автоматизированные системы давно и прочно обосновались во многих сферах деятельности человека, сделав хранение и обработку данных различного объёма более простыми и удобными. Развитие сети Internet позволило со временем сделать доступ к программному комплексу удалённым посредством реализации концепции «клиент-сервер», в которой централизованным хранением и обработкой данных по запросу клиента занимается серверное приложение.

Для разрабатываемой системы оптимальным вариантом будет реализация в виде web-приложения. Это позволит собрать весь функционал в рамках одной программы, обеспечить удалённый доступ, как для операторов, так и для заказчиков, а также сведёт системные требования для клиента к наличию браузера и подключения к интернету.

В рамках единой программы реализуется весь функционал приложения. Примером такой организации системы может служить Microsoft Exchange Server, обеспечивающий обработку и пересылку сообщений электронной почты, работу с календарем и многое другое. В качестве клиентского приложения используется, например, Microsoft Outlook или Outlook Express, которые представляют собой программы, установленные на компьютер пользователя, а также Outlook Web Access, представляющий из себя веб-клиент, практически аналогичный по функциональности Microsoft Outlook.

Этот пример позволяет увидеть основные различия между web-клиентом и приложением, которое устанавливается на компьютер пользователя.

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

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

Если же приложение имеет более специфические функции (например, система электронного документооборота, в которую заложена зачастую достаточно сложная логика управления движением документов по бизнес-процессу, или разрабатываемая система управления заказами, предусматривающая возможность конструирования наборов данных, соответствующих определённому объекту), целесообразно использовать более гибкие инструменты (например, каркасы приложения (framefork) Django или Ruby on Rails).

Необходимые действия по установке обычно сводятся к обеспечению удалённого доступа посредством настройки сети или сетевых модулей (если работа с приложением возможно только из локальной сети предприятия) и создания учётной записи для работы с системой. Такой принцип подходит для систем различного вида, таких как системы электронного документооборота, управления проектами (Redmine, серверное веб-приложение), контроля версий (Git, в частности gerrit и gitweb).

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

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

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

Для реализации данного приложения будет использоваться каркас приложения (framework) Ruby on Rails, созданный с помощью объектно-ориентированного языка Ruby

3.2 Архитектура.

В современной индустрии информационных технологий, связанных с разработкой веб-приложений часто используются «каркасы» (frameworks), которые задают общую архитектуру приложения. Например, Ruby on Rails, используемы для данного проекта, реализует архитектурный образец «модель-представление-контроллер» (model-view-controller, MVC).

«Концепция MVC позволяет разделить данные, представление и обработку действий пользователя на три отдельных компонента:



  1. Модель (англ. Model). Модель предоставляет знания: данные и методы работы с этими данными, реагирует на запросы, изменяя своё состояние. Не содержит информации, как эти знания можно визуализировать.

  2. Представление, вид (англ. View). Отвечает за отображение информации (визуализацию). Часто в качестве представления выступает форма (окно) с графическими элементами.

  3. Контроллер (англ. Controller). Обеспечивает связь между пользователем и системой: контролирует ввод данных пользователем и использует модель и представление для реализации необходимой реакции» [1]



Рис.1 Схема взаимодействия компонентов в рамках архитектуры MVC

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

Как было упомянуто выше, модель данных никак не участвует непосредственно в отображении информации, она лишь формирует необходимый объём данных по запросу контроллера.

Для вызова нужного контроллера в Rails используется специальный механизм маршрутизации, с помощью которого на основе запрашиваемого браузером URI (Uniform Resource Identifier, последовательность символов, идентифицирующая абстрактный или физический ресурс [1]) и http - метода запроса определяется, какое действие должно быть совершено. На основании этого выбирается нужный контроллер, обеспечивающий выполнение требуемого действия.

Для иллюстрации примера работы приложения, предположим, что заказчик собирается просмотреть описание оборудования, выбрав его из списка.

В упрощённом виде последовательность операций, которые совершает приложение, можно описать так:



  1. От браузера поступает запрос на страницу, соответствующую определённой единице оборудовния. В нашем примере это будет /machinery/42.

  2. В контроллере machinery программа находит действие show (показать).

  3. С помощью действия show происходит обращение к модели machinery c целью получить информацию о сущности machinery c идентификатором 42.

  4. Модель machinery выполняет соответствующий запрос к базе данных.

  5. Модель возвращает контроллеру machinery полученную из запроса информацию.

  6. В некой переменной контроллер передаёт представлению machinery полученные данные.

  7. Представление генерирует визуализацию страницы с полученным от контроллера набором данных в HTML.

  8. Контроллер возвращает браузеру сгенерированный представлением HTML-код страницы

Такая реализация приложения позволяет разделить процесс разработки – модели представления могут создаваться более-менее независимо. Для представления не важна внутренняя бизнес-логика модели, оно поучит от контроллера информацию в том виде, в котором она потребуется.

Из приведённого примера может сложиться мнение, что модель – это просто интерфейс для взаимодействия приложения с базой данных. На самом деле в моделях реализуется основная бизнес-логика приложения («совокупность правил, принципов, зависимостей поведения объектов предметной области»[1]), а как раз контроллеры являются интерфейсами для передачи данных и запросов между различными компонентами приложения. Компоненты-представлений не занимаются обработкой данных, только выводом в нужной для пользователя форме.



<< предыдущая страница   следующая страница >>
Смотрите также:
Пояснительная записка к дипломной работе на тему
417.05kb.
4 стр.
Пример оформления задания по дипломной работе
29.14kb.
1 стр.
Пояснительная записка к дипломному проекту на тему: Тема дипломного проекта
14.05kb.
1 стр.
Пояснительная записка к дипломному проекту на тему: Тема дипломного проекта
14.42kb.
1 стр.
Требования по оформлению
150.55kb.
1 стр.
Пояснительная записка к Отчёту о работе архивного отдела администрации муниципального образования Куйтунский район за 2012 год
136.32kb.
1 стр.
Пояснительная записка к годовому отчету ОАО кб «Торжокуниверсалбанк»
867.03kb.
6 стр.
Пояснительная записка к курсовой работе по дисциплине: «Электроника и микросхемотехника» 030502. 06 005. Пз
166.66kb.
1 стр.
Предварительное распределение научных руководителей по преддипломной практике и дипломной работе Группа 711 з
225.78kb.
1 стр.
Пояснительная записка к конкурсной работе «Мультимедийный урок»
16.8kb.
1 стр.
Положение о дипломной работе студента факультета психологии и социальной работы по специальности педагогика и психология
254.18kb.
1 стр.
Пояснительная записка к отчету о работе Управления Федеральной антимонопольной службы по Пермскому краю
1025.85kb.
4 стр.