Brownfield-проект

Размещено на http://www.allbest.ru/

РЕФЕРАТ

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

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

Разрабатываемое приложение является так называемым brownfield- проектом (brownfield -«коричневое, т.е. распаханное поле», пер. с англ.). Это значит, что оно разрабатывает не с нуля, и, фактически, является реконструкцией старого проекта. Оно предназначено для улучшения и усовершенствования текущего приложения (выпущенного в 1997 году).

При разработке сервиса была использована технология ASP.NET. Сервис предоставляет полный набор операций для работы с SQL базой данных. Для разработки серверной части приложения был использован MVC Web API + EF5 (EF - Entity Framework пятой версии, компонент Visual Studio, предназначенный для создания и управления сущностями баз данных) для доступа к БД. Клиентская часть веб приложения построена на основе фрэймворка Knockout JS.

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

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

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



ВВЕДЕНИЕ

проектирование тестирование приложение модель

Мы живем в мире, где информационные технологии играют огромную роль, как в нашей повседневной жизни, так и в работе. На данный момент большинство предприятий при ведении отчетности и управления предприятием используют устаревшие формы и методы. Формы создаются в Excel вручную, приказы оформляются на бумаге. При разработке данного дипломного проекта первым встал вопрос: каким образом можно автоматизировать и ускорить рабочий процесс на предприятии?

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

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

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

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

На протяжении всей истории эволюции программных средств принципы и методики построения программных систем совершенствовались. Были сделаны переходы от линейного программирования к структурному, а затем и к объектно-ориентированному подходу. Постоянно совершенствуют методы и подходы к проектированию, растет модульность программных продуктов.

Что касается процесса управления предприятием - на данный момент отчетность о заказах, выполненных работах, состоянии процесса и пр. в своем большинстве хранится на бумаге (хотя существуют системы автоматизации и усовершенствования этого процесса). Каким образом можно усовершенствовать и автоматизировать весь контроль над производственным процессом SRM(SRM - Supplier Relationship Management, управление взаимоотношениями с поставщиком, пер. с англ.) и CRM (CRM - Customer Relationship Management, управление взаимоотношениями с клиентом, пер. с англ.). Данный проект должен помочь решить этот вопрос.

Задачи проекта:

1. На базе классического приложения Plex (разновидность ERP системы, Enterprise Resource Planning System - система управления ресурсами) разработать новое, более совершенное и простое в настройке приложение «Plex Online», которое охватывает всю сферу управления, контроля с возможностью online-мониторинга производственного процесса, розничных продаж, остатков товара и прочим функционалом.

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

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

Целью дипломного проекта является реализация модуля продаж и запросов на одобрение цены (модуль SalesAndCRM, RFQ - Request for Quotation, запрос цены, пер. с англ.). Задачей проекта ставится исправление известных недостатков системы в виде сложного интерфейса администрирования и использования, создание простого, легкого и наглядного интерфейса, а так же предоставить новые средства для управления предприятия.

1. ОБЗОР ЛИТЕРАТУРЫ

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

Новое приложение «Plex Online» реализовано на языке С# по принципу Single Page Application[1] с использованием JavaScript для реализации клиентской части.

В приложении используется открытый фреймворк Knockout.js[2] для двустороннего биндинга модели и отображения.

При первоначальном знакомстве с языком программирования C# полезным изучить базовые конструкции и общие правила языка [3], а также получить представление о принципах объектно-ориентированного программирования.

Далее, для более полного понимания всего, что будет происходить с программным кодом, необходимо углубиться в архитектуру и устройство библиотеки .NET Framework [4,5]. Библиотека .NET Framework состоит из двух частей: общеязыковой исполняющей среды (Common Language Runtime, CLR) и библиотеки классов Framework Class Library (FCL).

Следует отметить следующие достоинства .NET Framework [6]:

Единая программная модель. В отличие от существующего подхода, когда одни функции ОС доступны через процедуры динамически подключаемых библиотек (DLL), а другие - через СОМ-объекты, весь прикладной сервис представлен общей объектно-ориентированной программной моделью.

Упрощенная модель программирования. CLR избавляет от работы с разными структурами, как это было с Win32 и СОМ. Так, разработчику не нужно разбираться с реестром, глобально-уникальными идентификаторами (QUID), Release, HRESUIT и так далее. CLR не просто позволяет разработчику абстрагироваться от этих концепций - их просто нет в CLR в каком бы то ни было виде.

