«Глава 1. Основные сведения о языке UML Самое лучшее средство – это большая диаграмма, приколотая к стене. Даг Скотт 1.1. Цели и история создания языка UML Унифицированный язык моделирования UML (Unified Modeling ...»

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

График не найден Если во время выполнения подчиненных потоков «Обновить график»

или «Удалить график» система не может найти график студента, то выдается сообщение об ошибке. После того, как студент подтвердит это сообщение, основной поток начнется с начала.

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

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

Удаление отменено Если во время выполнения подчиненного потока «Удалить график»

студент решит не удалять его, удаление отменяется, и основной поток начнется с начала.

Предусловия Перед началом выполнения данного варианта использования студент должен войти в систему.

Постусловия Если вариант использования завершится успешно, график студента будет создан, обновлен или удален. В противном случае состояние системы не изменится.

Вариант использования Close Registration:

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

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

1. Система проверяет состояние процесса регистрации. Если регистрация еще выполняется, выдается сообщение и вариант использования завершается.

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

4. Система закрывает все конкретные курсы. Если в каком-либо конкретном курсе оказывается менее трех студентов (с учетом добавлений, сделанных в п.3), система отменяет его и исключает из каждого содержащего его графика.

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

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

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

Предусловия Перед началом выполнения данного варианта использования регистратор должен войти в систему.

Постусловия Если вариант использования завершится успешно, регистрация закрывается. В противном случае состояние системы не изменится.

Упражнение 5. Прикрепление файла к варианту использования 1. Щелкните правой кнопкой мыши на варианте использования.

2. В открывшемся меню выберите пункт Open Specification 3. Перейдите на вкладку файлов.

4. Щелкните правой кнопкой мыши на белом поле и из открывшегося меню выберите пункт Insert File.

5. Укажите созданный ранее файл и нажмите на кнопку Open, чтобы прикрепить файл к варианту использования.

вариантов использования в браузере примет следующий вид:

Удаление вариантов использования и действующих лиц Существует два способа удалить элемент модели – из одной диаграммы или из всей модели. Чтобы удалить элемент модели из диаграммы:

1. Выделите элемент на диаграмме.

2. Нажмите на клавишу Delete.

3. Обратите внимания, что, хотя элемент и удален с диаграммы, он остался в браузере и на других диаграммах системы.

Чтобы удалить элемент из модели:

1. Выделите элемент на диаграмме.

2. Выберите пункт меню Edit > Delete from Model или нажмите сочетание клавиш CTRL + D.

3.5. Анализ системы 3.5.1. Архитектурный анализ Принятие соглашений по моделированию Включает:

• Используемые диаграммы и элементы модели;

• Правила их применения;

• Соглашения по именованию элементов;

• Организация модели (пакеты).

Пример соглашений моделирования:

• Имена вариантов использования должны быть короткими глагольными фразами.

• Для каждого варианта использования должен быть создан пакет Use-Case Realization, включающий:

§ по крайней мере одну реализацию варианта использования;

§ диаграмму «View Of Participating Classes» (VOPC).

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

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

Реализация варианта использования (Use-Case Realization):

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

Рис. 3.3. Реализация варианта использования Идентификация ключевых абстракций Заключается в предварительном определении классов системы (классов анализа). Источники – знание предметной области, требования к системе, глоссарий. Классы анализа для системы регистрации показаны на рис. 3.4:

Рис. 3.4. Классы анализа системы регистрации Упражнение 6. Создание структуры модели и классов анализа в соответствии с требованиями архитектурного анализа Структура логического представления браузера должна иметь следующий вид:

Создание пакетов и диаграммы Traceabilities:

1. Щелкните правой кнопкой мыши на логическом представлении браузера.

2. В открывшемся меню выберите пункт New > Package 3. Назовите новый пакет Design Model.

4. Создайте аналогичным образом пакеты Use-Case Realizations, UseCase Realization – Close Registration, Use-Case Realization – Login и Use-Case Realization – Register for Courses.

5. В каждом из пакетов типа Use-Case Realization создайте соответствующие кооперации Close Registration, Login и Register for Courses (каждая кооперация представляет собой вариант использования со стереотипом «use-case realization», который задается в спецификации варианта использования).

6. Создайте в пакете Use-Case Realizations новую диаграмму вариантов использования с названием Traceabilities и постройте ее в соответствии с рис. 3.5.

(from Use-Case Realization - Login) (from Use-Case Realization - Register for Courses) (from Use-Case Realization Close Registration) Рис. 3.5. Диаграмма Traceabilities Создание классов анализа и соответствующей диаграммы Key Abstractions:

1. Щелкните правой кнопкой мыши на пакете Design Model.

2. Выберите в открывшемся меню пункт New > Class. Новый класс под названием NewClass появится в браузере.

3. Выделите его и введите имя Student.

4. Создайте аналогичным образом классы Professor, Schedule, Course и CourseOffering.

5. Щелкните правой кнопкой мыши на пакете Design Model.

6. В открывшемся меню выберите пункт New > Class Diagram.

7. Назовите новую диаграмму классов Key Abstractions.

8. Чтобы расположить вновь созданные классы на диаграмме классов, откройте ее и перетащите классы на открытую диаграмму мышью.

Диаграмма классов должна выглядеть как на рис. 3.4.

3.5.2. Анализ вариантов использования Идентификация классов, участвующих в реализации потоков событий варианта использования В потоках событий варианта использования выявляются классы трех типов:

1. Граничные классы (Boundary) – служат посредниками при взаимодействии внешних объектов с системой. Как правило, для каждой пары «действующее лицо – вариант использования»

определяется один граничный класс. Типы граничных классов:

пользователем, без деталей интерфейса – кнопок, списков, окон), системный интерфейс и аппаратный интерфейс (используемые протоколы, без деталей их реализации).

2. Классы-сущности (Entity) – представляют собой ключевые абстракции (понятия) разрабатываемой системы. Источники выявления классов-сущностей: ключевые абстракции, созданные в процессе архитектурного анализа, глоссарий, описание потоков событий вариантов использования.

3. Управляющие классы (Control) – обеспечивают координацию поведения объектов в системе. Могут отсутствовать в некоторых вариантах использования, ограничивающихся простыми манипуляциями с хранимыми данными. Как правило, для каждого варианта использования определяется один управляющий класс.

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

Пример набора классов, участвующих в реализации варианта использования Register for Courses, приведен на рис. 3.6.

Рис. 3.6. Классы, участвующие в реализации варианта использования Register for Courses Упражнение 7. Создание классов, участвующих в реализации варианта использования Register for Courses, и диаграммы классов «View Of Participating Classes» (VOPC) 1. Щелкните правой кнопкой мыши на пакете Design Model.

2. Выберите в открывшемся меню пункт New > Class. Новый класс под названием NewClass появится в браузере.

3. Выделите его и введите имя RegisterForCoursesForm.

RegisterForCoursesForm.

5. В открывшемся меню выберите пункт Open Specification.

6. В поле стереотипа выберите Boundary и нажмите на кнопку ОК.

7. Создайте аналогичным образом классы CourseCatalogSystem со стереотипом Boundary и RegistrationController со стереотипом 8. Назначьте классам Schedule, CourseOffering и Student стереотип 9. Щелкните правой кнопкой мыши на кооперации Register for Courses в пакете Use-Case Realization – Register for Courses.

