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

Архитектура системы

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

Система будет состоять из нескольких проектов.

Domain (проект 1)

Начнем разработку с создания Domain Layer (доменный слой). Доменный слой содержит все бизнес - сущности системы. Бизнес - сущность (Entity) описывает таблицу БД и представляет собой класс с публичными свойствами - полями таблицы. Помимо описания полей класс содержит бизнес логику, связанную с этой сущностью.

Ниже приведен листинг сущности «Material».

using System;

using CorpseAccount. CommonTypes. Enums;

using CorpseAccount. Infrastructure. Domain;

namespace CorpseAccount. Domain. Entities

{

/// <summary>

/// Информация о материале

/// </summary>

public class Material: Entity

{

/// <summary>

/// УКТ, которой принадлежит файл

/// </summary>

public virtual AccountCorpseCard Card { get; set; }

/// <summary>

/// Категория файла

/// </summary>

public virtual MaterialCategory Category { get; set; }

/// <summary>

/// Бинарный массив, представляющий файл.

/// </summary>

public virtual MaterialData Data { get; set; }

/// <summary>

/// Расширение

/// Пример:. exe

/// </summary>

public virtual string Extension { get; set; }

/// <summary>

/// Имя файла

/// Пример: run. exe

/// </summary>

public virtual string FileName { get; set; }

/// <summary>

/// Определяет, помечен ли файл на удаление

/// </summary>

public virtual bool IsDeleted { get; set; }

/// <summary>

/// MIME-тип файла

/// </summary>

public virtual string MimeType { get; set; }

/// <summary>

/// Дата и время загрузки материала

/// </summary>

public virtual DateTime UploadDateTime { get; set; }

/// <summary>

/// Видимое имя файла

/// Пример: run

/// </summary>

public virtual string VisibleName { get; set; }

}

}

DTO (проект 2)

Data Transfer Object - один из шаблонов проектирования, используется для передачи данных между подсистемами приложения.

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

Ниже приведен листинг DTO «MaterialDto»:

using System;

using System. Runtime. Serialization;

using CorpseAccount. CommonTypes. Enums;

namespace CorpseAccount. Dto

{

/// <summary>

/// Информация о материале

/// </summary>

[Serializable]

[DataContract]

public class MaterialDto: EntityDto

{

/// <summary>

/// Категория файла

/// </summary>

[DataMember]

public virtual MaterialCategory Category { get; set; }

/// <summary>

/// Расширение

/// </summary>

[DataMember]

public virtual string Extension { get; set; }

/// <summary>

/// Имя файла

/// </summary>

[DataMember]

public virtual string FileName { get; set; }

/// <summary>

/// Определяет, помечен ли файл на удаление

/// </summary>

[DataMember]

public virtual bool IsDeleted { get; set; }

/// <summary>

/// MIME-тип файла

/// </summary>

[DataMember]

public virtual string MimeType { get; set; }

/// <summary>

/// Видимое имя файла

/// </summary>

[DataMember]

public virtual string VisibleName { get; set; }

}

}

DAL (проект 3)

Слой доступа к данным (Data Access Layer - DAL) - это слой компьютерной программы, который предоставляет упрощенный доступ к данным, хранимым в постоянном хранилище, таком как реляционная база данных.

Задача этого проекта связать бизнес - сущность с конкретной таблицей в БД с помощью специальных классов - «маппингов».

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

Ниже приведен пример «маппинга» «MaterialMap»:

using CorpseAccount. Dal. Extentions;

using CorpseAccount. Domain. Entities;

using FluentNHibernate. Mapping;

namespace CorpseAccount. Dal. Maps

{

internal class MaterialMap: ClassMap<Material>

{

public MaterialMap ()

{

Table («Materials») ;

Id (p => p. Id). GuidForeignPrimaryKey (nameof (Material. Data)) ;

Map (context => context. VisibleName). Column («VisibleName») ;

Map (context => context. Extension). Column («Extension») ;

Map (context => context. FileName). Column («FileName») ;

Map (context => context. MimeType). Column («MimeType») ;

Map (context => context. IsDeleted). Column («IsDeleted») ;

Map (context => context. Category). Column («Category»). CustomType<int> () ;

References (card => card. Card, «CardId»). Nullable () ;

HasOne (x => x. Data)

. Constrained ()

. ForeignKey () ;

}

}

}

