Сдам Сам

ПОЛЕЗНОЕ


КАТЕГОРИИ







Диаграмма последовательностей.





1) Распознайте на рисунке 1 диаграмму последовательности.

Рисунок 1

Ответ: б.

 

2) Объясните назначение диаграммы последовательностей.

Ответ: Диаграмма последовательностей показывает последовательность, в которой объекты в процессе взаимодействия обмениваются сообщениями.

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

 

3) Охарактеризуйте объекты на рисунке 2 по их именам.

Рисунок 2

Ответ:

о: С – объект с собственным именем о, образуемый на основе класса С;

: С – анонимный объект, образуемый на основе класса С;

о – объект-сирота с собственным именем о;

о / R: С – объект с собственным именем о, образуемый на основе класса С и играющий роль R;

/ R: С – анонимный объект, образуемый на основе класса С и играющий роль R;

о / R – объект-сирота с собственным именем о, играющий роль R;

/ R – анонимный объект-сирота, играющий роль R.

 

 

4) Смоделируйте с помощью диаграммы последовательности сохранение документа в Ms Word.

Ответ:

 

 


Диаграмма классов.

1) Назовите, какие разделы класса показывает графическая нотация.

Ответ: название класса и его родитель, поля и методы, свойства.

 

2) Объясните формат написания методов класса.

Ответ: После того как в модуле описан класс, необходимо описать реализацию всех его методов (если они есть) исключая абстрактные. В языках программирования высокого уровня встречается реализация методов двух видов: inline и outline. Суть первого в том, что мы реализуем метод сразу же после его описания, т.е. прямо в теле класса. При втором методе реализация находиться ниже описания класса в этом же модуле, как сделано в Delphi или вынесена в отдельный файл, как в C++. Inline реализация в стандарте object pascal отсутствует.

Чтобы компилятор понял, к какому классу относится конкретная подпрограмма, перед её названием указывается имя соответствующего класса и точка, т.е. используется уточнение имени. Например, реализуем один метод из листинга 9.5.

 

Листинг 9.6. Пример реализации метода

function TSimpleClass.GetCount: integer;

Begin

result:= self.fV;

end;

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

Доступ к полям и методам объекта происходит с помощью уточненных имен через точку, например: MyClass.Draw(). Кроме того, как и при работе с записями, допустимо использование оператора with, например: with MyClass do Draw().

Обратите внимание, что внутри методов класса обращения к полям и другим методам выполняются как к обычным переменным и подпрограммам без уточнения экземпляра объекта. Такое упрощение достигается путем использования в пределах метода псевдопеременной self (стандартный идентификатор, но его использование не является обязательным). Физически self представляет собой дополнительный неявный параметр, передаваемый в метод при вызове. Напоминаем, что методы класса хранятся в памяти отдельно от объектов и в единственном экземпляре, поэтому чтобы определить какой объект в данный момент должен обрабатывать метод и используется данная переменная. Чтобы пояснить сказанное, напишем отдельный метод SetActive, представив его в виде обычной процедуры (не метода класса) листинг 9.7. При этом нам придётся явно передать экземпляр объекта на обработку в параметре функции, пусть это будет self.

 

 

3) Прокомментируйте отношения между классами на диаграмме классов.

Ответ:

Отношения между классами

Кроме внутреннего устройства или структуры классов на соответствующей диаграмме указываются различные отношения между классами. При этом совокупность типов таких отношений фиксирована в языке UML и предопределена семантикой этих типов отношений. Базовыми отношениями или связями в языке UML являются:

· Отношение зависимости

· Отношение ассоциации

o исключающая ассоциация

o агрегация

o композиция

· Отношение наследования (обобщения generalization relationship)

· Отношение реализации (realization relationship)

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

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

 

Рисунок 11.30 – Графическое изображение отношения зависимости на диаграмме классов