10.В открывшемся меню выберите пункт New > Class Diagram.

11.Назовите новую диаграмму классов VOPC (classes only).

12.Откройте ее и перетащите классы на открытую диаграмму в соответствии с рис. 3.6.

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

• обработка ошибок;

• контроль времени выполнения;

• обработка неправильных вводимых данных.

Нецелесообразно описывать тривиальные потоки событий (например, в потоке участвует только один объект).

Упражнение 8. Создание диаграмм взаимодействия Создадим диаграммы последовательности и кооперативные диаграммы для основного потока событий варианта использования Register for Courses. Готовые диаграммы последовательности должны иметь вид, как на рис. 3.7 – 3.11.

Выполняется один из трех потоков:

Рис. 3.7. Диаграмма последовательности Register for Courses – Basic Flow :RegisterForCourses :Registration :CourseCatalog Студент хочет создать график занятий Отображается список курсов текущего семестра 7: // select 4 primary and 2 alternate offerings( ) В этой точке выполняется подчиненный поток «Принять график»

Рис. 3.8. Диаграмма последовательности Register for Courses – Basic Flow (Create Schedule) Настройка 1. В меню модели выберите пункт Tools > Options.

2. Перейдите на вкладку диаграмм.

3. Контрольные переключатели Sequence Numbering, Collaboration Numbering должны быть помечены, а Focus of Control – нет.

4. Нажмите ОК, чтобы выйти из окна параметров.

Создание диаграммы последовательности 1. Щелкните правой кнопкой мыши на кооперации Register for Courses в пакете Use-Case Realization – Register for Courses.

2. В открывшемся меню выберите пункт New > Sequence Diagram.

3. Назовите новую диаграмму Register for Courses – Basic Flow.

4. Дважды щелкните на ней, чтобы открыть ее.

Добавление на диаграмму действующего лица, объектов и сообщений 1. Перетащите действующее лицо Student из браузера на диаграмму.

2. Перетащите классы RegisterForCoursesForm и RegistrationController из браузера на диаграмму.

3. На панели инструментов нажмите кнопку Object Message (Сообщение объекта).

4. Проведите мышью от линии жизни действующего лица Student к линии жизни объекта RegisterForCoursesForm.

5. Выделив сообщение, введите его имя: // register for courses.

6. Повторите действия 3 – 5, чтобы поместить на диаграмму остальные сообщения, как показано на рис. 3.7 (для рефлексивного сообщения 3 используется кнопка Message to Self).

: Student 1: // update schedule( ) Студент хочет обновить график Отображается текущий график Выводится список курсов текущего семестра 8: // update offering selections( ) В этой точке выполняется подчиненный поток «Принять график»

Рис. 3.9. Диаграмма последовательности Register for Courses – Basic Flow (Update Schedule) : Student Студент хочет Система запрашивает 5: // request schedule delete confirmation( ) подтверждение 6: // confirm schedule deletion( ) Рис. 3.10. Диаграмма последовательности Register for Courses – Basic Flow (Delete Schedule) Соотнесение сообщений с операциями 1. Щелкните правой кнопкой на сообщении 1, // register for courses.

2. В открывшемся меню выберите пункт. Появится окно спецификации операции.

3. В поле имени оставьте имя сообщения – // register for courses.

4. Нажмите на кнопку ОК, чтобы закрыть окно спецификации операции и вернуться на диаграмму.

5. Повторите действия 1 – 4, пока не соотнесете с операциями все остальные сообщения.

Выполните аналогичные действия для создания диаграмм последовательности, показанных на рис. 3.8 – 3.11. Обратите внимание, что на диаграмме рис. 3.11 появился объект нового класса PrimarySheduleOfferingInfo (класса ассоциаций, описывающего связь между классами Shedule и OfferingInfo), который нужно предварительно создать.

: Student 1: // submit schedule( ) Рис. 3.11. Диаграмма последовательности Register for Courses – Basic Flow (Submit Schedule) Создание примечаний Чтобы поместить на диаграмму примечание:

1. Нажмите на панели инструментов кнопку Note.

2. Щелкните мышью в том месте диаграммы, куда собираетесь поместить примечание.

3. Выделив новое примечание, введите туда текст.

4. Чтобы прикрепить примечание к элементу диаграммы, на панели инструментов нажмите кнопку Anchor Notes To Item (Прикрепить примечания к элементу).

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

Между примечанием и элементом возникнет штриховая линия.

6. Чтобы создать примечание-ссылку на другую диаграмму (как это сделано на диаграмме рис. 3.7 и других), создайте пустое примечание (без текста) и перетащите на него из браузера нужную Кроме примечаний, на диаграмму можно поместить также и текстовую область. С ее помощью можно, например, добавить к диаграмме заголовок.

Чтобы поместить на диаграмму текстовую область:

1. На панели управления нажмите кнопку Text Box.

2. Щелкните мышью внутри диаграммы, чтобы поместить туда текстовую область.

3. Выделив эту область, введите в неё текст.

Создание кооперативной диаграммы Для создания кооперативной диаграммы достаточно открыть диаграмму последовательности и нажать клавишу F5.

Определение обязанностей (responsibilities), атрибутов и ассоциаций классов Обязанность (responsibility) – действие, которое объект обязан выполнять по запросу других объектов. Обязанность преобразуется в одну или более операций класса на шаге проектирования. Обязанности определяются, исходя из сообщений на диаграммах взаимодействия, и документируются в классах в виде операций «анализа», которые появляются там автоматически в процессе построения диаграмм взаимодействия (соотнесения сообщений с операциями).

Так, диаграмма классов VOPC (classes only) (рис. 3.6) после построения диаграмм взаимодействия в упражнении 8 должна принять вид, изображенный на рис. 3.12.

// display course offerings() // confirm schedule deletion() // request schedule delete confirmation() // register for courses() // display possible operations() // save schedule() // create schedule() // select 4 primary and 2 alternate offerings() // display blank schedule() // update offering selections() // get schedule() // get number of students() // any conflicts?() // has pre-requisites() // still open?() Рис. 3.12. Диаграмма классов VOPC (classes only) с операциями «анализа»

о предметной области, требований к системе и глоссария.

Упражнение 9. Добавление атрибутов к классам 1. В меню модели выберите пункт Tools > Options.

2. Перейдите на вкладку Diagram.

3. Убедитесь, что переключатель Show All Attributes помечен.

4. Убедитесь, что переключатели Suppress Attributes и Suppress Operations не помечены.

Добавление атрибутов 1. Щелкните правой кнопкой мыши на классе Student.

2. В открывшемся меню выберите пункт New Attribute.

3. Введите новый атрибут address 4. Нажмите клавишу Enter.

5. Повторите шаги 1 – 4, добавив атрибуты name и studentID.

PrimaryScheduleOfferingInfo, как показано на рис. 3.13.

address name studentID // get tuition() // add schedule() // get schedule() // delete schedule() // has pre-requisites() grade // is selected?() // mark as enrolled in() Рис. 3.13. Классы с операциями «анализа» и атрибутами Связи между классами (ассоциации) определяются на основе диаграмм взаимодействия. Если два объекта взаимодействуют (обмениваются сообщениями), между ними должна существовать связь (путь взаимодействия). Для ассоциаций задаются множественность и, возможно, направление навигации. Могут использоваться множественные ассоциации, агрегации и классы ассоциаций.

