Проектный практикум. Учебное пособие для студентов, обучающихся по направлению 230700. 62 При кладная информатика
 Скачать 1.9 Mb.
|
Упражнение 13. Генерация описания базы данных на языке SQL S 0. 2. В открывшемся меню выберите пункт Data Modeler > Forward Engineer- откроется окно мастера ―Forward Engineering Wizard‖(рис. 44). 100 3. Щелкните по кнопке Next в открывшемся окне мастера "Forward Engineering Wizard". Рис. 44. Окно мастера Forward Engineering Wizard 4. Оставьте все флажки генерации языка описания данных (DDL) отмеченными (рис. 45) и щелкните по кнопке Next. 101 Рис. 45. Установка параметров генерации DDL 5. Укажите расположение и имя (указав расширение .sql) текстового файла с результатами генерации (рис. 46) и щелкните по кнопке Next. Рис. 46. Задание имени файла с результатами генерации DDL 102 Завершив генерацию, откройте созданный текстовый файл и просмот- рите результаты. Результаты генерации должны иметь следующий вид: CREATE TABLE T_Order ( OrderNumber NUMBER ( 10 ) NOT NULL, CustomerName VARCHAR2 ( 255 ) NOT NULL, OrderDate DATE NOT NULL, OrderFillDate DATE NOT NULL, T_Order_ID NUMBER ( 10 ) NOT NULL, CONSTRAINT PK_T_Order0 PRIMARY KEY (T_Order_ID) ) / CREATE TABLE T_OrderItem ( ItemID NUMBER ( 10 ) NOT NULL, ItemDescription VARCHAR2 ( 255 ) NOT NULL, T_Order_ID NUMBER ( 10 ), CONSTRAINT PK_T_OrderItem1 PRIMARY KEY (ItemID) ) / CREATE INDEX TC_T_OrderItem1 ON T_OrderItem (T_Order_ID) / ALTER TABLE T_OrderItem ADD ( CONSTRAINT FK_T_OrderItem0 FOREIGN KEY (T_Order_ID) REFERENCES T_Order (T_Order_ID)) / 103 1.10. Публикация разработанного проекта Упражнение 14. Публикация разработанного проекта Сделайте публикацию разработанного проекта в Web и ознакомьтесь с ее содержанием. 1.11. Количественная оценка UML диаграмм При построении диаграмм необходимо учитывать, что диаграмма должна легко читаться, следовательно, она не должна быть перегруженной количеством помещенных на нее элементов и связей между ними. В то же время диаграмма должна подробно отображать всю необходимую информа- цию. Для оценки информационной насыщенности диаграмм применяют ме- тодику количественной оценки. Методика количественной оценки и сравнения диаграмм UML строит- ся на присвоении элементам диаграмм оценок, зависящих от их информаци- онной ценности, а также от вносимой ими в диаграмму дополнительной сложности. Ценность отдельных элементов меняется в зависимости от типа диаграммы, на которой они находятся. Словарь языка UML включает два вида строительных блоков: сущно- сти и отношения. Сущности - это абстракции, являющиеся основными эле- ментами модели. Отношения связывают различные сущности. Количественную оценку диаграммы можно выполнить по следующей формуле: где S оценка диаграммы; S obj - оценки для элементов диаграммы; S Lnk - оценки для связей на диаграмме; O bj - число объектов на диаграмме; Т оbj число типов объектов на диаграмме; 104 Т Lnк - число типов связей на диаграмме. Если диаграмма содержит большое число связей одного типа (напри- мер, модель БД), то число и тип связей можно не учитывать и формула расчета приводится к виду: Если на диаграмме показаны атрибуты и операции классов, можно учесть их при расчете, при этом оценка прибавляется к оценке соответст- вующего класса: где S cls - оценка операций и атрибутов для класса; О р - число операций у класса; A rt - число атрибутов у класса. При этом учитываются только атрибуты и операции, отображенные на диаграмме. Далее в табл. 9 и 10 приводятся оценки для различных типов элементов и связей. Таблица 2. Основные элементы языка UML Тип элемента Оценка для элемента Класс (class) 5 Интерфейс (interface) 4 Прецедент (use case) 2 Компонент (component) 4 Узел (node) 3 Процессор (processor) 2 Взаимодействие (interaction) 6 Пакет (package) 4 Состояние (state) 4 Примечание (node) 2 105 Таблица 3 Основные типы связей языка UML Тип связи Оценка для связи Зависимость (dependency) 2 Ассоциация (association) 1 Агрегирование (aggregation) 2 Композиция (composition) 3 Обобщение (generalization) 3 Реализация (reali2ation) 2 Остальные типы связей должны рассматриваться как ассоциации. Недостатком диаграммы является как слишком низкая оценка (при этом диаграмма недостаточно информативна), так и слишком высокая оценка (при этом диаграмма обычно слишком сложна для понимания). В табл. 4 приведены диапазоны оптимальных оценок для основных ти- пов диаграмм. Таблица 4. Диапазоны, оценок для диаграмм UML Тип диаграммы Диапазон оценок Классов (class) - с атрибутами и операциями 5 - 5,5 Классов (class) без атрибутов и операций 3 - 3,5 Компонентов (component) 3,5 - 4 Вариантов использования (use case) 2,5-3 Развертывания (deployment) 2 2,5 Последовательности (sequences) 3 - 3,5 Кооперативная (cooperative) 3,5-4 Пакетов (package) 3,5 - 4 Состояний (state) 2,5 - 3 Приведем пример оценки простой диаграммы классов (рис. 47) по при- веденной выше методике. Диаграмма содержит три класса без операций и атрибутов, следова- тельно T obj = 1, S obj = 15 и O bj =3. В качестве связей на диаграмме использу- ются ассоциация, агрегирование и обобщение, следовательно S Lnk = 6 и Т Lnk = 3. 106 Рис. 47. Диаграмма классов Определим численную оценку диаграммы классов: То есть численная оценка для данной диаграммы равна 3,5. Полученное значение лежит в рекомендуемом диапазоне (табл. 4). 107 2. СОЗДАНИЕ БАЗЫ ТРЕБОВАНИЙ К ПРОЕКТУ 2.1. Инструментальное средство IBM Rational Requisitepro 2.1.1. Общие сведения Назначение RequisitePro - управление требованиями (организация тре- бований и отслеживание их изменений в жизненном цикле ПО). Каждое тре- бование имеет определенный тип (используемый для классификации требо- ваний) и наименование. Требования содержат текст и обладают следующим стандартным набором атрибутов, который может быть расширен при необ- ходимости: • приоритет (высокий, средний, низкий); • статус (предложено, одобрено, утверждено, реализовано, вери- фицировано); • стоимость (высокая, средняя, низкая или числовое значение); • сложность реализации (высокая, средняя, низкая); • стабильность (высокая, средняя, низкая); • исполнитель. Требования могут быть созданы в документе или в представлении (view). Вся информация о требованиях сохраняется в базе данных. Проект RequisitePro включает базу данных требований и набор связан- ных с ней документов (например, документы вариантов использования в Re- quisitePro содержат их обычные текстовые описания). Требования в этих до- кументах связаны с базой данных, в которой хранится дополнительная ин- формация о требованиях - атрибуты, связи трассировки, сведения о версии, история изменений, уровень обеспечения безопасности проекта и др. Из базы данных RequisitePro можно запросить информацию о требовании для провер- ки его выполнения и оценки влияния изменения. Проект обычно создается 108 менеджером проекта, который определяет его структуру и устанавливает права доступа для участников проекта. Проектная база данных - база данных требований, управляемая Requisi- tePro (одна из трех физических баз данных — Microsoft Access, Oracle или Microsoft SQL Server). Каждый проект RequisitePro имеет собственную базу данных. Основным элементом интерфейса RequisitePro является Проводник (Explorer). В его окне отображаются в иерархической упорядоченности раз- личные рабочие продукты проекта (документы, требования, представления и содержащие их пакеты). Проводник позволяет осуществлять навигацию по проекту. 2.1.2. Создание проекта RequisitePro Для создания проекта RequisitePro: 1. Запустите RequisitePro из меню программ, сразу после запуска может появиться интерфейс системной помощи Let's Go. Закройте его. Затем появится диалоговое окно "Open Project". Оно позволяет выбрать проект для работы с ним (вкладка "Existing") или создать новый проект (вкладка "New"). 2. После выбора вкладки "New" появится диалоговое окно "Create Project" (рис. 48). Здесь необходимо указать шаблон, на основе которого бу- дет создан новый проект. Шаблоны "Composite Template‖, "Traditional Tem- plate" и "Use Case Template" содержат готовые наборы типов требований и типов документов, которые можно использовать для того, чтобы приступить к новому проекту RequisitePro. При выборе одного из указанных шаблонов эти типы требований и документов будут добавлены в новый проект. Описа- ние выделенного шаблона можно получить в нижнем поле окна "Create Project". Выбор пустого шаблона "Blank" позволит создать новый проект с чистого листа. Выбор "Make New Template" запускает специальный мастер, позволяющий самостоятельно построить новый шаблон на основе имеюще- 109 гося проекта. При этом в шаблон войдут уже имеющиеся требования и доку- менты этого проекта. Рис. 48.Диалоговое окно Create Progect 3. Выберите шаблон "Blank" и щелкните по кнопке ОК. Появится новое диалоговое окно "Rational RequisitePro Project Properties" (рис. 49), в котором необходимо указать название создаваемого проекта, за- ранее созданную папку на диске (где будут храниться файлы проекта), тип базы данных (эта база данных будет содержать требования проекта и допол- нительную информацию) и описание проекта. 4. Щелкните по кнопке ОК для создания проекта. Проект появится в окне Проводника. Если появится сообщение "Project directory does not exist. Do you want to create it?", щелкните по кнопке Yes. 110 Рис. 49. Диалоговое окно Свойства проекта 2.1.3. Создание типов требований в проекте RequisitePro Перед описанием требований необходимо определить их типы: 1. Выберите пункт меню File > Properties, появится диалоговое окно "Project Properties". Для добавления новых типов требований активизируйте вкладку "Requirement Types" (рис. 50). Рис. 50. Окно Свойства проекта (Типы требований) 111 Для добавления нового типа требований нужно щелкнуть по кнопке "Add...", а для редактирования существующего – по кнопке "Edit...". Затем заполните следующие поля в открывшемся диалоге "Requirement Туре" (рис. 51): "Name" - название типа требования (обязательное поле). "Description‖ - описание типа требования. "Initial Requirement #" - уникальный номер, который будет при- своен первому требованию данного типа и станет увеличиваться на единицу для всех последующих (обязательное поле). Рис. 51. Установка типа требования "Allow External Traceability" - следует активировать, если требо- вания этого типа будут связываться с требованиями из других проектов. "Requirement Must Contain" - слово или простая фраза, содержа- щие не более 32 символов, которые обязательно должны входить в состав требований данного типа (RequisitePro будет выводить 112 предупреждающее сообщение, если при создании требований данного типа это условие не будет выполнено). "Requirement Tag Prefix" - префикс, который добавляется всем требованиям данного типа (обязательное поле). "Requirement Color" и "Requirement Style" – характеристики фор- матирования требований данного типа, с помощью которых по- следние выделяются в документах Microsoft Wоrd (выбрать из списка). 3. Щелкните по кнопке ОК и повторите действия для следующего типа требований. 2.1.4. Определение атрибутов требований Для созданных типов требований необходимо определить атрибуты, которые позволяют ввести метрики для оценки требований с точки зрения пользователя. Некоторые атрибуты определяются только для служебных целей и соз- даются автоматически при выполнении определенных операций. Например, атрибуты "Roseltemld", "RoseModePath" и "RoseType" создаются при выпол- нении интеграции некоторой модели Rose с проектом RequisitePro. Для добавления или изменения атрибутов нужно активизировать вкладку "Attributes". В левом окне группы "Requirement Attributes" перечислены основные атрибуты типа требования, выбранного в "Requirement Туре". Если выделен один из этих атрибутов, то справа выводится дополнительная информация. Активный элемент управления "Labels for Attributes" означает, что кнопки группы "Requirement Attributes" позволяют выполнять соответст- вующие операции над атрибутами списка (добавить атрибут - кнопка "Add...", изменить свойства атрибута – кнопка "Edit...", удалить атрибут - "Delete‖, передвинуть атрибут в списке — соответственно кнопки "Move Up‖ 113 и "Move Down"). Щелчок по кнопке "Add..." приводит к появлению диалого- вого окна "Add Attribute". Поля для заполнения: "Label" - название атрибута. "Туре" - тип атрибута (например, список значений, текстовая строка, целочисленное поле, поле даты и т.д.). "List Values" - список возможных значений атрибута (выводится, если в "Туре" выбран список). "Deafult Value" — значение атрибута, устанавливаемое по умол- чанию для создаваемых требований (выводится, если в "Туре" указан какой-либо простой тип, например, строковый). "Hidden from display" - флажок, установка которого позволяет скрывать данный атрибут в представлениях RequisitePro. "Change affect suspect" — флажок, установка которого окажет влияние на состояние трассируемых (по отношению к текущему) требований при изменении данного атрибута (в этом случае из- менение атрибута приведет к установке всех трассируемых тре- бований в состояние "подозрительных", т.е. представление RequisitePro будет приравнивать изменение атрибута к измене- нию самого требования). При создании нового типа требований RequisitePro по умолчанию соз- дает для него начальный набор атрибутов, который можно взять за основу. В проекте системы регистрации заказов удалите существующие атри- буты для каждого созданного типа требований и создайте следующие (рис. 52): "Приоритет" (список значений; возможные значения: "Высокий", Средний'', "Низкий") - приоритет функционального требования или варианта использования; 114 "Состояние" (список значений; возможные значения: "Предложе- но", "Одобрено", "Реализовано", "Протестировано") - состояние, в котором находится процесс реализации требования на данный момент; "Сложность реализации" (список значений; возможные значения: "Высокая", ―Средняя", "Низкая") - оценочная сложность реализа- ции требования; "Ответственный" (строка) - указывается фамилия ответственного за реализацию требования. Рис. 52. Создание атрибутов требований 2.1.5. Создание типов документов Каждый документ RequisitePro должен иметь свой тип, который опре- деляет основное назначение этого документа (область использования в про- екте). Для создания нового типа документов необходимо активизировать вкладку "Document Types" и щелкнуть по кнопке "Add...". 115 Откроется диалоговое окно "Document Туре" (рис. 53). Поля для запол- нения: "Name" - название типа документа (обязательное поле); "Description" - описание типа документа; "File Extension" - расширение, с которым будут сохраняться фай- лы документов данного типа (обязательное поле); "Default Requirement Type‖ — тип требования по умолчанию (обязательное поле); "Outline" - указание на шаблон Microsoft Word, который будет использоваться при создании новых документов данного типа. Для проекта системы регистрации создадим два типа документов: концепция (рис. 53) и спецификация варианта использования (рис. 54). Рис. 53. Определение типа документа Концепция 116 Рис. 54. Определение типа документа Варианты использования 2.1.6. Связывание модели Rose и проекта RequisitePro Для использования модели Rose совместно с RequisitePro необходимо, чтобы в Rose было активизировано соответствующее встроенное средство (Add-In). Для этого нужно выбрать пункт меню "Add-Ins/Add-In Manager...", что приведет к появлению окна "Add-In Manager", и проконтролировать, что- бы пункт"RequisitePro‖ (рис. 55) был активен. В результате появятся дополнительные пункты в главном и различных контекстных меню, позволяющие работать с RequisitePro из среды Rose. Затем нужно связать текущий файл модели Rose с проектом Requisite- Pro с помощью пункта меню "Tools/Rational Requisite Pro/Associate Model To Project". 117 Рис. 55. Установка связи Rose c RequisitePro В открывшемся окне "Associate Model To RequisitePro Project" следует указать проект RequisitePro, в который будут экспортированы варианты ис- пользования (рис. 56), а также типы требований и документов по умолчанию, с которыми будут автоматически связаны экспортированные варианты ис- пользования. В дальнейшем указанные типы могут быть заменены на любые другие с помощью этого окна. Рис. 56. Установка связи модели Rose c RequisitePro 118 2.1.7. Экспорт вариантов использования из модели Rose в проект RequisitePro Рассмотрим экспорт вариантов использования на примере системы регистрации заказов. Для экспорта варианта использования следует выбрать пункт его контекстного меню '‗Requirement Properties/New...". При этом появится форма добавления требований "Requirement Properties..." из RequisitePro (рис. 57). Рис. 57. Добавление свойства требования Эта форма позволяет установить значения атрибутов вариантов ис- пользования. Вкладка "Attributes" (рис. 58) , позволяет выполнить эту уста- новку, вкладка "Traceability" - создать связи с существующими требованиями любых типов, вкладка ―Hierarchy‖ -сформировать иерархию вариантов ис- пользования (вкладка "Hierarchy'‘). Щелчок по кнопке ОК приведет к созданию требования типа "Варианты использования" в базе данных RequisitePro. Таким образом, можно экспортировать все остальные варианты ис- пользования в проект RequisitePro. 119 Рис. 58. Установка атрибутов Требования, созданные в RequisitePro, следует перенести в пакет, пред- назначенный для их хранения (создать новые пакеты "Документы", "Требо- вания" и "Варианты использования" (рис. 59) с помощью контекстного меню проекта в Проводнике RequisitePro, используя пункты New > Package). Рис. 59. Создание требований 120 2.1.8. Создание представлений в проекте RequisitePro Представления (views) RequisitePro отображают в табличном или дре- вовидном виде сами требования с их атрибутами или связи трассировки меж- ду требованиями различных типов. Можно создавать представления трех ви- дов: матрица атрибутов (Attribute Matrix). Она показывает все требо- вания заданного типа с их атрибутами; матрица трассировки (Traceability Matrix). Она показывает связи трассировки между требованиями двух типов; дерево трассировки (Traceability Tree). Оно показывает цепочки связей трассировки, направленные от требований заданного типа или к ним. С помощью представлений можно выполнить следующие действия: создать и модифицировать наименование, текст и атрибуты тре- бования, а также его связи трассировки; упорядочить и отфильтровать информацию;. сохранить представление и вывести его на печать. Для создания матрицы атрибутов для вариантов использования созда- дим в Проводнике RequisitePro пакет "Матрицы атрибутов", выберем в его контекстном меню пункт New > View..., после чего появится окно "View Properties". Зададим в окне значения, как показано на рис. 60. 121 Рис. 60. Создание матрицы атрибутов После щелчка на кнопке ОК откроется окно матрицы атрибутов (рис.61). Рис. 61. Матрица атрибутов Упражнение 15. Создание проекта RequisitePro Ознакомьтесь с RequisitePro и создайте матрицу требований для вари- анта использования разработанного проекта. 122 3. ЗАДАНИЯ ДЛЯ САМОСТОЯТЕЛЬНОЙ РАБОТЫ В этом разделе с целью закрепления пройденного материала предлага- ется выполнить несколько работ по разработке проектов. 3.1. Задание 1. Ознакомление с методами построения графических моделей и описа- ний бизнес-процессов средствами комплекса продуктов IBM Rational Rose. Цель работы: ознакомление с принципами построения графических моделей и описаний бизнес-процессов; использование диаграмм для составления описаний. Язык UML выделяет следующие виды блоков, обозначающих понятия предметной области: сущности, отношения, диаграммы. Сущности представляют абстракции, являющиеся основными элемен- тами модели. Обычно сущность обозначает конкретный элемент предметной области. Основным типом сущности, используемым при моделировании, является класс – описание совокупности объектов с общими атрибутами, от- ношениями и семантикой. Отношения предназначены для связывания различных сущностей и выражения их взаимозависимостей. Рассматривают следующие типы отно- шений между сущностями: зависимость, ассоциация, обобщение и реализа- ция. Диаграммы группируют представляющие интерес совокупности сущ- ностей и их отношений. Диаграмма – это графическое представление набора элементов, изображаемое в виде графа, в вершинах которого расположены сущности, а в качестве ребер выступают отношения между этими сущностя- ми. 123 Задание В ходе выполнения работы необходимо разработать описание предмет- ной области, используя сущности и отношения между ними. Работа рассчитана на два академических часа. Порядок выполнения работы Определите точку зрения, цель и контекст модели. Запустите программный продукт IBM Rational Rose и выберите создание диаграммы классов. Выделите основные классы, присутствующие в системе и отрази- те их на диаграмме. Выделите атрибуты, характеризующие эти классы. Выделите отношения, связывающие выделенные классы. При рассмотрении отношений необходимо использовать все их типы. Определите, какие атрибуты классов используются в различных типах отношений. Варианты заданий Разработать описание объекта автоматизации, определив точку зрения, цель и контекст модели: 1. Система информационного учета состояния склада компьютер- ных комплектующих; 2. Рабочее место кассира, осуществляющего продажу товаров; 3. Система банковского обслуживания на основе банкомата, осу- ществляющего выдачу наличных и работу с картами; 4. Информационная система сопровождения процесса сборки и тес- тирования компьютерных серверов. Контрольные вопросы Какие типы сущностей можно выделить в процессе моделирова- ния? 124 Какова роль атрибутов в различных типах отношений между классами? Для чего необходим выбор контекста модели при составлении описания? Какие отношения между классами рассматривает отношение реа- лизации? Какие основные типы отношений используются при описании бизнес-процессов? 3.2. Задание 2. Разработка диаграмм для статического описания системы: классов, объектов, компонентов и развертывания средствами комплекса IBM Rational Rose. Цель работы: ознакомление с типами диаграмм, используемыми для описания статических аспектов системы; ознакомление с составными элементами и правилами составле- ния диаграмм классов, объектов, компонентов и развертывания; формирование навыков составления описаний статических аспек- тов бизнес-процессов. Для составления статического описания системы в языке UML исполь- зуются несколько типов диаграмм, каждая из которых предназначена для описания различных понятий системы. Диаграммы дополняют друг друга и позволяют получить комплексное описание объекта автоматизации. Диаграммой классов называют диаграмму, на которой показано мно- жество классов, интерфейсов, коопераций и отношений между ними. Ее изображают в виде множества вершин и дуг. 125 Диаграммы объектов позволяют моделировать экземпляры сущностей, которые содержатся в диаграммах классов. На диаграмме объектов показано множество объектов и отношений между ними в некоторый момент времени. Диаграммы компонентов показывают общую организацию компонен- тов системы и взаимосвязи между ними. Диаграммы развертывания используют для моделирования физических аспектов систем, связанных с выявлением конфигурации узлов, где происхо- дит обработка информации и компонентов, размещенных на каждом из уз- лов. Задание В ходе работы необходимо разработать статическое описание объекта автоматизации, используя различные типы диаграмм. Работа рассчитана на два академических часа. Порядок выполнения работы Выберите разрабатываемые типы диаграмм в программном про- дукте IBM Rational Rose и создайте их экземпляры. Определите основные сущности, присутствующие в системе, связывающие их отношения и разработайте соответствующую диаграмму классов. Определите экземпляры сущностей для каждого из классов, вхо- дящих в разработанную диаграмму классов и составьте диаграм- му объектов, показывающую состояние системы в некоторый момент времени. Разработайте диаграмму компонентов, отражающую структуру программного решения используемого на объекте автоматизации. Разработайте диаграмму развертывания, описывающую структу- ру вычислительной системы, используемой в решении. 126 Варианты заданий Разработайте статическое описание объекта автоматизации, используя различные типы диаграмм: 1. Информационная система учебной компьютерной лаборатории, предназначенной для подготовки специалистов производственно- го предприятия. 2. Информационная система оповещения о рейсах и регистрации пассажиров на посадку в аэропорте. 3. Система сопровождения производственного процесса сборки ав- томобилей, организованная на базе компьютерных интерфейсов. 4. Информационная система обслуживания очереди на основе тер- миналов самообслуживания в офисе оператора сотовой связи. 5. Информационная система предприятия, занимающегося автомо- бильными перевозками грузов с возможностью отслеживания маршрута передвижения автотранспорта при помощи мобильных коммуникаторов. Контрольные вопросы Какие основные типы диаграмм используются для описания ста- тического состояния системы? Какие основные компоненты используются при разработке диа- грамм развертывания? На каком этапе реализации проекта автоматизации разрабатыва- ются диаграммы компонентов? Какова последовательность разработки диаграмм, описывающих статическое состояние системы? 127 3.3. Задание 3. Разработка диаграмм для динамического описания системы: прецеден- тов, последовательностей, кооперации и видов деятельности для технологи- ческого участка средствами комплекса IBM Rational Rose. Цель работы: знакомство с типами диаграмм, используемых для описания ди- намических аспектов системы; знакомство с составными элементами и правилами составления диаграмм прецедентов, последовательностей, кооперации и ви- дов деятельности; получение навыков составления описаний динамических аспек- тов технологических процессов. Для составления динамического описания системы в языке UML ис- пользуются несколько типов диаграмм. Диаграммы прецедентов применяются для моделирования вида систе- мы с точки зрения прецедентов (или вариантов использования). Диаграммы прецедентов используются при моделировании поведения системы, подсис- темы или класса. На диаграммах взаимодействий показывают связи, включающие мно- жество объектов и отношений между ними, в том числе сообщения, которы- ми они обмениваются. Диаграмма последовательностей является диаграммой взаимодействий, акцентирующая внимание на временной упорядоченности сообщений. Диаграмма коопераций является диаграммой взаимодействий, основ- ное внимание в которой уделяется структурной организации объектов, обме- нивающихся сообщениями. Диаграмма деятельности представляет схему, показывающую, как по- ток управления переходит от одной деятельности к другой. 128 Задание В ходе работы необходимо разработать динамическое описание объек- та автоматизации, используя различные типы диаграмм. Работа рассчитана на два академических часа. Порядок выполнения работы • Запустите программную систему IBM Rational Rose, выберите нуж- ный тип диаграмм и создайте экземпляр. • Для рассматриваемой предметной области выделите основные 3-4 процесса, выполнение которых является определяющим для работы системы. • Для каждого из процессов определите его границы и основные со- ставляющие его элементы. • Составьте диаграммы классов, описывающие отношения между сущ- ностями, участвующими в процессе. • Составьте описания, используя заданный тип диаграмм, для каждого из выделенных процессов. • Определите варианты оптимизации структуры каждого из описанных процессов. Варианты заданий Необходимо разработать динамическое описание объекта автоматиза- ции, используя различные типы диаграмм: 1. Центр тестирования специалистов, прошедших обучение новой IT технологии. 2. Банковский офис, предоставляющий услуги по кредитованию физических лиц. 3. Система контроля доступа в корпус университета, организован- ная на основе пропускного пункта. 4. Сертификационный центр технической продукции, проводящий тестирование и выдачу сертификатов на соответствие системе ГОСТ Р. 129 Контрольные вопросы Какой тип диаграмм используется для моделирования требований к системе? Какова цель передачи сообщения в диаграммах взаимодействий от одного объекта к другому? Каким образом можно описать структурную упорядоченность потоков управления? Какие составные элементы используются при разработке диа- граммы видов деятельности? Каковы основные этапы моделирования рабочего процесса? 3.4. Групповой проект 3.4.1. Цель проведения группового проекта Практикум по курсу «Проектный практикум» выполняется в форме группового проекта группами студентов из 2-4 человек. Групповой проект выполняется в аудиторные часы. Целью практикума по дисциплине «Проектный практикум» является: приобретение практических навыков выполнения проекта разра- ботки бизнес приложения, включая анализ предметной области и разработки спецификации требований к программному обеспечению, моделирование бизнес-приложения средствами унифицированного языка моделирования UML, документирование проекта путем построения диаграмм различных ти- пов и текстовых описаний. Выполнение группового проекта является подго- товительным шагом перед выполнением курсового проекта. 3.4.2. Результаты выполнения проекта В результате выполнения группового проекта студенты разрабатывают и защищают следующие позиции: 130 Наименование Пояснение 1 Протокол встречи с заказчиком Текст 1-3 стр 2 Одностраничное описание Текст 1-3 стр 3 Спецификация требований (ТЗ) Текст, включающий диаграммы использования 4 Детальный проект архитектуры Текст, диаграммы всех типов, образы экранных форм, формулы, алгорит- мы, документация 3.4.3. Темы группового проекта Список тем групповых проектов для выбора: 1. Программное обеспечение банкомата. Краткое описание: банкомат по карте позволяет снимать наличные со счета по и/или печатать справку об остатке на счете. 2. Программное обеспечение мобильного телефона. Краткое описание: телефон позволяет звонить путем набора номера и выбором из телефонной книги, отвечать на звонки или блокировать их. Те- лефонная книга позволяет искать, добавлять и удалять записи. 3. Информационная система кафедры университета Краткое описание: Информационная система кафедры позволяет вы- полнять планирование нагрузки преподавателя на учебный год и учитывать реальную нагрузку. Каждый преподаватель читает определенный набор учебных дисциплин. Учебная дисциплина характеризуется количеством ау- диторных часов и периодом изучения в соответствии с учебным планом. 4. Информационная система библиотеки. Краткое описание: информационная система библиотеки позволяет ис- кать книги в своем каталоге, учитывать выдачу книг на руки и возврат книг, а также позволяет добавлять книги в фонд и списывать их. 5. Информационная система деканата. Краткое описание: информационная система деканата позволяет при- нимать и отчислять студентов, вести учет успеваемости по итогам сессии, переводить студентов из группы в группу и с курса на курс. 131 6. Информационная система склада. Краткое описание: информационная система склада позволяет учиты- вать поступление и уход товаров со склада, а также определять место хране- ния товаров на складе. 7. Система учета рабочего времени. Краткое описание: Система учета рабочего времени позволяет руково- дителям выдавать задания и отслеживать ход их выполнениям исполнителя- ми — вести учет рабочего времени, затраченного на выполнение каждого за- дания. 8. Информационная система жилищного агентства. Краткое описание: информационная система жилищного агентства по- зволяет квартиросъемщикам подобрать и снять жилье, а владельцам жилья — предложить и сдать жилье. 9. Система продажи билетов на футбол. Краткое описание: система продажи билетов позволяет покупать и сда- вать билеты и абонементы на матчи, проходящие на одном стадионе с нуме- рованными местами через несколько одновременно работающих касс. 3.4.4. Этапы выполнения проекта Используя рекомендуемые учебные материалы и анализируя выбран- ную предметную область, поэтапно разработать модель приложения, прото- тип программного обеспечения и программную документация для выбранной предметной области. Результаты работы по каждому этапу (кроме подготовительного) оформляются в виде указанных выше позиций и защищаются группой на оч- ной встрече с преподавателями. Образцы протокола встречи с заказчиком, одностраничного описания, спецификации требований и детального проекта архитектуры прилагаются. 132 Подготовительный этап. Выбор инструментов 1. Выбрать инструмент моделирования (инструмент должен быть доступен). 2. Выбрать инструмент разработки (инструмент должен быть дос- тупен и знаком). 3. Выбрать инструмент подготовки презентаций и документации (инструмент должен быть доступен) 4. Проверить совместимость инструментов (необходимо проверить возможность экспорта диаграмм из инструмента моделирования в инстру- мент подготовки презентаций, совместимость инструментов моделирования и разработки). 1 этап. Анализ предметной области 5. Провести собрание группы проекта и предварительный анализ выбранной предметной области методом «мозгового штурма» (составить протокол полученных результатов для использования внутри группы). 6. Провести интервью с заказчиком и составить протокол встречи с заказчиком (текстовый документ 1-3 стр., защищаемая позиция). 2 этап. Эскизное проектирование 7. Составить глоссарий предметной области. 8. Составить «одностраничное» описание проекта (текстовый доку- мент 1-3 стр., защищаемая позиция). 3 этап. Техническое задание 9. Составить спецификацию функциональных требований, для чего выполнить задания 10-15. 10. Идентифицировать действующих лиц системы. 11. Идентифицировать варианты использования системы. 12. Определить отношения между действующими лицами и вариан- тами использования. 133 13. Составить полную диаграмму (или несколько диаграмм) исполь- зования. 14. Определить, какие из вариантов использования (не менее трех) будут уточняться при последующем моделировании и будут реализованы в прототипе. 15. Реализовать выбранные варианты использования в виде записи сценария на псевдокоде или на естественном языке. 16. Определить нефункциональные и специальные требования, если они необходимы, и объединить все требования в единый документ (тексто- вый документ с диаграммами использования, защищаемая позиция). 4 этап. Проектирование 17. Реализовать выбранные варианты использования диаграммами деятельности, диаграммами последовательности и диаграммами кооперации (коммуникации). Должны быть использованы диаграммы всех трех указан- ных типов. 18. Идентифицировать классы на основе технического задания, сло- варя предметной области и реализованных вариантов использования. 19. Выделить хранимые и динамически создаваемые объекты (клас- сы) и определить отношения между классами. 20. Спроектировать схему хранимых данных в форме диаграммы «сущность-связь» или диаграммы классов. 21. Составить сводную диаграмму (или несколько диаграмм) клас- сов, на которой должны быть отражены все классы и интерфейсы, задейство- ванные на других диаграммах. 22. Выделить компоненты системы и определить их интерфейсы. 23. Составить диаграмму компонентов или диаграмму размещения (по выбору), описывающую структуру системы в целом. 24. Выделить класс или классы, поведение которых зависит от исто- рии. 134 25. Составить диаграмму (или диаграммы) состояний, описывающую поведение выбранных классов. 26. Проверить согласованность и корректность всех диаграмм. В случае наличия ошибок вернуться к шагу 17 и повторить необходимые шаги. 27. Спроектировать графический интерфейс пользователя в виде эк- ранных форм. 28. Составить детальный проект архитектуры, содержащий текст, согласованный с техническим заданием, диаграммы использования, диа- граммы деятельности, диаграммы последовательности, диаграммы коммуни- кации, диаграммы состояний, диаграммы компонентов или размещения, об- разы экранных форм, схемы данных и описания интерфейсов основных ком- понентов системы (защищаемая позиция). 5 этап. Реализация прототипа 29. Разработать документацию программной системы. 30. Разработать и отладить код программы на выбранном инструмен- те разработки. 31. Разработать план тестирования программы с определением зна- чений параметров (качественных характеристик системы). 32. Разработать графический интерфейс пользователя в виде экран- ных форм. 6 этап. Приемо-сдаточные испытания 33. Определить план презентации для представления результатов разработки. 34. Составить презентацию, включив в нее необходимый текстовый, графический численный материал. 35. Провести презентацию продолжительностью 10 минут, предста- вить основные результаты выполненной разработки (защищаемая позиция). 135 36. Составить и подписать протокол приемо-сдаточных испытаний (защищаемая позиция). ЗАКЛЮЧЕНИЕ В соответствии с программой учебной дисциплины «Проектный прак- тикум» для направления подготовки 230700.62 «Прикладная информатика» основной задачей учебного пособия является освоение студентами техноло- гии проектирования информационных систем с использованием наиболее широко распространенных CASE – средств. В пособии на примере рассмот- рен процесс проектирования информационной системы в среде CASE – сред- ства Rational Rose. Приведено большое количество упражнений, которые по- зволяют пошагово осваивать инструментальное средство и технологические приемы проектирования. Рассматриваются также основные процессы управления требованиями по проектированию в CASE среде RequisitePro. Пособие рассчитано как на работу под руководством преподавателя, так и на самостоятельную работу. С этой целью в пособии приведен перечень заданий, которые студенты должны выполнить самостоятельно с целью за- крепления изученного материала. Для привития навыков работы в проектной команде приведено задание для группового проектирования с описанием последовательности шагов его выполнения и защищаемых артефактов. Содержание пособия и приводимые в нем примеры и упражнения по- зволяют полностью освоить технологию проектирования и разработку про- ектной документации и тем самым сформировать требуемые компетенции, определенные ФГОС. 136 137 ПРИЛОЖЕНИЯ: ДОКУМЕНТАЦИЯ ПРОЕКТА Приложение 1. КОНЦЕПЦИЯ 1. Введение 1.1. Цель Определяется цель этого документа 1.2. Область применения Определяется область применения системы 1.3. Определения, акронимы и сокращения Приводится глоссарий. 2. Основные положения 2.1. Возможности системы Описываются возможности системы 2.2. Формулировка проблемы Проблема Приводится писание сути проблемы Затрагивает Приводится перечень лиц Последствия Успешное решение позволит Открывающиеся новые возможности 2.3. Формула продукта Для Для кого предназначена система Которые Выполняют функции … Является Чем является (Инструментом, …) Который Что обеспечивает? 3. Описание заинтересованных лиц и пользователей В этом разделе приводится описание типов пользователей. 138 3.1. Потенциальные потребители Приводится краткая характеристика. 3.2. Заинтересованные лица Наименование лица Кого представляет Роль 3.3. Пользователи Наименование Описание 3.4. Пользовательская среда Краткое описание пользовательской среды. 3.5. Основные потребности заинтересованных лиц/пользователей Потребность Приоритет Проблема Существую- щее решение Предлагаемые ре- шения 4. Обзор продукта Данный раздел содержит общее описание возможностей системы, ее внешних интерфейсов, а также конфигурации. 4.1. Перспективы продукта 139 4.2. Возможности продукта Приводятся основные возможности системы в терминах ее свойств и достоинств с точки зрения потребителей. Достоинство Свойство системы 4.3. Проектные ограничения Отражаются все проектные ограничения. 4.4. Стоимость проекта Выполняется ориентировочная оценка проекта 4.5. Лицензирование и установка Приводятся требования к лицензированию и установке 5. Функциональные возможности продукта В данном разделе определены и приводятся высокоуровневые функциональные возможности (свойства) системы, которые необходимы сточки зрения пользователей. 5.1. Вход в систему И т.д. 7. Требования к качеству В данном разделе определяются требования к производительности, на- дежности, удобству использования и другим характеристикам качества системы. Готовность: Удобство использования: Сопровождаемость: 8. Приоритеты 140 Данный раздел определяет относительную важность предлагаемых функциональных возможностей системы. 9. Прочие требования к продукту 9.1. Используемые стандарты Требования к стандартам интерфейса, … 9.2. Системные требования 9.3. Требования к производительности 9.4. Требования к окружающей среде 10. Требования к документации 10.1. Руководство пользователя Руководство пользователя должно описывать использование системы с точки зрения пользователей и включать: минимальные системные требования; установку ПК-клиента; вход в систему; выход из системы; все функциональные возможности системы; информацию о поддержке пользователей. 10.2. Диалоговая помощь 10.3. Руководство по установке, конфигурированию 10.4. Маркировка и упаковка 141 Приложение 2. Описание вариантов использования Вариант использования Актеры Цель Краткое описание Тип Ссылки на другие варианты исполь- зования Специальные тре- бования Предусловия Сценарий выполнения варианта использования (основные и аль- тернативные потоки) Действия актеров Отклик системы Приложение 3. Методические указания к курсовому проекти- рованию |