Писание процесса проектирования ПК.

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

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

Диаграмма классов представляет собой некоторый граф, вершинами которого являются элементы типа "классификатор", которые связаны различными типами структурных отношений. Следует заметить, что диаграмма классов может также содержать интерфейсы, пакеты, отношения и даже отдельные экземпляры, такие как объекты и связи. Когда говорят о данной диаграмме, имеют в виду структурную статическую модель проектируемой системы. Поэтому диаграмму классов принято считать графическим представлением таких структурных взаимосвязей логической модели системы, которые не зависят или инвариантны от времени. Диаграмма классов состоит из множества элементов, которые в совокупности отражают декларативные знания о предметной области. Эти знания интерпретируются в базовых понятиях языка UML, таких как классы, интерфейсы и отношения между ними и их составляющими компонентами. При этом отдельные компоненты этой диаграммы могут образовывать пакеты для представления более общей модели системы. Если диаграмма классов является частью некоторого пакета, то ее компоненты должны соответствовать элементам этого пакета, включая возможные ссылки на элементы из других пакетов. В общем случае пакет структурной статической модели может быть представлен в виде одной или нескольких диаграмм классов. Декомпозиция некоторого представления на отдельные диаграммы выполняется с целью удобства и графической визуализации структурных взаимосвязей предметной области. При этом компоненты диаграммы соответствуют элементам статической семантической модели. Модель системы, в свою очередь, должна быть согласована с внутренней структурой классов, которая описывается на языке UML [http://khpi-iip.mipk.kharkiv.edu/library/case/leon/index.html]. На диаграмме 1, представленной ниже, указана диаграмма классов ПК.

Диаграмма 1 - Диаграмма классов объектной модели ПК

Диаграмма действий.

При моделировании поведения проектируемой или анализируемой системы возникает необходимость не только представить процесс изменения ее состояний, но и детализировать особенности алгоритмической и логической реализации выполняемых системой операций. Традиционно для этой цели использовались блок-схемы или структурные схемы алгоритмов. Каждая такая схема акцентирует внимание на последовательности выполнения определенных действий или элементарных операций, которые в совокупности приводят к получению желаемого результата. Алгоритмические и логические операции, требующие выполнения в определенной последовательности, окружают нас постоянно. Важно подчеркнуть то обстоятельство, что с увеличением сложности системы строгое соблюдение последовательности выполняемых операций приобретает все большее значение. Для моделирования процесса выполнения операций в языке UML используются так называемые диаграммы деятельности. Применяемая в них графическая нотация во многом похожа на нотацию диаграммы состояний, поскольку на диаграммах деятельности также присутствуют обозначения состояний и переходов. Отличие заключается в семантике состояний, которые используются для представления не деятельностей, а действий, и в отсутствии на переходах сигнатуры событий. Каждое состояние на диаграмме деятельности соответствует выполнению некоторой элементарной операции, а переход в следующее состояние срабатывает только при завершении этой, операции в предыдущем состоянии. Графически диаграмма деятельности представляется в форме графа деятельности, вершинами которого являются состояния действия, а дугами - переходы от одного состояния действия к другому. Таким образом, диаграммы деятельности можно считать частным случаем диаграмм состояний. Именно они позволяют реализовать в языке UML особенности процедурного и синхронного управления, обусловленного завершением внутренних деятельностей и действий. Метамодель UML предоставляет для этого необходимые термины и семантику. Основным направлением использования диаграмм деятельности является визуализация особенностей реализации операций классов, когда необходимо представить алгоритмы их выполнения. При этом каждое состояние может являться выполнением операции некоторого класса либо ее части, позволяя использовать диаграммы деятельности для описания реакций на внутренние события системы. В контексте языка UML деятельность (activity) представляет собой некоторую совокупность отдельных вычислений, выполняемых автоматом. При этом отдельные элементарные вычисления могут приводить к некоторому результату или действию (action). На диаграмме деятельности отображается логика или последовательность перехода от одной деятельности к другой, при этом внимание фиксируется на результате деятельности. Сам же результат может привести к изменению состояния системы или возвращению некоторого значения [http://khpi-iip.mipk.kharkiv.edu/library/case/leon/index.html].Диаграммах 2, 3 раскрыты действия для методов DlgRooms::OnAddR() и DlgClients::OnAddC().

Диаграмма 2 - Диаграмма действий, раскрытая для метода

добавления комнаты

Диаграмма 3 - Диаграмма действий, раскрытая для метода

поселения проживающего

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

В языке UML взаимодействие элементов рассматривается в информационном аспекте их коммуникации, т. е. взаимодействующие объекты обмениваются между собой некоторой информацией. При этом информация принимает форму законченных сообщений. Другими словами, хотя сообщение и имеет информационное содержание, оно приобретает дополнительное свойство оказывать направленное влияние на своего получателя. Любые виды информационного взаимодействия между элементами системы должны быть сведены к отправке и приему сообщений между ними. Для моделирования взаимодействия объектов в языке UML используются соответствующие диаграммы взаимодействия. Говоря об этих диаграммах, имеют в виду два аспекта взаимодействия. Взаимодействия объектов можно рассматривать во времени, и тогда для представления временных особенностей передачи и приема сообщений между объектами используется диаграмма последовательности. Однако временной аспект поведения может иметь существенное значение при моделировании синхронных процессов, описывающих взаимодействия объектов. Именно для этой цели в языке UML используются диаграммы последовательности. На диаграмме последовательности изображаются исключительно те объекты, которые непосредственно участвуют во взаимодействии и не показываются возможные статические ассоциации с другими объектами. Для диаграммы последовательности ключевым моментом является именно динамика взаимодействия объектов во времени. При этом диаграмма последовательности имеет как бы два измерения. Одно - слева направо в виде горизонтальных линий, каждая из которых изображает линию жизни отдельного объекта, участвующего во взаимодействии. Второе измерение диаграммы последовательности - вертикальная временная ось, направленная сверху вниз. Начальному моменту времени соответствует самая верхняя часть диаграммы. При этом взаимодействия объектов реализуются посредством сообщений, которые посылаются одними объектами другим. Сообщения изображаются в виде горизонтальных стрелок с именем сообщения и также образуют порядок по времени своего возникновения. Другими словами, сообщения, расположенные на диаграмме последовательности выше, инициируются раньше тех, которые расположены ниже. При этом масштаб на оси времени не указывается, поскольку диаграмма последовательности моделирует лишь временную упорядоченность взаимодействий типа "раньше-позже".

Линия жизни объекта (object lifeline) изображается пунктирной вертикальной линией, ассоциированной с единственным объектом на диаграмме последовательности. Линия жизни служит для обозначения периода времени, в течение которого объект существует в системе и, следовательно, может потенциально участвовать во всех ее взаимодействиях. Если объект существует в системе постоянно, то и его линия жизни должна продолжаться по всей плоскости диаграммы последовательности от самой верхней ее части до самой нижней [http://khpi-iip.mipk.kharkiv.edu/library/case/leon/index.html].Диаграмма 4 представляет действия для метода DlgEmpl::OnAddE().

Диаграмма 4 - Диаграмма последовательностей, раскрыта

для метода добавления служащего

DlgEmpl – объект класса диалогового окна CDialog.

CEmpl – объект класса «служащие».

Use Case – диаграмма.

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

- Определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы.

- Сформулировать общие требования к функциональному поведению проектируемой системы.

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

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

Суть данной диаграммы состоит в следующем: проектируемая система представляется в виде множества сущностей или актеров, взаимодействующих с системой с помощью так называемых вариантов использования. При этом актером (actor) или действующим лицом называется любая сущность, взаимодействующая с системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая может служить источником воздействия на моделируемую систему так, как определит сам разработчик. В свою очередь, вариант использования (use case) служит для описания сервисов, которые система предоставляет актеру. Другими словами, каждый вариант использования определяет некоторый набор действий, совершаемый системой при диалоге с актером. При этом ничего не говорится о том, каким образом будет реализовано взаимодействие актеров с системой. Рассматривая диаграмму вариантов использования в качестве модели системы, можно ассоциировать ее с моделью черного ящика". Действительно, подробная детализация данной диаграммы на начальном этапе проектирования скорее имеет отрицательный характер, поскольку предопределяет способы реализации поведения системы. А согласно рекомендациям именно эти аспекты должны быть скрыты от разработчика на диаграмме вариантов использования. В самом общем случае, диаграмма вариантов использования представляет собой граф специального вида, который является графической нотацией для представления конкретных вариантов использования, актеров, возможно, некоторых интерфейсов, и отношений между этими элементами. При этом отдельные компоненты диаграммы могут быть заключены в прямоугольник, который обозначает проектируемую систему в целом. Следует отметить, что отношениями данного графа могут быть только некоторые фиксированные типы взаимосвязей между актерами и вариантами использования, которые в совокупности описывают сервисы или функциональные требования к моделируемой системе [http://khpi-iip.mipk.kharkiv.edu/library/case/leon/index.html].На диаграмме 5 изображены функциональные характеристики ПК.

Диаграмма 5 - Use Case –диаграмма, представляющая

функциональные характеристики ПК

Описание интерфейса.

Внешний вид главного диалогового окна, выглядит таким образом (рис.1):

Рисунок 1 - Главное диалоговое окно

Таблица 1 Конструкция главного диалогового окна.

Наименование элемента формы	Тип элемента формы	Действие пользователя	Отклик системы
“Проживающие”	кнопка	одинарный щелчок левой кнопкой мыши	открытие диалогового окна «Проживающие»
“Номера”	кнопка	одинарный щелчок левой кнопкой мыши	открытие диалогового окна «Номера»
“Служащие”	кнопка	одинарный щелчок левой кнопкой мыши	открытие диалогового окна «Служащие»
“Отчет”	кнопка	одинарный щелчок левой кнопкой мыши	открытие диалогового окна «Отчет»
“Выход”	кнопка	одинарный щелчок левой кнопкой мыши	завершение работы с программой

Нажатие на кнопку «Проживающие» приводит к появлению следующего диалогового окна.

Рисунок 2 - Диалоговое окно для просмотра сведений о проживающих

Таблица 2 Конструкция диалогового окна для просмотра сведений о проживающих

Наименование элемента формы	Тип элемента формы	Действие пользователя	Отклик системы
«Фио», «Паспорт», «Номер», «Заселение», «Выселение»	статическая надпись	---------------------	---------------------
“Добавить”	кнопка	одинарный щелчок левой кнопкой мыши	Открытие диалогового окна ввода проживающего
“Удалить”	кнопка	одинарный щелчок левой кнопкой мыши	удаление выбранного проживающего из списка
“Выход”	кнопка	одинарный щелчок левой кнопкой мыши	Закрытие диалогового окна и сохранение данных в файл
Список	Список	двойной щелчок правой кнопкой мыши	открытие окна добавления проживающего в котором можно изменить сведения выбранного проживающего

Нажатие на кнопку «Добавить» приводит к появлению следующего диалогового окна.

Рисунок 3 - Диалоговое окно для добавления/изменения проживающего.

Таблица 3. Конструкция диалогового окна добавления проживающего

Наименование элемента формы	Тип элемента формы	Действие пользователя	Отклик системы
«Фио», «Паспорт», «Занимаемый Номер», «Заселение», «Выселение», «Номер», «Тип», «Занято», «Цена»	статическая надпись	---------------------	---------------------
“EditBox1”	окно для ввода текста	одинарный щелчок левой кнопкой мыши	появление I-курсора на месте клика в EditBox1
“EditBox2”	окно для ввода текста	одинарный щелчок левой кнопкой мыши	появление I-курсора на месте клика в EditBox2
“DataTime Picker1”	окно для ввода даты	одинарный щелчок левой кнопкой мыши	появление I-курсора на месте клика в DataTime Picker1
“DataTime Picker2”	окно для ввода даты	одинарный щелчок левой кнопкой мыши	появление I-курсора на месте клика в DataTime Picker2
List Box	Список	------------------	----------------------
“Ok”	кнопка	одинарный щелчок левой кнопкой мыши	Сохранение проживающего и закрытие окна
“Cancel”	кнопка	одинарный щелчок левой кнопкой мыши	Отмена ввода и закрытие окна

Варианты заданий для курсовой работы

Разработать программный комплекс (ПК) на объектно-ориентированном языке для автоматизации предприятия связи.

ариант 1

АТС обслуживает 16 номеров, из которых 4 номера 3 категории, 4 – 2 категории, 8 номеров – 1 категории. Спроектировать работу АТС, предусмотреть возможность редактирования информации в справочнике, поиск по ключевому слову для любого поля, вывод информации в виде отчета. Отчет должен содержать следующую информацию: класс обслуживания, номер абонента, фамилию, дату разговора, время разговора, сумму для оплаты, отсортированную по адресу абонента. Составить запрос для подсчета вызовов каждой категории и построить диаграмму работы абонентов каждой категории.

Справочные данные:

1 категория – бюджетные организации;

2 категория - коммерческие организации;

3 категория – физические лица без льгот

4 категория - физические лица, имеющие льготы

ариант 2

АТС обслуживает 16 номеров, из которых 2 номера 3 категории, 8 номеров – 2 категории, 6 номеров – 1 категории. Спроектировать работу АТС, предусмотреть возможность редактирования информации в справочнике, поиск по ключевому слову для любого поля, вывод информации в виде отчета. Отчет должен содержать следующую информацию: класс обслуживания, номер абонента, фамилию, дату разговора, время разговора, сумму для оплаты, сгруппированную по категориям. Составить запрос для подсчета стоимости разговоров абонентов каждой категории и построить диаграмму стоимости разговоров каждой категории АТС

ариант 3

АТС обслуживает 16 номеров, из которых 8 номеров 3 категории, 4 номера – 2 категории, 4 номера – 1 категории. Спроектировать работу АТС, предусмотреть возможность редактирования информации в справочнике, поиск по ключевому слову для любого поля, вывод информации в виде отчета. Отчет должен содержать следующую информацию: класс обслуживания, номер абонента, фамилию, дату разговора, время разговора, сумму для оплаты, сгруппированную по датам. Составить запрос для подсчета числа вызовов каждого абонента и построить диаграмму работы абонентов 1 категории.

ариант 4

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

Справочные данные:

1. Распределение абонентов:
доля абонентов квартирного сектора 70%;
доля абонентов народно-хозяйственного сектора 26%;
количество таксофонов 4%.

2. Доля состоявшихся разговоров – 60% (если разговор не состоялся то Dt взять равным 10 секунд)

ариант 5

Имеется междугородный канал связи, который днем загружен в среднем на 70%, а ночью на 20% (сгенерировать нагрузку на канал). Канал поочередно занимается абонентами. Исследовать работу канала в течении нескольких суток. Определить двузначный код (ab) вызываемого города (8-2ab-XXXXX), предварительно сформировав таблицу кодов (не более 10), назначить поминутный тариф на этот код ночной и дневной, а также вычислить плату за разговор, вывести график – рейтинг или таблицу наиболее приносящих прибыль городов. Время одного разговора может колебаться от одной минуты до 30 минут.

Справочные данные:

1. Распределение абонентов:
доля абонентов квартирного сектора 70%;
доля абонентов народно-хозяйственного сектора 26%;
количество таксофонов 4%.

2. Доля состоявшихся разговоров – 60% (если разговор не состоялся то Dt взять равным 10 секунд)

ариант 6

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

Справочные данные:

1. Распределение абонентов по категориям:
доля абонентов квартирного сектора 80%;
доля абонентов народно-хозяйственного сектора 15%;
количество таксофонов 5%.

2. Доля состоявшихся разговоров – 70% (если разговор не состоялся, то Dt взять равным 10 секунд)

ариант 7

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

Справочные данные:

1. Распределение абонентов:
доля абонентов квартирного сектора 60%;
доля абонентов народно-хозяйственного сектора 30%;
количество таксофонов 10%.

2. Доля состоявшихся разговоров – 60% (если разговор не состоялся, то Dt взять равным 10 секунд)

ариант 8

Спроектировать работу междугородней телефонной станции.

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

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

ариант 9

Имеется междугородный канал связи, который днем загружен в среднем на 80%, а ночью на 10% (сгенерировать нагрузку на канал). Канал поочередно занимается абонентами. Исследовать работу канала в течении нескольких суток. Определить двузначный код (ab) вызываемого города (8-2ab-XXXXX), предварительно сформировав таблицу кодов (не более 10), назначить поминутный тариф на каждый код ночной и дневной, а также вычислить плату за разговор, вывести график – рейтинг или таблицу наиболее загруженных городов в дневное время (в ночное время). Вывести 10 наиболее разговорчивых абонентов,

Справочные данные:

1. Распределение абонентов:
доля абонентов квартирного сектора 70%;
доля абонентов народно-хозяйственного сектора 26%;
количество таксофонов 4%.

2. Доля состоявшихся разговоров – 60% (если разговор не состоялся то Dt взять равным 10 секунд)

ариант 10

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

Литература

1. Кьоу Дж. Объектно-ориентированное программирование : учеб. курс : Питер, 2005

2. Лафоре Р. Объектно-ориентированное программирование в С++ Object-Oriented Programming in C++ .- 4-е изд.- СПб.: Питер, 2008

3. Павловская Т. А.Объектно - ориентированнное программирование. Практикум : учеб. пособие для вузов /.- СПб.: Питер, 2008