Упражнение 10. Добавление связей Добавим связи к классам, принимающим участие в варианте использования Register for Courses. Для отображения связей между классами построим три новых диаграмм классов в кооперации Register for Courses пакета Use-Case Realization – Register for Courses (рис. 3.14 – 3.16).

FulltimeStudent ParttimeStudent Рис. 3.14. Диаграмма Entity Classes (классы-сущности) Добавлены два новых класса – подклассы FulltimeStudent (студент очного отделения) и ParttimeStudent (студент вечернего отделения).

Рис. 3.15. Диаграмма CourseOfferingInfo На данной диаграмме показаны классы ассоциаций, описывающие связи между классами Schedule и CourseOffering и добавлен суперкласс ScheduleOfferingInfo. Данные и операции, содержащиеся в этом классе (status – курс включен в график или отменен), относятся как к основным, так и к альтернативным курсам, в то время как оценка (grade) и окончательное включение курса в график могут иметь место только для основных курсов.

FulltimeStudent ParttimeStudent Рис. 3.16. Полная диаграмма классов VOPC (без атрибутов и операций) Создание ассоциаций Ассоциации создают непосредственно на диаграмме классов. Панель инструментов диаграммы классов содержит кнопки для создания как однотак и двунаправленных ассоциаций. Чтобы на диаграмме классов создать ассоциацию:

1. Нажмите на панели инструментов кнопку Association.

2. Проведите мышью линию ассоциации от одного класса к другому.

Чтобы задать возможности навигации по ассоциации:

1. Щелкните правой кнопкой мыши на связи с того конца, на котором хотите показать стрелку.

2. В открывшемся меню выберите пункт Navigable.

Чтобы создать рефлексивную ассоциацию:

1. На панели инструментов диаграммы нажмите кнопку Association.

2. Проведите линию ассоциации от класса до какого-нибудь места 3. Отпустите кнопку мыши.

4. Проведите линию ассоциации назад к классу.

Создание агрегаций 1. Нажмите кнопку Aggregation панели инструментов.

2. Проведите линию агрегации от класса-части к целому.

Чтобы поместить на диаграмму классов рефлексивную агрегацию:

1. На панели инструментов диаграммы нажмите кнопку Aggregation.

2. Проведите линию агрегации от класса до какого-нибудь места 3. Отпустите кнопку мыши.

4. Проведите линию агрегации назад к классу.

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

Чтобы поместить обобщение на диаграмму классов:

1. Нажмите кнопку Generalization панели инструментов.

2. Проведите линию обобщения от подкласса к суперклассу.

Спецификации связей Спецификации связей касаются имен ассоциаций, ролевых имена, множественности и классов ассоциаций.

Чтобы задать множественность связи:

1. Щелкните правой кнопкой мыши на одном конце связи.

2. В открывшемся меню выберите пункт Multiplicity.

3. Укажите нужную множественность.

4. Повторите то же самое для другого конца связи.

Чтобы задать имя связи:

1. Выделите нужную связь.

2. Введите ее имя.

Чтобы задать связи ролевое имя:

1. Щелкните правой кнопкой мыши на ассоциации с нужного конца.

2. В открывшемся меню выберите пункт role Name.

3. Введите ролевое имя.

Чтобы задать элемент связи (класс ассоциаций):

1. Откройте окно спецификации требуемой связи.

2. Перейдите на вкладку Detail.

3. Задайте элемент связи в поле Link Element.

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

3.6. Проектирование системы 3.6.1. Проектирование архитектуры Цели проектирования архитектуры системы:

• анализ взаимодействий между классами анализа, выявление подсистем и интерфейсов;

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

необходимых для проектирования системы.

Вводятся глобальные пакеты:

• базисные (foundation) классы (списки, очереди и т.д.);

• обработчики ошибок (error handling classes);

• математические библиотеки;

• утилиты;

• библиотеки других поставщиков.

Определяются проектные классы (design classes):

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

• сложный класс анализа может быть разбит на несколько классов, преобразован в пакет или в подсистему.

Примеры возможных подсистем:

• классы, обеспечивающие сложный комплекс услуг (например, обеспечение безопасности и защита);

• граничные классы, реализующие сложный пользовательский интерфейс или интерфейс с внешними системами;

• различные продукты: коммуникационное ПО (middleware, поддержка COM/CORBA), доступ к базам данных, типы и структуры данных (стеки, списки, очереди), общие утилиты (математические библиотеки), различные прикладные продукты.

Принятие решения о преобразовании класса в подсистему определяется опытом и знаниями архитектора проекта.

Соглашения по проектированию интерфейсов:

• Имя интерфейса: короткое (одно-два слова), отражающее его роль • Описание интерфейса: должно отражать его обязанности (размер – небольшой абзац).

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

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

• Класс непосредственно реализует интерфейс и управляет реализацией его операций.

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

Выделение архитектурных уровней:

Application Layer – содержит элементы прикладного уровня (пользовательский интерфейс);

Business Services Layer – содержит элементы, реализующие бизнеслогику приложений (наиболее устойчивая часть системы);

Middleware Layer – обеспечивает сервисы, независимые от платформы.

Пример выделения архитектурных уровней и объединения элементов модели в пакеты для системы регистрации приведен на рис. 3.17.

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

Данное представление отражает следующие решения, принятые архитектором:

• Выделены три архитектурных уровня (созданы три пакета со стереотипом );

• В пакете Application создан пакет Registration, куда включены граничные и управляющие классы;

• Граничный класс CourseCatalogSystem преобразован в подсистему (пакет CourseCatalogSystem со стереотипом ) CourseCatalogSystem, включены еще два пакета: пакет External CourseCatalogSystem (класс ICourseCatalogSystem со стереотипом ), а пакет University Artifacts – все классы-сущности.

Структура и диаграммы пакета (подсистемы) CourseCatalogSystem показана на рис. 3.18 – 3.22.

Рис. 3.18. Структура пакета CourseCatalogSystem (from Business Services) Рис. 3.19. Зависимости между подсистемой и другими пакетами (диаграмма классов CourseCatalogSystem Dependencies) Чтобы поместить зависимость между пакетами на диаграмму классов:

1. Нажмите кнопку Dependency панели инструментов.

2. Проведите линию зависимости от зависимого пакета к тому, от которого он зависит.

Рис. 3.20. Классы, реализующие интерфейс подсистемы (диаграмма классов ICourseCatalogSystem) Класс DBCourseOfferring отвечает за взаимодействие с БД каталога курсов.

CourseCatalog 1: getCourseOfferings(Semester) Retrieve all available course offerings for the current semester Repeat these operations for each element returned from the query.

The CourseOfferingList is loaded with the data retrieved from the database.

The getData and setData operations are called for each attribute in the each retrieved class instance.

Рис. 3.21. Диаграмма последовательности ICourseCatalogSystem::getCourse Offerings, описывающая взаимодействие элементов при реализации операции интерфейса getCourseOfferings CourseCatalog : CourseCatalogSystem : DBCourseOfferring Рис. 3.22. Диаграмма последовательности ICourseCatalogSystem:

:initialize, описывающая взаимодействие элементов при реализации операции интерфейса initialize 3.6.2. Моделирование распределенной конфигурации системы Распределенная конфигурация системы моделируется с помощью диаграммы размещения. Ее основные элементы:

• узел (node) – вычислительный ресурс (процессор или другое устройство (дисковая память, контроллеры различных устройств и т. д.). Для узла можно задать выполняющиеся на нем процессы;

• соединение (connection) – канал взаимодействия узлов (сеть).

Пример: сетевая конфигурация системы регистрации (без процессов).

Рис. 3.23. Сетевая конфигурация системы регистрации Распределение процессов по узлам сети производится с учетом следующих факторов:

• используемые образцы распределения (трехзвенная клиентсерверная конфигурация, «толстый клиент», «тонкий клиент», равноправные узлы (peer-to-peer) и т.д.);

• время отклика;

• минимизация сетевого трафика;

• мощность узла;

• надежность оборудования и коммуникаций.

Пример распределения процессов по узлам приведен на рис. 3.24.

с распределением процессов по узлам Упражнение 11. Создание диаграммы размещения системы регистрации Чтобы открыть диаграмму размещения, надо дважды щелкнуть мышью на представлении Deployment View (представлении размещения) в браузере.

Чтобы поместить на диаграмму процессор:

1. На панели инструментов диаграммы нажмите кнопку Processor.

2. Щелкните на диаграмме размещения в том месте, куда хотите 3. Введите имя процессора.

В спецификациях процессора можно ввести информацию о его стереотипе, характеристиках и планировании. Стереотипы применяются для классификации процессоров (например, компьютеров под управлением UNIX или ПК).

Характеристики процессора – это его физическое описание. Оно может, в частности, включать скорость процессора и объем памяти.

Поле планирования (scheduling) процессора содержит описание того, как осуществляется планирование его процессов:

• Preemptive (с приоритетом). Высокоприоритетные процессы имеют преимущество перед низкоприоритетными.

• Non preemptive (без приоритета). У процессов не имеется приоритета. Текущий процесс выполняется до его завершения, после чего начинается следующий.

• Cyclic (циклический). Управление передается между процессами по кругу. Каждому процессу дается определенное время на его выполнение, затем управление переходит к следующему процессу.

• Executive (исполнительный). Существует некоторый вычислительный алгоритм, который и управляет планированием процессов.

• Manual (вручную). Процессы планируются пользователем.

Чтобы назначить процессору стереотип:

1. Откройте окно спецификации процессора.

2. Перейдите на вкладку General.

3. Введите стереотип в поле Stereotype.

Чтобы ввести характеристики и планирование процессора:

1. Откройте окно спецификации процессора.

2. Перейдите на вкладку Detail.

3. Введите характеристики в поле характеристик.

4. Укажите один из типов планирования.

Чтобы показать планирование на диаграмме:

1. Щелкните правой кнопкой мыши на процессоре.

2. В открывшемся меню выберите пункт Show Scheduling.

Чтобы добавить связь на диаграмму:

1. На панели инструментов нажмите кнопку Connection.

2. Щелкните на узле диаграммы.

3. Проведите линию связи к другому узлу.

Чтобы назначить связи стереотип:

1. Откройте окно спецификации связи.

2. Перейдите на вкладку General.

3. Введите стереотип в поле Stereotype (Стереотип).

Чтобы добавить процесс:

1. Щелкните правой кнопкой мыши на процессоре в браузере.

2. В открывшемся меню выберите пункт New > Process.

3. Введите имя нового процесса.

Чтобы показать процессы на диаграмме:

1. Щелкните правой кнопкой мыши на процессоре.

2. В открывшемся меню выберите пункт Show Processes.

3.6.3. Проектирование классов Классы анализа преобразуются в проектные классы:

• Проектирование граничных классов – зависит от возможностей среды разработки пользовательского интерфейса (GUI Builder);

• Проектирование классов-сущностей – с учетом соображений производительности (выделение в отдельные классы атрибутов с различной частотой использования);

• Проектирование управляющих классов – удаление классов, реализующих простую передачу информации от граничных классов к сущностям;

• Идентификация устойчивых (persistent) классов, содержащих хранимую информацию.

Обязанности классов, определенные в процессе анализа, преобразуются в операции. Каждой операции присваивается имя, характеризующее ее результат. Определяется полная сигнатура операции: operationName(parameter:class,…):returnType. Создается краткое описание операции, включая смысл всех ее параметров. Определяется видимость операции: public, private, protected. Определяется область действия (scope) операции: экземпляр или классификатор.

Определяются (уточняются) атрибуты классов:

(необязательное): attributeName:Type = Default;

• Учитываются соглашения по именованию атрибутов, принятые в проекте и языке реализации;

• Задается видимость атрибутов: public, private, protected;

• При необходимости определяются производные (вычисляемые) Упражнение 12. Определение атрибутов и операций для класса Student Чтобы задать тип данных, значение по умолчанию и видимость атрибута:

1. Щелкните правой кнопкой мыши на атрибуте в браузере.

2. В открывшемся меню выберите пункт Open Specification.

3. Укажите тип данных в раскрывающемся списке типов или введите собственный тип данных.

4. В поле Initial Field (Первоначальное значение) введите значение атрибута по умолчанию.

5. В поле Export Control выберите видимость атрибута: Public, Protected, Private или Implementation. По умолчанию видимость всех атрибутов соответствует Private.

- address : string - nextAvailID : int - studentID : int - dateofBirth : Date + getTuition() : double + addSchedule(theSchedule : Schedule) + getSchedule(forSemester : Semester) : Schedule + deleteSchedule(forSemester : Semester) + hasPrerequisites(forCourseOffering : CourseOffering) : boolean # passed(theCourseOffering : CourseOffering) : boolean + getNextAvailID() : int + getStudentID() : int + getName() : string + getAddress() : string Рис. 3.25. Класс Student с полностью определенными операциями и атрибутами Чтобы изменить нотацию для обозначения видимости:

1. В меню модели выберите пункт Tools > Options.

2. Перейдите на вкладку Notation.

3. Пометьте контрольный переключатель Visibility as Icons, чтобы использовать нотацию Rose, или снимите пометку, чтобы использовать нотацию UML.

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

Чтобы задать тип возвращаемого значения, стереотип и видимость операции:

1. Щелкните правой кнопкой мыши на операции в браузере.

2. Откройте окно спецификации класса этой операции.

3. Укажите тип возвращаемого значения в раскрывающемся списке или введите свой тип.

4. Укажите стереотип в соответствующем раскрывающемся списке или введите новый.

5. В поле Export Control укажите значение видимости операции:

Public, Protected, Private или Implementation. По умолчанию видимость всех операций установлена в public.

Чтобы добавить к операции аргумент:

1. Откройте окно спецификации операции.

2. Перейдите на вкладку Detail.

3. Щелкните правой кнопкой мыши в области аргументов, в открывшемся меню выберите Insert.

4. Введите имя аргумента.

5. Щелкните на колонке Data type и введите туда тип данных 6. Если надо, щелкните на колонке default и введите значение аргумента по умолчанию.

Определение состояний для классов моделируется с помощью диаграмм состояний.

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

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

add student / set count=0 ^CourseRoster.create entry/ Register student exit/ ^CourseRoster.AddStudent(Student) add student[ count < 10 ] Рис. 3.26. Диаграмма состояний для класса CourseOffering Упражнение 13. Создание диаграммы состояний для класса CourseOffering Для создания диаграммы состояний:

1. Щелкните правой кнопкой мыши в браузере на нужном классе.

2. В открывшемся меню выберите пункт New > Statechart Diagram.

Чтобы добавить состояние:

1. На панели инструментов нажмите кнопку State 2. Щелкните мышью на диаграмме состояний в том месте, куда хотите его поместить.

Все элементы состояния можно добавить с помощью вкладки Detail окна спецификации состояния.

Чтобы добавить деятельность:

1. Откройте окно спецификации требуемого состояния.

2. Перейдите на вкладку Detail.

3. Щелкните правой кнопкой мыши на окне Actions.

4. В открывшемся меню выберите пункт Insert.

5. Дважды щелкните на новом действии.

6. Введите действие в поле Actions.

7. В окне When укажите Do, чтобы сделать новое действие деятельностью.

Чтобы добавить входное действие, в окне When укажите On Entry.

Чтобы добавить выходное действие, в окне When укажите On Exit.

Чтобы послать событие:

1. Откройте окно спецификации требуемого состояния.

2. Перейдите на вкладку Detail.

3. Щелкните правой кнопкой мыши на окне Actions.

4. В открывшемся меню выберите пункт Insert.

5. Дважды щелкните на новом действии.

6. В качестве типа действия укажите Send Event.

7. В соответствующие поля введите событие (event), аргументы (arguments) и целевой объект (Target).

Чтобы добавить переход:

1. Нажмите кнопку Transition панели инструментов.

2. Щелкните мышью на состоянии, откуда осуществляется переход.

3. Проведите линию перехода до того состояния, где он завершается.

Чтобы добавить рефлексивный переход:

1. Нажмите кнопку Transition to Self панели инструментов.

2. Щелкните на том состоянии, где осуществляется рефлексивный Чтобы добавить событие, его аргументы, ограждающее условие и действие:

1. Дважды щелкните на переходе, чтобы открыть окно его спецификации.

2. Перейдите на вкладку General.

3. Введите событие в поле Event.

4. Введите аргументы в поле Arguments.

5. Введите ограждающее условие в поле Condition.

6. Введите действие в поле Action.

Чтобы отправить событие:

1. Дважды щелкните на переходе, чтобы открыть окно его спецификации.

2. Перейдите на вкладку Detail.

3. Введите событие в поле Send Event.

4. Введите аргументы в поле Send Arguments.

5. Задайте цель в поле Send Target.

Для указания начального или конечного состояния:

1. На панели инструментов нажмите кнопку Start State или End State.

2. Щелкните мышью на диаграмме состояний в том месте, куда хотите поместить состояние.

Уточнение ассоциаций: некоторые ассоциации (семантические, структурные, устойчивые связи по данным) могут быть преобразованы в зависимости (неструктурные, временные связи, отражают видимость), а агрегации – в композиции.

+ saveSchedule() + getCourseOfferings() : CourseOfferingList + getCurrentSchedule(forStudent : Student, forSemester :

Semester) : Schedule + deleteCurrentSchedule() + getStudent(withID : string) : Student + getTuition() : double + hasPrerequisites(forCourseOffering : CourseOffering) : Artifacts) boolean # passed(theCourseOffering : CourseOffering) : boolean + getNextAvailID() : int + getStudentID():int + getName() : string + getAddress(): string Рис. 3.27. Пример преобразования ассоциаций и агрегаций Чтобы установить преобразовать агрегацию в композицию:

