Мегаобучалка Главная | О нас | Обратная связь


Разработка информационно-логической модели разрабатываемой автоматизированной системы



2018-06-29 446 Обсуждений (0)
Разработка информационно-логической модели разрабатываемой автоматизированной системы 0.00 из 5.00 0 оценок




Унифицированный язык моделирования – UML(Unified Modeling Languadge), который предназначен для описания, визуализации и документирования объектно-ориентированных систем и бизнес процессов с ориентацией их на последующую реализацию в виде программного обеспечения. При создании учитывались следующие требования:

- позволять моделировать не только программное обеспечение, но и более широкие классы систем и бизнес-приложений, с использованием объектно-ориентированных понятий;

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

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

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

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

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

Логическое проектирование программного комплекса было произведено с помощью CASE-средства UML-проектирования Visual Paradigm.

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

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

Разработка диаграммы вариантов использования преследует следующие цели:

- определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы;

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

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

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

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

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

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

Отношения – описывающие взаимодействия экземпляров одних акторов и вариантов использования с экземплярами других акторов и вариантов. В языке UML имеется несколько стандартных видов отношений между акторами и вариантами использования:

Отношение ассоциации – служит для обозначения специфической роли актора в отдельном варианте использования.

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

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

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

На диаграмме вариантов использования в данном курсовом проекте были предложены следующие акторы:

тестируемый – осуществляет прохождение психологических тестов;

психолог – осуществляет просмотр результатов тестирований, ответов. Данных тестируемым и проверяет корректность тестов.

Также на диаграмме предложены следующие варианты использования системы:

- войти в систему;

- пройти тест;

- выбрать тест;

- проверить тест;

- просмотреть данные ответы тестируемого;

- просмотреть результаты прохождения теста;

- выбрать тестируемого;

- выбрать тест.

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

 

Рисунок 4.1 - Диаграмма вариантов использования системы

Сценарии

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

Сценарий варианта использования «Прохождение тестирования»

Вариант использования: Прохождение тестирования.

Краткое описание. Позволяет тестируемому пройти психологический тест.

Актант. Тестируемый.

Предусловия. Вариант использования "Войти в систему" выполнен успешно, на экране главное окно приложения с пунктами главного меню, настроенное на права тестируемого.

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

Тестируемый выбирает пункт «Тесты», в котором выбирает необходимый тест.

А1: «Выход».

Система начинает проведение теста. На форме появляется текст пояснения к прохождению данного теста, текст первого вопроса и варианты ответа с радио-кнопками и кнопка «Далее». Активна кнопка «Далее»

Тестируемый выбирает один из предлагаемых вариантов ответа, используя радио-кнопки. Нажимает кнопку «Далее».

Система выводит на форму текст следующего вопроса.

A2: Тестирование окончено.

Выполняется пункт 3 основной последовательности.

Альтернативы.

А1: Выбран пункт меню «Выход».

А1.1: Система закрывает главную форму приложения, приложение завершает свою работу. Вариант использования завершается.

A2: Тестирование окончено.

А2.1 Тестирование окончено. На экран выводится текст о завершении прохождения тестирования. Система выводит главное окно приложения, настроенное на права тестируемого. Вариант использования завершается успешно.

 

Сценарий варианта использования «Просмотр результатов тестирования психологом»

Вариант использования: Просмотр результатов тестирования психологом.

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

Актант. Психолог.

Предусловия. Вариант использования "Войти в систему" выполнен успешно, на экране – главное окно приложения с пунктами главного меню, настроенное на права психолога.

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

1. Психолог выбирает пункт «Просмотр», подпункт «Просмотр результатов тестирования».

2. Система выводит на главную форму поля ввода с присоединёнными выпадающими списками: «Тестируемый», «Тест», «Дата прохождения».

3. Психолог выбирает нужного тестируемого, тест и дату прохождения.

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

5. Психолог нажимает пункт главного меню «Выход».

А1: Психолог изменяет значение полей «Тестируемый», «Тест», «Дата тестирования».

А2: Психолог изменяет выбранный пункт списка критериев.

6. Система закрывает главное окно программы. Программа завершает свою работу. Вариант использования завершается успешно.

Альтернативы.

А1: Психолог изменяет значение полей «Тестируемый», «Тест», «Дата тестирования».

А1.1: Система обновляет содержимое списка критериев, количество баллов, набранное выбранным тестируемым. Выбранным становится первый пункт списка критериев. Выполняется пункт 4 основной последовательности.

А2: Психолог изменяет выбранный пункт списка критериев.

