Технологии разработки программного обеспечения Структуризация классов программной системы
реклама
Технологии разработки программного обеспечения Лекция 9. Структуризация классов программной системы Последовательность выполнения анализа системы 1. Построение концептуальной статической модели системы: – выявляются внешние и интерфейсные классы; – выявляются сущностные классы; 2. Структуризация программных классов статической модели. – выявляются другие программные классы 3. Построение динамической модели системы на основе реализации вариантов использования. • Концептуальная статическая модель создается на раннем этапе анализа. • Концептуальная модель – применяется для моделирования ПрО и – помогает понять проблемы ПрО. • Разработка концептуальной статической модели включает: 1. выделению контекста системы – внешних и интерфейсных классов; 2. выделению сущностных классов. Пример концептуальной статической модели • Концептуальная статическая модели банковской системы. • Банк предоставляет сервисы (услуги) для нескольких Банкоматов (ATM). • Каждый ATM является композитным классом, который включает составные части Типы объектов и классов • Объекты и классы разделяются в соответствии с теми ролями, которые они играют в приложении, на следующие типы: 1. сущностные классы (entity class); 2. интерфейсные (граничные классы, boundary class); 3. управляющие классы (control class); 4. классы прикладной логики (application logic class). • Большинство приложений будет включать объекты всех 4 типов. • Однако, разные виды приложений будут иметь наибольшее количество классов какого-то одного типа. Типы программных классов • Обычно выделяют следующие типы программных классов : • Связи между классами показывают отношение наследования. Типы классов приложения • Обычно выделяют следующие типы программных классов : • Связи между классами показывают отношение наследования. Отнесение объектов к типам • В большинстве случаев, отнесение объекта к определенному типу, является очевидным. • Однако, в некоторых случаях, может оказаться, что объект удовлетворяет более чем одному описанному ранее критерию. • Например: объект может иметь – характеристики сущностного объекта, тем что он инкапсулирует некоторые данные и – характеристики алгоритмического объекта, тем что он выполняет некоторый существенный алгоритм.. • В этом случае данный объект следует отнести к тому типу, которая кажется более подходящей. • Более важно определить все объекты в системе, чем чрезмерно беспокоиться о том, к какому точно типу их отнести в не понятных случаях. • Для каждой типа объектов имеется некоторый шаблон их поведения объектов, который описывает, как они взаимодействуют со своими соседними объектами. • Полезно понять типичный шаблон поведения объектов, – когда некоторая категория объектов используется в приложении, то очень вероятно, что ее объекты взаимодействует с соседними объектами одинаковых типов аналогичным способом. 1. Сущностные объекты • Сущностной объект (entity object) это программный объект, который содержит информацию и предоставляет доступ к хранилищу, которое хранит данную информацию. – во многих случая является устойчивым (persistent). • В некоторых случаях доступ к сущностному объекту можно получить через сервисный объект. 2. Интерфейсный (граничный) объект • • Граничный объект (boundary object) это программный объект, который взаимодействует и обменивается информацией с внешней средой (контекстом). Граничные объекты далее делятся на следующие подтипы: 1. объект взаимодействия с пользователем (user interaction object) - программный объект, взаимодействующий и предоставляющий интерфейс для пользователя – человека; 2. объект – заместитель (Proxy object) - программный объект, который взаимодействует и обменивается информацией с внешней системой или подсистемой; 3. объект взаимодействующий с устройством ввода/вывода (device I/O boundary object). 3. Управляющий объект • Управляющий объект (control object) это программный объект, выполняющий координацию работы набора объектов. • Управляющие объекты делятся на следующие подтипы: 1. координирующие объекты; 2. управляющие объекты, зависящие от состояния; 3. таймерные объекты, формирующие сообщения по заданному временному. 4. Объект прикладной логики • • Объект прикладной логики (application logic object) это программный объект, содержащий подробности прикладной логики. Требуется, когда желательно скрыть прикладную логики отдельно от данных, которые она использует, – • • Например, чтобы прикладной логикой можно было обмениваться независимо от данных. В информационных системах, объекты прикладной логики обычно являются объектами бизнес-логики. А в СРВ, научных и инженерных приложениях, объекты прикладной логики обычно являются алгоритмическими объектами. 5. Сервисные объекты • Сервисные объекты это еще один тип программных объектов. • Они предоставляют сервисы клиентским объектам, обычно в сервисориентированных архитектурах (ServiceOriented Architectures, SOA) и приложениях. UML стереотипы • Для задания типа конкретного класса на UML диаграммах используются стереотипы. • Каждый поведенческий шаблон изображается на UML диаграммах в виде <<тип>> • Такое разделение по типам применяется одинаково и к классам и к объектам. 1. Моделирование контекста системы Моделирование контекста системы • Важно понять пределы компьютерной системы, – что должно быть включено в саму систему, – что должно остаться вне системы. • Моделирование контекста явно задает, что находится внутри системы, а что находится вне системы. • Моделирование контекста может быть сделано – на уровне всей системы (технического и программного обеспечения) или – на уровне программной системы (только ПО). • Моделирование контекста системы состоит в следующем: 1. определение внешних сущностей, взаимодействующих с сиcтемой (внешние классы); 2. определение классов, которые будут взаимодействовать с этими внешними сущностями (интерфейсные классы). • В диаграмме классов контекста (ДКК) системы задает явную границу между – системой (технической и программной), рассматриваемой в виде черного ящика, и – внешней средой (которая теперь включает ТО) • Такое задание границ вокруг системы является более детальным, чем то, что обычно показывается в диаграммах вариантов использования. Пример технич. и прогр. системы • На контекстной ДК технич. и прогр. обеспечения банковской системы показываются ее взаимодействие с актерами: – ATM Клиентами и – ATM Операторами • Все другие элементы включаются (как часть) в общую технич. и прогр. систему. Стереотипы для задания типа внешних классов • Внешние классы также описываются с помощью UML стереотипов. • На схеме показаны типы внешних классов. • Каждый прямоугольник представляет разные типы внешних классов, а связи между ними отношения наследования. Пример стереотипов для внешних классов • Стереотипы для классификации внешних классов системы: – «external user» («внешний пользователь»), – «external system» («внешняя система»), – «external timer» («внешний таймер»). • Классы внешних устройств далее классифицируются следующим образом: 1. внешние классы устройств ввода (например: датчики); 2. внешние классы устройств вывода (например, исполнительные механизмы (приводы, actuator)); 3. внешние классы устройств ввода/вывода (ATM card reader). Пример диаграммы классов контекста • Контекстная диаграмма классов для Банковской Системы. Пример диаграммы классов контекста (2) • Диаграмма классов контекста Банковской Системы со стереотипами Моделирование человекапользователя системой • Человек-пользователь часто взаимодействует с ПС с помощью стандартных устройств ввода/вывода, таких, как клавиатура/дисплей и «мышь». – Характеристики таких стандартных устройств не являются важными, т.к. они управляются ОС. • Более важным является интерфейс с пользователем в терминах – информации, которая выводится для пользователя и – информации, которая вводится пользователем. • Поэтому внешний пользователь, взаимодействующий с системой при помощи стандартных устройств, моделируется как «внешний пользователь», а не как устройство. Рекомендация • Если пользователь-человек взаимодействует с системой с помощью стандартных устройств ввода/вывода, то только тогда он показываться в виде внешнего класса пользователей • Если пользователь взаимодействует с ПС с помощью специфичных для приложения устройств ввода/вывода, то эти устройства должны показываться в виде внешних классов устройств ввода/вывода. • Для встроенных систем реального времени желательно выявлять низкоуровневые внешние классы, которые соответствуют физическим устройств ввода/вывода, для которых ПС должна выполнять взаимодействие. • Такие внешние классы показываются с помощью стереотипа «внешнее устройство ввода/вывода» («external I/O device»). • Примерами таких внешних устройств I/O в «Автоматизированной Системе Управления Транспортными средствами» являются: – внешнее устройство ввода - «Датчика прибытия» (Arrival Sensor); – внешнее устройство вывода - «Двигатель» (Motor). Класс «внешняя система» • Класс «внешняя система» («external system») требуется, в том случае, если разрабатываемая система взаимодействует с другими системами (посылает или получает от них данные). – Например, в «Автоматизированной Системе Управления ТC») система взаимодействует с двумя внешними системами: 1. Управляющая система 2. Показывающая система Класс «внешний таймер» • Класс «внешний таймер» («external timer») показывается в контекстной ДК, – если требуется отслеживать время; – и/или если требуется внешний таймер для запуска (инициирования) внешних действий в данной системе. • Классы «внешний таймер» наиболее часто требуются в системах реального времени (СРВ). – Пример: в «Автоматизированной Системе Управления ТС» моделируются «Часы» (Clock). – Они требуются, т.к. ПС требуются события от внешнего таймера, чтобы инициировать различные периодически повторяющиеся действия. Связи внешних классов с системой • Ассоциации между внешними классами и агрегированным классом ПС и показывается на контекстной диаграммы классов. • Также показывается имя и кратность (multiplicity) таких ассоциаций. • Стандартными именами таких ассоциаций в контекстной ДК ПС являются 1. «Вводить_в» (Inputs to); 2. «Выводить_в» (Outputs to); 3. «Общаться_с» (Communicates with); 4. «Взаимодействовать_с» (Interacts with); 5. «Отправлять_сигналы» (Signals). Выявление интерфейсных (граничных) классов Интерфейсные классы • Внешние классы это классы, описывающие сущности, которые находятся вне системы и взаимодействуют с ней. • Интерфейсные (граничные) классы это классы, находящиеся внутри системы, которые взаимодействуют и обмениваются данными с внешними классами. • Для определения интерфейсных классов программной системе, необходимо рассмотреть внешние классы, с которыми они связаны. Выявление интерфейсных классов • Выявление внешних классов, взаимодействующих с системой, помогает выявить некоторые из классов внутри системы, а именно интерфейсные классы. • Каждый внешний класс взаимодействует с некоторым интерфейсным классом. • Между внешними и соответствующими им интерфейсными классами существует взаимно-однозначное соответствие (при условии, что внешние классы правильно выявлены). Типы интерфейсных классов 1. Классы интерфейсов пользователя. 2. Классы прокси-объектов. 3. Классы интерфейсов устройств. Изображение внешних и интерфейсных классов • Ранее рассматривалось, как провести границу системы и разработать диаграмму классов контекста системы, на которой представлены все внешние классы, взаимодействующие с системой. • Полезно уточнить эту диаграмму, показав интерфейсные и. внешние классы. • Интерфейсные классы расположены внутри системы - точнее, на границе между системой и внешней средой. • Система показана в виде пакета, внутри которого изображены интерфейсные классы, являющиеся частью системы. • Каждый внешний класс взаимно-однозначно связан с каким-либо интерфейсным. • Таким образом, начав с внешних классов, изображенных на рассматриваемой диаграмме, задача уточняется до выявления интерфейсных классов. Пример показа внешних и интерфейсных классов • Внешние и интерфейсные классы в банковской системе 1. Объекты интерфейса пользователя • Объект интерфейса пользователя описывает интерфейс с человеком на основе таких стандартных устройств, как клавиатура, дисплей и мышь. • Стандартные устройства ввода/вывода обычно управляются операционной системой, так что в приложение не нужно включать специальные объекты для интерфейса с ними. • В зависимости от применяемой технологии интерфейс пользователя бывает – очень простым (в виде командной строки) или – очень сложным (графический интерфейс пользователя - GUI). Пример класса и объекта взаимодействия с пользователем • Пример представления простого класса, выполняющего взаимодействие с пользователем, который называется «Operator Interaction»: Объекты интерфейса пользователя • Примером простого объекта интерфейса пользователя является «Интерфейс Оператора», который – принимает команды оператора, – запрашивает показания датчика от сущностного объекта «Хранилище Показаний Датчика» и – отображает полученные данные на дисплее. • Объект интерфейса пользователя может быть составным и включать несколько более простых объектов. • Это значит, что актеры взаимодействуют с системой при помощи нескольких объектов интерфейса пользователя, последовательно или параллельно. • Для таких объектов предусмотрен стереотип «интерфейс пользователя» («user interaction»). 2. Прокси объекты • Объект-заместитель (прокси объект) взаимодействует и обменивается данными с внешней системой. • Прокси объект является представителем внешней системы и скрывает детали того, «как» выполняется взаимодействие с внешней системой. • Например: прокси класс для робота «Захвати и положи». • Каждый прокси объект скрывает детали того, как он взаимодействует и обменивается данными с конкретной внешней системой. • Наиболее вероятно, что прокси объект обменивается данными, с помощью сообщений, с внешней, управляемой компьютером системой (такой, как робот в рассмотренном примере), а не с датчиками и исполнительными устройствами, как это делают граничные объекты устройств ввода/вывода. • Однако, такие задачи рассматриваются уже на этапе проектирования. 3. Объекты интерфейса устройства • Объект интерфейса устройства представляет собой программный интерфейс с аппаратным устройством ввода/вывода. • Для нестандартных устройств требуются объекты интерфейса устройства, относящиеся к уровню приложения. • Чаще они встречаются в системах реального времени, хотя бывают необходимыми и в других системах. • Физический объект в ПрО приложения является объектом реального мира, который имеет физические характеристики. – Например, его может видеть и к нему можно прикоснуться. • Для каждого физического объекта реального мира, который релевантен решаемой проблеме, должен быть соответствующий ему программный объект в системе. • Реальные физические объекты обычно взаимодействуют с системой при помощи датчиков и приводов. • Такие объекты либо передают информацию в систему посредством датчиков, либо получают от нее управляющие воздействия на приводы. • С точки зрения программной системы объекты реального мира — это, по сути дела, устройства ввода/вывода, поставляющие в систему входную информацию и получающие от нее выходную. • Поскольку объекты реального мира соответствуют устройствам ввода/вывода, то осуществляющие интерфейс с ними программные объекты называются объектами интерфейса устройств. Пример объекта интерфейса устройства ввода на диаграмме коммуникации. • Объект интерфейса устройства ввода «Интерфейс Датчика Температуры» получает информацию о температуре от объекта, представляющего физическое устройство ввода, - Датчика Температуры. Моделирование классов сущностей Сущностные классы • Сущностные классы (классы-сущности, entity classes) это концептуальные классы, активно использующие данные. – их основная цель состоит в хранении данных и предоставлении доступа этим данным. • Во многих случаях, классы сущностей являются постоянными (persistent) – эти данные являются долгоживущими и должны храниться файлах или БД. • Сущностные объекты хранят данные и предоставляют ограниченный доступ к ним с помощью своих операций. • Иногда сущностному объекту может понадобиться доступ к информации, инкапсулированной в других аналогичных объектах. • В системах реального времени такие объекты часто располагаются в оперативной памяти. • Во многих информационных системах инкапсулированные ими данные находятся в базе данных. Пример атрибутов классов сущностей системы он-лайн торговли Выявление сущностных классов • Сущностные классы выявляются с помощью ранее рассмотренных методов: – грамматический анализ «существительное глагол»; – CRC анализ; – объектный блиц. Пример концептуальной статической модели : сущностные классы • Концептуальная статическая модель банковской системы: сущностные классы Пример моделирования сущностных классов • Пример моделирования сущностных классов – система онлайн торговли. • В описании проблемы упоминаются: – клиенты (customers), – счета (accounts) и – каталоги (accounts) . Пример сущностного класса и объекта • На рис. показан фрагмент диаграммы коммуникации, объект «Счет» получает сообщения «Открыть», «Закрыть», «Кредитовать», «Дебетовать» и «Прочитать» и отвечает на них, предоставляя информацию о «Балансе» и «Состоянии». • «Счет» также используется в варианте использования ежемесячной подготовки и печати выписок из счета для клиентов. Примером сущностного класса (2) • Примером сущностного класса в приложении, которое занимается мониторингом датчика реального времени, может служить класс «Показания Датчика» (рис. 9.10), где хранится информация об аналоговых датчиках. • Его атрибуты - имя Датчика, значение Датчика, верхний Предел, нижний Предел и состояние Тревоги. • Экземпляром этого класса может быть объект показания Датчика Температуры, который получает сообщения Прочитать и Обновить и отвечает, возвращая Текущие Показания Датчика. • Как показано на рисунке, объект, нуждающийся в получении последних показаний датчика, посылает сообщение Прочитать. • Объект, который считал показания реального датчика и хочет обновить объект показания Датчика Температуры, посылает сообщение Обновить. 3. Управляющие классы и объекты • Управляющие объекты (control object) это программные объекты, выполняющие координацию работы для наборов объектов. • Управляющие объекты делятся на: 1. координирующие объекты; 2. управляющие объекты, зависящие от состояния; 3. таймерные объекты, связанные с отправкой сообщений в заданные моменты времени. Управляющие объекты (2) • Управляющий объект обеспечивает общую координацию исполнения варианта использования. • Для простых ВИ управляющие объекты не нужны, но для более сложных могут понадобиться. • Управляющий объект похож на дирижера оркестра, который распоряжается поведением других объектов, участвующих в ВИ, говоря каждому из них, что и когда он должен делать. • В зависимости от особенностей ВИ управляющий объект может зависеть или не зависеть от состояния. 1. Объекты-координаторы • Объект-координатор задает весь порядок работы набора взаимосвязанных объектов на основе поступающих входных данных, вне зависимости от состояния. • Он устанавливает, когда и в какой последовательности будут действовать другие объекты, участвующие в прецеденте. • Координатор принимаем решение только на основе поступающих входных данных и не зависят от состояния. • Иными словами, действие, инициированное координатором, определяется исключительно информацией во входном Пример объекта-координатора • Пример объекта-координатора и объектов бизнеслогики. • В банковской системе такими объектами являются – – – – Менеджер Транзакций Снятия, Менеджер Транзакций Перевода, Менеджер Транзакций Получения Справки и Менеджер Транзакций Проверки ПИН-кода. 2. Управляющие объекты, зависящие от состояния • Поведение управляющего объекта, зависящего от состояния, различно в каждом из возможных состояний. • Для определения такого объекта применяется конечный автомат, и графически он изображается на диаграмме состояний. • Существует два вида диаграммы состояний – плоские и – иерархические. • Управляющий объект, зависящий от состояния, получает входные события, которые вызывают переходы между состояниями, и генерирует выходные события, управляющие работой других объектов. • Выходное событие зависит не только от входного, но и от текущего состояния объекта. Пример управляющего объекта, зависящего от состояния • Примером управляющего объекта, зависящего от состояния, служит объект «Управление Банкоматом», определяемый с помощью диаграммы состояний. • Из рисунка видно, что этот объект управляет двумя объектами интерфейса устройства – – Интерфейсом Устройства Печати Чеков и – Интерфейсом Устройства Выдачи Наличных. • В системах реального времени обычно есть один или несколько управляющих объектов, зависящих от состояния. • Может существовать даже несколько объектов одного типа. • Каждый объект исполняет экземпляр одного и того же конечного автомата (изображаемого в виде диаграммы состояний), хотя в каждый момент времени эти объекты, скорее всего, оказываются в разных состояниях. • В банковской системе примерами такого рода являются банкоматы, имеющие собственный зависящий от состояния управляющий объект «Управление Банкоматом», который исполняет свой экземпляр диаграммы состояний. • Другой пример - система управления лифтами, моделируемой с помощью управляющего объекта «Управление Лифтом» посредством диаграммы состояний. • Очевидно, что у любого лифта есть свой объект «Управление Лифтом». 3. Объекты-таймеры • Объект-таймер - это управляющий объект, активизируемый внешним таймером, например тактовым генератором или часами операционной системы. • Объект-таймер либо сам осуществляет некоторое действие, либо активизирует другой объект, который выполнит нужное действие. • Объект «Таймер Пути» активизируется событием, которое генерирует внешний таймер «Тактовый Генератор». • Объект-таймер посылает сообщение «Вычислить объекту Путь», который вычисляет общее пройденное автомобилем расстояние. 4. Классы и объекты прикладной логики • Обычно выделяют 3 типа объектов прикладной 1. Объекты бизнес-логики 2. Алгоритмические объекты 3. Сервисные объекты. • Как и управляющие объекты, объекты прикладной логики наиболее вероятно будут рассматриваться, когда будет разрабатываться в динамическая модель, а не начальная концептуальная модель. 1. Объекты бизнес-логики • Объекты бизнес-логики определяют логику обработки приложением запросов клиентов. • Их назначение заключается в инкапсуляции бизнес-правил, которые могут изменяться независимо друг от друга. • Обычно во время выполнения объекты бизнес-логики обращаются к сущностным объектам. • Объекты бизнес-логики нужны только в некоторых ситуациях. • иногда бизнес-логику разумно инкапсулировать в отдельный объект, • иногда она настолько проста, что ее можно реализовать в виде операции сущностного объекта. • Общая рекомендация такова: – если для выполнения бизнес-правила приходится обращаться к двум или более сущностным объектам, вводите отдельный объект бизнес-логики; – если же для выполнения правила достаточно одного сущностного объекта, предоставьте это операции самого объекта. Пример объекта бизнес-логики • На диаграмме показан пример объекта бизнес-логики – «Менеджер Транзакций Снятия денег». • Он обслуживает запросы клиентов на снятие денег. • Например: – первое бизнес-правило может состоять в том, что после снятия на счету клиента должно остаться не менее 100 рублей. – Второе правило гласит, что по дебетовой карточке клиент не имеет нрава снимать более 30000 рублей в день. • Менеджер Транзакций Снятия обращается к объекту Счет, чтобы удостовериться в выполнении условий первого правила. • Для проверки второго правила он запрашивает объект Дебетовая Карточка, который хранит накопительный итог сумм, снятых клиентом банкомата в течение дня. • Если хотя бы одно правило не выполняется, запрос на снятие денег отклоняется. • Для выполнения бизнес-правил объект бизнес-логики обычно должен взаимодействовать с сущностными объектами. • В этом отношении он напоминает объект-координатор. • Однако, если в обязанности координатора входит управление работой других объектов, объект бизнес-логики отвечает, прежде всего, за выполнение бизнес-правил. 2. Алгоритмические объекты • Объект-алгоритм инкапсулирует алгоритм, применяемый в данной предметной области. • Такие объекты чаще всего встречаются – в приложениях реального времени, – а также научных и инженерных задачах в тех случаях, когда в предметной области имеется нетривиальный алгоритм, который может изменяться независимо от других ее аспектов. • Простые алгоритмы обычно реализуются как операции сущностного объекта, работающие с хранящимися в нем данными. • Во многих научных и инженерных приложениях алгоритмы уточняются итеративно, поскольку их совершенствование, например с точки зрения производительности и точности вычислений, не зависит от данных. • В системе круиз-контроля объект-алгоритм Крейсер вычисляет, как надо изменить тягу путем сравнения текущей скорости автомобиля с требуемой крейсерской скоростью. • Алгоритм достаточно сложен, поскольку требуется плавно разгонять или притормаживать автомобиль, чтобы пассажиры не испытывали неудобств. • Объект-алгоритм часто инкапсулирует данные, необходимые для выполнения алгоритма. • Это могут быть начальная информация, промежуточные результаты или пороговые данные, например максимальные и минимальные значения. • Объект-алгоритм обычно взаимодействует с другими объектами. В этом отношении он напоминает объект-координатор. • Но в отличие от координатора, который должен управлять другими объектами, назначение объекта-алгоритма состоит, прежде всего, в инкапсуляции и выполнении алгоритма. 3. Сервисные объекты • Сервисный объект это объект, который предоставляет услуги (сервис) для других объектов. • Обычно они используются в сервис-ориентированных архитектурах и приложениях. • Клиентский объект может сделать запрос на услугу от сервисного объекта, на который сервисный объект будет отвечать. • Сервисный объект сам никогда не инициирует запрос, однако, в ответ на запрос в услуге он может искать помощи у других сервисных объектов. • Сервисные объекты играют важную роль в сервисориентированных архитектурах (SOA), хотя они также используются и в других архитектурах, таких, как клиент/серверная архитектуры и основанных на компонентах архитектурах ПО. • Сервисный объект может инкапсулировать данные, которые должны для обработки запроса клиента сервиса или для доступа к другому сущностному объекту (или объектам), которые содержат эти данные. • Примером сервисного класса является «Сервис Каталога» (Catalog Service): • На рис. показан пример выполнения экземпляра класса «Catalog Service». • Объект класса «Catalog Service» предоставляет поддержку для просмотра различных элементов из каталога поставщика и для их выбора. • Координатор «Customer Coordinator» помогает объекту класса «Customer Interaction» найти каталог поставщика, путем предоставления объекта «Catalog Service» и выполнения выборки из данного каталога.
