Программирование в C++ Преподаватель Колотова Людмила Павловна

ТРПП (технология разработки программного продукта) 2 Разработка объектно-ориентированного ПО Эволюция процесса создания программного обеспечения Моделирование вариантов использования Предметная область программирования Программа LANDLORD: стадия развития От вариантов использования к классам Написание кода Взаимодействие с программой

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

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

Эволюция процесса создания программного обеспечения 5 Современные подходы. Они определяют последовательность действий и способы взаимодействия заказчиков, постановщиков задач, разработчиков и программистов. На сегодняшний день ни один язык моделирования не обладает той универсальностью, каковая присуща UML. В качестве примера современного метода разработки ПО рассмотрим основные черты подхода, которому мы дадим название Унифицированный процесс.

Эволюция процесса создания программного обеспечения 6 Унифицированный процесс разбивается на четыре этапа: начало; развитие; построение; передача. На начальной стадии выявляются общие возможности будущей программы и ее осуществимость. Фаза оканчивается одобрением руководства проекта. На этапе развития планируется общая архитектура системы. Именно здесь определяются требования пользователей. На стадии построения осуществляется планирование отдельных деталей системы и пишется собственно код. В фазе внедрения система представляется конечным пользователям, тестируется и внедряется. Все четыре фазы могут быть разбиты на ряд так называемых итераций. В частности, этап построения состоит из нескольких итераций. Каждая из них является подмножеством всей системы и отвечает определенным задачам, поставленным заказчиком. Каждая итерация включает в себя свою собственную последовательность этапов анализа, планирования, реализации и тестирования. Итерации могут повторяться несколько раз.

Эволюция процесса создания программного обеспечения 7 Целью итерации является создание работающей части системы. В отличие от водопадного, унифицированный процесс дает возможность вернуться на более ранние стадии разработки. Например, замечания, сделанные пользователями на стадии передачи, должны быть учтены, что приводит к пересмотру фазы построения и, возможно, фазы развития. Следует отметить, что рассматриваемая концепция Унифицированного процесса может быть применена к любым типам программной архитектуры, а не только к проектам, в которых используются объектно-ориентированные языки. На самом деле, наверное, как раз слабой стороной этого подхода является не очень-то активное использование ООП. Фаза развития обычно за основу берет технологию вариантов использования (use case). Это отправная точка детальной разработки системы. По этой причине Унифицированный процесс называют прецедентным. Далее мы обсудим эту технологию, а затем применим ее к проекту, взятому нами в качестве примера.

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

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

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

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

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

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

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

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

От вариантов использования к классам 16 Когда определены все действующие субъекты и варианты использо- вания, процесс разработки плавно переходит из фазы развития в фазу построения программы. Это означает, что наметилась тенден- ция некого сдвига в сторону разработчиков от пользователей. С этого момента их тесное сотрудничество прекращается, поскольку они начинают говорить на разных языках. Первой проблемой является создание и развитие классов, которые будут входить в программу. Одним из подходов к именованию клас- сов является использование имен существительных, встречающихся в кратких описаниях вариантов использования. Мы хотим, чтобы объекты классов программы соответствовали объектам реального мира, и эти существительные как раз являются именами тех сущнос- тей, которые указал нам заказчик. Они являются кандидатами в классы, но, право слово, не из всех существительных могут полу- читься приемлемые классы.

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

Предметная область программирования 18 Программа, которую мы будем создавать в нашем примере, называется LANDLORD (Домовладелец). Необходимо представить себе те данные, с которыми домовладельцу приходится работать: плата за жилье и расходы. Вот такой незамысловатый бизнес. Его мы и будем описывать в нашей программе. Представьте, что вы являе- тесь независимым экспертом по домовладельцам и C++, и к вам пришел заказчик Печкин. Печкин – мелкий собственник, в его веде- нии находится здание, состоящее из 12 комнат, которые он сдает. Он хочет, чтобы вы написали программу, которая упростила бы его нелегкий труд по регистрации данных и распечатыванию отчетов о своей финансовой деятельности. Если вы сможете договориться с Печкиным о цене, сроках и общем предназначении программы, можете считать, что вы включились в процесс разработки ПО. Стадия Начало

