Визуальное моделирование предметной области «Генеалогическое дерево»

СОДЕРЖАНИЕ Введение

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

2 Описание предметной области

3 Морфологическая модель

4 Функциональная модель

5 Диаграмма состояний

6 Диаграмма деятельности

7 Диаграмма «сущность-связь»

8 Диаграмма компонентов

9 Диаграмма размещения

10 Диаграмма классов

11 Диаграмма взаимодействия

12 Теория о BPWin

13 Теория о Microsoft Word

Выводы Список использованной литературы Приложение, А Техническое задание

ВВЕДЕНИЕ

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

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

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

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

Семейство продуктов Rational Rose призвано обеспечить разработчика программ полным набором инструментов визуального моделирования для эффективного решения сложных бизнес — задач с использованием архитектуры клиент/сервер, распределенных сред и систем реального времени.

1 ПОСТАНОВКА ЗАДАЧИ визуальное моделирование программный Общие определения. Разрабатываемая программа предназначена для хранения и структуризации данных генеалогического дерева. Данные, хранимые в проектируемой системе: информация о персонах, их ф.и. о, пол, дата рождения и о родственных связях между ними.

Цель и задачи разработки. Целью данного курсового проекта является проектирование и объектно-ориентированный анализ программного продукта «Система создания и поддержки составления генеалогического дерева».

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

Постановка задачи разработки программного продукта.

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

— создание генеалогического дерева;

— изменение дерева: добавления, удаление, изменение данных.

— создание отчетов.

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

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

Тестер Ищет ошибки и недочеты, его задача найти их как можно больше. Очень важно, чтобы это был независимый человек. Очень нежелательно возлагать эти функции на кого-либо из членов команды.

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

2 ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ Родословное или генеалогическое древо — схематичное представление родственных связей, родословной росписи в виде условно-символического «дерева», у «корней» которого указывается родоначальник, на «стволе» — представители основной (по старшинству) линии рода, а на «ветвях» — различных линиях родословия, известные его потомки — «листья» (настоящий пример иллюстрирует древо «нисходящего родословия», каковые являются наиболее распространёнными); но зачастую, если она, роспись, не стилизована в виде дерева реального, что было очень распространено в прошлом, схема эта для удобства восприятия и формирования представляет родословное древо в перевёрнутом виде, когда родоначальник располагается в верхней части таблицы Основой генеалогических исследований является оформление в виде родословия сведений, полученных в ходе поиска. Для записи родословий применяются три способа: родословное дерево, родословная таблица и родословная роспись. Наиболее широкое распространение получили родословия в виде генеалогического дерева. В других вариантах дерева в основании помещается имя того, для кого составляется родословная, а его предки образовывали «ствол» и «крону». Внешний вид генеалогических таблиц также разнообразен: они могут быть вертикальными, горизонтальными и круговыми. Таблицы очень удобны в использовании, так как наглядны и компактны. Их недостатком считается чрезвычайный лаконизм. Кроме того, генеалогическая таблица, как правило, охватывает не более десяти поколений, так как дальнейшее продолжение затрудняет работу с ней.

Система хранит сведения о персонах, их ф.и. о, пол, дата рождения и о родственных связях между ними. Связи бывают трех видов: мужья-жены, дети-родители и братья-сестры .

Система обеспечивает возможность добавления данных о новых персонах и родственных связях, изменение введенных данных. Система следит за непротиворечивостью вводимых данных. Недопустимо, чтобы человек был собственным предком или потомком.

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

3 МОРФОЛОГИЧЕСКАЯ МОДЕЛЬ Морфологическая модель описывает состав и структуру системы, ее взаимосвязи с окружающей средой.

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

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

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

Построение гиперкомплексной матрицы происходит в несколько этапов.

1. Определение числа иерархических уровней и числа элементов на каждом уровне.

2. Установление взаимосвязи между элементами и подсистемами на каждом уровне.

3. Формирование матрицы в виде квадрата, условная длина стороны которого определяется общим числом элементов на самом нижнем уровне иерархии.

4. Сторона квадрата разбивается на части, число которых равно количеству элементов на самом высоком уровне иерархии.

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

6. По главной диагонали выписываются элементы системы, представляя тем самым модель состава системы.

Рассмотрим построение морфологической модели системы поддержки составления расписания занятий.

Основными подсистемами являются деканат и диспетчер.

На рисунке 3.1 представлена гиперкомплексная матрица для СПСРЗ.

Рисунок 3.1 — Морфологическая модель

4 ФУНКЦИОНАЛЬНАЯ МОДЕЛЬ Функциональная модель описывает порядок работы системы. Существуют различные формальные методики описания функционирования системы. Одной из наиболее распространенных методик является IDEF технология. Особенностями IDEF являются:

— четкое определение границы системы;

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

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