Стрелка может помечаться необязательным, но стандартным ключевым словом в кавычках и необязательным индивидуальным именем. Для отношения зависимости предопределены ключевые слова, которые обозначают некоторые специальные виды зависимостей. Эти ключевые слова (стереотипы) записываются в кавычках рядом со стрелкой, которая соответствует данной зависимости. Примеры стереотипов для отношения зависимости представлены ниже:

· «access» – служит для обозначения доступности открытых атрибутов и операций класса-источника для классов-клиентов;

· «bind» – класс-клиент может использовать некоторый шаблон для своей последующей параметризации;

· «derive» – атрибуты класса-клиента могут быть вычислены по атрибутам класса-источника;

· «import» – открытые атрибуты и операции класса-источника становятся частью класса-клиента, как если бы они были объявлены непосредственно в нем;

· «refine» – указывает, что класс-клиент служит уточнением класса-источника в силу причин исторического характера, когда появляется дополнительная информация в ходе работы над проектом.

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

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

В качестве простого примера отношения бинарной ассоциации рассмотрим отношение между двумя классами – классом «Компания» и классом «Сотрудник» (рис. 11.31). Они связаны между собой бинарной ассоциацией Работа, имя которой указано на рисунке рядом с линией ассоциации. Для данного отношения определен порядок следования классов, первым из которых является класс «Сотрудник», а вторым – класс «Компания».

 

Рисунок 11.31 – Изображение отношения бинарной ассоциации между классами

 

Тернарная ассоциация и ассоциации более высокой арности в общем случае называются N-арной ассоциацией. Такая ассоциация связывает некоторым отношением 3 и более классов, при этом один класс может участвовать в ассоциации более чем один раз. N-арная ассоциация графически обозначается ромбом, от которого ведут сплошные линии к символам классов данной ассоциации. Обычно линии проводятся от вершин ромба или от середины его сторон. Некоторый класс может быть присоединен к ромбу пунктирной линией. Это означает, что данный класс обеспечивает поддержку свойств соответствующей N-арной ассоциации, а сама N-арная ассоциация имеет атрибуты, операции и/или ассоциации. Другими словами, такая ассоциация, в свою очередь, является классом с соответствующим обозначением в виде прямоугольника и является самостоятельным элементом языка UML – ассоциацией-классом (Association Class). N-арная ассоциация не может содержать символ агрегации ни для какой из своих ролей.

 

Рисунок 11.32 – Графическое изображение тернарной ассоциации между тремя классами

 

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

Так, для рассмотренного ранее примера (см. рис. 11.31) кратность "1" для класса «Компания» означает, что каждый сотрудник может работать только в одной компании. Кратность «1..*» для класса «Сотрудник» означает, что в каждой компании могут работать несколько сотрудников, общее число которых заранее неизвестно и ничем не ограничено. Заметим, что вместо кратности «1..*» записать только символ "*" нельзя, поскольку последний означает кратность «0..*». Для данного примера это означало бы, что отдельные компании могут совсем не иметь сотрудников в своем штате. Но такая кратность вполне приемлема в других ситуациях, как это видно из рассмотренного выше примера (рис. 11.32).

Частным случаем отношения ассоциации является так называемая исключающая ассоциация (Xor-association). Семантика данной ассоциации указывает на тот факт, что из нескольких потенциально возможных вариантов данной ассоциации в каждый момент времени может использоваться только один ее экземпляр. На диаграмме классов исключающая ассоциация изображается пунктирной линией, соединяющей две и более ассоциации, рядом с которой записывается строка-ограничение «{хог}». Например, счет в банке может быть открыт для клиента, в качестве которого может выступать физическое лицо (индивидум) или компания, что изображается с помощью исключающей ассоциации (рис. 11.33).

 

Рисунок 11.33 – Изображение исключающей ассоциации между тремя классами

 

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

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

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

Графически отношение агрегации изображается сплошной линией, один из концов которой представляет собой незакрашенный внутри ромб. Этот ромб указывает на тот из классов, который представляет собой «целое». Остальные классы являются его «частями» (рис. 11.34).

 

Рисунок 11.34 – Графическое изображение отношения агрегации в языке UML

 

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