Помимо «маппингов» в проекте находится реализация репозитория, миграции.

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

Класс репозитория реализует методы для манипулирования данными - Get, Update, Create, Delete.

Common (проект 4)

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

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

Пример такого перечисления приведен ниже:

using System;

using System. ComponentModel;

namespace CorpseAccount. CommonTypes. Enums

{

/// <summary>

/// Список типов запросов на выдачу документов

/// </summary>

[Serializable]

public enum ActConclusionType

{

[Description («Акт») ]

Act = 0,

[Description («Заключение») ]

Conclusion = 1

}

}

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

Windows Communication Foundation - программный фреймворк, используемый для обмена данными между приложениями, входящий в состав. NET Framework. До своего выпуска в декабре 2006 года в составе. NET Framework 3. 0, WCF был известен под кодовым именем Indigo.

WCF делает возможным построение безопасных и надёжных транзакционных систем через упрощённую унифицированную программную модель межплатформенного взаимодействия. Комбинируя функциональность существующих технологий. NET по разработке распределённых приложений (ASP. NET XML Web Services - ASMX, WSE 3. 0,. NET Remoting,. NET Enterprise Services и System. Messaging), WCF предоставляет единую инфраструктуру разработки, при умелом применении повышающую производительность и снижающую затраты на создание безопасных, надёжных и транзакционных Web-служб нового поколения. Заложенные в неё принципы интероперабельности позволяют организовать работу с другими платформами, для чего используются технологии взаимодействия платформ, например, WSIT, разрабатываемые на базе открытого исходного кода. [9]

WCF - сервис состоит из интерфейса и его реализации. Пример интерфейса и реализации приведен ниже.

Интерфейс:

using System;

using System. Collections. Generic;

using System. ServiceModel;

using System. Threading. Tasks;

using CorpseAccount. Dto;

namespace CorpseAccount. Application. Common. Services

{

[ServiceContract]

public interface IAdditionalResearchDataService

{

/// <summary>

/// Возвращает список анализов по Id.

/// </summary>

/// <returns></returns>

[OperationContract]

Task<IEnumerable<AdditionalResearchDataDto>> GetAnalysisAsync (Guid id) ;

/// <summary>

/// Возвращает список документов по Id.

/// </summary>

/// <returns></returns>

[OperationContract]

Task<IEnumerable<AdditionalResearchDataDto>> GetDocumentsAsync (Guid id) ;

}

}

Реализация:

using System;

using System. Collections. Generic;

using System. Threading. Tasks;

using CorpseAccount. Application. Common. Extensions;

using CorpseAccount. Application. Common. Services;

using CorpseAccount. Application. FetchStrategy;

using CorpseAccount. Application. Specifications. DirectionStudy;

using CorpseAccount. Application. Specifications. RequestAdditionalDocuments;

using CorpseAccount. Domain. Entities;

using CorpseAccount. Dto;

using CorpseAccount. Infrastructure. Domain;

using CorpseAccount. Infrastructure. Factory;

namespace CorpseAccount. Application. Services

{

public class AdditionalResearchDataService: ServiceBase, IAdditionalResearchDataService

{

private readonly IRepository<DirectionStudy> _directionStudy;

private readonly IUnitOfWorkFactory _factory;

private readonly IRepository<RequestAdditionalDocuments> _requestDocuments;

public AdditionalResearchDataService (IUnitOfWorkFactory factory,

IRepository<DirectionStudy> directionStudy, IRepository<RequestAdditionalDocuments> requestAdditionalDocuments)

{

_factory = factory;

_directionStudy = directionStudy;

_requestDocuments = requestAdditionalDocuments;

}

public async Task<IEnumerable<AdditionalResearchDataDto>> GetAnalysisAsync (Guid id)

{

return await InvokeAsyncWithErrorHandler (() =>

{

using (_factory. Create ())

{

var strategy = new DirectionStudyBasicStrategy () ;

var documents = _directionStudy. FindAll (new HasDirectionStudyByCardId (id), strategy) ;

var map = documents. MapEachTo<AdditionalResearchDataDto> () ;

return map;

}

}) ;

}

public async Task<IEnumerable<AdditionalResearchDataDto>> GetDocumentsAsync (Guid id)

{

return await InvokeAsyncWithErrorHandler (() =>

{

using (_factory. Create ())

{

var strategy = new RequestAdditionalDocumentsBasicStrategy () ;

var documents = _requestDocuments. FindAll (new HasRequestAdditionalDocsByCardId (id), strategy) ;

var map = documents. MapEachTo<AdditionalResearchDataDto> () ;

return map;

}

}) ;

}

}

}

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