Рассмотрим технологию построения модели в рамках IDEF.

Каждая IDEF диаграмма содержит блоки и дуги. Блоки изображают функцию системы, а дуги связывают блоки и описывают взаимосвязь между ними.

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

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

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

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

На рисунке 4.1 представлена контекстная диаграмма.

Рисунок 4.1 — Контекстная диаграмма

5 ДИАГРАММА СОСТОЯНИЙ Диаграмма состояний по существу является графом специального вида, который представляет некоторый автомат. Понятие автомата в контексте UML обладает довольно специфической семантикой, основанной на теории автоматов. Вершинами этого графа являются состояния и некоторые другие типы элементов автомата (псевдо состояния), которые изображаются соответствующими графическими символами. Дуги графа служат для обозначения переходов из состояния в состояние. Диаграммы состояний могут быть вложены друг в друга, образуя вложенные диаграммы более детального представления отдельных элементов модели. Для понимания семантики конкретной диаграммы состояний необходимо представлять не только особенности поведения моделируемой сущности, но и знать общие сведения по теории автоматов.

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

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

Диаграмма состояний для проектируемой предметной области представлена на рисунке 5.1.

Рисунок 5.1 — Диаграмма состояний

6 ДИАГРАММА ДЕЯТЕЛЬНОСТИ Диаграмма деятельности — диаграмма, на которой показано разложение некоторой деятельности на её составные части. Под деятельностью понимается спецификация исполняемого поведения в виде координированного последовательного и параллельного выполнения подчинённых элементов — вложенных видов деятельности и отдельных действий, соединённых между собой потоками, которые идут от выходов одного узла к входам другого.

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

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

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

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

Диаграмма деятельности для проектируемой предметной области представлена на рисунке 6.1.

Рисунок 6.1 — Диаграмма деятельности

7 ДИАГРАММА «СУЩНОСТЬ-СВЯЗЬ»

Модель сущность-связь (ER-модель) — модель данных, позволяющая описывать концептуальные схемы предметной области.

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

Во время проектирования баз данных происходит преобразование ER-модели в конкретную схему базы данных на основе выбранной модели данных (реляционной, объектной, сетевой или др.).

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

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

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

Диаграмма сущность-связь для разрабатываемой предметной области представлена на рисунке 7.1.

Рисунок 7.1 — Диаграмма «сущность-связь»

8 ДИАГРАММА КОМПОНЕНТОВ Диаграмма компонентов — статическая структурная диаграмма, показывает разбиение программной системы на структурные компоненты и связи (зависимости) между компонентами. В качестве физических компонентов могут выступать файлы, библиотеки, модули, исполняемые файлы, пакеты и т. п.

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

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

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

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

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

Диаграмма компонентов для проектируемой предметной области представлена на рисунке 8.1.

Рисунок 8.1 — Диаграмма компонентов.

9 ДИАГРАММА РАЗМЕЩЕНИЯ Диаграмма развёртывания (размещения), в UML моделирует физическое развертывание артефактов на узлах. Например, чтобы описать веб-сайт диаграмма развертывания должна показывать, какие аппаратные компоненты («узлы») существуют (например, веб-сервер, сервер базы данных, сервер приложения), какие программные компоненты («артефакты») работают на каждом узле (например, веб-приложение, база данных), и как различные части этого комплекса соединяются друг с другом.

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

Существует два типа узлов:

— Узел устройства

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

Диаграмма развёртывания для проектируемой предметной области представлена на рисунке 9.1.

Рисунок 9.1 — Диаграмма развёртывания

10 ДИАГРАММА КЛАССОВ В UML диаграмма классов является типом диаграммы статической структуры. Она описывает структуру системы, показывая её классы, их атрибуты и операторы, а также взаимосвязи этих классов.

Взаимосвязь — это особый тип логических отношений между сущностями, показанных на диаграммах классов и объектов. В UML’е представлены следующие виды отношений:

Ассоциация показывает, что объекты одной сущности (класса) связаны с объектами другой сущности.

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

Двойные ассоциации (с двумя концами) представляются линией, соединяющей два классовых блока. Ассоциации более высокой степени имеют более двух концов и представляются линиями, один конец которых идет к классовому блоку, а другой к общему ромбику. В представлении однонаправленной ассоциации добавляется стрелка, указывающая на направление ассоциации.

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

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

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

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

Диаграмма классов для проектируемой предметной области представлена на рисунке 10.1.

Рисунок 10.1 — Диаграмма классов