1. Щелкните правой кнопкой мыши на том конце агрегации, который упирается в класс-часть (на рис.3.27 – Schedule).

2. В открывшемся меню выберите пункт Containment.

3. Укажите метод включения By Value.

Примечание. Значение By Value предполагает, что целое и часть создаются и разрушаются одновременно, что соответствует композиции.

Агрегация (By Reference) предполагает, что целое и часть создаются и разрушаются в разное время.

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

Рис. 3.28 Преобразование обобщения 3.6.4. Проектирование баз данных Проектирование реляционных баз данных выполняется с использованием средства Data Modeler. Его работа основана на известном механизме отображения объектной модели в реляционную. Результатом является построение диаграммы «сущность-связь» и последующая генерация описания БД на SQL.

Упражнение 14. Проектирование реляционной базы данных Проектирование БД состоит из следующих шагов:

Создание нового компонента – базы данных:

1. Щелкните правой кнопкой мыши на представлении компонентов.

2. В открывшемся меню выберите пункт Data Modeler > New > 3. Откройте окно спецификации вновь созданного компонента DB_ и в списке Target выберите Oracle 8.x.

Определение устойчивых (persistent) классов:

1. Откройте окно спецификации класса Student в пакете University 2. Перейдите на вкладку Detail.

3. Установите значение переключателя Persistence в Persistent.

4. Проделайте такие же действия для классов Classification, FulltimeClassification и ParttimeClassification.

5. Откройте класс Student в браузере, нажав « + ».

6. Щелкните правой кнопкой мыши на атрибуте studentID.

7. В открывшемся меню выберите пункт Data Modeler > Part of Object Identity (указание атрибута в качестве части первичного ключа).

Примечание. Шаги 5, 6 и 7 можно выполнять в Rational Rose, начиная с версии 2001.

Создание схемы БД:

1. Щелкните правой кнопкой мыши на пакете University Artifacts.

2. В открывшемся меню выберите пункт Data Modeler > Transform to 3. В появившемся окне в списке Target Database укажите DB_0 и нажмите ОК. В результате в логическом представлении появится новый пакет Schemas.

4. Откройте пакет Schemas и щелкните правой кнопкой мыши на 5. В открывшемся меню выберите пункт Data Modeler > New > Data Model Diagram.

6. Откройте пакет, затем откройте вновь созданную диаграмму «сущность-связь» NewDiagram и перенесите на нее все классытаблицы, находящиеся в пакете S_0. Получившаяся диаграмма показана на рис. 3.29.

T_Classification_ID : NUMBER(10, 0) T_Classification_ID : NUMBER(10, 0) + PK_T_FulltimeClassification16() + PK_T_ParttimeClassification17() + FK_T_FulltimeClassification7() + FK_T_ParttimeClassification8() Рис. 3.29. Диаграмма «сущность-связь»

Генерация описания БД на SQL:

1. Щелкните правой кнопкой мыши на пакете S_0.

2. В открывшемся меню выберите пункт Data Modeler > Forward 3. В открывшемся окне мастера Forward Engineering Wizard нажмите 4. Отметьте все флажки генерации DDL и нажмите Next.

5. Укажите имя и расположение текстового файла с результатами генерации и нажмите Next.

6. После завершения генерации откройте созданный текстовый файл и просмотрите результаты.

3.7. Реализация системы 3.7.1. Создание компонентов В Rational Rose диаграммы компонентов создаются в представлении компонентов системы. Отдельные компоненты можно создавать непосредственно на диаграмме, или перетаскивать их туда из браузера.