Для размещения серверной части потребуется несколько физических серверов. Их список с характеристиками и назначением представлен в таблице 2.

Таблица 2 - Сервера Системы

Архитектура системы представлена на рисунке №1.

Рисунок 1 - Архитектура системы

Проектирование и разработка базы данных

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

Рассмотрим основные таблицы.

Работа в бюро ведется в нескольких танатологических отделениях, соответственно для каждого отделения свои данные.

Создадим таблицу для хранения информации по ТО, структура таблицы приведена в таблице 3.

Таблица 3 - Структура таблицы «Танатологические отделения»

В каждом ТО работают сотрудники заведем для них отдельную таблицу, структура приведена в таблице 4.

Таблица 4 - Структура таблица «Пользователи»

Далее, создадим таблицу, в которой будут содержаться основные данные УКТ, структура описана в таблице 5.

Таблица 5 - Структура таблицы «УКТ»

Помимо основных данных для каждого трупа есть карта судебно-медицинской экспертизы (таблица 6), акты и заключения (таблица 7), вскрытия (таблица 8), обстоятельства (таблица 9), словесные портреты (таблица 10), клинические диагнозы (таблица 11).

Таблица 6 - Структура таблицы «Карты СМЭ»

Таблица 7 - Структура таблицы «Акты»

Продолжение таблицы 7

Таблица 8 - Структура таблицы «Вскрытия»

Продолжение таблицы 8

Таблица 9 - Структура таблицы «Обстоятельства»

Таблица 10 - Структура таблицы «Словесные портреты»

Таблица 11 - Структура таблицы «Клинические диагнозы»

Последняя таблица, которую можно отнести к основным - выдача тел. Структура описана в таблице 12.

Таблица 12 - Структура таблицы «Выдача тел»

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

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

В нашем случае миграция представляет собой класс, содержащий 2 метода - Up и Down.

Пример простой миграции - создание таблицы: метод Up - содержит код, создающий таблицу, а Down - метод, противоположный методу Up - удаляет её.

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

Ещё одна особенность разрабатываемой БД заключается в типе первичного ключа. Обычно первичным ключом служит поле типа integer с автоинкрементом. В нашем случае используется специальный тип GUID.

GUID - уникальный 128-битный идентификатор. Его главная особенность - уникальность, которая позволяет создавать расширяемые сервисы и приложения без опасения конфликтов, вызванных совпадением идентификаторов. Хотя уникальность каждого отдельного GUID не гарантируется, общее количество уникальных ключей настолько велико (2128 или 3, 4028Ч1038), что вероятность того, что в мире будут независимо сгенерированы два совпадающих ключа, крайне мала.

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

{6F9619FF-8B86-D011-B42D-00CF4FC964FF}

Стоит отметить, что PostgreSQL не поддерживает данный тип по - умолчанию. Поэтому, для его работы необходимо расширение «uuid-ossp».

Полная структура базы данных представлена в приложении 1.

Выбор шаблона проектирования

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

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

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

Есть три основных вида шаблонов проектирования:

Структурные

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

Порождающие

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

поведенческие

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

Рассмотрим 3 паттерна - MVC, MVP, MVVM.

MVC

Концепция паттерна (шаблона) MVC (model - view - controller) предполагает разделение приложения на три компонента:

Контроллер (controller) представляет класс, обеспечивающий связь между пользователем и системой, представлением и хранилищем данных. Он получает вводимые пользователем данные и обрабатывает их. И в зависимости от результатов обработки отправляет пользователю определенный вывод, например, в виде представления.

Представление (view) - это собственно визуальная часть или пользовательский интерфейс приложения.

Модель (model) представляет класс, описывающий логику используемых данных.

Рисунок 2 - Структура паттерна MVC

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

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

Назначение паттерна

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

К одной модели можно присоединить несколько видов, не затрагивая при этом реализацию модели.

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

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

MVP

Model - View - Presenter - шаблон проектирования пользовательского интерфейса, производный от MVC, который используется в основном для построения пользовательского интерфейса.

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

Рисунок 3 - Структура паттерна MVP

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

MVVM

