Методические рекомендации по выполнению лабораторных работ для студентов специальностей 351400 «Прикладная информатика (в экономике)», 071900 «Информационные системы и технологии» Бийск 2005




НазваниеМетодические рекомендации по выполнению лабораторных работ для студентов специальностей 351400 «Прикладная информатика (в экономике)», 071900 «Информационные системы и технологии» Бийск 2005
страница2/6
Дата конвертации31.12.2012
Размер0.63 Mb.
ТипМетодические рекомендации
1   2   3   4   5   6

1.4 Принцип работы в Rational Rose



Исходным шагом разработки нового проекта является создание отдельных моделей или представлений в контексте построения канонических диаграмм.

Для нового проекта можно воспользоваться мастером типовых проектов (если он установлен в данной конфигурации). Мастер типовых проектов доступен из меню File -> New (Файл -> Создать). Если мастер недоступен, то появляется рабочий интерфейс программы с чистым окном диаграммы.

Если имеется готовый проект (файл с расширением mdl  модель), то его можно открыть для последующей модификации через меню File -> Open (Файл -> Открыть). В этом случае программа загрузит существующий проект со всеми имеющимися в нем диаграммами, спецификациями и документацией.

По окончании сеанса работы над проектом выполненную работу необходимо сохранить в файле проекта с расширением mdl. Это можно сделать через меню File -> Save (Файл -> Сохранить) или
File -> Save As (Файл -> Сохранить как). При этом вся информация о проекте, включая диаграммы и спецификации элементов, будет сохранена в одном файле.

Как и другие программы, Rational Rose позволяет настраивать глобальные параметры среды, такие как выбор шрифтов и цвета для представления различных элементов модели. Настройка шрифтов производится через меню Tools -> Options (Инструменты -> Параметры). Характерной особенностью среды является возможность работы с символами кириллицы. Однако следует заметить, что при спецификации элементов модели с последующей генерацией текста программного кода нужно сразу записывать имена и свойства элементов символами того языка, который поддерживается соответствующим языком программирования.

Для изменения цвета линий необходимо воспользоваться пунктом меню Edit -> Diagram Object Properties -> Line Color (Правка -> Свойства объекта диаграммы -> Цвет линии). В этом случае предлагается специальная цветовая палитра, на которой можно выбрать подходящий цвет для линий на диаграммах.

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

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


1.5 Рабочие процессы RUP и диаграммы UML



Ни для кого не секрет, что создание программного обеспечения – это сложный процесс, который, с одной стороны, имеет много общего с творчеством, а с другой, – хотя и высокодоходный, но и высокозатратный бизнес. Жестокая конкуренция на рынке вынуждает разработчиков вести поиск более эффективных методов работы, путей создания программных систем в еще более короткие сроки, с меньшими затратами и лучшим качеством. Сложность программ постоянно увеличивается. Еще недавно программные продукты могли быть созданы в обозримые сроки одиночками или, например, в IT-отделе автоматизируемого предприятия [1].

