Курсовая работа.

Цель работы

Целью работы является приобретение навыков проектирования объектно-ориентированных моделей реальных систем.

Объектно-ориентированное проектирование — это методология проек­тирования, соединяющая в себе процесс объектной декомпозиции и приемы представления логической и физической, а также статической и динами­ческой моделей проектируемой системы [Г. Буч].

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

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

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

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

Ключом к написанию хорошей программы является разработка таких классов, чтобы каждый из них представлял одно основное понятие. Обычно это означает, что программист должен сосредоточиться на вопросах: Как создаются объекты этого класса? Могут ли эти объекты копироваться и/или уничтожаться? Какие действия можно производить над этими объектами? Если на такие вопросы нет удовлетворительных ответов, то, во-первых, скорее всего, понятие не было "ясно", и может быть неплохо еще немного подумать над задачей и предлагаемым решением вместо того, чтобы сразу начинать "программировать вокруг" сложностей. [Б.Страуструп]

В процессе проектирования важно установить возможные состояния объектов классов. Например, взлетно-посадочная полоса может быть а) свободной, б) занятой, в) неработоспособной (поврежденной или занесенной снегом). Обитатели зоопарка и аквариума могут быть здоровыми или больными. Трамваи могут быть на линии, в парке или неработоспособными. Методы классов должны переводить объекты из одного состояния в другое или отвечать на вопрос да/нет. Например, диспетчер, отдав разрешение на посадку самолета, тем самым занимает полосу, что соответствует изменению ее состояния. Ветеринар, выявив заболевшее животное, вылечивает его, т.е. переводит объект из состояния “болен” в состояние “здоров”. Буксир(объект) переводит судно (объект) из состояния “на рейде” в состояние “у причала”. Диспетчер, контролируя воздушную зону над аэропортом, или метеоролог, контролирующий атмосферу, выдают однозначные ответы: “зона свободна/занята” или “ясно/шторм”, что позволяет корректировать последующие действия.

Давайте посмотрим, как, например, смоделировать пожар в супермаркете. У вас в системе должен быть класс «Здание» с полями площадь, двери(открыты/закрыты), покупатели(есть/нет) и т. п. Добавим в класс поле «Датчик» (включен/выключен) и метод «Проверка на задымление». Этот метод можно включать регулярно, но если датчик выключен, то он ничего не делает. Если датчик включился, то метод переводит объект класса «Охрана» в состояние «Пожарная тревога». После этого охранники должны распахнуть все двери здания и освободить его от посетителей, т.е. метод класса «Охрана» изменяет состояния соответствующих полей здания.

Каким образом должна функционировать программа?

Модель должна иметь некий управляющий класс – монитор (например, класс главного окна в Windows-приложении), в число методов которого входит инициализация модели (создание соответствующих объектов) и посылка сообщений на выполнение обычных операций. Они могут быть запущены нажатием кнопки на панели диалога: одна кнопка – одно или группа сообщений. Более интересным является решение, в котором моделируется некоторый временной отрезок функционирования реальной системы – например, рабочий день в аэропорту или осенний сезон в оранжерее. Здесь методы должны запускаться монитором автоматически в заданной последовательности через некоторые, возможно, случайные промежутки времени.

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

Программа может быть написана на С++ или на С#. Графика не обязательна – можно делать и консольные проекты.

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

Наличие содержательного пояснения - необходимое условие получения хорошей оценки.

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

Критерии оценки:

1. Соответствие содержания программы заданию.

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

3. Наличие ее описания.

4. Самостоятельность работы – как минимум, полное знание текста программы – отговорка «Делал месяц назад и уже забыл» не принимается.

5. Отсутствие аналогичной программы среди ранее сданных.

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

Курсовая работа по дисциплине

«Объектно-ориентированное программирование»

Модель аэропорта.