Графически отношение композиции изображается сплошной линией, один из концов которой представляет собой закрашенный внутри ромб. Этот ромб указывает на тот из классов, который представляет собой «целое». Остальные классы являются его «частями» (рис. 11.35).

 

Рисунок 11.35 – Графическое изображение отношения композиции в языке UML

 

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

 

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

 

Рисунок 11.36 – Графическое изображение отношения обобщения в языке UML

 

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

 

Рисунок 11.37 – Вариант графического изображения отношения обобщения классов для случая объединения отдельных линий

 

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

· {complete} – означает, что в данном отношении обобщения специфицированы все классы-потомки, и других классов-потомков у данного класса-предка быть не может;

· {incomplete} – означает случай, противоположный первому. А именно, предполагается, что на диаграмме указаны не все классы-потомки. В последующем возможно восполнить их перечень не изменяя уже построенную диаграмму. Пример – диаграмма класса «Автомобиль», для которой указание всех без исключения моделей автомобилей соизмеримо с созданием соответствующего каталога;

· {disjoint} –запрет множественного наследования;

· {overlapping} – противоположность п.3, означает, что отдельные экземпляры классов-потомков могут принадлежать одновременно нескольким классам.

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

 

Рисунок 11.38 – Вариант графического изображения отношения обобщения классов с использованием строки-ограничения

 

 

4) Преобразуйте приведённую диаграмму так, чтобы в ней присутствовал класс-родитель.

Ответ:

 


Технический проект.

1) Чем различаются техническое задание и технический проект.

Ответ:

 

2) Опишите назначение и требования к техническому проекту.

Ответ:

 

3) Выявите и прокомментируйте неточности в приведённом участке технического проекта.

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

Описание:

1. Открыть проект;

2. Выбрать в меню строку.

Заголовок раздела: основные технические характеристики изделия.

Описание: Разработанная программа должна обладать интуитивно понятным интерфейсом. На форме будут размещаться компоненты.)

Ответ:

1. Инструкции не хватает деталей, вряд ли пользователь решить свою задачу за два простых действия.

2. Раздел должен содержать: планируемое число форм, язык программирования и IDE, примерное число строк программного кода, используемый фреймворк, поддерживаемая ОС, требования к компьютеру.

 

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

Ответ:

 

 


Диаграмма состояний.

1) Назовите причины использования диаграммы состояний.

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

 

2) Как трактуется понятие «автомат».

Ответ: Автомат (state machine) является графом специального вида. В языке UML представляет собой некоторый формализм для моделирования поведения элементов ПО в виде дискретного пространства с конечным числом состояний и переходов. С другой стороны, автомат описывает поведение отдельного объекта в форме последовательности состояний, которые охватывают все этапы его жизненного цикла, начиная от создания объекта и заканчивая его уничтожением. Диаграмма состояний по существу является конечным автоматом.

 

3) Сформируйте перечень элементов с описанием для составления диаграмм состояний.

Ответ:

Состояние (state)

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

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

 

Рисунок 11.58 – Графическое изображение состояний на диаграмме состояний

 

Состояние на диаграмме изображается прямоугольником со скругленными вершинами. Этот прямоугольник, в свою очередь, может быть разделен на две секции горизонтальной линией. Если указана лишь одна секция, то в ней записывается только имя состояния (рис. 11.58а). В противном случае в первой из них записывается имя состояния, а во второй – список некоторых внутренних действий или переходов в данном состоянии (рис. 11.58б). При этом под действием в языке UML понимают некоторую атомарную операцию, выполнение которой приводит к изменению состояния или возврату некоторого значения (например, «истина» или «ложь»).

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

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

 

<метка-действия [/ выражение-действия]>

 

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

Перечень меток действия имеет фиксированные значения в языке UML, которые не могут быть использованы в качестве имен событий. Эти значения следующие:

· entry – действие, специфицированное следующим за ней выражением действия, которое выполняется в момент входа в данное состояние (входное действие);

· exit – эта метка указывает на действие, специфицированное следующим за ней действием, которое выполняется в момент выхода из данного состояния;