Упражнение 15. Создание компонентов Выберем в качестве языка программирования С++ и для класса Student создадим соответствующие этому языку компоненты.

Создание диаграммы компонентов:

1. Дважды щелкните мышью на главной диаграмме компонентов в представлении компонентов.

2. На панели инструментов нажмите кнопку Package Specification.

3. Поместите спецификацию пакета на диаграмму.

4. Введите имя спецификации пакета Student и укажите в окне спецификации язык С++.

5. На панели инструментов нажмите кнопку Package Body.

6. Поместите тело пакета на диаграмму.

7. Введите имя тела пакета Student и укажите в окне спецификации 8. На панели инструментов нажмите кнопку Dependency.

9. Проведите линию зависимости от тела пакета к спецификации пакета.

Рис. 3.30. Диаграмма компонентов Соотнесение классов с компонентами:

1. В логическом представлении браузера найдите класс Student.

2. Перетащите этот класс на спецификацию пакета компонента Student в представлении компонентов браузера. В результате класс Student будет соотнесен со спецификацией пакета компонента Student.

3. Перетащите класс Student на тело пакета компонента Student в представлении компонентов браузера. В результате класс Student будет соотнесен с телом пакета компонента Student.

3.7.2. Генерация кода Процесс генерации кода состоит из четырех основных шагов:

1. Проверка корректности модели.

2. Установка свойств генерации кода.

3. Выбор класса, компонента или пакета.

4. Генерация кода.

Для проверки модели:

1. Выберите в меню Tools > Check Model.

2. Проанализируйте все найденные ошибки в окне журнала.

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

С помощью пункта меню Check Model можно выявить большую часть неточностей и ошибок в модели. Пункт меню Access Violations позволяет обнаруживать нарушения правил доступа, возникающие тогда, когда существует связь между двумя классами разных пакетов, но связи между самими пакетами нет.

Чтобы обнаружить нарушение правил доступа:

1. Выберите в меню Report > Show Access Violations.

2. Проанализируйте все нарушения правил доступа в окне.

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

Перед генерацией кода рекомендуется анализировать эти свойства и вносить необходимые изменения.

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

Любые изменения, вносимые в набор свойств в окне Tools > Options, воздействуют на все элементы модели, для которых используется данный набор.

Иногда нужно изменить свойства генерации кода для одного класса, атрибута, одной операции и т.д. Для этого отройте окно спецификации элемента модели. Выберите вкладку языка (C++, Java, …) и измените свойства здесь. Все изменения, вносимые в окне спецификации элемента модели, оказывают влияние только на этот элемент.

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

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

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

Во время генерации кода Rose выбирает информацию из логического и компонентного представлений модели и генерирует большой объем «скелетного» (skeletal) кода:

– Классы. Генерируются все классы модели.

– Атрибуты. Код включает атрибуты каждого класса, в том числе видимость, тип данных и значение по умолчанию.

– Сигнатуры операций. Код содержит определения операций со всеми параметрами, типами данных параметров и типом возвращаемого значения операции.

– Связи. Некоторые из связей модели вызывают создание атрибутов при генерации кода.

соответствующего файла с исходным кодом.

Упражнение 16. Генерация кода С++ 1. Откройте диаграмму компонентов системы.

2. Выберите все объекты на диаграмме компонентов.

3. Выберите Tools > C++ > Code Generation в меню.

4. Выполните генерацию кода.

5. Просмотрите результаты генерации (меню Tools > C++ > Browse Header и Tools > C++ > Browse Body).

Глава 4. Варианты заданий для самостоятельной работы „Нет проблем! Мы можем покончить с этой ерундой за выходные!“ В каждом из предложенных вариантов требуется при помощи CASEсредства Rational Rose построить модель программного обеспечения.

Процесс создания модели должен проходить так, как это описано в главе 3.

Должны быть выполнены следующие действия:

1) составление глоссария проекта;

2) создание модели вариантов использования;

3) анализ вариантов использования;

4) проектирование системы;

5) реализация системы.

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

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

§ создать иерархию классов системы;

§ разместить классы по пакетам (использовать деление:

пользовательский интерфейс – управление – данные; или другое в зависимости от постановки задачи);

§ связать объекты с классами, сообщения на диаграммах взаимодействия – с операциями;

§ каждый класс снабдить описанием, которое должно включать в себя краткое описание (ответственность класса), описание атрибутов в виде таблицы (имя, описание, тип), таблицу с описанием операций (имя, описание, сигнатура);

§ для классов указать стереотипы;

§ построить диаграммы классов системы, отображающие связи между классами;

§ для описания поведения экземпляров отдельных классов построить диаграммы состояний;

§ разработать (если это требуется вариантом задания) схему базы данных и отобразить ее на диаграмме «сущность – связь».

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

Ниже перечислены варианты заданий.

4.1. Цифровой диктофон Требуется разработать средствами Rational Rose модель программного обеспечения, управляющего работой цифрового диктофона.

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

Примерный внешний вид устройства изображен на рисунке 4.1.

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

Исполнителем должна быть разработана схема базы данных для хранения сообщений в памяти диктофона.

Интерфейс с пользователем осуществляется при помощи экранного меню и управляющих кнопок на корпусе диктофона. При помощи кнопокстрелок осуществляется навигация по пунктам меню. Кнопки «Да», «Нет»

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

Во время записи сообщения на экране отображается время, в течение которого ведется запись, при воспроизведении – длительность воспроизведенной части сообщения.

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

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

4.2. Торговый автомат Первый торговый автомат в мире был изготовлен в III веке до нашей эры. Он продавал всем, кто бросал монетку, священную воду в одном египетском храме.

Требуется разработать средствами Rational Rose модель программного обеспечения встроенного процессора универсального торгового автомата.

Рис. 4.2. Лицевая панель торгового автомата Внешний вид автомата изображен на рисунке 4.2. В автомате имеется пять лотков для хранения и выдачи товаров. Загрузка товаров на лотки осуществляется обслуживающим персоналом. Автомат следит за наличием товара. Если какой-либо товар распродан, автомат отправляет сообщение об этом на станцию обслуживания и информирует покупателей (зажигается красная лампочка рядом с лотком данного товара).

Автомат принимает к оплате бумажные купюры и монеты.

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

При нажатии на кнопку «Возврат» клиенту возвращаются все принятые от него к оплате деньги. Возврат денег не производился после выдачи товара. Автомат должен корректно работать при одновременном нажатии на кнопки выдачи товара и возврата денег.

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

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

4.3. Табло на станции метро Требуется разработать средствами Rational Rose модель программного обеспечения табло для информационной службы метрополитена.

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

На табло высвечивается конечная станция назначения прибывающего поезда. Эти данные содержатся в расписании движения поездов, которое хранится в памяти табло и периодически обновляется с ПУ.

В «бегущей строке» табло отображается рекламная информация.

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

Содержание рекламных сообщений поступает с ПУ.

Дополнительная функция табло – по запросу с ПУ оно пересылает данные о нарушениях расписания (преждевременных отправлениях поездов или опозданиях).

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

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

4.4. Система автоматизации для пункта проката видеокассет Требуется разработать средствами Rational Rose модель программной системы автоматизации работы пункта проката видеокассет (далее в тексте – системы).

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

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

