Архитектура Аудит Военная наука Иностранные языки Медицина Металлургия Метрология
Образование Политология Производство Психология Стандартизация Технологии


IDEF0-модели состоят из трех типов документов:



-графических диаграмм(главный компонент IDEF0-модели, содержащий блоки, стрелки, соединения блоков и стрелок и ассоциированные с ними отношения)

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

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

В методологии IDEF0 существует 6 типов отношений между блоками в пределах одной диаграммы:

-доминирование;

-управление;

-выход - вход;

-обратная связь по управлению;

-обратная связь по входу;

-выход – механизм

Билет

  1. Диаграммы потоков данных (DFD-диаграммы) и диаграммы потоков работ (IDEF3-диаграммы), их использование при моделировании предметной области.

Ответ

Эти диаграммы (Data flow diagramming, DFD) хорошо дополняют функциональные диаграммы модели, описывая потоки данных

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

Используются для описания документооборота, обработки информации

С помощью DFD-диаграмм требования к проектируемой ИС разбиваются на функциональные компоненты (процессы) и представляются в виде сети, связанной потоками данных

Главная цель декомпозиции DFD-функций- продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами

На DFD-диаграммах могут присутствовать следующие элементы:

-функциональные блоки (процессы);

-стрелки (данные);

-хранилища данных;

-внешние ссылки

Билет

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

Ответ

Этап анализа (analysis) состоит в исследовании системных требований и проблемы,

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

. Задачи:

1) Понять проблему или проблемы, которые программная (или иная) система должна решить.

2) Задать значимые вопросы о проблеме и о системе.

3) Обеспечить основу для ответов на вопросы о специфических свойствах проблемы и системы.

4) Определить, что система должна делать.

5) Определить, что система не должна делать.

6) Убедиться, что система удовлетворит потребности ее пользователей и определить критерии ее приемки. Это особенно важно, когда система разработана по контракту для внешнего клиента.

7) Обеспечить основу для разработки системы.)

Предметная область: Что делается Как делаетсяГде делается Кто делает Когда делаетсяЗачем делается

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

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

Для этого надо ответить на вопросы:

· Кто будет снабжать систему информацией?

· Кто будет получать информацию от системы?

· Кто будет осуществлять поддержку и обслуживание системы?

· Использует ли система внешние ресурсы?

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

Нефункциональные требования к системе, их виды.

Описывают характеристики системы и ее окружения

Эргономичность: Для достижения высокой скорости обслуживания покупателей при его высоком качестве необходимо:

· обеспечить минимальное время отклика системы,

· текст должен быть виден с расстояния 1 м,

· не должно быть мерцания экрана,

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

Надежность: При сбое в работе внешних систем (анализ деятельности) необходимо обеспечить возможность локальной обработки данных, их сохранение и последующую передачу

Производительность: Покупатель хочет оформить покупку как можно быстрее

— Одна из основных причин задержки – низкая скорость авторизации

— Необходимо обеспечить выполнение авторизации менее, чем за 1 минуту в 90% случаев

 

Билет

  1. Функциональные требования к системе. Способ их представления в виде UML-диаграммы. Пример диаграммы с использованием отношений «расширяет» и «включает».
  2. Понятие прецедента и сценария

Ответ

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

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

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


 

Билет

  1. Концептуальная модель системы: концептуальные классы, системные события и системные операции. Способ их представления в виде UML-диаграмм. Пример концептуального описания прецедента.

Ответ

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

Отображает наиболее важные для цели моделирования классы понятий (концептуальные классы) предметной области

Кроме того концептуальная модель может отображать

    1. ассоциации между концептуальными классами,
    2. атрибуты концептуальных классов

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

Системное событие (systemevent) — это событие высокого уровня, генерируемое внешним исполнителем (событие с внешним входом). Системные события связаны с системными операциями (systemoperation), т.е. операциями, выполняемыми системой в ответ на события.


Поделиться:



Последнее изменение этой страницы: 2019-05-18; Просмотров: 830; Нарушение авторского права страницы


lektsia.com 2007 - 2024 год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! (0.016 с.)
Главная | Случайная страница | Обратная связь