Рукописные формы 19 На данный момент Печкин записывает всю информацию о своем доме вручную в старомодный гроссбух. Он показывает вам, какие формы используются для ведения дел: 1. список жильцов; 2. доходы от аренды; 3. расходы; 4. годовой отчет. 1. В Списке жильцов содержатся номера комнат и имена съемщиков, проживающих в них. Таким образом, это таблица из двух столбцов и 12 строк. 2. Доходы от аренды. Здесь хранятся записи о платежах съемщиков. В этой таблице содержится 12 столбцов (по числу месяцев) и по одной строке на каждую сдаваемую комнату. Вся- кий раз, получая деньги от жильцов, Печ- кин записывает заплаченную сумму в соот- ветствующую ячейку таблицы. Такая таб- лица наглядно показывает, какие суммы кем внесены. Стадия Начало

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

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

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

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

Действующие субъекты 24 Вначале нужно определить, кто будет являться действующими субъектами. Кто будет вводить информацию? Кто будет запрашивать? Будет ли кто-либо еще взаимодействовать с программой? Будет ли сама программа взаимодействовать с другими? В примере LANDLORD с программой работает только один человек: домовладелец. Таким образом, один и тот же человек вводит информацию и просматривает ее в разных видах. Даже в таком небольшом проекте можно представить себе еще каких-то действующих лиц. Это может быть счетовод, а сама наша программа может стать действующим субъектом, обращаясь к компьютерной системе налоговой службы. Для простоты мы не будем включать эти возможности в проект. Стадия Развития

Варианты использования 25 Следующей группой, которую нужно описать, является группа дейст- вий, которые будет инициировать действующий субъект. В реальном проекте это может стать довольно объемной задачей, требующей длительного обсуждения и уточнения деталей. Здесь все не так сложно, составим список вариантов использования, которые могут возникнуть при работе нашей програм- мы. Варианты использования отображе- ны на диаграмме. Домовладельцу потре- буется выполнять следующие действия: 1. начать работу с программой; 2. доба- вить нового жильца в список; 3. ввести значение арендной платы в таблицу доходов от аренды; 4. ввести значение в таблицу расходов; 5. вывести список жильцов; 6. вывести таблицу доходов от аренды; 7. вывести таблицу расходов; 8. вывести годовой отчет. Стадия Развития

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

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

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

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

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

От вариантов использования к классам 31 Фаза построения начинается тогда, когда мы переходим к планиро- ванию структуры программы. Выберем классы. Для этого просмот- рим список существительных из описаний вариантов использования. Список существительных (см. описания вариантов использования) 1. Экран интерфейса пользователя. 2. Жилец. 3. Экран ввода жильцов. 4. Имя жильца. 5. Номер комнаты. 6. Строка жильца. 7. Список жильцов. 8. Арендная плата. 9. Экран ввода арендной платы. 10. Месяц. 11. Сумма арендной платы. 12. Таблица доходов от аренды. 13. Строка арендной платы. Стадия Построения

От вариантов использования к классам 32 Фаза построения начинается тогда, когда мы переходим к планиро- ванию структуры программы. Выберем классы. Для этого просмот- рим список существительных из описаний вариантов использования. Список существительных (см. описания вариантов использования) Стадия Построения 1. Экран интерфейса пользователя. 2. Жилец. 3. Экран ввода жильцов. 4. Имя жильца. 5. Номер комнаты. 6. Строка жильца. 7. Список жильцов. 8. Арендная плата. 9. Экран ввода арендной платы. 10. Месяц. 11. Сумма арендной платы. 12. Таблица доходов от аренды. 13. Строка арендной платы. 14. Расход. 15. Экран ввода расходов. 16. Получатель. 17. Размер платежа. 18. День. 19. Бюджетная категория. 20. Строка в таблице расходов. 21. Таблица расходов. 22. Годовой отчет. 23. Суммарная арендная плата. 24. Суммарные расходы по категориям 25. Баланс.

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

От вариантов использования к классам 34 Уточнение списка Строка арендной платы, с другой стороны, содержит сведения о номере комнаты и массив из 12 платежей за аренду по месяцам. Она отсутствует в таблице до тех пор, пока не будет сделан первый взнос в текущем году. Последующие платежи вносятся в уже существующие строки. Это ситуация более сложная, чем с жильцами и расходами, поэтому, так и быть, сделаем строку арендной платы классом. Тогда класс арендной платы как таковой не будет содержать ничего, кроме суммы платежа, поэтому это существительное превращать в класс мы не станем. Программа может порождать значения в годовом отчете из таблицы арендной платы и таблицы расходов, поэтому, наверное, не стоит сумму арендных платежей, а также суммарные расходы по категориям и баланс делать отдельными классами. Они являются просто результатами вычислений. Стадия Построения

