
- •Понятие иэс. Технология проектирования эис: понятие, классификация, требования.
- •Методы и средства проектирования эис.
- •Жизненный цикл процесса проектирования эис. Основные модели.
- •4. Каноническое проектирование эис. Состав стадий и этапов канонического проектирования эис.
- •Состав и содержание работ на предпроектной стадии канонического проектирования эис.
- •Этапы предпроектной стадии.
- •6Методы обследования и методы сбора материалов обследования на предпроектной стадии канонического проектирования эис.
- •7. Формализация материалов обследования на предпроектной стадии канонического проектирования эис. Состав и формы документов формализации материалов обследования.
- •Анализ материалов обследования на предпроектной стадии канонического проектирования эис. Состав и содержание работ.
- •Цель, параметры и основные компоненты технико-экономического обоснования проекта эис.
- •Цель и основные компоненты документа «Техническое задание на создание автоматизированной эис».
- •Состав и содержание работ на стадии технического проектирования эис.
- •Состав и содержание работ на стадии рабочего проектирования эис.
- •Состав и содержание работ на стадиях внедрения и сопровождения проекта эис.
- •Понятия и основные системы кодирования экономической информации. Классификация систем кодирования.
- •Проектирование классификаторов технико-экономической документации эис. Основные типы классификации.
- •Единая система классификации и кодирования. Функции, структура.
- •Состав и содержание операций проектирования классификаторов эис.
- •Типовое проектирование эис. Параметрически-ориентированное проектирование эис.
- •Типовое проектирование эис. Модельно-ориентированное проектирование эис.
- •Основное понятие и классификация case-технологий. Методология rad.
- •Функционально-ориентированное проектирование эис. Диаграммы idef0, dfd, idef3
- •Объектно-ориентированное проектирование эис. Нотация uml
- •Объектно-ориентированное проектирование эис. Метод comet. Модель требований. Моделирование прецедентов.
- •Объектно-ориентированное проектирование эис. Метод comet. Аналитическая модель. Статическое моделирование.
- •Объектно-ориентированное проектирование эис. Метод comet. Аналитическая модель. Разбиение на объекты
- •Объектно-ориентированное проектирование эис. Метод comet. Аналитическая модель. Конечные автоматы и диаграммы состояний.
- •1 Конечные автоматы
- •2 События и состояния
- •2.1 События
- •2.2 Состояния
- •5 Действия
- •5.1 Деятельности
- •6Иерархические диаграммы состояний
- •6.1 Иерархическая декомпозиция состояний
- •6.2 Агрегирование переходов состояний
- •7 Параллельные диаграммы состояний
- •Объектно-ориентированное проектирование эис. Метод comet. Аналитическая модель. Динамическое моделирование
- •1 Моделирование взаимодействий объектов
- •1.1 Диаграммы кооперации
- •1.2Диаграммы последовательности
- •1.3 Сравнение диаграмм последовательности и кооперации
- •1.4 Прецеденты и сценарии
- •2 Сообщения-метки на диаграммах взаимодействия
- •2.1 Порядковая нумерация сообщений
- •Объектно-ориентированное проектирование эис. Метод comet. Проектная модель. Разбиение на задачи.
Объектно-ориентированное проектирование эис. Метод comet. Проектная модель. Разбиение на задачи.
Причины разбиения задачи
Необходимость разбиения задачи, которую предстоит решать автоматизированным способом, хорошо обосновывается с помощью одного из принципов, сформулированных еще Декартом.
Фактически это принцип «модульности» очень важный для многих областей деятельности, и в частности для автоматизации управления, и очень трудный для его практического применения, взять хотя бы проблему компромисса между разбиениями задачи на большее число микромодулей, требующих многочисленных сопряжений, и на малое количество макромодулей, которые трудно разработать и которыми трудно пользоваться и управлять. Существуют основные причины, которыми обосновывают разбиение задачи:
- Простота реализации задачи. Разбиение задачи на функциональные блоки позволяет осуществить разделение труда при ее алгоритмизации. Действительно, в самом начале этапа алгоритмического представления задачи разработка разных функциональных блоков может быть распределена между различными группами программистов-разработчиков.
- Простота проведения испытаний и отладки программ задачи. Прежде чем планировать испытания и отладку задачи в целом, будут проводиться испытания и отладка программ задачи на уровне функциональных блоков.
- Простота сопровождения задачи. Когда задача уже будет эксплуатироваться в реальных условиях, пользователи будут высказывать пожелания о ее совершенствовании. Если задача структурирована в виде функциональных блоков, то достаточно рассмотреть лишь те из них, которые имеют отношение к предлагаемым изменениям.
- Простота эксплуатации программ задачи. Для персонала, отвечающего за эксплуатацию программ задачи, гораздо проще организовать выполнение программ одного функционального блока в одни и те же сроки, чем некоторых программ одного функционального блока к определенному сроку, а затем других программ того же функционального блока к другому сроку.
Основные критерии разбиения задачи на функциональные блоки многочисленны, но часто определяются характером самой рассматриваемой задачи. Однако всегда необходимо иметь в виду следующие критерии:
"Размер" задачи;
Территориальную распределенность процедур обработки;
Число сопряжений между функциональными блоками;
Использование пакетов прикладных программ (готовых программных продуктов).
Размер задачи. Размер задачи можно оценивать с точки зрения ее «конструкции» и ее эксплуатации.
С точки зрения эксплуатации задача считается «большой», если велик объем обрабатываемых при ее решении данных.
В обоих случаях, и в особенности в первом, рекомендуется применять следующий принцип: чем крупнее задача, тем целесообразнее разбить ее на большее число функциональных блоков.
Территориальная распределенность процедур обработки. Распределенными считаются такие задачи, в которых процедуры обработки вьшолняются в разных друг от друга местах. Здесь создаются функциональные блоки, обеспечивающие выполнение функций по поддержанию связей между территориально разнесенными пунктами.
Способы разбиения задачи
К сожалению, не существует ни правила, ни универсального метода, которые позволили бы целенаправленно действовать при разбиении задачи. Можно сформулировать одно основное правило: «Не существует в общем случае разбиения, которое было бы наилучшим, но существует несколько разбиений, которые могут быть вполне обоснованными и считаться такими же приемлемыми, как и другие».
Различают разбиения 2-х классических типов:
разбиения по функциям задачи управления;
разбиение по основным функциям обработки данных при решении задачи (контроль, расчет, ведение БД, отчеты, справки и т.д.)
Разбиение по функциям задач управления.
Задача реализуется с целью выполнения некоторого числа функций управление. Цель данного способа разбиения заключается в назначении функционального блока каждой крупной функции управления, выполняемой при решении задачи.
Основные преимущества разбиения задачи по функциям управления:
- Получаемые функциональные схемы понятны пользователям. Они могут участвовать в их разработке, вносить замечания, коррективы;
Когда в рамках задачи должны выполняться новые функции управления, то, как правило, будет достаточно создать для них ФБ и подключить к уже являющимся блокам.
Основные недостатки разбиения задачи по функциям управления. В данном варианте разбиение функции обработки информации реализуются в большом числе функциональных блоков, чем и обусловлены следующие недостатки:
Плохое соответствие такой структуры возможностям использования некоторых специализированных пакетов прикладных программ (функций);
Плохое соответствие такой структуры возможностям использования специализированных технических средств для выполнения некоторых видов работ.
Разбиение задачи по основным функциям обработки данных
Основные преимущества: к любой задаче - одинаковый подход, одинаковый сценарий работы. Поэтому специалисты, сопровождающие задачу, будут ее лучше понимать. Недостатки;
- менее понятна пользователям;
- в дальнейшем требуется разбиение некоторых функциональных блоков на такое число программных блоков, сколько функций управления должны выполнять эти функциональные блоки.