11 ДИАГРАММА ВЗАИМОДЕЙСТВИЯ В языке UML взаимодействие элементов рассматривается в информационном аспекте их коммуникации, т. е. взаимодействующие объекты обмениваются между собой некоторой информацией. При этом информация принимает форму законченных сообщений. Другими словами, хотя сообщение и имеет информационное содержание, оно приобретает дополнительное свойство оказывать направленное влияние на своего получателя. Это полностью согласуется с принципами ООАП, когда любые виды информационного взаимодействия между элементами системы должны быть сведены к отправке и приему сообщений между ними.

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

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

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

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

Диаграмма последовательности для проектируемой предметной области представлена на рисунке 11.1.

Рисунок 11.1 -Диаграмма взаимодействия

12 ТЕОРИЯ О BPWIN

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

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

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

С помощью BPwin пользователь может сделать свою работу более продуктивной. Действия и другие объекты создаются буквально несколькими щелчками мыши, а затем легко отбуксированы в нужное место. Интерфейс BPwin, выполненный в стиле «проводника» облегчает навигацию и редактирование сложных процессов с иерархической структурой. Развитые возможности изменения масштаба представления позволяют быстро найти и сосредоточиться на необходимой для работы части модели процесса.

BPwin позволяет:

· Обеспечить эффективность операций, рассматривая текущие бизнес-операции через мощные инструменты моделирования;

· совершенствовать бизнес-процессы, формулируя и определяя альтернативные реакции на воздействия рынка;

· быстро исключать непродуктивные операции, легко и интуитивно сопоставляя операционные изменения. Неэффективные, неэкономичные или избыточные операции могут быть легко выявлены и, следовательно, улучшены, изменены или вовсе исключены — в соответствии с целями компании.

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

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

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

BPwin совмещает в одном инструменте средства моделирования функций (IDEF0), потоков данных (DFD) и потоков работ (IDEF3), координируя эти три основных аспекта бизнеса для соответствия потребностям бизнес — аналитиков и системных аналитиков. BPwin позволяет повторно использовать ключевую информацию моделирования с точки зрения базовых аспектов, чтобы определить точки конфликтов и, в конечном счете, достичь их согласования.

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

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

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

13 ТЕОРИЯ О 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 можно из панели на рабочем столе, либо с помощью ярлыка (если он присутствует на рабочем столе), либо из Главного меню стандартным образом, найдя в нем имя .

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

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

ВЫВОДЫ Результатом курсового проекта стало визуальное моделирование предметной области «Генеалогическое дерево». Перед написанием предметная область тщательно анализировалась.

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

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

1. Г. Буч, Д. Рамбо, А. Джекобсон, Программирование: Язык UML. Руководство пользователя: Питер, 2005. — 205 стр.

2. С. Макконнелл, Совершенный код. Мастер-класс. / Пер. с англ. — М.: Издательско-торговый дом «Русская редакция»; СПб.: Питер, 2005. — 896 стр.: ил

3. М. Фаулер, К. Скотт., Программирование: UML: Основы.

Приложение, А ТЕХНИЧЕСКОЕ ЗАДАНИЕ А.1 Общие сведения Тема курсового проекта: «Объектно-ориентированный анализ и проектирование программного обеспечения. Генеалогическое дерево».

Система проектируется студентом 2-го курса Донецкого национального технического университета (ДонНТУ), факультета ИИиИИ, группы ПОС-10а Келембетом Сергеем Валерьевичем.

Основанием для разработки ПП является задание, выданное кафедрой ПОИС. Плановый срок начала работы по созданию информационной системы: 03.02.2012 г., срок окончания: 18.04.2012 г.

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

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

А.3 Требования к оформлению проектной документации Проектная документация должна содержать следующие диаграммы UML:

— структурная диаграмма процесса разработки;

— диаграмма деятельности;

— диаграмма «сущность-связь»;

— диаграмма компонентов;

— диаграмма размещения.

А.4 Требования к программному обеспечению Программный продукт разрабатывается под операционную систему MS Windows ХР, Vista, 7.

Разработка проекта предусматривается на языке C++. Проектная документация оформляется с использованием диаграмм UML.

А.5 Требования к техническому обеспечению Для запуска проекта необходим компьютер со следующими характеристиками:

— процессор с тактовой частотой 1 Гц или выше;

— объем оперативной памяти — не менее 512 Мб;

— свободное дисковое пространство — около 1 Гб. Не менее 500 Мб свободного дискового пространства для временных файлов;

— графический адаптер — VGA-совместимый;

— монитор — VGA-совместимый;

— клавиатура.

А.6 Требования к программному продукту А.6.1 Требования к системе в целом В целом к системе предъявляются следующие требования:

a) обеспечить удобный и понятный пользовательский интерфейс;

b) организовать защиту от некорректного ввода данных;

c) обеспечить надежное хранение информации.

А.6.2 Требования к задачам и функциям программного продукта В процессе работы необходимо обеспечить выполнение следующих функций:

a) операции создания, обновления, добавления, удаления, поиска.

b) вывод отчетов на экран;