От вариантов использования к классам 35 Итак, составим список классов, которые мы с вами придумали. 1. Экран пользовательского интерфейса. 2. Жилец. 3. Экран ввода жильцов. 4. Список жильцов. 5. Экран ввода арендной платы. 6. Таблица доходов от аренды. 7. Строка таблицы доходов от аренды. 8. Расход. 9. Экран ввода расходов. 10. Таблица расходов. 11. Годовой отчет. Стадия Построения Определение атрибутов Многие существительные, которым отказано в регистрации в кандидаты классов, будут кандидатами в атрибуты классов. Например, у класса Жильцы будут такие атрибуты: Имя жильца, Номер комнаты. У класса Расходы: Получатель, Месяц, День, Сумма, Бюджетная категория. Другие атрибуты определим далее.

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

От глаголов к сообщениям 37 В сообщении содержится указание вывести самого себя на экран. Несложно догадаться, что метод может называться, например, display(). Глагол «состоит» не относится ни к какому сообщению. Он просто примерно определяет состав строки объекта Список жильцов. Рассмотрим более сложный пример: вариант использования Добавить нового жильца: На экране должно отобразиться сообщение, в котором программа просит пользователя ввести имя жильца и номер комнаты. Эта информация должна заноситься в таблицу. Лист автоматически сортируется по номерам комнат. Глагол «отобразиться» в данном случае будет обозначать следую- щее. Экран пользовательского интерфейса должен послать сообще- ние классу «экран ввода жильцов», приказывая ему вывести себя и получить данные от пользователя. Это сообщение может быть вызо- вом метода класса с именем, например getTenant(). Глаголы «про- сит» и «ввести» относятся к взаимодействию класса «экран ввода жильцов» с пользователем. Они не становятся сообщениями в объектном смысле. Стадия Построения

От глаголов к сообщениям 38 Просто-напросто getTenant() выводит приглашение и записывает ответы пользователя (имя жильца и номер комнаты). Глагол «заноситься» означает, что объект класса Экран ввода жильцов посылает сообщение объекту класса Список жильцов. Возможно, в качестве аргумента используется новый объект класса Жильцы. Объект Список жильцов может затем вставить этот новый объект в свой список. Эта функция может иметь имя типа insertTenant(). Глагол «сортируется» это никакое не сообщение и вообще не вид взаимодействия объектов. Это просто описание списка жильцов. Стадия Построения

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

От глаголов к сообщениям 40 Например, нигде не говорится о создании объекта Жилец. Тем не менее, наверное, понятно, что Список Жильцов содержит объекты типа Жилец, а последние должны быть созданы до их внесения в список. Итак, системный инженер решает, что метод getTenant() класса «экран ввода жильцов» это подходящее место для создания объекта Жилец, вставляемого в список жильцов. Все прочие варианты использования должны быть проанализированы аналогичным образом, чтобы можно было создать основу для связывания классов. Обратите внимание, что мы все еще используем имена классов, совпадающие со словами или словосочетаниями вариантов использования. Когда мы начнем писать код, нам, конечно, придется переименовать их во что-либо более приемлемое (имена должны состоять из одного слова). Стадия Построения

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

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

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

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

Диаграмма последовательностей для варианта использования Начать программу 45 Допустим, программа создает единственный объект класса под названием theUserInterface. Именно этот объект порождает все варианты использования. Он появляется слева на диаграмме после- довательностей. (Как видите, мы на этом этапе уже перешли к нор- мальным именам классов, принятым при написании кода.) Когда вступает в работу объект theUserInterface, первое, что он делает, он создает три основные структуры данных в программе. Это объекты классов TenantList, rentRecord и ExpenceRecord. Получается, что они рождаются безымянными, так как для их создания используется new. Имена имеют только указатели на них. Как же нам их назвать? К счастью, как мы убедились на примере объектных диаграмм, UML предоставляет несколько способов именования объектов. Если на- стоящее имя неизвестно, можно использовать вместо него двоето- чие с именем класса (:tenantList). На диаграмме подчеркивание имени и двоеточие перед ним напоминает о том, что мы имеем дело с объектом, а не с классом. Стадия Построения

