
- •Донецкий национальный технический университет
- •1. Источники требований:
- •1) Описание бизнес-процесса предприятия
- •2) Описания моделей деятельности успешных компаний отрасли
- •3. Нижний уровень - функциональный (functional requirements).
- •3.1. Функциональные требования
- •3.1.1. Требования на поведение
- •3.1.2. Системные требования и требования к программному обеспечению
- •3.1.3. Характеристика продукта
- •4. Нефункциональные требования
- •Глава 1. Разработка вербальной модели для методики проектирования в заданной предметной области.
2) Описания моделей деятельности успешных компаний отрасли
Должно включать описания:
1) Лучших фирм (две);
2) Лучших САПР (три - четыре);
Необходимо:
- сделать анализ достоинств и недостатков;
- перспективную путь (средства и методы построения) новых, более эффективных САПР.
3) Документ "Требования совладельцев".
Около 60 требований, перечисляющих требования следующих уровней.
Уровни требований
Обычно выделяют три уровня требований.
1. Верхний уровень - уровень бизнес-требований (business requirements).
Примеры бизнес-требования: система должна сократить срок оборачиваемости обрабатываемых на предприятии заказов в три раза.
Бизнес-требования обычно формулируются топ-менеджерами, либо акционерами предприятия.
Сформулировать 2-3 требования.
2. Средний уровень - уровень требований пользователей (user requirements).
Пример требования пользователя: система должна представлять диалоговые средства для ввода исчерпывающей информации о заказе, последующей фиксации информации в базе данных и маршрутизации информации о заказе к сотруднику, отвечающему за его планирование и исполнение.
Требования пользователей часто бывают плохо структурированными, дублирующимися, противоречивыми. Поэтому для создания системы важен третий уровень, в котором осуществляется формализация требований.
Сформулировать 5-7 требований.
3. Нижний уровень - функциональный (functional requirements).
Пример функциональных требований (или просто функций) по работе с электронным заказом: заказ может быть создан, отредактирован, удален и перемещен с участка на участок.
Включают: функциональные и нефункциональные требования.
3.1. Функциональные требования
Включают: требования на поведение (собственно функциональные требования), системные требования, характеристику продукта.
3.1.1. Требования на поведение
Регламентируют функционирование или поведение системы (behavioral requirements) и отвечают на вопрос "что должна делать система" в тех или иных ситуациях. Функциональные требования определяют для Разработчика цели, задачи и сервисы, предоставляемые системой Заказчику.
Функциональные требования записываются:
- как правило, при посредстве предписывающих правил: "система должна позволять кладовщику формировать приходные и расходные накладные".
- другим способом являются так называемые варианты использования (uses cases).
Это - основной, определяющий вид требований.
Сформулировать 5-7 требований.
3.1.2. Системные требования и требования к программному обеспечению
Системные требования (system requirements) являются подмножеством функциональных требований к ИС.
Пример таких требований:
- тактовая частота процессора,
- объем памяти,
- требования к выбору операционной системы и т.д.
Сформулировать 5-7 требований.
3.1.3. Характеристика продукта
Это подмножество важнейших логически связанных функциональных требований, которые обеспечивают возможности пользователя и удовлетворяют бизнес-цели.
4. Нефункциональные требования
Регламентируют внутренние и внешние условия или атрибуты функционирования системы.
Основные группы нефункциональных требований:
Внешние интерфейсы (External Interfaces),
Атрибуты качества (Quality Attributes),
Ограничения (Constraints).
Детальнее:
1) Внешние интерфейсы. Среди внешних интерфейсов наиболее важным является интерфейс пользователя (User Interface, UI). Кроме того, выделяются интерфейсы с внешними устройствами (аппаратные интерфейсы), программные интерфейсы и интерфейсы передачи информации (коммуникационные интерфейсы).
Сформулировать 3-4 требования.
2) Основные атрибуты качества:
Применимость,
Надежность,
Производительность,
Эксплуатационная пригодность,
Сформулировать по одному требованию для каждого атрибута качества.
3) Ограничения - формулировки условий, модифицирующих требования или наборы требований, сужая выбор возможных решений по их реализации.
Например: Выбор платформы реализации и/или развертывания (протоколы, серверы приложений, баз данных, ...), которые, в свою очередь, могут относиться, например, к внешним интерфейсам.
Сформулировать 3-4 требования.
Отчет:
1) Неформально т.е. словесно в свободном формате прописанные требования в соответствии с классификацией источников и стратегий выявления требований, включая:
- документы с описанием бизнес-процессов предприятии;
описания моделей деятельности успешных компаний отрасли.
- документ "Требования совладельцев";
Лаб. 4
Разработка средствами диаграмм IDEF0 моделей бизнес-процессов, имеющихся в вербальной модели для заданной предметной области.
В среде пакета BpWin (AllFusion Process Modeler) построить модели процессов:
1) Статическую модель объекта проектирования:
2) Статическую модель проектной организации.
Источник информации: вербальная модель.
Требования:
- не менее трех уровней (начальный блок, его структура т.е. подблоки, структура подблоков);
- не менее трех подблоков для каждого разбитого блока.
Отчет:
- все диаграммы.
Порядок создания моделей.
Нажав правую кнопку на начальном блоке в разделе «font» выбрать русский язык и применить его ко всем блокам.
Нажав правую кнопку и выбрав «name», задать имя блока.
Аналогично сделать для всех стрелочек (связей).
Рис. Пример установки русского языка для всех стрелочек.
Если нужно, что бы надписи на стрелочках были чуть в стороне, необходимо воспользоваться «молнией» на меню пиктограмм. Это позволит перетаскивать надпись с «молнией».
Примечание. В блоке всегда:
- сверху – входная управляющая информация (ГОСТ, приказы правила, методики и т.д.);
- слева – входные данные (сырье, материалы, требования ТЗ, т.е. мощность и т.д.);
- снизу – вход как механизм, т.е. материальные средства достижения цели (проектировщики, инженеры, рабочие, станки, базы данных, компутеры, лопаты и т.д.);
- справа – выход, т.е. результат работы (состав чертежей, спецификации к ним, структура сети, программы управления и т.д.).
Встав на имя блока в верхнем левом углу экрана, и нажав контекстную кнопку, выберем команду «decomnose». Это позволит разбить исходный блок на нужное число подблоков.
Рис. Декомпозиция блока.
Выбрав стрелочку (связь) на пиктографическом меню получим курсор в виде «крестика». Постараемся попасть на кончик входной стрелочки. Это позволит отправить ее на нужный подблок.
Рис. Стыковка подблоков и входных стрелочек.
Выбрать форму блоков, исходя из их типа (работа с базой данных, работа с проектировщиком и т.д.)
Рис. Меню выбора формы блоков.
Соответственно раскрасить блоки.
Рис. Меню раскраски блоков.
Лаб. 5.
Разработка алгоритмической модели управления объектом средствами диаграмм типа IDEF3 для CALS-технологии заданной предметной области.
Пользуясь средствами диаграмм типа IDEF3 описать алгоритмическую модель для заданной предметной области, включая:
Динамическую модель объекта проектирования;
Динамическую модель процесса проектирования:
Использовать:
- все типы блоков-перекрестков;
- не менее трех уровней иерархии, применяя на каждом уровне не менее трех блоков (перекрестки не учитываются).
Отчет по Лабе включает:
Не менее 5-ти диаграмм для управление процессом
Требование: Использовать тип PFDD диаграммы.
Срок: следующий раз.
Рисунок 1. Пример PFDD диаграммы.
Рисунок 1. Пример PFDD диаграммы.
Типы перекрестков:
|
Наименование |
Смысл в случае слияния стрелок |
Смысл в случае разветвления стрелок |
|
Асинхронное И.
|
Все предшествующие процессы должны быть завершены |
Все следующие процессы должны быть запущены |
|
Синхронное И.
|
Все предшествующие процессы завершены одновременно |
Все следующие процессы запускаются одновременно |
|
Асинхронное ИЛИ.
|
Один или несколько предшествующих процессов должны быть завершены |
Один или несколько следующих процессов должны быть запущены |
|
Синхронное ИЛИ.
|
Один или несколько предшествующих процессов завершаются одновременно |
Один или несколько следующих процессов запускаются одновременно |
|
Исключающее ИЛИ.
|
Только один предшествующий процесс завершен |
Только один следующий процесс запускается |
Приложение 1.
Типичные функции программ различных назначений (САПР, АСУ ТП, ОС)
САПР
-----------------------
Типичный САПР включает:
- систему ведения диалога;
- систему синтеза изделий;
- базу данных;
- графический редактор;
- систему моделирования;
- систему синтеза документации;
- систему управления натурными экспериментами и документирования их результатов.
Типичный САПР имеет функции:
1) В диалоге с проектировщиком вводит техническое задание на изделие, выясняя параметры требуемого изделия,
2) По ТЗ строит модель изделия, т.е.:
- определяет структуру изделия, обращаясь к базе данных компонент;
- определяет функции блоков всех уровней иерархии;
- определяет размерностные и функциональные параметры компонент;
- строит трехмерную модель изделия;
3) С помощью системы моделирования позволяет выполнить модельное исследование изделия, проверяя его на качество;
4) С помощью графического редактора позволяет отредактировать полученное изделие, исправляя выявленные недостатки;
5) На выходе формирует:
- набор чертежей изделия (виды боковые, фронтальные, трехмерные каркасные и т.д.);
- спецификации к чертежам, где указывается состав элементов изделия, их тип и количество;
- сметы к спецификациям, где дается стоимость как отдельных компонент, так узлов и изделия в целом;
6) Может предполагать изготовление экспериментального изделия и его натурное испытание с последующим возвратом на уровень редактирования изделия. Результаты исследований должны быть задокументированы. Например, возможны исследования на:
- прочность;
- функциональность;
- скорость;
- эргономичность и т.д.
Конкретный САПР отличается:
- формой ведения диалога ввода ТЗ;
- числом этапов синтеза изделия, связанных с его структурой и функциями;
- структурой и функциональными возможностями базы данных;
- методам модельного исследования изделия;
- методами построения графического редактора;
- составом документации на готовое изделие;
- видами требуемых натурных испытаний, составом измеряемых характеристик и способами их документирования;
АСУ ТП
-------------------------------------
Типичная система управления производством – автоматизированная система управления технологическим процессом (АСУ ТП) производства требуемых изделий включает:
- подсистема управления автоматизированными производственными роботами;
- подсистема управления автоматизированным складом комплектующих, необходимых для производства изделия;
- подсистема управления автоматизированным складом готовой продукции, куда поступают готовые изделия;
- подсистема оперативной диспетчеризации, обеспечивающая текущий контроль производства и его автоматическую корректировку в случае различных сбоев (поломка оборудования, нехватка комплектующих, переполнение склада готовой продукции, пожар и т.д.);
- подсистема визуализации состояния процесса производства;
- подсистема ведения диалога с оперативным персоналом для случаев, если необходимо его вмешательство;
Входом системы являются:
- чертежи, спецификации и сметы, полученные на этапе проектирования изделия;
- программы для станков с ЧПУ, роботов и автоматизированных станков;
Конкретный АСУ ТП отличается:
1) Структурой автоматизированной линии производства, включая тип и функции оборудования:
- роботов-манипуляторов,
- автоматизированных станков (токарных, фрезерных, расточных и т.д.),
- роботов-транспортеров;
2) Структурой автоматизированных складов комплектующих и готовой продукции, включая:
- состав и емкость отдельных хранилищ;
3) Структурой потоков комплектующих, полуфабрикатов и готовой продукции, объединяющих автоматизированную линию и склады;
4) Структурой системы контроля за производством, включая:
- составом и типов датчиков, сигнализирующих о состоянии производства;
- составом и типом камер, необходимых для визуального контроля производства;
5) Структурой и составом вычислительной информационной сети, включая:
- состав вычислительных контроллеров, необходимых для управления производства и контроля его состояния, включая и центральный процессор;
- составом маршрутизаторов, т.е. сетевых контроллеров;
- составом линий связи (кабелей, коннекторов и т.д.) между вычислителями.
6) Функциями и составом программного обеспечения, необходимого для управления:
- оборудованием линии, выполняющем конкретные производственные операции;
- работы складов;
- вычислительных контроллеров управления линией;
- сетевых контроллеров;
- выполнения задач диспетчеризации на центральном процессоре;
- ведения диалога с персоналом;
- визуализации состояния производства;
Программное обеспечение конкретного АСУ ТП отличается:
- формой ведения диалога с диспетчером;
- числом этапов производства изделия, связанных с его структурой и функциями;
- структурой и функциональными возможностями базы данных;
- методам контроля производства изделия;
- методами построения системы визуализации процесса производства;
- составом выходных параметров контроля производства;
- видами требуемых натурных испытаний, составом измеряемых характеристик и способами их документирования;
ОС:
------------------------------------------
ОС является вариантом АСУ ТП с подобными же функциями и структурой.
Типичная система управления функционированием готового, произведенного изделия в процессе его эксплуатации отличается:
1) Структурой оборудования, которым необходимо управлять, набором их функций, составом возможных команд и их параметров, набором драйверов;
2) Заданием цели (целей) (движения, оптимального состояния объекта);
3) Алгоритмами достижения целей;
4) Средствами визуализации процесса достижения цели и средствами сигнализации о критических состояниях;
5) Средствами оперативного вмешательства персонала, типами ведения диалога;
6) Управляющей программой, обеспечивающей:
- достижение целей;
- возможность контроля;
- возможность оперативного вмешательства.
Приложение 2. Структура пояснительной записки по курсовой работе.
Тема курсовой работы: Разработка модели знаний методики проектирования объектов заданной предметной области.
Пример:
Разработка средствами языков системного проектирования модели знаний для методики проектирования гидростанций.
Введение.
Цель курсовой работы:
- пользуясь языками системного проектирования;
- разработать модель знаний методики проектирования объектов заданной предметной области;
- обеспечить тем самым возможность построения соответствующего интеллектуального САПР в среде специализированных инструментальных оболочек для создания экспертных систем;
Методика проектирования включает:
- модель объекта проектирования (динамическую и статическую);
- модель собственно методики проектирования объектов заданной предметной области как комплекс проектных процедур и критериев проектирования (требований).