Содержание курса

• ВВЕДЕНИЕ

• Введение в процесс формирования требований

• Инфраструктура (ландшафт) для организации проектной деятельности

• Управление целями заинтересованных лиц

• Формализация потребностей заказчика

• Выявление функции системы. 1.Теория систем

• Выявление функции системы. 2. Моделирование сервисов

• Инжиниринг бизнес-процессов заказчика. 1. Применение UML Activity

• Инжиниринг бизнес-процессов заказчика. 2. Применение BPMN. Предварительный расчет ресурсоемкости проекта.

• Разработка логической структуры данных. 1. Применение UML Class diagram. Приемы и подходы проектирования

• Разработка логической структуры данных. 2. Паттерны проектирования применительно к структуре данных.

• Моделирование поведения целевой системы. Моделирование процессов управления

• Формирование спецификаций требований на создание целевой ИС

• Управление изменениями требований и организация эффективного взаимодействия в команде производства ИТ продукта

• Организация процессов проектирования в производстве ИТ-продукта

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

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

Таким образом мы расширяем наш Домен решений, добавляя в него – модель данных.

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

Это можно сделать огрублено, приблизительно, упрощенно:

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

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

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

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

Итак, какие абстракции явлений мы можем выделить, для удобства их формализации?

• Материя\Вещество - всё вещественное, «телесное», имеющее массу, протяжённость, локализацию в пространстве, проявляющее корпускулярные свойства

• Энергия - единая мера различных форм движения и взаимодействия материи, отражение изменчивости материи, переходов из одного вида в другой

• Информация - сведения, воспринимаемые человеком или специальными устройствами как отражение фактов материального мира в процессе коммуникации

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

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

• Пространство - мера протяженности материи (события), распределения её (его) в окружающей среде

• Время - мера обратимости (необратимости) материи, событий. Время неразрывно связано с изменениями действительности

Особый и нетривиальный вопрос — классификация не по одному, а по нескольким признакам одновременно.

Для более глубокого понимания темы начнем с теории.

1.    Теория информации

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

Главная цель теории информации:

• Описать и объяснить процессы передачи, хранения и обработки информации с помощью математических моделей.

• Найти способы оптимизации этих процессов для уменьшения потерь и повышения эффективности.

Ключевые задачи теории информации:

• Оценка количества информации — как измерить объём передаваемой информации.

• Кодирование информации — как преобразовать информацию, чтобы она занимала меньше места и передавалась быстрее.

• Передача информации — как передавать информацию с минимальными потерями через шумные каналы.

• Сохранение информации — как сохранять информацию в удобной и надёжной форме.

• Обнаружение и исправление ошибок — как находить и устранять ошибки при передаче информации.

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

Характерные черты сущности:

• Отражает суть реального бизнес-процесса.

• Хранит данные (атрибуты: имя, цена, статус и т.д.).

• Содержит бизнес-логику (методы: оплатить(), отправить(), изменить статус()).

• Может быть связана с другими бизнес-объектами (например, Заказ связан с Клиентом).

Более сложная конструкция используемая для работы с данными - это Бизнес-объект. Под Бизнес-объектом (Business Object) понимают модель реальных вещей или процессов компании в информационной системе, который представляет важный объект бизнес-логики приложения. В сложных системах применяют модель «Живой и богатый бизнес-объект» (Rich Domain Model), то есть такой объект, который:

• Сам управляет своим состоянием (а не просто переносит данные).

• Содержит бизнес-логику, связанную со своим поведением.

• Защищает свои инварианты (не дает перейти в неправильное состояние).

• Работает самодостаточно: чтобы изменить его, нужно обращаться к нему самому через его методы.

Более обширный обзор работы с информацией мы будем проводить в курсе ИТ Архитектура, рассматривая слой - Архитектуры данных.

2.    Инструменты моделирования структуры данных

При проектировании структуры сущностей продукта, удобно использовать канонические диаграммы «Сущность-связь» (ERD), а также логическую диаграмму или диаграмму классов.

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

    Объект— сущность, обладающая уникальностью и инкапсулирующая в себе состояние и поведение.

    Класс— описание множества объектов с общими атрибутами, определяющими состояние, и операциями, определяющими поведение.

На диаграмме Класс обозначается как прямоугольник, содержащий 3 секции:

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

• секция атрибутов — содержит список описаний атрибутов класса;

• секция операций — содержит список описаний операций класса.

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

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

Например, на диаграмме мы видим интерфейс «Состояние книги», который по запросу о состоянии конкретного экземпляра книги, возвращает его текущий статус (в наличие, на руках, забронирован и т.п.)

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

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

Рассмотрим основные их типы.

1)  Ассоциация (association) - семантическое отношение между двумя и более классами, которое специфицирует характер связи между соответствующими экземплярами этих классов.

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

