Рекомендации по моделированию предметной области автоматизированной исполнительной системы производства
Разработка инфологической модели предметной области
Цель инфологического моделирования – обеспечить наиболее естественные для человека способы сбора и представления той информации, которую предполагается хранить в базе данных. Основными конструктивными элементами инфологических моделей являются сущности, связи между ними и свойства (атрибуты) сущностей.
Сущность – это любой различимый объект, то есть объект, который можно отличить от другого объекта по его атрибутам. Если объекты имеют одинаковые атрибуты, то они не различаются по типу и принадлежат одной сущности. Таким образом, атрибуты необходимы, так как они являются поименованными характеристиками сущностей.
Связь – это ассоциирование двух или более сущностей. Связь позволяет найти в базе данных одни сущности по известным значениям других, а в программе определяют допустимые взаимодействия между объектами. При проектировании баз данных создание связей является наиболее сложной задачей.
При построении инфологической модели базы данных можно использовать язык ER-диаграмм (ER от англ. Entity-Relationship, то есть сущность-связь), универсальный язык моделирования UML, а также язык инфологического моделирования (ЯИМ).
Пример концептуальной ER-диаграммы базы данных, не учитывающей особенности конкретной СУБД, приведен на рис. 2.5.
Рисунок 2.5 – Концептуальная ER-диаграмма базы данных
В процессе инфологического моделирования базы данных необходимо не только составить перечень сущностей предметной области, их атрибутов и связей, но и собрать информацию о пользователях и особенностях существующих приложений, использующих базу данных. Это нужно сделать для того, чтобы учесть совершенно противоположные требования к базе данных со стороны прикладных программистов, создающих базы данных, требования пользователей, делающих запрос на данные, а также требования администраторов баз данных, заботящихся об исключении возможных искажений данных при вводе новой информации или удалении существующей.
Следует учитывать, что плохо продуманную структуру базы данных невозможно исправить никакими приложениями.
Особенности моделирования предметной области программного приложения
Модель предметной области должна представлять собой словарь терминов (объектов и классов), необходимых для моделирования программного приложения.
В основу модели должны быть положены диаграммы классов. Класс в UML – это место для размещения атрибутов (данных об объектах) и операций (функций, выполняемых объектами). Однако при моделировании предметной области в определении атрибутов и операций нет необходимости – эти процедуры следует выполнить позднее. Здесь же необходимо сконцентрировать внимание на выявлении собственно объектов и отношений между ними.
Построение модели предметной области приложения начинается из выявления абстракций, которые существуют в реальном мире и представляют собой основные концептуальные объекты системы. При этом программное обеспечение должно быть структурировано так, чтобы в центре оказались объекты из пространства задачи.
Одной из главных целей разработки программы на основе абстракций из реального мира является создание возможности повторного использования того, или другого программного модуля. Эта возможность создается именно на этапе, когда классы формируются. От выбора классов, то есть от качества абстрагирования, зависит также, какое будет наблюдаемое поведение объекта. Реализация этого поведения обеспечивается внутренним устройством (проведенной инкапсуляцией), однако это устройство не должно содержать излишеств, которые усложняют поведение, или не должно быть слишком простым, ограничивающим поведение.
При моделировании предметной области следует двигаться изнутри наружу. Это означает, что сначала в системе выделяются ключевые объекты, а потом, в процессе изучения с какими еще объектами они взаимодействуют, к ключевым объектам добавляются другие с убывающей степенью значимости, пока не будет создана полная картина взаимодействия объектов и не будет разработан интерфейс, обеспечивающий управление этим взаимодействием.
Необходимо учесть, что при выполнении следующего этапа, то есть при выявлении прецедентов и описании поведения системы, следует применять движение снаружи внутрь, пока не будет понятно, с помощью чего реализуется каждый элемент необходимого поведения.
Итак, моделирование предметной области – это взгляд на систему изнутри наружу и первое, что нужно сделать при построении статической модели системы, это найти классы, которые адекватно отражают абстракции предметной области.
Лучшими источниками для выявления классов являются:
высокоуровневое описание задачи;
низкоуровневые требования к системе.
Практически следует использовать описание задачи и формулировки требований, сделанные в первом разделе проекта, и в этих описаниях и формулировках обвести или подчеркнуть все существительные и именные группы. Таким способом можно найти почти все важные доменные объекты (классы). По мере уточнения этого перечня должно происходить следующее:
существительные и именные группы могут стать объектами или атрибутами;
глаголы и глагольные группы могут стать операциями и ассоциациями;
родительный падеж показывает, что существительное должно быть атрибутом, а не объектом.
Дальше из полученного списка классов следует удалить ненужные (избыточные или несущественные) и непригодные (слишком расплывчатые) элементы.
При построении диаграмм классов можно также рассмотреть возможные обобщения (отношения вида «есть», когда отдельные объекты можно объединить одним именем). Этап моделирования предметной области – это именно тот момент, когда следует также принять решение об агрегировании классов, например, класс «Привод» включает в себя классы (объекты) – преобразователь, двигатель и датчики, осуществляющие заданное поведение привода.
В итоге модель предметной области, дополненная ассоциациями (статическими отношениями между парами классов), должна адекватно описывать статические аспекты задачи, которые не зависят от времени, и в этом напоминать диаграмму сущность-связь, которая применяется в моделировании базы данных.
Пример модели предметной области для программного обеспечения банкомата приведен на рис. 2.6. В модели показаны классы программного обеспечения и их взаимосвязи.
Рисунок 2.6 – Модель предметной области “Банкомат”
Для размещения программы используется абстрактный класс «Контроллер», который не имеет четкого поведения, а поэтому не описывается атрибутами и операциями. Четкое поведение реализуется классом «Транзакция», обеспечивающим соединение контроллера с банком посредством класса-интерфейса «IБанк». Клиент взаимодействует с программным обеспечением банкомата посредством устройства чтения пластиковой карты, которое обслуживается классом «УстрЧтКарт», а также посредством ввода информации с клавиатуры, которая обслуживается классом «Клавиатура». Сервисные функции банкомата реализуют классы «ЭкранФорма» (диалог с клиентом), «Принтер» (печать квитанции) и «УстрВыдНал» (выдача наличных).
Распространенные ошибки моделирования предметной области
При моделировании предметной области студенты допускают следующие ошибки:
1. Слишком большое внимание уделяют анализу всех существительных и глаголов, упуская главные сущности (классы).
При составлении большого словаря есть риск спуститься на весьма низкий уровень абстракции.
2. Включают в классы операции, не изучив детали прецедентов.
Не следует уделять слишком много внимания определению операций на этапе моделирования предметной области. В этот момент еще мало информации для принятия обоснованных решений о деталях поведения.
3. При анализе ассоциации вида «является частью» испытывают трудности, что использовать - агрегирование или композицию.
На стадии моделирования предметной области лучше говорить просто об агрегировании. Более точный выбор следует отложить на этап детального проектирования.
4. Студенты дают классам малопонятные имена, например, cportmgr.Intf вместо Portfoliomanager (специалист, отвечающий за анализ инвестиций).
Чем очевиднее имена классов, тем проще взаимопонимание участников процесса разработки программы. Об акронимах и других видах сокращений можно подумать на этапе реализации.
Рекомендации по разработке спецификации функций системы
Программные приложения различаются между собой набором функций, которые они реализуют. Набор функций определяется конкретной задачей автоматизации. Однако конкретность задачи на начальном этапе проектирования обычно отсутствует. Поэтому для формирования перечня функций программного приложения приходится применять моделирование.
Визуальное моделирование можно представить как некоторый процесс поуровневого спуска от наиболее общих представлений о задачах автоматизации к уточненным процедурам и операциям программной системы. Для этого вначале строится так называемая диаграмма вариантов использования (use case diagram), которая описывает функциональное назначение системы или, другими словами, то, что система будет делать в процессе своего функционирования.
Вершинами в диаграмме использования являются актеры и элементы Use Case. Актеры представляют внешний мир, нуждающийся в работе системы, а элементы Use Case представляют действия, выполняемые системой в интересах актеров. Один актер может использовать несколько элементов Use Case, и наоборот, каждый элемент может быть использован несколькими актерами.
Между актером и элементом Use Case может быть только один вид отношения – ассоциация, отображающая их взаимодействие. Ассоциация может быть помечена именем, ролями, мощностью.
Между элементами Use Case могут существовать два вида отношений – расширения (extend) и включения (include). Эти отношения показаны на рисунке 2.5.
Рисунок 2.5 – Диаграмма варианта использования «Размещение
заказа» программной системы интернет-магазина
Отношение расширения (extend) между элементами Use Case означает, что поведение базового элемента может быть расширено поведением другого элемента Use Case.
Отношение включения (include) между двумя элементами соответствует делегации обязанностей. При этом включаемый элемент реализует обязательное поведение.
Элемент Use Case описывает, что должна делать система, но не определяет, как она должна это делать. Это правило позволяет отделять внешнее представление системы (интерфейс) от её внутреннего представления (способа реализации).
Поведение элемента Use Case описывается потоком событий, в котором выделяют:
основной поток и альтернативные потоки поведения;
условия для запуска и остановки элемента Use Case;
условия взаимодействия элемента Use Case с актерами;
данные, которыми обмениваются актер и система.
Для спецификации прецедентов нужно использовать прототипы графического интерфейса, с помощью которых можно представить, что будет делать пользователь и как на это действие пользователя будет реагировать система.
Текст прецедента следует формулировать в ясной и короткой форме. Каждое предложение должно иметь структуру «существительное-глагол» и должны быть сразу видны актеры и потенциальные доменные объекты. По мере выявления новых объектов или их уточнения нужно сразу обновлять модель предметной области. Важно также внимательно следить за возможными альтернативными последовательностями действий (исключениями) для каждого прецедента.
В качестве примера в табл. 2.2 представлено описание прецедента «Снять наличные» применительно к системе управления банкоматом.
Таблица 2.2
Действия актеров |
Отклик системы |
Исключение 1. Кредитная карточка недействительна. |
|
Исключение 2. ПИН-код неверный. |
|
|
|
Исключение 3. Требуемая сумма превышает текущее состояние счета. |
|
Рекомендуется следующая последовательность моделирования прецедентов:
Создать шаблон описания прецедента, в котором предусмотреть разделы «Главная последовательность» и «Альтернативные последовательности». Другие разделы не нужны, они будут только отвлекать внимание.
Задать себе вопрос: «Что должно происходить?». Из ответа на него начинается главная последовательность.
Задать себе вопрос: «Что еще может происходить?». Важно учесть все, что может сделать пользователь и зафиксировать все альтернативные варианты, то есть исключения. Если будет упущен какой то вариант, ситуация станет неопределенной и система зависнет.
Типичные ошибки при моделировании прецедентов
1. Вместо словесного сценария использования студенты пишут функциональные требования.
Следует четко отличать описание порядка использования от требований к системе. Требования обычно формулируются относительно того, что должна делать система. Сценарий же описывает действия, которые осуществляются пользователем и системой. При этом действия системы являются её реакцией на действия пользователя.
2. Описываются атрибуты и методы, а не порядок использования.
Тексты прецедентов не должны излишне подробно описывать детали представления. Следует также воздержаться от ссылок на поля в экранных формах. В тексте прецедента не следует ни именовать, ни описывать методы (операции), так как они говорят о том, как система делает что-то.
3. Прецеденты записываются слишком лаконично.
При написании текстов прецедентов, многословие более предпочтительно, чем лаконичность. Переходя к следующему этапу моделирования (моделирование поведения), хорошо бы иметь часть деталей из описания прецедентов.
4. Прецеденты полностью абстрагируются от интерфейса пользователя.
Один из фундаментальных принципов, основанный на прецедентах, заключается в том, что при проектировании системы разработчики должны учитывать действия, которые пользователи выполняют с помощью экрана и клавиатуры, то есть помнить об интерфейсе.
5. Не присваиваются явные имена граничным объектам.
Граничными называются объекты, с которыми взаимодействуют актеры. К их числу относятся экранные формы, диалоговые окна и меню. Граничные объекты следует именовать в текстах прецедентов явным образом.
6. Прецеденты описываются не с точки зрения пользователя.
С точки зрения пользователя прецедент более всего эффективно формулируется с применением глаголов настоящего времени в действительном залоге, например, «Пользователь вводит пароль». Прецеденты должны описывать действия пользователя и реакцию на них системы, а такого рода текст лучше всего звучит в действительном залоге.
7. Описываются только действия пользователя, а реакция системы игнорируется.
Текст прецедента должен отображать как событие, так и отклик на это событие, например: «Когда пользователь делает то-то, система делает то-то». Прецедент должен описывать то, что происходит «под капотом» в ответ на действии пользователя, например, создание новых объектов, контроль данных, которые вводятся, или вывод сообщений об ошибках. В тексте прецедента должны рассматриваться обе стороны диалога пользователя с системой. Игнорирование описания реакции системы равносильно игнорированию поведения программы.
8. Опускаются описания альтернативных последовательностей действий.
Главные потоки обычно проще описать. Но это не означает, что работу с альтернативными потоками можно отложить к этапу детального проектирования. Опыт показывает, что, когда остаются нераскрытыми важные альтернативные последовательности, возникают проблемы с доводкой проекта, так как непредусмотренные действия пользователей приводят к «зависанию» приложения.
Переходить к дальнейшим этапам процесса разработки надо после того, как достигнуты следующие цели моделирования прецедентов:
прецеденты описывают всю необходимую функциональность системы;
для каждого прецедента четко и коротко описана главная последовательность действий, а также все альтернативные последовательности;
выделены сценарии, общие для нескольких прецедентов.
Благодаря модели прецедентов, разработчик приложения может получить представление о динамическом аспекте объектной модели.