Корпорация Rational Software (http://www.rational.com) выпустила на рынок структурированную базу знаний под названием Rational Unified Process (RUP), которая представляет собой набор исчерпывающих рекомендаций для создания практически любых программных продуктов. Вобрав в себя опыт лучших разработок, RUP подробно рассказывает, когда, кто и что должен делать в проекте, чтобы в результате получить программную систему в установленные сроки, с определенной функциональностью и в рамках отведенного бюджета.

Для реализации требований заказчика в установленные сроки унифицированный процесс разделяется на фазы, которые состоят из итераций, поэтому процесс еще называют итеративным и инкрементным. Каждая итерация проходит цикл основных работ и подводит разработчиков к конечной цели: созданию программной системы. В ходе итераций создаются промежуточные артефакты, которые требуются для успешного завершения проекта, и вариант программной системы, который реализует некоторый набор функций, увеличивающийся от итерации к итерации. Фазы и основные потоки работ процесса показаны на рисунке 1.9, там же даны примерные трудозатраты работ по фазам [2, 3]. Нужно отметить, что на рисунке 1.9 показаны только основные работы унифицированного процесса. Например, работы по управлению деятельностью здесь не показаны, чтобы не загромождать диаграмму.

Вся разработка ПО рассматривается в RUP как процесс создания артефактов. Любой результат работы проекта, будь то исходные тексты, объектные модули, документы, передаваемые пользователю, модели – это подклассы всех артефактов проекта. Каждый член проектной группы создает свои артефакты и несет за них ответственность. Программист создает программу, руководитель  проектный план,
а аналитик  модели системы. RUP позволяет определить: когда, кому и какой артефакт необходимо создать, доработать или использовать.





Рисунок 1.9 – Фазы и потоки работ RUP


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

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


1.5.1 Определение требований


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





Рисунок 1.10 – Пример диаграммы прецедентов


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

Для детализации конкретного прецедента используется диаграмма активности (Activity Diagram), пример которой дан на рисунке 1.11.

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





Рисунок 1.11 – Пример диаграммы активности


Также диаграмма прецедентов может использоваться для создания сценариев тестирования, поскольку все взаимодействие пользователей и системы уже определено.


1.5.2 Анализ


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

Эта модель позволяет понять, как система должна быть спроектирована, какие в ней должны быть классы и как они должны взаимодействовать между собой. Основное ее назначение  определить направление реализации функциональности, выявленной на этапе сбора требований и сделать набросок архитектуры системы.

Для отображения модели анализа при помощи UML используется диаграмма классов со стереотипами (образцами поведения) «граничный класс», «сущность», «управление», а для детализации используются диаграммы сотрудничества (Collaboration) (рисунок 1.12). Стереотип «граничный класс» отображает класс, который взаимодействует с внешними актантами, «сущность» отображает классы, которые являются хранилищами данных, а «управление» – классы, управляющие запросами к сущностям.

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




Рисунок 1.12 – Пример диаграммы сотрудничества


Если акцентировать внимание на порядке взаимодействия, то другим его представлением будет диаграмма последовательности (Sequence), показанная на рисунке 1.13. Эта диаграмма позволяет взглянуть на обмен сообщениями во времени, наглядно отобразить последовательность процесса. При использовании такого инструмента для создания моделей, как Rational Rose, эти два вида диаграмм могут быть созданы друг из друга.

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




Рисунок 1.13 – Пример диаграммы последовательности действий

1.5.3 Проектирование


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

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

Для максимально точного понимания архитектуры системы, эта модель должна быть максимально формализована, и поддерживаться в актуальном состоянии на протяжении всего жизненного цикла разработки системы.

Для создания модели проектирования используется целый набор UML диаграмм: диаграммы классов (рисунок 1.14), диаграммы кооперации, диаграммы взаимодействия, диаграммы активности.





Рисунок 1.14 – Пример диаграммы классов


Дополнительно в этом рабочем процессе может создаваться модель развертывания, которая реализуется на основе диаграммы развертывания (Deployment Diagram). Это самый простой тип диаграмм, предназначенный для моделирования распределения устройств в сети.

Для отображения используется всего два варианта значков  процессор и устройство вместе со связями между ними.


1.5.4 Реализация


Основная задача процесса реализации – создание системы в виде компонентов: исходных текстов программ, сценариев, двоичных файлов, исполняемых модулей и т.д. На этом этапе создается модель реализации, которая описывает то, как реализуются элементы модели проектирования, какие классы будут включены в конкретные компоненты. Данная модель описывает способ организации этих компонентов в соответствии с механизмами структурирования и разбиения на модули, принятыми в выбранной среде программирования, и представляется диаграммой компонентов (рисунок 1.15).




Рисунок 1.15 – Пример диаграммы компонентов


1.5.5 Тестирование


В процессе тестирования проверяются результаты реализации. Для данного процесса создается модель тестирования, которая состоит из тестовых примеров, процедур тестирования, тестовых компонентов, однако не имеет отображения на UML диаграммы, поэтому не будем на ней останавливаться.


2 ЛАБОРАТОРНЫЙ ПРАКТИКУМ


Постановка задачи


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

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

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

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

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

Профессора должны иметь доступ к онлайновой системе, чтобы указать курсы, которые они будут читать, и просмотреть список студентов, записавшихся на их курсы. Кроме этого, профессора должны иметь возможность проставить оценки за курсы. Глоссарий предназначен для описания терминологии предметной области. Он может быть использован как неформальный словарь данных системы (таблица 2.1).

Таблица 2.1 – Глоссарий системы

Курс

Учебный курс, предлагаемый университетом

Конкретный курс (Course Offering)

Конкретное чтение данного курса в конкретном семестре (один и тот же курс может вестись в нескольких параллельных сессиях). Включает точные дни недели и время

Каталог курсов

Полный каталог всех курсов, предлагаемых
университетом

Расчетная
система

Система обработки информации об оплате
за курсы

Оценка

Оценка, полученная студентом за конкретный курс

Профессор

Преподаватель университета

Табель
успеваемости (Report Card)

Все оценки за все курсы, полученные студентом в данном семестре

Список курса (Roster)

Список всех студентов, записавшихся на конкретный курс

Студент

Личность, проходящая обучение в университете

Учебный график (Schedule)

Курсы, выбранные студентом в текущем семестре


Функциональные возможности:

  • система должна обеспечивать многопользовательский режим работы;

  • если конкретный курс оказывается заполненным в то время, когда студент формирует свой учебный график, включающий данный курс, то система должна известить его об этом.

Удобство использования: пользовательский интерфейс должен быть совместимым с Windows.

Надежность: система должна быть в работоспособном состоянии 24 часа в день семь дней в неделю, время простоя – не более 10%.

Производительность: система должна поддерживать до 2000 одновременно работающих с центральной базой данных пользователей и до 500 пользователей, одновременно работающих с локальными серверами.

Безопасность:

  • система не должна позволять студентам изменять любые учебные графики, кроме своих собственных, а также не должна позволять профессорам модифицировать конкретные курсы, выбранные другими профессорами;

  • только профессора имеют право ставить студентам оценки;

  • только регистратор может изменять любую информацию о студентах.

Проектные ограничения: система должна быть интегрирована с существующей системой каталога курсов, функционирующей на основе реляционной СУБД.

1   2   3   4   5   6

Похожие:

Методические рекомендации по выполнению лабораторных работ для студентов специальностей 351400 «Прикладная информатика (в экономике)», 071900 «Информационные системы и технологии» Бийск 2005 iconМетодические рекомендации по выполнению лабораторных работ для студентов специальностей 080801 «Прикладная информатика в экономике», 230200 «Информационные системы и технологии» Бийск
Методические рекомендации предназначены для студентов специальностей 080801, 230200 изучающих дисциплину «Алгоритмы и методы обработки...

Методические рекомендации по выполнению лабораторных работ для студентов специальностей 351400 «Прикладная информатика (в экономике)», 071900 «Информационные системы и технологии» Бийск 2005 iconМетодические указания к выполнению практических и лабораторных работ
Методические указания предназначены для студентов специальностей «Прикладная информатика (в экономике)», «Бухгалтерский учет, анализ...

Методические рекомендации по выполнению лабораторных работ для студентов специальностей 351400 «Прикладная информатика (в экономике)», 071900 «Информационные системы и технологии» Бийск 2005 iconМетодические указания по дипломному проектированию в филиалах мфпу для направления «Информационные системы» испециальностей «Информационные системы и технологии», «Прикладная информатика (в экономике)», «Прикладная информатика (в дизайне)» Под редакцией декана факультета исит денисова Д.
«Информационные системы» и специальностей «Информационные системы и технологии», «Прикладная информатика (в экономике)», «Прикладная...

Методические рекомендации по выполнению лабораторных работ для студентов специальностей 351400 «Прикладная информатика (в экономике)», 071900 «Информационные системы и технологии» Бийск 2005 iconМетодические указания по выполнению лабораторных работ №1-4 для студентов специальности 071900 «Информационные системы и технологии»
Теория информационных процессов и систем : методические указания к лабораторным работам №1–4 для студентов специальности 071900 «Информационные...

Методические рекомендации по выполнению лабораторных работ для студентов специальностей 351400 «Прикладная информатика (в экономике)», 071900 «Информационные системы и технологии» Бийск 2005 iconМетодические рекомендации по выполнению самостоятельной работы студентов специальностей 080801 «Прикладная информатика в экономике», 230201 «Информационные системы и технологии» дневной формы обучения
Методические рекомендации по выполнению самостоятельной работы студентов специальностей 080801 Прикладная информатика

Методические рекомендации по выполнению лабораторных работ для студентов специальностей 351400 «Прикладная информатика (в экономике)», 071900 «Информационные системы и технологии» Бийск 2005 iconМетодические рекомендации по изучению дисциплины для студентов специальностей 080801 «Прикладная информатика в экономике», 230201 «Информационные системы в технологии» дневной формы обучения
Методические рекомендации по изучению дисциплины для студентов специальностей 080801 «Прикладная информатика в экономике», 230201...

Методические рекомендации по выполнению лабораторных работ для студентов специальностей 351400 «Прикладная информатика (в экономике)», 071900 «Информационные системы и технологии» Бийск 2005 iconМетодические указания к выполнению лабораторных работ
Методические указания предназначены для студентов экономических специальностей при изучении дисциплин «Информационные технологии»,...

Методические рекомендации по выполнению лабораторных работ для студентов специальностей 351400 «Прикладная информатика (в экономике)», 071900 «Информационные системы и технологии» Бийск 2005 iconМетодические рекомендации по изучению дисциплины для студентов специальностей 080801 «Прикладная информатика в экономике», 230201 «Информационные системы»
Тушкина, Т. М. Теория вероятностей и математическая статистика: методические рекомендации по изучению дисциплины для студентов специальностей...

Методические рекомендации по выполнению лабораторных работ для студентов специальностей 351400 «Прикладная информатика (в экономике)», 071900 «Информационные системы и технологии» Бийск 2005 iconМетодические рекомендации по самостоятельной работе студентов специальностей 080801 «Прикладная информатика в экономике», 230201 «Информационные системы и технологии»
Издательство Алтайского государственного технического университета им. И. И. Ползунова

Методические рекомендации по выполнению лабораторных работ для студентов специальностей 351400 «Прикладная информатика (в экономике)», 071900 «Информационные системы и технологии» Бийск 2005 iconМетодические рекомендации по выполнению лабораторных работ для студентов специальностей 351100, 351300 всех форм обучения Бийск 2005 удк 668. 58
Ердакова В. П. Ассортимент и качество упаковки для косметических товаров: Методические рекомендации по выполнению лабораторных работ...


Разместите кнопку на своём сайте:
lib.convdocs.org


База данных защищена авторским правом ©lib.convdocs.org 2012
обратиться к администрации
lib.convdocs.org
Главная страница