Диаграмма последовательностей для варианта использования Начать программу 46 Вертикальная позиция прямоугольника с именем объекта указывает на тот момент времени, когда объект был создан (первым создается объект класса tenantList). Все объекты, которые вы видите на диа- грамме, продолжают существовать все время, пока программа стоит на исполнении. Шкала времени, строго говоря, рисуется не в масшта- бе – она предназначена только лишь для того, чтобы показать взаи- мосвязь различных событий. Горизонтальные линии представляют собой сообщения (то есть вызовы методов). Сплошная стрелочка го- ворит о нормальном синхронном вызове функции. Прямоугольник, расположенный под theUserInterface, называется блоком активнос- ти (или центром управления). Он показывает, что расположенный над ним объект является активным. В обычной процедурной програм- ме, такой, как наша (LANDLORD), «активный» означает, что метод данного объекта либо исполняется сам, либо вызвал на исполнение другую функцию, которая еще не завершила свою работу. Три других объекта на этой диаграмме не являются активными, потому что theUserInterface еще не послал им активизирующих сообщений. Стадия Построения

Диаграмма последовательностей для варианта использования Вывод списка жильцов 47 Возвращения значений функ- циями показаны прерывис- тыми линиями. Обратите внимание: объекты активны только тогда, когда вызван какой-либо их метод. Сверху над линией сообщения мо- жет быть указано имя вызы- ваемого метода. Объект theUserInterface дает зада- ние объекту tenantList вы- вести себя на экран, а тот, в свою очередь, выводит все объекты класса tenant. Фра- за в квадратных скобках [для всех объектов tenant] сооб- щает условие повторения. Стадия Построения

Диаграмма последовательностей для варианта использования Добавить нового жильца 48 Сюда мы включили самого домовладельца в виде объек- та, который определяет раз- личные действия. У него есть свой собственный блок актив- ности. С помощью этого объе- кта можно очень хорошо по- казать процесс взаимодей- ствия пользователя с про- граммой. Пользователь сооб- щает программе, что он же- лает добавить нового жильца. Объект theUserInterface создает новый объект класса tenantInputScreen. Стадия Построения

Диаграмма последовательностей для варианта использования Добавить нового жильца 49 Объект theUserInterface создает новый объект класса tenantInputScreen. В этом объекте есть методы, позволяющие получить от пользователя данные о жильце, создать новый объект типа tenant и вызвать метод объекта класса tenantList для добавления в список вновь созданного жильца. Когда все это проделано, объект tenantInputScreen удаляется. Большая буква «X» в конце линии жизни tenantInputScreen говорит о том, что объект удален. Диаграммы последовательностей, примеры которых мы здесь привели, имеют дело только с главными сценариями каждого варианта использования. Существуют, конечно же, способы показать на диаграммах и несколько сценариев, но можно и для каждого сценария создать свою диаграмму. Стадия Построения

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

Заголовочный файл 51 Мы добрались до написания таких родных и привычных файлов с кодами. Лучше всего начинать с заголовочного (.H) файла, в кото- ром следует определить только интерфейсные части классов, но не подробности реализации. Как говорилось ранее, объявления в заголовочном файле – это общедоступная часть классов. Тела функций расположены в.cpp-файлах, называются реализацией и пользователям недоступны. Написание заголовочного файла – это промежуточный шаг между планированием и обыкновенным кодированием методов. Рассмотрим содержимое заголовочного файла LANDLORD.H. Стадия Построения –вторая часть

Листинг 1. Заголовочный файл к программе LANDLORD 52 Стадия Построения –вторая часть

Объявления классов 53 Объявлять классы – это просто. Большинство объявлений вырастают напрямую из классов, созданных с помощью взятых из описаний вариантов использования существительных, и отображаются на диаграмме классов. Только лишь имена нужно сделать однословными из многословных. Например, имя Список жильцов (Tenant List) превращается в TenantList. В заголовочном файле было добавлено еще несколько вспомогательных классов. Впоследствии окажется, что мы храним указатели на объекты в разных типах контейнеров STL. Это означает, что мы должны сравнивать объекты этих контейнеров, как описано в главе «Стандартная библиотека шаблонов (STL)». Объектами сравнения на самом деле являются классы compareTenants, compareRows, compareDates и compareCategories. Стадия Построения –вторая часть

