Подсистема ANALYZER
ANALYZER является основной подсистемой Prokit*WORKBENCH, которая помогает разработчику программного обеспечения собрать и запомнить системные требования, используя схемы потоков данных и поддерживающий проект репозиторий.
Систему ANALYZER используют:
аналитик приложения - для проектирования
директор проекта - для составления долгосрочного системного плана.
В процессе долгосрочного системного планирования система ANALYZER используется для описания экономической функциональной модели предприятия.
В процессе системного проектирования система ANALYZER используется при анализе:
для того, чтобы собрать и занести в репозиторий требования для определенной прикладной задачи
для разработки разной степени детализации схем потоков данных (от абстрактных логических моделей до очень подробных моделей “физического” уровня).
В процессе сопровождения системы система ANALYZER используется:
для определения последствий доработок/изменений
для документирования текущей системы (по необходимости).
Система ANALYZER используется для построения схем потоков данных.
Внешняя сущность:
- определяет границы системы
- служит для представления источника и/или получателя информации.
Внешний объект
APP
Претендент
Процесс:
- осуществляет преобразование входных данных в выходные
- служит для описания функции
- может быть детализирован (раскрыт) в виде другой схемы потоков данных.
Хранилище данных служит для представления места, где должны содержаться данные:
- между процессами (в интервалах между обработкой)
- для отражения свойств внешнего объекта
- потому что так сложилось.
Поток данных:
- служит для представления перемещения данных при помощи определенной конфигурации символов (диаграммы)
- изображается с одним источником и одним получателем.
Информация о диаграмме потоков данных помещается в репозиторий.
Правильность работы в посистеме ANALYZER проверяется посредством отчетов:
Листинги содержания:
- используются для контроля содержания объектов (например, содержания накопителя данных)
- используются для уточнения, объединения и сокращения представления данных.
Обзорные отчеты:
- используются для оценки полноты и корректности информации
- используется, как блокнот.
Анализ согласованности по горизонтали:
- используется для контроля входов и выходов накопителей данных и процессов по информации, имеющейся в репозитории.
Анализ согласованности по вертикали:
- используется для согласования уровней схемы потоков данных
- гарантирует, что элементы данных не потерялись при детализации к новой диаграмме, и что новые данные, введенные на следующих уровнях детализации, отражены также на верхних уровнях.
Взаимосвязи с другими подсистемами
От ANALYZER к PROTOTYPER
Можно установить соответствие между схемой потоков данных и реальными экранами, отчетами и формами, привязав потоки данных к образам.
Поможет аналитику проверить корректность требований пользователя и понять, как они будут взаимодействовать с системой.
От ANALYZER к DATA MODELLER
Можно обеспечить соответствие хранилищ данных (на схеме потоков данных) и сущностей данных (на ER - модели)
Позволит исполнителям двух ролей (аналитику данных и аналитику приложений) вместе участвовать в разработке и свести два представления данных воедино.
От ANALYZER к DESIGNER
Можно установить соответствие между процессами (на схеме потоков данных) и модулями на структурной схеме, чтобы гарантировать, что всем процессам соответствует их программная реализация.
Подсистема REPOSITORY
Назначение репозитория - полнота информации. Именно в репозитории накапливается вся информация о системе. Репозиторий системы Prokit*WORKBENCH объектно-ориентированный, полностью интегрированный, изменения/удаления являются глобальными, доступ к объектам и их модификации контролируются. Имеется возможность использования алиасов (вторых имен).
Элемент данных - минимальная единица данных, имеющая значение для того чтобы проект был документированю
Структура данных - один или более элементов данных и/или структур данных, связаных логически.
Объект - это нечто, имеющее четко определенные границы.
Объект, его содержание, данные о нем и отношения с другими объектами хранятся в объектно-ориентированном репозитории.
Выводы:
Объектно-ориентированный репозиторий используется таким образом, что как только получены новые проектные данные, связанные с объектом, они могут быть непосредственно описаны и сохранены с соответствующими взаимосвязями в реляционном виде.
Объект имеет хорошо определенные рамки и является характерной категорией для сущностей (связанных с ним данных), которые требуется хранить в системе.
Схемы являются графическим представлением информации хранимой в подсистеме REPOSITORY.
Символ на схеме можно считать отображением объекта, но он не является самим объектом.
Элементы данных, их структуры и типы, а также понятия, включенные в глоссарий, сохраняются в подсистеме REPOSITORY системы Prokit*WORKBENCH один раз и используются на протяжениии всего жизненного цикла.
Каждый объект, хранящийся в подсистеме REPOSITORY может быть расширен для включения атрибутов (полей), определенных пользователем, и одного текстового блока.
Следующие виды схем непосредственно связаны с подсистемой EPOSITORY (интегрированы с подсистемой REPOSITORY):
- схемы потоков данных
- ER-модели
- структурные схемы
- образы прототипа.
Подсистема EXPORT/IMPORT
Подсистема IMPORT используется для получения проектных данных из внешнего источника.
Откуда импорт? Из версии в версию внутри проекта:
- на одной рабочей станции;
- с другой рабочей станции.
Из проекта в проект:
- на одной рабочей станции;
- с другой рабочей станции.
Из другой компьютерной Среды.
Из общего словаря данных.
Из некоторого другого источника, который может быть
преобразован в формат ASCII.
Для чего? Для:
- многократного использования информации;
- поддержки управления данными;
- обеспечения возможности коллективной разработки
системы без использования сетевой версиии системы
Prokit*WORKBENCH.
Подсистема EXPORT используется для копирования проектных данных во внешний файл DOS предопределенного формата.
Куда экспорт? Из версии в версию внутри проекта:
- на одной рабочей станции;
- на другую рабочую станцию.
Из проекта в проект:
- на одной рабочей станции;
- на другую рабочую станцию.
В другую компьютерную среду.
Во внешний словарь данных.
В некоторый другой источник, который может быть
преобразован в формат ASCII.
Для чего? Для:
- многократного использования информации;
- поддержки управления данными;
- обеспечения возможности коллективной разработки
системы без использования сетевой версиии системы
Prokit*WORKBENCH.
Prokit*WORKBENCH поддерживает 3 вида экспорта:
1. Synchronization (синхронизация)
- используется внутри того же проекта при коллективной
разработке системы без использования сетевой версии
Prokit*WORKBENCH
2. Check Out (полный расчет)
- используется внутри того же проекта при коллективной
разработке системы без использования сетевой сетевой
версии Prokit*WORKBENCH
3. Inter Project (между-проектный)
- используется при обмене данными проектами.
Кроме того, импорт/экспорт текстов может быть осуществлен между текстовыми процессорами и репозиторием системы Prokit*WORKBENCH.
Подсистема DATA MODELER
DATA MODELER - это одна из главных подсистем Prokit*WORKBENCH, которая помогает программисту в сборе и документировании требований к данным прикладной системы и к способам их связей между собой.
Для чего и кто пользуется подсистемой?
Для создания модели действующего предприятия:
Технический консультант по планированию.
Для создания проектной модели:
Аналитик данных (отвечает за интерпретацию и определение
необходимой информации)
Администратор данных (отвечает за общее планирование данных,
контроль и руководство их организацией)
Администратор базы данных (отвечает за проектирование/
управление базой данных).
Используются следующие схемы: Бахмана, Чена и E/R.
Для проверки работы подсистемы DATA MODELER используются отчеты.
Например,
Отчет о составе объектов - используется для проверки содержания объектов,
например, список сущностей данных
- используется при уточнении, объединении и
сокращении атрибутов сущности данных
Отчет о полноте данных - используется при контроле полноты и правильности
информации
- используется как форма для заполнения
недостающими данными
Печатная копия схемы - показывает графически схемы сущности данных,
атрибуты, связи и принятые ограничения
- используется проектировщиками базы данных в
процессе проектирования физической базы
данных/файла
Отчет о синхронизации - используется для поддержки процесса
храниилищ данных и синхронизации пометкой несоответсвия между
сущности данных хранилищем данных и сущностью данных, которые
должны быть синхронизированы.
Стратегическая модель данных
Базовая модель
Модель с ключами
 |