При необходимости служащий может запросить у системы следующие данные:

– имеется ли в наличии кассета с данным названием;

– когда будет возвращена какая-либо кассета из тех, что сданы – является ли данный клиент постоянным клиентом пункта проката (пользовался ли прокатом 5 или более раз).

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

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

4.5. Мини-АТС Требуется разработать средствами Rational Rose модель программного обеспечения встроенного микропроцессора учрежденческой мини-АТС (автоматической телефонной станции).

Мини-АТС осуществляет связь между служащими учреждения.

Каждый абонент подключен к ней линией связи. Мини-АТС соединяет линии абонентов (осуществляет коммутацию линий). Абоненты имеют номера, состоящие из трех цифр. Специальный номер 9 зарезервирован для внешней связи.

Телефонное соединение абонентов производится следующим образом.

Абонент поднимает трубку телефона, и мини-АТС получает сигнал «Трубка». В ответ мини-АТС посылает сигнал «Тон». Приняв этот сигнал, абонент набирает телефонный номер (посылает три сигнала «Цифра»).

Мини-АТС проверяет готовность вызываемого абонента. Если абонент не готов (его линия занята), мини-АТС посылает вызывающему абоненту сигнал «Занято». Если абонент готов, мини-АТС посылает обоим абонентам сигнал «Вызов». При этом телефон вызываемого абонента начинает звонить, а вызывающий абонент слышит в трубке длинные гудки. Вызываемый абонент снимает трубку, и мини-АТС получает от него сигнал «Трубка», после чего осуществляет коммутацию линии.

Абоненты обмениваются сигналами «Данные», которые мини-АТС должна передавать от одного абонента к другому. Когда один из абонентов опускает трубку, мини-АТС получает сигнал «Конец» и посылает другому абоненту сигнал «Тон».

В любой момент абонент может положить трубку, при этом мини-АТС получает сигнал «Конец». После получения этого сигнала сеанс обслуживания абонента завершается.

Если абонент желает соединиться с абонентом за пределами учреждения, то он набирает номер «9». Мини-АТС посылает по линии, соединяющей с внешней (городской) АТС, сигнал «Трубка» и в дальнейшем служит посредником между телефоном абонента и внешней АТС. Она принимает и передает сигналы и данные между ними, не внося никаких изменений. Единственное исключение касается завершения сеанса. Получив от городской АТС сигнал «Конец», мини-АТС посылает абоненту сигнал «Тон», и ждет сигнала «Конец» для завершения обслуживания абонента. Если же вызывавший абонент первым вешает трубку, то мини-АТС получает сигнал «Конец», передает его городской АТС и завершает сеанс.

Мини-АТС может получить сигнал «Вызов» от городской АТС. Это происходит, когда нет соединений с внешними абонентами. Сигнал «Вызов» от городской АТС передается абоненту с кодом «000». Только этот абонент может отвечать на внешние звонки.

4.6. Телефон Требуется разработать средствами Rational Rose модель программного обеспечения встроенного микропроцессора для аппарата учрежденческой телефонной сети.

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

В начальном состоянии трубка телефона повешена, телефон не реагирует на нажатия кнопок. Телефон реагирует только на сигнал «Вызов» от мини-АТС, при этом включается звонок.

При снятии трубки на АТС подается сигнал «Трубка». При получении ответного сигнала «Тон» от АТС телефон воспроизводит звуковой тон «Готов» (длинный непрекращающийся гудок) в трубку. При получении сигнала «Занято», в трубке воспроизводится тон «Занято» (частые короткие гудки).

Пользователь, слыша в трубке тон «Готов», набирает трехзначный номер. Номер может быть набран при помощи кнопок с цифрами или нажатием на специальную кнопку « # ». При нажатии на кнопку с цифрой соответствующий ей сигнал «Цифра» передается АТС. Нажатия на кнопки с цифрами после третьего игнорируются. Во время набора номера введенные цифры отображаются на экране. Последний полностью набранный номер запоминается в памяти аппарата для того, чтобы можно было его воспроизвести при нажатии на кнопку « # ». При нажатии на эту кнопку номер из памяти аппарата высвечивается на экране, и АТС передается последовательность из трех сигналов «Цифра». В ответ на набранный номер от АТС приходит либо сигнал «Занято», либо сигнал «Вызов». При получении сигнала «Вызов» телефон воспроизводит в трубку длинные гудки до того момента, когда АТС осуществит коммутацию и передаст сигнал «Данные».

Телефон воспроизводит данные, передаваемые с сигналом, в трубку.

Ответ пользователя воспринимается микрофоном трубки, преобразуется в сигнал «Данные» и передается АТС. Обмен данными прерывается, если повешена трубка одного из телефонов, участвующих в обмене. О том, что трубку повесил вызываемый абонент, сообщает сигнал «Занято», посылаемый АТС. После того, как трубка аппарата была повешена, телефон посылает АТС сигнал «Конец», и телефон переходит в начальное состояние.

4.7. Стиральная машина Требуется разработать средствами Rational Rose модель программного обеспечения встроенного микропроцессора стиральной машины.

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

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

1) Подогревает, если необходимо, воду до нужной температуры.

2) Включает таймер и запускает вращение бака для стирки.

3) По таймеру подает в бак моющие средства, предусмотренные 4) По окончании стирки сливает воду и запускает отжим.

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

4.8. Таксофон Требуется разработать средствами Rational Rose модель встроенной системы управления работой таксофона городской телефонной сети.

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

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

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

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

из линии таксофон воспроизводит звуковой тон «Готов» (длинный непрекращающийся гудок) в трубку. При получении сигнала «Занято», в трубке воспроизводится тон «Занято» (короткие гудки).

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

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

– исчерпан кредит;

– карта вынута из приемника;

– от АТС пришел сигнал «Занято»;

– повешена трубка таксофона.

Если трубка была повешена, аппарат посылает в линию сигнал «Конец» и выдает на дисплей сообщение «Выньте карту».

После извлечения карты из приемника таксофон переходит в начальное состояние.

4.9. Банкомат Если Вы забыли взять свою карточку, то после полутора минут ожидания и неоднократного предупреждения банкомат затягивает карточку внутрь. Не пытайтесь ее самостоятельно достать!!!

Требуется разработать средствами Rational Rose модель программного обеспечения банкомата. Банкомат – это автомат для выдачи наличных денег по кредитным пластиковым карточкам. В его состав входят следующие устройства: дисплей, панель управления с кнопками, приемник кредитных карт, хранилище денег и лоток для их выдачи, хранилище конфискованных кредитных карт, принтер для печати справок.

Банкомат подключен к линии связи для обмена данных с банковским компьютером, хранящим сведения о счетах клиентов.

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

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

Клиент может либо снять наличные со счета, либо узнать остаток на его счету.

При снятии наличных со счета банкомат предлагает указать сумму (10, 50, 100, 200, 500, 1000 рублей). После выбора клиентом суммы банкомат запрашивает, нужно ли печатать справку по операции. Затем банкомат посылает запрос на снятие выбранной суммы центральному компьютеру банка. В случае получения разрешения на операцию, банкомат проверяет, имеется ли требуемая сумма в его хранилище денег.

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

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