Отсутствие проблем с версиями. Все Windows-разработчики знают о проблемах совместимости версий, известных под названием «ад DLL». Этот «ад» возникает, когда компоненты, устанавливаемые для нового приложения, заменяют компоненты старого приложения, и в итоге последнее начинает вести себя странно или перестает работать. Архитектура .NET Framework позволяет изолировать прикладные компоненты, так что приложение всегда загружает компоненты, с которыми оно строилось и тестировалось. Если приложение работает после начальной установки, оно будет работать всегда.

Упрощенная разработка. Сегодня Windows-приложения очень трудно устанавливать и разворачивать: обычно нужно создать массу файлов, параметров реестра и ярлыков. К тому же полностью удалить приложение практически невозможно. С приходом .NET Framework все эти проблемы остаются в прошлом. Компоненты .NET Framework теперь не связаны с реестром. По сути, установка приложений .NET Framework сводится лишь к копированию файлов в нужные каталоги и установку. Удаление же приложений сводится к удалению файлов.

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

Интеграция языков программирования. СОМ позволяет разным языкам взаимодействовать. .NET Framework позволяет разным языкам интегрироваться, т. е. одному языку использовать типы, созданные на других языках. CLR делает это возможным, так как она определяет и предоставляет общую систему типов (Common Type System, CTS), которую должны использовать все языки, ориентированные на CLR.

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

Автоматическое управление памятью. Одна из самых распространенных ошибок - небрежное отношение к освобождению этих ресурсов, что может привести к некорректному выполнению программы в непредсказуемый момент. CLR автоматически отслеживает использование ресурсов, гарантируя, что не произойдет их утечки. По сути она исключает возможность явного «освобождения» памяти.

Проверка безопасности типов. CLR может проверять безопасность использования типов в коде, что гарантирует корректное обращение к существующим типам. Безопасность типов также означает, что управление может передаваться только в определенные точки (точки входа методов). Невозможно указать произвольный адрес и заставить программу исполняться, начиная с этого адреса. Совокупность всех этих защитных мер избавляет от многих распространенных программных ошибок.

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

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

Взаимодействие с существующим кодом. В Microsoft понимают, что разработчики накопили огромный объем кода и компонентов. Переписывание всего этого кода, так чтобы он задействовал все достоинства .NET Framework значительно замедлило бы переход к этой платформе. Поэтому в .NET Framework реализована полная поддержка доступа к СОМ-компонентам и Win32-функциям в существующих DLL.

Enterprise Resource Planning System - система управления ресурсами компании, причем эксперты в данной области отмечают, что главное слово здесь - «компания»[7].

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

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

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

Внедрение ERP системы - нелегкое дело. Внедрение закрытых ERP систем предполагает изменение внутренних процедур в компании, а также изменения в работе ее сотрудников. В связи со сложностью проекта сроки внедрения систем подобного рода достаточно большие (2-3 года).

Другие же ERP системы (более гибкие) можно с легкостью подстроить под работу сотрудников компании. Их настройка может осуществляться на любой дальнейшей стадии развития компании. И при этом нет необходимости привлекать консультантов фирмы, которая занималась внедрением, настройку сможет выполнить и администратор системы. Внедрение такой ERP системы займет от 6 до 18 месяцев.

Компании выбирают ERP системы, исходя из трех основных соображений.

Объединение финансовых данных

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

Стандартизация производственных процессов

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

Стандартизация информации в системе кадров

ERP система с успехом решает задачи объединения данных о персонале в различных подразделениях - кадровый подбор, перспективы роста, переподготовка и т.п.

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

Фактически ERP системы являются своеобразным компьютерным представлением способов ведения бизнеса различными компаниями.

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

Согласно анализу Panorama Consulting[8] по состоянию на 2010 год поставщики ERP-систем разделены на три группы по мере уменьшения доли присутствия на рынке: SAP (24 %), Oracle (18 %), Microsoft (11 %);

Epicor, Sage, Infor, IFS, QAD, Lawson, Ross -- 11 % навсех;

ABAS, Activant Solutions, Baan, Bowen and Groves, Compiere, Exact, Netsuite, Visibility, Blue Cherry, HansaWorld, Intuitive, Syspro.