А2.1: Система обновляет тест описания критерия и количество баллов, набранных тестируемым по вновь выбранному критерию. Выполняется пункт 4 основной последовательности.

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

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

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

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

Кроме внутреннего устройства или структуры классов, на соответствующей диаграмме указываются различные отношения между классами. Базовыми отношениями или связями в языке UML являются: отношение, отношение ассоциации, отношение агрегации, отношение, отношение обобщения.

Существуют разные точки зрения на построение диаграмм классов в зависимости от целей их применения:

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

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

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

В разрабатываемой системе на концептуальном уровне выделено 3 группы классов:

· Группа сущностных классов (рисунок 4.2);

· Группа управляющих классов (рисунок 4.3);

· Группа граничных классов (рисунок 4.4).

Сущностный класс представляет собой объект предметной области. В рамках курсового проекта выбраны следующие сущностные классы:

1. «Тестируемый» - имеет код тестируемого, фамилию, имя, отчество и дату рождения, связан с классом «Пройденный тест» отношением 1 – 0..*.

2. «Тест» – имеет код теста, название теста, инструкции по прохождению, связан с классом «Вопрос» отношением 1 – 1..* , с классом «Критерий» отношением 1 – 1..* и с классом «Вариант» отношением 1 – 1..*.

3. «Критерий» - имеет код критерия и название, связан с классом «Тест» отношением 1..* – 1 и с классом «Результат» отношением 1 - 0..*.

4. «Вариант ответа» - имеет код ответа, название ответа, связан с классом «Тест» отношением 1..* – 1 и с классом «Данный ответ» отношением 1 – 0..*.

5. «Вопрос» - имеет код вопроса, текст вопроса, правильный вариант ответа, связан с классом «Тест» отношением 1 – 1..*.

6. «Пройденный тест» - имеет дату прохождения, связан с классом «Тестируемый» отношением 0..* - 1 и с классом «Тест» отношением 1 – 0..*, с классом «Результат» отношением 1 – 1..* и с классом «Данный ответ» отношением 1 – 1..*.

7. «Данный ответ» - класс, реализующий тернарную связь между классами «Пройденный тест», «Вопрос» и «Вариант ответа».

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

Граничные классы представляют собой оконные формы, с которой взаимодействует пользователь. При запуске активируется форма «Форма аутентификации пользователя», в которой происходит авторизация тестируемого или психолога. Основная форма работы пользователя – «Главное окно». Если авторизован тестируемый, то на главной форме активизируется «Вид тестируемого», если авторизован психолог – «Вид психолога». В виде психолога представлены так же два вида для отображения ответов тестируемого – «Представление данных тестируемого» - и для отображения результатов прохождения тестирования – «Представление результатов тестирования».

Логика по обработке и отображению данных будет частично реализована в граничных классах.

 

Рисунок 4.2 – Диаграмма сущностных классов

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

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

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

Состояние определяется именем и списком внутренних действий или деятельностей, которые выполняются в процессе нахождения моделируемого элемента в данном состоянии и характеризуются меткой действия (entry, exit, do, include). Начальное состояние – частный случай состояния, которое не содержит никаких внутренних действий (псевдосостояния), в котором находится объект по умолчанию в начальный момент времени. Конечное состояние – частный случай состояния, которое не содержит никаких внутренних действий (псевдосостояния), в котором находится объект по умолчанию после завершения работы автомата в конечный момент времени. Состояния могут быть составными (композитными) – т.е. состоящими из других, вложенных в него состояний (подсостояний), которые могут быть как последовательными, так и параллельными; историческими – т.е. запоминающими; синхронизирующими.

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

Сложные переходы:

Соединение – если имеется две и более входящих дуг.

Ветвление - если имеется две и более исходящих дуг.

Общая диаграмма состояний системы представлена на рисунке 4.5.

Рисунок 4.3 – Диаграмма классов управления

Рисунок 4.4 – Диаграмма граничных классов



2018-06-29 446 Обсуждений (0)
Разработка информационно-логической модели разрабатываемой автоматизированной системы 0.00 из 5.00 0 оценок









Обсуждение в статье: Разработка информационно-логической модели разрабатываемой автоматизированной системы

Обсуждений еще не было, будьте первым... ↓↓↓

Отправить сообщение

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



©2015-2024 megaobuchalka.ru Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. (446)

Почему 1285321 студент выбрали МегаОбучалку...

Система поиска информации

Мобильная версия сайта

Удобная навигация

Нет шокирующей рекламы



(0.011 сек.)