- •Проектирование информационной системы «дефектоскопии рельсов»
- •Анализ предметной области
- •Анализ аналогов и прототипов
- •Требования к по
- •Обоснование выбора компонентов
- •Определение критериев выбора среды разработки
- •Обоснование выбора технологии доступа к бд
- •Выбор языка программирования
- •Обоснование выбора используемой субд
- •Выводы по первой главе
- •Структурный подход к проектированию по
- •Функциональная модель по
- •Диаграмма потоков данных
- •Логическая модель данных
- •Объектно – ориентированный подход к проектированию по
- •Определение вариантов использования
- •Диаграмма классов
- •Описание поведения программного средства
- •Диаграмма последовательностей
- •Диаграмма деятельности
- •Диаграмма состояния
- •Проектирование пользовательского интерфейса
- •Граф переходов состояний интерфейса
- •Проектирование интерфейса
- •Реализация и тестирование по
- •Создание базы данных
- •Требования к программе
- •Требования к функциональным характеристикам
- •Технико-экономические показатели
- •Стадии и этапы разработки
Описание поведения программного средства
Диаграмма последовательностей
Диаграмма последовательности (англ. sequence diagram) — диаграмма, на которой показано взаимодействие объектов (обмен между ними сигналами и сообщениями), упорядоченное по времени, с отражением продолжительности обработки и последовательности их проявления. Используется в языке UML.
Основными элементами диаграммы последовательности являются обозначения объектов (прямоугольники с названиями объектов), вертикальные "линии жизни"(англ. lifeline), отображающие течение времени, прямоугольники, отражающие деятельность объекта или исполнение им определенной функции (прямоугольники на пунктирной "линии жизни"), и стрелки, показывающие обмен сигналами или сообщениями между объектами.
Для данной информационной системы была построены диаграммы последовательностей UML формирование списка дефектоскопов рисунок 3.3, и обслуживание дефектоскопа рисунок 3.4.
Рисунок 3.3 – Диаграмма последовательностей "Формирование списка дефектоскопов"
Рисунок 3.4 – Диаграмма последовательностей "Обслуживание дефектоскопа"
Диаграмма деятельности
Диаграмма деятельности (англ. activity diagram) — UML-диаграмма, на которой показано разложение некоторой деятельности на её составные части. Под деятельностью (англ. activity) понимается спецификация исполняемого поведения в виде координированного последовательного и параллельного выполнения подчинённых элементов — вложенных видов деятельности и отдельных действий англ. action, соединённых между собой потоками, которые идут от выходов одного узла ко входам другого.
Для данной информационной системы была построены диаграммы деятельности UML формирование дефектоскопов рисунок 3.5, и обслуживание дефектоскопа рисунок 3.6.
На данной диаграмме показаны алгоритмы формирование дефектоскопов рисунок 3.5.
Рисунок 3.5 – Диаграмма деятельности "Формирование дефектоскопов"
На данной диаграмме показаны алгоритмы обслуживание дефектоскопа рисунок 3.6.
Рисунок 3.6 – Диаграмма деятельности "Обслуживание дефектоскопа"
Диаграмма состояния
Диаграмма состояний представляет динамическое поведение сущностей, на основе спецификации их реакции на восприятие некоторых конкретных событий.
Для данной информационной системы была построена диаграмма состояний UML рисунок 3.7.
Рисунок 3.7 – Диаграмма состояния "Дефектоскопа"
Диаграмма состояния разработана для объекта «Дефектоскоп». Дефектоскоп может находиться в 3-х состояниях: новый дефектоскоп, действующий дефектоскоп, списанный дефектоскоп.
Новый дефектоскоп появляется, когда за, МОЛ, закрепляется новый дефектоскоп.
Действующий когда МОЛ работает с дефектоскопом и списанные когда дефектоскоп списывают с предприятия.
Проектирование пользовательского интерфейса
Проектирование графического интерфейса представляет собой междисциплинарную деятельность.
Задача программиста заключается не в том, чтобы слепо реализовать экраны, но также предложить изменения, обусловленные средой программирования. В некоторых случаях изменения могут привести к улучшению GUI интерфейса, в других случаях изменения отрицательно сказываются на проекте из-за ограничений, связанных с программированием или продуктивностью.
Основной момент в проектировании GUI интерфейса заключается в том, что контроль находится на стороне пользователя (при условии, что система, а не пользователь, контролирует системную целостность, защиту и безопасность). Современные объектно – ориентированные программы управляются событиями. Объекты реагируют на события (сообщения). Внутренние взаимодействия между объектами запускаются внешними событиями, инициируемыми пользователем. «Впечатление и ощущение» от GUI интерфейса служит «двигателем торговли» при продаже программного продукта заказчику. Прототипы GUI интерфейса могут служить двоякой цели оценки «ощущения» от GUI экранов и передачи его функций.