Третья группа и плюс не представленные поставщики заняли в общей сложности 36 % рынка. Распределение поставщиков на рынке зависит от масштаба заказчиков, так, в сегменте ERP для организаций с выручкой более $1 млрд у SAP -- 47 %, у Oracle -- 32 %, у Microsoft -- 4 %, тогда как в сегменте организаций с выручкой до $25 млн у SAP -- 22 %, у Oracle -- 23 %, у Microsoft -- 16 %. Plex[9] на данный момент не вошел в эту статистику, однако эта ERP система подает имеет большие шансы на захват существенной части рынка.

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

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

2. СИСТЕМНОЕ ПРОЕКТИРОВАНИЕ

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

Клиентское приложение взаимодействует с сервером, посредством API (Application Programming Interface-интерфейс прикладного программирования, пер. с англ.), разработка которого не входит в рамки дипломного проекта. Разработка сервисов по взаимодействию клиентской части и сервера входит в рамки дипломного проекта. Сервис по взаимодействию с базой данных поставляется вместе с фрэймворком. По условиям задачисервер должен работать под управлением Internet Information Service 7 (IIS7). Клиент должен предоставлять интерфейс, с помощью которого пользователь сможет получать и сохранять информацию, предоставляемую сервисом.

Важным моментом при разработке приложения является то, что система является многокомпонентной. К разным компонентам системы может применяться различные архитектурные подходы. Ниже рассмотрены некоторые из них.

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

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

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

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

Программные комплексы, разработанные в соответствии с Service-Oriented Architecture (SOA) обычно реализуются как набор веб-служб, взаимодействующих по протоколу Simple Object Access Protocol (SOAP). Интерфейсы компонентов в сервис-ориентированной архитектуре инкапсулируют детали реализации (операционную систему, платформу, язык программирования) от остальных компонент, таким образом, обеспечивая комбинирование и многократное использование компонентов для построения сложных распределённых программных комплексов, обеспечивая независимость от используемых платформ и инструментов разработки, способствуя масштабируемости и управляемости создаваемых систем.

Архитектура не привязана к какой-то определённой технологии. Она может быть реализована с использованием широкого спектра технологий, включая веб-сервисы.

REST сервисы. REST (Representational state transfer) - это стиль архитектуры программного обеспечения для распределенных систем, таких как World Wide Web, который, как правило, используется для построения веб-служб. Термин REST был введен в 2000 году Роем Филдингом, одним из авторов HTTP-протокола. Системы, поддерживающие REST, называются RESTful-системами.

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

Управление информацией REST сервиса полностью основывается на протоколе передачи данных. Наиболее распространенный протокол HTTP. Для HTTP действие над данными задается с помощью методов: GET (получить), PUT (добавить, заменить), POST (добавить, изменить, удалить), DELETE (удалить). Таким образом, действия CRUD (Create-Read-Update-Delete) могут выполняться как со всеми 4-мя методами, так и только с помощью GET и POST. Сам принцип использования методов GET и POST часто используется при разработке одностраничных приложений.

Тип разрабатываемого приложения в дипломном проекте представляет собой одностраничное приложение (Single-Page Applications, SPA, пер. с англ.) -- это веб-приложение, которые HTML-страницу один раз методом GET и динамически обновляют данные этой страницы при взаимодействии с пользователем посредством методов GET и POST. В данном контексте метод GET используется только для получения данных или разметки от сервера, метод POST как для получения, так и для отправки данных на сервер.

SPA используют AJAX и HTML5 для создания гибких и адаптивных веб-приложений без постоянных перезагрузок страницы. Однако это означает, что большая часть работы возлагается на клиентскую сторону, а именно на JavaScript-код. Разработчику для традиционной ASP.NET может быть трудно совершить такой кульбит. К счастью, существует множество JavaScript-инфраструктур с открытым исходным кодом, которые облегчают создание SPA при работе с модулями и блоками программы.

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

- пользователь получает возможность просматривать записи группы Price Summary (Итоговая цена, пер. с англ.). Каждый пользователь обладает уникальным идентификатором, который проверяется при загрузке приложения. Если конкретный пользователь пытается просмотреть запись квоты, которая находится на рассмотрении, либо запись, которая принадлежит другому пользователю, она будет открыта в режиме «только просмотр» и закрыта для редактирования;