Model - View - ViewModel - шаблон проектирования архитектуры приложения. Представлен в 2005 году Джоном Госсманом (John Gossman) как модификация шаблона Presentation Model. Ориентирован на современные платформы разработки, такие как Windows Presentation Foundation, Silverlight.

Рисунок 4 - Структура паттерна MVVM

Шаблон MVVM делится на три части:

Модель (англ. Model) (так же, как в классической MVC) представляет собой логику работы с данными и описание фундаментальных данных, необходимых для работы приложения.

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

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

Резюме

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

MVC имеет больше возможностей по управлению представлением.

Таблица 13 - Сравнительная таблица использования паттернов

В качестве шаблона проектирования выбран MVVM. Решающими факторами стали:

При использовании MVVM снижается объем кода, необходимый для управления представлением

Двухсторонняя коммуникация с представлением

Легкость тестирования приложения

Проектирование и разработка интерфейса

В предыдущем разделе мы выбрали паттерн MVVM для разработки клиентской части. Данный паттерн хорошо сочетается с технологией WPF.

Windows Presentation Foundation (WPF) - это платформа пользовательского интерфейса для создания клиентских приложений для настольных систем. Платформа разработки WPF поддерживает широкий набор компонентов для разработки приложений, включая модель приложения, ресурсы, элементы управления, графику, макет, привязки данных, документы и безопасность. Она является частью платформы. NET Framework, и если ранее вы создавали приложения в. NET Framework с помощью ASP. NET или Windows Forms, то должны быть знакомы с принципами программирования. WPF использует расширяемый язык разметки для приложений (XAML), чтобы предоставить декларативную модель для программирования приложений.

Самое первое, что увидит сотрудник, запустив клиент - форма авторизации. Поэтому начнем именно с неё. Эта форма достаточно предсказуема - на ней находится 2 поля для ввода имени и пароля, выпадающий список с выбором ТО и 2 кнопки - ОК, Отмена. Форма представлена на рисунке 5.

Рисунок 5 - Форма авторизации

Главный экран

После авторизации открывается главный экран (рисунок 6).

Рисунок 6 - Главное экран

Его можно разбить на несколько составляющих:

Верхнее меню

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

Рабочая область

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

Состоит из вкладок, каждая вкладка отображает список УКТ в соответствующем статусе. Список представляет собой таблицу с фильтрами по регистрационному номеру, номеру труппа, ФИО, дате доставки и т. д.

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

Как и в случае с верхним меню, каждая роль видит свой набор вкладок.

Строка состояния

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

Просмотр УКТ

Двойной клик в списке по УКТ открывает её в новом окне (рисунок 7).

Рисунок 7 - Учетная карточка трупа

Здесь отображается вся информация, связанная с трупом. Информация разбита по вкладкам. При открытии УКТ она доступна только для чтения. Сделано это для того, чтобы в одно и тоже время только один сотрудник имел возможность редактирования карты.

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

Рисунок 8 - Проверка полей ввода

Помимо валидации есть такие поля, которые могут быть недоступны для редактирования по какому - то признаку (условию). Это может сэкономить время сотрудника от ввода данных.

Не будем подробно останавливаться на просмотре УКТ, т. к. там всё однотипно и перейдем к настройкам системы.

Настройки безопасности

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

Рисунок 9 - Настройки доступа для ролей

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

Справа располагается матрица прав. Сверху матрицы указаны все роли в системе, слева - возможные варианты прав. Их всего 3:

Полный доступ - сотрудник может просматривать и редактировать элемент формы

Чтение - сотрудник может только просматривать элемент формы

Нет доступа - данный элемент скрыт с формы

Справочники

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

Таблица 14 - Структура таблицы «Справочники»

Форма редактирования справочников представлена на рисунке 10.

Рисунок 10 - Управление справочниками

Окно разбито на 2 части - слева список справочников, справа их значения и форма редактирования. Форма состоит из поля ввода и 5 кнопок:

Очистить - очищает текстовое поле

Добавить - добавляет уникальное значение из текстового поля в БД

Изменить - позволяет изменить выделенное значение

Удалить - помечает выделенное значение как удаленное

Восстановить - восстанавливает удаленное значение

На рисунке 11 показан пример использования значений справочника.

Рисунок 11 - Выпадающий список со значениями из справочника

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

ТРЕБОВАНИЯ К СИСТЕМЕ