Модель с атрибутами
 |
Полная модель
Схемы потоков данных и ER - модели могут создаваться паралельно.
Это позволяет двум разработчикам с разными проектными ролями (каждый со своей концепцией и базой знаний) прийти к единой системе представлений.
Подсистема PROTOTYPER
Подсистема PROTOTYPER - это наиболее важная подсистема системы Prokit*WORKBENCH, которая позволяет разработчику системы выяснить требования к системе, описать и промоделировать систему до того, как она действительно будет разработана.
Подсистема PROTOTYPER предоставляет для разработки:
- меню
- экраны
- отчеты
- формы
, а также возможности выполнения прототипа.
Подсистема PROTOTYPER может быть использована:
- в качестве показа результатов;
- для выявления истинных потребностей пользователя;
- для исследования режима функционирования системы;
- для изготовления системы.
Кто может использовать подсистему PROTOTYPER?
Аналитик прикладных программ (для определения требований пользователя и проверки диаграмм потоков данных).
Конечный пользователь (для понимания взаимодействия с предлагаемой системой).
Специалист по человеко-машинному интерфейсу (для определения интерфейсов пользователя).
Проектировщик (для окончательного специфицирования проекта).
Разработчик (для передачи информации, пригодной для дальнейшего использования, в генераторы кода или генераторы прикладных программ).
Цель прототипирования - промоделировать работу реальной системы через режим ВЫПОЛНЕНИЕ.
режим выполнения требует четыре компоненты:
1. Образ
2. Спецификация состояний
3. Описание клавиатуры
4. Параметры настройки (атрибутов экрана).
Образ создается с помощью рисовальщика образов.
Четыре типа образов:
Меню
Экран
Отчет
Форма.
Образ может быть сильно или слабо связан с репозиторием:
- образ может быть связан с потоком данных
- образ может использовать элементы данных из репозитория
- образ может использовать локальные переменные.
Для выполнения прототипа должен быть создан файл с описанием клавиатуры.
Примеры функций клавиш:
Табуляция
Перемещение курсора
Доступ к подсказке экрана
Доступ к подсказке к полю
Удалить до конца строки.
Для выполнения прототипа должен быть создан файл с описанием параметров настройки (атрибутов экрана) для цветного дисплея.
Примеры атрибутов экрана:
Цвет фона
Выделенная строка (да/нет)
Цвет/интенсивность защищенных полей
Цвет/интенсивность разрешенных полей
Цвет/интенсивность графики (линий)
Цвет/интенсивность меток.
Просмотр (по кадровый) системы в определенный момент времени для определенной перспективы состоит из пяти основных компонент:
- образ
- запрос-приглашение
- директивы препроцессора
- правила комплексного редактирования
- переходы в другие состояния.
Возможность выполнения прототипа позволяет пользователю понять, как работать с системой. Для выполнения прототипа необходимо задать следующие компоненты:
- стартовый образ(образ связанный с состоянием)
- описание клавиатуры
- параметры настройки.
Существует три типа имитации работы системы:
1. Предопределенный - ни какие правила не контролируются во время выполнения
2. Нормальный
- правила проверяются во время выполнения
- ошибки, соответствующие правилам, контролируются
3. С завершение выполнения
- окончание работы по <Ctrl+Break>
- или используется состояние ‘QUIT’.
Имеется интерфейс в другие системы, в частности, в систему
PRO IV.
Выводы:
Прототип системы создается из образов (меню, экраны, отчеты и формы), разработанных в подсистеме PROTOTYPER, и в определенном порядке имитирует работу реальной системы.
Образ создается в диалоговом режиме, что позволяет системному инженеру интерактивно изменять содержимое образа и атрибуты экрана в соответствии с запросами пользователя.
Спецификация состояний дополняет образ реалистическими свойствами и устанавливает условия перехода из одного состояния в другие.
Для того, чтобы выполнить прототип, пользователь выбирает начальное состояние, файл с описанием клавиатуры и файл с параметрами настройки дисплея.
Рисовальщик образов с легкостью прокладывает мостик между логическими картинками (видами) пользователя (потоки данных) и их физическими представлениями (меню, экраны, отчеты и формы).
Оценки системы в процессе прототипирования оказывают помощь в поверке диаграмм потоков данных.
Окончательные результаты прототипирования могут быть переданы для использования через интерфейс в системы: TELON, PRO-IV, TRANSFORM.
Подсистема DESIGNER
Подсистема DESIGNER является одной из подсистем системы Prokit*WORKBENCH, которая помогает проектировщику программного обеспечения преобразовать результаты анализа (где получено множество функциональных требований к системе) в проектную спецификацию программных компонентов.
Для того, чтобы справиться с присущей большим системам сложностью, применяется разбиение задачи на управляемые компоненты:
Подсистемы (Subsystems)
Единицы проекта (Design Units).
Для обеспечения лучшего взаимопонимания разработчиков и преемственности проектных решений за счет тспользования:
Единиц проекта
Схем потоков данных второго уровня
Структурных схем.
Для получения спецификаций результатов, необходимых для разработки:
Баз данных/Файлов
Определений модулей
Планов тестирования
Руководств пользователя.
Пример
Проект реализации компании, разрабатывающей программные средства
1.Постановка задачи
Компания “Software Company” разрабатывала коммерческие программные средства для сферы финансовой деятельности в течение последних 6 лет. За этот период компания создала много новых программных средств и имеет успехи в их сбыте. Компания имеет годовой прирост рабочей силы в 50%. В будущем ожидается годовой рост доходов на 40% и прирост рабочей силы, оцениваемый цифрой 25%. Это будет происходить по мере того как рост компании стабилизируется и будут повышаться требования, предъявляемые к принимаемым на работу новым сотрудникам. Этот прогноз накладывает повышенные требования к деятельности компаниии и, в особенности, к деятельности отдела кадров.
Как следует из долгосрочного плана развития компании, подготовленного исполнительным комитетом, автоматизация отдела кадров является ключевым фактором достижения успеха в решении задач, стоящих перед компанией. Перед компанией в частности поставлены следующие стратегические управленческие задачи:
1) снизить в будущем году на 20% затраты труда работников отдела кадров за счет автоматизации процедур ввода, проверки и учета данных о кандидатах на прием и принятых сотрудниках;
2) в последующие 6 месяцев увеличить на 15% число сотрудников принятых из предварительно отобранных кандидатов за счет повышения эффективности подбора кадров и оперативности подготовки необходимых документов.
2. Определение основных функций информационной системы
После нескольких недель рассмотрение проблем, имеющихся в отделе кадров, и оценки возможных путей достижения поставленных целей, руководство отдела кадров сформировало следующие требования к информационной системе:
- сбор и хранение приемных документов;
- обеспечение проверки соответствия кандидатов требованиям к должностям;
- поддержка процедуры приема кандидата на работу в качестве сотрудника;
- подготовка уведомления кандидата о приеме;
- передача сведений о приеме в отдел труда и зарплаты;
- формирование необходимых для работы отчетов.
3. Количественные требования и ограничения
Информационная система должна удовлетворять следующим количественным требованиям и ограничениям:
А. ежедневно может быть принято до 30 заявлений о приеме на работу (требования к формату и содержанию приемных документов будут оставаться неизменными)
В. в начальный момент имеются описания 43 должностей. Ожидается увеличения числа должностей на 10 % в год
С. в начальный момент в компаниичислится 570 сотрудников. Ожидается прирост числа сотрудников на 25 % в год
D. в начальный момент имеется около 70 кандидатов на прием. 10 % из их числа была предложена работа, но от них еще не поступили окончательные подтверждения о согласии выйти на работу
Е. в среднем поступает 28 заявлений о приеме на работу в неделю. Ожидается, что число заявок не будет превышать 50 в неделю
F. максимально только 10 кандидатов могут рассматриваться к категории “высоко квалифицированный работник” для одной открытой вакансии
G. политика управления предписывает, что открытая вакансия должна быть заполнена в течение трех недель. В противном случае она должна быть открыта вновь
H. кандидатура не должна рассматриваться более 60 дней: после этого срока заявление на прием отклоняется
I. компания имеет текучесть кадров 15% в год.