- в зависимости от настроек приложения заказчиком, пользователь может просматривать и редактировать определенные группы данных (смешанные процессы, внедрение новых материалов, основные процессы, закрепленные процессы);

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

- диалог калькуляции веса и стоимости материалов позволяет рассчитать стоимость определенного материала автоматически;

- при редактировании записей данные итоговой стоимости обновляются при помощи запроса на сервер - таким образом пользователь всегда видит актуальную цифру в таблице итоговой стоимости;

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

Дополнительные возможности программы включают в себя:

- пользователь может просматривать связанные процессы, или похожие процессы, что предоставляет ему возможность сравнивать и оценивать затраты на производство;

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

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

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

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

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

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

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

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

Интерфейс в случае с программой представляет собой то, как выглядит программа на экране и то, как пользователь взаимодействует с логикой программы. Блок интерфейса пользователя отвечает именно за отображение программы на экране и обеспечение визуальных реакций на действия пользователя. Например, при нажатии кнопки на панели действий, на сервер отправляет запрос и выполнится обновление записи в базе данных.

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

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

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

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

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

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

Сервис доступа к базе данных и Блок реализации CRUD логики предоставляются фрэймворком приложения. Оба сервиса работают по принципу «черного ящика» - на вход передаются параметры, на выходе возвращаются данные.

Как уже упоминалось выше проект представляет собой сложный комплекс программных средств взаимодействующих в сети. Средства разноплановые в плане протоколов взаимодействий. Основным компонентом является сайт системы. С учетом последних тенденций развития Сети был выбран подход SPA для клиента сайта. С учетом этой специфики была выбрана смешанная архитектура REST и SOA для серверной части сайта.

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

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

Таким образом общая архитектура системы является симбиозом REST SOA и SPA архитектур. Возможность такого симбиоза определяется слабой связанностью компонентов системы.

Для написания REST части системы доступной по HTTP протоколу была выбрана технология ASP NET MVC Web API

Данная технология позволяет достаточно просто создать гибкий REST сервис для работы с данными. Методы в контроллерах могут разделяться подобно типам HTTP запросов. Логика работы здесь следующая: один контроллер - одна сущность которую он обслуживает. Однако с помощью таблиц роутинга можно задать гораздо более сложные пути для разнообразных запросов. В фреймворке имеется достаточно большой набор фильтров для авторизации и любой другой необходимой обработки запроса перед поступлением на метод контроллера. При необходимости можно делать свои фильтры с любой необходимой логикой. Встроенные парсеры принимают модель в формате JSON или HTML.

Single Page Application архитектура реализуется в приложении при помощи javascript фреймворка Knockout JS.

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

Основные принципы Knockout JS:

хорошо отделять манипуляцию DOM-ом от логики работы приложения. Это существенно улучшает тестируемость кода.

хорошо считать, что автоматизированное тестирование приложения настолько же важно, насколько и написание самого приложения. Тестируемость очень сильно зависит от того, как структурирован код.

хорошо отделять разработку клиентской части от серверной. Это позволяет вести разработку параллельно и улучшает повторное использование на обеих сторонах.

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

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

KnockoutJS представляет собой комплексный фреймворк. При разработке клиентской части данного проекта использовались следующие его возможности:

при создании клиентской части данного приложения были внедрены следующие компоненты: data-binding, базовые директивы для шаблонов, валидация форм, deep linking, повторное использование компонентов, dependency injection, инструменты для взаимодействия с серверными (RESTful) источниками данных.

Шаблон типового приложения, включающего в себя структуру каталогов и тестовые скрипты.

