Визуальное моделирование предметной области 'Генеалогическое дерево'
СОДЕРЖАНИЕ
Введение
Постановка задачи
Описание предметной области
Морфологическая модель
Функциональная модель
Диаграмма состояний
Диаграмма деятельности
Диаграмма «сущность-связь»
Диаграмма компонентов
Диаграмма размещения
Диаграмма классов
Диаграмма взаимодействия
Теория о BPWin
Теория о Microsoft
Word
Выводы
Список использованной литературы
Приложение А Техническое задание
ВВЕДЕНИЕ
Визуальное моделирование - это способ
представления идей и проблем реального мира с помощью моделей. Модель помогает
понять проблему всем участникам, задействованным в реализации проекта на
различных этапах: заказчику, эксперту, аналитику, проектировщику, автору
документации, программисту и др. Моделирование обеспечивает более точную оценку
необходимых ресурсов, четкую проработку планов и эффективное функционирование
создаваемых систем.
Нотация - важная составляющая любой модели,
своего рода связующее звено между процессами. Унифицированный язык
моделирования (UML)
предлагает достаточно полную нотацию, которая расширяется при переходе от
анализа к проектированию.
Успешно разработанный проект удовлетворяет или
превосходит ожидание заказчика, выполняется в срок с оптимальными затратами и
может быть адаптирован к изменению условий. Жизненный цикл разработки должен
способствовать творческим и новаторским идеям. Правильно управляемый
итеративный и инкрементальный жизненный цикл обеспечивает необходимый контроль
и поддерживает творческий процесс на нужном уровне. В итеративном и
инкрементальном жизненном цикле разработка осуществляется с помощью серии
версий, которые развиваются в направлении конечной системы. Каждая версия
состоит из одного или более компонентов процесса: построение бизнес - модели,
определение требований к системе, анализ, проектирование, реализация,
тестирование и внедрение.
В качестве средства управления итеративным и
инкрементальным жизненным циклом разработки применяется методика Rational
Unified Process,
с помощью которой можно подробно описать технические и организационные аспекты
разработки программного обеспечения на стадиях определения требований к
системе, анализа и проектирования.
Семейство продуктов Rational
Rose призвано
обеспечить разработчика программ полным набором инструментов визуального
моделирования для эффективного решения сложных бизнес - задач с использованием
архитектуры клиент/сервер, распределенных сред и систем реального времени.
1 ПОСТАНОВКА ЗАДАЧИ
визуальное
моделирование программный
Общие определения. Разрабатываемая
программа предназначена для хранения и структуризации данных генеалогического
<#"564529.files/image001.gif">
Рисунок 3.1 - Морфологическая модель
ФУНКЦИОНАЛЬНАЯ МОДЕЛЬ
Функциональная модель описывает порядок работы
системы. Существуют различные формальные методики описания функционирования
системы. Одной из наиболее распространенных методик является IDEF технология.
Особенностями IDEF являются:
четкое определение границы системы;
все функции рассматриваются исходя из цели
создания системы, в рамках методологии получила название точки зрения;
описывается функционирование верхнего уровня, а
каждая функция
декомпозируется на несколько уровней.
Рассмотрим технологию построения модели в рамках
IDEF.
Каждая IDEF диаграмма содержит блоки и дуги.
Блоки изображают функцию системы, а дуги связывают блоки и описывают
взаимосвязь между ними.
Функциональные блоки изображают
прямоугольниками, внутри которых содержатся название. Название блока должно
содержать глаголы (выполнить задания, оценить качество). На диаграмме должно
быть не меньше трех и не больше пяти блоков.
Блоки размещаются на диаграмме по степени
важности (доминирования). Доминирующим блоком может быть первый блок цепочки
или блок, выход которого является управлением для других блоков диаграммы.
Наиболее доминирующий блок располагается в
верхнем левом углу диаграммы, а наименее доминирующий блок в правом нижнем
углу. Порядок доминирования обозначен цифрой, расположенный в правом нижнем
углу блока.
Построение модели начинается с контекстной
диаграммы. На ней система представляется виде одного блока. Дуги отображают
связи системы с внешними системами. Название дуг блока являются достаточно
общими, так как характеризуют всю систему целиком. Кроме того, на контекстной
диаграмме указывается цель создания модели системы и точка зрения (с каких
позиций рассматривается система.) Контекстная диаграмма обозначается как A0.
Далее система декомпозируется на три - пять блоков и обозначается А1. Затем
каждый из блоков в свою очередь декомпозируется на три - пять блоков на
диаграмме следующего уровня. Диаграмму обозначаются буквой А с цепочкой номеров
декомпозированных блоков.
На рисунке 4.1 представлена контекстная
диаграмма.
Рисунок 4.1 - Контекстная диаграмма
ДИАГРАММА СОСТОЯНИЙ
Диаграмма состояний по существу является графом
специального вида, который представляет некоторый автомат. Понятие автомата в
контексте UML обладает довольно специфической семантикой, основанной на теории
автоматов. Вершинами этого графа являются состояния и некоторые другие типы
элементов автомата (псевдо состояния), которые изображаются соответствующими
графическими символами. Дуги графа служат для обозначения переходов из
состояния в состояние. Диаграммы состояний могут быть вложены друг в друга,
образуя вложенные диаграммы более детального представления отдельных элементов
модели. Для понимания семантики конкретной диаграммы состояний необходимо
представлять не только особенности поведения моделируемой сущности, но и знать
общие сведения по теории автоматов.
Автомат в языке UML представляет собой некоторый
формализм для моделирования поведения элементов модели и системы в целом. В
метамодели UML автомат является пакетом, в котором определено множество
понятий, необходимых для представления поведения моделируемой сущности в виде
дискретного пространства с конечным числом состояний и переходов. С другой
стороны, автомат описывает поведение отдельного объекта в форме
последовательности состояний, которые охватывают все этапы его жизненного
цикла, начиная от создания объекта и заканчивая его уничтожением. Каждая
диаграмма состояний представляет некоторый автомат.
В языке UML под состоянием понимается
абстрактный метакласс, используемый для моделирования отдельной ситуации, в
течение которой имеет место выполнение некоторого условия. Состояние может быть
задано в виде набора конкретных значений атрибутов класса или объекта, при этом
изменение их отдельных значений будет отражать изменение состояния
моделируемого класса или объекта.
Диаграмма состояний для проектируемой предметной
области представлена на рисунке 5.1.
Рисунок 5.1 - Диаграмма состояний
6 ДИАГРАММА ДЕЯТЕЛЬНОСТИ
Диаграмма деятельности - диаграмма, на которой
показано разложение некоторой деятельности на её составные части. Под
деятельностью понимается спецификация исполняемого поведения в виде
координированного последовательного и параллельного выполнения подчинённых
элементов - вложенных видов деятельности и отдельных действий, соединённых
между собой потоками, которые идут от выходов одного узла к входам другого.
При моделировании поведения проектируемой или
анализируемой системы возникает необходимость не только представить процесс
изменения ее состояний, но и детализировать особенности алгоритмической и
логической реализации выполняемых системой операций. Традиционно для этой цели
использовались блок-схемы или структурные схемы алгоритмов. Каждая такая схема
акцентирует внимание на последовательности выполнения определенных действий или
элементарных операций, которые в совокупности приводят к получению желаемого
результата.
Для моделирования процесса выполнения операций в
языке UML используются так называемые диаграммы деятельности. Применяемая в них
графическая нотация во многом похожа на нотацию диаграммы состояний, поскольку
на диаграммах деятельности также присутствуют обозначения состояний и
переходов. Отличие заключается в семантике состояний, которые используются для
представления не деятельностей, а действий, и в отсутствии на переходах
сигнатуры событий. Каждое состояние на диаграмме деятельности соответствует
выполнению некоторой элементарной операции, а переход в следующее состояние
срабатывает только при завершении этой, операции в предыдущем состоянии.
Таким образом, диаграммы деятельности можно
считать частным случаем диаграмм состояний. Именно они позволяют реализовать в
языке UML особенности процедурного и синхронного управления, обусловленного
завершением внутренних деятельностей и действий.
В общем случае действия на диаграмме
деятельности выполняются над теми или иными объектами. Эти объекты либо
инициируют выполнение действий, либо определяют некоторый результат этих
действий.
Диаграмма деятельности для проектируемой
предметной области представлена на рисунке 6.1.
Рисунок 6.1 - Диаграмма деятельности
7 ДИАГРАММА «СУЩНОСТЬ-СВЯЗЬ»
Модель сущность-связь (ER-модель) -
модель данных
<#"564529.files/image004.gif">
Рисунок 7.1 - Диаграмма «сущность-связь»
ДИАГРАММА КОМПОНЕНТОВ
Диаграмма компонентов - статическая
структурная диаграмма
<#"564529.files/image005.gif">
Рисунок 8.1 - Диаграмма компонентов.
ДИАГРАММА РАЗМЕЩЕНИЯ
Диаграмма развёртывания
(размещения), в UML <#"564529.files/image006.gif">
Рисунок 9.1 - Диаграмма развёртывания
10 ДИАГРАММА КЛАССОВ
В UML
<#"564529.files/image007.gif">
11 ДИАГРАММА ВЗАИМОДЕЙСТВИЯ
В языке UML взаимодействие элементов
рассматривается в информационном аспекте их коммуникации, т. е.
взаимодействующие объекты обмениваются между собой некоторой информацией. При
этом информация принимает форму законченных сообщений. Другими словами, хотя
сообщение и имеет информационное содержание, оно приобретает дополнительное
свойство оказывать направленное влияние на своего получателя. Это полностью
согласуется с принципами ООАП, когда любые виды информационного взаимодействия
между элементами системы должны быть сведены к отправке и приему сообщений
между ними.
Для моделирования взаимодействия объектов в
языке UML используются соответствующие диаграммы взаимодействия. Говоря об этих
диаграммах, имеют в виду два аспекта взаимодействия. Взаимодействия объектов
можно рассматривать во времени, и тогда для представления временных
особенностей передачи и приема сообщений между объектами используется диаграмма
последовательности.
На диаграмме последовательности изображаются
исключительно те объекты, которые непосредственно участвуют во взаимодействии и
не показываются возможные статические ассоциации с другими объектами. Для
диаграммы последовательности ключевым моментом является именно динамика
взаимодействия объектов во времени.
Линия жизни объекта изображается пунктирной
вертикальной линией, ассоциированной с единственным объектом на диаграмме
последовательности. Линия жизни служит для обозначения периода времени, в
течение которого объект существует в системе и, следовательно, может
потенциально участвовать во всех ее взаимодействиях. Если объект существует в
системе постоянно, то и его линия жизни должна продолжаться по всей плоскости
диаграммы последовательности от самой верхней ее части до самой нижней.
В процессе функционирования
объектно-ориентированных систем одни объекты могут находиться в активном
состоянии, непосредственно выполняя определенные действия или в состоянии
пассивного ожидания сообщений от других объектов. Чтобы явно выделить подобную
активность объектов, в языке UML применяется специальное понятие, получившее
название фокуса управления.
Диаграмма последовательности для проектируемой
предметной области представлена на рисунке 11.1.
Рисунок 11.1 -Диаграмма взаимодействия
12 ТЕОРИЯ О BPWIN
- мощный инструмент моделирования, который
используется для анализа, документирования и реорганизации сложных
бизнес-процессов. Модель, созданная средствами BPwin, позволяет четко
документировать различные аспекты деятельности - действия, которые необходимо
предпринять, способы их осуществления, требующиеся для этого ресурсы и др.
Таким образом, формируется целостная картина деятельности предприятия - от
моделей организации работы в маленьких отделах до сложных иерархических
структур. При разработке или закупке программного обеспечения модели
бизнес-процессов служат прекрасным средством документирования потребностей,
помогая обеспечить высокую эффективность инвестиций в сферу IT. В руках же
системных аналитиков и разработчиков BPwin - еще и мощное средство
моделирования процессов при создании корпоративных информационных систем.
Модели BPwin дают основу для осмысления
бизнес-процессов и оценки влияния тех или иных событий, а также описывают
взаимодействие процессов и потоков информации в организации. Неэффективная,
высоко затратная или избыточная деятельность может быть легко выявлена и,
следовательно, усовершенствована, изменена или устранена в соответствии с
общими целями организации.
Внешние обстоятельства зачастую вынуждают
вносить изменения в деятельность организации. Последствия этих изменений должны
быть тщательно изучены и осмыслены перед тем, как система будет переделана с их
учетом. BPwin может помочь пользователю на протяжении всего цикла, предоставив
возможность оптимизировать бизнес-процесс, которого коснутся эти изменения.
С помощью BPwin пользователь может сделать свою
работу более продуктивной. Действия и другие объекты создаются буквально
несколькими щелчками мыши, а затем легко отбуксированы в нужное место.
Интерфейс BPwin, выполненный в стиле "проводника" облегчает навигацию
и редактирование сложных процессов с иерархической структурой. Развитые
возможности изменения масштаба представления позволяют быстро найти и
сосредоточиться на необходимой для работы части модели процесса.позволяет:
· Обеспечить эффективность операций,
рассматривая текущие бизнес-операции через мощные инструменты моделирования;
· совершенствовать бизнес-процессы,
формулируя и определяя альтернативные реакции на воздействия рынка;
· быстро исключать непродуктивные
операции, легко и интуитивно сопоставляя операционные изменения. Неэффективные,
неэкономичные или избыточные операции могут быть легко выявлены и,
следовательно, улучшены, изменены или вовсе исключены - в соответствии с целями
компании.автоматизирует решение многих вспомогательных задач, которые обычно
связаны с построением модели процесса, и обеспечивает логическую строгость,
необходимую для достижения корректных и согласованных результатов. BPwin
отслеживает связи в диаграммах, сохраняя их целостность при внесении изменений
в модель. Динамическая "подсветка" объектов служит подсказкой при
построении модели и предостерегает от повторения распространенных ошибок в
моделировании. Кроме этого, BPwin поддерживает заданные пользователем свойства,
что позволяет вносить соответствующую вашим потребностям информацию.
Различные варианты оформления с гибким
использованием шрифтов, цвета и других средств форматирования придают
документам большую наглядность. Пользователь может просматривать и
распечатывать общее представление своей модели в виде древовидных диаграмм. С
помощью средства создания FEO диаграмм (For Exposition Only) вариации модели
или проблемной области можно проанализировать, не внося изменений в основную
модель. Возможности настройки пользовательских палитр цветов позволяют легко
адаптировать вид документов в соответствии с особенностями принтера или
демонстрационного проектора без внесения изменений в саму модель.позволяет
адаптироваться к постоянно меняющимся реалиям современного рынка
Конкуренция предполагает мгновенную реакцию на
новые возможности, угрозы и потребности покупателей. Сегодня постоянные
изменения стали нормой. Поскольку бизнес-процессы становятся все более сложными,
требуются решения, представляющие интегрированный взгляд на функционирование
компании.совмещает в одном инструменте средства моделирования функций (IDEF0),
потоков данных (DFD) и потоков работ (IDEF3), координируя эти три основных
аспекта бизнеса для соответствия потребностям бизнес - аналитиков и системных
аналитиков. BPwin позволяет повторно использовать ключевую информацию
моделирования с точки зрения базовых аспектов, чтобы определить точки
конфликтов и, в конечном счете, достичь их согласования.
С помощью функционального моделирования (нотация
IDEF0), можно провести систематический анализ бизнеса, сосредоточившись на
регулярно решаемых задачах (функциях), свидетельствующих об их правильном
выполнении показателях, необходимых для этого ресурсах, результатах и исходных
материалах (сырье).
Моделирование потоков данных (DFD), часто
используемое при разработке программного обеспечения, сосредоточено вокруг
потоков данных, передающихся между различными операциями, включая их хранение,
для достижения максимальной доступности и минимального времени ответа. Такое
моделирование позволяет рассмотреть конкретный процесс, проанализировать
операции, из которых он состоит, а также точки принятия решений, влияющих на
его ход.
Моделирование потоков работ позволяет рассмотреть
конкретный процесс, проанализировать операции, из которых он состоит, а также
точки принятия решений, влияющих на его ход.
ТЕОРИЯ О MICROSOFT
WORD
Общее название программных средств,
предназначенных для создания, редактирования и форматирования простых и
комплексных текстовых документов, - текстовые процессоры. Одним из таких
текстовых процессоров является текстовый редактор из пакета Microsoft
Office - Microsoft
Word. На момент
написания данного курсового проекта актуальной является версия Microsoft
Word 2010.
Первоначальная версия текстового процессора
Microsoft Word относится к операционной системе MS-DOS. Эта система не является
графической и не может соблюдать принятый принцип соответствия экранного
изображения печатному (принцип WYSIWYG).
Принцип WYSIWYG впервые был реализован версий
программы, которая называлась Microsoft Word for Windows. Благодаря этому
принципу значительно упростились и стали наглядными приемы форматирования
документов.
Следующая версия программы называлась Microsoft
Word 95. Она была ориентирована на графическую операционную систему Windows 95.
Основным достижением этой системы стало, то, что после нее текстовой процессор
не рассматривался только как отдельное приложение. В состав мощного офисного
пакета Microsoft Office входит несколько приложений (с каждой новой версией
пакета этот состав расширяется), и на процессор Microsoft Word возлагаются,
дополнительный функций интеграций прочих приложений. Он занимает центральное
положение в системе и позволяет организовать эффективный обмен данными между
составляющими приложениями, что позволило в значительной степени
автоматизировать разработку офисных документов разной содержательности и
сложности.
Еще одним важным нововведением в этой версий
стало управление взаимодействием текста со встроенными объектами, что
значительно расширило набор возможностей при форматировании документов. А
особенный успех этой версий программы в России завоевали встроенные средства
поддержки русского языка (Автоматически проверки орфографии и грамматики).
Дальнейшая версия программы
Microsoft Word 97,вошедшая в состав пакета Microsoft Office 97,внесла
относительно мало практически полезных изменений для повседневной офисной
работы. Расписание
Начиная с этой версий текстовой
процессор Microsoft Word можно рассматривать как средство автоматизаций
авторской деятельности. При использовании этой программы следует четко
определить целевой объект-документ Электронный или печатный. Для разных типов
документов используют разные средства, приемы и методы. Приемы не адекватных
средств значительно усложняет последующие этапы работы с документами.
Усовершенствованная версия
текстового процессора это Microsoft Word 2000, входящая в состав пакета
Microsoft Office 2000. В ней заметно улучшена система управления и введены мощные
средства поддержки сетевых режимов работы.
Это комплекс программ около 25
Мбайт, расположенных в отдельной папке либо в общей папке пакета MS Office.
Запустить Word можно из панели<MS
Office> на рабочем столе, либо с помощью ярлыка (если он присутствует на
рабочем столе), либо из Главного меню стандартным образом, найдя в нем имя
<Word>.
Для работы с ранее созданными
файлом, содержащим документ Word. Можно вызвать текстовый редактор. Путем
двойного щелчка левой кнопки мыши на имени этого файла.
Для завершения работы Word следует
закрыть его окно любым известным способом. Если измененный документ не был
записан в файл, Word потребует сохранить документ либо подтвердить
необходимость выхода без его сохранения.
ВЫВОДЫ
Результатом курсового проекта стало
визуальное моделирование предметной области «Генеалогическое дерево». Перед
написанием предметная область тщательно анализировалась.
На основании полученных данных и,
продолжая углубляться в предметную область, были разработаны диаграмма классов,
взаимодействия, состояния, деятельности, компонентов, размещения и
сущность-связь. Все диаграммы были составлены на языке UML.
Наличие в языке UML изобразительных средств для
представления структуры и поведения модели позволяет достичь адекватного
представления декларативных и процедурных знаний и, что не менее важно,
установить между этими формами знаний семантическое соответствие. Все эти
особенности языка UML позволяют сделать вывод о том, что он имеет самые
серьезные перспективы уже в ближайшем будущем.
СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ
1. Г. Буч, Д. Рамбо, А. Джекобсон,
Программирование: Язык UML.
Руководство пользователя : Питер, 2005. - 205 стр.
2. С. Макконнелл, Совершенный код.
Мастер-класс. / Пер. с англ. - М.: Издательско-торговый дом "Русская
редакция” ; СПб. : Питер, 2005. - 896 стр.: ил
3. М. Фаулер, К. Скотт.,
Программирование: UML:
Основы.
Приложение А
ТЕХНИЧЕСКОЕ ЗАДАНИЕ
А.1 Общие сведения
Тема курсового проекта:
«Объектно-ориентированный анализ и проектирование программного обеспечения.
Генеалогическое <http://sp.cmc.msu.ru/courses/prak5/variants.html>
дерево».
Система проектируется студентом 2-го
курса Донецкого национального технического университета (ДонНТУ), факультета
ИИиИИ, группы ПОС-10а Келембетом Сергеем Валерьевичем.
Основанием для разработки ПП
является задание, выданное кафедрой ПОИС. Плановый срок начала работы по
созданию информационной системы: 03.02.2012 г., срок окончания: 18.04.2012 г.
А.2 Назначение и цели создания
программы
Данный программный продукт
предназначен для работы системы создания и поддержки составления
генеалогического <http://sp.cmc.msu.ru/courses/prak5/variants.html>
дерева.
Целью курсового проектирования
является обеспечение качественной работы системы создания и поддержки
составления генеалогического <http://sp.cmc.msu.ru/courses/prak5/variants.html>
дерева посредством создания диаграмм, обеспечивающих быстрый и удобный доступ к
информации.
А.3 Требования к оформлению проектной
документации
Проектная документация должна содержать
следующие диаграммы UML:
- структурная
диаграмма процесса разработки;
- диаграмма
деятельности;
- диаграмма
«сущность-связь»;
- диаграмма
компонентов;
- диаграмма
размещения.
А.4 Требования к программному обеспечению
Программный продукт разрабатывается под
операционную систему MS
Windows ХР, Vista,
7.
Разработка проекта предусматривается на языке
C++. Проектная документация оформляется с использованием диаграмм UML.
А.5 Требования к техническому обеспечению
Для запуска проекта необходим компьютер со
следующими характеристиками:
процессор с тактовой частотой 1 Гц или выше;
объем оперативной памяти - не менее 512 Мб;
свободное дисковое пространство - около 1 Гб. Не
менее 500 Мб свободного дискового пространства для временных файлов;
графический адаптер - VGA-совместимый;
монитор - VGA-совместимый;
клавиатура.
А.6.1 Требования к системе в целом
В целом к системе предъявляются следующие
требования:) обеспечить удобный и понятный пользовательский интерфейс;) организовать
защиту от некорректного ввода данных;) обеспечить надежное хранение
информации.
А.6.2 Требования к задачам и функциям
программного продукта
В процессе работы необходимо обеспечить
выполнение следующих функций:) операции создания, обновления,
добавления, удаления, поиска.) вывод отчетов на экран;