Технология программирования

Конспекты лекций Конспект лекций Тема 1. Вводная. Порядок разработки. Требования к содержанию и документам. История развития ИСРП Тема 2. Выработка требований. ТЗ. Методы и инструменты логического проектирования Тема 3. UML. Описание функциональности разработки. Методы и инструменты Тема 4. Построение диаграммы классов. Методы, технологии, инструменты Тема 5. Определение языка разработки, среды реализации, инструментов разработки. Особенности виртуальной среды реализации программ и их учет в разработке ПП Тема 6. Определение инструментов разработки. Системные макросы и их применение в текстах разработки. Инструментальные средства и технологии Windows. MFC. SDK Тема 7. Средства визуального программирования - MS Visual Studio, Borland Delphi и др. Тема 8. Средства визуального программирования. Результаты компиляции. Список опций компилятора и компоновщика. Управление компилятором (С++Builder) Тема 9. Построение интерфейса программы. Принципы разработки инструментария Тема 10. Отладка программ. Инструменты. Методика отладки Тема 11. Тестирование. Разработка инвариантов и тестовых примеров Тема 12-13. Построение Help. Инструменты и методы. Требования на защиту и инсталляцию программ Тема 14-15. Файл менеджеры и их использование в работе с программами План проведения лабораторных занятий Лабораторная работа 1. Создание диаграммы вариантов использования и действующих лиц Лабораторная работа 2. Создание диаграммы Последовательности Лабораторная работа 3. Создание Кооперативной диаграммы Добавление на диаграмму дополнительных объектов Лабораторная работа 4. Диаграмма Состояний для класса Заказ Лабораторная работа 5. Построение диаграммы Активности для варианта использования "Выполнить поставку Заказа" Лабораторная работа 6. Пакеты и классы Лабораторная работа 7. Уточнение методов и свойств классов Добавление атрибутов Лабораторная работа 9. Исключение кириллизованного текста в информации классов Лабораторная работа 10. Построение диаграммы компонентов Лабораторная работа 11. Кодогенерация проекта в Delphi Лабораторная работа 12. Анализ Delphi проекта, добавление визуальных объектов, реинжениринг в Rose Лабораторная работа 13. Кодогенерация модельных элементов из Приложения Б Лабораторная работа 14. Построение диаграммы размещения   Конспект лекций   Тема 1. Вводная. Порядок разработки. Требования к содержанию и документам. История развития ИСРП   Технология программирования - это научная и практически-апробированная стратегия разработки программ, содержащая описание совокупности методов и средств разработки программ, а также порядок применения этих методов и средств. Программный продукт - программа, которую можно запускать, тестировать, исправлять и развивать. Такая программа должна быть написана в едином стиле, тщательно оттестирована до требуемого уровня надежности, сопровождена подробной документацией и подготовлена для тиражирования. Программа - очень сложный объект. Она обуславливается: ) сложностью задачи, ) сложностью управления, ) сложностью описания поведения отдельных подсистем, ) сложности обеспечения гибкости отдельных конечного программного продукта. Проектирование - это разработка проекта, процесс создания спецификаций, необходимых для построения в заданных условиях еще не существующего объекта на основе первичного описания этого объекта. Результатом проектирования является проектное решение или совокупность проектных решений, удовлетворяющих заданным требованиям, включающим форму представления решения. Спецификация - это какое-либо описание в точных терминах. Проектным документом называют документ, выполненный по заданной форме, в котором представлено какое-либо проектное решение. В программировании проектные решения оформляются в виде программной документации. Различают внешнюю - согласующуюся с заказчиком, и внутреннюю - для работы программистов, программные документации. Проект (от лат. project - брошенный вперед) - совокупность проектных документов в соответствии с установленным перечнем, который представляет результат проектирования. Объектом проектирования является программа. Решение проектной задачи должно быть найдено в рамках ограничений внешней среды проектирования: доступных денежных средств, заранее заданных сроков, возможностями технических средств и инструментария программирования, научных знаний и т.д. Общие принципы разработки программ. Частотный принцип Выделение в алгоритмах и данных особых групп по частоте использования. Для действий, наиболее часто встречающихся в работе программ, создаются условия для их быстрого выполнения. К часто используемым данным обеспечивается наиболее быстрый доступ. "Частые" операции стараются делать более короткими. Известно, что только не более 5% операторов программы оказывают ощутимое влияние на скорость выполнения программы. Этот факт позволяет значительную часть операторов программы кодировать бе учета скорости вычислений, обращая основное внимание на "красоту" и наглядность текстов. Принцип модульности Способы обособления составных частей программ в отдельные модули в значительной степени определяется используемым методом проектирования программ. Принцип функциональной избирательности В программах выделяется некоторая часть важных модулей, которые постоянно должны быть в состоянии готовности для эффективной организации вычислительного процесса. Эту часть программы называют ядром или монитором. Программы, входящие в состав монитора постоянно хранятся в ОП, остальные модули - подгружаются. Принцип генерируемости Исходная программа должна быть настраиваемой на конкретную конфигурацию технических средств, круг решаемых проблем, условия работы пользователя. Принцип функциональной избыточности Принцип предусматривает возможность проведения одной и той же работы различными средствами (для удобства пользователя). Принцип "по умолчанию" Принцип основан на хранении в системе некоторых базовых описаний структур, модулей, конфигурации оборудования и данных, определение условия работы с программой. Системный подход. Системный подход предусматривает всестороннее исследование сложного объекта с использованием компонентного, структурного, функционального, параметрического и генетического видов анализа. Компонентный анализ - рассмотрение объекта, включающего в себя составные элементы, и входящего в свою очередь в системы более высокого ранга. Структурный анализ - выявление элементов объекта и связей между ними. Функциональный анализ - рассмотрение объекта как комплекса выполняемых им функций. Параметрический анализ - установление качественных пределов развития объекта: время выполнения алгоритма, размер занимаемой памяти и т.д. Возникшие противоречия решаются за счет новых технологических решений. Частотный случай системного подхода - в блочно-иерархический подход. В нем процесс проектирования расчленяется на уровни. Парадигмы программирования. Процедурно-ориентированное программирование (алгоритмы) Объектно-ориентированное программирование (классы и объекты) Логически ориентированное программирование (цели, выраженные в исчислении предикатов) Ориентированное на правила программирование (правила "если …, то …") Ориентированное на соотношения программирование (инвариантные соотношения) Параллельное программирование (потоки данных) Стандарты программирования Группа стандартов ГОСТ "Единая система программоной документации" (ЕСПД) Стандарты ANSI (Американский Национальный институт стандартов) Описание жизненного цикла ПО Жизненный цикл - это совокупность взаимосвязанных процессов создания и последовательного изменения состояния продукции от формирования к ней исходных требований до окончания ее эксплуатации или потребления   Стадии и этапы разработки программ (по ГОСТ 19.102-77).   программирование визуальное язык макрос Стадия проекта - заканчивается выпуском проектной документации, содержащей описание полной, в рамках заданных требований, модели программы на заданном для данной стадии уровне. Заказчик принимает решение по дальнейшему продолжению проектных работ. Этапы проекта - части стадии проекта, выделяемые по соображениям единства характера работ. Программный документ Техническое задание (ТЗ) помимо основных требований к программному изделию содержит проект порядка взаимодействия заказчика и исполнителя по окончании конкретных этапов и требований к их выполнению. Эскизный проект (ЭП) - несколько альтернативных вариантов будущего изделия и уточнения требований на основе их анализа. Технический проект (ТП) - выполняется для получения однозначного описания конечного (оптимального) варианта построения программного изделия и порядка его реализации. Рабочий проект (РП) - необходим для реализации изделия в соответствии с ранее намеченным планом. Стадия "Внедрение" необходима для размножения программной документации в нужном количестве, обучения пользователей, помощи в освоении программы, сопровождение программы. НИР - научно-исследовательская работа. Модели играют важнейшую роль в проектировании программ. При построении моделей используется абстрагирование и декомпозиция.   Тема 2. Выработка требований. ТЗ. Методы и инструменты логического проектирования   1. Первые универсальные языки Это была эра программирования непосредственно в машинных кодах, а основным носителем информации были перфокарты и перфоленты. Программисты обязаны были знать архитектуру ЭВМ досконально. Программы были простыми, так как из-за ограниченных возможностей этих машин и большой сложностью разработки и отладки программ непосредственно на машинном языке. Программисты могли применять хитроумные алгоритмы, такие как самомодифицирующийся код. . Ассемблер Первый шаг к переходу к символическому кодированию машинных команд. Программисту не нужно было теперь вникать в хитроумные способы кодирования на аппаратном уровне. Появилось несколько способов кодирования одной и той же команды. Применялись макросы и метки, что упрощало создание, модификацию и отладку программ. Становилось невозможным применение хитроумных приемов. Впервые в истории программирования появилось два представления программы: в исходных текстах и в откомпилированном виде. Перевод вначале из машинных кодов в ассемблер (дизассемблирование) был возможен, но с появлением меток и макросов, процесс затруднился, а затем и вовсе стал невозможен. . Фортран г. Корпорация IBM, группа разработчиков во главе с Джоном Бакусом Это первый язык программирования высокого уровня. Впервые программист мог по-настоящему абстрагироваться от особенностей машинной архитектуры. Ключевой идеей, отличающей Фортран от ассемблера, была идея подпрограмм. Но синтаксис языка был не удобным, так как пробелы как синтаксическая единица вообще не использовались. Пр.: Do 10 I = 1, 100 или Do10I=1.100 (отличаются только запятой, первая - цикл, вторая объявление вещественной переменной) Сейчас Фортран используется для научных вычислений. Компилятор практически никак не проверяет синтаксически-правильную программу. В нем нет современных способов поддержки структурирования кода и данных. Появление фортрана было встречено яростной критикой, так как их пугало снижение эффективности программ из-за появления дополнительного звена в виде компилятора. Действительно, небольшая программа, созданная непосредственно в машинных кодахработает быстрее, чем автоматически созданная компилятором. Через некоторое время пришло понимание того, что реализация больших проектов невозможна без применения языков программирования высокого уровня. Мощность ЭВМ росла, и вместе с тем, падение эффективности, которое раньше казалось угрожающим, стало не такое значительное. . Cobol. г.- язык коммерческих приложений, возможность работы с большими массивами данных. До сих пор появляются новые диалекты. . PL/1 г. IBM, создан для замены Фортрана и Кобола. Неудачный синтаксис, не распространился. . Basic. г. в Дартмуртском колледже был создан BASIC - многоцелевой язык символических инструкций для начинающих. Он легко интерпретируется и компилируется. Распространился как язык для обучения программированию. Современный язык Microsoft VisualBasic поддерживает объектно-ориентированное программирование (ООП). . Algol. г. Петер Наур создал язык Алгол. Затем возникла целая серия алгол подобных языков, куда входит и Паскаль. Не распространился. . Pascal. г. Никлаус Вирт. Первый широко распространенный язык для структурного программирования. Здесь внедрена строгая проверка типов, отпала надобность в операторе безусловного перехода. Отрицательная черта - отсутствие в нем средств для разбиения программы на модули. г. Modula2 г. Modula3 Современные ОО версии этих языков Oberon, Oberon2. . С и С++ г. Керниган и Ритчи, язык С, как язык для разработки Операционной системы UNIX (поэтому его называют переносимым Ассемблером). Компилятор С очень слабо контролирует типы, поэтому очень легко написать внешне совершенно правильную, но логически-ошибочную программу. г. Бьярн Страуструп создал первую версию языка С++, добавив объектно-ориентированные черты в С, взятые из языка Simula. г. последняя версия С++. Язык стал основой для разработки больших и сложных проектов. Имеются и слабые стороны, вытекающие из требований эффективности. . Java г. корпорация Sun Microsystems, Кен Арнольд и Джеймс Гослинг. Наследовал синтаксис С и С++ и был избавлен от некоторых неприятных черт последнего. Отличительной чертой языка является компиляция в код некоей абстрактной машины, для которой затем пишется эмулятор (Java Virtual Machine) для реальных систем. В Java нет указателей и множественного наследования, что сильно повышает надежность программирования. . С# -2000 г. Корпорация Microsoft. Схож с Java, ориентирован, в основном, на разработку многокомпонентных Интернет-приложений. Языки обработки данных. г. APL (Aplication Programming Language) - математическая обработка данных - не получил распространения. г. Snobol и Icon - мощные средства обработки строк и текста. Наследник - Perl. В Perl добавлены некоторые принципы ООП, создавался в помощь системному администратору для обработки различного рода текстов и выделения нужной информации, очень практичный язык, но не достает элегантности. Является интерпретатором и реализован почти на всех платформах. Применяется также для автоматической генерации веб-страниц на веб-серверах. г. SETL - язык для описания операций над множествами. г. Lisp - язык для обработки списков, получил широкое распространение в системах искусственного интеллекта. Потомки: Planner (1967), Scheme (1975), Common Lisp (1984). Многие черты были унаследованы языками функционального программирования. Скриптовые языки: для использования в часто изменяемых программах, очень небольших программах, когда для выполнения операторов языка затрачивается время несопостовимое со временем их разбора. Script - создан в компании Netscape Communications для описания сложного поведения веб-страниц. Интерпретируется браузером во время отображения веб-страницы.Script - создан в компании Microsoft, альтернатива Java Script, схож с Visual Basic.(как Perl, но менее распространен). г. Simula г. Smalltalk г. Eiffel   Тема 3. UML. Описание функциональности разработки. Методы и инструменты   В таких специальных областях, как графика, базы данных, синтаксический разбор, цифровой анализ и моделирование, возможность решения задачи целиком и полностью зависит от наличия специальных алгоритмов и структур данных. Если вы разрабатываете программы в новых для вас областях программирования, то вы должны выяснить, какие наработки уже существуют, иначе вы потратите свое время впустую в попытках плохо сделать то, что уже кем-то было сделано хорошо. Каждая программа зависит от алгоритмов и структур данных, но редко бывает нужно изобретать новые алгоритмы. Даже в сложной программе, например в компиляторе или Web - браузере, структуры данных по большей части являются массивами, списками, деревьями и хэш-таблицами. Когда программе нужна более изощренная структура, она, скорее всего, будет основываться на этих более простых структурах. Соответственно, задача программиста - знать, какие алгоритмы и структуры доступны, а также понимать, как выбрать среди них нужные. Структура данных - это совокупность элементов данных, между которыми существуют некоторые отношения, причем элементами данных могут быть простые данные и структуры данных. Структуру данных можно определить, как S = (D,R), где D - множество элементов данных, R-множество отношений (связей) между элементами данных. Структуру можно изображать в виде графа, при этом элементам данных соответствуют вершины, а связям или отношениям - ориентированные или неориентированные ребра. В зависимости от отсутствия или наличия явно заданных связей между элементами данных различают структуры несвязные (вектор, массив, строка, стек, очередь) и связные (списки). Важный признак структуры - ее изменчивость. По этому признаку различают структуры статические, полустатические и динамические. В зависимости от характера взаимного расположения элементов в памяти ЭВМ структуры делят на структуры данных с последовательным расположением элементов в памяти (вектор, массив, стек, очередь) и структуры с произвольным распределением - (односвязные, двусвязные, ассоциативные списки). . Статические структуры данных (векторы, массивы, записи и таблицы). Вектор - конечное упорядоченное множество простых данных или скаляров одного и того же типа. Элементы вектора находятся между собой в отношении непосредственного следования. В памяти ЭВМ элементы вектора представляются последовательностью одинаковых по длине участков памяти, как правило, расположенных в порядке следования элементов в группе. к-мерным массивом называется конечное упорядоченное множество (к-1) мерных массивов, все элементы которых принадлежат одному и тому же типу. При к=1 получаем вектор. Запись - конечное упорядоченное множество элементов, характеризующихся в общем случае различным типом данных. Элементы записи называются полями. Примером структуры данных может служить таблица. Таблица - конечное упорядоченное множество записей, имеющих одну и ту же организацию. Наиболее распространена форма таблицы, в которой элемент представляет собой одноуровневую запись, состоящую из упорядоченной последовательности полей, имеющих в общем случае различный размер и соответствующих различным типам простых данных. Логическая структура представляется в виде последовательности расположенных друг под другом строчек одинаковой длины, представляющих элементы таблицы и разделенных на графы. Обычно одно из полей всех элементов таблицы отводится для хранения ключа, являющегося уникальным для каждой записи таблицы. Доступ к записям таблицы может осуществляться по номеру записи, но чаще доступ осуществляется по ключу, причем целью доступа является получение не отдельного поля записи, а как правило, сначала ищется какая-то одна запись (или группа записей), а затем осуществляется обработка полей этой записи или группы записей. Отличие массива от таблицы: доступ осуществляется не с помощью индексов, а по ключу, и целью доступа служит не отдельные данные, а запись. . Полустатические структуры данных (стеки, очереди). Определения этих структур данных основаны на понятии списка или списковой структуры. Списком называется линейно-упорядоченная последовательность элементов данных E (1),E (2) …E (n), где n>0, причем каждый элемент E (i) характеризуется одним и тем же набором полей. Такой список называют линейным списком из-за линейной упорядоченности элементов. При n=constи соответствующем выборе элемента данных, последовательный линейный список сводится к вектору, к массиву, записи или таблице. Так, вектор может быть определен как последовательный линейный список, в котором каждый элемент-скаляр одного и того же типа. При n = Var последовательный линейный список представляет собой структуру, не обладающую свойством постоянства. Однако, хотя n = Var, максимальное значение n задается явно и ограничивает длину списка. Такие структуры называют полустатические. Полустатические структуры данных - это последовательные линейные списки с переменной длиной, ограниченной фиксированной максимальной величиной и с ограниченным доступом. К таким структурам относятся стеки и очереди. . Динамические структуры данных (односвязные, двусвязные списки). Динамическая структура имеет следующие основные признаки: . Непостоянство и непредсказуемость размера (числа элементов) структуры в процессе ее обработки. . Отсутствие физической смежности элементов структуры в физической памяти. Логическая последовательность элементов задается в явном виде с помощью одного или нескольких указателей или связок, хранящихся в самих элементах. Часто динамические структуры физически представляются в форме связных списков. Связный список - такая структура, элементами которой служат записи с одним и тем же форматом, связанные друг с другом с помощью указателей, хранящихся в самих элементах списка. Списком называется линейно-упорядоченная последовательность элементов данных E (1), E (2) …E (n), где n>0, причем каждый элемент E (i) характеризуется одним и тем же набором полей. Такой список называют линейным списком из-за линейной упорядоченности элементов. Связный список - такая структура, элементами которой служат записи с одним и тем же форматом, связанные друг с другом с помощью указателей, хранящихся в самих элементах списка. В односвязном линейном списке каждый элемент состоит из двух различных по назначению полей: содержательного и поля указателя. Линейный двусвязный список отличается от односвязного тем, что каждый его элемент содержит два указателя, один из которых (прямой указатель) адресует следующий элемент в списке, а другой (обратный указатель) - адресует предыдущий элемент списка. Примером двусвязного списка является дерево. Бинарное дерево поиска - в бинарном дереве поиска каждая вершина имеет два указателя left и right, которые указывают на дочерние вершины. Эти указатели могут быть равны null, если у дерева меньше двух вершин. Структуру бинарного дерева поиска определяют значения в его вершинах: все дочерние узлы, расположенные левее данной, имеют меньшие значения, а все дочерние вершины правее - большие. Двоичный поиск занимает меньшее время, чем обычный (O (log n)). Дерево бинарного поиска достраивается рекурсивным спуском по дереву: на каждом шаге спуска выбирается соответствующая левая или правая ветка, пока не найдется место для вставки новой вершины. Новая вершина добавляется как лист дерева, т.е. у него пока отсутствуют дочерние вершины. Дерево может быть плохо сбалансированным, т.е. длина от корня до каждого листа дерева различные и сильно отличаются, это может увеличить время основных операций. Хэш-таблицы - сочетание массивов и списков с использованием специального механизма, называемого "хэшированием". При хэшировании информационное содержание ключа используется, чтобы определить уникальное значение, называемое его хэш-кодом. Затем хэш-код применяется как индекс (номер) элемента, в котором хранятся данные, связанные с ключом. Преобразование ключа в его хэш код выполняется автоматически при помощи хэш-функции (мы не можем увидеть хэш код). С каждым хэш значением ассоциируется список элементов, которые обладают этим значением. Хэш-код равномерно распределен по диапазону целых чисел приемлемого размера. Каждый элемент массива - это список, который сцепляет вместе элементы, имеющие общее хэш-значение. Хэш-функция, которая подходит для одного набора данных может плохо подходить для других (неравномерное распределение данных). Для выполнение основных операции: вставка, удаление, поиска в хэш таблицах затрачивается константное время O (1). Хэш-таблицы применяются для символьных таблиц.   Тема 4. Построение диаграммы классов. Методы, технологии, инструменты   Цель структурного программирования - разработка программы, которой присуща определенная структура, основанная на применении принципов структурного программирования. Перечислим эти принципы: . Каждый программный модуль (блок, функция, процедура) должен иметь только один вход и один выход. Это позволяет максимально упростить стыковку модулей в программе. . В программах рекомендуется применять 4 типа конструкций: а) последовательность (модулей, операторов) б) разветвление (условный оператор); в) цикл 1) с предусловием 2) с постусловием 3) выбор из нескольких альтернатив . Разработку программ рекомендуется вести сверху - вниз или по нисходящей стратегии. Суть нисходящей стратегии в том, что проектировщик должен приступить к работе, имея только концептуальный, абстрактный замысел о том, что система или программа будет делать. Затем этот замысел постепенно конкретизируется шаг за шагом, тем самым погружаясь в подробности окончательного программного продукта до тех пор, пока не будет достигнуто "дно", под которым понимаются программные модули, реализующие отдельные функции или процедуры преобразования данных       Модуль - это замкнутая программа, которую можно вызвать из другого модуля и самостоятельно откомпилировать. Другое определение: программный модуль - это любой фрагмент описания процесса, оформляемый как самостоятельный программный продукт, пригодный для использования в описаниях процесса. Модуль - это программа, обладающая тремя основными атрибутами: .        он выполняет одну или несколько функций; 2.      модуль реализует некоторую логику (алгоритм). .        используется в одном или нескольких контекстах. При этом функция - это то, что делает модуль, а не то, как он это делает. А вот логика характеризует, как модуль выполняет свои функции. Контекст описывает конкретное применение. Принципы модульного программирование следующие: а) усиление внутренних связей в каждом модуле (иначе принцип называется повышением прочности модуля); б) ослабление взаимосвязи между модулями (иначе этот принцип называется ослаблением сцепления модулей). Процедурное программирование основано на потоке управления. Суть его заключается в алгоритмической декомпозиции процесса решения задачи (разбиение на операторы), таким образом, чтобы из операторов языка программирования сконструировать программу, выполняющую некоторое заданное преобразование данных. Этот стиль программирования является базовым инструментарием для всех остальных технологий программирования. Процедурный стиль выражается в четком выделении в программе двух составляющих: непроцедурной (описание переменных, функций, процедур) и процедурной (описание действий). Существенный недостаток процедурного программирования - сложная реализация параллельного программирования. Также как недостаток можно отметить существенный объем программного кода. Функциональный стиль программирования основан на аргументной постановке задачи абстракции математической функции и аналитическом методе построения программ подобно математическим преобразованиям. Функциональное программирование широко используется в языке Лисп. Можно привести пример на языке Паскаль: Begin {Функциональный стиль) Writeln (Ln (Abs (Sin (5.5)); End., а если бы использовали процедурный стиль программирования то: Var x,y,z,t: Real; {Процедурный стиль} Begin х: =5.5; y: =Sin(x); z: =Abs (y); t: = Ln (z); Writeln (t); End.   Тема 5. Определение языка разработки, среды реализации, инструментов разработки. Особенности виртуальной среды реализации программ и их учет в разработке ПП   Качество ПП - это совокупность его черт и характеристик, которые влияют на способность ПП удовлетворять заданные потребности пользователя. Как и в случае технических устройств, показатели качества являются противоречивыми, что означает: улучшение одних показателей качества может быть достигнуто за счет ухудшения других. Качество ПП является удовлетворительным, если количественные показатели свойств гарантируют успешное его использование. Критериями качества ПП являются: функциональность; надежность; легкость применения; эффективность; сопровождаемость; мобильность. Функциональность - это способность ПП выполнять набор функций, определенных его внешними спецификациями. Надежность ПП - это способность безотказно выполнять заданные функции при заданных условиях в течение заданного периода времени с высокой степенью вероятности. Легкость применения - это способность минимизировать затраты пользователя на подготовку и ввод исходных данных и оценку полученных результатов, а также вызывать положительные эмоции пользователя. Эффективность - это отношение уровня услуг, предоставляемых ПП к объему используемых вычислительных ресурсов. Сопровождаемость - это такие характеристики ПП, которые позволяют минимизировать усилия по внесению изменений при обнаружении ошибок в ПП и при его модификации. Мобильность - это способность ПП быть перенесенным из одной вычислительной среды (окружения) в другую, в частности, с одной ЭВМ на другую (применяют термин "перенос с одной платформы на другую”. Функциональность и надежность являются обязательными критериями качества ПП, причем обеспечение надежности является неотъемлемой частью всех этапов и процессов разработки ПП. Предварительное внешнее проектирование. Следует отметить, что наиболее общей рекомендацией для этого этапа является структурирование (декомпозиция) целей программного продукта по схеме: основные цели - > подцели 1-го уровня. - >. подцели i-го уровня - >.. - > подцели n-го уровня - > функции для пользователя ПО. Результатом выполнения этапа должна быть структура целей программного продукта, которая может быть описана словесно, но наиболее наглядным является схематичное представление структуры целей. В результате выполнения декомпозиции целей получают системную архитектуру. СА представляет собой документ, отражающий модульно-иерархическую структуру проектируемого программного продукта с подробным описанием функциональных спецификаций отдельных модулей Схема - графическое представление определения, анализа или метода решения задачи, в котором используются символы для отображения операций, данных, потока, оборудования и т.д. Различают: схемы данных; схемы программ; схемы работы системы; схемы взаимодействия программ; схемы ресурсов системы. Схемы данных отображают путь данных при решении задач и определяют этапы обработки и применяемые носители данных. Схемы программ отображают последовательность операций в программе. Схемы работы системы отображают управление операциями и поток данных в системе. Схемы взаимодействия программ отображают путь активации программ и взаимодействий с данными. Каждая программа показывается только один раз (в схеме работы системы может изображаться более чем в одном потоке управления). Схемы ресурсов системы отображают конфигурацию блоков данных и обрабатывающих блоков, требуемую для решения задачи или набора задач. Детальное внешнее проектирование Содержанием детального внешнего проектирования является разработка спецификаций функций ПО. Фактически спецификации являются описаниями алгоритмов соответствующих функций. Для этих целей существует достаточно много методов, которые перечислим в порядке увеличения трудности проектирования алгоритмов: текстовое описание, структурированный естественный язык, таблица решений, дерево решений, визуальный язык, блок-схема, алгоритмический язык программирования. Восходящий и нисходящий методы проектирования. Суть нисходящей стратегии в том, что проектировщик должен приступить к работе, имея только концептуальный абстрактный замысел о том, что система или программа будет делать. Затем этот замысел постепенно конкретизируется шаг за шагом, тем самым погружаясь в подробности окончательного программного продукта до тех пор, пока не будет достигнуто "дно", под которым понимаются программные модули, реализующие отдельные функции или процедуры преобразования данных (принцип декомпозиции). Суть восходящей стратегии отличается от сути нисходящей стратегии. Для этой стратегии характерна первичная разработка модулей или функций, являющихся "дном" ПП, т.е. модулей, которые являясь самостоятельными, не используют какие-либо программные модули низшего уровня. Далее разрабатываются модули более высоких уровней, пока не будет достигнута "верхушка". Наиболее популярна нисходящая стратегия разработки ПО. Спецификация - это формальное описание требований, свойств и функций объекта. Наиболее распространено специфицирование с помощью таблиц решений. Проектирование спецификаций процессов с помощью таблиц решений (ТР) заключается в задании матрицы, отображающей множество входных условий в множество решений. Таблица решений - это такая внешняя спецификация ПО, в которой отражаются комбинации условий, выполняемых для входных данных, и соответствующие этим комбинациям действия по преобразованию информации. Пр.: Пример таблицы решений для спецификации процесса выбора символов из входного потока по следующим правилам: а) если очередной символ является управляющим, то подать звуковой сигнал и вернуть код ошибки; б) если буфер формируемой строки заполнен, то подать звуковой сигнал и вернуть код ошибки; в) если очередной символ не находится в заданном диапазоне, (положим, от ‘а’ до ‘я’), то подать звуковой сигнал и вернуть код ошибки; г) иначе поместить символ в буфер, увеличить значение счетчика выбранных символов и вернуть новое значение счетчика. Таблица решений для данного примера приведена ниже (таблица 1.1). Здесь ‘Д’ означает ‘да’, ‘Н’ - ‘нет’, 1,2 - помеченные действия выполняются в указанном порядке.     Тема 6. Определение инструментов разработки. Системные макросы и их применение в текстах разработки. Инструментальные средства и технологии Windows. MFC. SDK   Рекомендации по стилю программирования: Используйте осмысленные имена для глобальных переменных и короткие - для локальных. Сходным объектам давайте сходные имена, которые бы показывали их сходство и подчеркивали различия между ними Используйте активные имена для функций Будьте точны. Форматируйте код, подчеркивая его структуру Используйте естественную форму выражений Используйте скобки для устранения неясностей Разбивайте сложные выражения Будьте проще Будьте осторожны с побочными эффектами Будьте последовательны в применении отступов и фигурных скобок Используйте идиомы (устоявшиеся приемы) для единства стиля Используйте цепочки else-if для многовариантных ветвлений Используйте символьные, а не целые константы Используйте средства языка для определения размера объекта (Не используйте явно заданного размера ни для каких типов данных) Не пишите об очевидном Комментируйте функции и глобальные данные Не комментируйте плохой код, а перепишите его Вносите ясность, а не сумятицу В этой лекции мы поговорили об основных составляющих хорошего стиля программирования: информативных именах, ясности в выражениях, прозрачной логике, читабельности кода и комментариев, а также обсудили важность использования соглашений и идиоматических блоков для достижения всего вышеперечисленного. Однако стоит ли так беспокоиться о стиле? Кому какая разница, как программа выглядит изнутри, если она работает? Не слишком ли много времени придется тратить на ее "причесывание"? Не слишком ли расплывчаты рекомендуемые правила? Ответ на эти вопросы состоит в следующем: хорошо и красиво написанный код проще читать и воспринимать; в нем, без сомнения, содержится меньше ошибок, и он почти наверняка будет короче, чем код, бездумно скомпонованный и оставленный без улучшений. Когда программа пишется в спешке, когда и так трудно успеть к установленным срокам, кажется вполне естественным не обращать внимания на стиль, оставив заботы о нем на потом. Некоторые примеры из этой главы уже дали вам представление о том, что может случиться, если пренебрегать хорошим стилем. Небрежно оформленный код - плохой код, и не только потому, что выглядит он некрасиво и читать его трудно; как правило, в таком коде содержатся и ошибки. Основная мысль состоит в том, что хороший стиль должен просто войти в привычку. Если вы будете задумываться о стиле при написании кода, если вы будете выкраивать время для того, чтобы проверять и улучшать его стиль, вы выработаете у себя очень полезную привычку. После того как все это вы будете проделывать автоматически, ваше подсознание позаботится о многих деталях, и даже код, который вы будете писать в спешке, станет гораздо лучше   Тема 7. Средства визуального программирования - MS Visual Studio, Borland Delphi и др.   Целью тестирования является обнаружение ошибок в программе. В тестирование входят следующие этапы: а) постановка задачи для теста, б) проектирование тестов, в) написание тестов, г) тестирование тестов, д) выполнение тестов, е) изучение результатов тестирования. Отладкой называется процесс выявления природы ошибки программы и исправления ошибок, после того, как ошибки были обнаружены в процессе тестирования. На этом этапе выделяют две задачи: ) определение природы ошибки; ) исправление ошибки. Наиболее распространенными и наименее эффективными для отладки являются так называемые методы ‘грубой силы’. К ним относят: ) отладку с использованием дампа памяти; ) отладку с использованием операторов печати по всей программе; ) отладку с использованием автоматических средств: наиболее предпочтительно. Общей характеристикой методов ‘грубой силы’ является то, что они не требуют значительных умственных затрат и могут продолжаться бесконечно долго, если наряду с ними не применять более гибкие методы, к которым относятся: . метод индукции. . метод дедукции Из всех этапов проектирования логики программных модулей этап отладки является наименее формализованным. В нем выделяют две задачи: определение природы ошибки; исправление ошибки. Стратегии тестирования. Решающую роль играет проектирование тестов. Возможен целый ряд подходов к стратегии проектирования тестов. Чтобы ориентироваться в них, рассмотрим два крайних подхода. Первый состоит в том, что тесты проектируются на основе внешних спецификаций программ и модулей, либо спецификаций сопряжения программы или модуля. Программа при этом рассматривается как черный ящик (стратегия ‘черного ящика’). Существо такого подхода - проверить соответствует ли программа внешним спецификациям. При этом логика модуля совершенно не принимается во внимание. Второй подход основан на анализе логики программы (стратегия ‘белого ящика’). Существо подхода - в проверке каждого пути, каждой ветви алгоритма. При этом внешняя спецификация во внимание не принимается. Полное тестирование программы невозможно. Тест для любой программы будет обязательно неполным, то есть тестирование не гарантирует отсутствие всех ошибок. Стратегия проектирования тестов заключается в том, чтобы попытаться уменьшить эту неполноту насколько это возможно. При этом ключевым вопросом является следующий: какое подмножество всех возможных тестов имеет наивысшую вероятность обнаружения ошибок при ограниченных времени, трудовых затратах, стоимости, машинном времени и т.п. Наихудшей из всех методологий является случайный набор тестов, так как он имеет малую вероятность быть оптимальным. Рекомендуется следующая процедура разработки тестов: разрабатывать тесты, используя методы стратегии "черного ящика”; дополнительное тестирование, используя методы стратегии "белого ящика”. Методы "белого ящика": покрытия операторов (каждый оператор программы выполняется хотя бы 1 раз), покрытия решений или переходов (каждое направление перехода должно быть реализовано по крайней мере один раз), покрытия условий (все возможные результаты каждого условия в решении выполнить хотя бы 1 раз), критерий решений, комбинаторного покрытия условий (все возможные комбинации результатов условия в каждом решении выполнить по крайней мере один раз). Методы "черного ящика": эквивалентное разбиение, анализ граничных значений, тестирования таблицы решений (ТР), тестирование модульных программ. Метод эквивалентного разбиения. Поскольку исчерпывающее входное тестирование программы невозможно, реально приходится ограничиваться использованием небольшого подмножества всех возможных входных данных. Исходя из этого: а) каждый тест должен включать столько различных входных условий, сколько это возможно, с тем чтобы минимизировать общее число тестов; б) необходимо пытаться разбить входную область программы на конечное число классов эквивалентности так, чтобы можно было предположить, что каждый тест, являющийся представителем некоторого класса, эквивалентен любому другому тесту этого класса. Другими словами, если один тест класса эквивалентности обнаруживает ошибку, то следует ожидать, что и все другие тесты этого класса эквивалентности будут обнаруживать эту ошибку. И наоборот, если тест не обнаруживает ошибки, то следует ожидать, что ни один тест этого класса эквивалентности не будет обнаруживать ошибки. Разработка тестов методом эквивалентного разбиения осуществляется в два этапа: а) выделение класса эквивалентности; б) построение тестов. Классы эквивалентности выделяются путем выбора каждого входного условия (обычно это предложение или фраза в спецификации) и разбиением его на две или более групп. Для выполнения этой операции используют таблицу следующего вида:   Входные условия Правильные классы эквивалентности Неправильные классы эквивалентности   Здесь - правильные классы эквивалентности соответствуют правильным входным данным программы, а неправильные классы эквивалентности представляют все другие возможные состояния входных условий. Следующий этап данного метода - построение тестов. Этот процесс включает в себя: назначение каждому классу эквивалентности уникального номера; проектирование новых тестов, каждый из которых покрывает как можно большее число непокрытых правильных классов эквивалентности, пока все правильные классы эквивалентности не будут покрыты тестами; запись тестов, каждый из которых покрывает один и только один из непокрытых неправильных классов эквивалентности. Тестирование модульных программ. Наиболее распространенным приемом тестирования модульных программ является пошаговое тестирование. На практике применяют две его разновидности: . восходящее тестирование; . нисходящее тестирование. Методика восходящего тестирования включает следующие шаги: а) сначала тестируются ‘листья’ дерева структуры программы, т.е. модули Е,C,F. Для их тестирования программируются драйверы. В функции драйвера входит формирование тестовых данных для отлаживаемого модуля и передача ему управления; б) затем аналогично тестируются модули вышележащего уровня совместно с уже оттестированными модулями нижележащего уровня. Применительно к рассматриваемому нами примеру проектируются драйверы для тестирования пар B-E и D-F; в) пошаговый процесс продолжается до тех пор, пока не будет включен в процесс тестирования последний модуль (‘корень’ дерева структуры программы). Для нашего примера это будет модуль А. Для его тестирования совместно с вызываемыми программами нижележащего уровня драйвер разрабатывать не требуется. Альтернативное нисходящее тестирование состоит из следующих действий: а) тестирование начинается с вызывающего модуля программы (‘корня’ дерева структуры программы). Для модулей нижележащего уровня (вызываемых) программируются так называемые ‘заглушки’; б) после переходят к тестированию нижележащих модулей. Причем, формализованной процедуры подключения к вызывающему модулю нижележащих вызываемых модулей не существует. Единственное ограничение, которым руководствуются при выборе очередного претендента на тестирование, заключается в том, что этот модуль должен вызываться уже оттестированным модулем вышележащего уровня. Если очередной тестируемый модуль вызывает модули еще нижележащего уровня, для нижележащих модулей программируются ‘заглушки’; в) процесс тестирования продолжается до тех пор, пока не будет оттестирован последний модуль из ‘листьев’ дерева структуры программы.   Тема 8. Средства визуального программирования. Результаты компиляции. Список опций компилятора и компоновщика. Управление компилятором (С++Builder)   Объектно-ориентированное программирование - это подход, в котором данные и поведение (методы обработки данных) жестко связаны. Данные и поведение представлены в виде классов, экземпляры которых - объекты. ООП позволяет пользователю вводить собственные типы данных, расширяя тем самым набор встроенных в язык типов данных. Для обозначения этих расширений используется термин абстрактные типы данных (АТД). Основными свойствами ООП являются инкапсуляция, наследование и полиморфизм. Под инкапсуляцией понимается сокрытие данных и операций АТД от внешних программ, использующих их. Наследование - это средство получения новых типов данных (классов) из уже существующих типов, называемых базовыми классами. При этом повторно используется существующий код. Порождённый класс образуется из базового путем добавления или изменения кода. Полиморфизм - средство для придания различных значений одному и тому же сообщению в зависимости от типа обрабатываемых данных. Например, если аргументы оператора целого типа, то используется целочисленное деление. Если же один или оба аргумента - значения с плавающей точкой, то используется деление с плавающей точкой. Основным достоинством объектно-ориентированного программирования по сравнению с модульным программированием является "более естественная" декомпозиция программного обеспечения, которая существенно облегчает его разработку. Это приводит к более полной локализации данных интегрированию их с подпрограммами обработки, что позволяет вести практически независимую разработку отдельных частей (объектов) программы. Кроме этого, объектный подход предлагает новые способы организации программ, основанные на механизмах наследования, полиморфизма, композиции, наполнения. Эти механизмы позволяют конструировать сложные объекты из сравнительно простых. В результате существенно увеличивается показатель повторного использования кодов и появляется возможность создания библиотек классов для различных применений. Бурное развитие технологий программирования, основанных на объектном подходе, позволило решить многие проблемы. Так, были созданы среды, поддерживающие визуальное программирование, например, Delphi, C++ Builder, Visual C++ и т.д. При использовании визуальной среды у программиста появляется возможность проектировать некоторую часть, например, интерфейсы будущего продукта, с применением визуальных средств добавления и настройки специальных библиотечных компонентов. Результатом визуального проектирования является заготовка будущей программы, в которую уже внесены соответствующие коды. Использование объектного подхода имеет много преимуществ, однако его конкретная реализация в объектно-ориентированных языках программирования, таких как Pascal и C++, имеет существенные недостатки: фактически отсутствуют стандарты компоновки двоичных результатов компиляции объектов в единое целое даже в пределах одного языка программирования: компоновка объектов, полученных разными компиляторами C++ в лучшем случае проблематична, что приводит к необходимости разработки программного обеспечения с использованием средств и возможностей одного языка программирования высокого уровня и одного компилятора, а значит, требует наличия исходных кодов используемых библиотек классов; изменение реализации одного из программных объектов, как минимум, связано с перекомпиляцией соответствующего модуля и перекомпоновкой всего программного обеспечения, использующего данный объект. Таким образом, при использовании этих языков программирования сохраняется зависимость модулей программного обеспечения от адресов экспортируемых полей и методов, а также структур и форматов данных. Эта зависимость объективна, так как модули должны взаимодействовать между собой, обращаясь к ресурсам друг друга. Связи модулей нельзя разорвать, но можно попробовать стандартизировать их взаимодействие, на чем и основан компонентный подход к программированию.   Тема 9. Построение интерфейса программы. Принципы разработки инструментария В жизненный цикл программы входит этап формализации и анализа требований заказчика. Идея ведения этого этапа с помощью визуальных моделей развивается уже много лет. Она реализована в виде визуальных высокоуровневых средств, понятных людям, слабо знакомым с технологиями программирования. Такие средства задают целостную внутреннюю архитектуру сложной информационной системы. Лучшие подобные решения поддерживают прямую и двустороннюю связь модели и программного кода. Из модели можно автоматически получить исходный код, а из исходного кода - визуальную модель. В результате удается плавно состыковать этап выработки и согласования требований с этапом кодирования и формирования исполнимого приложения. В крупных проектах с моделью обычно работает не программист, а системный аналитик. Он отвлекается от мелких деталей реализации и перестает мыслить в терминах отдельных операторов языка программирования. Хороший проектировщик способен охватить и продумать структуру больших функциональных логических блоков и основные взаимосвязи между ними. Далее подобная модель детализируется и транслируется в исходный код на выбранном языке. Модель приложения - это взаимосвязанный набор визуальных диаграмм, наглядно описывающих внутреннюю структуру системы и принципы ее функционирования. Модель приложения не привязана к конкретному языку или конкретной среде программирования. Визуальные диаграммы чаще всего строятся с помощью унифицированного языка моделирования UML (Unified ModelingLanguage). Его стандарт разработан группой OMG (Object Management Group, версии языка в 1997-первая, 2004-последняя) для задач объектно-ориентированного проектирования. Существуют множество диаграмм в языке UML, но наиболее полезными при проектировании объектно-ориентированной программы являются: диаграммы вариантов использования диаграммы классов диаграммы последовательности. Далее рассмотрим эти виды диаграмм на примерах. Диаграммы вариантов использования:   Диаграммы вариантов использования отображают взаимодействие между вариантами использования, представляющими функции системы, и действующими лицами, представляющими людей или системы, получающие или передающие информацию в данную систему. Пример диаграммы вариантов использования для банковского автомата (ATM) показан на рисунке. На диаграмме представлено взаимодействие между вариантами использования и действующими лицами. Она отражает требования к системе с точки зрения пользователя. Таким образом, варианты использования - это функции, выполняемые системой, а действующие лица - это заинтересованные лица по отношению к создаваемой системе. Диаграммы показывают, какие действующие лица инициируют варианты использования. Из них также видно, когда действующее лицо получает информацию от варианта использования. В сущности диаграмма вариантов использования может иллюстрировать требования к системе. В нашем примере клиент банка инициирует различные варианты использования: "Снять деньги со счета", "Перевести деньги", "Положить деньги на счет", "Показать баланс", "Изменить идентификационный номер", "Произвести оплату". Банковский служащий может инициировать вариант использования "Изменить идентификационный номер". От варианта использования "Произвести оплату" идет стрелка к Кредитной системе. Действующими лицами могут быть и внешние системы, в данном случае Кредитная система показана именно как действующее лицо - она является внешней для системы ATM. Стрелка, направленная от варианта использования к действующему лицу, показывает, что вариант использования предоставляет некоторую информацию действующему лицу. В данном случае вариант использования "Произвести оплату" предоставляет Кредитной системе информацию об оплате по кредитной карточке. Из диаграмм вариантов использования можно получить довольно много информации о системе. Этот тип диаграмм описывает общую функциональность системы. Пользователи, менеджеры проектов, аналитики, разработчики, специалисты по контролю качества и все, кого интересует система в целом, могут, изучая диаграммы вариантов использования, понять, что система должна делать. Диаграммы последовательности.     Диаграммы последовательности отражают поток событий, происходящих в рамках варианта использования. Например, вариант использования "Снять деньги" предусматривает несколько возможных последовательностей: снятие денег, попытка снять деньги при отсутствии их достаточного количества на счету, попытка снять деньги по неправильному идентификационному номеру и некоторые другие. Нормальный сценарий снятия $20 со счета (при отсутствии таких проблем, как неправильный идентификационный номер или недостаток денег на счету) показан на рис. В верхней части диаграммы показаны все действующие лица и объекты, требуемые системе для выполнения варианта использования "Снять деньги". Стрелки соответствуют сообщениям, передаваемым между действующим лицом и объектом или между объектами для выполнения требуемых функций. Следует отметить также, что на диаграмме последовательности показаны именно объекты, а не классы. Классы представляют собой типы объектов. Объекты конкретны; вместо класса Клиент на диаграмме последовательности представлен конкретный клиент Джо. Вариант использования начинается, когда клиент вставляет свою карточку в устройство для чтения - этот объект показан в прямоугольнике в верхней части диаграммы. Он считывает номер карточки, открывает объект "счет Джо" и инициализирует экран ATM. Экран запрашивает у Джо его регистрационный номер. Клиент вводит число 1234. Экран проверяет номер у объекта "счет Джо" и обнаруживает, что он правильный. Затем экран предоставляет Джо меню для выбора, и тот выбирает пункт "Снять деньги". Экран запрашивает, сколько он хочет снять, и Джо указывает $20. Экран снимает деньги со счета. При этом он инициирует серию процессов, выполняемых объектом "счет Джо". В то же время осуществляется проверка, что на этом счету лежат, по крайней мере, $20 и из счета вычитается требуемая сумма. Затем кассовый аппарат получает инструкцию "выдать чек и $20 наличными". Наконец, все тот же объект "счет Джо" дает устройству для чтения карточек инструкцию вернуть карточку. Итак, данная диаграмма последовательности иллюстрирует последовательность действий, реализующих вариант использования "Снять деньги со счета" на конкретном примере снятия клиентом Джо $20. Глядя на эту диаграмму, пользователи знакомятся со спецификой своей работы. Аналитики видят последовательность (поток) действий, разработчики - объекты, которые надо создать, и их операции. Специалисты по контролю качества поймут детали процесса и смогут разработать тесты для их проверки. Таким образом, диаграммы последовательности полезны всем участникам проекта. Диаграммы классов.   Диаграммы классов отражают взаимодействие между классами системы. Например, "счет Джо" - это объект. Типом такого объекта можно считать счет вообще, т.е. "Счет" - это класс. Классы содержат данные и поведение (действия), влияющее на эти данные. Так, класс Счет содержит идентификационный номер клиента и проверяющие его действия. На диаграмме классов класс создается для каждого типа объектов из диаграмм последовательности или Кооперативных диаграмм. Диаграмма классов для варианта использования "Снять деньги" показана на рис. На диаграмме показаны связи между классами, реализующими вариант использования "Снять деньги". В этом процессе задействованы четыре класса: Card Reader (устройство для чтения карточек), Account (счет), ATM (экран ATM) и Cash Dispenser(кассовый аппарат). Каждый класс на диаграмме классов изображается в виде прямоугольника, разделенного на три части. В первой части указывается имя класса, во второй - его атрибуты. Атрибут - это некоторая информация, характеризующая класс. Например, класс Account (счет) имеет три атрибута: Account Number (номер счета), PIN (идентификационный номер) и Balance(баланс). В последней части содержатся операции класса, отражающие его поведение (действия, выполняемые классом). Связывающие классы линии показывают взаимодействие между классами. Разработчики используют диаграммы классов для реального создания классов. Такие инструменты, как Rose, генерируют основу кода классов, которую программисты заполняют деталями на выбранном ими языке. С помощью этих диаграмм аналитики могут показать детали системы, а архитекторы - понять ее проект. Если, например, какой-либо класс несет слишком большую функциональную нагрузку, это будет видно на диаграмме классов, и архитектор сможет перераспределить ее между другими классами. С помощью диаграммы можно также выявить случаи, когда между сообщающимися классами не определено никаких связей. Диаграммы классов следует создавать, чтобы показать взаимодействующие классы в каждом варианте использования. Можно строить также более общие диаграммы, охватывающие все системы или подсистемы.   Тема 10. Отладка программ. Инструменты. Методика отладки   Разработка архитектуры - это процесс разбиения большой системы на более мелкие части. Процесс разработки архитектуры - этап, необходимый при проектировании систем или комплексов, но необязательный при создании программы. Если внешние спецификации (экранные формы, организация файлов.) описывают программную систему с точки зрения пользователя, то следующий шаг проектирования состоит в разработке архитектуры, а за ним следует проектирование структуры каждой программы. Программная система может состоять из отдельных, разработанных разными организациями выполняемых программ; из программ, обменивающихся данными через порты; из отдельных резидентных программ. Традиционно программа проектировалась из отдельных файлов, модулей или классов, которые компилировались и компоновались в единое целое. Разработка программ из компонент - так называемых приложений компонентной архитектуры - происходит совершенно иначе. С появлением технологии разработки развивающихся и рассредоточенных (многомашинных) комплексов программ, основанной на модели компонентных объектов (СОМ), единого целого больше нет: программы состоят из отдельных компонент. Компонента поставляется пользователю как двоичный код, скомпилированный, скомпонованный и готовый к использованию. Доступ к этому коду осуществляется через точно документированный интерфейс. Во время выполнения компоненты подключаются к другим компонентам, формируя программу.   Тема 11. Тестирование. Разработка инвариантов и тестовых примеров   Компонентный подход предполагает построение программного обеспечения из отдельных компонентов - физически отдельно существующих частей программного обеспечения, которые взаимодействуют между собой через стандартизованные двоичные интерфейсы. В отличие от обычных объектов объекты-компоненты можно собрать в динамически вызываемые библиотеки или исполняемые файлы, распространять в двоичном виде (без исходных текстов) и использовать в любом языке программирования, поддерживающем соответствующую технологию. Сегодня рынок объектов стал реальностью: так, в Интернете существуют узлы, предоставляющие большое количество компонентов, рекламой компонентов забиты журналы. Это позволяет программистам создавать продукты, хотя бы частично состоящие из повторно использованных частей, т.е. применять технологию, хорошо зарекомендовавшую себя в области проектирования аппаратуры. Компонентный подход лежит в основе технологий, разработанных на базе COM (Component Object Model - компонентная модель объектов), и технологии создания распределенных приложений CORBA (Common Object Request Broker Architecture - общая архитектура с посредником обработки запросов объектов). Эти технологии используют сходные принципы и различаются лишь особенностями их реализации. Технология СОМ фирмы Microsoft является развитием технологии OLE (Object Linking and Embedding - связывание и внедрение объектов), которая использовалась в ранних версиях Windows для создания составных документов. Технология СОМ определяет общую парадигму взаимодействия программ любых типов: библиотек, приложений, операционной системы, т.е. позволяет одной части программного обеспечения использовать функции (службы), предоставляемые другой, независимо от того, функционируют ли эти части в пределах одного процесса, в разных процессах на одном компьютере или на разных компьютерах. Модификация СОМ, обеспечивающая передачу вызовов между компьютерами, называется DCOM (Distributed COM - распределенная СОМ). По технологии СОМ приложение предоставляет свои службы, используя специальные объекты - объекты СОМ, которые являются экземплярами классов СОМ. Объект СОМ, так же как обычный объект, включает поля и методы, но в отличие от обычных объектов каждый объект СОМ может реализовывать несколько интерфейсов, обеспечивающих доступ к его полям и функциям. Это достигается за счет организации отдельной таблицы адресов методов для каждого интерфейса (по типу таблиц виртуальных методов). При этом интерфейс обычно объединяет несколько однотипных функций. Кроме того, классы СОМ поддерживают наследование интерфейсов, но не поддерживают наследования реализации, т.е. не наследуют код методов, хотя при необходимости объект класса-потомка может вызвать метод родителя. Каждый интерфейс имеет имя, начинающееся с символа I и глобальный уникальный идентификатор IID (Interface IDentifier). Любой объект СОМ обязательно реализует интерфейс (Unknown (на схемах этот интерфейс всегда располагают сверху).Использование этого интерфейса позволяет получить доступ к остальным интерфейсам объекта. Объект всегда функционирует в составе сервера - динамической библиотеки или исполняемого файла, которые обеспечивают функционирование объекта. Различают три типа серверов: внутренний сервер: реализуется динамическими библиотеками, которые подключаются к приложению-клиенту и работают в одном с ними адресном пространстве. Это наиболее эффективный сервер, кроме того, он не требует специальных средств; локальный сервер: создается отдельным процессом (ехе), который работает на одном компьютере с клиентом; удаленный сервер: создается процессом, который работает на другом компьютере. Например, Microsoft Word является локальным сервером. Он включает множество объектов, которые могут использоваться другими приложениями. Взаимодействие клиента и сервера обеспечивается базовыми механизмами СОМ или DCOM, поэтому клиенту безразлично местонахождение объекта. При использовании локальных и удаленных серверов в адресном пространстве клиента создается proxy-объект - заместитель объекта СОМ, а в адресном пространстве сервера СОМ - заглушка, соответствующая клиенту. Получив задание от клиента, заместитель упаковывает его параметры и, используя службы операционной системы, передает вызов заглушке. Заглушка распаковывает задание и передает его объекту СОМ. Результат возвращается клиенту в обратном порядке. До конца ХХ в. все возможные проектные модели употребляли исключительно для документирования промежуточных и заключительных этапов разработки программного обеспечения, для чего применялись различные графические нотации и технологии, которые впоследствии были использованы для создания стандарта объектного моделирования. В ноябре 1997 г. после продолжительного процесса объединения различных методик группа OMG (Object Management Group) приняла получившийся в результате унифицированный язык моделирования (Unified Model Language - UML) в качестве стандарта. В 2001 г. члены OMG начали работу над новой версией UML, добавляя в нее недостающие элементы и устраняя недостатки, выявленные в UML1. Версия UML2 была принята в 2004 г. С официальной спецификацией UML можно ознакомится на веб-сайтеOMG по адресу www.omg.org. Идея создания языка UML включала в себя не только реализацию стандарта для документирования и общения разработчиков, но и реализацию возможности использования UML как языка программирования. Этот момент вызывал массу проблем при осуществлении, так как язык визуального моделирования по определению не мог содержать в себе всей выразительности объектно-ориентированных языков в плане проектирования (программирования) динамики и реализации алгоритмов. Нужен был язык, который на более высоком (абстрактном) уровне смог бы обеспечить разработку на UML. Такой язык был создан - это объектный язык ограничений OCL (Object Constraint Language). Тенденции развития средств разработки программных систем заключаются в создании таких средств, которые обеспечили бы не только автоматизацию всех этапов и процессов разработки программных систем, но и связь между результатами этапов. Одним из ключевых соединительных узлов является связь между проектными моделями и программным кодом. Когда разработка программных систем начинается от проектирования ее структуры до последующего кодирования и все изменения в функциях разрабатываемой системы реализуются начиная с перепроектирования архитектуры, то такая технология называется ориентированной на архитектуру (Model DrivenArchitecture MDA). Компания Borland начиная с седьмой версии своей среды разработки (Delphi) уже использует набор компонент, реализующий подход, ориентированный на архитектуру, но в этой версии присутствует еще масса недостатков и недоработок. В последней своей версии (Delphi 2006) компания Borland модернизировала технологию, ориентированную на архитектуру, что позволило использовать ее для разработки промышленных приложений, в том числе и для платформы Microsoft Framework.net.   Тема 12-13. Построение Help. Инструменты и методы. Требования на защиту и инсталляцию программ   Компания Borland начиная с седьмой версии своей среды разработки (Delphi) уже использует набор компонент, реализующий подход, ориентированный на архитектуру, но в этой версии присутствует еще масса недостатков и недоработок. В последней своей версии (Delphi 2006) компания Borland модернизировала технологию, ориентированную на архитектуру, что позволило использовать ее для разработки промышленных приложений, в том числе и для платформы Microsoft Framework.net.   Тема 14-15. Файл менеджеры и их использование в работе с программами   Каждый системный администратор стремится создать наиболее комфортную среду, для выполнения своих обязанностей с минимальными усилиями и максимальным удобством. В первую очередь, эти цели достигаются использованием программного обеспечения, наиболее функционального, удобного, компактного, и соответствующего личным предпочтениям.- это работающая в текстовом режиме программа управления файлами для Windows 95/98/Me/NT/2000/XP/2008/7, которая обеспечивает обработку файлов с длинными именами и имеет обширный набор дополнительных функций. Что верно, конечно, но на самом деле, совсем не отражает основного предназначения FAR Manager - быть максимально удобным инструментом администрирования системы. Наверно не менее половины всех повседневных задач администрирования можно решить с использованием одного единственного инструмента - FAR. Наиболее популярной версией FAR Manager многие годы была 1.70 (1.705) прекрасно работающая во всех Windows от NT до Windows 7. Затем, начиная с 2006 года, вышло несколько обновленных пакетов, и по состоянию на вторую половину 2012 г. на сайте разработчика доступны для свободного скачивания стабильные версии: универсальная версия FAR Manager 1.75 для использования в любой ОС семейства Windows. Во многом, данная версия, внешне почти ничем не отличается от старой доброй 1.705; версия FAR Manager 2.0 для использования в среде Windows XP и старше; На сайте разработчика имеется возможность скачать инсталляционные пакеты FAR как для 32-разрядных, так и 64-разрядных ОС WindowsВсе версии FAR от 1.705 до 2.0 практически не имеют внешних отличий, и не требуют от пользователя каких либо дополнительных усилий по освоению программы при переходе на новую версию. Тот, кто освоил работу с FAR 1.705, без проблем сможет пользоваться FAR2.1.705 распространялся как условно - бесплатное приложение (shareware). Для пользователей бывшего СССР, требовалась бесплатная регистрация программы с помощью довольно простой процедуры, и не требующая наличия доступа в Интернет. Версии 1.75 и 2.0 (а также и последующие в будущем) являются бесплатными (Freeware и Open Source) программами, распространяемыми под модифицированной BSD лицензией. В состав стандартной поставки FAR изначально входит достаточное количество дополнительных внешних модулей (плагинов,plugins), обеспечивающих комфортное выполнение большинства действий по обслуживанию системы без использования каких-либо дополнительных программ - от работы с архивами, файлами и папками до подключения к скрытым сетевым ресурсам или FTP-серверам. При необходимости, набор внешних модулей можно легко изменить, добавив необходимый функционал, или удалив ненужный. Все версии FAR Manager в стандартном варианте поставки позволяют работать с архивами. При этом, файлы в архивах обрабатываются аналогично файлам в папкам файловой системы Windows. FAR сам преобразует ваши команды в соответствующие вызовы внешних архиваторов.также обеспечивает значительное количество сервисных функций. Кроме стандартных возможностей обработки файлов он предоставляет возможности: FTP-клиента, позволяющего работать с FTP-серверами через Прокси и NAT. Просмотра сетевого окружения и сетевых папок, в т. ч и скрытых. Встроенного редактора с возможностью просмотра файлов как в текстовом так и HEX - формате. При чем в текстовом формате легко меняется DOS-кодировка на Windows и наоборот. Кроме того, возможности встроенного редактора позволяют легко выполнять даже такие "экзотические" операции, как перенос из текстового файла выделенного в прямоугольном окне текста в другой файл и т.д. Менеджера программ, позволяющего просмотреть список процессов, сведения о каждом из них, его источник и используемые ресурсы системы. И убить ЛЮБОЙ процесс, чего не позволяет сделать стандартный Task Manager. Имеется возможность просмотра списков процессов на другом компьютере в локальной сети. Менеджера печати. Возможность создания своих макросов и меню для максимальной адаптации "под себя". Поддержку русского языка и бесплатную регистрацию для пользователей бывшего СССР в shareware-версиях.  5. Вопросы и задания для контроля   1 Понятие программы, проектирования, общий подход при разработке программ Модели жизненного цикла программного обеспечения Стадии жизненного цикла программного обеспечения Унифицированный процесс разработки Rational (RUP). Инструмент Rational Rose Фазы RUP: фаза начала проекта, фаза проектирования, фаза построения, фаза внедрения Артефакты RUP: модель вариантов использования, модель анализа, модель проектирования, модель реализации, модель развертывания, модель тестирования Понятие качества программного обеспечения и основные критерии качества программного обеспечения Принципы создания удобного пользовательского интерфейса Унифицированный язык моделирования. Сущности, отношения, диаграммы в UML Диаграммы вариантов использования в UML Диаграммы последовательностей в UML Диаграммы классов в UML: области видимости, иерархия классов, кратность Диаграммы классов в UML: отношение агрегации и композиции, примеры Диаграммы классов в UML: отношение ассоциации, обобщения, примеры Диаграммы состояний в UML Диаграммы активности в UML Кооперативные диаграммы в UML Диаграммы компонентов в UML Диаграммы размещения в UML Тестирование программного обеспечения. Фазы тестирования. Стратегии тестирования Отладка программного обеспечения. Методы отладки в средах программирования (logging, step into, step over, step out, остановы (breakpoints), анализ трасс и состояний памяти (dump)) Стратегия тестирования "черного ящика" Стратегия тестирования "белого ящика" Методы тестирования "белого ящика": покрытия операторов, покрытия решений, покрытия условий, комбинаторного покрытия условий Методы тестирования "черного ящика": эквивалентное разбиение, анализ граничных значений, тестирование таблицы решений, тестирование модульных программ Виды тестирования модульных программ: восходящее и нисходящее тестирования Метод эквивалентного разбиения Интеграционное тестирование Системное тестирование Реляционное тестирование Тестовое окружение. Понятие драйверов и заглушек Ручное тестирование. Автоматизация тестирования Тестирование интерфейса программного обеспечения Визуальное программирование в MS Visual Studio, Borland Delphi и т.д. Выбор языка разработки, среды реализации, инструментов разработки. Файл-менеджеры (FAR, NC). Принципы работы Принципы создания и построители справочной документации Инструменты установки программ и настройки среды их использования (Install Shield) План проведения лабораторных занятий   № работы Наименование работ   Лабораторно-практическая работа №1. "Создание диаграммы вариантов использования и действующих лиц"   Лабораторно-практическая работа №2. "Создание диаграммы Последовательности"   Лабораторно-практическая работа №3. "Создание Кооперативной диаграммы"   Лабораторно-практическая работа №4 "Диаграмма Состояний для класса Заказ"   Лабораторно-практическая работа №5. "Построение диаграммы Активности для варианта использования "Выполнить поставку Заказа""   Лабораторно-практическая работа №6. "Пакеты и классы"   Лабораторно-практическая работа №7. "Уточнение методов и свойств классов."   Лабораторно-практическая работа №8 "Описание связей между классами."   Лабораторно-практическая работа №9. "Исключениекириллизованного текста в информации классов"   Лабораторно-практическая работа №10 "Построение диаграммы компонентов"   Лабораторно-практическая работа №11 "Кодогенерация проекта в Delphi"   Лабораторно-практическая работа №12 "Анализ Delphiпроекта, добавление визуальных объектов, реинжиниринг в Rose"   Лабораторно-практическая работа №13 "Кодогенерация модельных элементов"   Лабораторно-практическая работа №14 "Построение диаграммы размещения"   Всего:   Лабораторная работа 1. Создание диаграммы вариантов использования и действующих лиц   Результатом проделанной работы должна стать диаграмма, показанная на рис. 1.   Рис. 1 Диаграмма вариантов использования задачи о заказе товара.   Этапы выполнения упражнения. . Дважды щелкнув мышью на Главной диаграмме Вариантов Использования (Main) в браузере, откройте ее. . С помощью кнопки Use Case (Вариант использования) панели инструментов поместите на диаграмму новый вариант использования. Назовите его "Ввести новый заказ". . Повторив этапы 2 и 3, поместите на диаграмму остальные варианты использования: Изменить существующий заказ Напечатать инвентарную опись Обновить инвентарную опись Оформить заказ Отклонить заказ Выполнить поставку заказа 4. С помощью кнопки Actor (Действующее лицо) панели инструментов поместите на диаграмму новое действующее лицо. 5. Назовите его "Продавец". 6. Повторив шаги 4 и 5, поместите на диаграмму остальных действующих лиц: Управляющий магазином Клерк магазина Бухгалтерская система 7. Создание абстрактного варианта использования (не требующего дальнейшей декомпозиции). Щелкните правой кнопкой мыши на варианте использования "Отклонить заказ" на диаграмме. В открывшемся меню выберите пункт Open Specification (Открыть спецификацию). Установите флажок Abstract (Абстрактный), чтобы сделать этот вариант использования абстрактным. Добавление ассоциаций 1. С помощью кнопки Unidirectional Association (Однонаправленная ассоциация) панели инструменте нарисуйте ассоциацию между действующим лицом Продавец и вариантом использования "Ввести заказ". . Повторив шаг 1, поместите на диаграмму остальные ассоциации, согласно рис.1. Добавление связи расширения С помощью кнопки Generalization (Обобщение) панели инструментов нарисуйте связь между вариантом использования "Отклонить заказ" и вариантом использования "Оформить заказ". Стрелка должна быть направлена от первого варианта использования ко второму. Связь расширения означает, что вариант использования "Отклонить заказ" при необходимости дополняет функциональные возможности варианта использования "Оформить заказ". Щелкните правой кнопкой мыши на новой связи между вариантами использования "Отклонить заказ" и "Оформить заказ". В открывшемся меню выберите пункт Open Specification (Открыть спецификацию). В раскрывающемся списке стереотипов введите слово extends (расширение), затем нажмите ОК. Надпись "extends" появится на линии данной связи. Добавление описаний к вариантам использования Выделите в браузере вариант использования "Ввести новый заказ". В окне документации введите следующее описание: " Этот вариант использования дает клиенту возможность ввести новый заказ в систему". С помощью окна документации добавьте описания ко всем остальным вариантам использования. Добавление описаний к действующему лицу Выделите в браузере действующее лицо Продавец. В окне документации введите следующее описание: "Продавец - это служащий, старающийся продать товар". С помощью окна документации добавьте описания к остальным действующим лицам. Лабораторная работа 2. Создание диаграммы Последовательности   Согласовав основные бизнес процессы с Антоном, Павел приступил к построению модели бизнес - процессов, что бы ответить на вопрос - "как это должно делаться в системе". Для начала он выбрал наиболее важный Вариант использования-"Ввод нового заказа" и построил для него диаграммы взаимодействия. Диаграммы взаимодействия включают в себя два типа диаграмм - Последовательности и Кооперативную. Этапы выполнения упражнения Настройка программной среды 1. В меню модели выберите пункт Tools > - Options (Инструменты > - Параметры). 2. Перейдите на вкладку Diagram (Диаграмма). 3. Установите флажки Sequence numbering, Collaboration numbering и Focus of control. 4. Нажмите OK, чтобы выйти из окна параметров. Создание диаграммы Последовательности 1. Щелкните правой кнопкой мыши на Логическом представлении браузера. 2. В открывшемся меню выберите пункт New > Sequence Diagram (Создать >Диаграмма Последовательности). 3. Назовите новую диаграмму: Ввод заказа. 4. Дважды щелкнув на этой диаграмме, откройте ее. Добавление на диаграмму действующего лица и объектов 1. Перетащите действующее лицо Продавец из браузера на диаграмму. 2. Нажмите кнопку Object (Объект) панели инструментов. 3. Щелкните мышью в верхней части диаграммы, чтобы поместить туда новый объект. 4. Назовите объект Выбор варианта заказа. 5. Повторив шаги 3 и 4, поместите на диаграмму объекты: Форма деталей заказа Заказ №1234 Добавление сообщений на диаграмму 1. На панели инструментов нажмите кнопку Object Message (Сообщение объекта). 2. Проведите мышью от линии жизни действующего лица Продавец к линии жизни объекта Выбор варианта заказа. 3. Выделив сообщение, введите его имя - Создать новый заказ. 4. Повторив шаги 2 и 3, поместите на диаграмму сообщения: Открыть форму - между Выбор Варианта Заказа и Форма деталей Заказа Ввести номер заказа, заказчика и число заказываемых предметов - между Продавец и Форма Деталей Заказа Сохранить заказ - между Продавец и Форма Деталей Заказа Создать пустой заказ - между Форма Деталей Заказа и Заказ N1234 Ввести номер заказа, заказчика и число заказываемых предметов - между Форма Деталей Заказа и Заказ N1234 Сохранить заказ - между Форма Деталей Заказа и Заказ N1234 Завершен первый этап работы. Готовая диаграмма Последовательности представлена на рис.2.       Рис.2. Диаграмма последовательности без управляющих элементов.     Теперь нужно позаботиться об управляющих объектах и о взаимодействии с базой данных. Как видно из диаграммы, объект Форма Деталей Заказа имеет множество ответственностей, с которыми лучше всего мог бы справиться управляющий объект. Кроме того, новый заказ должен сохранять себя в базе данных сам. Вероятно, эту обязанность лучше было бы переложить на другой объект. Добавление на диаграмму дополнительных объектов 1. Нажмите кнопку Object панели инструментов. 2. Щелкните мышью между объектами Форма Деталей Заказа и Заказ №1234, чтобы поместить туда новый объект. 3. Введите имя объекта - Управляющий заказами. 4. Нажмите кнопку Object панели инструментов. 5. Новый объект расположите справа от Заказ №1234. . Введите его имя - Управляющий транзакциями. Назначение ответственностей объектам 1. Выделите сообщение 5: Создать пустой заказ. 2. Нажав комбинацию клавиш CTRL+D, удалите это сообщение. 3. Повторите шаги 1 и 2 для удаления двух последних сообщений: Вести номер заказа, заказчика и число заказываемых предметов Сохранить заказ 4. Нажмите кнопку Object Message панели инструментов. 5. Поместите на диаграмму новое сообщение, расположив его под сообщением 4 между Форма деталей заказа и Управляющий заказами. 6. Назовите его Сохранить заказ. 7. Повторите шаги 4 - 6, добавив сообщения с шестого по девятое и назвав их: Создать новый заказ - между Управляющий заказами и Заказ №1234 Ввести номер заказа, заказчика и число заказываемых предметов - между Управляющий заказами и Заказ №1234 Сохранить заказ - между Управляющий заказами и Управляющий транзакциями Информация о заказе - между Управляющий транзакциями и Заказ №1234 8. На панели инструментов нажмите кнопку Message to Self (Сообщение себе). 9. Щелкните на линии жизни объекта Управляющий транзакциями ниже сообщения 9, добавив туда рефлексивное сообщение. 10. Назовите его Сохранить информацию о заказе в базе данных. Соотнесение объектов с классами 1. Щелкните правой кнопкой мыши на объекте Выбор варианта заказа. 2. В открывшемся меню выберите пункт Open Specification (Открыть спецификацию). В раскрывающемся списке классов выберите пункт (Создать). Появится окно спецификации классов. 4. В поле Name введите Выбор заказа. 5. Щелкните на кнопке ОК. Вы вернетесь в окно спецификации объекта. 6. В списке классов выберите класс Выбор Заказа. 7. Щелкните на кнопке ОК, чтобы вернуться к диаграмме. Теперь объект называется Выбор варианта заказа: Выбор Заказа . Для соотнесения остальных объектов с классами повторите шаги с 1 по 7: Класс Детали заказа соотнесите с объектом Форма деталей заказа Класс Упр_заказами - с объектом Управляющий заказами Класс Заказ - с объектом Заказ N 1234 Класс Упр_ транзакциями - с объектом Управляющий транзакциями Соотнесение сообщений с операциями 1. Щелкните правой кнопкой мыши на сообщении 1: Создать новый заказ. 2. В открывшемся меню выберите пункт (создать операцию). Появится окно спецификации операции. 3. В поле Name введите имя операции - Создать. 4. Нажмите на кнопку ОК, чтобы закрыть окно спецификации операции и вернуться к диаграмме. 5. Еще раз щелкните правой кнопкой мыши на сообщении 1. . В открывшемся меню выберите новую операцию Создать (). 7. Повторите шаги с 1 по 6, чтобы соотнести с операциями все остальные сообщения: Сообщение 2: Открыть форму соотнесите с операцией Открыть () Сообщение 3: Ввести номер заказа, заказчика и число заказываемых предметов - с операцией Ввести номер заказа, заказчика и число заказываемых предметов () Сообщение 4: Сохранить заказ - с операцией Сохранить заказ () Сообщение 5: Сохранить заказ - с операцией Сохранить заказ () Сообщение 6: Создать пустой заказ - с операцией Создать пустой заказ () Сообщение 7: Ввести номер заказа, заказчика и число заказоваемых предметов - с одноименной операцией. Сообщение 8 Сохранить заказ - с операцией Сохранить заказ () Сообщение 9 Информация о заказе - с одноименной операцией Сообщение 10 Сохранить информацию о заказе с одноименной операцией. Диаграмма должна выглядеть, как на рис.3.     Рис.3. Окончательный вид диаграмы последовательности   Лабораторная работа 3. Создание Кооперативной диаграммы   Конечный вид диаграммы представлен на рис.4.   Рис.4. Окончательный вид кооперативной диаграммы.   . Щелкните правой кнопкой мыши на Логическом представлении в браузере. 2. В открывшемся меню выберите пункт New > Collaboration Diagram (Создать > Кооперативная диаграмма). 3. Назовите эту диаграмму Ввод заказа. 4. Дважды щелкнув мышью на диаграмме, откройте ее. Добавление действующего лица и объектов на диаграмму 1. Перетащите действующее лицо Продавец из браузера на диаграмму. 2. Нажмите кнопку Object (Объект) панели инструментов. 3. Щелкните мышью где-нибудь внутри диаграммы, чтобы поместить туда новый объект. 4. Назовите объект Выбор варианта заказа. 5. Повторив шаги 3 и 4, поместите на диаграмму объекты: Форма деталей заказа Заказ №1234 Добавление сообщений на диаграмму 1. На панели инструментов нажмите кнопку Object Link (Связь объекта). 2. Проведите мышью от действующего лица Продавец к объекту Выбор варианта заказа. 3. Повторите шаги 1 и 2, соединив связями следующие объекты: Действующее лицо Продавец и объект Форма деталей Заказа Объект Форма деталей Заказа и объект Выбор Варианта Заказа Объект Форма деталей Заказа объект Заказ N1234 . На панели инструментов нажмите кнопку Link Message (Сообщение связи). 5. Щелкните мышью на связи между Продавец и Форма деталей Заказа. 6. Выделив сообщение, введите его имя - Создать новый заказ; 7. Повторив шаги с 4 по 6, поместите на диаграмму сообщения: Открыть форму - между Выбор Варианта Заказа и Форма Деталей Заказа. Ввести номер заказа, заказчика и число заказываемых предметов - между Продавец и Форма Деталей Заказа Сохранить заказ - между Продавец и Форма деталей Заказа Создать пустой заказ - между Форма деталей Заказа и Заказ №1234 Ввести номер заказа, заказчика и число заказываемых предметов - между Форма деталей Заказа и Заказ №1234 Сохранить заказ - между Форма деталей Заказа и Заказ №1234 Теперь нужно поместить на диаграмму дополнительные элементы, а также рассмотреть ответственности объектов. Добавление на диаграмму дополнительных объектов 1. Нажмите кнопку Object панели инструментов. 2. Щелкните мышью где-нибудь на диаграмме, чтобы поместить туда новый объект. 3. Введите имя объекта - Управляющий заказами. 4. На панели инструментов нажмите кнопку Object. 5. Поместите на диаграмму еще один объект. 6. Введите его имя - Управляющий транзакциями. Назначение ответственностей объектам 1. Выделите сообщение 5: Создать пустой заказ. Выделяйте слова, а не стрелку. 2. Нажав комбинацию клавиш CTRL+D, удалите это сообщение. 3. Повторите шаги 1 и 2 для удаления сообщений 6 и 7: Ввести номер заказа, заказчика и число заказываемых предметов Сохранить заказ . Выделите связь между объектами Форма деталей Заказа и Заказ №1234 . Нажав комбинацию клавиш CTRL+D, удалите эту связь 6. На панели инструментов нажмите кнопку Object Link (Связь объекта). 7. Нарисуйте связь между Форма деталей Заказа и Управляющий Заказами. 8. На панели инструментов нажмите кнопку Object Link (Связь объекта). 9. Нарисуйте связь между Управляющий Заказами и Заказ №1234 10. На панели инструментов нажмите кнопку Object Link (Связь объекта). 11. Нарисуйте связь между Заказ №1234 и Управляющий Транзакцией. 12. На панели инструментов нажмите кнопку Object Link (Связь объекта). 13. Нарисуйте связь между Управляющий Заказами и Управляющий Транзакцией. 14. На панели инструментов нажмите кнопку Link Message (Сообщение связи). 15. Щелкните мышью на связи между объектами Форма деталей Заказа и Управляющий Заказами, чтобы ввести новое сообщение. 16. Назовите это сообщение Сохранить заказ. 17. Повторите шаги 14 - 16, добавив сообщения с шестого по девятое, и назвав их: Создать новый заказ - между Управляющий Заказами и Заказ №1234 Ввести номер заказа, заказчика и число заказываемых предметов - между Управляющий Заказами и Заказ №1234 Сохранить заказ - между Управляющий Заказами и Управляющий Транзакцией Информация о заказе - между Управляющий Транзакцией и Заказ №1234 18. На панели инструментов нажмите кнопку Link to Self (Связь с собой). 19. Щелкнув на объекте Управляющий Транзакцией, добавьте к нему рефлексивное сообщение. 20. На панели инструментов нажмите кнопку Link Message (Сообщение связи). 21. Щелкните мышью на рефлексивной связи Управляющий Транзакциями, чтобы ввести туда сообщение. 22. Назовите новое Сохранить информацию о заказе в базе данных. Соотнесение объектов с классами (если классы были созданы при разработке описанной выше диаграммы Последовательности) 1. Найдите в браузере класс Выбор Заказа. 2. Перетащите его на объект Выбор варианта заказа на диаграмме. 3. Повторите шаги 1 и 2 соотнеся остальные объекты и соответствующие им классы: Класс заказ деталей соотнесите с объектом Форма деталей заказа Класс Упр_заказами - с объектом Управляющий Заказами Класс Заказ - с объектом Заказ №1234 Класс Упр_транзакциями - с объектом Управляющий транзакциями Соотнесение объектов с классами (если вы не создавали описанную выше диаграмму Последовательности) 1. Щелкните правой кнопкой мыши на объекте Форма деталей Заказа. 2. В открывшемся меню выберите пункт Open Specification (Открыть спецификацию). 3. В раскрывающемся списке классов выберите пункт (Создать). Появится окно спецификации классов. 4. В поле имени введите Выбор заказа. 5. Щелкните на кнопке ОК. Вы вернетесь в окно спецификации объекта. 6. В списке классов выберите класс Выбор заказа. 7. Щелкните на кнопке OK, чтобы вернуться к диаграмме. Теперь объект называется Выбор варианта заказа: Выбор Заказа 8. Для соотнесения остальных объектов с классами повторите шаги с 1 по 7: Класс Детали заказа соотнесите с объектом Форма деталей заказа Класс Упр_заказами - с объектом Управляющий заказами Класс Заказ - с объектом Заказ N 1234 Класс Упр_ транзакциями - с объектом Управляющий транзакциями Соотнесение сообщений с операциями (если операции были созданы при разработке описанной выше диаграммы Последовательности) 1. Щелкните правой кнопкой мыши на сообщении 1: Создать новый заказ. 2. В открывшемся меню выберите пункт Open Specification (Открыть спецификацию). 3. В раскрывающемся списке имен укажите имя операции - Создать (). 4. Нажмите на кнопку ОК. 5. Повторите шаги 1-4 для соотнесения с операциями остальных сообщений: Сообщение 2: Открыть форму соотнесите с операцией Открыть () Сообщение 3: Ввести номер заказа, заказчика и число заказываемых предметов - с операцией Ввести номер заказа, заказчика и число заказываемых предметов () Сообщение 4: Сохранить заказ - с операцией Сохранить заказ () Сообщение 5: Сохранить заказ - с операцией Сохранить заказ () Сообщение 6: Создать пустой заказ - с операцией Создать пустой заказ () Сообщение 7: Ввести номер заказа, заказчика и число заказоваемых предметов - с одноименной операцией. Сообщение 8 Сохранить заказ - с операцией Сохранить заказ () Сообщение 9 Информация о заказе - с одноименной операцией Сообщение 10 Сохранить информацию о заказе с одноименной операцией Соотнесение сообщений с операциями (если вы не создавали описанную выше диаграмму Последовательности) 1. Щелкните правой кнопкой мыши на сообщении 1: Создать новый заказ (). 2. В открывшемся меню выберите пункт (создать операцию). Появится окно спецификации операции. 3. В поле имени введите имя операции - Создать (). 4. Нажмите на кнопку ОК, чтобы закрыть окно спецификации операции и вернуться к диаграмме. 5. Еще раз щелкните правой кнопкой мыши на сообщении 1. . В открывшемся меню выберите пункт Open Specification (Открыть спецификацию). 7. В раскрывающемся списке Name (Имя) укажите имя новой операции. 8. Нажмите на кнопку ОК. 9. Повторите шаги 1-8, чтобы создать новые операции и соотнести с ними остальные сообщения: Сообщение 2: Открыть форму соотнесите с операцией Открыть () Сообщение 3: Ввести номер заказа, заказчика и число заказываемых предметов - с операцией Ввести номер заказа, заказчика и число заказываемых предметов () Сообщение 4: Сохранить заказ - с операцией Сохранить заказ () Сообщение 5: Сохранить заказ - с операцией Сохранить заказ () Сообщение 6: Создать пустой заказ - с операцией Создать пустой заказ () Сообщение 7: Ввести номер заказа, заказчика и число заказоваемых предметов - с одноименной операцией. Сообщение 8 Сохранить заказ - с операцией Сохранить заказ () Сообщение 9 Информация о заказе - с одноименной операцией Сообщение 10 Сохранить информацию о заказе с одноименной операцией Ваша диаграмма должна выглядеть, как показано на рис.4 Лабораторная работа 4. Диаграмма Состояний для класса Заказ   Постройте диаграмму Состояний для класса Заказ, показанную на рис.5.   Рис 5. Диаграмма состояний для класса Заказ   Этапы выполнения упражнения Создание диаграммы . Найдите в браузере класс Заказ. 2. Щелкните на классе правой кнопкой мыши и в открывшемся меню укажите пункт New > Statechart Diagram (Создать диаграмму состояний). Добавление начального и конечного состояний 1. Нажмите кнопку Start State (Начальное состояние) панели инструментов. 2. Поместите это состояние на диаграмму. 3. Нажмите кнопку End State (Конечное состояние) панели инструментов. 4. Поместите это состояние на диаграмму. Добавление суперсостояния . Нажмите кнопку State (Состояние) панели инструментов. 2. Поместите это состояние на диаграмму. Добавление оставшихся состояний . На панели инструментов нажмите кнопку State (Состояние). 2. Поместите состояние на диаграмму. 3. Назовите состояние Отменен. 4. На панели инструментов нажмите кнопку State (Состояние). 5. Поместите состояние на диаграмму. 6. Назовите состояние Выполнен. 7. На панели инструментов нажмите кнопку State (Состояние). 8. Поместите состояние на диаграмму внутрь суперсостояния. 9. Назовите состояние Инициализация. 10. На панели инструментов нажмите кнопку State (Состояние). 11. Поместите состояние на диаграмму внутрь суперсостояния. 12. Назовите состояние Выполнение заказа приостановлено. Описание состояний 1. Дважды щелкните мышью на состоянии Инициализация. 2. Перейдите на вкладку Detail (Подробно). 3. Щелкните правой кнопкой мыши в окне Actions (Действия). 4. В открывшемся меню выберите пункт Insert (Вставить). 5. Дважды щелкните мышью на новом действии. 6. Назовите его Сохранить дату заказа. 7. Убедитесь, что в окне When (Когда) указан пункт On Entry (На входе). 8. Повторив шаги 3-7, добавьте следующие действия: Собрать клиентскую информацию, в окне When укажите DO (Выполнять между входом и выходом) Добавить к заказу новые позиции, укажите DO 9. Нажмите два раза на ОК, чтобы закрыть спецификацию. 10. Дважды щелкните мышью на состоянии Отменен. 11. Повторив шаги 2-7, добавьте действия: Сохранить дату отмены, укажите On Exit (На выходе) 12. Нажмите два раза на ОК, чтобы закрыть спецификацию. 13. Дважды щелкните мышью на состоянии Выполнен. 14. Повторив шаги 2-7, добавьте действие: Выписать счет, укажите On Exit 15. Нажмите два раза на ОК, чтобы закрыть спецификацию. Добавление переходов . Нажмите кнопку Transition (Переход) панели инструментов. 2. Щелкните мышью на начальном состоянии. 3. Проведите линию перехода к состоянию Инициализация. 4. Повторив шаги с первого по третий, создайте следующие переходы: От состояния Инициализация к состоянию Выполнение заказа приостановлено От состояния Выполнение заказа приостановлено к состоянию Выполнен От суперсостояния к состоянию Отменен От состояния Отменен к конечному состоянию От состояния Выполнен к конечному состоянию 5. На панели инструментов нажмите кнопку Transition to Self (Переход к себе). 6. Щелкните мышью на состоянии Выполнение заказа приостановлено Описание переходов 1. Дважды щелкнув мышью на переходе от состояния Инициализация к состоянию Выполнение заказа приостановлено, откройте окно спецификации перехода. 2. В поле Event (Событие) введите фразу Выполнить заказ. 3. Щелкнув на кнопке ОК, закройте окно спецификации. 4. Повторив шаги с первого по третий, добавьте событие Отменить заказ к переходу между суперсостоянием и состоянием Отменен. 5. Дважды щелкнув мышью на переходе от состояния Выполнение заказа приостановлено к состоянию Выполнен, откройте окно его спецификации. 6. В поле Event (Событие) введите фразу Добавить к заказу новую позицию. 7. Перейдите на вкладку Detail (Подробно). 8. В поле Guard Condition (Сторожевое Условие) введите Не осталось незаполненных позиций. 9. Щелкнув на кнопке ОК, закройте окно спецификации. 10. Дважды щелкните мышью на рефлексивном переходе (Transition to Self) состояния Выполнение заказа приостановлено. 11. В поле Event (Событие) введите фразу Добавить к заказу новую позицию. 12. Перейдите на вкладку Detail (Подробно). 13. В поле Guard Condition (Сторожевое Условие) введите Остаются незаполненные позиции. 14. Щелкнув на кнопке ОК, закройте окно спецификации. Лабораторная работа 5. Построение диаграммы Активности для варианта использования "Выполнить поставку Заказа"   Побеседовав с Павлом, Антон понял, что необходимо согласовать логику реализации еще одного варианта использования "Выполнить поставку заказа". Стало ясно, что здесь возможны несколько альтернативных потоков управления. Для таких ситуаций более удобно использовать не диаграммы взаимодействия, приспособленные для единственного потока, а диаграмму активности. Описание варианта использования. При оформлении заказа проверяют каждую содержащуюся в нем позицию, чтобы убедиться в наличии соответствующих товаров на складе. После этого выписываются товары для реализации заказа. Во время выполнения этих процедур одновременно проверяется прохождение платежа. Если платеж прошел, и товары имеются на складе, то осуществляется их поставка. Если платеж прошел, но товары на складе отсутствуют, то заказ ставится в ожидание. Если платеж не прошел, то заказ аннулируется. Этапы выполнения упражнения. 1. Найдите в браузере вариант использования "Выполнить поставку заказа" . Щелкните на классе правой кнопкой мыши и в открывшемся меню укажите пункт New > Activity Diagram (Создать диаграмму активности). . Назвите диаграмму "Выполнить поставку" и откройте ее двукратным щелчком мыши . На панели инструментов щелкните мышкой на элементе Swimline, затем на поле диаграммы. На диаграмме появится разделительная линия ("водная дорожка"). . Установите курсор на заголовок NewSwinlane и нажмите правую клавишу мыши. В выпадающем списке нажмите Select inbrousere. В браузере выделится этот объект. Нажав правую клавишу мыши в выпадающем списке выберете Open Specefication и откройте спецификацию. Измените поле Name на Клерк. Выберите в поле Class Клерк в магазине. . Выполните заново пункты 5-6 и присвойте полю Name Система, Class - Бухгалтерская система. 7. Найдите в браузере сплошной черный кружок (начальное состояние). Перенесите его на дорожку Клерк. 8. Выберете из панели инструментов объект Activity и помемтите его на диаграмму в "дорожку" Клерк. Измените имя объекта на ”Получить заказ”. . Повторите предыдущий этап, создайте на "дорожке" Клерк 4 новых Activity и присвойте им имена Проверить позицию заказа, закрепить позицию за заказом, Поставить заказ в ожидание, Скомплектовать заказ 10. Поместите на "дорожку" 2 новых объекта End State (конечное состояние). Одному из них измените поле Name на "Выполнить поставку" . На дорожку Система поместите новый объект Activity и присвойте полю Name "Проверить платеж”. На эту же дорожку поместите новый объект End State и измените в его спецификации поле Name на "Отменить заказ". . Поместить на "дорожку" Клерк 2 объекта Horisontal Sinhronization (горизонтальная синхронизация). Присвойте полю Nameспецификации одного объекта "1", другого - "2". . Поместить на "дорожку" Клерк объект Dicision (выбор). Через спецификацию присвойте полю Name "Позиция имеется?". . Поместить на "дорожку" Система объект Dicision. Присвойте полю Name "Деньги поступили?". . Щелкните мышкой на панели инструментов объекте - стрелке State Transition (состояние перехода). Затем щелкните мышкой на диаграмме объекта начальное состояние. Удерживая кнопку мыши перенесите курсор на активность ”Получить заказ" и лишь затем отпустить курсор. В результате два объекта будут соединены стрелкой. . Выполните этап 14, соединив стрелкой объект Активность "Получить заказ" с объектом Horisontal Sinhronization 1. . Соедините этими же стрелками объекты 1 и "Проверить платеж", 1 и "Проверить позицию заказа", "Проверить заказ" и "Деньги подступили?", "Деньги поступили?" и "Отменить заказ", "Проверить позицию заказа" и "Позиция имеется", "Позиция имеется" и "Закрепить позицию за заказом", "Деньги получены?" и 2, "Закрепить позицию за заказом" и 2, "Позиция имеется?" и "Поставить заказ в ожидание", 2 и "Скомплектовать заказ", "Скомплектовать заказ" и "Выполнить поставку", "Поставить заказ в ожидание" и объект Конечное состояние (без имени). . Присвоим некоторым стрелкам наименование полю Event (условие перехода). Для этого, установим курсор на стрелке, соединяющей "Деньги получены?" и "Отменить заказ". Двукратным щелчком мыши откроем окно спецификации. В поле Eventвведем "Нет". . Выполним пункт 18 для стрелки, соединяющей "Деньги получены?" и 2 и присвойте Event "Да". Аналогично для стрелки соединяющей "Позиция имеется?" и "Закрепить позицию за заказом" присвоить Event "Да". Стрелке, соединяющей "Позиция имеется?" и "Поставить заказ в ожидание" - "Нет". . Добавим элементарные действия (Actions) к активности "Проверить позицию заказа". Установим курсор на "Проверить позицию заказа" и двукратным щелчком мыши откроем окно спецификации. Откроем закладку Actions. Установим курсор на свободное поле и нажмем правую клавиши мыши. В выпадающем меню нажмем Insert. В появившейся заставке в поле When выберем Entry (на входе в активность), В поле Name введем "Просмотреть спецификацию к заказу". Нажать Ok. Вновь нажмем курсор правой мыши и введем новое действие. Полю When прсвоим Do (промежуток между входом и выходом), а полю Name "Найти новую позицию". При вводе третьей активности полю When присвойте Exit (выход), а полю Name "Передать результаты поиска". . Путем перемещения объектов (установить курсор мыши - нажать - тащить - отпустить) привести диаграмму к виду, показанному на рис.6.     Рис.6 Диаграмма активности для варианта использования "Выполнить поставку заказа"     Лабораторная работа 6. Пакеты и классы   В этом упражнении необходимо сгруппировать в пакеты классы, созданные при выполнении предыдущих работ. Затем нужно будет построить несколько диаграмм Классов и показать на них классы и пакеты системы. Создание диаграммы Классов Объедините обнаруженные классы в пакеты. Создайте диаграмму Классов для отображения пакетов, диаграммы Классов, для представления классов в каждом пакете и диаграмму Классов для представления всех классов варианта использования "Ввести новый заказ". Этапы выполнения упражнения Создание пакетов 1. Щелкните правой кнопкой мыши на Логическом представлении браузера. 2. В открывшемся меню выберите пункт New > Package (Создать >Пакет). 3. Назовите новый пакет Сущности. 4. Повторив шаги 1-3, создайте пакеты Границы и Управление. Создание Главной диаграммы Классов 1. Дважды щелкнув мышью на Главной диаграмме Классов, находящейся под Логическим представлением браузера, откройте ее. 2. Перетащите пакет Сущности из браузера на диаграмму. 3. Перетащите пакеты Границы и Управление из браузера на диаграмму. Главная диаграмма Классов должна выглядеть, как показано на рис.7   Рис.7 Главная диаграмма классов в логическом представлении браузера.   Создание диаграммы Классов для сценария "Ввести новый заказ" с отображением всех классов 1. Щелкните правой кнопкой мыши на Логическом представлении браузера. 2. В открывшемся меню выберите пункт New > Class Diagram (Создать > Диаграмма Классов). 3. Назовите новую диаграмму Классов: Ввод нового заказа. 4. Дважды щелкнув мышью на этой диаграмме в браузере, откройте ее. 5. Перетащите из браузера все классы (Выбор_заказа, Заказ_деталей, упр_заказами, Заказ, Упр_транзакциями. Объединение классов в пакеты 1. В браузере перетащите класс выбор_заказа на пакет Границы. 2. Перетащите класс заказ_деталей на пакет Границы. 3. Перетащите классы Упр_заказами и Упр-транзакциями на пакет Управление. 4. Перетащите класс Заказ на пакет Сущности. Классы и пакеты в браузере показаны на рис.9   Рис.8 Представление пакетов и классов   Добавление диаграмм Классов к каждому пакету 1. В браузере щелкните правой кнопкой мыши на пакете Границы. 2. В открывшемся меню выберите пункт New > Class Diagram (Создать > Диаграмма Классов). 3. Введите имя новой диаграммы - Main (Главная). 4. Дважды щелкнув мышью на этой диаграмме, откройте ее. 5. Перетащите на нее из браузера классы выбор_заказа и заказ_деталей. 6. Закройте диаграмму. В браузере щелкните правой кнопкой мыши на пакете Сущности. 8. В открывшемся меню выберите пункт New > Class Diagram (Создать > Диаграмма Классов). . Введите имя новой диаграммы - Main (Главная). . Дважды щелкнув мышью на этой диаграмме, откройте ее. . Перетащите на нее из браузера класс Заказ. . Закройте диаграмму . В браузере щелкните правой кнопкой мыши на пакете Управление . В открывшемся меню выберите пункт New > Class Diagram (Создать > Диаграмма Классов). . Введите имя новой диаграммы - Main (Главная). . Дважды щелкнув мышью на этой диаграмме, откройте ее. . Перетащите на нее из браузера классы Упр_заказами и Упр_транзакциями . Закройте диаграмму Лабораторная работа 7. Уточнение методов и свойств классов   В этом упражнении к описаниям операций будут добавлены детали, включая параметры и типы возвращаемых значений, и определены атрибуты классов Постановка проблемы Для определения атрибутов классов был проанализирован поток событий. В результате к классу Заказ диаграммы Классов были добавлены атрибуты Номер заказа и Имя клиента. Так как в одном заказе можно указать большое количество товаров и у каждого из них имеются свои собственные данные и поведение, было решено моделировать товары как самостоятельные классы, а не как атрибуты класса Заказ. Добавление атрибутов и операций Добавим атрибуты и операции к классам диаграммы Классов "Ввод нового заказа". При этом используем специфические для языка особенности. Установим параметры так, чтобы показывать все атрибуты, все операции и их сигнатуры. Применим нотацию UML. Этапы выполнения упражнения Настройка 1. В меню модели выберите пункт Тооls > Options (Инструменты >Параметры). 2. Перейдите на вкладку Diagram. 3. Убедитесь, что флажок Show visibility (Показать видимость) установлен. 4. Убедитесь, что флажок Show stereotyps (Показать стереотипы) установлен. 5. Убедитесь, что флажок Show operation signatures (Показать сигнатуры операций) установлен. . Убедитесь, что флажки Show all attributes (Показать все атрибуты) и Show all operations (Показать вое операции) установлены. . Убедитесь, что флажки Suppress attributes (Подавить атрибуты) и Suppress operations (Подавить операции) сброшены. 8. Перейдите на вкладку Notation (Нотация). 9. Убедитесь, что флажок Visibility as icons (Отображать пиктограммы) сброшен. Добавление нового класса . Найдите в браузере диаграмму Классов варианта использования "Ввести новый заказ". 2. Дважды щелкнув мышью на диаграмме, откройте ее. 3. Нажмите кнопку С1аss панели инструментов. 4. Щелкните мышью внутри диаграммы, чтобы поместить туда новый класс. 5. Назовите его Позиц_заказа. 6. Назначьте этому классу стереотип Entity. 7. В браузере перетащите класс в пакет Сущности. Добавление атрибутов 1. Щелкните правой кнопкой мыши на классе Заказ. 2. В открывшемся меню выберите пункт New Attribute (Создать атрибут), . Введите новый атрибут: OrderNumber: Integer . Нажмите клавишу Enter . Введите следующий атрибут: CustomerName: String. . Повторив шаги 4 и 5, добавьте атрибуты: OrderDate: Date OrderFillDate: Date Если тип атрибута не появляется в выпадающем списке, то введите его от руки и он далее будет появляться. 7. Щелкните правой кнопкой мыши на классе Позиц_заказа. 8. В открывшемся меню выберите пункт New Attribute (Создать атрибут). 9. Введите новый атрибут: ItemID: Integer. . Нажмите клавишу Enter. 11. Введите следующий атрибут: ItemDescription: String. Добавление операций к классу Позиц_заказа 1. Щелкните правой кнопкой мыши на классе Позиц_заказа. 2. В открывшемся меню выберите пункт New Opration (Создать операцию). 3. Введите новую операцию: Создать () 4. Нажмите клавишу Enter. 5. Введите следующую операцию: Взять_информацию () 6. Нажмите клавишу Enter. 7. Введите операцию: Дать_информацию () Подробное описание операций с помощью диаграммы Классов 1. Щелкнув мышью на классе Заказ, выделите его. 2. Щелкните на этом классе еще раз, чтобы переместить курсор внутрь. 3. Отредактируйте операцию Создать (), чтобы она выглядела следующим образом: Создать (): Воо1еаn 4. Отредактируйте операцию Взять_информацию: Взять_информацию (OrderNum: Integer, Customer: String, OrderDate: Date, FillDate: Date): Boolean 5. Отредактируйте операцию Дать_информацию; Дать_информацию (): String Подробное описание операций с помощью браузера 1. Найдите в браузере класс Позиц_заказа. 2. Раскройте этот класс, щелкнув на значке "+" рядом с ним. В браузере появятся атрибуты и операции класса. 3. Дважды щелкнув мышью на операции Дать_информацию (), откройте окно ее спецификации: 4. В раскрывающемся списке Return class (Возвращаемый класс) укажите String. 5. Щелкнув мышью на кнопке ОК, закройте окно спецификации операции. 6. Дважды щелкните в браузере на операции Дать_информацию () класса Позиц_заказа, чтобы открыть окно ее спецификации. 7. В раскрывающемся списке Return class укажите Воо1еаn. 8. Перейдите на вкладку Detail (Подробно). 9. Щелкните правой кнопкой мыши в области аргументов, чтобы добавить туда новый параметр: 10. В открывшемся меню выберите пункт Insert (Вставить). Rose добавит аргумент под названием argname. 11. Щелкнув один раз на этом слове, выделите его и измените имя аргумента на ID. 12. Щелкните на колонке Туре (Тип). В раскрывающемся списке типов выберите Integer (Если этого либо иного необходимого типа не будет - введите его вручную). 13. Щелкните на колонке Default (По умолчанию), чтобы добавить значение аргумента по умолчанию. Введите число 0. 14. Нажав на кнопку ОК, закройте окно спецификации операции. 15. Дважды щелкните на операции Создать () класса Позиц_заказа, чтобы открыть окно ее спецификации. 16. В раскрывающемся списке Return class укажите Воо1еаn. 17. Нажав на кнопку ОК, закройте окно спецификации операции. Подробное описание операций 1. Используя браузер или диаграмму Классов, введите следующие сигнатуры операций класса Заказ_деталей: Открыть (): Boolean Сохранить заказ (): Boolean 2. Используя браузер или диаграмму Классов, введите сигнатуру операций класса Выбор_заказа: Создать (): Воо1еаn 3. Используя браузер или диаграмму Классов, введите сигнатуру операций класса Упр_заказами: Сохранить заказ (OrderID: Integer): Воо1еаn 4. Используя браузер или диаграмму Классов, введите сигнатуры операций класса Упр_транзакциями: Сохранить заказ (OrderID: Integer): Boolean Сохранить информацию (): Integer Лабораторная работа 8. Описание связей между классами В этом упражнении определяются связи между классами, участвующими в варианте использования "Ввести новый заказ". Постановка задачи Чтобы найти связи, были просмотрены диаграммы Последовательности. Все взаимодействующие там классы нуждались в определении соответствующих связей на диаграммах Классов. После обнаружения связи были добавлены на диаграммы классов. Добавление связей Добавим связи к классам, принимающим участие в варианте использования "Ввести новый заказ". Этапы выполнения упражнения Настройка 1. Найдите в браузере диаграмму Классов "Ввод нового заказа", 2. Дважды щелкнув на диаграмме, откройте ее. 3. Проверьте, имеется ли в панели инструментов диаграммы кнопка Unidirectional Association (Однонаправленная ассоциация). Если ее нет, продолжите настройку, выполнив шаги 4 и 5. Если есть, приступайте к выполнению самого упражнения. 4. Щелкните правой кнопкой мыши на панели инструментов диаграммы и в открывшемся меню выберите пункт Customize(Настроить), 5. Добавьте на панель кнопку Creates A Unidirectional Association (Создать однонаправленную ассоциацию). Добавление ассоциаций 1. Нажмите кнопку Unidirectional Association панели инструментов. 2. Проведите ассоциацию от класса выбор_заказа к классу заказ_деталей. 3. Повторите шаги 1 и 2, создав ассоциации: От класса заказ_деталей к классу упр_заказами От класса упр_заказами к классу Заказ От класса упр_заказами к классу упр_транзакциями От класса упр_транзакциями к классу Заказ От класса упр_транзакциями к классу Позиц_заказа От класса Заказ к классу Позиц_заказа 4. Щелкните правой кнопкой мыши на однонаправленной ассоциации между классами выбор_заказа и заказ_деталей класса выбор_заказа. 5. В открывшемся меню выберите пункт Multiplicity > Zero or One (Множественность > - Нуль или один), 6. Щелкните правой кнопкой мыши на другом конце однонаправленной ассоциации. 7. В открывшемся меню выберите пункт Multiplicity > Zero or One (Множественность > Нуль или один), 8. Повторите шаги 4-7, добавив на диаграмму значения множественности для остальных ассоциаций, как показано на рис.10     Рис.10 Ассоциации сценария "Ввести новый заказ"   Лабораторная работа 9. Исключение кириллизованного текста в информации классов   Разработанные ранее модели, предназначенные для описания предметной области используют кириллизованную символику, недопустимую для большинства языков программирования. Выполните замену русского текста на латинский шрифт. Для этой цели сохраните предыдущую модель под другим именем и далее работайте с новым файлом (что бы при необходимости можно было бы вернуться к бизнес - процессам, описанным русским шрифтом). Этапы выполнения упражнения. Этап 1. Используя меню (Файл-> Сохранить как) сохраните данную модель под другим именем (например Заказ1) в той же папке, что и исходная модель. Работайте далее с копией модели (то есть Заказ1). Этап 2. Переименуйте классы и их спецификации таким образом, чтобы использовался только латинский шрифт. Замените имя класса Заказ_деталей на OrderDetail Выбор_заказа на OrderОptions Заказ на Order Упр_заказами на OrderMgr Позиц_заказа на OrderItem Упр_транзакциями на TransactionMgr Измените имена операций таким образом, чтобы рис.10 преобразовался в рис.11. Для этого, измените операцию класса OrderОptions Открыть () на Open () Класса OrderDetail Открыть () на Open () Сохранить заказ () на Save () Класса Order Ввести номер заказа, заказчика и число заказываемых предметов () на SetInfo () Сохранить_заказ () на Save () Класса OrderMgr Сохранить заказ () на SaveOrder () Класса TransactionMgr Сохранить заказ () на SaveOrder () Сохранить информацию о заказе () на Commit () Создать_заказ () на SubmitInfo () Класса OrderItem Создать () на Create () Взять_информацию () на GetInfo () Дать_информацию на SetInfo () Переименуйте имена пакетов Границы на Boundaries Сущности на Entity Контроль на Control Добавление стереотипов к классам 1. Щелкните правой кнопкой мыши на классе OrderOptions диаграммы. 2. В открывшемся меню выберите пункт Open Specification (Открыть спецификацию). 3. В поле стереотипа выберите из выпадающего списка слово Boundary (если его нет, то введите). 4. Нажмите на кнопку ОК. 5. Повторив шаги 1-4, свяжите классы OrderDetail со стереотипом Boundary, OrderMgr и TransactionMgr со стереотипом Control, а класс Order и OderItem - со стереотипом Entity. Теперь диаграмма Классов должна иметь вид, показанный на рис.11.     Рис.11 Основная диаграмма классов   Замечание. На диаграмме рис.11 возможно визуальное представление классов не в виде иконок, а в виде дополнительной строки текста с именем стереотипа. За этот вид отвечает метка установленная либо на icon либо на label (Class> Open Specefication> Options> Label) Лабораторная работа 10. Построение диаграммы компонентов   В настоящем разделе начинается построение физической модели системы (то есть программной системы). Этапы выполнения упражнения. Так как эта модель связана с конкретным языком программирования, то в настройках это необходимо отметить. Выполнить Tools>Options>Notations>Default Language и из выпадающего списка языков программирования выбрать Delphi. Создание пакетов компонентов 1. Щелкните правой кнопкой мыши на представлении компонентов в браузере. 2. В открывшемся меню выберите пункт New > Package (Создать > Пакет}. 3. Назовите пакет Entities (Сущности). 4. Повторив шаги с первого по третий, создайте пакеты Boundaries (Границы) и Control (Управление). Добавление пакетов на Главную диаграмму Компонентов 1. Откройте Главную диаграмму Компонентов, дважды щелкнув на ней мышью, 2. Перетащите пакеты Entities, Boundary и Control из браузера на Главную диаграмму. Отображение зависимостей между пакетами 1. Нажмите кнопку Dependency (Зависимость) панели инструментов. 2. Щелкните мышью на пакете Boundary Главной диаграммы Компонентов. 3. Проведите линию зависимости к пакету Control. 4. Повторив шаги 1 - 3, проведите зависимость от пакета Control к пакету Entities. В результате диаграмма примет вид рис.12   Рис.12 Зависимости между пакетами   Добавление компонентов к пакетам и отображение зависимостей 1. Дважды щелкнув мышью на пакете Entities Главной диаграммы Компонентов, откройте Главную диаграмму Компонентов этого пакета. 2. Нажмите кнопку Package Specification (Спецификация пакета) панели инструментов. 3. Поместите спецификацию пакета на диаграмму. 4. Введите имя спецификации пакета - OrderItem_. . Повторив шаги 2-4, добавьте спецификацию пакета Order_. . Нажмите кнопку Dependency (Зависимость) панели инструментов. 7. Щелкните мышью на спецификации пакета OrderItem_. 8. Проведите линию зависимости к спецификации пакета OrderItem_. 9. С помощью описанного метода создайте следующие компоненты и зависимости: Для пакета Boundaries: Спецификацию пакета Orderоptions_ Спецификацию пакета OrderDetail_ Зависимости в пакете Boundaries: От спецификации пакета Orderоptions_ к спецификации пакета OrderDetai_l Для пакета Control: Спецификацию пакета OrderMgr_ Спецификацию пакета TransactionMgr_ Зависимости в пакете Control: От спецификации пакета OrderMgr_ к спецификации пакета TransactionMg_ Создание диаграммы Компонентов системы 1. Щелкните правой кнопкой мыши на представлении Компонентов в браузере. 2. В открывшемся меню выберите пункт New > Component Diagram (Создать > Диаграмма Компонентов). 3. Назовите новую диаграмму System. . Дважды щелкните на этой диаграмме мышью.