Подведя итоги, в разрабатываемом приложении можно выделить две больших части программы, связанных между собой: часть отображения данных и часть обработки данных, которые взаимодействуют между собой посредством Ajax-запросов. И хотя у них есть общие части, такие, как модель данных, они вполне могут разрабатываться независимо друг от друга. Эта модель объединяет два основных блока: интерфейс пользователя и блок доступа к базе данных. При этом, интерфейс пользователя управляет блоком доступа к базе с помощью сервисов, поставляемых фрэймворком, и классов-помощников. Таким образом, структура программы напоминает классическую трехуровневую модель, в которой имеется три явно выраженных блока. Пользовательский интерфейс представляет собой блок отображения данных. Серверная часть приложения, управляемая пользовательским интерфейсом, представляет собой уровень доступа к базе данных (DAL-уровень, DataAccessLayer, Уровень Доступа к Данным, пер. с англ.). Сюда относятся сервисы, которые поставляются фрэймворком, классы-помощники, и классы действий (Actions).База данных представляет уровень Data, самый нижний уровень в иерархии. Каждый из слоев имеет свой уровень абстракции, согласно которому каждый слой не знает о реализации другого. Все блоки работают по принципу черного ящика, каждому из которых необходимо лишь знать о входных и выходных параметрах.

3. ФУНКЦИОНАЛЬНОЕ ПРОЕКТИРОВАНИЕ

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

1)Actions.

2)Builders.

3)ActionBars.

4) Models.

5) Validation.

6) Controller.

3.1 Классы, реализующие действия (Actions)

К категории классов, непосредственно реализующих действия, относятся классы, которые в первую очередь работают с сервисами доступа к базе данных. Такие классы реализуют логику Create/Read/Update/Delete. Все эти действия вызываются из контроллера приложения, и могут возвращать два типа данных: отображение и данных в формате Json.

3.1.1 Класс Add General Cost Data Action

Представляет собой класс, реализующий добавление новых записей в таблицу General Costs. Является реализацией интерфейса IDataAction.

Поля:

_applicationContext- поле контекста приложения, содержит в себе информацию о текущем пользователе, локализации;

_dataResultFactory- поле фабрики результатов, формирует модель результат валидации для дальнейшей передачи на клиент;

_dataSourceInvoker- поле исполнения процедуры в базе данных. На вход принимает модель запроса, на выходе возвращает результат выполнения процедуры;

_partCostDetailQuoteHelper- поле класса помощника, выполняющего проверку на разрешение редактирования записи, и контейнера констант;

_quoteWizardSettings- контейнер настроек для текущего пользователя;

Методы:

AddGeneralCostDataAction () - конструктор класса;

async Task<IDataResult<PartCostDetailFormModel, PartCostDetailFormModel>> ProcessAsync(PartCostDetailFormModel contextModel) - метод, выполняющий обработку данных и запись этих данных в таблицу. На вход поступает модель, которую необходимо обновить, на выходе получается результат добавления;

3.1.2 Класс AddMiscItemDataAction

Представляет собой класс, реализующий добавление новых записей в таблицу Miscellaneous Costs. Является реализацией интерфейса IDataAction.

Поля:

_applicationContext- поле контекста приложения, содержит в себе информацию о текущем пользователе, локализации;

_dataResultFactory- поле фабрики результатов, формирует модель результат валидации для дальнейшей передачи на клиент;

_dataSourceInvoker- поле исполнения процедуры в базе данных. На вход принимает модель запроса, на выходе возвращает результат выполнения процедуры;

_partCostDetailQuoteHelper- поле класса помощника, выполняющего проверку на разрешение редактирования записи, и контейнера констант;

_quoteWizardSettings- контейнер настроек для текущего пользователя;

_updatePartCostDetailFormDataHelper- помощник для работы с сервисом запросов базы данных.

Методы:

AddMiskItemDataAction () - конструктор класса;

async Task<IDataResult<PartCostDetailFormModel, PartCostDetailFormModel>> ProcessAsync(PartCostDetailFormModel contextModel) - метод, выполняющий обработку данных и запись этих данных в таблицу. На вход поступает модель, которую необходимо обновить, на выходе получается результат добавления;

3.1.3 Класс AddPartComponentDataAction

Представляет собой класс, реализующий добавление новых записей в таблицу Part Component Costs. Является реализацией интерфейса IDataAction.

Поля:

_applicationContext- поле контекста приложения, содержит в себе информацию о текущем пользователе, локализации;

_dataResultFactory- поле фабрики результатов, формирует модель результат валидации для дальнейшей передачи на клиент;

_dataSourceInvoker- поле исполнения процедуры в базе данных. На вход принимает модель запроса, на выходе возвращает результат выполнения процедуры;

_partCostDetailQuoteHelper- поле класса помощника, выполняющего проверку на разрешение редактирования записи, и контейнера констант;

_quoteWizardSettings- контейнер настроек для текущего пользователя;

