Отчет по выполнению пр практики
Содержание
1. ВВЕДЕНИЕ 3
1.1 ОБЗОР ДОКУМЕНТА 3
1.2 ССЫЛКИ 3
2. ПОСТАНОВКА ЗАДАЧИ 3
3. МОДЕЛЬ ТРЕБОВАНИЙ 3
UML - МОДЕЛЬ 5
3.2 ОПИСАНИЕ ЭЛЕМЕНТОВ МОДЕЛИ 5
3.2.1 Внешние роли 5
3.2.2 Варианты использования 5
4. МОДЕЛЬ АНАЛИЗА 10
4.1 ОБЗОР 10
4.2 АРХИТЕКТУРНАЯ МОДЕЛЬ 10
5. МОДЕЛЬ ПРОЕКТИРОВАНИЯ 11
5.1 ОБЗОР 11
5.2 ДИАГРАММЫ КЛАССОВ 11
6. МОДЕЛЬ КОМПОНЕНТОВ 12
6.1 ОБЗОР 12
6.2 ДИАГРАММА КОМПОНЕНТОВ 12
7. ЗАКЛЮЧЕНИЕ 12
1. Введение
1.1 Обзор документа
Документ построен следующим образом:
· в главе 2 дается постановка задачи,
· в главе 3 описывается модель требований к разрабатываемой системе,
· в главе 4 описывается модель анализа разрабатываемой системы,
· в главе 5 описывается модель проектирования разрабатываемой системе,
· в главе 6 описывается модель компонентов разрабатываемой системы,
1.2 Ссылки
UML specification 1.3 - стандарт языка моделирования UML, версия 1.3.
Rational Unified Process 5.5 - методология разработки программных средств, разработанная компанией Rational.
2. Постановка задачи
Требуется разработать средствами Rational Rose модель системы автоматизирующей деятельность библиотеки.
В библиотеке осуществляется регистрация всех читателей и ведутся каталоги поступивших в библиотеку книг, кроме того фиксируется информация о том, какие книги у какого читателя находятся в данный момент. Система поддержки управления библиотекой должна обеспечивать возможность добавления/удаления читателей и соответственно книг в каталоги, регистрацию взятых и возвращенных читателем книг, а также выдавать полезную справочную информацию (например, о наличии в данный момент указанной книги).
3. Модель требований
Этап 1. Анализ требований
Исходные данные: начальная постановка задачи (в текстовом виде).
Требуется: построить диаграммы вариантов использования, описывающие функциональность системы. Каждое действующее лицо (actor) и вариант использования сопровождается описанием. Все описания составляются на русском языке. Описание действующего лица - короткое (1-2 строки). Описание варианта использования состоит из пояснения, предусловия, потоков событий (основного и альтернативных, если таковые есть) и постусловия. Описания представляют собой либо присоединенные текстовые файлы, либо текст введенный в поле Documentation спецификации соответствующего элемента диаграммы.
Этап 2. Реализация вариантов использования
Исходные данные: начальная постановка задачи (в текстовом виде) и диаграммы вариантов использования.
Требуется: выделить прототипные объекты системы и построить диаграммы взаимодействия между объектами (последовательности и кооперативные), соответствующие потокам событий вариантов использования. Для анализа нескольких вариантов использования можно использовать диаграммы деятельности. Названия диаграмм должны совпадать с названиями соответствующих вариантов использования. Все необходимые пояснения должны содержаться в примечаниях диаграмм. На этом этапе проектируются диаграммы взаимодействия в начальном приближении, объекты не соотносятся с классами, сообщения не соотносятся с операциями.
После выполнения этого этапа производится промежуточная сдача задания.
Этап 3. Проектирование
Исходные данные: начальная постановка задачи (в текстовом виде) и диаграммы вариантов использования, диаграммы взаимодействия.
Требуется: создать иерархию классов системы, разместить классы по пакетам (использовать деление: пользовательский интерфейс - управление - данные; или другое в зависимости от постановки задачи), связать объекты с классами, сообщения - с операциями (второй этап разработки диаграмм взаимодействия). Каждый класс снабдить описанием. Оно должно включать в себя краткое описание - ответственность класса; описание атрибутов в виде таблицы из 3-х столбцов: имя, описание, тип; таблицу с описанием операций (имя, описание, сигнатура). Для классов указать стереотипы. Построить диаграммы классов системы, отображающие связи между классами. Для описания поведения экземпляров отдельных классов использовать диаграммы состояний.
Этап 4. Конструирование
Требуется: построить диаграммы компонентов для каждого пакета и для системы в целом. Также следует разработать диаграмму размещения. В зависимости от варианта задания диаграмма размещения показывает расположение компонентов в распределенном приложении или связи между встроенным процессором и устройствами.
3.1 UML - модель
3.2 Описание элементов модели
3.2.1 Внешние роли
3.2.1.1 Человек
Описывает всех пользователей библиотеки.
3.2.1.2 Читатель
Описывает всех пользователей библиотеки, которые могут брать в ней книги.
3.2.1.3 Библиотекарь
Описывает суперпользователя библиотеки, который управляет каталогами. Он может добавлять и удалять книги и читателей, выдавать и принимать книги
3.2.2 Варианты использования
3.2.2.1 Добавить книгу
Сценарий описывает варианты добавления поступившей в библиотеку книги
1. Добавление книги, которой еще нет в библиотеке
2. Добавление книги, несколько экземпляров которой уже есть в библиотеке.
3.2.2.2 Удалить книгу
Сценарий описывает удаление книги
3.2.2.3 Добавить читателя
Сценарий описывает добавление нового читателя
3.2.2.4 Удалить читателя
Сценарий описывает удаление читателя
3.2.2.5 Взять книгу
Сценарий описывает выдачу книги на руки
3.2.2.6 Вернуть книгу
Сценарий описывает возвращение читателем книги
3.2.2.7 Информация о книге
Сценарий описывает получение информации о книге (в том числе о ее наличии)
4. Модель анализа
4.1 Обзор
В данной главе описывается модель архитектурного анализа программного обеспечения библиотеки. Описание архитектурного анализа содержит диаграммы классов, описывающие архитектуру программного обеспечения и диаграммы последовательностей, описывающие реализацию вариантов использования на основе предложенной архитектуры.
4.2 Архитектурная модель
5. Модель проектирования
5.1 Обзор
В данной главе описывается модель проектирования программного обеспечения библиотеки.
5.2 Диаграммы классов
6. Модель компонентов
6.1 Обзор
В данной главе описывается модель компонент программного обеспечения библиотеки.
6.2 Диаграмма компонентов
7. Заключение
В заключение вышесказанного стоит добавить несколько строк. Поставленная задача - изучение среды проектирования Rational Rose 2000, и последующее применение полученных знаний для проектирования заданной модели - была выполнена за отведенное время. Среда обладала требуемой функциональностью. Необходимые результаты - достигнуты.
© Copyright: , 2001
Свидетельство о публикации №201112200038 Список читателей / Версия для печати / Разместить анонс / Заявить о нарушении правил
Рецензии
Написать рецензию
Написать рецензию Другие произведения автора
Разделы: авторы / произведения / рецензии / поиск / кабинет / ваша страница / о сервере Ресурсы: Стихи.ру / Проза.ру
--------------------------------------------------------------------------------
Сервер Проза.ру предоставляет авторам возможность свободной публикации своих литературных произведений в сети Интернет на основании пользовательского договора. Все авторские права на произведения принадлежат авторам и охраняются законом. Перепечатка произведений возможна только с согласия его автора, к которому вы можете обратиться на его авторской странице. Ответственность за тексты произведений авторы несут самостоятельно на основании правил сервера и российского законодательства. Вы также можете посмотреть более подробную информацию о сервере и связаться с администрацией.
Ежедневная аудитория сервера Проза.ру – свыше 70 тысяч посетителей, которые в общей сумме просматривают более семисот тысяч страниц по данным независимых счетчиков посещаемости Top.Mail.ru и LiveInternet, которые расположены справа от этого текста. В каждой графе указано по две цифры: количество просмотров и количество посетителей. 18+
|
