Главная страница Случайная страница
Разделы сайта
АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника
⚡️ Для новых пользователей первый месяц бесплатно. А далее 290 руб/мес, это в 3 раза дешевле аналогов. За эту цену доступен весь функционал: напоминание о визитах, чаевые, предоплаты, общение с клиентами, переносы записей и так далее.
✅ Уйма гибких настроек, которые помогут вам зарабатывать больше и забыть про чувство «что-то мне нужно было сделать».
Сомневаетесь? нажмите на текст, запустите чат-бота и убедитесь во всем сами!
Упражнения. 1. Предположим, что есть две пересекающиеся улицы с двусторонним движением, светофорами и пешеходными переходами
|
|
1. Предположим, что есть две пересекающиеся улицы с двусторонним движением, светофорами и пешеходными переходами. Нужно создать виртуальную модель, чтобы определить, позволит ли изменение частоты подачи сигнала светофора сделать дорожное движение более равномерным.
Какие объекты и какие классы потребуются для имитации этой ситуации?
Автомобили, мотоциклы, грузовики, велосипеды, пешеходы и спецмашины — все используют этот перекресток. Кроме того, существует еше светофор, регулирующий движение по перекрестку.
Нужно ли включать в модель покрытие дороги? Безусловно, качество дороги может оказывать существенное влияние на движение транспорта, однако для упрощения начального варианта модели лучше пока исключить из рассмотрения этот фактор.
Первым объектом, вероятно, будет сам перекресток. Возможно, объект перекрестка будет управлять списками автомобилей, ожидающих зеленого сигнала светофора в каждом направлении, а также списками пешеходов, ожидающих возможности пройти по переходу. Для этого объекта потребуются методы, позволяюшие выбирать, какие автомобили и пешеходы пересекут этот перекресток и в каком количестве.
Поскольку рассматривается только один перекресток, нужно позаботиться о том, чтобы в программе допускалось создание только одного экземпляра этого объекта (подсказка: вспомните о статических методах и защищенном доступе к членам).
Как пешеходы, так и автомобили являются клиентами перекрестка. Они обладают некоторыми общими характеристиками. Например, могут появляться в любое время, могут отсутствовать вообще и могут ожидать сигнала светофора (хотя и на различных линиях). Эта " общность" является предпосылкой того, что стоит рассмотреть общий базовый класс для пешеходов и автомобилей.
Следовательно, в модель перекрестка необходимо включить такие классы:
class Entity; // клиент перекрестка
// базовый класс для всех автомобилей, грузовиков, велосипедов и спецмашин
class Vehicle: Entity...;
// базовый класс для пешеходов
class Pedestrian: Entity...;
class C.; r: public Vehicle...;
class Truck. public Vehicle...;
class Motorcycle: public Vehicle...;
class Bicycle: public Vehicle...;
class Emergency_Vehicle: public Vehicle...;
// класс списка автомобилей и людей, ожидающих движения
class Intersection;
2. Усложним ситуацию из упражнения 1. Предположим, что есть три вида водителей: таксисты, переезжающие переход на красный свет; иногородние, которые едут медленно и осторожно; и частники, которые ведут машины по-разному, в зависимости от представлений о своей " крутизне".
Также есть два вида пешеходов: местные, которые переходят улицу, где им заблагорассудится, и туристы, которые переходят улицу только на зеленый свет.
А кроме того, есть еше велосипедисты, которые ведут себя то как пешеходы, то как водители.
Как эти соображения изменят модель?
Вероятно, целесообразно начать с создания производных объектов, которые моделируют разновидности рассмотренных выше объектов:
class Local_Car: public Car...;
class Tourist_Car: public Car...;
class Taxi: public Car...;
class Local_Pedestrian: public Pedestrian...;
classTourist_Pedestrian: public Pedestrian...;
class Local_Bicycle. public Bicycle...;
Используя виртуальные методы, для объектов разных классов можно модифицировать общее поведение в соответствии с особенностями этих объектов. Например, местный водитель может реагировать на красный сигнал светофора не так, как турист, но в остальном наследовать общее поведение своего класса.
3. Вам заказали программу планирования времени конференций и встреч, а также бронирования мест в гостинице для визитеров компании и для участников конференций. Определите главные подсистемы.
Для этого проекта нужно написать две отдельные программы: программу-клиент, которую будут запускать пользователи, и программу-сервер, которая будет работать на отдельном компьютере. Кроме того, компьютер клиента должен иметь административный компонент, позволяющий системному администратору добавлять новых людей и новые помещения.
Если вы решили реализовать этот проект в виде модели типа клиент/сервер, то программа-клиент должна принимать данные, веодимые пользователем, и генерировать запрос к программе-серверу. Сервер должен обслужить запрос и отправить результаты назад клиенту. С помощью этой модели многие участники конференции смогут одновременно планировать свои встречи.
На стороне клиента (помимо административного модуля) существует две основные подсистемы: интерфейс пользователя и система связей. На стороне сервера — три основные подсистемы: связей, планирования и почтового интерфейса, который объявляет пользователю об изменениях в расписании.
4. Спроектируйте интерфейсы к классам той части программы, обсуждаемой в упражнении 3, которая относится к резервированию гостиничных номеров.
Для организации конференции или деловой встречи необходимо зарезервировать помещение на определенное время. Этим занимается организационный комитет, который должен знать конкретное время проведения встречи и список участников.
В качестве объектов, вероятно, следует определить всех возможных пользователей системы, а также все имеющиеся залы заседаний и номера гостиниц. Не забудьте также включить для календаря и класс Meeting, который инкапсулирует все, что известно о конкретной встрече или конференции.
Приведем прототипы перечисленных выше классов.
class Calendar_Class; // ссылка на класс
class Meeting, // ссылка на класс
class Configuration
{
public:
Configuration();
~Configuration();
Meeting Schedule(ListOfPerson&, Oelta Time duration);
Meeting Schedule(ListOfPerson&, Delta Time duration, Time);
Meeting Schedule(ListOfPerson&, Delta Time duration, Room);
ListOfPerson& People(); // открытые методы доступа
ListOfRoom& Rooms(); // открытые методу доступа
protected:
ListOfRoom rooms;
ListOfPerson people;
};
typedef long Room_ID;
class Room
{
public:
Room(String name, Room_ID id, int capacity. String directions description = " ");
~Room();
Calendar_Class Calendar();
protected:
Calendar_Class calendar;
int capacity;
Room_ID id;
String name;
String directions; // где этот гостиничный номер?
String description;
};
typedef long Person_ID;
class Person
{
public:
Person (String name, Person_ID id);
~Person();
Calendar_Class Calendar(); // место доступа для добавления встреч
protected:
Calendar_Class calendar;
Person_ID id;
String name;
};
class Calendar_Class
{
public:
Calendar_Class();
~Calendar_Class();
void Add(const Meeting&); // добавляем встречу в календарь
void Delete(const Meeting&);
Meeting* Lookup(Time); // проверяем, не назначена ли уже встреча на это чис-
Block(Time, Duration, String reason = " ");
// резервируем время...
protected:
OrderedListOfMeeting meetings;
};
class Meeting
{
public:
Meeting(ListOfPerson&, Room room, Time when, Duration duration, String purpose = " ");
~Meeting();
protected:
ListOfPerson people;
Room room;
Time when;
Duration duration;
String purpose;
};
|
|