_updatePartCostDetailFormDataHelper- помощник для работы с сервисом запросов базы данных.

Методы:

AddPartComponentDataAction () - конструктор класса;

async Task<IDataResult<PartCostDetailFormModel, PartCostDetailFormModel>> ProcessAsync(PartCostDetailFormModel contextModel) - метод, выполняющий обработку данных и запись этих данных в таблицу. На вход поступает модель, которую необходимо обновить, на выходе получается результат добавления;

3.1.4 Класс AddProcessRoutingDataAction

Представляет собой класс, реализующий добавление новых записей в таблицу Process Routing Costs. Является реализацией интерфейса IDataAction.

Поля:

_applicationContext- поле контекста приложения, содержит в себе информацию о текущем пользователе, локализации;

_dataResultFactory- поле фабрики результатов, формирует модель результат валидации для дальнейшей передачи на клиент;

_dataSourceInvoker- поле исполнения процедуры в базе данных. На вход принимает модель запроса, на выходе возвращает результат выполнения процедуры;

_partCostDetailQuoteHelper- поле класса помощника, выполняющего проверку на разрешение редактирования записи, и контейнера констант;

_quoteWizardSettings- контейнер настроек для текущего пользователя;

_updatePartCostDetailFormDataHelper- помощник для работы с сервисом запросов базы данных.

Методы:

AddProcessRoutingDataAction () - конструктор класса;

async Task<IDataResult<PartCostDetailFormModel, PartCostDetailFormModel>> ProcessAsync(PartCostDetailFormModel contextModel) - метод, выполняющий обработку данных и запись этих данных в таблицу. На вход поступает модель, которую необходимо обновить, на выходе получается результат добавления;

3.1.5 Класс AddSubComponentDataAction

Представляет собой класс, реализующий добавление новых записей в таблицу Sub Component Costs.При вызове данный класс строит диалоговое окно, в котором содержатся поля, необходимые для добавления новой записи. Является реализацией интерфейса IDataAction.

Поля:

_applicationContext- поле контекста приложения, содержит в себе информацию о текущем пользователе, локализации;

_dataResultFactory- поле фабрики результатов, формирует модель результат валидации для дальнейшей передачи на клиент;

_dataSourceInvoker- поле исполнения процедуры в базе данных. На вход принимает модель запроса, на выходе возвращает результат выполнения процедуры;

_partCostDetailQuoteHelper- поле класса помощника, выполняющего проверку на разрешение редактирования записи, и контейнера констант;

_quoteWizardSettings- контейнер настроек для текущего пользователя;

_updatePartCostDetailFormDataHelper- помощник для работы с сервисом запросов базы данных.

Методы:

AddSubComponentDataAction () - конструктор класса;

async Task<IDataResult<PartCostDetailFormModel, PartCostDetailFormModel>> ProcessAsync(PartCostDetailFormModel contextModel) - метод, выполняющий обработку данных и запись этих данных в таблицу. На вход поступает модель, которую необходимо обновить, на выходе получается результат добавления;

3.1.6 Класс AddSupplyItemDataAction

Представляет собой класс, реализующий добавление новых записей в таблицу Supply Items Costs. При вызове данный класс строит диалоговое окно, в котором содержатся поля, необходимые для добавления новой записи. Является реализацией интерфейса IDataAction.

Поля:

_applicationContext- поле контекста приложения, содержит в себе информацию о текущем пользователе, локализации;

_dataResultFactory- поле фабрики результатов, формирует модель результат валидации для дальнейшей передачи на клиент;

_dataSourceInvoker- поле исполнения процедуры в базе данных. На вход принимает модель запроса, на выходе возвращает результат выполнения процедуры;

_partCostDetailQuoteHelper- поле класса помощника, выполняющего проверку на разрешение редактирования записи, и контейнера констант;

_quoteWizardSettings- контейнер настроек для текущего пользователя;

_updatePartCostDetailFormDataHelper- помощник для работы с сервисом запросов базы данных.

Методы:

AddSupplyItemDataAction () - конструктор класса;

async Task<IDataResult<PartCostDetailFormModel, PartCostDetailFormModel>> ProcessAsync(PartCostDetailFormModel contextModel) - метод, выполняющий обработку данных и запись этих данных в таблицу. На вход поступает модель, которую необходимо обновить, на выходе получается результат добавления;

