Министерство образования и науки Российской федерации
Федеральное агентство по образованию
Новосибирский государственный технический университет
Кафедра АСУ
Курсовой проект
по дисциплине Технология разработки информационных программных систем
на тему Реализация анализа образовательной системы
методом обращения в среде Rational Rose
Группа: АС-514
Студент: Сайко Дарья Владимировна
Преподаватель: Пушкарева Галина
Витальевна
Новосибирск 2009
Содержание
1. Описание предметной области
. Канонические диаграммы UML
.1 Диаграмма вариантов использования
.2 Диаграмма последовательности
.3 Диаграмма кооперации
.4 Диаграмма классов
.5 Диаграмма состояний
.6 Диаграмма деятельности
.7 Диаграмма компонентов
.8 Диаграмма развертывания
. Сгенерированный код
.1 Клиент диаграмма код кооперация сервер
.2
Сервер
В настоящее время образование находится в кризисной ситуации, так как уровень его развития не соответствует уровню развития техносферы. Научно-технический прогресс развивается настолько быстро, что технологии устаревают и не попадают в систему образования, будучи современными. Поэтому обеспечение инновационного характера образования является актуальной проблемой. Однако, своевременного внедрения новых технологий в систему образования не достаточно, для того чтобы сохранить актуальность знаний потребителей образовательных услуг. Требуется создание современной системы непрерывного образования, подготовки и переподготовки профессиональных кадров.
Для решения этих и многих других проблем необходимо научиться определять "узкие места" (нежелательные эффекты) в развитии системы и своевременно их устранять.
Целью проекта является разработка системы автоматизированного анализа сложных объектов образовательной системы. Для поиска дестабилизирующих факторов (нежелательных эффектов) и "узких мест" применен метод обращения.
Пользователем системы является преподаватель. Вводя данные об имеющейся образовательной системе, он может получать список вредных воздействий, просматривать построенную в соответствии с этим списком диаграмму Исикавы-Сибирякова, а также получать рекомендации по улучшению образовательной системы. Результаты его работы сохраняются в базу данных. Также он может изменять информацию о ранее созданных им образовательных системах.
Пользователь с правами администратора имеет право редактировать список пользователей системы, а также изменять сохраненные преподавателями данные об образовательных системах.
Для данной предметной области были построены следующие виды канонических диаграмм.
Работа над проектом в среде Rational Rose начинается с общего анализа проблемы и построения диаграммы вариантов использования, которая отражает функциональное назначение проектируемой программной системы. Диаграмма вариантов использования содержит варианты использования системы, действующих лиц и связи между ними.
Диаграмма вариантов использования для данной предметной области представлена на рисунке 1.
На этой диаграмме показаны два действующих лица: пользователь (преподаватель) и администратор. Так же на диаграмме изображены еще 10 вариантов использования:
1. авторизация пользователя;
2. создание новой системы;
. редактирование имеющейся системы;
. ввод данных о системе;
. формирование списка вредных воздействий;
. построение диаграммы Исикавы-Сибирякова;
. выдача рекомендаций по улучшению системы;
. просмотр результатов обработки данных;
. сохранение результатов работы;
. редактирование списка пользователей системы.
Все варианты использования, которые связаны с действующими лицами, связаны с ними связью коммуникации - это связь между вариантом использования и действующим лицом. Связь коммуникации изображается в виде стрелки, направление стрелки показывает, кто инициирует коммуникацию.
Остальные действия связаны связью расширения, либо использования. Связь расширения (extend) позволяет варианту использования только при необходимости применять функциональные возможности, предоставляемые другим вариантом использования. А связь использования (include) позволяет одному варианту использования задействовать функциональность другого, в данном случае функциональность другого варианта использования задействуется всегда.
Часто для одной системы создается несколько диаграмм вариантов
использования. На диаграмме высокого уровня, называемой в среде Rational Rose
главной (main), указываются только пакеты (группы вариантов использования).
Другие диаграммы конкретизируют какой-либо пакет совокупности вариантов
использования и действующих лиц.
Рисунок 1 - Диаграмма вариантов использования (Main)
Диаграмма последовательности состоит из объектов, сообщений, изображенных сплошными линиями со стрелками и вертикальной оси времени, определяющей последовательность событий.
Объекты располагаются в верхней части диаграммы слева направо. Порядок расположения может быть произвольным, он определяется лишь требованием простоты диаграммы. Пунктирная вертикальная линия, расположенная под каждым объектом, называется линией жизни этого объекта.
В процессе функционирования системы один объект может находиться в активном состоянии, выполняя определенные действия, или же в состоянии пассивного ожидания. Чтобы явно выделить подобную активность объекта применяется понятие фокуса управления. На диаграмме фокус управления изображается в виде узкого прямоугольника, расположенного вдоль линии жизни объекта.
Сообщения, передаваемые от одного объекта другому, на диаграмме изображаются в виде линий, соединяющих линии жизни этих объектов.
Сообщение показывает, что один объект вызывает функцию другого. Сообщения могут быть рефлексивными, что соответствует обращению объекта к своей собственной операции.
Диаграмма последовательности для моделируемой системы показана на рисунке
2.
Рисунок 2 - Диаграмма последовательности для создания новой системы
Диаграммы последовательности упорядочены по времени, а кооперативные диаграммы больше внимания заостряют на связях между объектами. На диаграмме кооперации представлена та же информация, что и на диаграмме последовательности, но диаграмма кооперации по-другому описывает поток событий. Из нее легче понять отношения между объектами, но труднее понять последовательность событий.
В Rational Rose диаграмму последовательности можно преобразовать в диаграмму кооперации и наоборот, нажав клавишу F5.
Диаграмма кооперации представлена на рисунке 3.
Рисунок 3 - Диаграмма кооперации
Диаграмма классов является основным логическим представлением модели, она отражает статическое представление системы. На данной диаграмме отображаются классы и пакеты системы, а также связи между ними. Диаграмма классов представлена на рисунке 4.
Boundaries:
1. MainForm - тип boundary, основное окно приложения.
Controls:
1. SystemManager - тип Control, элементы управления окна.
Entities:
1. DevelopmentGuide - тип Entity, справочник развития;
2. EducationGuide - тип Entity, справочник воспитания;
. KnowlageGuide - тип Entity, справочник знаний;
. FounderGuide - тип Entity, справочник пользователей;
. SystemsGuide - тип Entity, справочник систем.
Рисунок 4 - Диаграмма классов для создания новой системы
Диаграмма состояний относится к диаграммам поведения. На диаграммах состояний отображают жизненный цикл одного объекта, начиная с момента его создания и заканчивая разрушением. Диаграмма состояний изображена на рисунке 5.
На диаграмму состояний можно добавить два специальных состояния объекта: начальное и конечное. На диаграмме может быть только одно начальное состояние. В конечном состоянии объект находится непосредственно перед уничтожением. Конечное состояние не является обязательным, конечных состояний может быть сколько угодно.
Переход представляет собой отношение между двумя последовательными
состояниями, которое указывает на факт смены одного состояния другим.
Пребывание моделируемого объекта в первом состоянии может сопровождаться выполнением
некоторых действий, а переход во второе состояние будет возможен после
завершения этих действий, а также после удовлетворения некоторых дополнительных
условий.
Рисунок 5 - Диаграмма состояний
Диаграммы деятельности относятся к диаграммам поведения моделируемой системы. При моделировании поведения системы возникает необходимость не только представить процесс изменения ее состояний, но и детализировать особенности алгоритмической и логической реализации выполняемых системой операций. Применяемая в диаграммах деятельности графическая нотация во многом похожа на нотацию диаграммы состояний.
Каждый вид деятельности изображается прямоугольником с округленными углами (Activity) - более узким и овальным, чем символ состояния. После завершения одного вида деятельности переход к следующему происходит автоматически. Переход от одного вида деятельности к другому изображается стрелкой. Как и на диаграмме состояний, на диаграмме деятельности есть начальная и конечная точка. Но диаграмма деятельности имеет единственное начальное и конечное состояние. Диаграмму деятельности принято располагать так, чтобы действия следовали сверху вниз. Понятие точки принятия решения используется для выбора альтернативного пути. Как правило, точку принятия решений изображают в виде небольшого ромбика (Decision). Именно в этом случае для любого из переходов должно быть явно записано сторожевое условие. При этом для всех выходящих из некоторого состояния переходов должно выполняться требование истинности только для одного из них.
Диаграммы деятельности используются при моделировании бизнес-процессов, при этом желательно выполнение каждого действия ассоциировать с конкретным подразделением компании. В этом случае подразделение несет ответственность за реализацию конкретных действий, а сам бизнес-процесс представляется в виде переходов действий от одного подразделения к другому. Для моделирования этих особенностей в UML используется специальная конструкция, получившая название "дорожки".
Диаграмма деятельности для данной системы представлена на рисунке 6.
Рисунок 6 - Диаграмма деятельности
Диаграмма компонентов является частью физического представления модели. Диаграмма компонентов позволяет определить архитектуру разрабатываемой системы, установить зависимости между программными компонентами, в роли которых может выступать исходный и исполняемый код.
Компонент - физический модуль кода. Во многих средах разработки компонент соответствует файлу. Пунктирные стрелки, соединяющие модули показывают отношения зависимости, аналогичные тем, которые имеют место при компиляции исходных текстов программ. Зависимости между компонентами отражают порядок их компиляции.
В данной системе для каждого пакета классов созданы отдельные диаграммы компонентов, которые объединяются в диаграмму компонентов для всей системы.
Диаграммы компонентов для данной системы представлены на рисунках 7 - 9.
Рисунок 7 - Диаграмма компонентов всей системы
Рисунок 8 - Диаграмма компонентов для пакета Клиент
Рисунок 9 - Диаграмма компонентов для пакета Сервер
Представление развертывания содержит процессоры, устройства, процессы и связи между процессорами и устройствами. Все они наносятся на диаграмму размещения. Для системы может быть создана только одна диаграмма размещения. Диаграмма размещения отображает все узлы сети, связи между ними и процессы, выполняющиеся на каждом узле.
На рисунке 10 представлена диаграмма развертывания для данной системы.
Рисунок 2.10 - Диаграмма развертывания
ClientExe.h
//## begin module%1.7%.codegen_version preserve=yes
// Read the documentation to learn more about C++ code generator
// versioning.
//## end module%1.7%.codegen_version
//## begin module%4B31B6750076.cm preserve=no
// %X% %Q% %Z% %W%
//## end module%4B31B6750076.cm
//## begin module%4B31B6750076.cp preserve=no
//## end module%4B31B6750076.cp
//## Module: ClientExe%4B31B6750076; Task specification
//## Subsystem: Клиент%4B31B4DD03CE
//## Source file: D:\Клиент\ClientExe.h
#ifndef ClientExe_h
#define ClientExe_h 1
//## begin module%4B31B6750076.additionalIncludes preserve=no
//## end module%4B31B6750076.additionalIncludes
//## begin module%4B31B6750076.includes preserve=yes
//## end module%4B31B6750076.includes
// MainForm
#include "Клиент\MainForm.h"
// SystemManager
#include "Клиент\SystemManager.h"
//## begin module%4B31B6750076.declarations preserve=no
//## end module%4B31B6750076.declarations
//## begin module%4B31B6750076.additionalDeclarations preserve=yes
//## end module%4B31B6750076.additionalDeclarations
//## begin module%4B31B6750076.epilog preserve=yes
//## end module%4B31B6750076.epilog
#endif
MainForm.cpp
//## begin module%1.7%.codegen_version preserve=yes
// Read the documentation to learn more about C++ code generator
// versioning.
//## end module%1.7%.codegen_version
//## begin module%4B31B65F0319.cm preserve=no
// %X% %Q% %Z% %W%
//## end module%4B31B65F0319.cm
//## begin module%4B31B65F0319.cp preserve=no
//## end module%4B31B65F0319.cp
//## Module: MainForm%4B31B65F0319; Package body
//## Subsystem: Клиент%4B31B4DD03CE
//## Source file: D:\Клиент\MainForm.cpp
//## begin module%4B31B65F0319.additionalIncludes preserve=no
//## end module%4B31B65F0319.additionalIncludes
//## begin module%4B31B65F0319.includes preserve=yes
//## end module%4B31B65F0319.includes
// MainForm
#include "Клиент\MainForm.h"
//## begin module%4B31B65F0319.declarations preserve=no
//## end module%4B31B65F0319.declarations
//## begin module%4B31B65F0319.additionalDeclarations preserve=yes
//## end module%4B31B65F0319.additionalDeclarations
// Class MainForm::MainForm()
//## begin MainForm::MainForm%4B319C190084_const.hasinit preserve=no
//## end MainForm::MainForm%4B319C190084_const.hasinit
//## begin MainForm::MainForm%4B319C190084_const.initialization preserve=yes
//## end MainForm::MainForm%4B319C190084_const.initialization
{
//## begin MainForm::MainForm%4B319C190084_const.body preserve=yes
//## end MainForm::MainForm%4B319C190084_const.body
}::MainForm(const MainForm &right)
//## begin MainForm::MainForm%4B319C190084_copy.hasinit preserve=no
//## end MainForm::MainForm%4B319C190084_copy.hasinit
//## begin MainForm::MainForm%4B319C190084_copy.initialization preserve=yes