ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 20.05.2024
Просмотров: 48
Скачиваний: 0
|
49. Техническое проектирование автоматизированной информационной системы Технический проект – это комплект проектных документов на АИС, разрабатываемых на этапе технического проектирования, утвержденный в установленном порядке, содержащий основные проектные решения по системе в целом, ее функциям и всем видам обеспечения и достаточный для разработки рабочей документации на АИС. Техническое проектирование – стадия работ по проектированию АС, которая включает (этапы): 1. разработка проектных решений по системе и ее частям 2. разработка документации на АС и ее части 3. разработка и оформление документации на поставку изделий для комплектования АС и (или) технических требований (технических заданий) на их разработку 4. разработка заданий на проектирование в смежных частях проекта объекта автоматизации Итоговым документом данной стадии проектирования является технический проект, содержащий помимо перечисленных материалов принципиальные электрические схемы и конструкторскую документацию объекта разработки и составных его частей, перечень выбранных готовых средств программного и технического обеспечения (в том числе - ЭВМ, операционной системы , прикладных программ и т.д.), а также алгоритмы решения задач для разработки новых средств программного обеспечения и др. Этап технического проектирования предполагает разработку широкого комплекта проектных документов всесторонне представляющих общесистемные проектные решения и проектные решения по каждой обеспечивающей подсистеме. В составе документов с общесистемными проектными решениями должны быть представлены следующие документы: - ведомость технического проекта; - пояснительная записка к техническому проекту; - описание автоматизируемых функций; - ведомость покупных изделий; - описание постановки задач (комплекса задач); - локальный сметный расчет; - проектная оценка надежности системы. Содержание пояснительной записки к техническому проекту имеет структуру аналогичную структуре пояснительной записки к эскизному проекту: 1) общие положения; 2) описание процесса деятельности; 3) проектные решения; 4) мероприятия по подготовке объекта автоматизации к вводу системы в действие. Проектные решения по техническому обеспечению в данном комплекте представлены следующими документами: - описание комплекса технических средств; - ведомость оборудования и материалов; - план расположения; - перечень заданий на разработку строительных, санитарно-технических, электротехнических др. разделов проекта, связанных с созданием системы. Проектные решения по информационному обеспечению представлены следующими документами: - описание информационного обеспечения; - описание организации информационной базы; - описание массива информации; - перечень входных сигналов и данных; - чертеж формы документа. В рамках программного обеспечения создается: описание программного обеспечения. Проектные решения по математическому обеспечению отражаются в документе описания алгоритма (проектной процедуры). Проектные решения по организационному обеспечению должны быть представлены документом – описание организационной структуры. Лингвистическое обеспечение – описание систем классификации и кодирования информации. В ходе технического проектирования осуществляется: · Разработка проектных решений по системе и ее частям – при этом разрабатывается несколько вариантов проектных решений, для каждого из которых проводится оценка их трудоемкости и стоимости, на основе сопоставительной оценки всех представленных вариантов, принимаются окончательные проектные решения по системе в целом и каждой ее подсистеме. · На основе оптимального варианта проектных решений по системе в целом и ее подсистемам далее осуществляется разработка документации на АИС и ее части · Разработка и оформление документации на поставку изделий для комплектования АИС и/или технических требований (технических заданий) на их разработку · Разработка заданий на проектирование в смежных частях проекта объекта автоматизации. На этапе технического проектирования осуществляется комплекс научно-исследовательских и экспериментальных работ для выбора основных проектных решений и расчет экономической эффективности системы.
|
50. Рабочее проектирование автоматизированной информационной системы Рабочий проект – это комплект проектных документов на АИС, разрабатываемых на этапе рабочего проектирования, утвержденный в установленном порядке, содержащий взаимоувязанные проектные решения по системе в целом, ее функциям, всем видам обеспечения, достаточные для создания и функционирования АИС. Рабочее проектирование – заключительная стадия проектирования, которая помимо требуемой ГОСТ 34.601-90 разработки рабочей документации на систему и её части в общем случае предусматривает уточнение и детализацию результатов предыдущих этапов, создание и испытания опытного и/или опытно-промышленного образца объекта автоматизации, разработку и отработку программных продуктов, технологической и эксплуатационной документации. Результаты излагаются в рабочем или технорабочем проекте. В современной практике проектирования автоматизированных информационных систем (например, АБИС, АСНТИ, АСУ и др.) он является начальным этапом их внедрения в работу фирмы, организации или службы, являющейся заказчиком проекта, или головной в ряде других автоматизируемых фирм, организаций, служб и т.д. Цикл разработки (проектирования) программного обеспечения – совокупность стадий разработки программного обеспечения начиная от системного анализа и разработки исходных требований до её внедрения. На этапе рабочего проектирования осуществляется разработка комплекта рабочей документации, содержащей взаимоувязанные окончательные проектные решения по системе в целом и по всем видам обеспечения достаточные для создания и функционирования ИС. В составе рабочих документов должны быть документы с общесистемными и локальными проектными решениями. Состав их определяется ГОСТом 34.201-89 Виды, комплектность и обозначение документов при создании автоматизированных систем. Содержание каждого документа определяется РД 50-34.698-90 Комплекс стандартов и руководящих документов на АС. Требования к содержанию документов. В приложениях к этому документу приводятся требования к содержанию документов предпроектной стадии. В частности к отчету о предпроектном обследовании и концепции. Центральное место в составе работ, выполняемых на этапе проектирования занимает создание программного продукта, обеспечивающего решение задач системы, сопровождающей программной документации. В качестве альтернативы речь может идти о выборе и адаптации программного продукта к условиям создаваемой системы. При этом могут разрабатываться отдельные модули программного обеспечения, встраиваемые в существующий программный продукт и ориентированные на решение инновационных задач. Рабочее проектирование включает следующие этапы: 1. разработка рабочей документации на систему и ее части 2. разработка или адаптация программ 3. разработка программ и программных средств системы 4. выбор, адаптация и (или) привязка приобретаемых программных средств 5. разработка программной документации. В состав основных разрабатываемых документов входят: - ведомость держателей подлинников; - ведомость эксплуатационных документов; - спецификация оборудования; - ведомость машинных носителей информации; -технологическая инструкция; - руководство пользователя; - инструкция по формированию и ведению базы данных (набора данных); - инструкция по эксплуатации комплекса технических средств (КТС); - чертеж установки технических средств; - описание технологического процесса обработки данных (включая телеобработку); - общее описание системы; - программа и методика испытаний (компонентов, комплексов средств автоматизации, подсистем, систем); - формуляр; - паспорт. Нормативная база рабочего проектирования: 1. ГОСТ 34.003-90 ИТ. Комплекс стандартов на АС. Автоматизированные системы. Термины и определения. 2. ГОСТ 34.601-90 ИТ. Комплекс стандартов на АС. Автоматизированные системы. Стадии создания. 3. ГОСТ 34.201-89 ИТ. Комплекс стандартов на АС. Виды, комплектность и обозначение документов при создании автоматизированных систем. 4. РД 50-34.698-90 Методические указания. ИТ. Комплекс стандартов и руководящих документов на АС. АС. Требования к содержанию документов.
|
51. Внедрение проекта автоматизированной информационной системы Состав и общая характеристика этапов послепроектной стадии На после послепроектной стадии (стадии внедрения проекта) осуществляется подготовка объекта автоматизации к внедрению проекта и постепенное освоение разработанной в ходе проектирования рабочей документации заказчиком ИС, при участии на начальных этапах разработчика. Внедрение проекта может осуществляться с использованием следующих методов: 1) Последовательный метод – когда последовательно, одна за другой внедряются подсистемы, а в подсистемах также последовательно задачи, реализуемые этими подсистемами. 2) Параллельный метод – все подсистемы и все задачи внедряются одновременно. 3) Смешанный подход – сочетает в себе возможности и последовательного и параллельного метода. Внедрение проекта осуществляется с выделением следующих этапов: 1) Подготовка объекта автоматизации к внедрению проекта ИС. 2) Испытание проекта ИС. Предусматривает следующие виды испытаний: - предварительные испытания - опытная эксплуатация - приемочное испытание 3) Сопровождение ИС, введенного в эксплуатацию, в частности гарантийное и послегарантийное. К числу важнейших нормативно-технических документов, регламентирующих выполнение работ на послепроектной стадии относятся: - ГОСТ 34.601-90 Автоматизированные системы. Стадии создания. - ГОСТ 34.603-92 Виды испытаний автоматизированных систем. - РД 50-34.698-90 Автоматизированные системы. Требования к содержанию документов. В числе важнейших видов документов, созданных на послепроектной стадии, относятся: - приказ о проведении работ - план-график проведения работ - программа испытаний - акт приемки или завершения - протокол испытаний или согласования. Состав и характеристика видов работ выполняемых на этапах послепроектной стадии I) Подготовка объекта автоматизации к внедрению ИС. В соответствии с требованиями нормативных документов, на данном этапе выполняются следующие виды работ: 1) Изменение в соответствии с требованиями к ИС организационной и функциональной структуры объекта автоматизации. 2) Выполнение (при необходимости) строительных, монтажных и испытательных работ. 3) Приобретение технических, программных и иных обеспечивающих средств, предусмотренных проектом. 4) Подбор кадров соответствующей квалификации и их обучение работе в условиях ИС. 5) Обеспечение всех пользователей инструктивно-методическими документами. 6) Создание компонентов машинной информационной базы. В результате выполнения работ на этом этапе составляется «Акт готовности объекта автоматизации к внедрению проекта ИС». Акт подготавливается членами комиссии и утверждается в установленном порядке. После этого формируется состав комиссии которая оценивает результаты последовательных испытаний системы. II) Испытание системы В составе испытаний выделяются: 1) Предварительные испытания ИС – проводят для определения ее работоспособности и решения вопроса о возможности приемки системы в опытную эксплуатацию. В ходе предварительных испытаний проверяют: Предварительные испытания могут быть: - автономные – проводимые для отдельных частей ИС - комплексные – распространяются на систему в целом. 2) Опытная эксплуатация Проводят в соответствии с программой опытной эксплуатации. В программе указывают: 1) Условия и порядок функционирования системы в целом и ее подсистемах 2) Продолжительность опытной эксплуатации, достаточной для проверки правильности функционирования ИС и готовности персонала к работе в условиях функционирования ИС. 3) Порядок устранения недостатков, выявленных в процессе опытной эксплуатации. Результаты опытной эксплуатации фиксируются в рабочем журнале, где представляют сведения об отказах, сбоях, аварийных ситуациях, изменениях параметров объекта автоматизации, проведенных корректировках документации и программных средств, наладке технических средств, а также замечаний персонала по неудобству работ в условиях внедряемой ИС. Работа по проверке системы на данном этапе завершается оформлением акта о завершении опытной эксплуатации и допуск системы к приемочным испытаниям. 3) Приемочные испытания Проводят в соответствии с программой в которой указывают: 1) Состав объектов (подсистем, комплексов задач, отдельных задач), выделяемых для испытаний и перечень требований, которым они должны соответствовать со ссылкой на ТЗ. 2) Состав документации, которая должна быть представлена для проведения приемочных испытаний, в т.ч.: - ТЗ - акт приемки в опытную эксплуатацию - рабочие журналы опытной эксплуатации - акт завершения опытной эксплуатации и допуска ИС к приемочным испытаниям. - программа и методика испытаний. На основании общего протокола составляется заключение о соответствии системы требованиям ТЗ и возможности оформления акта приемки ИС в постоянную эксплуатацию. Работу завершают оформлением акта о приемке ИС в постоянную эксплуатацию. 4) Постоянная эксплуатация В составе ввода системы в постоянную эксплуатацию выделяют 2 этапа: 1) Гарантийное обслуживание – осуществляется выполнение работ в соответствии с гарантийными обязательствами разработчика. В соответствии с испытаниями разработчик обязан устранить недостатки, выявленные при эксплуатации ИС в течении установленных гарантийных сроков. В соответствии с выявленными и устраненными недостатками разработчиком должны быть внесены необходимые изменения в рабочую документацию на ИС. 2) Послегарантийное сопровождение и обслуживание – выявление отклонений фактических эксплуатационных характеристик ИС от проектных значений, а также устранение выявленных недостатков может осуществляться силами как заказчика, так и разработчика. В соответствии с выявленными недостатками на данном этапе разработчику предлагается внесение необходимых изменений в рабочую документацию.
|
||
|
52. Проектирование подсистемы организационного обеспечения Обеспечивающие подсистемы ЭИС являются общими для всей ИС независимо от конкретных функциональных подсистем, в которых применяются те или иные виды обеспечения. Состав обеспечивающих подсистем не зависит от выбранной предметной области. В состав обеспечивающих подсистем входят подсистемы организационного, правового, технического, математического, программного, информационного, лингвистического и технологического обеспечения. Подсистема «Организационное обеспечение» {ОО) является одной из важнейших подсистем ИС, от которой зависит успешная реализация целей и функций системы. В составе организационного обеспечения можно выделить четыре группы компонентов. Первая группа включает важнейшие методические материалы, регламентирующие процесс создания и функционирования системы: • общеотраслевые руководящие методические материалы по созданию ИС; • типовые проектные решения; • методические материалы по организации и проведению предпроектного обследования на предприятии; • методические материалы по вопросам создания и внедрения проектной документации. Вторым компонентом в структуре организационного обеспечения ИС является совокупность средств, необходимых для эффективного проектирования и функционирования ИС (комплексы задач управления, включая типовые пакеты прикладных программ, типовые структуры управления предприятием, унифицированные системы документов, общесистемные и отраслевые классификаторы и т.п.). Третьим компонентом подсистемы организационного обеспечения является техническая документация, получаемая в процессе обследования, проектирования и внедрения системы: технико-экономическое обоснование, техническое задание, технический и рабочий проекты и документы, оформляющие поэтапную сдачу системы в эксплуатацию. Четвертым компонентом подсистемы организационного обеспечения является «Персонал», где представлена организационно-штатная структура проекта, определяющая, в частности, состав главных конструкторов системы и специалистов по функциональным подсистемам управления. Для организационного обеспечения приводят требования: 1) к структуре и функциям подразделений, участвующих в функционировании системы или обеспечивающих эксплуатацию; 2) к организации функционирования системы и порядку взаимодействия персонала АС и персонала объекта автоматизации; 3) к защите от ошибочных действий персонала системы.
|
53. Проектирование подсистемы технологического обеспечения Технологическая подготовка – совокупность мероприятий, обеспечивающих технологическую готовность. Технологическая готовность производства – наличие на предприятии полных комплектов конструкторской и технологической документации и средств технологического оснащения, необходимых для осуществления заданного объема выпуска продукции с установленными технико-экономическими показателями Технологичность – соотношение затрат на производство продукции и получение при этом результатов с позиции объема и качества. Применительно к технологической подготовке производства рассматриваются вопросы ее планирования, учета, контроля, регулирования, анализа. Критериями технологической подготовки производства являются: - технологичность продукции - эффективность производства - сокращение сроков освоения выпуска новой продукции - повышение удельного веса продукции, отвечающего заданному (мировому) уровню качества - повышение производительности труда.
Подсистема «Технологическое обеспечение» (ТО) ИС соответствует разделению ИС на подсистемы по технологическим этапам обработки различных видов информации: · первичной и результатной информации (этапы технологического процесса сбора, передачи, накопления, хранения, обработки первичной информации, получения и выдачи результатной информации); · организационно-распорядительной документации (этапы получения входящей документации, передачи на исполнение, этапы формирования и хранения дел, составления и размножения внутренних документов и отчетов); · технологической документации и чертежей (этапы ввода в систему и актуализации шаблонов изделий, ввода исходных данных и формирования проектной документации для новых видов изделий, выдачи на плоттер чертежей, актуализации банка ГОСТов, ОСТов, технических условий, нормативных данных, подготовки и выдачи технологической документации по новым видам изделий); · баз данных и знаний (этапы формирования баз данных и знаний, ввода и обработки запросов на поиск решения, выдачи варианта решения и объяснения к нему); · научно-технической информации, ГОСТов и технических условий, правовых документов и дел (этапы формирования поисковых образов документов, формирования информационного фонда, ведения тезауруса справочника ключевых слов и их кодов, кодирования запроса на поиск, выполнения поиска и выдачи документа или адреса хранения документа).
Проектирование технологических процессов В проектировании технологических процессов можно выделить собственно проектирование, а также подготовительную и заключительную работы. В соответствии с этим принято говорить о 3-х стадиях разработки технологических процессов (предпроектная, проектная и послепроектная). 1) Предпроектная стадия включает следующие этапы: - анализ исходных данных для разработки технологического процесса - выбор типового или обоснование разработки единичного технологического процесса 2) Проектная стадия - составление технологического маршрута - разработка технологических операций - нормирование технологического процесса - расчет экономической эффективности технологического процесса 3) Послепроектная стадия - подготовка технологической документации на технологический процесс (маршрутная карта или карта технологического процесса, операционная карта и др.) - согласование и утверждение технологических документов.
|
54. Проектирование подсистемы информационного обеспечения Информационное обеспечение предусматривает создание единого информационного фонда системы, представленного информационными массивами, базами данных, форматами входных, выходных и промежуточных документов. Для информационного обеспечения системы приводят требования: 1) к составу, структуре и способам организации данных в системе; 2) к информационному обмену между компонентами системы; 3) к информационной совместимости со смежными системами; 4) по использованию общесоюзных и зарегистрированных республиканских, отраслевых классификаторов, унифицированных документов и классификаторов, действующих на данном предприятии; 5) по применению систем управления базами данных; 6) к структуре процесса сбора, обработки, передачи данных в системе и представлению данных; 7) к защите данных от разрушений при авариях и сбоях в электропитании системы; 8) к контролю, хранению, обновлению и восстановлению данных; 9) к процедуре придания юридической силы документам, продуцируемым техническими средствами АС (в соответствии с ГОСТ 6.10.4). Проектирование информационного обеспечения осуществляется в соответствии с составом задач, решение которых предусмотрено в условиях проектируемой АИС. Описание информационного обеспечения предусматривает представление следующих сведений: - принципов организации информационного обеспечения; - организации сбора и обработки информации; - структуры внемашинной и внутримашинной информационной базы. При описании структуры информационной базы должны быть указаны: 1) состав документов и данных, использование которых предусматривается при построении информационной базы; 2) состав баз данных с указанием логических связей между их элементами; 3) состав средств защиты информационной базы от несанкционированного доступа и разрушения; 4) способы актуализации информационных массивов. Описание выходных и входных документов и данных предусматривает представление их перечня, форматов, сведений о ритмичности потоков документов, оценку документов с позиций требований совместимости, оценку их объемов. При проектировании форматов входных и выходных документов должны учитываться существующие системы документации межотраслевого, отраслевого уровней, а также системы документации предприятий и организаций. При этом предпочтение рекомендуется отдавать унифицированным системам документации. В соответствии с ГОСТ Р 51141-98 «Делопроизводство и архивное дело. Термины и определения» под унифицированной системой документации понимается система документации, созданная по единым правилам и требованиям, содержащая информацию, необходимую для управления в определенной сфере деятельности. Важнейшим элементом любой унифицированной системы документации являются унифицированные формы документов – совокупность реквизитов, установленных в соответствии с решаемыми в данной деятельности задачами и расположенных в определенном порядке на носителе информации. В составе выходных форматов, наряду с традиционными (бумажными) формами, могут быть предусмотрены экранные формы представления данных. При проектировании информационного обеспечения также должна быть разработана и приведена в составе приложений к дипломному проекту технологическая инструкция по формированию и ведению баз данных. Данная инструкция отражает правила подготовки данных; порядок и средства заполнения базы данных; процедуры изменения и контроля базы данных; порядок и средства восстановления базы данных. В правилах подготовки данных приводят порядок отбора информации для включения в базу данных; правила подготовки и кодирования информации; формы ее представления и правила заполнения форм; порядок внесения изменений. При описании порядка и средств заполнения базы данных приводят состав правила, последовательность и описание процедур, используемых при заполнении базы данных, включая перенос данных на машинные носители информации. Описание процедур изменения и контроля базы данных включает сведения о составе и последовательность действий по контролю и изменению содержания базы данных. При описании порядка и средств восстановления базы данных приводят описание средств защиты базы данных от разрушения и несанкционированного доступа, а также правила, средства и порядок проведения процедур по копированию и восстановлению базы данных. Состав аспектов содержания, подлежащих отражению в инструкции, должен соответствовать требованиям комплексов стандартов «3. Единая система технологической документации», «34. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы». В заключении необходимо дать оценку соответствия спроектированного информационного обеспечения требованиям к информационному обеспечению системы (подсистемы), предъявляемым нормативными документами (стандартами, руководящими документами и др.), а также техническим заданием на создание конкретной АИС.
|
||
|
55. Проектирование подсистемы лингвистического обеспечения Лингвистическое обеспечение предусматривает выбор и (или) создание лингвистических средств, обеспечивающих рациональное представление и поиск данных в АИС. Лингвистическое обеспечение АИС включает в себя комплекс информационно-поисковых языков (ИПЯ), а также средств и методов их создания, ведения, использования и контроля. Для лингвистического обеспечения системы приводят требования к применению в системе языков программирования высокого уровня, языков взаимодействия пользователей и технических средств системы, а также требования к кодированию и декодированию данных, к языкам ввода-вывода данных, языкам манипулирования данными, средствам описания предметной области (объекта автоматизации), к способам организации диалога. В структуре лингвистического обеспечения проектируемой АИС, в зависимости от ее типа и состава решаемых задач, могут быть представлены следующие группы лингвистических средств: 1. Информационно-поисковые языки: 1.1. Классификационные ИПЯ 1.2. Дескрипторные ИПЯ 1.3. Объектно-признаковый язык (в т. ч. язык библиографического описания) 2. Элементы информационно-поисковых языков: 2.1. Международные стандартные номера (ISBN, ISSN) 2.2. Коды названий (языков, стран, физических единиц и т. п.) 3. Языки взаимодействия с системой: 3.1. Семантические языки разметки текста ((HTML и т. п.) 3.2. Языки диалога (элементы интерфейса и т. п.) 4. Форматы представления данных в машиночитаемой форме (коммуникативные форматы RUSMARC, UNIMARC и т. п.) 5. Нормативно-справочная база: 5.1. Нормативные документы 5.2. Инструктивно-методические документы 5.3. Справочники 5.4. Файлы авторитетных записей (предметных рубрик, авторов и т. п.). Наполнение данных групп конкретными лингвистическими средствами осуществляется на основе анализа задач, решаемых конкретной системой, функционирующих в ней документальных потоков, а также выполняемых информационных запросов. Процесс проектирования лингвистического обеспечения АИС включает следующие этапы: 1. Выявление лингвистических средств на основе анализа задач, решаемых в конкретной АИС. 2. Выявление лингвистических средств входного и выходного документального потока. 3. Выявление лингвистических средств, обеспечивающих выполнение информационных запросов. 4. Выявление компонентов нормативно-справочной базы лингвистического обеспечения: стандартов, положений, инструктивно-методических документов, справочников и т. п. 5. Разработка логических структур проектируемых справочников. В случае, если лингвистические средства разрабатываются самостоятельно либо используются локальные лингвистические средства конкретных организаций и учреждений, следует привести их (полностью или в виде фрагмента) в приложении. Необходимо обосновать выбор той или иной системы кодирования при построении лингвистического средства. При этом рекомендуется ориентироваться на системы кодирования, представленные на рис.
Порядковый метод кодирования метод, при котором кодами служат числа натурального ряда; в этом случае кодом каждого из объектов классифицируемого множества является его порядковый номер Серийно-порядковый метод кодирования метод, при котором кодами служат числа натурального ряда с закреплением отдельных серий этих чисел за объектами классификации с одинаковыми признаками Последовательный метод кодирования метод кодирования, при котором код объекта классификации и (или) классификационной группировки образуется с использованием кодов последовательно расположенных подчиненных группировок, полученных при иерархическом методе классификации; в этом случае код нижестоящей группировки образуется путем добавления соответствующего количества разрядов к коду вышестоящей группировки Параллельный метод кодирования метод, при котором код объекта классификации и (или) классификационной группировки образуется с использованием кодов независимых группировок, полученных при фасетном методе классификации
|
56. Проектирование подсистемы математического обеспечения Подсистема «Математическое обеспечение» (МО) - это совокупность математических моделей и алгоритмов для решения задач и обработки информации с применением вычислительной техники, а также комплекс средств и методов, позволяющих строить экономико-математические модели задач управления. В состав МО входят: 1. средства МО (средства моделирования типовых задач управления, методы многокритериальной оптимизации, математической статистики, теории массового обслуживания и др.); 2. техническая документация (описание задач, алгоритмы решения задач, экономико-математические модели); 3. методы выбора МО (методы определения типов задач, методы оценки вычислительной сложности алгоритмов, методы оценки достоверности результатов). Для математического обеспечения системы приводят требования к составу, области применения (ограничения) и способам, использования в системе математических методов и моделей, типовых алгоритмов и алгоритмов, подлежащих разработке. Назначение, состав и структура математического обеспечения (МО) МО в АС предназначено для реализации управляющих решений, рассматриваемых как совокупность действий для достижения поставленных целей в рамках технического задания. Состав МО: 1. Математическое описание (формализация) задач. 2. Математические модели и их оптимизация. 3. Данные, подготовленные для описания исследуемых процессов. 4. Алгоритмы решения задач. 5. Анализ моделей и алгоритмов по результатам выполненных работ на ЭВМ. Система математического обеспечения АС должна выполнять следующие функции: • реализацию любых процедур обработки данных; • компоновку рабочих программ решения конкретных задач из стандартных программ и оригинальных блоков; • организацию управления процессом решения задач и их комплексов; • реализацию экономико-математических методов решения оптимизационных задач. МО АС должна содержать средства автоматизации программирования задач, а также средства компоновки рабочих моделей конкретных систем из стандартных программ и их обслуживания. В МО по последовательности проектирования АСУ рассматривают три уровня: 1) математическое обеспечение конкретной АС, которой определяется мощность АС; 2) автоматизацию проектирования АС; 3) автоматизацию программирования и организацию работ на ЭВМ. Разработка МО предполагает выполнение следующих этапов: • создание модели системы; • разработку укрупненного алгоритма; • разработку алгоритмов отдельных элементов МО; • проверку достоверности алгоритмов (выбор вычислительных средств, проведение программирования, проверку достоверности программы). Прежде всего выполняют постановку задачи моделирования: • определение требований к исходной информации, ее сбор; • выдвижение гипотез и предположений; • определение параметров и переменных модели; • обоснование выбора показателей и критериев эффективности системы; • определение содержания и описание модели (основной документ). Модели и алгоритмы обработки информации Существующие математические модели экономических систем можно представить тремя группами: 1. Алгебраические уравнения 2-й или 3-й степени (алгебраические). 2. Модели систем массового обслуживания (статистические). 3. Модели больших и очень больших систем. Алгебраическое моделирование — процесс функционирования системы во времени, причем имитируются элементарные явления, с сохранением их логической структуры и последовательности протекания во времени. Статистические модели строятся методом статистических испытаний случайных чисел. Документ "Описание алгоритма (проектной процедуры)" в зависимости от специфики АС допускается разрабатывать как документ "Описание алгоритма" или как документ "Описание проектной процедуры (операции)". Документ "Описание алгоритма" содержит разделы: 1) назначение и характеристика; 2) используемая информация; 3) результаты решения; 4) математическое описание; 5) алгоритм решения. В разделе "Алгоритм решения" следует приводить: 1) описание логики алгоритма и способа формирования результатов решения с указанием последовательности этапов счета, расчетных и (или) логических формул, используемых в алгоритме; 2) указания о точности вычисления (при необходимости); 3) соотношения, необходимые для контроля достоверности вычислений; 4) описание связей между частями и операциями алгоритма; 5) указания о порядке расположения значений или строк в выходных документах (например, по возрастанию значений кодов объектов, по группам объектов и т. д ). Алгоритмом должны быть предусмотрены все ситуации, которые могут возникнуть в процессе решения задачи. При изложении алгоритма следует использовать условные обозначения реквизитов, сигналов, граф, строк со ссылкой на соответствующие массивы и перечни сигналов. В расчетных соотношениях (формулах) должны быть использованы обозначения реквизитов, приведенные при описании их состава в других разделах документа. Алгоритм представляют одним из следующих способов: 1) графический (в виде схемы); 2) табличный; 3) текстовой; 4) смешанный Алгоритм в виде схемы выполняют по правилам, установленным ГОСТ 19.002 или ГОСТ 19.005. Алгоритм в виде таблиц выполняют по правилам, установленным ГОСТ 2.105. Алгоритм в виде текстового описания выполняют по правилам, установленным ГОСТ 24.301. |
57. Проектирование подсистемы программного обеспечения Подсистема «Программное обеспечение» {ПО) включает совокупность компьютерных программ, описаний и инструкций по их применению на ЭВМ. Программное обеспечение предусматривает выбор и (или) создание комплекса программных средств, необходимых для реализации поставленных задач, а также разработку руководства пользователя. Для программного обеспечения системы приводят перечень покупных программных средств, а также требования: 1) к независимости программных средств от используемых СВТ и операционной среды; 2) к качеству программных средств, а также к способам его обеспечения и контроля; 3) по необходимости согласования вновь разрабатываемых программных средств с фондом алгоритмов и программ. Определение программной платформы проектируемой АИС связано, прежде всего, с выбором одного из альтернативных вариантов: использование существующих на рынке тиражируемых систем или создание уникальной системы, полностью ориентированной только на задачи конкретной предметной области (предприятия, организации и т. п.). Основным достоинством первого подхода является апробированность и отсутствие часто проявляющихся, типовых ошибок. Основным преимуществом второго подхода является его ориентация на разработку системы, полностью соответствующей особенностям конкретного предприятия. Среди факторов, влияющих на выбор программного обеспечения, определяющее значение имеют: - достигнутый к моменту проектирования уровень автоматизации предприятия (организации и т.п.) и учет принятых при этом проектных решений; - мировой и отечественный уровень достижений в сфере разработки программных продуктов, ориентированных на решение задач данной предметной области; - состав задач, решаемых проектируемой АИС или ее подсистемой. Проектные решения по структуре программного обеспечения АИС должны включать: определение всех компонентов программного обеспечения с указанием их взаимосвязей и обоснованием выделения каждого из них; функции компонентов программного обеспечения; методы и средства разработки программного обеспечения. При описании системного программного обеспечения следует привести наименование, краткую характеристику операционной системы и ее версии, в рамках которой будет функционировать прикладное программное обеспечение проектируемой системы (подсистемы), а также обоснование решения о выборе данной операционной системы. При описании прикладного программного обеспечения системы (подсистемы) также следует обосновать его выбор и дать характеристику внутренней структуры прикладного программного обеспечения с указанием основных функций и взаимосвязей его частей (программ, процедур, модулей, подпрограмм). В случае принятия решения о разработке собственного программного обеспечения необходимо привести критерии выбора среды программирования (языка программирования, системы управления базами данных, интегрированной среды, встроенного языка) или использования готового (существующего) программного продукта (пакета прикладных программ). При этом следует привести краткую характеристику инструментария технологии программирования (среды программирования, языка программирования, системы управления базами данных, интегрированной среды, встроенного языка, CASE-технологии). Особое место при описании проектных решений по программному обеспечению занимает характеристика интерфейса прикладного программного обеспечения системы (подсистемы). Описание методов и средств разработки программного обеспечения должно включать описание алгоритмов решения задач АИС. Алгоритм может быть представлен графическим, табличным, текстовым или смешанным способом. При подготовке дипломного проекта следует использовать текстовый и графический способы представления процедуры решения задачи. При составлении текстового (словесного) описания алгоритма должны быть отражены: назначение алгоритма; характеристика задачи, на решение которой направлен алгоритм; ограничения на возможность и условия применения алгоритма; описание логики алгоритма и способа формирования результатов решения; характеристика результатов (перечень информационных массивов, формируемых в результате реализации алгоритма). Текстовый способ описания алгоритма входит в состав параграфа, описывающего решения по программному обеспечению. Графический способ описания алгоритма, представленный в виде блок-схем алгоритмов решения трех наиболее важных задач, решаемых проектируемой АИС, должен быть приведен в приложении к дипломному проекту. Требования к представлению схем алгоритмов регламентируются ГОСТ 19.701-90 «ЕСПД. Схемы алгоритмов, программ, данных и систем. Условные обозначения и правила выполнения». При проектировании программного обеспечения также должно быть разработано и приведено в составе приложений к дипломному проекту руководство пользователя. При создании данного документа следует ориентироваться на такие нормативные документы, как ГОСТ Р ИСО 9127-94 «Системы обработки информации. Документация пользователя и информация на упаковке для потребительских программных пакетов» и РД 50-34.698-90 «Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Требования к содержанию документов». В соответствии с данными документами структура руководства пользователя должна включать следующие разделы: введение; назначение и условия применения; подготовка к работе; описание операций; аварийные ситуации; рекомендации по освоению.
|
|
58. Проектирование подсистемы технического обеспечения Подсистема «Техническое обеспечение» (ТО) представляет комплекс технических средств, предназначенных для обработки данных в ЭИС. В состав комплекса входят электронные вычислительные машины, осуществляющие обработку экономической информации, средства подготовки данных на машинных носителях, средства сбора и регистрации информации, средства передачи данных по каналам связи, средства накопления и хранения данных и выдачи результатной информации, вспомогательное оборудование и организационная техника. Для технического обеспечения системы приводят требования: 1) к видам технических средств, в том числе к видам комплексов технических средств, программно-технических комплексов и других комплектующих изделий, допустимых к использованию в системе; 2) к функциональным, конструктивным и эксплуатационным характеристикам средств технического обеспечения системы. В составе технического обеспечения должен быть представлен комплекс технических средств, предназначенных для обеспечения функционирования автоматизированной информационной системы, а также соответствующая документация на эти средства. Комплекс технических средств составляют: - персональные компьютеры; - периферийные устройства: устройства ввода-вывода, накопления и хранения информации; - устройства передачи информации и каналы связи; - оргтехника; - эксплуатационные материалы. Среди факторов, влияющих на выбор технического обеспечения, определяющее значение имеют: - мировой и отечественный уровень достижений в сфере разработки технических средств; - состав технических средств, имеющихся на предприятии (в организации и т.п.) к моменту проектирования АИС; - состав задач, решаемых проектируемой АИС или ее подсистемой; - требования подсистем информационного, лингвистического и программного обеспечения к уровню технических средств. Проектирование подсистемы технического обеспечения, в первую очередь, предполагает обоснование и описание основных решений по выбору комплекса технических средств. При этом необходимо привести исходные данные для проектирования технического обеспечения. С одной стороны, они характеризуют современный рынок вычислительной и организационной техники, а с другой стороны, связаны с требованиями, которые обусловлены проектными решениями по информационному, лингвистическому, программному обеспечению, с третьей стороны, связаны с имеющейся технической базой заказчика АИС и его возможностями по модернизации технической базы. Результатом сопоставления исходных данных является структура комплекса технических средств, предлагаемая с позиций минимального и оптимального (рекомендуемого) уровня технического обеспечения. Результаты принятия проектных решений по структуре комплекса технических средств должны быть представлены в виде ведомости оборудования и материалов. Ведомость оборудования и материалов Данные, приведенные в ведомости оборудования и материалов, в дальнейшем используются при составлении сметы на приобретение и монтаж средств технического обеспечения, что также необходимо и при определении состава затрат в ходе технико-экономического обоснования создания АИС. При характеристике персонального компьютера следует привести следующие данные: - фирма-производитель микропроцессора; - тип микропроцессора; - тактовая частота микропроцессора; - емкость оперативной памяти - тип и емкость накопителей на машинных носителях; - виды и емкость КЭШ-памяти. Описание основных решений по выбору типов периферийных технических средств должно распространяться на средства получения, контроля, подготовки, сбора, ввода, регистрации, хранения и отображения информации. Для видеомонитора следует привести следующие характеристики: фирма-производитель, тип, разрешающая способность, размер экрана; максимально допустимый размер зерна. Видеоадаптер описывается по следующим параметрам: разрешающая способность, число цветов, емкость видеобуфера, частота кадров. Характеристика клавиатуры должна быть представлена следующим набором данных: фирма-производитель, тип, количество и набор клавиш (в том числе специальных клавиш). При описании манипулятора «мышь» приводятся данные о фирме-производителе, типе. При выборе принтера следует учитывать такие факторы, как: набор функциональных возможностей, по которым можно оценить применимость принтера для решения конкретных задач (размеры печатаемых документов, объемы выполняемых работ и т. п.); возможность формирования цветного изображения; качество изображения; производительность; надежность и удобство работы; эксплуатационные затраты, включающие стоимость носителя, расходных материалов, обслуживания устройства, потребление электроэнергии; стоимость принтера. С учетом приведенных факторов для характеристики принтера необходимо указать следующие данные: фирма-производитель; тип, разрешающая способность, скорость печати, форматы бумаги, количество встроенных шрифтов, подача бумаги. Характеристика сканеров должна включать следующие данные: фирма-производитель; тип, разрешающая способность, скорость сканирования, форматы бумаги. При проектировании АИС, функционирующей в сетевом режиме, при проектировании технического обеспечения также необходимо обосновать и описать решения по выбору аппаратуры (коммутаторов, концентраторов и т. п.), каналов передачи данных (проводных или беспроводных, аналоговых или цифровых, коммутируемых или некоммутируемых и т. п.), устройств сопряжения ПК с аппаратурой и каналами передачи данных (линейных адаптеров, мультиплексоров и т. п.), устройств межсетевого взаимодействия (маршрутизаторов, мостов, шлюзов, повторителей и т. п.). Практически в любых АИС используются средства копирования документов. При их описании приводятся такие характеристики, как: фирма-производитель, тип, производительность, формат документов, возможность масштабирования, возможность получения одноцветных или многоцветных копий. Кроме обоснования состава необходимого оборудования, должна быть определена и потребность в приобретении расходных материалов (бумаги, картриджей, тонеров, дискет, CD и т. п.). Наряду с описанием состава комплекса технических средств, дипломником должны быть сформулированы рекомендации по размещению комплекса технических средств на объектах и производственных площадях с учетом выполнения требований безопасности, соблюдения технических условий эксплуатации оборудования, а также требований эргономики. Особое место занимает обоснование используемых технических средств защиты данных от несанкционированного доступа к ним. В заключении необходимо дать оценку соответствия спроектированного технического обеспечения требованиям к техническому обеспечению системы (подсистемы), предъявляемым нормативными документами (стандартами, руководящими документами и др.), а также техническим заданием на создание конкретной АИС.
|
59. Индустриальное типовое проектирование информационных систем Методы типового проектирования ЭИС предполагают создание системы из готовых покупных типовых элементов (типовых проектных решений). Для этого проектируемая ЭИС должна быть декомпозируема на множество составляющих компонентов (подсистем, комплексов задач, программных модулей и т.д), для которых подбираются и закупаются имеющиеся на рынке типовые проектные решения. Далее закупленные типовые элементы, как правило, включающие программные продукты, настраиваются на особенности конкретного предприятия или дорабатываются в соответствии с требованиями проблемной области. Под типовым проектным решением (ТПР) будем понимать представленное в виде проектной документации, включая программные модули, проектное решение, пригодное к многократному использованию. В качестве проектного решения может выступать реализация как отдельных компонентов ИС (программных модулей, функциональных задач, автоматизированных рабочих мест, локальных баз данных, локальных вычислительных сетей), так и взаимосвязанных комплексов компонентов (функциональных и обеспечивающих подсистем, ЭИС в целом). Типовые проектные решения также называют тиражируемыми продуктами. В зависимости от уровня декомпозиции системы различают элементный, подсистемный и объектный методы типового проектирования. При элементном методе типового проектирования ЭИС в качестве типового элемента системы используется типовое решение по задаче или по отдельному виду обеспечения задачи (информационному, программному, техническому, математическому, организационному). Сущность применения ТПР при элементном методе заключается в комплектации ИС из множества ТПР по отдельным разрозненным задачам. Если данного множества недостаточно для того, чтобы спроектировать систему, необходимые модули дорабатываются вручную. Достоинство элементного метода типового проектирования ИС связано с применением модульного подхода к проектированию и документированию ИС. К недостаткам применения метода относятся большие затраты времени на сопряжение разнородных элементов вследствие информационной, программной и технической несовместимости ТПР, а также плохая адаптивность (настраиваемость) элементов к особенностям предприятия. Следствием перечисленных недостатков являются большие затраты времени на доработку и комплексирование ТПР отдельных элементов, сопоставимые со временем ручного оригинального проектирования ИС. В настоящее время элементные ТПР в основном применяются в качестве библиотек методо-ориентированных программ (библиотек классов объектов), например, при разработке графических интерфейсов, применении вычислительных и служебных функций. В силу ограниченного характера применения в дальнейшем метод элементного типового проектирования ИС не рассматривается. При использовании подсистемного метода типового проектирования ИС в качестве элементов типизации выступают отдельные подсистемы, которые обеспечивают функциональную полноту, минимизацию внешних информационных связей, параметрическую настраиваемость, альтернативность схем в пределах значений входных параметров. При этом достигается более высокая степень интеграции типовых элементов ИС. Типовые проектные решения для функциональных подсистем реализуются в виде пакетов прикладных программ (ППП), которые позволяют осуществлять: · модульное проектирование; · параметрическую настройку программных компонентов на различные объекты управления; · сокращение затрат на проектирование и программирование взаимосвязанных компонентов; · хорошее документирование отображаемых процессов обработки информации. Вместе с тем адаптивность типовых проектных решений в виде функциональных ППП недостаточна с позиции непрерывного инжиниринга деловых процессов. Также возникают проблемы в комплексировании ППП разных функциональных подсистем, особенно в случае использования ППП нескольких производителей программного обеспечения, для которых, как правило, характерна их информационная, программная и техническая несовместимость между собой при построении единой, корпоративной ЭИС. В качестве примеров широкораспространенных функциональных ППП можно назвать; 1С «Предприятие» (автоматизация бухгалтерского учета, расчета заработной платы, складского учета), «Фолио - Склад» (автоматизация складских операций), Project Expert (бизнес-планирование), ИНЭК (финансовый анализ) и др. При объектном методе типового проектирования ЭИС в качестве типового элемента используется типовой проект для объектов управления определенной отрасли, который включает полный набор функциональных и обеспечивающих подсистем ЭИС. Современные типовые проекты отличаются: · открытостью архитектуры, позволяющей устанавливать проекты на разных программно-технических платформах; · масштабируемостью, допускающей конфигурацию ЭИС для переменного числа рабочих мест; · конфигурируемостью, позволяющей выбирать подмножество компонентов, которые необходимы для конкретной проблемной области и параметрически настраиваются на особенности объекта управления. Несомненное преимущество объектного метода типового проектирования ЭИС перед подсистемным методом заключается в комплексируемости всех компонентов за счет методологического единства и информационной, программной и технической совместимости компонентов. Адаптивность объектного метода проектирования зависит от используемого подхода. При параметрической настройке типовых информационных систем, таких, например, как ППП «Галактика», «Парус», «БОСС» и другие, возникают проблемы привязки типового проекта к конкретному объекту управления так же, как и при подсистемном подходе. Обычным способом решения проблемы адаптации является изменение структуры организационно-экономической системы объекта внедрения в соответствии с требованиями типового проекта либо существенная доработка типового проекта с помощью специальных инструментальных средств типовой системы. Параметрически-ориентированное проектирование ИС При проектировании ИС на основе параметрической настройки пакета прикладных программ (ППП) последний рассматривается как «черный ящик». На вход ППП подаются параметрический (ПП) и информационный (ИП) потоки, а выходом служит результат работы пакета (РП). ППП включает следующие блоки: функционирования, обработки параметров, адаптации. Рассмотрим взаимосвязь основных потоков и компонентов пакета прикладных программ. Информационный поток представляет собой исходные данные, которые обрабатываются и необходимы для получения результатов работы пакета. Блок функционирования обрабатывает исходные данные и формирует результаты работы пакета. Графически блок функционирования представляется деревом программных модулей, которые автоматизируют функции обработки данных. Параметрический поток - информация, необходимая для настройки пакета на конкретные условия функционирования. Параметрический поток включает информацию, которая задается один раз при установке (инсталляции) этого пакета. Изменяя параметры, можно включать и выключать какие-либо модули или влиять на режим их работы. Для архитектуры «клиент-сервер» в параметрическом потоке описываются пользователи и их уровни доступа к программным модулям и ко всему пакету в целом. Параметрическая информация предоставляется: · в справочниках (классификаторах с задаваемым числом уровней классификации, например, в справочниках номенклатуры изделий и услуг, видов расчетов, валют и т.д.); · в таблицах описаний конфигурации программных модулей (например, условия включения (выключения) модуля, режимы ручного или автоматического обновления полей данных, методы расчетов показателей и т.д.). Блок обработки параметров представляет собой совокупность специальных модулей по интерпретации значений параметров. В частности, блок обработки параметров переносит установки пользователя непосредственно в прикладные программы и в используемую базу данных. Проводимая настройка ППП позволяет использовать его для широкого класса объектов управления. Блок адаптации взаимодействует с блоком функционирования и может добавлять модули или модифицировать их. Необходимость применения блока адаптации связана с потребностями доработки программных модулей ППП под воздействием внешних условий функционирования. Поэтому в состав ППП включается инструментарий адаптации существующих типовых проектных решений. В качестве таких инструментов, доступных квалифицированному пользователю (непрограммисту), используются: · генераторы программ ЭИС на основе языковых средств RAD-технологии (4GL); · макроязыки проектирования и настройки типовых модулей. Сущность применения метода типового проектирования ИС на основе параметрической настройки ППП заключается в определении критериев оценки ППП, оценке множества ППП-претендентов по сформулированным критериям, выбору и закупке ППП с наивысшей интегральной оценкой, а далее - собственно настройке параметров и возможной доработке закупленного ППП. Параметрически-ориентированное проектирование ИС на основе использования ППП по сравнению с оригинальным проектированием дает возможность более быстрого и гибкого внедрения информационной системы. Однако существует ряд проблем, сдерживающих распространение данной технологии. К ним можно отнести следующее: · психологические и организационные трудности внедрения ППП; · достаточно высокую стоимость приобретения ППП и обучения персонала; · отсутствие глобальной модели объекта управления, что ведет к затратам по увязке различных ППП в рамках корпоративной ЭИС. Модельно-ориентированное проектирование ЭИС Сущность модельно-ориентированного проектирования ЭИС сводится к адаптации компонентов типовой ЭИС в соответствии с моделью проблемной области конкретной организационно-экономической системы. Для этого технология проектирования должна поддерживать как модель типовой ЭИС, так и модель конкретного предприятия, а также средства поддержания соответствия между ними. Ядром типовой ИС является постоянно развиваемая модель проблемной области (предприятия), поддерживаемая в специальной базе метаинформации - репозитории, на основе которого осуществляется конфигурация программного обеспечения. Таким образом, проектирование и адаптация ИС сводятся прежде всего к построению модели проблемной области и ее периодической корректировке.
|
|
|
60. Индустриальное автоматизированное проектирование информационных систем Основные понятия и классификация CASE-технологий Термин CASE (Computer Aided System/Software Engineering) используется в довольно широком смысле. Первоначальное значение термина CASE, ограниченное вопросами автоматизации разработки только лишь программного обеспечения, в настоящее время приобрело новый смысл, охватывающий процесс разработки сложных ИС в целом. С самого начала CASE-технологии развивались с целью преодоления ограничений при использовании структурной методологии проектирования (сложности понимания, высокой трудоемкости и стоимости использования, трудности внесения изменений в проектные спецификации и т.д.) за счет ее автоматизации и интеграции поддерживающих средств. Таким образом, CASE-технологии не могут считаться самостоятельными, они только обеспечивают, как минимум, высокую эффективность их применения, а в некоторых случаях и принципиальную возможность применения соответствующей методологии. Большинство существующих CASE-систем ориентировано на автоматизацию проектирования программного обеспечения и основано на методологиях структурного (в основном) или объектно-ориентированного проектирования и программирования, использующих спецификации в виде диаграмм или текстов для описания системных требований, связей между моделями системы, динамики поведения системы и архитектуры программных средств. В последнее время стали появляться CASE-системы, уделяющие основное внимание проблемам спецификации и моделирования технических средств. Наибольшая потребность в использовании CASE-систем испытывается на начальных этапах разработки, а именно на этапах анализа и спецификации требований к ЭИС, Это объясняется тем, что цена ошибок, допущенных на начальных этапах, на несколько порядков превышает цену ошибок, выявленных на более поздних этапах разработки. Появлению CASE-технологии предшествовали исследования в области методологии программирования. Программирование обрело черты системного подхода с разработкой и внедрением языков высокого уровня, методов структурного и модульного программирования, языков проектирования и средств их поддержки, формальных и неформальных языков описания системных требований и спецификаций и т.д. Кроме того, этому способствовали перечисленные ниже факторы: • подготовка аналитиков и программистов, восприимчивых к концепциям модульного и структурного программирования; • широкое внедрение и постоянный рост производительности персональных ЭВМ, позволяющих использовать эффективные графические средства и автоматизировать большинство этапов проектирования; • внедрение сетевой технологии, предоставившей возможность объединения усилий отдельных исполнителей в единый процесс проектирования путем использования разделяемой базы данных, содержащей необходимую информацию о проекте. Преимущества CASE-технологии по сравнению с традиционной технологией оригинального проектирования сводятся к следующему: • улучшение качества разрабатываемого программного приложения за счет средств автоматического контроля и генерации; • возможность повторного использования компонентов разработки; • поддержание адаптивности и сопровождения ЭИС; • снижение времени создания системы, что позволяет на ранних стадиях проектирования получить прототип будущей системы и оценить его; • освобождение разработчиков от рутинной работы по документированию проекта, так как при этом используется встроенный документатор; • возможность коллективной разработки ЭИС в режиме реального времени. CASE-технология в рамках методологии включает в себя методы, с помощью которых на основе графической нотации строятся диаграммы, поддерживаемые инструментальной средой. Методология определяет шаги и этапность реализации проекта, а также правила использования методов, с помощью которых разрабатывается проект. Метод - это процедура или техника генерации описаний компонентов ЭИС (например, проектирование потоков и структур данных). Нотация - отображение структуры системы, элементов данных, этапов обработки с помощью специальных графических символов диаграмм, а также описание проекта системы на формальных и естественных языках. Инструментальные средства CASE - специальные программы, которые поддерживают одну или несколько методологий анализа и проектирования ИС. Ядром системы является база данных проекта - репозиторий (словарь данных). Он представляет собой специализированную базу данных, предназначенную для отображения состояния проектируемой ЭИС в каждый момент времени. Объекты всех диаграмм синхронизированы на основе общей информации словаря данных. Репозиторий содержит информацию об объектах проектируемой ЭИС и взаимосвязях между ними, все подсистемы обмениваются данными с ним. В репозитории хранятся описания следующих объектов: Графический редактор диаграмм предназначен для отображения в графическом виде в заданной нотации проектируемой ЭИС. Он позволяет выполнять следующие операции: Верификатор диаграмм служит для контроля правильности построения диаграмм в заданной методологии проектирования ЭИС. Документатор проекта позволяет получать информацию о состоянии проекта в виде различных отчетов. Отчеты могут строиться по нескольким признакам, например по времени, автору, элементам диаграмм, диаграмме или проекту в целом. Администратор проекта представляет собой инструменты, необходимые для выполнения следующих административных функций: • инициализации проекта; • задания начальных параметров проекта; • назначения и изменения прав доступа к элементам проекта; • мониторинга выполнения проекта. Сервис представляет собой набор системных утилит по обслуживанию репозитория. Данные утилиты выполняют функции архивации данных, восстановления данных и создания нового репозитория. Современные CASE-системы классифицируются по следующим признакам: 1) по поддерживаемым методологиям проектирования: функционально 2) по поддерживаемым графическим нотациям построения диаграмм 3) по степени интегрированности: 4) по типу и архитектуре вычислительной техники: 5) по режиму коллективной разработки проекта: ; 6) по типу операционной системы (ОС): Функционально-ориентированное проектирование ЭИС Основными идеями функционально-ориентированной CASE-технологии являются идеи структурного анализа и проектирования информационных систем. Они заключаются в следующем: 1) декомпозиция всей системы на некоторое множество иерархически подчиненных функций; 2) представление всей информации в виде графической нотации. Систему всегда легче понять, если она изображена графически. В качестве инструментальных средств структурного анализа и проектирования выступают следующие диаграммы: Диаграммы функциональных спецификаций позволяют представить общую структуру ИС, отражающую взаимосвязь различных задач (процедур) в процессе получения требуемых результатов. Основными объектами BFD являются: • Функция - некоторое действие информационной системы, необходимое для решения экономической задачи; • Декомпозиция функции - разбиение функции на множество подфункций. Диаграммы потоков данных (ДПД) показывает внешние по отношению к системе источники данных и адресатов, которые принимают информацию от системы, а также идентифицируют хранилища данных (накопители данных), к которым осуществляется доступ системы. Каждая логическая функция системы (бизнес-функция) описывается своей ДПД. Причем эта ДПД может иерархически детализировать функцию на ее подфункции. Диаграммы переходов состояний (ДПС) моделируют поведение системы во времени в зависимости от происшедших событий (нажатая клавиша, дата отчетного периода и т.д.). Такие диаграммы позволяют осуществить декомпозицию управляющих процессов, происходящих в системе, и описать отношение между управляющими потоками. С помощью ДПС можно моделировать последующее функционирование системы исходя из предыдущих и текущего состояний. Диаграммы инфологических моделей «сущность-связь» (ER-диаграммы) ориентированы на разработку базы данных, структура которой не зависит от конкретных информационных потребностей и позволяет выполнять любые запросы пользователей. ERD-диаграмма «сущность-связь» представляет собой набор множества объектов и их характеристик, а также взаимосвязей между ними, нужных для выявленных данных, которые в дальнейшем используются функциями проектируемой системы. Диаграмма структуры программного приложения (SSD) задает взаимосвязь функций и программных модулей, которые их реализуют (меню, формы,отчеты и т.д.) Структура программного приложения (SSD) представляет собой иерархическую взаимосвязь программных модулей, которые реализует ИС SSD служит мостом для перехода от системных требований, которые отображены в предыдущих диаграммах (BFD, DFD, STD, ERD), к реализации информационной системы. Объектно-ориентированное проектирование ЭИС Структурная декомпозиция ИС на основе объектно-ориентированного подхода отличается от функционально-ориентированного подхода лучшей способностью отражать динамическое поведение системы в зависимости от возникающих событий. В этом плане модель проблемной области рассматривается как совокупность взаимодействующих во времени объектов. Тогда конкретный процесс обработки информации формируется в виде последовательности взаимодействий объектов. Одна операция обработки данных может рассматриваться как результат одного взаимодействия объектов. В настоящее время для объектно-ориентированного моделирования проблемной области широко используется унифицированный язык моделирования UML (Unified Modeling Language), Система объектно-ориентированных моделей в соответствии с нотациями UML включает в себя следующие диаграммы: 1) диаграмму прецедентов использования (Use-case diagram), которая отображает функциональность ЭИС в виде совокупности выполняющихся последовательностей транзакций; 2) диаграмму классов объектов (Class diagram), которая отображает структуру совокупности взаимосвязанных классов объектов аналогично ER-диаграмме функционально-ориентированного подхода; 3) диаграммы состояний (Statechart diagram), каждая из которых отображает динамику состояний объектов одного класса и связанных с ними событий; 4) диаграммы взаимодействия объектов (Interaction diagram), каждая из которых отображает динамическое взаимодействие объектов в рамках одного прецедента использования; 5) диаграммы деятельностей (Activity diagram), которые отображают потоки работ во взаимосвязанных прецедентах использования (могут декомпозироваться на более детальные диаграммы); 6) диаграммы пакетов (Package diagram), которые отображают распределение объектов по функциональным или обеспечивающим подсистемам (могут декомпозироваться на более детальные диаграммы); 7) диаграмму компонентов (Component diagram), которая отображает физические модули программного кода; 8) диаграмму размещения (Deployment diagram), которая отображает распределение объектов по узлам вычислительной сети. RAD (от англ. rapid application development — быстрая разработка приложений) — концепция создания средств разработки программных продуктов, уделяющая особое внимание быстроте и удобству программирования, созданию технологического процесса, позволяющего программисту максимально быстро создавать компьютерные программы Достоинство: Значительное снижение объема доработок ИС при ее внедрении, который для традиционных методов проектирование, соразмерен с затратами на первоначальную реализацию |
61. Информационное обеспечение автоматизированных информационных систем Основной принцип создания информационного обеспечения (ИО) — решение задачи удовлетворения информационных потребностей пользователя и (или) системы управления объектом (производством.) При решении этих задач осуществляется: • накопление информации; • обмен информацией; • обработка информации; • управление данными; • формализация данных и знаний. Создание ИО проходит следующие этапы: • исследование информационных потоков; • разработка системы классификации и кодирования; • разработка унифицированных форм представления данных в информационной базе; • накопление массивов данных и работа с ними. На предпроектной стадии разработки АС на основании технико-экономического обоснования разрабатывается техническое задание (ТЗ) на создание системы. В ТЗ определяются принципы ее построения, организационная и функциональная структура, требования к обеспечивающим подсистемам, в том числе к ИО. Информационное обеспечение определяет размещение и формы организации информации в системе, представляя собой совокупность методов и средств построения и реализации информационной базы. ИО реализуется как: I. Внешнее (немашинное) ИО, которое, однако, должно учитывать принципы автоматизации информационных процессов. Его состав: • система классификации и кодирования; • нормативно-справочные документы; • оперативные документы; • методические и инструктивные материалы. Движение этих документов реализуется в соответствии с организационной структурой управления. II. Внутримашинное ИО включает: • информационные массивы, составляющие информационную базу системы; • пакеты программ. ИО реализуется в виде банков данных и банков знаний, в основе построения которых — модели накопления данных и представления знаний. Эти процессы должны быть формализованы на концептуальном и логическом уровнях.
Традиционно, в соответствии с ГОСТ 34.03-90, информационное обеспечение рассматривалось как «совокупность форм документов, классификаторов, нормативной базы и реализованных решений по объемам, размещению и формам существования информации, применяемой в АС при ее функционировании». Таким образом, информационное обеспечение АИС включало три составляющих: единую систему классификации и кодирования информации, унифицированные системы документации и массивы информации. Лингвистическое обеспечение рассматривалось как «совокупность средств и правил для формализации естественного языка, используемых при общении пользователей и эксплуатационного персонала АС с комплексом средств автоматизации при функционировании АС». Лингвистическое обеспечение АИС включало две составляющих: лексическую (словарную) базу и языковые средства. В настоящее время информационное обеспечение рассматривается как совокупность собственно информационного и лингвистического обеспечения. При этом под собственно информационным обеспечением понимают файлы операционной системы и базы данных, а под лингвистическим — форматную базу, лексическую базу и языковые средства. Поэтому можно сформулировать: Информационное обеспечение АИС — это совокупность баз данных и файлов операционной системы, форматной и лексической баз, а также языковых средств, предназначенных для ввода, обработки, поиска и представления информации в форме, необходимой потребителю. Информационное обеспечение делят на немашинное и машинное. К первому относят классификаторы технико-экономической информации, нормативно-справочную информацию. Ко второму относят БД, СУБД. Это деление довольно условное, так как первый вид обеспечения можно вести и на ЭВМ.
|
|