3.1.7 Класс CalculatePriceSummaryTotalstDataAction

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

Поля:

_applicationContext- поле контекста приложения, содержит в себе информацию о текущем пользователе, локализации;

_dataResultFactory- поле фабрики результатов, формирует модель результат валидации для дальнейшей передачи на клиент;

_dataSourceInvoker- поле исполнения процедуры в базе данных. На вход принимает модель запроса, на выходе возвращает результат выполнения процедуры. Является экземпляром сервиса доступа к базе данных. Данное поле инициализируется на этапе запуска приложения с помощью контейнера;

_partCostDetailQuoteHelper- поле класса помощника, выполняющего проверку на разрешение редактирования записи, и контейнера констант;

_quoteWizardSettings- контейнер настроек для текущего пользователя;

_updatePartCostDetailFormDataHelper- помощник для работы с сервисом запросов базы данных.

Методы:

CalculatePriceSummaryTotalstDataAction () - конструктор класса;

async Task<IDataResult<PartCostDetailFormModel, PartCostDetailFormModel>> ProcessAsync(PartCostDetailFormModel contextModel) - метод, выполняющий обработку данных и запись этих данных в таблицу. На вход поступает модель, которую необходимо обновить, на выходе получается результат добавления;

3.1.8 Класс CalculateProcessCostDataAction

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

Поля:

_applicationContext- поле контекста приложения, содержит в себе информацию о текущем пользователе, локализации;

_dataResultFactory- поле фабрики результатов, формирует модель результат валидации для дальнейшей передачи на клиент;

_dataSourceInvoker- поле исполнения процедуры в базе данных. На вход принимает модель запроса, на выходе возвращает результат выполнения процедуры;

_partCostDetailQuoteHelper- поле класса помощника, выполняющего проверку на разрешение редактирования записи, и контейнера констант;

_quoteWizardSettings- контейнер настроек для текущего пользователя;

_updatePartCostDetailFormDataHelper- помощник для работы с сервисом запросов базы данных.

Методы:

CalculateProcessCostDataAction () - конструктор класса;

async Task<IDataResult<PartCostDetailFormModel, PartCostDetailFormModel>> ProcessAsync(PartCostDetailFormModel contextModel) - метод, выполняющий обработку данных и запись этих данных в таблицу. На вход поступает модель, которую необходимо обновить, на выходе получается результат добавления;

3.1.9 Класс CalculateRawMaterialCostDataAction

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

Поля:

_applicationContext- поле контекста приложения, содержит в себе информацию о текущем пользователе, локализации;

_dataResultFactory- поле фабрики результатов, формирует модель результат валидации для дальнейшей передачи на клиент;

_dataSourceInvoker- поле исполнения процедуры в базе данных. На вход принимает модель запроса, на выходе возвращает результат выполнения процедуры;

_partCostDetailQuoteHelper- поле класса помощника, выполняющего проверку на разрешение редактирования записи, и контейнера констант;

_quoteWizardSettings- контейнер настроек для текущего пользователя;

_updatePartCostDetailFormDataHelper- помощник для работы с сервисом запросов базы данных.

Методы:

CalculateRawMaterialCostDataAction () - конструктор класса;

async Task<IDataResult<PartCostDetailFormModel, PartCostDetailFormModel>> ProcessAsync(PartCostDetailFormModel contextModel) - метод, выполняющий обработку данных и запись этих данных в таблицу. На вход поступает модель, которую необходимо обновить, на выходе получается результат добавления.

3.1.10 Класс CheckProcessRoutingDeleteDataAction

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

Поля:

_applicationContext- поле контекста приложения, содержит в себе информацию о текущем пользователе, локализации;

_dataResultFactory- поле фабрики результатов, формирует модель результат валидации для дальнейшей передачи на клиент;

_dataSourceInvoker- поле исполнения процедуры в базе данных. На вход принимает модель запроса, на выходе возвращает результат выполнения процедуры;

_partCostDetailQuoteHelper- поле класса помощника, выполняющего проверку на разрешение редактирования записи, и контейнера констант;

_quoteWizardSettings- контейнер настроек для текущего пользователя;

_updatePartCostDetailFormDataHelper- помощник для работы с сервисом запросов базы данных.