· do – эта метка специфицирует деятельность, которая выполняется в течение всего времени, пока объект находится в данном состоянии;

· include – эта метка используется для обращения к подавтомату, при этом следующее за ней выражение действия содержит имя этого подавтомата.

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

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

 

Рисунок 11.59 – Пример состояния с непустой секцией внутренних действий

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

 

Рисунок 11.60 – Графическое изображение начального и конечного состояний

 

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

Переход (transition)

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

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

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

 

<сигнатура события> [<сторожевое условие>] </выражение действия>.

 

При этом сигнатура события описывает некоторое событие с необходимыми аргументами:

 

<имя события> (<список параметров, разделенных запятыми>).

 

Термин событие (event) требует отдельного пояснения, поскольку является самостоятельным элементом языка UML. Формально, событие представляет собой спецификацию некоторого факта, имеющего место в пространстве и во времени. Про события говорят, что они «происходят», при этом отдельные события должны быть упорядочены во времени. Семантика понятия события фиксирует внимание на внешних проявлениях качественных изменений, происходящих при переходе моделируемого объекта из состояния в состояние. Например, после успешного ремонта компьютера также происходит немаловажное событие – восстановление его работоспособности.

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

Сторожевое условие (guard condition) записывается в квадратных скобках после события-триггера и представляет собой некоторое булевское выражение. Напомним, что булевское выражение должно принимать одно их двух взаимно исключающих значений: «истина» или «ложь». Из контекста диаграммы должна явно следовать семантика этого выражения. Если сторожевое условие принимает значение «истина», то соответствующий переход может сработать, в результате чего объект перейдет в целевое состояние. Если же сторожевое условие принимает значение «ложь», то переход не может сработать, и при отсутствии других переходов объект не может перейти в другое состояние. Однако вычисление истинности сторожевого условия происходит только после возникновения, ассоциированного с ним события-триггера. При этом никакие два сторожевых условия не должны одновременно принимать значение «истина».

 

Рисунок 11.61 – Диаграмма состояний для моделирования почтовой программы-клиента

 

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

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

Выражение действия. Выражение действия (action expression) выполняется в том и только в том случае, когда переход срабатывает. Представляет собой достаточно простое вычисление, выполняемое сразу после срабатывания соответствующего перехода до начала каких бы то ни было действий в целевом состоянии. Атомарность действия означает, что оно не может быть прервано никаким другим действием до тех пор, пока не закончится его выполнение. Данное действие может оказывать влияние, как на сам объект, так и на его окружение. Выражение записывается после знака "/" в строке текста, присоединенной к соответствующему переходу.

В общем случае, выражение действия может содержать целый список отдельных действий, разделенных символом ";". Обязательное требование – все действия из списка должны четко различаться между собой и следовать в порядке их записи. На синтаксис записи выражений действия не накладывается никаких ограничений. Главное – их запись должна быть понятна разработчикам модели и программистам.

В качестве примера выражения действия может служить ситуация с выделением графических объектов на экране при однократном нажатии левой кнопки мыши. В этом случае соответствующий переход: "нажата и отпущена левая кнопка мыши (координаты) [координаты в области графического объекта] / выделить объект (цвет).







Живите по правилу: МАЛО ЛИ ЧТО НА СВЕТЕ СУЩЕСТВУЕТ? Я неслучайно подчеркиваю, что место в голове ограничено, а информации вокруг много, и что ваше право...

ЧТО ПРОИСХОДИТ, КОГДА МЫ ССОРИМСЯ Не понимая различий, существующих между мужчинами и женщинами, очень легко довести дело до ссоры...

Что делает отдел по эксплуатации и сопровождению ИС? Отвечает за сохранность данных (расписания копирования, копирование и пр.)...

Что способствует осуществлению желаний? Стопроцентная, непоколебимая уверенность в своем...





Не нашли то, что искали? Воспользуйтесь поиском гугл на сайте:


©2015- 2024 zdamsam.ru Размещенные материалы защищены законодательством РФ.