По требованию клиента печатается и выдается соответствующая справка.

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

4.10. Холодильник Требуется разработать средствами Rational Rose модель программного обеспечения встроенного процессора холодильника. Холодильник состоит из нескольких холодильных камер для хранения продуктов. В каждой холодильной камере имеется регулятор температуры, мотор, термометр, индикатор, таймер, датчик открытия двери камеры и устройство для подачи звуковых сигналов.

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

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

Холодильник ведет электронный журнал, в котором отмечаются все происходящие события:

– изменение положения терморегулятора камеры;

– включение и отключение мотора;

– доступ в камеру;

– внештатные ситуации.

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

4.11. Кодовый замок Черненька собачка, свернувшись, лежит: ни лает, ни кусает, а в дом не пускает.

Требуется разработать средствами Rational Rose модель программного обеспечения встроенного микропроцессора для кодового замка, регулирующего доступ в помещение.

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

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

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

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

4.12. Турникет метро – Правильно нас называть «Контролер-оператор турникетных автоматов».

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

Требуется разработать средствами Rational Rose модель программного обеспечения встроенного процессора турникета для метрополитена.

При помощи турникета контролируется проход пассажиров в метро и взимается входная плата. Турникет имеет приемник карт, устройство для перекрывания доступа, таймер, три оптических датчика для определения прохода пассажира, устройство подачи звуковых сигналов, индикаторы «Проход» и «Стоп».

В начальном состоянии турникета зажжен индикатор «Стоп», индикатор «Проход» потушен. Если один из датчиков посылает сигнал, то проход через турникет сразу же перекрывается, и подается предупредительный звуковой сигнал. Для прохода пассажир должен поместить карту в приемник карт. Турникет считывает с нее данные: срок годности карты и количество «единиц» на ней. Если данные не удается считать, или карта просрочена, или заблокирована, то карта возвращается пассажиру, и турникет остается в исходном состоянии. В другом случае с карты списывается одна «единица», карта возвращается из приемника, индикатор «Стоп» гаснет, зажигается индикатор «Проход», и пассажир может пройти через турникет. Получив от одного из датчиков сигнал, турникет ожидает время, отведенное на проход пассажира (5 секунд), после чего он возвращается в начальное состояние.

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

Турникет заносит в свою память время всех оплаченных проходов.

В конце рабочего дня он передает всю информацию, накопленную за день, в АСУ метрополитена.

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

4.13. Система учета товаров Требуется разработать средствами Rational Rose модель системы поддержки заказа и учета товаров в бакалейной лавке.

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

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

– список всех товаров;

– список товаров, имеющихся в наличии;

– список товаров, количество которых необходимо пополнить;

– список товаров, поставляемых данным поставщиком.

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

4.14. Библиотечная система Требуется разработать средствами Rational Rose модель системы автоматизирующей деятельность библиотеки.

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

В регистрационном списке читателей хранятся следующие сведения:

фамилия, имя и отчество читателя; номер его читательского билета и дата выдачи билета. Наряду с регистрационным списком системой должен поддерживаться каталог библиотеки, где хранится информация о книгах:

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

– какие книги были выданы за данный промежуток времени;

– какие книги были возвращены за данный промежуток времени;

– какие книги находятся у данного читателя;

– имеется ли в наличии некоторая книга.

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

4.15. Интернет-магазин Требуется разработать средствами Rational Rose модель программного обеспечения Интернет-магазина.

Интернет-магазин позволяет делать покупки с доставкой на дом.

Клиенты магазина при помощи программы-браузера имеют доступ к каталогу продаваемых товаров, поддержку которого осуществляет Интернет-магазин. В каталоге товары распределены по разделам.

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

При отборе клиентами товаров поддерживается виртуальная «торговая корзина». Любое наименование товара может быть добавлено в «корзину» или изъято в любой момент по желанию покупателя с последующим пересчетом общей стоимости покупки. Текущее содержимое «корзины» постоянно показывается клиенту.

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

При выполнении этого варианта задания рекомендуем ознакомиться с работой [Коналлен-2001]. Следует определиться, по какому архитектурному шаблону будет строиться Web-приложение («тонкий клиент» или «толстый клиент»). В соответствии с выбранным шаблоном следует построить модели клиентской части магазина и серверной части, промоделировать связи между частями приложения. Для Web-приложений типичными являются следующие классы:

– клиентская Web-страница;

– серверная Web-страница (например, CGI-скрипт);

– HTML-форма;

– объект JavaScript.

Дополнительные связи между классами Web-приложений:

– link – ссылка с одной страницы на другую;

– build – связь между CGI-скриптом и клиентской страницей, генерируемой при его выполнении;

– submit – связь между формой и серверной Web-страницей, принимающей данные из формы.

Типичные компоненты:

– Web-страница (HTML-файл), – Active Server Page (ASP), – Java Server Page (JSP), – сервлет, – библиотека скриптов (например, подключаемый файл с Javascriptфункциями).

4.16. WWW-конференция Требуется разработать средствами Rational Rose модель программного обеспечения WWW-конференции.

WWW-конференция представляет собой хранилище сообщений в сети Интернет, доступ к которому осуществляется при помощи браузера.

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

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

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

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

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

Вариант задания включает в себя разработку схемы базы данных для хранения сообщений конференции и информации об её участниках.

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

Единственным её элементом, который может выполняться на стороне клиента, является проверка правильного заполнения полей формы, перед отправкой её содержимого на сервер.

4.17. Каталог ресурсов Интернет Требуется разработать средствами Rational Rose модель программного обеспечения каталога ресурсов сети Интернет.

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

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

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

Вариант задания включает в себя разработку схемы базы данных для хранения сообщений конференции и информации об её участниках.

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

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

Требуется разработать средствами Rational Rose модель программного обеспечения встроенного микропроцессора для будильника.

На экране будильника постоянно отображается текущее время (часы и минуты, например: 12 : 00), двоеточие между числом часов и числом минут зажигается и гаснет с интервалом в полсекунды.

Управление будильником осуществляется следующими кнопками:

– кнопкой режима установки времени, – кнопкой режима установки времени срабатывания, – двумя отдельными кнопками для установки часов и минут, – кнопкой сброса сигнала «СБРОС».

со следующими положениями: «ВЫКЛ», «ВКЛ», «РАДИО» и «ТАЙМЕР».

Для установки текущего времени нужно нажать на кнопку режима установки и, при нажатой кнопке, нажимать на кнопки установки часов и минут. При каждом нажатии на кнопки, устанавливаемое значение увеличивается на одну единицу (один час или одну минуту соответственно). При достижении максимального значения производится сброс. Для установки времени срабатывания будильника нужно нажать на кнопку режима установки времени срабатывания и, держа кнопку нажатой, нажимать на кнопки установки часов и минут. Когда переключатель режима работы находится в положении «ВКЛ», при достижении времени срабатывания происходит подача звукового сигнала в течение одной минуты. Сигнал можно прервать, нажав на кнопку «СБРОС». При этом сигнал должен быть возобновлен через пять минут. При установке переключателя в положение «ВЫКЛ» звуковой сигнал не подается.

Когда переключатель находится в положении «РАДИО» работает радиоприемник. При переводе переключателя в положение «ТАЙМЕР»