Билет 17 - stankin/design-1 GitHub Wiki
1. Понятие модели системы. Элементы системы и точки зрения.
Модели могут быть физические и виртуальные. Методология SADT Модель – искусственный объект, представляющий собой отображение (образ) системы и ее компонентов. Блочное моделирование и его графическое представление. Основной концептуальный принцип методологии IDEF – представление любой изучаемой системы в виде набора взаимодействующих и взаимосвязанных блоков, отображающих процессы, операции, действия, происходящие в изучаемой системе. В IDEF0 все, что происходит в системе и ее элементах, принято называть функциями. Каждой функции ставится в соответствие блок. Лаконичность и точность. Графический язык позволяет лаконично, однозначно и точно показать все элементы (блоки) системы и все отношения и связи между ними, выявить ошибочные, лишние или дублирующие связи и т.д.
Элементами системы могут быть процессы (методология SADT) и объекты (ООП).
Блок.
Блок описывает функцию. Внутри каждого блока имя и номер. Имя должно описывать функцию. Номера блоков используются для их идентификации.
Стрелка(и) слева – вход(ы).
Стрелка(и) сверху – управление(я).
Стрелка(и) покидающая(ие) блок справа - выход(ы).
Каждая модель должна иметь контекстную диаграмму верхнего уровня А-0, на которой объект моделирования представлен единственным блоком с граничными стрелками.
А-0 имеет точку зрения должностного лица или подразделения, если поменять точку зрения, соответственно поменяется вся модель. Для ИС точка зрения должна отражать позицию оператора ИС по ФЗ "Об информации, информационных информационных технологиях и о защите информации".
Формулировка цели выражает причину создания модели, то есть содержит перечень вопросов, которые в значительной мере определяет ее структуру.
Дочерняя диаграмма, создаваемая при декомпозиции, охватывает ту же область, что и родительский блок, но описывает ее более подробно. Отношения блоков на диаграммах В методологии IDEF0 существует шесть типов отношений между блоками в пределах одной диаграммы:
- доминирование;
- управление;
- выход - вход;
- обратная связь по управлению;
- обратная связь по входу;
- выход - механизм.
Перечень узлов представляет информацию о входящих в модель узлах в форме списка, напоминающего обычное оглавление и отражающего иерархическую структуру модели, приведу пример иерархии на своей курсовой работе. Тема: "Разработка средств информационной поддержки организации по реализации швейных изделий".
Создание контекстной диаграммы и диаграммы уровня A0 c 4 блоками А0 Реализация изделий Декомпозиция автоматизируемых блоков до уровня, прямо сопоставляемого с программными модулями А1 Закупка А2 Транспортировка изделий на склад А3 Реализация изделий А4 Мониторинг и анализ продаж Декомпозиция всех автоматизируемых блоков в DFD А31 Оформление заказа А32 Контроль оплаты А33 Выдача товара Точка зрения - директор магазина швейной продукции.
Элементы иерархии механизмов определяются следующим образом: Деятельность. Организационно-техническая система - организационная структура, персонал и комплекс технических средств (оборудование), необходимые для осуществления деятельности. Процесс. Организационно-техническая подсистема - часть организационно-технической системы, обеспечивающая протекание процесса (субдеятельности). Операция. Организационно-технический комплекс (модуль) - часть организационно-технической подсистемы, предназначенная для выполнения операции. Действие. Организационно-технический блок - часть организационно-технического комплекса, обеспечивающая выполнение действия.
Сделала Семионова Анастасия
- Классификация CASE-средств по категориям инструментов.
Классификация по типам CASE-инструментов отражает функциональную ориентацию средств на те или иные процессы жизненного цикла разработки программного обеспечения:
• средства построения и анализа модели предметной области
• средства проектирования баз данных
• средства разработки приложений
• средства реинжиниринга процессов
• средства планирования и управления проектом
• средства тестирования
• средства документирования
Пример: средство тестирования Quality Works (ранее - QA)
Quality Works представляет собой интегрированную, многоплатформенную среду для разработки автоматизированных тестов любого уровня, включая тесты регрессии для приложений с графическим интерфейсом пользователя.
Quality Works позволяет начинать тестирование на любой фазе ЖЦ, планировать и управлять процессом тестирования, отображать изменения в приложении и повторно использовать тесты для более чем 25 различных платформ.
Основными компонентами Quality Works являются:
• QA Partner - среда для разработки, компиляции и выполнения тестов;
• QA Planner - модуль для разработки планов тестирования и обработки результатов. Для создания и выполнения тестов в процессе работы QA Planner вызывается QA Partner;
• Agent - модуль, поддерживающий работу в сети.
Процесс тестирования состоит из следующих этапов:
• создание плана тестирования;
• связывание плана с тестами;
• пометка и выполнение тестов;
• получение отчетов о тестировании и управление результатами.
Создание тестового плана в QA Planner включает в себя составление схемы тестовых требований и выделение уровней детализации. Для этого необходимо определить все, что должно быть протестировано, подготовить функциональную декомпозицию приложения, оценить, сколько тестов необходимо для каждой функции и характеристики, определить, сколько из них будет реализовано в зависимости от доступных ресурсов и времени. Эта информация используется для создания схемы тестовых требований.
Для связывания плана с тестами необходимо создать управляющие предложения (скрипты) на специальном языке 4Test и тесты, которые выполняют требования плана, и связать компоненты любым способом. Для избежания перегруженности тестов используют управление тестовыми данными.
При выполнении плана результаты записываются в формате, похожем на план. Все результаты связаны с планом. Есть возможность просмотреть или скрыть общую информацию о выполнении, слить файлы результатов, разметить неудавшиеся тесты, сравнить результаты предыдущего выполнения тестов, выполнить или отменить отчет.
Классификация по категориям CASE-инструментов определяет степень интегрированности:
• отдельные локальные средства, решающие небольшие автономные задачи,
• набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла
• полностью интегрированных средств, охватывающий весь жизненный цикл информационной системы и связанных общим репозиторием
Типичными CASE-инструментами являются:
• инструменты управления конфигурацией ( поддержкой технической и административной деятельностью, связанной с управлением продукцией и требованиями к взаимосвязанным функциональным и физическим характеристикам продукции на всех стадиях ее ЖЦ )
• инструменты моделирования данных
• инструменты анализа и проектирования
• инструменты преобразования моделей
• инструменты редактирования программного кода
• инструменты рефакторинга кода
• генераторы кода
Доработано: Якубова Вероника