В качестве простого примера ненаправленной бинарной ассоциации можно рассмотреть отношение между двумя классами - классом Автор и классом Книга. Они связаны между собой бинарной ассоциацией- «Написал», имя которой указано на рисунке рядом с линией ассоциации. Для данного отношения определен следующий порядок чтения следования классов – Книгу Написал Автор.

Частный случай отношения ассоциации – Исключающая ассоциация.

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

2)  Зависимость (dependency) - указывает на то, что изменение независимой сущности каким-то образом влияет на зависимую сущность.

3)  Обобщение (generalization) — это отношение между двумя сущностями, одна из которых является частным (специализированным) случаем другой. Другими словами, отношение между более общим понятием и менее общим понятием

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

4)  Агрегация (aggregation) - специальная форма ассоциации, которая служит для представления отношения типа "часть-целое" между агрегатом (целое) и его составной частью.

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

Отличие. Агрегации от Обобщения заключается в том, что части системы (классы) никак не обязаны наследовать ее свойства и поведение, поскольку являются самостоятельными сущностями

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

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

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

Еще один важный элемент на диаграммах сущность-связь - Кратность.

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

Кратность         Множество может иметь

•       0..*             Произвольное число элементов

•       1..*              Один или более элементов

•       0..1              Не более одного элемента (Опциональная связь)

Связь 1 : 1 имеет место, когда одному экземпляру одной сущности соответствует один экземпляр другой сущности. Такая связь может быть установлена между сущностями ЭКЗЕМПЛЯР_КНИГИ и УЧЕТНАЯ_КАРТОЧКА: каждый Экземпляр книги имеет Формуляр, и каждая Формуляр заведена на один Экземпляр книги.

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

Связь 1 : М имеет место, когда одному экземпляру одной сущности может соответствовать несколько экземпляров другой сущности. Например, Автор может написать несколько Книг; у одного Читателя может быть несколько Книг.

Связь М : М имеет место, когда нескольким экземплярам одной сущности соответствует несколько экземпляров другой сущности. Например, многие Читатели имеют на руках много разных Книг; один Читатель может взять несколько Книг, и, в то же время, одну Книгу могли читать несколько Читателей.

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

3.    Нормализация данных.

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

Цели нормализации:

• Уменьшение избыточности: Снижение количества дублирующихся данных. Это позволяет экономить дисковое пространство и уменьшает затраты на хранение данных.

• Повышение целостности данных: Обеспечение точности и согласованности данных. Это важно для принятия правильных решений на основе актуальной информации.

• Улучшение производительности: Оптимизация запросов к базе данных. Нормализованные таблицы позволяют быстрее выполнять запросы и уменьшить время отклика системы.

• Упрощение структуры базы данных: Легкость в понимании и управлении данными. Это облегчает работу разработчиков и администраторов баз данных, снижая вероятность ошибок.

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

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

• Избыточность данных: Уменьшение дублирования данных для экономии места и повышения эффективности. Избыточность данных может привести к увеличению объема хранимой информации и усложнению процессов её обработки.

• Целостность данных: Обеспечение точности и согласованности данных в базе. Целостность данных гарантирует, что все данные в базе являются актуальными и непротиворечивыми.

• Аномалии данных: Избежание проблем при изменении данных, таких как аномалии вставки, обновления и удаления. Аномалии могут привести к некорректным данным и нарушению целостности базы данных.

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

Первая нормальная форма (1NF)

Таблица находится в первой нормальной форме, если:

• Все столбцы содержат атомарные значения (неразделимые). Это означает, что каждый столбец должен содержать только одно значение.

• Все записи уникальны. Это исключает дублирование строк в таблице.

Вторая нормальная форма (2NF)

Таблица находится во второй нормальной форме, если:

• Она находится в 1NF. Это означает, что таблица уже удовлетворяет требованиям первой нормальной формы.

• Все неключевые столбцы зависят от всего первичного ключа. Это исключает частичные зависимости.

Третья нормальная форма (3NF)

Таблица находится в третьей нормальной форме, если:

• Она находится в 2NF. Это означает, что таблица уже удовлетворяет требованиям второй нормальной формы.

• Все неключевые столбцы зависят только от первичного ключа. Это исключает транзитивные зависимости.

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

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

4.    Использование приема Декомпозиция при проектировании структуры данных

В продолжение темы Нормализации данных рассмотрим прием Декомпозиция.

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

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

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

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

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

При этом важно соблюдать 9_ое правило Кодда: Логическая независимость данных

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

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

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

5.    Использование приема Инкапсуляция при проектировании структуры данных

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

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

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

У термина “Инкапсуляция” есть несколько трактовок и толкований.

Мне нравится следующий вариант:

Инкапсуляция - обеспечение доступности главного, выделение основного содержания путем помещения всего мешающего, второстепенного в некую условную капсулу (чёрный ящик).

С точки зрения системного анализа — это элемент процесса абстрагирования.

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

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

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

Но следует помнить, что слишком сложная инкапсуляция приводит к снижению управляемости и сужает применяемость модуля.

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

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