Проектирование программного продукта «Генеалогическое дерево»

Доступны для изменения следующие поля таблицы «Персона»: имя, дата смерти, биография.

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

2. Вывод запрошенной информации. Должна быть предусмотрена возможность  получать следующие сведения  о персоне:

- список детей;

- список родителей;

- список братьев и сестер;

- список всех предков;

- список всех потомков;

- список всех родственников;

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

К предкам персоны относятся родители, их родители, родители их родителей и т.д.

К потомкам персоны относятся дети, их дети, дети их детей и т.д.

К родственникам персоны относятся все персоны, прямо или косвенно связанные с ней.

База данных хранится в файле на внешнем носителе. Должна быть возможность сохранения текущей базы и загрузки ранее созданной.

Программный генеалогическое дерево

 

2. Проектирование программного  продукта

 

2.1 Описание модели вариантов  использования

2.1.1 Диаграмма вариантов  использования

Были выбраны следующие актеры и прецеденты (рисунок 2).

Актёры:

Пользователь – человек, работающий с системой. Этот актер инициирует все прецеденты.

База данных – файл на внешнем носителе, хранящий таблицы данных. Взаимодействие с этим актером происходит при чтении и сохранении базы данных.

Прецеденты:

Наполнение базы – включает в себя процедуры добавления, редактирования и удаления записей из базы.

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

 

 

Рисунок 2- Актеры и прецеденты

 

 

2.2 Описание модели анализа  системы

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

Рассмотрим более подробно прецеденты, выделенные на предыдущем этапе.

В варианте использования «Наполнение базы» могут быть выделены следующие потоки событий: пользователь выбирает, с чем он будет работать с персонами или со связями. После чего пользователю предлагается Добавить, Изменить, Удалить персону, либо Добавить, Удалить связь. В случае Добавления персоны, система запрашивает данные о персоне, и после того, как пользователь ввел все необходимые данные, новая запись добавляется в базу.

Если пользователь решил изменить какие-либо данные, ему предлагается выбрать  ту персону из списка, чьи данные будут изменены.

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

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

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

Альтернативные потоки событий:

1. При удалении персоны  выясняется, что удаляемая персона  состоит в связях.

1.1. Выводится сообщение об ошибке, и прецедент завершается.

2. При добавлении связи  выясняется, что таблица персон  содержит менее двух записей.

2.1. Выводится сообщение  об ошибке и прецедент завершается.

Предусловия.

1. Система должна находиться  в состоянии «Ожидание действий от пользователя».

Постусловия.

1. Система возвращается  в состояние «Ожидание действий  от пользователя».

Вариант использования «Запрос к базе»

Основные потоки событий:

1. Пользователь выбирает, какой запрос выполнить.

1.1. Исходными данными  для запроса служит одна персона.

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

1.2. Исходными данными  для запроса служит 2 персоны.

1.2.1. Пользователь выбирает  нужных персон из списка.

2. Система выполняет поиск  в базе по запросу.

3. Система отображает результат запроса.

Предусловия.

1. Система должна находиться  в состоянии «Ожидание действий  от пользователя».

Постусловия.

1. Система возвращается  в состояние «Ожидание действий  от пользователя».

 

 

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

 

Родословное или генеалогическое древо - схематичное представление родственных связей, родословной росписи в виде условно-символического «дерева», у «корней» которого указывается родоначальник, на «стволе» - представители основной (по старшинству) линии рода, а на «ветвях» - различных линиях родословия, известные его потомки - «листья» (настоящий пример иллюстрирует древо «нисходящего родословия», каковые являются наиболее распространёнными); но зачастую, если она, роспись, не стилизована в виде дерева реального, что было очень распространено в прошлом, схема эта для удобства восприятия и формирования представляет родословное древо в перевёрнутом виде, когда родоначальник располагается в верхней части таблицы

Основой генеалогических исследований является оформление в виде родословия сведений, полученных в ходе поиска. Для записи родословий применяются три способа: родословное дерево, родословная таблица и родословная роспись. Наиболее широкое распространение получили родословия в виде генеалогического дерева. В других вариантах дерева в основании помещается имя того, для кого составляется родословная, а его предки образовывали "ствол" и "крону". Внешний вид генеалогических таблиц также разнообразен: они могут быть вертикальными, горизонтальными и круговыми. Таблицы очень удобны в использовании, так как наглядны и компактны. Их недостатком считается чрезвычайный лаконизм. Кроме того, генеалогическая таблица, как правило, охватывает не более десяти поколений, так как дальнейшее продолжение затрудняет работу с ней.

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

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

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

 

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

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

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

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

описывается функционирование верхнего уровня, а каждая функция

декомпозируется на несколько уровней.

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

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

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

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

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

 

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

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

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

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

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

 

 

 

Рисунок 3 - Диаграмма состояний

 

 

 

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

 

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

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

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

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

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

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

 

 

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

 

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

 

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

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