Описания атрибутов 54 Как уже было замечено выше, многие атрибуты (методы) для каждого из классов вырастают из тех существительных, которые сами не стали классами. Например, name и aptNumber стали атрибутами класса tenant. Прочие атрибуты могут быть выведены из ассоциаций в диаграмме классов. Ассоциации могут определять те атрибуты, которые являются указателями или ссылками на другие классы. Это объясняется невозможностью ассоциировать что-то с чем-то, что находится неизвестно где. Таким образом, у класса rentInputScreen появляются атрибуты ptrTenantList и ptrRentRecord. Стадия Построения –вторая часть

Составные значения (агрегаты) 55 Агрегатные связи показаны в трех местах на диаграмме классов. Обычно агрегаты выявляют те контейнеры, которые являются атрибутами агрегирующего класса (то есть «целого» класса, содержащего «части»). Ни по описаниям вариантов использования, ни по диаграмме классов невозможно угадать, какого рода контейнеры должны использоваться для этих агрегатов. Вам как программистам придется самим всякий раз выбирать подходя- щий контейнер для каждого составного значения будь то прос- той массив, контейнер STL или что-либо еще. В программе LANDLORD мы сделали такой выбор: класс tenantlist содержит STL-множество указателей на объекты класса tenant; класс rentRecord содержит множество указателей на объекты класса rentRow; класс expenseRecord содержит вектор указателей на объекты класса expense. Стадия Построения –вторая часть

Составные значения (агрегаты) 56 Для tenantlist и rentRecord мы выбрали множества, так как основным параметром является быстрый доступ к данным. Для expenseRecord выбран вектор, потому что нам важно осуществлять быструю сортировку и по дате, и по категории, а векторы позволяют сортировать данные наиболее эффективно. Во всех агрегатах мы предпочли хранить указатели вместо самих объектов, чтобы избежать излишнего копирования данных в памяти. Хранение самих объектов следует применять в тех случаях, когда объектов мало и они небольшие. Конечно, большой разницы в скорости на примере каких-то 12 экземпля- ров объекта мы не увидим, но в принципе об эффективности метода хранения данных следует задумываться всегда. Стадия Построения –вторая часть

Исходные.cpp файлы 57 В исходных файлах содержатся тела методов, которые были объявлены в заголовочном файле. Написание кода этих методов должно начинаться только на этом этапе разработки и ни шагом раньше, потому что только сейчас мы знаем имя каждой функции, ее предназначение и даже, возможно, можем предугадать аргументы, передаваемые ей. Мы разделили модули: main() храним в одном коротеньком файле LORDAPP.CPP, а определения функций, объявленных в заголовочном файле, в другом. В секции main() создается объект userInterface и вызывается метод interact(). Приведем файл, в котором хранится main(). Стадия Построения –вторая часть

Листинг 2. Программа LORDAPP.CPP 58 // lordApp.cpp // файл, поставляемый клиенту. #include "landlord.h" int main() { userInterface theUserInterface; theUserInterface.interact(); return 0; } ////////////////////конец файла lordApp.cpp//////////////// Стадия Построения –вторая часть

Листинг 3. Программа LANDLORD.CPP 59 Стадия Построения –вторая часть

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

Взаимодействие с программой 61 Мы прошли огонь и воду – спланировали и написали программу. Теперь интересно было бы пройти и медные трубы – посмотреть нашу программу «на ходу». Вот подходит к компьютеру Печкин и нажимает «i», а затем «t» для ввода нового жильца. После соот- ветствующих запросов программы (в скобках в конце запроса обычно пишут формат данных) он вводит информацию о жильце. Стадия Передача – внедрение Нажмите 'i' для ввода данных. 'd' для вывода отчета 'q' для выхода: i Нажмите 't' для добавления жильца 'r' для записи арендной платы 'e' для записи расходов: t Введите имя жильца (Дядя Федор): Кот Матроскин Введите номер комнаты: 101

