Кафедра МОЭВМ ПОЯСНИТЕЛЬНАЯ ЗАПИСКА к междисциплинарному проекту Разработка и реализация распределенной программной системы на базе инфраструктуры WCF Выполнил Худяков П.С. Факультет КТИ Группа № 5305 Дата Руководитель _____________ Кринкин К.В. Санкт-Петербург, 2016 Содержание Введение ........................................................................................................................................ 3 1 Проектирование приложения "Планировщик личного времени" ...................................... 5 1.1 Варианты использования планировщика личного времени ....................................... 6 1.2 Архитектура системы ..................................................................................................... 7 1.3 Размещение компонентов системы на вычислительных узлах .................................. 8 1.4 Сервис "Планировщик" .................................................................................................. 9 1.4.1 Интерфейс сервиса "Планировщик"...................................................................... 10 2 Реализация приложения "Планировщик личного времени" ............................................ 12 2.1 Пользовательский интерфейс приложения ................................................................ 12 2.1.1 Основное окно приложения ................................................................................... 12 2.1.2 Окно добавления задачи ......................................................................................... 13 2.1.3 Окно настроек связи с Google Calendar................................................................. 13 2.2 Сценарий использования .............................................................................................. 14 Заключение .................................................................................................................................. 15 2 Введение В рамках данного проекта планируется реализовать распределенное приложение на безе сервис-ориентированной архитектуры (SOA). В качестве предметной области выбрана задача учета личного времени. В ходе работы планируется реализовать приложения "Планировщик личного времени" основываясь на принципах сервисной архитектуры с использованием технологической платформы Microsoft.NET, в частности инфраструктуры обмена данными Windows Communication Foundation (WCF). Сервис-ориентированная архитектура (англ. SOA, service-oriented architecture) — модульный подход к разработке программного обеспечения, основанный на использовании сервисов (служб) со стандартизированными интерфейсами. В основе SOA лежат принципы многократного использования функциональных элементов ИТ, ликвидации дублирования функциональности в ПО, унификации типовых операционных процессов, обеспечения перевода операционной модели компании на централизованные процессы и функциональную организацию на основе промышленной платформы интеграции. Компоненты программы могут быть распределены по разным узлам сети, и предлагаются как независимые, слабо связанные, заменяемые сервисы-приложения. Программные комплексы, разработанные в соответствии с SOA, часто реализуются как набор веб-сервисов, интегрированных при помощи известных стандартных протоколов (SOAP, WSDL, и т. п.) Интерфейс компонентов SОА-программы предоставляет инкапсуляцию деталей реализации конкретного компонента (ОС, платформы, языка программирования, вендора, и т. п.) от остальных компонентов. Таким образом, SOA предоставляет гибкий и элегантный способ комбинирования и многократного использования компонентов для построения сложных распределённых программных комплексов. SOA хорошо зарекомендовала себя для построения крупных корпоративных программных приложений. Целый ряд разработчиков и интеграторов предлагают инструменты и решения на основе SOA (например, платформы JBoss SOA Platform, IBM WebSphere,Software AG webMethods, Oracle/BEA Aqualogic, Microsoft Windows Communication Foundation, SAP NetWeaver, TIBCO, Diasoft). Принципы SOA 1. Архитектура, как таковая, не привязана к какой-то определённой технологии. 3 2. Независимость организации системы от используемой вычислительной платформы (платформ). 3. Независимость организации системы от применяемых языков программирования. 4. Использование сервисов, независимых от конкретных приложений, с единообразными интерфейсами доступа к ним. 5. Организация сервисов как слабо-связанных компонентов для построения систем. 4 1 Проектирование приложения "Планировщик личного времени" Процесс проектирования планировщика личного времени в рамках данного проекта начинается с выявления прецедентов, вариантов использования. Варианты использования предназначены в первую очередь для определения функциональных требований к системе и управляют всем процессом разработки. Все основные виды деятельности такие как анализ, проектирование, тестирование выполняются на основе вариантов использования. После выявления прецедентов создается системная архитектура. В рамках данного проекта применяется подключен сервис-ориентированная к общей сервисной архитектура, шине, которая где каждый обеспечивает из компонентов среду для (сервисов) эффективного взаимодействия. Архитектура задает общее разбиение системы на компоненты, после того как это разбиение становится очевидным следует приступить к проектированию каждого из компонентов в отдельности и во взаимосвязи с другими компонентами. Обозначаются интерфейсы сервисов и более точно определяется их функциональность. 5 1.1 Варианты использования планировщика личного времени На рисунке (Рис. 1.1) показаны варианты использования планировщика личного времени. CRUD Tasks Move Task to The Daily Routine Make The Daily Routine Remove Task form The Daily Routine User View The Daily Routine Get The Day Totals Receive Alert By E-mail Receive Alert Set Task Status Receive Alert By SMS Autenticate Backup&Restore Database Register Change Account Params LogIn The System Create User Account Manage User Accounts Manage Database and System Configuration Admin Request To Change User Password Manage Web-Server Configuration Рис. 1.1 Варианты использования планировщика личного времени Существуют две роли (Actors): 6 Пользователь (User) – это роль, предполагающее использование функций, реализующих логику предметной области Администратор (Admin) – это роль, предполагающая обслуживание и администрирование системы Для пользователя определены следующие сценарии использования: Работать с задачами(CRUD Tasks) Задать расписания дня (Make The Daily Routine) путем помещения задач на расписание дня и удаления задач с расписания дня Просмотреть расписания дня (View The Daily Routine) Получить оповещения (Receive Alerts) по E-mail и/или SMS Подвести итог дня, отметив прогресс и статус выполнения задач Войти/Зарегистрироваться/Изменить параметры учетной записи Для администратора определены следующие сценарии использования: Управление учетными записями: создать новую учетную запись пользователя, запросить изменение пароля для пользователя Скопировать/Восстановить БД, изменить конфигурацию веб-сервера 1.2 Архитектура системы На рисунке (Рис. 1.2) показана схема архитектуры системы. Показанная архитектура является сервис-ориентированной, каждый из компонентов (сервисов) взаимодействует остальными через сервисную шину. Основным для планировщика личного времени является сервис "Планировщик", которые реализует логику предметной области. Сервис "Планировщик" взаимодействует с сервисом оповещений, хранилищем данных и службой аутентификации и авторизации пользователей (через классы ASP.NET). Клиентское Silverlight приложение (Client Application) предоставляет пользователю графический интерфейс к сервису "Планировщик". Сервис аутентификации и авторизации предоставляет клиентскому приложению функции регистрации пользователей и функции входа в систему, а сервису "Планировщик" информацию о пользователе в рамках запроса. 7 Client Application Service BUS (SOAP via HTTP) ASP.NET Classes Planner Notification Service (Google Calendar) ADO.NET Authentication and Authorization Storage (Microsoft SQL Server) Рис. 1.2 Схема архитектуры системы 1.3 Размещение компонентов системы на вычислительных узлах На рисунке (Рис. 1.3) показана схема развертывания системы. 8 Рис. 1.3 Схема развертывания системы 1.4 Сервис "Планировщик" Сервис "Планировщик" реализует логику приложения, обращаясь к сервису оповещения (Notification Service) и хранилищу данных. Клиентское приложение (Client Application) 9 обращается к сервису "Планировщик" предоставляя пользователю графический интерфейс к логике, реализуемой сервисом "Планировщик". 1.4.1 Интерфейс сервиса "Планировщик" В таблице (Табл. 1.1) показаны методы, доступные в интерфейсе сервиса "Планировщик". Таблица 1.1 Интерфейс сервиса "Планировщик" Работа с задачами List<Task> GetTasks() получение всех задач Task GetTask(int ID) получение задачи по ID int CountTasks() подсчет всех задач List<Task> getRootTasks() получение задач самого верхнего уровня List<Task> получение getChildTasks(int taskID) всех подзадач задачи с идентификатором taskID bool isLeaf(int taskID) получение информации о том является ли задача с идентификатором taskID листовой void InsertTask(Task taskToInsert) вставка задачи void UpdateTask(taskToUpdate) обновление задачи void DeleteTask(int ID) удаление задачи по ID со всеми её связями void DeleteAllTasks() удаление всех задач Работа с расписанием на день void taskID, setTaskTiming(int Изменить DateTime? временные рамки задачи с since, идентификатором taskID DateTime? till) Работа с оповещениями void taskID) makeTaskCritical(int Назначить задаче высокий приоритет. Пользователь получает оповещения о задачах с высоким приоритетом Если задано время начала и окончания, то за 10% времени до истечения сроков. Если задано только время окончания, 10 то за сутки до наступления даты окончания Если задано только время начала, то через сутки после наступления даты начала. Если не задано ни время начала ни время окончания, то каждые сутки после добавления задачи. Работа с заметками List<Note> GetNotes() получение всех заметок Note GetNote(int ID) получение заметки по ID int CountNotes() подсчет всех заметок void InsertNote(Note noteToInsert) вставка новой заметки void UpdateNote(Note noteToUpdate) обновление заметки void DeleteNote(int noteID) удаление заметки по ID со связями void DeleteAllNotes() удалить все заметки 11 2 Реализация приложения "Планировщик личного времени" 2.1 Пользовательский интерфейс приложения 2.1.1 Основное окно приложения Рис.2.1 Основное окно приложения SweetPlanner. Цифрами помечено, 1 – переход к списку задач более высокого уровня, 2 – создание новой задачи, 3 – удаление выбранной задачи, 4 – настройки сервиса Google Calendar, 5 – список задач текущего уровня (может представлять список подзадач, либо корневых задач), 6 – расписание на ближайшие дни, на котором отображаются ближайшие задачи, 7 – информация о состоянии приложения, может содержать информацию о возникающих ошибках. Окно, представленное на рис. 2.1, является основной рабочей областью, с которой взаимодействует пользователь. 12 2.1.2 Окно добавления задачи Рис.2.1 Окно добавления новой задачи. Каждое из полей ввода соответствует колонке БД. 2.1.3 Окно настроек связи с Google Calendar Рис.2.2 Окно настроек сервиса Google Calendar. Поле ввода напротив надписи Каледарь содержит список всех календарей, которыми обладает пользователь. При этом есть возможность автоматически создать календарь в случае его отсутствия. 13 Сценарий использования 2.2 Типичный сценарий использования интерфейса может быть следующим: 1. Настройка сервиса Google Calendar, для этого требуется нажать кнопку 4 и ввести данные в форму на рис.2.2 2. Добавление задачи нажатием на кнопку 1 (рис.4), и заполнением полей в окне, представленном на рис.2.1 3. Просмотр области 6 (список наиболее актуальных задач) 4. Навигация по задачам в области 5. Удаление задач с помощью кнопки 3. Замечания по интерфейсу: в текущем состоянии приложения, не доделаны некоторые запланированные возможности, а именно: Изменение параметров задачи. Для реализации, необходимо: a. Добавить соответствующие элементы управления b. Удалить события из сервиса Google Calendar c. Удалить строки из базы данных задачи Реализация не потребует изменения существующей спецификации приложения. 1. 2. Представление существующих задач в виде древовидного элемента управления. Такое представление значительно упростило бы восприятие информации пользователем, однако требует некоторых дополнительных преобразований структур данных. Реализация не потребует изменения существующей спецификации приложения. 3. Возможность просмотра событий с помощью области 6, на какую либо неделю кроме текущей. Реализация потребует написания дополнительной логики клиентского приложения, и не изменит существующую спецификацию. Возможность фильтрации задач по некоторому критерию. Возможность поиска задач по ключевым словам. 14 Заключение Создано работоспособное приложение, удовлетворяющее поставленной задаче. Однако значительная часть желаемой функциональности на данный момент не реализована. Тем не менее, эта её реализация не повлечет изменение существующей спецификации приложения. В ходе разработки приложения, активно использовалась система контроля версий subversion. Были выявлены недостатки локального хранения базы данных – некоторые из файлов, отвечающие за связь базы данных со SweetPlanner, должны быть одинаковы для всех разработчиков, что не стыкуется с локальным хранением базы данных. Локальная база данных может иметь индивидуальные для каждого разработчика атрибуты. 15 Список литературы 1. Кристиан Нейгел, С# 2005 и платформа .NET 3.0 для профессионалов, "Диалектика", 2008 2. Глеб Архангельский, Тайм-драйв. Как успевать жить и работать, Манн, Иванов и Фербер, 2007 г. 3. Джувел Леве,Создание служб WCF, Питер, 2008 г. 4. j. Ambrose Little, Jason Beres, Silverlight 3 Programmer's Reference, Wiley Publishing, Inc, 2009 16