3. Основные принципы объектно-ориентированного подхода.
Объектно-ориентированные подходы к разработке ПО (Object-oriented Development, OOD)
Данный период начался в начале 80-х годов и оказал влияние на почти все виды деятельности в области разработки ПО.
OOП, более конкретно дисциплинированный подход к анализу и проектированию ПО, был только одним из множества инноваций.
Прошло около десяти лет, пока ООА и ООПр развились до такого состояния, что стали универсальными.
Базовая философия ОО подхода
ОО подход является достаточно сложным по сравнению с ранее предложенным структурным подходом к разработке ПО.
Данный подход не очень интуитивно понятный в смысле выполнения вычислений (по сравнению с декомпозицией функций), поэтому он требует специального образа мышления.
Данный подход также включает набор различных понятий, которые должны использоваться совместно
Проблема сопровождения ПО
В 70-х годах было проведено много статистических исследований того, как разные компании выполняют разработку ПО.
В результате были полученные очень интересные результаты:
большинство компаний тратили 70% своих усилий на сопровождение ранее созданного ПО;
работа по модификации существующего ПО часто требует в 5-10 раз больше усилий, чем первоначальная его разработка.
Стало понятно, что-то делалось неправильно в разработке ПО.
Специалисты по ПО пришли к выводу, что не возможно исправить (улучшить) структурный подход.
Стало понятно, что ООП является тем подходом, который выведет из проблем удобства сопровождения.
Основной целью ООА/ООПр стало удобство сопровождения ПО.
Удобство поддержки ПО
Основной целью ОО подхода является удобство сопровождения ПО в связи постоянным изменением требований.
Удобство сопровождения улучшится если структура ПО будет имитировать инфраструктуру проблемного пространства.
Показатель производительности первоначального создания ПО является менее важным, по сравнению с производительностью сопровождения.
Другой очень приоритетной целью разработки ПО является его надежность .
Одной из основных причин того, что обычная поддержка ПО является трудоемкой, связано с тем, что изменения стали настолько сложными, что они вносили новые дефекты.
Все в современном ООА/ООПр нацелено на разработку более понятных, легко поддерживаемых и надежных приложений.
Базовым допущением ОО подхода является -- ПО постоянно меняются в течение жизни программного продукта.
Если это не выполняется. (программирование научных задач), то ОО подход может быть лучшим использовать структурны подход к разработки ПО.
Изменения требований к ПО
Изменения неизбежны, но их никто не любит изменения.
Когда изменения предметной области доходят до ПО в виде новых требований, то оказывается, что их проще внести в ПО, если структура ПО копирует структуру ПрО потребителя.
Это является базовым предположением, которое лежит в основе ОО подхода.
Абстрагирование области решения проблемы
Основная цель ОО подхода заключается в имитировании структуры предметной области (ПрО) пользователей в структуре ПО.
Вводятся следующие понятия:
ПрО пространства потребителей и
ПрО компьютерного пространства.
Эти пространства существенно различаются.
ПрО потребителей являются очень разнообразными и концептуально сложными.
Практически не возможно напрямую имитировать (копировать) ПрО потребителей в ПО (ПрО программы).
Проблемное пространство
Проблемное пространство это среда, в которой должна быть решена некоторая проблема (задача).
Определяющим признаком проблемного пространства является то, что в нем живет потребитель,
Тот кто определяет требования, тот для выполнения такой работы должен содержать у себя в голове конкретную ПрО.
Любая функциональность разрабатываемого ПО является тем, что люди уже должны были выполнять в данной ПрО, до того, когда там появилось ПО.
Как раз данная ПрО и является проблемным пространством.
Обычно ПП не связано с КП и находится вне его.
Это совершенно очевидно в следующих ситуациях:
управление складом,
система подачи заявок в точках продаж (point-of-sales (POS) order entry ),
управление портфелем ценных бумаг,
управление воздушным движением,
и т.п.
Это немного менее очевидно для научных приложений, таких, как:
линейное программирование и
системы прогнозирование погоды
Основные виды деятельности в объектно-ориентированном подходе
Основными видами работ в объектно-ориентированном подходе (ООП) являются:
Объектно-ориентированный анализ (OOA),
Объектно-ориентированное проектирование (ООПр, OOD),
Объектно-ориентированное программирование (ООП, OOP)
Требования потебителей к ПО
Функциональные - какие задачи ПО должно решать
Не функциональные - как должно работать ПО
безопасность
производительность (время отклика)
соответствие стандартам
поддерживаемые протоколы взаимодействия
4. Основные этапы разработки ПО в ОО Подходе
Выявление и описание требований к ПО
Планирование выполнения проекта разработки ПО
Анализ проблемы
Выявление классов
Разработка архитектуры ПО (общей структуры).
Проектирование системы
Укрупненное проектирование ПО.
Детальное проектирование ПО.
Кодирование и тестирование единиц кода.
Системное тестирование.
Внедрение разработанного ПО у заказчика.
Выявление и спецификация требований
Во всех моделях разработки ПО в той или иной форме выполняется выявление и описание требований к ПО.
В гибких подходах к разработке предполагается, что будут выявлены и документально описаны только высокоуровневые требования, а детальные требования будут выявлены в результате взаимодействия с потребителем.
Другие подходы предпочитают, чтобы требования были выявлены и точно описаны заранее.
Целью деятельности по работе с требования является создание документа:
«Спецификаций Требований к ПО» (СТПО),
которые детально описывают, что должна уметь делать разрабатываемое ПО.
В российских условиях это документ «Техническое задание (ТЗ)»
Спецификаций Требований к ПО (СТПО) ==
Software Requirements Specification (SRS)
Планирование выполнения проекта разработки
Процесс работы с требованиями является последовательностью видов деятельности, в результате которых создается высококачественный документ, содержащий СТПО.
Процесс работы с требованиями обычно состоит из трех основных задач:
анализ проблемы или требований;
спецификация (детальное описание) требований;
проверка требований.
Аналих проблемы
Встречи с заказчиком
5. Варианты использования и их описание
Что такое варианты использования?
Основная цель создания любой программной системы - создание такого программного продукта, который помогает пользователю выполнять свои повседневные задачи. Для создания таких программ первым делом определяются требования, которым должна удовлетворять система. Однако если дать пользователям написать эти требования на бумаге, то часто можно получить список функций, по которому трудно судить будет ли будущая система выполнять свое назначение и сможет ли она облегчить пользователю выполнение его работы вообще. Непонятно какие из выполняемых функций более важны и для кого.
Для того, чтобы более точно понять как должна работать система, все чаще используется описание функциональности системы через варианты использования (Use Case или прецеденты). Варианты использования это - описание последовательности действий, которые может осуществлять система в ответ на внешние воздействия пользователей или других программных систем. Варианты использования отражают функциональность системы с точки зрения получения значимого результата для пользователя, поэтому они точнее позволяют ранжировать функции по значимости получаемого результата.
Зачем нужны варианты использования?
Варианты использования предназначены в первую очередь для определения функциональных требований к системе и управляют всем процессом разработки. Все основные виды деятельности такие как анализ, проектирование, тестирование выполняются на основе вариантов использования. Во время анализа и проектирования варианты использования позволяют понять как результаты, которые хочет получить пользователь влияют на архитектуру системы и как должны себя вести компоненты системы, для того чтобы реализовать нужную для пользователя функциональность.
В процессе тестирования, описанные ранее варианты использования позволяют проще оценить точность реализации требований пользователей и позволяют провести пошаговую проверку этих требований.
Стратегия использования прецедентов при определении требований определяет необходимость дополнительно к вопросу "что пользователи ждут от системы?" задавать вопрос "что система должна сделать для конкретного пользователя?". Такой подход позволяет искать функции, которые нужны многим пользователям и исключать те возможности, которые не могут помочь пользователям выполнять свои повседневные задачи.
Состав диаграммы Use Case
Диаграмма вариантов использования состоит из актеров, для которых система производит действие и собственно действия Use Case, которое описывает то, что актер хочет получить от системы. Актер обозначается значком человечка, а Use Case - овалом. Дополнительно в диаграммы могут быть добавлены комментарии.
Ответы на следующие вопросы позволят определить актеров, взаимодействующих с системой:
кто взаимодействует с системой или использует систему;
кто передает или принимает информацию в/из системы;
кто является внешним по отношению к системе.
Каждый вариант использования показывает, как конкретный актер использует систему и в дальнейшем расширяется диаграммами состояний и последовательности действий.
Виды взаимодействий
Между актерами и вариантами использования могут быть различные виды взаимодействия. Основные виды взаимодействия следующие:
Простая ассоциация - отражается линией между актером и вариантом использования (без стрелки). Отражает связь актера и варианта использования. На рисунке между актером администратор и вариантом использования просматривать заказ.
Направленная ассоциация - то же что и простая ассоциация, но показывает, что вариант использования инициализируется актером. Обозначается стрелкой.
Наследование - показывает, что потомок наследует атрибуты и поведение своего прямого предка. Может применяться как для актеров, так для вариантов использования.
Расширение (extend) - показывает, что вариант использования расширяет базовую последовательность действий и вставляет собственную последовательность. При этом в отличие от типа отношений "включение" расширенная последовательность может осуществляться в зависимости от определенных условий.
Включение - показывает, что вариант использования включается в базовую последовательность и выполняется всегда (на рисунке не показан).
Существуют и другие виды взаимодействия, но они, на мой взгляд менее важны и реже применяются.
6. Объектно-ориентированный анализ
На этапе анализа моделируется, что должна делать система.
На этапе проектирования моделируется, как это поведение может быть реализовано.
Основной целью анализа является построение логической модели системы, отражающей что должна предоставлять система для удовлетворения требований пользователя.
Основной целью проектирования является определение в полном объеме того, как будет реализовываться эта функциональность.
Проектная модель базируется на модели анализа и может считаться просто ее улучшенной и уточненной версией.
Предметная область – это область реального мира, в которой возникает необходимость в программной системе (и, следовательно, в деятельности по разработке программного обеспечения).
Обычно это определенная область деловой активности, например сетевая торговля или управление взаимоотношениями с клиентами.
Однако важно отметить, что предметная область может являться физическим оборудованием, для работы которого необходимо программное обеспечение.
Разработка коммерческого программного обеспечения служит некоторой прикладной цели
Например,
автоматизация существующего бизнес-процесса
разработка нового устройства, имеющего существенную программную составляющую.
В модели анализа основное внимание уделяется пониманию проблемы:
выявлению объектов предметной области (ПрО)
выявлению взаимосвязей между ними;
выявлению взаимодействия между ними.
Основные виды работ:
Статическое моделирование
выявление классов;
разделение классов по категориям (структуризация классов)
Динамическое моделирование:
Моделирование динамического взаимодействия между объектами независимого от состояния
Моделирование взаимодействия между объектами зависимого от состояния - на основе машины конечных состояний (конечных автоматов).
Исходные данные для анализа
Бизнес-модель – в распоряжении разработчиков модели может быть (а может и не быть) бизнес-модель моделируемой системы.
Если она уже есть, это превосходный источник требований.
Общие требования к ПО - Спецификация требований к ПО (включает функциональные и не функциональные требования)
Диаграммы и спецификации вариантов использования (прецедентов).
Модель анализа
Все системы разные, поэтому сложно найти универсальный подход к созданию моделей анализа.
Модель анализа системы среднего размера и сложности включает от 50 до 100 классов анализа.
При создании МА важно ограничиться лишь теми классами, которые являются частью словаря предметной области.
часто имеется желание поместить в модель анализа и проектные классы (такие как классы, используемые для установления соединений или доступа к базе данных), но этого необходимо избегать (если только предметная область не касается связи или баз данных)!
МА должна быть кратким, простым описанием структуры и поведения системы.
Все решения по реализации должны приниматься при проектировании и реализации ПС.
Способы создания хорошей МА
МА всегда создается на языке предметной области заказчика.
Абстракции аналитической модели должны формировать часть словаря бизнес-сферы.
Необходимо сосредоточиться на отображении основной картины.
Не надо углубляться в детали того, как будет работать система.
Для этого отводится достаточно времени при проектировании.
Необходимо четко различать
проблемную область (проблемное пространство) и
область решения (компьютерное пространство).
Основное внимание всегда должно быть направлено на абстракции предметной области.
Например, при моделировании системы электронной торговли в аналитической модели должны присутствовать классы Customer (клиент), Order (заказ) и ShoppingBasket (корзина покупок).
Здесь не должно быть классов доступа к базе данных или классов для установления соединений, поскольку они – артефакты области решения.
Всегда необходимо стремиться минимизировать связанность (coupling).
Каждая ассоциация между классами увеличивает их связанность.
Наследование между классами следует применять только в том случае, если присутствует естественная и очевидная иерархия абстракций,
При анализе иерархия не должна применяться для повторного использования кода.
Наследование – самая сильная форма связанности классов.
Модель должна быть полезна для всех заинтересованных сторон.
Не надо создавать модель анализа, которая не понятна пользователям, проектировщикам или разработчиками.
Основные способы достижения этого:
сделать модель анализа и процесс моделирования максимально открытыми,
по возможности привлечь в их выполнение все заинтересованные стороны,
проводить частые и открытые обсуждения.
И, прежде всего, модель должна быть простой!
Это легче сказать, чем сделать, но из опыта специалистов известно, что внутри любой сложной модели анализа можно найти простую.
Один из способов упрощения – рассматривать вопрос в общем, не погружаясь в частности.
7. Построение статистической модели анализа
Статическое моделирование
Разработка ПО начинается с базовой (скелет) структуры приложения, на которую будет навешиваться все остальное.
Предполагается, что данная структура будет относительно стабильной в течении всего жизненного цикла разрабатываемого приложения.
Обычно данная структура называется статической моделью приложения.
При статическом моделировании выявляются базовые элементы – объекты, с их свойствами и взаимосвязями между ними.
Такое абстрагирование объектов из проблемной области потребителя гарантирует стабильную структуру ПО.
Статическая модель подсистемы описывает внутренний скелет, так как разработчик представляет структуру или каркас того содержания, на который внутренне накладывается динамическая модель.
Для выполнения правильной разработки требуется понимание сути того, чем именно являются сущности проблемной области.
Абстракции классов, составляющие статическую модель представляют собой как основу объектно-ориентированного подхода, так и основу содержания проблемной области.
8. Классы анализа. Выявление и описание.
Классы анализа моделируют важные аспекты предметной области.
Например: «банкомат», «клиент», «покупатель» или «продукт».
Классы анализа – это классы, которые:
представляют четкую абстракцию предметной области (problem domain);
должны проецироваться на реальные бизнес-понятия
быть поименованы в соответствии с используемыми в ПО именами этих понятий.
Классы анализа должны четко и однозначно связываться с реальными прикладными понятиями.
Самое важное свойство класса анализа – он должен четко и однозначно проецироваться в некоторое реальное прикладное понятие, например покупатель, продукт или счет.
Это предполагает четкость и однозначность самих бизнес-понятий, что случается редко.
Задача ОО аналитика – попытаться прояснить беспорядочные или несоответствующие прикладные понятия и превратить их в то, что может стать основой для класса анализа.
В это состоит сложность ОО анализа.
Для перехода от класса анализа к классу проектирование:
уточняется и полностью описывается набор атрибутов, включая: имя, тип, видимость и (необязательно) применяемое по умолчанию значение;
уточнить набор операций и полностью описать их, включая имя, список параметров и возвращаемый тип.
Выявление:
На этапах ООА и ООПр не делаются попытки выявить классы напрямую.
Существует несколько концептуальных шагов для получения классов для «Диаграммы классов».
Выявление сущностей ПрП, которые являются кандидатами для разделения рассматриваемого предмета обсуждения.
Отсеивание кандидатов, которые являются избыточными или не релевантными (не относящимися) решаемой проблеме.
Выявление внутренних свойств сущностей ПрП, релевантных решаемой проблеме.
Абстрагирование свойств сущностей в ответственности объектов.
Выявление классов для организации наборов объектов.
Типичными причинами отсеивания сущностей-кандидатов являются:
Они не имеют присущих им свойств, относящихся к рассматриваемой проблеме (шаг 3).
Имеются другие сущности, свойства которых являются более подходящими для решаемой проблемы (шаг 3 и 4).
Практические методы выявления классов
анализ «существительное/глагол».
CRC-анализа.
объектный блиц.
Существительное/глагол
Собираются различные текстовые документы
В документах стараются выделить существительные и глагол.
Существительные и именные группы указывают на классы или атрибуты.
Глаголы и глагольные группы служат признаком обязанностей или операций классов.
Хорошими источниками информации являются:
модель требований;
модель прецедентов;
глоссарий проекта;
различные документы, концепции и т. д.
Выделяются (каким-то способом: вручную, гистограммы встречаемости) следующее:
существительные, например: «рейс»;
именные группы, например: «номер рейса»;
глаголы, например: «разместить»;
глагольные группы, например: «проверить действительность кредитной карточки».
Существительные и именные группы могут служить признаком классов или атрибутов классов.
Глаголы и глагольные группы – обязанностей классов.
Если встретился термин, значение которого осталось непонятным, необходимо проконсультироваться у эксперта в предметной области и добавить этот термин в глоссарий проекта.
CRC-анализ
Очень хорошим способом привлечения пользователей к процессу выявления классов является применение CRC-анализа
CRC – class-responsibilities-collaborators, класс-обязанности-участники.
Этот технический прием использует клеящуюся записку (стикер)!
CRC – это техника мозгового штурма, при которой важные моменты предметной области записываются на стикерах.
Записка делится на три ячейки.
В верхней записывается имя предполагаемого класса, в левой – обязанности, в правой – участники.
Участники – это другие классы, которые могут взаимодействовать с этим классом для реализации функциональности системы.
Ячейка с участниками обеспечивает возможность записи отношений между классами.
Другой способ показать отношения (который мы считаем предпочтительным) – приклеить записки на доску и провести линии между взаимодействующими классами.
CRC анализ выполняется в два этапа
Этап 1: мозговой штурм – сбор информации
Этап 2: анализ информации
Этап 2:
Участники – специалисты по ОО анализу и эксперты ПрО.
Определенные клеящиеся записки будут представлять ключевые бизнес-понятия и, непременно, должны стать классами.
Другие записки могут стать классами или атрибутами.
Если по логике кажется, что записка является частью другой записки, то это верный признак того, что она представляет атрибут.
Кроме того, если записка не кажется особенно важной или не отличается интересным поведением, стоит рассмотреть возможность сделать ее атрибутом другого класса.
Если по поводу записки есть какие-то сомнения, просто сделайте ее классом.
Важно сделать лучшее приближение, а затем довести этот процесс до логического конца.
Всегда можно уточнить модель позже.
Объектный блиц:
Это наиболее общая форма начального формирования Диаграммы Классов при командной разработке.
Он основан на методе достижения консенсуса, который был разработан для поддержки систематического процесса улучшения (например, Общее Управление Качеством использует варианты такого метода).
Обычно объектный блиц выполняется командой, собранной в одной комнате.
Он включает следующие основные шаги:
Сбор сущностей-кандидатов без предубеждения.
Начальное отсеивание
Составление определений
Выполнение очистки
Имеются небольшие вариации, но все они включают такие основные шаги.
1. Сбор сущностей-кандидатов без предубеждения
Участники разработки предлагают имена сущностей в режиме свободного потока сознания.
Они просто записываются (например, в виде списка на одной стороне доски) без обсуждения или предубеждения.
На это тратится от 5 до 10 минут прежде чем закончатся предложения от участников.
2. Начальное отсеивание
Каждый кандидат поочередно рассматривается.
Тот кто изначально предложил его делает короткое (1-3 предложения) пояснение того, что он имел в виду.
Команда кратко обсуждает данную сущность (обычно ограничивается модератором в 1-2 минуты), чтобы определить является ли данный кандидат настолько полезным, как описывается.
Если есть полное согласие (консенсус), что он не является жизнеспособный (релевантным решаемой проблеме), то он отвергается.
Если нет полного согласия отклонить данного кандидата, то он остается кандидатом путем записи его имени на обоих сторонах карточки (карточка, 8 * 13 см.)
3. Составление определений
Для каждого оставшегося кандидата составляется определение.
Обычно лучше передать карточки с этими кандидатами членам команды, которые должны составить для них предварительное определение, которое будет уточняться на дальнейших шагах.
Эти определения должны состоять из 1-3 предложения, которые описывают, что собой представляет данная сущность, без подробностей о том, что она знает и делает.
Лучше всего это должен делать не тот сотрудник, который предложил данную сущность. Т.к. это немедленно покажет новый взгляд на то, что собой данная сущность представляет
4. Выполнение очистки
Каждый кандидат рассматривается поочередно.
Команда оценивает определение и корректирует его до тех пор пока не будет достигнут консенсус.
Целью данной работы является получить общее понимание того, что собой представляет данная сущность и как она связана с решаемой проблемой.
Здесь кандидаты могут быть отвергнуты, если уточнение показало, что они не релевантны решаемой проблеме.
На обсуждение каждого кандидата может затрачиваться по 1-5 минут.
В результате остаются карточки с начальным набором классов для Диаграммы Классов.
Согласно RUP считается полезным поискать классы, которые можно обозначить стереотипами
«boundary» (граница),
«control» (управление) и
«entity» (сущность).
Стереотипами, приведенными в табл., могут быть обозначены три типа классов анализа.
В следующих трех разделах рассматриваются способы выявления каждого из этих типов классов анализа.
9. Моделирование без учёта состояния
При моделировании динамического взаимодействия без учета состояния выполняются следующие основные шаги.
Разработка модели варианта использования.
Определение объектов, которые требуются для реализации данного ВИ.
2a. Определение интерфейсных (граничных) объектов.
2b. Определение внутренних программных объектов.
Определение основной очередности обмена сообщениями (в основной последовательности ВИ).
Определение альтернативной очередности обмена сообщениями.
1. Разработка модели варианта использования
Для динамического моделирования нужно рассмотреть взаимодействие между основным актером и разрабатываемой системой.
Следует помнить, что актер начинает взаимодействие с системой с помощью внешнего устройства ввода.
Система отвечает на введенные данные выполнением некоторых действий, а затем, обычно, предоставляет некоторые выходные данные.
Последовательность ввода данных актером и ответов системы описывается в варианте использования.
Разработка описания такой последовательности взаимодействия начинается с описания основного последовательности ВИ (основного потока событий).
Рассматривается каждое взаимодействие в анализируемой последовательности между актером и системой.
2. Определение объектов, которые требуются для реализации данного ВИ
На данном шаге используются критерии применяемые при структуризации объектов, требуемых для реализации рассматриваемого ВИ.
Выделяются следующие объекты:
интерфейсные (граничные) объекты (шаг 2a);
внутренние программные объекты (шаг 2b).
Шаг 2a: выделение интерфейсных (граничные) объектов
Рассматривается актер (или актеры), участвующие в данном ВИ.
Определяются внешние объекты (внешние для системыe) посредством которых данный актер взаимодействует с системой.
Определяются программные объекты, которые получают данные введенные данным актером.
Начинается рассмотрение данных вводимых внешними объектами в систему.
Для каждого события внешнего ввода данных, рассматриваются программные объекты, которые требуются для обработки данного события.
Определяются требуемые программные интерфейсные объекты (такие, как объекты ввода данных или объекты взаимодействия с пользователем), которые получают входные данных от внешнего объекта.
На основе полученных внешних данных, интерфейсный объект выполняет некоторую процедуру их обработки и обычно отправляет сообщение какому-то внутреннему объекту.
Шаг 2б: выделение внутренних программных объектов
Рассматривается основная последовательность ВИ.
С помощью критерия структуризации объектов выполняется первая попытка определения внутренних программных объектов, которые принимают участие в данном ВИ, таких, как сущностные объекты и управляющие объекты.
3. Определение основной очередности обмена сообщениями
Для каждого события ввода данных от внешнего объекта рассматривается передача сообщений между
интерфейсным объектом, который получает сообщение о вводе данных (input event) и
другими объектами (сущностными и управляющими), которые взаимодействуют между собой для обработки рассматриваемого события.
Рисуется диаграмма взаимодействия, которая показывает объекты, участвующие в данном ВИ и последовательности сообщений между ними.
Данная последовательность обычно
начинается с внешнего ввода данных актером (внешним объектом),
после чего следует последовательность внутренних сообщений между участвующими программными объектами, до вывода данных актеру (внешнему объекту).
Данный процесс повторяется для каждого последующего взаимодействия между актером (или актерами) и системой.
В результате такого описания может потребоваться участие дополнительных объектов и дополнительных обменов сообщениями, для которых должны быть заданы номера очередности их выполнения.
4. Определение альтернативной последовательности обмена сообщениями
Рассматриваются разные альтернативы, такие, как обработка ошибок, которые описываются в разделе «Альтернативный поток событий» в рассматриваемом ВИ.
Затем рассматриваются объекты, которые должны участвовать при выполнении альтернативных ветвей и определяется последовательность сообщений между ними.
10. Конечные автоматы
Конечный автомат - это автомат с конечным числом состояний.
В любой момент времени он находится только в одном состоянии.
Переход состояний - это изменение текущего состояния, вызванное внешним событием.
В ответ на поступившее событие автомат может перейти в новое состояние или остаться в прежнем.
То, в какое состояние перейдет автомат, зависит как от текущего состояния, так и от события.
Побочным результатом перехода в новое состояние иногда бывает выполнение некоторого действия.
Хотя с помощью конечных автоматов можно построить модель всей системы, в объектно-ориентированном анализе и проектировании конечный автомат инкапсулируется в некотором объекте.
Другими словами, этот объект зависит от состояния и всегда находится в одном из состояний, определенных конечным автоматом.
Конечный автомат объекта изображается в виде диаграммы состояний.
В объектно-ориентированной модели зависящие от состояния аспекты системы описываются одним или несколькими конечными автоматами, каждый из которых инкапсулирован в отдельный объект.
Взаимодействие конечных автоматов происходит опосредованно, путем обмена сообщениями между содержащими их объектами (см. главу 1).
11. Динамическое моделирование с учётом состояний
В данном случае речь идет о взаимодействиях между объектами, которые участвуют в прецеденте, зависящем от состояния:
выходные данные, получаемые актером, зависят не только от входных данных, но и от того, что происходило в системе раньше.
В прецеденте, зависящем от состояния, имеется зависящий от состояния управляющий объект, который исполняет свою диаграмму состояний, управляя тем самым последовательностью событий.
В сложных прецедентах таких объектов обычно несколько, и у каждого есть своя диаграмма состояний.
О том, как синтезировать диаграмму состояний по описанию прецедента, рассказывалось в главе 10.
Ниже приводится подробное описание динамического анализа, зависящего от состояния, изложение сопровождается двумя примерами.
В первом примере — Проверить ПИН-код - имеется простая главная последовательность с несколькими альтернативами.
Во втором примере - Круиз-Контроль - главная последовательность будет более сложной.
Сообщение состоит из события и связанных с ним данных.
Если объект, исполняющий некоторую диаграмму состояний, получает сообщение , то событие, которое является его частью вызывает переход состояний.
Выполняемое действие соответствует выходному событию, изображенному на диаграмме коммуникации.
Целью моделирования динамического взаимодействия, учитывающего состояние является определение взаимодействий между следующими объектами:
Управляющим объектом, зависящим от состояния, который выполняет машину состояний.
Объектами (обычно программными интерфейсными), которые отправляют сообщения управляющему объекту.
Эти события вызывают переходы между состояниями во внутренней машине состояний управляющего объекта.
Объектами, которые выполняют действия и деятельности, которые запускаются управляющим объектом в ответ на переход в новое состояние.
Прочими объектами, которые участвуют в реализации данного ВИ.
Взаимодействия между всеми этими объектами показываются на диаграмме коммуникации или последовательности.
Основные шаги динамического анализа, зависящего от состояния, таковы:
Определите интерфейсные объекты.
Для этого выясните, какие объекты получают входные данные от актера.
Укажите зависящий от состояния управляющий объект.
Существует хотя бы один управляющий объект, который исполняет некоторую диаграмму состояний, но могут потребоваться и дополнительные.
Задайте прочие внутренние объекты.
Речь идет о внутренних объектах, которые взаимодействуют с управляющими или интерфейсными объектами.
Проанализируйте кооперации объектов.
Этот шаг следует выполнять вместе с шагом 5, поскольку необходимо детально выяснить взаимодействие между управляющим объектом и диаграммой состояния, которую он исполняет (см. следующий раздел).
Охарактеризуйте исполнение диаграммы состояний.
12. Объектно ориентированное проектирование