Взаимодействие с программой 62 После ввода всех жильцов домовладелец пожелал просмотреть их полный список (для краткости ограничимся пятью жильцами из двенадцати): Стадия Передача – внедрение Нажмите 'i' для ввода данных. 'd' для вывода отчета 'q' для выхода: d Нажмите 't' для вывода жильцов 'r' для вывода арендной платы 'e' для вывода расходов 'a' для вывода годового отчета: t Apt #Имя жильца Кот Матроскин 102 Пес Шарик 103 Дядя Федор 104 Корова Мурка 201 Птица Говорун

Взаимодействие с программой 63 Для фиксации внесенной арендной платы домовладелец Печкин, нажимает вначале «i», затем «r» (далее мы не будем повторять пункты меню в примерах работы программы). Дальнейшее взаимодействие с программой протекает следующим образом: Стадия Передача – внедрение Введите имя жильца: Пес Шарик Введите внесенную сумму (345.67): 595 Введите месяц оплаты (1 -12); 5 Пес Шарик послал домовладельцу чек оплаты за май в размере 595. (Имя жильца должно быть напечатано так же, как оно появлялось в списке жильцов. Более умная программа, возможно, дала бы более гибкое решение этого вопроса.)

Взаимодействие с программой 64 Чтобы увидеть всю таблицу доходов от аренды помещений, нужно нажать «d», а затем «r». Вот каково состояние таблицы после внесения майской арендной платы: Стадия Передача – внедрение Apt No Янв Фев Мар Апр Май Июн Июл Авг Сен Окт Ноя Дек Обратите внимание, оплата для дяди Федора с марта была увеличена.

Взаимодействие с программой 65 Чтобы ввести значения расходов, нужно нажать «i» и «e». Например: Стадия Передача – внедрение Введите месяц: 1 Введите день: 15 Введите категорию расходов (Ремонт, Налоги): Коммунальные услуги Введите получателя (Простоквашино ЭлектроСбыт): ПЭС Введите сумму платежа:

Взаимодействие с программой 66 Для вывода на экран таблицы расходов необходимо нажать «d» и «e». Ниже показано начало такой таблицы. Стадия Передача – внедрение Дата Получатель Сумма Категория /3 Ультра МегаБанк Закладная 1/8 Просто Водоканал Коммунальные услуги 1/9 Супер Страх Страховка 1/15 ПЭС Коммунальные услуги 1/22 Хлам дяди Сэма Снабжение 1/25 Подвал Мастерз Ремонт 2/3 Ультра МегаБанк Закладная

Взаимодействие с программой 67 Наконец, для вывода годового отчета пользователь должен нажать «d» и «e». Посмотрим на отчет за первые пять месяцев года: Стадия Передача – внедрение Годовой отчет Доходы Арендная плата Расходы Закладная Коммунальные услуги Реклама Ремонт Снабжение Страховка Баланс Категории расходов сортируются в алфавитном порядке. В реальной ситуации может быть довольно много бюджетных категорий, включая одни налоги, другие, третьи, расходы на поездки, ландшафтный дизайн дворовой территории, уборку помещений и т. д.

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

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

Резюме Диаграмма вариантов использования UML демонстри- рует действующие субъекты и инициируемые ими опе- рации (варианты использования). Любое существитель- ное из описаний вариантов использования может в буду- щем стать именем класса или атрибута. Глаголы прев- ращаются в методы. В дополнение к диаграммам вари- антов использования существует еще множество других UML-диаграмм, помогающих в более полной мере дос- тичь взаимопонимания между пользователями и разра- ботчиками. Отношения между классами показываются на диаграммах классов, управляющие потоки на диаграммах действий, а диаграммы последовательнос- тей отображают взаимосвязи между объектами при выполнении вариантов использования. 70

xxx.h: No such file or directory не найден заголовочный файл 'xxx.h' (неверно указано его имя, он удален или т.п.) 'xxx' undeclared (first use this function) функция или переменная 'xxx' неизвестна missing terminating " characterне закрыты кавычки " expected ; нет точки с запятой в конце оператора в предыдущей строке expected }не закрыта фигурная скобка 71 Наиболее «популярные» ошибки

Литература Роберт Лафоре. Объектно-ориентированное программирование в С++ (Глава 16) 2.Л.Г. Гагарина, Е.В. Кокорева, Б.Д.Виснадул Технология разработки программного обеспечания

Конец 73