Министерство образования и науки Российской Федерации Владивостокский государственный университет экономики и сервиса
реклама
Министерство образования и науки Российской Федерации Владивостокский государственный университет экономики и сервиса Кафедра информационных систем и прикладной информатики С.Л. БЕДРИНА О.Б. БОГДАНОВА КУРСОВОЕ ПРОЕКТИРОВАНИЕ 1 в р и а т Институт информатики, инноваций и бизнес-систем а Рабочая программа учебной дисциплины 230700.62 (09.09.03) ПРИКЛАДНАЯ ИНФОРМАТИКА 230400.62 (09.03.02) ИНФОРМАЦИОННЫЕ СИСТЕМЫ И ТЕХНОЛОГИИ Б а к а л Основная образовательная программа Владивосток Издательство ВГУЭС 2014 ББК 32.973/2-018 Рабочая программа по курсовому проектированию составлена в соответствии с требованиями ООП 230700.62 (09.03.03) Прикладная информатика, 230400.62 (09.03.03) Информационные системы и технологии на базе ФГОС ВПО. Авторы-составители: Бедрина С.Л., канд. экон. наук, доцент кафедры информационных систем и прикладной информатики; О.Б. Богданова, ст. преподаватель кафедры информационных систем и прикладной информатики Утверждена на заседании кафедры информационных систем и прикладной информатики от 19.03.14 г., протокол № 9 Рекомендована к изданию учебно-методической комиссией Института информатики, инноваций и бизнес-систем © Издательство Владивостокского государственного университета экономики и сервиса, 2014 ВВЕДЕНИЕ Проектирование программных средств и баз данных – это логически сложная, трудоемкая и длительная работа, требующая высокой квалификации, участвующих в ней специалистов. Однако до настоящего времени проектирование выполнялось на интуитивном уровне неформализованными методами, включающими в себя элементы искусства, практический опыт и экспертные оценки. С появлением программной инженерии процесс проектирования стал носить формальный систематический характер, который представляет собой совокупность методов и средств создания программного обеспечения и баз данных. Основная доля трудозатрат при создании информационных систем приходится на программное обеспечение (ПО) и базы данных (БД). В связи с этим большую актуальность приобретает освоение принципов построения и эффективного применения соответствующих технологий и программных продуктов: систем управления базами данных (СУБД), CASE-систем автоматизации проектирования, средств администрирования и защиты баз данных и других. Поскольку использование баз данных является неотъемлемой частью любой информационной системы, на которых построено существование различных организаций, пристальное внимание разработчиков приложений баз данных вызывают инструменты, при помощи которых такие приложения можно было бы создавать. Выдвигаемые к ним требования: «быстрота, простота, эффективность, надежность». Среди большого разнообразия продуктов для разработки приложений Delphi занимает одно из ведущих мест. Приложения с помощью Delphi разрабатываются быстро в удобной для пользователя интерактивной среде. Для разработки приложений небольших баз данных наиболее популярной средой разработки является MS Access. Предлагаемое пособие дает возможность студенту освоить современные методы и средства проектирования программного обеспечения и баз данных, основанных на использовании CASE-технологий при выполнении Курсового проектирования 1. В предлагаемой работе содержатся варианты индивидуальных заданий для студентов и рассматривается пример разработки ПС и базы данных для выбранной предметной области, который поможет лучше овладеть методами разработки ПС и БД. 3 1. ОРГАНИЗАЦИОННО-МЕТОДИЧЕСКИЕ УКАЗАНИЯ 1.1. Цели и задачи курсового проектирования 1 Целью выполнения курсового проектирования 1 является закрепление основ и углубление знаний принципов и приемов проектирования программного обеспечения и баз данных для предприятий и вуза, приобретение практических навыков в решении прикладных задач, а также развитие навыков самостоятельной работы по анализу предметной области проектирования, разработке бизнес-моделей и моделей баз данных. В ходе выполнения курсового проектирования 1 у студента должно формироваться представление об этапах проектирования как программных средств, так и баз данных в соответствии с ГОСТ Р ИСО/МЭК 12207-99. В ходе достижения цели решаются следующие задачи: развитие логического и алгоритмического мышления; изучение принципов работы прикладного программного обеспечения; освоение инструментальных средств для моделирования предметной области, баз данных; проведение анализа существующих или возможных решений поставленной задачи с кратким обзором литературных источников; выработка умения самостоятельного решения задач по анализу информации и выбору метода ее обработки; освоение методов проектирования баз данных и работы с базами данных в среде конкретной СУБД; получение навыков в разработке прикладных программ; программировании и отладке программ, а также тестировании создаваемых программных модулей; изучение перспектив развития технологий создания ПО. 1.2. Место курсового проектирования 1 в структуре ООП (связь с другими дисциплинами) Для изучения дисциплины студенту необходимы знания, владения и умения, полученные в курсах: «Информационные системы и технологии», «Информатика и программирование», «Математическая логика», «Программирование на языке высокого уровня», «Реинжиниринг бизнес-процессов», «Программная инженерия», «Базы данных», «Базы 4 данных продвинутый курс». Вместе с тем такие личностные характеристики как общая образованность, организованность и трудолюбие, самостоятельность, настойчивость в достижении цели необходимы при освоении дисциплины. 1.3. Компетенции обучающегося, формируемые в результате освоения учебной дисциплины В результате освоения дисциплины у обучающегося должны быть сформированы компетенции. Формируемые компетенции «Курсовое проектирование 1». 230400.62 (09.03.02) Информационные системы и технологии Профессиональные: ПК-1 способность проводить предпроектное обследование объекта проектирования, системный анализ предметной области, их взаимосвязей ПК-2 способность проводить техническое проектирование ПК-11 способность к проектированию базовых и прикладных информационных технологий ПК-12 способность разрабатывать средства реализации информационных технологий (методические, информационные, математические, алгоритмические, технические и программные) ПК-13 способность разрабатывать средства автоматизированного проектирования информационных технологий ПК-23 способность проводить сбор, анализ научно-технической информации, отечественного и зарубежного опыта по тематике исследования ПК-27 способность оформлять полученные рабочие результаты в виде презентаций, научно-технических отчетов, статей и докладов на научно-технических конференциях 5 Формируемые компетенции «Курсовое проектирование 1». 230700.62 (09.03.03) Прикладная информатика. Прикладная информатика Профессиональные ПК-3 способен использовать основные законы естественнонаучных дисциплин в профессиональной деятельности и эксплуатировать современное электронное оборудование и информационно-коммуникационные технологии в соответствии с целями образовательной программы бакалавра ПК-6 способен документировать процессы создания информационных систем на всех стадиях жизненного цикла ПК-7 способен использовать технологические и функциональные стандарты, современные модели и методы оценки качества и надежности при проектировании, конструировании и отладке программных средств ПК-8 способен проводить обследование организаций, выявлять информационные потребности пользователей, формировать требования к информационной системе, участвовать в реинжиниринге прикладных и информационных процессов ПК-9 способен моделировать и проектировать структуры данных и знаний, прикладные и информационные процессы ПК-10 способен применять к решению прикладных задач базовые алгоритмы обработки информации, выполнять оценку сложности алгоритмов, программировать и тестировать программы ПК-16 способен оценивать и выбирать современные операционные среды и информационно-коммуникационные технологии для информатизации и автоматизации решения прикладных задач и создания ИС ПК-17 способен применять методы анализа прикладной области на концептуальном, логическом, математическом и алгоритмическом уровнях ПК-19 способен анализировать рынок программно-технических средств, информационных продуктов и услуг для решения прикладных задач и создания информационных систем ПК-22 способен готовить обзоры научной литературы и электронных информационно-образовательных ресурсов для профессиональной деятельности 6 В результате освоения дисциплины у обучающегося должны быть сформированы знания, умения, владения. ООП Коды компетенций Составляющие компетенции 1 2 3 230400.62, ИНФОРМАЦИОННЫЕ СИСТЕМЫ И ТЕХНОЛОГИИ. Информационные системы и технологии общую характеристику процесса предпроектного обследования объекта ПК-1 Знания ПК-2 методами и средствами представления данных и знаний о предметной области, методами и средствами анализа информационных систем, технологиями реализации, внедрения проекта Владения информационной системы функциональные и технологические стандарты разработки программных комплексов современными программными средствами для проектирования программного обеспечения, основанным на использовании CASE-технологии ПК-11 Умения использовать информационные технологии для решения различных прикладных задач в профессиональной деятельности ПК-12 Владения средствами реализации информационных технологий ПК-13 Умения формулировать требования к создаваемым программным комплексам ПК-18 Умения самостоятельно решать задачи по анализу информации и выбору метода ее обработки ПК-23 Знания основы методики сбора научно-технической информации ПК-27 Знания принципы оформления результатов сбора, передачи, поиска накопленной информации ПК-27 Знания методы и средства проектирования БД, особенности администрирования БД в локальных 7 и глобальных сетях 8 1 2 3 ОК-7 Владения навыками работы с источниками и поставщиками информационных ресурсов ОК-9 Умения работать в пакетах прикладных программ с англоязычным интерфейсом ПК-3 Владения навыками работы с различными информационно-коммуникационными технологиями ПК-5 Владения навыками выбора проектных решений по видам обеспечения информационных систем правила оформления проектной документации Знания ПК-6 230700.62, ПРИКЛАДНАЯ ИНФОРМАТИКА. Прикладная информатика состав и структуру технологической и технической документации на всех стадиях жизненного цикла Умения формулировать требования к создаваемым программным комплексам Владения навыками разработки технологической документации использовать международные и отечественные стандарты Умения ПК-7 использовать технологические и функциональные стандарты при проектировании, конструировании и отладке программных средств навыками проектирования, конструирования Владения и отладки программных средств в соответствии со стандартами Знания методы анализа прикладной области, информационных потребностей, формирования требований к ИС технологии реинжиниринга прикладных и информационных процессов ПК-8 выступать постановщиком задач и создавать информационную модель предприятия Умения проводить анализ предметной области, выявлять информационные потребности и разрабатывать требования к ИС 9 1 2 3 навыками выявления потребности организации в автоматизации ее деятельности и формирования требований к информационной Владения системе навыками построения моделей прикладных и информационных процессов организации методологию проектирования прикладных и информационных процессов Знания методы и средства проектирования БД, особенности администрирования БД в локальных и глобальных сетях модели данных системы управления БД и информационными хранилищами 230700.62, ПРИКЛАДНАЯ ИНФОРМАТИКА. Прикладная информатика ПК-9 Умения моделировать и проектировать прикладные и информационные процессы навыками работы с инструментальными средствами моделирования предметной области, прикладных и информационных процессов Владения навыками работы с инструментальными средствами проектирования баз данных и знаний, управления проектами ИС и защиты информации навыками разработки программных комплексов для решения прикладных задач, оценки сложности алгоритмов и программ, использоПК-10 Владения вания современных технологий программирования, тестирования и документирования программных комплексов Знания принципы организации проектирования и содержание этапов процесса разработки программных комплексов Умения формировать архитектуру программных комплексов для информатизации предприятий, разрабатывать программные приложения ПК-11 10 1 2 3 ПК-16 Умения Умения 230700.62, ПРИКЛАДНАЯ ИНФОРМАТИКА. Прикладная информатика ПК-17 Владения Знания ПК-19 формировать архитектуру программных комплексов для информатизации предприятий, разрабатывать программные приложения выбирать и применять различные нотации моделирования навыками анализа прикладной области на различных уровнях навыками моделирования ПО методами структурно-функционального анализа методы анализа рынка программно-технических средств, информационных продуктов и услуг, критерии выбора программного обеспечения методами анализа рынка программно-техниВладения ческих средств, информационных продуктов и услуг, навыками выбора поставщиков ИТ основами работы с научно-технической литеПК-22 Владения ратурой и технической документацией по программному обеспечению ПЭВМ 1.4. Основные виды занятий и особенности их проведения Объем и сроки изучения дисциплины: Для студентов третьего курса направления «Прикладная информатика» и «Информационные системы и технологии» курс «Курсовое проектирование 1» проводится в осеннем и весеннем семестрах. Общая трудоемкость дисциплины составляет 2 зачетные единицы: 36 часов самостоятельной работы в осеннем семестре, 36 часов самостоятельной работы в весеннем семестре. Промежуточная аттестация по курсу: в осеннем семестре – зачет, в весеннем – зачет с оценкой. 11 1.5. Техническое и программное обеспечение для выполнения курсовой работы Для выполнения курсового проектирования 1 необходимо наличие персонального компьютера не менее Pentium III-500МГц с оперативной памятью не менее 96 Мбайт и памятью на жестком диске 8 Гбайт и выше. На персональных компьютерах должно быть установлено следующее программное обеспечение: операционная система Windows 2000 и выше, СУБД MS Access 2000 и выше, среда визуального программирования Delphi 7.0 и выше, а также инструментальные средства, входящие в пакет AllFusion Modeling Suite: AllFusion Process Modeler 4.1 (BPWin 4.1) AllFusion ERWin Data Modeler 4.1 (ERWin 4.1). 1.6. Виды контроля и отчетности по дисциплине Проверяется все заявленное в п. 1.3. Проверка курсовой работы осуществляется поэтапно, согласно графика учебного процесса и проводимых в университете промежуточных аттестаций. В ходе выполнения курсового проектирования 1 рекомендуется придерживаться календарного плана. Календарный план курсового проектирования Этап выполнения работы Продолжительность этапа Семестр 5 1. Анализ предметной области 6 недели 2. Анализ проблемы 6 недели 3. Реинжиниринг бизнес-процессов 5 недели Семестр 6 4. Постановка задачи 1 недели 5. Проектирование 6 недели 6. Реализация 9 недели 7. Защита курсовой работы 1 12 В осеннем семестре результаты предпроектного исследования, оформленные в виде отчета, представляются руководителю для проверки. После проверки руководителем, проводится его защита в форме собеседования перед комиссией. Для аттестации студент должен предоставить: • файлы разработанных моделей (AS-IS, TO-BE); • отчет. В весеннем семестре в установленные сроки готовый курсовой проект должен быть сдан для проверки на кафедру «Информационных систем и прикладной информатики». Проверенная курсовая работа должна быть защищена студентом с учетом высказанных замечаний После проверки и устранения замечаний проводится защита курсового проекта. Защита курсового проекта осуществляется перед комиссией. Доклад студента должен сопровождаться презентацией результатов проектирования, подготовленной в среде PowerPointи демонстрацией работы программного приложения. Для аттестации студент должен предоставить: • файл разработанной базы данных; • разработанное приложение; • пояснительную записку к проекту. 13 2. МЕТОДИЧЕСКИЕ РЕКОМЕНДАЦИИ ПО ВЫПОЛНЕНИЮ КУРСОВОЙ РАБОТЫ 2.1. Требования к выполнению курсового проектирования 1 В качестве объекта исследования в курсовом проекте может быть выбран любой хозяйствующий субъект. В то же время следует отдать предпочтение тому предприятию, организации или фирме, на которой студент может получить работу после окончания университета. Следующим приоритетом может быть предприятие, организация или фирма, которая станет объектом дипломного проектирования. В курсовом проекте могут быть рассмотрены темы, которые условно можно подразделить на следующие типы: 1 – темы, отражающие комплекс вопросов деятельности предприятия, организации или фирмы в целом; 2 – темы, отражающие отдельные экономические и организационные стороны деятельности предприятия, организации или фирмы. Тема курсового проекта выбирается студентом самостоятельно из примерной тематики, приведенной в пункте 3 данного руководства, с учетом особенности направления подготовки, по которому учится студент, и мест прохождения студентом практики. Выбранная тема согласовывается с научным руководителем. Студент на основании имеющейся информации может предложить тему, не входящую в рекомендованный перечень, но являющуюся актуальной для предприятия, организации или фирмы. При этом необходимо учитывать возможность получения соответствующей информации, необходимой для оценки состояния рассматриваемых вопросов на предприятии, а также наличие научной литературы и других источников информации, посвященной проблематике курсового проекта. Студент должен собрать и обработать необходимую информацию, проверить ее достоверность и согласованность. 14 2.2. Порядок выполнения курсовой работы Порядок выполнения курсового проектирования 1 должен содержать следующие этапы работы: I. Предпроектное исследование 1 Анализ предметной области (предприятия, подразделения, сферы деятельности) Проектирование начинается с исследования предметной области для которой решается задача. Цели этапа: а) исследовать бизнес-процессы предприятия Исходной информацией для этого являются: а) регламенты работы отделов и должностные инструкции сотрудников этих отделов; б) интервью с работниками предприятия; в) другие документы, имеющие отношение к исследуемому объекту. Выходными данными, или результатом, этапа являются: а) модель бизнес-процессов (контекстный уровень) 2 Анализ проблемы На этапе анализа проблемы проводится анализ проблемы, для которой разрабатывается ПО. Цели этапа: а) определение границ, или контура, системы; б) описание объектов автоматизации и/или формализации знаний об этих объектах; в) выявление или определение потребностей заказчика ПО. Исходными данными для этапа являются: а) существующие программы, методы и средства, позволяющие решить данную проблему б) анкеты опроса заинтересованных лиц; в) записи интервью с заинтересованными лицами; г) другие документы, имеющие отношение к исследуемому объекту. Выходными данными, или результатом, этапа являются: а) анализ литературы, посвященный исследуемой проблеме; б) перечень заинтересованных лиц; в) список потребностей заинтересованных лиц в разрабатываемом ПО; г) уточненная и расширенная модель бизнес-процессов (AS-IS) 3 Реинжиниринг бизнес-процессов На этапе совершенствования и реинжиниринга проводится анализ, построенной модели (AS-IS). Цель этапа: а) выделить бизнес-процесс (функциональные блоки) для проведения реинжиниринга (автоматизации и реорганизации бизнес-процессов); 15 б) реорганизация бизнес-процессов предметной области. Исходными данными для этапа являются: а) модель бизнес-процессов предметной области (AS-IS) Выходными данными, или результатом, этапа являются: а) модифицированная модель бизнес-процессов (TO-BE) II. Проектирование и реализация 4 Постановка задачи Цель этапа: Формулировка задачи для разработки программного обеспечения и базы данных. Исходными данными для этапа являются: а) модель бизнес-процессов (TO-BE) Выходными данными, или результатом, этапа являются: а) Постановка задачи для разработки программного и информационного обеспечения задачи. 5 Проектирование 2.1. Разработка программного обеспечения Цель этапа Формирование архитектуры и алгоритмов модулей программы Исходными данными для этапа являются: а) модель бизнес-процессов (TO-BE) Выходными данными, или результатом, этапа являются: а) Модель архитектуры программы в нотации DFD; б) схема вызова модулей и процедур задачи. в) интерфейс системы (дерево диалога, диаграмма последовательности экранных форм). г) тестовые наборы данных 2.2. Разработка информационного обеспечения Цель этапа Формирование инфологической и даталогической моделей предметной области. Исходными данными для этапа являются: а) Модель архитектуры программы в нотации DFD; Выходными данными, или результатом, этапа являются: а) требования к БД б) концептуальную модель данных в) ERD-диаграмму. г) реляционную модель БД приведенная к соответствующей нормальной форме. 3. Реализация Цель этапа: Разработка приложения для работы с базой данных Исходными данными для этапа являются: а) реляционная модель БД 16 б) схема программных модулей и их детальные алгоритмы в) дерево диалога г) тестовые наборы Выходными данными, или результатом, этапа являются: а) база данных; б) программный код для реализации задачи. 2.3. Объем и содержание курсовой работы Курсовая работа выполняется в форме базы данных, моделей проектирования системы и пользовательского приложения, выполненного в среде Delphi или MS Access, и пояснительной записки к работе, которая должна иметь следующую структуру. Аннотация Содержание 1 Предметная область автоматизации 1.1 Документы предметной области, содержащие информацию, необходимую для решения задачи 1.2 Описание предметной области и функции решаемой задачи 1.2.1 Описание модели AS-IS 1.2.2 Выводы по автоматизации и реорганизации 1.2.3 Описание расширенной модели TO-BE, полученной после проектирования. 2 Постановка задачи 2.1 Организационно-экономическая сущность задачи 2.2 Описание выходной информации 2.3 Описание входной информации 3 Информационное обеспечение задачи 3.1 Информационный анализ предметной области и выделение информационных объектов задачи (концептуальная модель) 3.2 Определение логической структуры реляционной базы данных (ERD-модель) 3.3 Описание тестовых наборов 4 Архитектура системы 4.1 Структурная схема программы 5 Детальные алгоритмы реализации отдельных модулей задачи 6 Интерфейс системы 7 Технология решения задачи (функционально-технологические схемы) 7.1 Технология ввода, накопления и обработки данных, обеспечивающая решение задачи. 7.2 Технология осуществления запросов их реализация. 17 7.3 Технология получения отчетов и др. 8 Руководство пользователя Заключение Список используемых источников Приложение В аннотации в краткой и сжатой форме излагается содержание курсовой работы. В содержании представляется структура работы в соответствии с выбранной темой. Указывается страница, с которой начинается каждый пункт. В первом разделе в соответствии с выбранной темой индивидуального задания дается характеристика предметной области, согласно построенных бизнес-моделей. Второй раздел пояснительной записки содержит постановку задачи, описание входных и выходных документов с обязательным приведением форм этих документов. Третий раздел посвящен информационному обеспечению задачи, где описываются разработанные концептуальная и логическая модели базы данных, а также приводятся тестовые наборы. Четвертый раздел содержит описание модульной структуры созданного приложения в виде схемы модулей и алгоритмов для каждого из них. Алгоритмы должны соответствовать спецификациям DFD модели. Описание интерфейса системы в виде дерева диалога (форм ввода – вывода) должно быть представлено в пятом разделе В шестом разделе должна быть представлена функциональнотехнологическая схема решения задачи в соответствии с ГОСТ 19.70190 ЕСПД. Седьмым разделом является разработанное руководство пользователя, которое должно включать в себя описание функционального назначения программы, процесса ее установки, основных технологических операций и возможных ошибок в разработанной системе. В заключении содержатся выводы по выполненной работе и приводится оценка системы с точки зрения возможности ее дальнейшего развития. В качестве Приложения к пояснительной записке должны быть представлены код программы, формы, входные и выходные документы. 18 2.4. Методические рекомендации по использованию инструментальных средств Создание моделей бизнес-процессов с AllFusion Process Modeler 4.1 (BPwin 4.1) 2.4.1. Инструментальная среда Bpwin 4.1 Общее описание интерфейса Bpwin 4.1 Bpwin имеет достаточно простой и интуитивно понятный интерфейс пользователя, дающий возможность аналитику создавать сложные модели при минимальных усилиях. При запуске Bpwin по умолчанию появляется основная панель инструментов, палитра инструментов (вид которой зависит от выбранной нотации) и, в левой части, навигатор модели – Model Explorer (рис. 1). Рис. 1. Интегрированная среда разработки модели Bpwin 4.1 Функциональность панели инструментов доступна из основного меню Bpwin (табл. 1). 19 Таблица 1 Описание элементов управления основной панели инструментов Bpwin 4.1 Элемент управления Описание Соответствующий пункт меню Создать новую модель File/New Открыть модель File/Open Сохранить модель File/Save Напечатать модель File/Print Вызвать генератор отчетов Report Builder Tools/Report Builder Выбор масштаба View/Zoom Масштабирование View/Zoom Проверка правописания Tools/Spelling Включение и выключение навигатора модели Model Explorer View/Model Explorer Включение и выключение дополнительной ModelMart панели инструментов работы с ModelMart Создание новой модели При создании новой модели возникает диалог, в котором следует указать, будет ли создана модель заново, или она будет открыта из файла либо из хранилища ModelMart, внести имя модели и выбрать методологию, в которой будет построена модель (рис. 2). Как было указано выше, BPwin поддерживает три методологии – IDEF0, IDEF3 и DFD, каждая из которых решает свои специфические задачи. В BPwin возможно построение смешанных моделей, т. е. модель может содержать одновременно как диаграммы IDEF0, так и диаграммы IDEF3 И DFD. Состав палитры инструментов изменяется автоматически, когда происходит переключение с одной нотации на другую, поэтому палитра инструментов будет рассмотрена позже. 20 Рис. 2. Диалог создания модели После щелчка по кнопке ОК появляется диалог Properties for New Models (рис. 3), в который следует внести свойства модели. Рис. 3. Диалог Properties for New Models 21 Модель в BPwin рассматривается как совокупность работ, каждая из которых оперирует некоторым набором данных. Работа изображается в виде прямоугольников, данные – в виде стрелок. Если щелкнуть по любому объекту модели левой кнопкой мыши, появляется всплывающее контекстное меню, каждый пункт которого соответствует редактору какого-либо свойства объекта. Установка цвета и шрифта объектов Пункты контекстного меню Font и Color вызывают диалог Arrow Properties или Activity Properties для установки шрифта (в том числе его размера и стиля) и цвета объекта. В нижней части вкладки Font диалогов Arrow Properties и Activity Properties (рис. 4) находятся группа опций Apply setting to, позволяющих изменить шрифт для всех работ или стрелок на текущей диаграмме, в модели, и группа Global, позволяющая изменить шрифт одновременно для всех объектов модели. Рис. 4. Вкладка Font диалога Activity Properties 22 Кроме того, BPwin позволяет установить шрифт по умолчанию для объектов определенного типа на диаграммах и в отчетах. Для этого следует выбрать меню Model/Default Fonts, после чего появляется следующее каскадное меню, каждый пункт которого служит для установки шрифтов для определенного типа объектов: Context Activity – работа на контекстной диаграмме; Context Arrow – стрелки на контекстной диаграмме; Decomposition Activity – работы на диаграмме декомпозиции; Decomposition Arrow – стрелки на диаграмме декомпозиции; Node Tree Text – текст на диаграмме дерева узлов; Frame User Text – текст, вносимый пользователем в каркасе диаграмм; Frame System Text – системный текст в каркасе диаграмм; Text Blocks – текстовые блоки; Parent Diagram Text – текст родительской диаграммы; Parent Diagram Title Text – текст заголовка родительской диаграммы; Report Text – текст отчетов. Если на компьютере установлена операционная система Windows NT, возможно некорректное отображение на диаграммах кириллических шрифтов. Для корректной работы BPwin необходимо отредактировать регистры NT. В разделе HKEYJ-OCAL_MACHINE SOFTWARE Microsoft WindowsNT CurrentWersion FontMapper следует установить 204-ю таблицу – DEFAULT OXOOOOOOcc (204). В разделе HKEY_LOCAL_MACHINE SOFTWARE Microsoft WindowsNT CurrentWersion FontSubstitutes следует для всех стандартных шрифтов установить ссылку на 204-ю таблицу, например: Arial.O "Arial,204" 23 Model Explorer – навигатор модели процессов Инструмент навигации Model Explorer имеет три вкладки – Activities, Diagrams и Objects. Вкладка Activities (рис. 5) показывает в виде раскрывающегося иерархического списка все работы модели. Одновременно могут быть показаны все модели, открытые в BPwin. Работы с диаграмм IDEF0 показываются зеленым цветом, IDEF3 – желтым и DFD – голубым. Рис. 5. Вкладка Activities навигатора Model Explorer Щелчок по работе во вкладке Activity переключает левое окно BPwin на диаграмму, на которой эта работа размещена. Для редактирования свойств работы следует щелкнуть по ней правой кнопкой мыши. Появляется контекстное меню. В табл. 2 приведено значение пунктов меню. 24 Таблица 2 Контекстное меню редактирования свойств работы Пункт меню Описание Insert Before Создать новую работу на той же самой диаграмме. В списке работ новая работа будет вставлена перед текущей Insert After Создать новую работу на той же самой диаграмме. В списке работ новая работа будет вставлена после текущей Decompose Декомпозировать работу. В результате будет создана новая диаграмма декомпозиции Name Вызов редактора имени работы Definition/ Вызов редактора определения и примечания к работе Note Font Изменения шрифта работы Color Изменения цвета работы Costs Задание стоимости работы Data Usage Ассоциация работы с данными UDP Задание свойств, определяемых пользователем UOW Задание свойств для работ IDEF3 Если с помощью вкладки Activities можно перейти на стандартные диаграммы (контекстную и декомпозиции), то вторая вкладка – Diagrams (рис. 6) – служит для перехода на любую диаграмму модели. 25 Рис. 6. Вкладка Diagrams навигатора Model Explorer После перехода на вкладку Objects на ней показываются все объекты, соответствующие выбранной на вкладке Diagrams диаграмме, в том числе работы, хранилища данных, внешние ссылки, объекты ссылок и перекрестки (рис. 7). 26 Рис. 7. Вкладка Objects навигатора Model Explorer 2.4.2. Создание модели в стандарте IDEF0 Принципы построения модели IDEF0 На начальных этапах создания ИС необходимо понять, как работает организация, которую собираются автоматизировать. Для описания работы предприятия необходимо построить модель. Такая модель должна быть адекватна предметной области; следовательно, она должна содержать в себе знания всех участников бизнес-процессов организации. Наиболее удобным языком моделирования бизнес-процессов является IDEF0, предложенный более 20 лет назад Дугласом Россом (SoftTech, Inc.) и называвшийся первоначально SADT – Structured Analysis and Design Technique. (Подробно методология SADT излагается в книге Дэвида А. Марка и Клемента Мак-Гоуэна "Методология структурного анализа и проектирования SADT" (М.: Метатехнология, 1993.) 27 В начале 70-х годов вооруженные силы США применили подмножество SADT, касающееся моделирования процессов, для реализации проектов в рамках программы ICAM (Integrated Computer-Aided Manufacturing). В дальнейшем это подмножество SADT было принято в качестве федерального стандарта США под наименованием IDEF0. В IDEF0 система представляется как совокупность взаимодействующих работ или функций. Такая чисто функциональная ориентация является принципиальной – функции системы анализируются независимо от объектов, которыми они оперируют. Это позволяет более четко смоделировать логику и взаимодействие процессов организации. Под моделью в IDEF0 понимают описание системы (текстовое и графическое), которое должно дать ответ на некоторые заранее определенные вопросы. Моделируемая система рассматривается как произвольное подмножество Вселенной. Произвольное потому, что, во-первых, мы сами умозрительно определяем, будет ли некий объект компонентом системы, или мы будем его рассматривать как внешнее воздействие, и, вовторых, оно зависит от точки зрения на систему. Система имеет границу, которая отделяет ее от остальной Вселенной. Взаимодействие системы с окружающим миром описывается как вход (нечто, что перерабатывается системой), выход (результат деятельности системы), управление (стратегии и процедуры, под управлением которых производится работа) и механизм (ресурсы, необходимые для проведения работы). Находясь под управлением, система преобразует входы в выходы, используя механизмы. Процесс моделирования какой-либо системы в IDEF0 начинается с определения контекста, т.е. наиболее абстрактного уровня описания системы в целом. В контекст входит определение субъекта моделирования, цели и точки зрения на модель. Под субъектом понимается сама система, при этом необходимо точно установить, что входит в систему, а что лежит за ее пределами; другими словами, мы должны определить, что мы будем в дальнейшем рассматривать как компоненты системы, а что как внешнее воздействие. На определение субъекта системы будет существенно влиять позиция, с которой рассматривается система, и цель моделирования – вопросы, на которые построенная модель должна дать ответ; другими словами, первоначально необходимо определить область (Scope) моделирования. Описание области как системы в целом, так и ее компонентов является основой построения модели. Хотя предполагается, что в течение моделирования область может корректироваться, она должна быть в основном сформулирована изначально, поскольку именно область определяет 28 направление моделирования и когда должна быть закончена модель. При формулировании области необходимо учитывать два компонента – широту и глубину. Широта подразумевает определение границ модели – мы определяем, что будет рассматриваться внутри системы, а что снаружи. Глубина определяет, на каком уровне детализации модель является завершенной. При определении глубины системы необходимо не забывать об ограничениях времени – трудоемкость построения модели растет в геометрической прогрессии от глубины декомпозиции. После определения границ модели предполагается, что новые объекты не должны вноситься в моделируемую систему; поскольку все объекты модели взаимосвязаны, внесение нового объекта может быть не просто арифметической добавкой, но в состоянии изменить существующие взаимосвязи. Внесение таких изменений в готовую модель является, как правило, очень трудоемким процессом (так называемая проблема "плавающей области"). Цель моделирования (Purpose). Модель не может быть построена без четко сформулированной цели. Цель должна отвечать на следующие вопросы: Почему этот процесс должен быть замоделирован? Что должна показывать модель? Что может получить читатель? Примерами формулирования цели могут быть следующие утверждения: "Идентифицировать и определить текущие проблемы, сделать возможным анализ потенциальных улучшений", "Идентифицировать роли и ответственность служащих для написания должностных инструкций", "Описать функциональность предприятия с целью написания спецификаций ИС" и т. д. Точка зрения (Viewpoint). Хотя при построении модели учитываются мнения различных людей, модель должна строиться с единой точки зрения. Точку зрения можно представить как взгляд человека, который видит систему в нужном для моделирования аспекте. Точка зрения должна соответствовать цели моделирования. IDEFO-модель предполагает наличие четко сформулированной цели, единственного субъекта моделирования и одной точки зрения. Для внесения области, цели и точки зрения в модели IDEF0 в BPwin следует выбрать пункт меню Model/Model Properties, вызывающий диалог Model Properties (рис. 8). Во вкладку Purpose следует внести цель и точку зрения, а во вкладку Definition – определение модели и описание области. 29 Рис. 8. Диалог задания свойств модели Во вкладке Status того же диалога можно описать статус модели (черновой вариант, рабочий, окончательный и т.д.), время создания и последнего редактирования (отслеживается в дальнейшем автоматически по системной дате). Во вкладке Source описываются источники информации для построения модели (например, "Опрос экспертов предметной области и анализ документации"). Вкладка General служит для внесения имени проекта и модели, имени и инициалов автора и временных рамок модели -AS-IS и ТО-ВЕ. Модели AS-IS и ТО-ВЕ. Целью построения функциональных моделей обычно является выявление наиболее слабых и уязвимых мест деятельности организации, анализ преимуществ новых бизнес-процессов и степени изменения существующей структуры организации бизнеса. Анализ недостатков и "узких мест" начинают с построения мо30 дели AS-IS (Как есть), т. е. модели существующей организации работы. Модель AS-IS может строиться на основе изучения документации (должностных инструкций, положений о предприятии, приказов, отчетов и т. п.), анкетирования и опроса служащих предприятия, создания фотографии рабочего дня и других источников. Полученная модель AS-IS служит для выявления неуправляемых работ, работ не обеспеченных ресурсами, ненужных и неэффективных работ, дублирующихся работ и других недостатков в организации деятельности предприятия. Исправление недостатков, перенаправление информационных и материальных потоков приводит к созданию модели ТО-ВЕ (Как будет) – модели идеальной организации бизнес-процессов. Как правило, строится несколько моделей ТО-ВЕ, среди которых определяют наилучший вариант. TO-BE’ AS-IS TO-BE 1 TO-BE 2 TO-BE 3 Рис. 9. Схема построения моделей "ТО-ВЕ" как результат анализа модели "AS-IS" Технология проектирования программного обеспечения ИС подразумевает сначала создание модели AS-IS, ее анализ и улучшение бизнес-процессов, т. е. создание модели ТО-ВЕ, и только на основе модели ТО-ВЕ строится модель данных, прототип и затем окончательный вариант ПО. Иногда текущая модель AS-IS и будущая ТО-ВЕ различаются очень сильно, так что переход от начального состояния к конечному становится неочевидным. В этом случае необходима третья модель, описывающая процесс перехода от начального к конечному состоянию системы, поскольку такой переход – это тоже бизнес-процесс. Результат описания модели можно получить в отчете Model Report. Диалог настройки отчета по модели вызывается из пункта меню Tools/Reports/Model Report. В диалоге настройки следует выбрать необходимые поля, при этом автоматически отображается очередность вывода информации в отчете (рис. 10). 31 Рис. 10. Отчет по модели 32 Диаграммы IDEF0. Основу методологии IDEF0 составляет графический язык описания бизнес-процессов. Модель в нотации IDEF0 представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм. Каждая диаграмма является единицей описания системы и располагается на отдельном листе. Модель может содержать четыре типа диаграмм: контекстную (в каждой модели может быть только одна контекстная диаграмма); декомпозиции; дерева узлов; только для экспозиции (FEO). Контекстная диаграмма является вершиной древовидной структуры диаграмм и представляет собой самое общее описание системы и ее взаимодействия с внешней средой. После описания системы в целом проводится разбиение ее на крупные фрагменты. Этот процесс называется функциональной декомпозицией, а диаграммы, которые описывают каждый фрагмент и взаимодействие фрагментов, называются диаграммами декомпозиции. После декомпозиции контекстной диаграммы проводится декомпозиция каждого большого фрагмента системы на более мелкие и т.д., до достижения нужного уровня подробности описания. После каждого сеанса декомпозиции проводятся сеансы экспертизы – эксперты предметной области указывают на соответствие реальных бизнес-процессов созданным диаграммам. Найденные несоответствия исправляются, и только после прохождения экспертизы без замечаний можно приступать к следующему сеансу декомпозиции. Так достигается соответствие модели реальным бизнес-процессам на любом уровне модели. Синтаксис описания системы в целом и каждого ее фрагмента одинаков во всей модели. Диаграмма дерева узлов показывает иерархическую зависимость работ, но не взаимосвязи между работами. Диаграмм деревьев узлов может быть в модели сколь угодно много, поскольку дерево может быть построено на произвольную глубину и не обязательно с корня. Диаграммы для экспозиции (FEO) строятся для иллюстрации отдельных фрагментов модели, для иллюстрации альтернативной точки зрения либо для специальных целей. Работа (Activity) Работы обозначают поименованные процессы, функции или задачи, которые происходят в течение определенного времени и имеют распознаваемые результаты. Работы изображаются в виде прямоугольников. Все работы должны быть названы и определены. Имя работы должно 33 быть выражено сочетанием отглагольного существительного, обозначающего процесс, например: "Изготовление детали", "Прием заказа" и т.д. Работа "Изготовление детали" может иметь, например, следующее определение: "Работа относится к полному циклу изготовления изделия от контроля качества сырья до отгрузки готового упакованного изделия". При создании новой модели (меню File/New) автоматически создается контекстная диаграмма с единственной работой, изображающей систему в целом (рис. 11). Рис. 11. Пример контекстной диаграммы Для внесения имени работы следует щелкнуть по работе правой кнопкой мыши, выбрать в меню Name и в появившемся диалоге внести имя работы. Для описания других свойств работы служит диалог Activity Properties (рис. 12). Диаграммы декомпозиции содержат родственные работы, т. е. дочерние работы, имеющие общую родительскую работу. Для создания диаграммы декомпозиции следует щелкнуть по кнопке . Возникает диалог Activity Box Count (рис. 13), в котором следует указать нотацию новой диаграммы и количество работ на ней. Остановимся пока на нотации IDEF0 и щелкнем на ОК. Появляется диаграмма декомпозиции (рис. 14). Допустимый интервал числа работ 2–8. Декомпозировать работу на одну работу не имеет смысла: диаграммы с количеством работ более восьми получаются перенасыщенными и плохо читаются. Для обеспечения наглядности и лучшего понимания моделируемых процессов рекомендуется использовать от 3 до 6 блоков на одной диаграмме. 34 Рис. 12. Редактор задания свойств работы Рис. 13. Диалог Activity Box Count Если оказывается, что количество работ недостаточно, то работу можно добавить в диаграмму, щелкнув сначала по кнопке на палитре инструментов, а затем по свободному месту на диаграмме. 35 Работы на диаграммах декомпозиции обычно располагаются по диагонали от левого верхнего угла к правому нижнему. Такой порядок называется порядком доминирования. Согласно этому принципу расположения в левом верхнем углу помещается самая важная работа или работа, выполняемая по времени первой. Далее вправо вниз располагаются менее важные или выполняемые позже работы. Такое расположение облегчает чтение диаграмм, кроме того, на нем основывается понятие взаимосвязей работ (см. ниже). Рис. 14. Пример диаграммы декомпозиции Каждая из работ на диаграмме декомпозиции может быть, в свою очередь, декомпозирована. На диаграмме декомпозиции работы нумеруются автоматически слева направо. Номер работы показывается в правом нижнем углу. В левом верхнем углу изображается небольшая диагональная черта, которая показывает, что данная работа не была декомпозирована. Так, на рис. 16 работа "Представление информации о ценах" имеет номер 1 и не была еще декомпозирована. Работа "Оформление заказов" (номер 2) имеет несколько уровней декомпозиции. Взаимодействие работ с внешним миром и между собой описывается в виде стрелок. Стрелки представляют собой некую информацию и обозначаются существительными (например, "Заготовка", Изделие", "Заказ") или именными сочетаниями (например, "Готовое изделие"). 36 Рис. 15. Пример диаграммы декомпозиции Стрелка (Arrow) В IDEF0 различают пять типов стрелок. Вход (Input) – материал или информация, которые используются или преобразуются работой для получения результата (выхода). Допускается, что работа может не иметь ни одной стрелки входа. Каждый тип стрелок подходит к определенной стороне прямоугольника, изображающего работу, или выходит из нее. Стрелка входа рисуется как входящая в левую грань работы. При описании технологических процессов (для этого и был придуман IDEF0) не возникает проблем определения входов. Действительно, "Сырье" на рис. 11 – это нечто, что перерабатывается в процессе "Изготовление изделия" для получения результата. При моделировании ИС, когда стрелками являются не физические объекты, а данные, не все так очевидно. Например, при "Приеме пациента" карта пациента может быть и на входе и на выходе, между тем качество этих данных меняется. Другими словами, в нашем примере для того, чтобы оправдать свое назначение, стрелки входа и выхода должны быть точно определены с тем, чтобы указать на то, что данные действительно были переработаны (например, на выходе – "Заполненная карта пациента"). Очень часто сложно определить, являются ли данные входом или управлением. В этом случае подсказкой может служить то, перерабатываются/изменяются ли данные в работе или нет. Если изменяются, то скорее всего это вход, если нет – управление. Управление (Control) – правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Каждая работа должна иметь хотя бы одну стрелку управления. Стрелка управления рисуется как входящая в верхнюю грань работы. На рис. 11 стрелки "Задание" и "Чертеж" – управление для работы "Изготовление изделия". Управле37 ние влияет на работу, но не преобразуется работой. Если цель работы изменить процедуру или стратегию, то такая процедура или стратегия будет для работы входом. В случае возникновения неопределенности в статусе стрелки (управление или контроль) рекомендуется рисовать стрелку управления. Выход (Output) – материал или информация, которые производятся работой. Каждая работа должна иметь хотя бы одну стрелку выхода. Работа без результата не имеет смысла и не должна моделироваться. Стрелка выхода рисуется как исходящая из правой грани работы. На рис. 11 стрелка "Готовое изделие" является выходом для работы "Изготовление изделия". Механизм (Mechanism) – ресурсы, которые выполняют работу, например персонал предприятия, станки, устройства и т. д. Стрелка механизма рисуется как входящая в нижнюю грань работы. На рис. 11 стрелка "Персонал предприятия" является механизмом для работы "Изготовление изделия". По усмотрению аналитика стрелки механизма могут не изображаться в модели. Вызов (Call) – специальная стрелка, указывающая на другую модель работы. Стрелка механизма рисуется как исходящая из нижней грани работы. На рис. 11 стрелка "Другая модель работы" является вызовом для работы "Изготовление изделия". Стрелка вызова используется для указания того, что некоторая работа выполняется за пределами моделируемой системы. В BPwin стрелки вызова используются в механизме слияния и разделения моделей. Граничные стрелки. Стрелки на контекстной диаграмме служат для описания взаимодействия системы с окружающим миром. Они могут начинаться у границы диаграммы и заканчиваться у работы и наоборот. Такие стрелки называются граничными. Для внесения граничной стрелки входа надо: щелкнуть по кнопке с символом стрелки в палитре инструментов и перенести курсор к левой стороне экрана, пока не появится начальная темная полоска; щелкнуть один раз по полоске (откуда выходит стрелка) и еще раз в левой части работы со стороны входа (где заканчивается стрелка); вернуться в палитру инструментов и выбрать опцию редактирования стрелки ; щелкнуть правой кнопкой мыши на линии стрелки, во всплывающем меню выбрать Name и добавить имя стрелки во вкладке Name диалога Arrow Properties (рис. 16). Стрелки управления, выхода и механизма изображаются аналогично. Для рисования стрелки выхода, например, следует щелкнуть по 38 кнопке с символом стрелки на палитре инструментов, щелкнуть в правой части работы со стороны выхода (где начинается стрелка), перенести курсор к правой стороне экрана, пока не появится начальная штриховая полоска, и щелкнуть один раз по штриховой полоске. Рис. 16. Диалог Arrow Properties Имена вновь внесенных стрелок автоматически заносятся в словарь (Arrow Dictionary). ICOM-коды. Диаграмма декомпозиции предназначена для детализации работы. В отличие от моделей, отображающих структуру организации, работа на диаграмме верхнего уровня в IDEF0 – это не элемент управления нижестоящими работами. Работы нижнего уровня – это то же самое, что и работы верхнего уровня, но в более детальном изложении. Как следствие этого границы работы верхнего уровня – это то же самое, что и границы диаграммы декомпозиции. ICOM (аббревиатура от Input, Control, Output и Mechanism) – коды, предназначенные для иден39 тификации граничных стрелок. Код ICOM содержит префикс, соответствующий типу стрелки (I, С, О или М), и порядковый номер (рис. 17). Рис. 17. Фрагмент диаграммы декомпозиции с ICOM-кодом (11, С2) BPwin вносит ICOM-коды автоматически. Для отображения ICOMкодов следует включить опцию ICOM codes на вкладке Display диалога Model Properties (меню Model/Model Properties). Словарь стрелок редактируется при помощи специального редактора Arrow Dictionary, в котором определяется стрелка и вносится относящийся к ней комментарий (рис. 18). Рис. 18. Словарь стрелок Словарь стрелок решает очень важную задачу. Диаграммы создаются аналитиком для того, чтобы провести сеанс экспертизы, т. е. обсу40 дить диаграмму со специалистом предметной области. В любой предметной области формируется профессиональный жаргон, причем очень часто жаргонные выражения имеют нечеткий смысл и воспринимаются разными специалистами по-разному. В то же время аналитик-автор диаграмм вынужден употреблять те выражения, которые наиболее понятны экспертам. Поскольку формальные определения часто сложны для восприятия, аналитик вынужден употреблять профессиональный жаргон, а, чтобы не возникло неоднозначных трактовок, в словаре стрелок каждому понятию можно дать расширенное и, если это необходимо, формальное определение. Помимо словаря стрелок BPwin содержит еще 14 словарей (работ, хранилищ данных, внешних ссылок, объектов ссылок, перекрестков, сущностей, атрибутов, центров затрат, ресурсов, ролей, групп ролей, свойств UDP, ключевых слов UDP и изображений). Интерфейс большинства словарей унифицирован. Назначение кнопок панели управления словарем приведено в табл. 3. Таблица 3 Кнопки панели управления словарем (слева направо) Кнопка Назначение Сохранить словарь Предварительный просмотр печати словаря Печать словаря Экспорт словаря в текстовый файл Импорт словаря из текстового файла Удаление объектов из словаря. Удалить можно только те объекты, которые не используются в модели Содержимое словаря стрелок можно распечатать в виде отчета (меню Tools/Reports/Arrow Report) и получить тем самым толковый словарь терминов предметной области, использующихся в модели. Несвязанные граничные стрелки (unconnected border arrow). При декомпозиции работы входящие в нее и исходящие из нее стрелки (кроме стрелки вызова) автоматически появляются на диаграмме де41 композиции (миграция стрелок), но при этом не касаются работ. Такие стрелки называются несвязанными и воспринимаются в BPwin как синтаксическая ошибка. На рис. 19 приведен фрагмент диаграммы декомпозиции с несвязанными стрелками, генерирующийся BPwin при декомпозиции работы "Изготовление изделия" (см. рис. 11). Для связывания стрелок входа, управления или механизма необходимо перейти в режим редактирования стрелок, щелкнуть по наконечнику стрелки и щелкнуть по соответствующему сегменту работы. Для связывания стрелки выхода необходимо перейти в режим редактирования стрелок, щелкнуть по сегменту выхода работы и затем по стрелке. Рис. 19. Пример несвязанных стрелок Внутренние стрелки. Для связи работ между собой используются внутренние стрелки, т.е. стрелки, которые не касаются границы диаграммы, начинаются у одной и кончаются у другой работы. Для рисования внутренней стрелки необходимо в режиме рисования стрелок щелкнуть по сегменту (например, выхода) одной работы и затем по сегменту (например, входа) другой. ВIDEF0 различают пять типов связей работ. Связь по входу (output-input), когда стрелка выхода вышестоящей работы (далее – просто выход) направляется на вход нижестоящей (например, на рис. 20 стрелка "Детали" связывает работы "Изготовление деталей и Сборка изделия"). Связь по управлению (output-control), когда выход вышестоящей работы направляется на управление нижестоящей. 42 Рис. 20. Связь по входу Связь по входу показывает доминирование вышестоящей работы. Данные или объекты выхода вышестоящей работы не меняются в нижестоящей. На рис. 21 стрелка "Чертеж" связывает работы "Создание чертежа детали" и "Изготовление детали", при этом чертеж не претерпевает изменений в процессе изготовления деталей. Рис. 21. Связь по управлению Обратная связь по входу (output-input feedback), когда выход нижестоящей работы направляется на вход вышестоящей. Такая связь, как правило, используется для описания циклов. На рис. 22 стрелка "Брак" связывает работы "Переработка сырья" и "Контроль качества", при этом выявленный на контроле брак направляется на вторичную переработку. 43 Рис. 22. Обратная связь по входу Обратная связь по управлению (output-control feedback), когда выход нижестоящей работы направляется на управление вышестоящей (стрелка "Рекомендации", рис. 23). Обратная связь по управлению часто свидетельствует об эффективности бизнес-процесса. В случае, изображенном на рис. 23 качество изделия может быть повышено путем непосредственного регулирования процессами изготовления деталей и сборки изделия в зависимости от результата (выхода) работы "Контроль качества". Рис. 23. Обратная связь по управлению Связь выход-механизм (output-mechanism), когда выход одной работы направляется на механизм другой. Эта взаимосвязь используется 44 реже остальных и показывает, что одна работа подготавливает ресурсы, необходимые для проведения другой работы (рис. 24). Рис. 24. Связь выход-механизм Явные стрелки. Явная стрелка имеет источником одну-единственную работу и назначением тоже одну-единственную работу. Разветвляющиеся и сливающиеся стрелки. Одни и те же данные или объекты, порожденные одной работой, могут использоваться сразу в нескольких других работах. С другой стороны, стрелки, порожденные в разных работах, могут представлять собой одинаковые или однородные данные или объекты, которые в дальнейшем используются или перерабатываются в одном месте. Для моделирования таких ситуаций в IDEF0 используются разветвляющиеся и сливающиеся стрелки. Для разветвления стрелки нужно в режиме редактирования стрелки щелкнуть по фрагменту стрелки и по соответствующему сегменту работы. Для слияния двух стрелок выхода нужно в режиме редактирования стрелки сначала щелкнуть по сегменту выхода работы, а затем по соответствующему фрагменту стрелки. Смысл разветвляющихся и сливающихся стрелок передается именованием каждой ветви стрелок. Существуют определенные правила именования таких стрелок. Рассмотрим их на примере разветвляющихся стрелок. Если стрелка именована до разветвления, а после разветвления ни одна из ветвей не именована, то подразумевается, что каждая ветвь моделирует те же данные или объекты, что и ветвь до разветвления (рис. 25). 45 Рис. 25. Пример именования разветвляющейся стрелки Если стрелка именована до разветвления, а после разветвления какая-либо из ветвей не именована, то подразумевается, что эти ветви соответствуют именованию. Если при этом какая-либо ветвь после разветвления осталась неименованной, то подразумевается, что она моделирует те же данные или объекты, что и ветвь до разветвления (рис. 26). Рис. 26. Пример именования разветвляющейся стрелки Недопустима ситуация, когда стрелка до разветвления не именована, а после разветвления не именована какая-либо из ветвей. BPwin определяет такую стрелку как синтаксическую ошибку (рис. 27). 46 Рис. 27. Пример неверного именования разветвляющейся стрелки Правила именования сливающихся стрелок полностью аналогичны – ошибкой будет считаться стрелка, которая после слияния не именована, л до слияния не именована какая-либо из ее ветвей. Для именования отдельной ветви разветвляющихся и сливающихся стрелок следует выделить па диаграмме только одну ветвь, после этого вызвать редактор имени и присвоить имя стрелке. Это имя будет соответствовать только выделенной ветви. Тоннелирование стрелок. Вновь внесенные граничные стрелки на диаграмме декомпозиции нижнего уровня изображаются в квадратных скобках и автоматически не появляются на диаграмме верхнего уровня (рис. 28). Рис. 28. Неразрешенная (unresolved) стрелка 47 Для их "перетаскивания" наверх нужно сначала выбрать кнопку на палитре инструментов и щелкнуть по квадратным скобкам граничной стрелки. Появляется диалог Border Arrow Editor (рис. 29). Рис. 29. Диалог Border Arrow Editor Если выбрать опцию Resolve it to border arrow, стрелка мигрирует на диаграмму верхнего уровня, а если Change it to resolved rounded tunnel – стрелка будет затоннелирована и не попадет на другую диаграмму. Тоннельная стрелка изображается с круглыми скобками на конце (рис. 30). Рис. 30. Типы тоннелирования стрелок 48 Тоннелирование может быть применено для изображения малозначимых стрелок. Если на какой-либо диаграмме нижнего уровня необходимо изобразить малозначимые данные или объекты, которые не обрабатываются или не используются работами на текущем уровне, то их необходимо направить на вышестоящий уровень (на родительскую диаграмму). Если эти данные не используются на родительской диаграмме, их нужно направить еще выше и т. д. В результате малозначимая стрелка будет изображена на всех уровнях и затруднит чтение всех диаграмм, на которых она присутствует. Выходом является тоннелирование стрелки на самом нижнем уровне. Такое тоннелирование называется "не в родительской диаграмме". Другим примером тоннелирования может быть ситуация, когда стрелка механизма мигрирует с верхнего уровня на нижний, причем на нижнем уровне этот механизм используется одинаково во всех работах без исключения. (Предполагается, что не нужно детализировать стрелку механизма, т. е. стрелка механизма на дочерней работе именована до разветвления, а после разветвления ветви не имеет собственного имени.) В этом случае стрелка механизма на нижнем уровне может быть удалена, после чего на родительской диаграмме она может быть затоннелирована, а в комментарии к стрелке или в словаре можно указать, что механизм будет использоваться во всех работах дочерней диаграммы декомпозиции. Такое тоннелирование называется "не в дочерней работе" (рис. 30). Нумерация работ и диаграмм Все работы модели нумеруются. Номер состоит из префикса и числа. Может быть использован префикс любой длины, но обычно используют префикс А. Контекстная (корневая) работа дерева имеет номер А0. Работы декомпозиции А0 имеют номера Al, A2, A3 и т.д. Работы декомпозиции нижнего уровня имеют номер родительской работы и очередной порядковый номер, например работы декомпозиции A3 будут иметь номера А31, Л32, АЗЗ, А34 и т. д. Работы образуют иерархию, где каждая работа может иметь одну родительскую и несколько дочерних работ, образуя дерево. Такое дерево называют деревом узлов, а вышеописанную нумерацию – нумерацией по узлам. Имеются незначительные варианты нумерации, которые можно настроить во вкладке Presentation диалога Model Properties (меню lid it/ Model Properties). Диаграммы IDEF0 имеют двойную нумерацию. Во-первых, диаграммы имеют номера по узлу. Контекстная диаграмма всегда имеет номер А-0, декомпозиция контекстной диаграммы – номер А0, осталь49 ные диаграммы декомпозиции-номера по соответствующему узлу (например, Al, A2, А21, Л213 и т.д.). BPwin автоматически поддерживает нумерацию по узлам, т. е. при проведении декомпозиции создается новая диаграмма и ей автоматически присваивается соответствующий номер. В результате проведения экспертизы диаграммы могут уточняться и изменяться, следовательно, могут быть созданы различные версии одной и той же (с точки зрения ее расположения в дереве узлов) диаграммы декомпозиции. BPwin позволяет иметь в модели только одну диаграмму декомпозиции в данном узле. Прежние версии диаграммы можно хранить в виде бумажной копии либо как FEO-диаграмму. (К сожалению, при создании FEO-диаграмм отсутствует возможность отката, т. е. можно получить из диаграммы декомпозиции FEO, но не наоборот.) В любом случае следует отличать различные версии одной и той же диаграммы. Для этого существует специальный номер – С-number, который должен присваиваться автором модели вручную. C-number – это произвольная строка, но рекомендуется придерживаться стандарта, когда номер состоит из буквенного префикса и порядкового номера, причем к качестве префикса используются инициалы автора диаграммы, а порядковый номер отслеживается автором вручную, например МСВ00021. Общие рекомендации к построению диаграмм 1. Чертите дуги только по вертикали и горизонтали. Таким образом, блоки будут визуально выделяться как точки сбора дуг, которыми блоки и являются. Это помогает также проследить за направлением дуг. 2. Блоки всегда имеют дуги управления, но могут не иметь входных дуг. Дуги управления накладывают ограничения и включают или выключают функции системы. Без них система не может работать. 3. Если данные служат и для управления, и для входа, вычерчивайте только дугу управления. Этим вы уменьшаете сложность общей картины и делаете очевидным управляющий характер данных. 4. Максимально увеличьте расстояние между параллельными дугами, оставляя больше места для меток. Это помогает зрительно определять количество дуг и прослеживать их пути. 5. Максимально увеличьте расстояние между блоками и поворотами дуг, а также между блоками и пересечениями дуг, чтобы облегчить процесс чтения и уменьшить вероятность перепутать две разные дуги. 6. Объедините дуги, источники которых не указаны на диаграмме, если они представляют одни и те же данные. Этим вы графически покажете единый источник сходных данных. 50 7. Рисуйте циклические обратные связи для одного и того же блока только, чтобы выделить их. Обычно обратную связь изображают на диаграмме, декомпозирующей блок. Однако иногда требуется выделить буферы и повторно используемые объекты. 8. Объединяйте дуги с общим источником или с общим приемником, если они представляют связанные данные. Общее название лучше описывает суть данных. 9. Минимизируйте число дуг, касающихся каждой стороны блока, если, конечно, природа данных не слишком разнородна. 10. Обратные связи по управлению рисуйте "вверх и над". Таким образом, вы покажете ограничивающие обратные связи при минимальном числе линий и пересечений, а также соберете все дуги управления в верхней правой части диаграммы. 11. Обратные связи по входу рисуйте "вниз и под". Это позволит показать обратные потоки данных при минимальном числе линий и пересечений, а также собрать все входные дуги в нижней левой части диаграммы. 12. Если возможно, присоединяйте дуги к блокам в одной и той же ICOM-позиции. Соединения дуг конкретного типа с блоками будут согласованными, и тем самым вы упростите чтение диаграммы. 13. При соединении большого числа блоков избегайте необязательных пересечений дуг. Возможно, это простейшее и самое очевидное правило позволит более всего уменьшить сложность диаграммы. 14. Минимизируйте число петель и поворотов каждой дуги. Это также упростит диаграмму. Связывание модели процессов и модели данных После разработки модели процессов ее следует связать с моделью данных. Такая связь гарантирует завершенность анализа, гарантирует, что есть источник данных (сущность) для всех потребителей данных (работ). Связи объектов способствуют согласованности, корректности и завершенности анализа. В модели процессов стрелке соответствуют сущность модели данных. В связи с требованиями нормализации данных, одной и той же стрелке в модели процессов может соответствовать несколько сущностей в модели данных и, наоборот, одной сущности может соответствовать несколько стрелок (рис. 31). Работы в модели процессов могут создавать или изменять данные, которые соответствуют входящим или выходящим стрелкам. Они могут воздействовать как целиком на сущности (создавая или модифицируя экземпляры сущности), так и на отдельные атрибуты сущности. 51 Рис. 31. Соответствие сущностей стрелкам Для того чтобы связать модель процессов и модель данных необходимо: 1. Экспортировать модель данных из ERWin в BPWin. Для экспорта модели данных из ERWin в BPWin необходимо в ERWin открыть модель и выбрать пункт меню File/Export/BPWin. В появившемся диалоге Select BPWin Export File необходимо выбрать каталог, указать имя создаваемого файла экспорта *.eax и нажать OK. 2. Затем в BPWin нужно открыть модель процессов, выбрать в меню пункт File/Import/ERWin (EAX), в диалоге Open выбрать имя файла (*.eax) и нажать OK. Появится диалог Import Differences Preview, в котором показывается протокол импорта. Для внесения данных в модель процессов следует щелкнуть по кнопке Accept (рис. 32). 3. После внесения данных в модель процессов можно связать сущности и атрибуты со стрелками. Правой кнопкой мыши нужно щелкнуть по стрелке и выбрать в контекстном меню Arrow Data. Появляется вкладка Arrow Data диалога Arrow Properties (рис. 33). 4. Для связывания атрибута со стрелкой достаточно щелкнуть по иконке выбора в иерархическом списке атрибутов. 52 Рис. 32. Диалог Import Differences Preview Рис. 33. Вкладка Arrow Data диалога Arrow Properties 53 5. Как было указано выше, работы могут воздействовать на данные. Для документирования такого воздействия необходимо щелкнуть правой кнопкой мыши по работе и выбрать пункт меню Data Usage Editor (рис. 34). Рис. 34. Диалог Data Usage Editor В появившемся диалоге Data Usage Editor в виде иерархического списка показываются все работы модели, стрелки, которые касаются работ, сущности и атрибуты, которые были связаны со стрелками. В верхнем списке нужно щелкнуть по имени стрелки, с которой были связаны сущности и атрибуты. Для задания ассоциации достаточно щелкнуть по окну в иерархическом списке. Для сущностей задается ассоциация CRUD (Create, Read, Update, Delete), для атрибутов – IRUN (Insert, Read, Update, Nullify). Ассоциации CRUD и IRUN – это правила использования сущностей и атрибутов работами, т. е. то, что могут делать работы с входящими или исходящими данными. Данные не могут использоваться работами произвольно. Стрелки входа представляют данные, которые работа преобразует в выход или потребляет. Такие данные могут быть обновлены (Update) или прочитаны (Read), но не могут быть созданы (Create, Insert) или удалены (Delete, Nullify). Данные, связанные со стрелками управления, могут быть только прочитаны (Read), но не могут быть изменены – процедуры 54 и стратегии не могут изменяться в работе. Данные, связанные со стрелками выхода, могут быть обновлены (если им соответствуют данные стрелок входа), удалены (Delete, Nullify) или созданы (Create, Insert). Для стрелок механизма ассоциации не устанавливаются. 2.4.4. Отображение модели данных в ERWIN ERwin имеет два уровня представления модели – логический и физический. Логический уровень – это абстрактный взгляд на данные, на нем данные представляются так, как выглядят в реальном мире, и могут называться так, как они называются в реальном мире, например "Постоянный клиент", "Отдел" или "Фамилия сотрудника". Объекты модели, представляемые на логическом уровне, называются сущностями и атрибутами (подробнее о сущностях и атрибутах будет рассказано ниже). Логическая модель данных может быть построена на основе другой логической модели, например на основе модели процессов. Логическая модель данных является универсальной и никак не связана с конкретной реализацией СУБД. Физическая модель данных, напротив, зависит от конкретной СУБД, фактически являясь отображением системного каталога. В физической модели содержится информация о всех объектах БД Поскольку стандартов на объекты БД не существует (например, нет стандарта на типы данных), физическая модель зависит от конкретной реализации СУБД. Следовательно, одной и той же логической модели могут соответствовать несколько разных физических моделей. Если в логической модели не имеет значения, какой конкретно тип данных имеет атрибут, то в физической модели важно описать всю информацию о конкретных физических объектах – таблицах, колонках, индексах, процедурах и т. д Разделение модели данных на логические и физические позволяет решить несколько важных задач. Документирование модели Многие СУБД имеют ограничение на именование объектов (например, ограничение на длину имени таблицы или запрет использования специальных символов – пробела и т. п.). Зачастую разработчики ИС имеют дело с нелокализованными версиями СУБД. Это означает, что объекты БД могут называться короткими словами, только латинскими символами и без использования специальных символов (т. е. нельзя назвать таблицу предложением – только одним словом). Кроме того, проектировщики БД нередко злоупотребляют "техническими" 55 наименованиями, в результате таблица и колонки получают наименования типа RTD_324 или CUST_A12 и т. д. Полученную в результате структуру могут понять только специалисты (а чаще всего только авторы модели), ее невозможно обсуждать с экспертами предметной области. Разделение модели на логическую и физическую позволяет решить эту проблему. На физическом уровне объекты БД могут называться так, как того требуют ограничения СУБД. На логическом уровне можно этим объектам дать синонимы – имена более понятные неспециалистам, в том числе на кириллице и с использованием специальных символов. Например, таблице CUST_A12 может соответствовать сущность Постоянный клиент. Такое соответствие позволяет лучше задокументировать модель и дает возможность обсуждать структуру данных с экспертами предметной области. Масштабирование Создание модели данных, как правило, начинается с создания логической модели. После описания логической модели, проектировщик может выбрать необходимую СУБД и ERwin автоматически создаст соответствующую физическую модель. На основе физической модели ERwin может сгенерировать системный каталог СУБД или соответствующий SQL-скрипт. Этот процесс называется прямым проектированием (Forward Engineering). Тем самым достигается масштабируемость – создав одну логическую модель данных, можно сгенерировать физические модели под любую поддерживаемую ERwin СУБД. С другой стороны, ERwin способен по содержимому системного каталога или SQL-скрипту воссоздать o физическую и логическую модель данных (Reverse Engineering). На основе полученной логической модели данных можно сгенерировать физическую модель для другой СУБД и затем сгенерировать ее системный каталог. Следовательно, ERwin позволяет решить задачу по переносу структуры данных с одного сервера на другой. Например, можно перенести структуру данных с Oracle на Informix (или наоборот) или перенести структуру dbf-файлов в реляционную СУБД, тем самым облегчив решение по переходу от файл-серверной к клиент-серверной ИС. Заметим, однако, что формальный перенос структуры "плоских" таблиц на реляционную СУБД обычно неэффективен. Для того чтобы извлечь выгоды от перехода на клиент-серверную технологию, структуру данных следует модифицировать. Процессы прямого и обратного проектирования будут рассмотрены ниже. Для переключения между логической и физической моделью данных служит список выбора в левой части панели инструментов Erwin (рис. 35). 56 Рис. 35. Переключение между логической и физической моделью При переключении, если физической модели еще не существует, она будет создана автоматически. Интерфейс ERwin. Уровни отображения модели Интерфейс выполнен в стиле Windows-приложений. В дальнейшем будет описан интерфейс версии ERwin 3.5.2. Рассмотрим кратко основные функции ERwin по отображению модели, а также панель и палитру инструментов. Более подробно элементы интерфейса будут рассмотрены в последующих главах. Элементы панели инструментов описаны в табл. 4. Таблица 4 Основная панель инструментов Палитра инструментов выглядит различно на разных уровнях отображения модели. На логическом уровне (рис. 36) палитра инструментов имеет: 1. Слева направо, верхний ряд: кнопку указателя (режим мыши) – в этом режиме можно установить фокус на каком-либо объекте модели; кнопку внесения сущности – для внесения сущности нужно щелкнуть левой кнопкой мыши по кнопке внесения сущности и один 57 раз по свободному пространству на модели. Повторный щелчок приведет к внесению в модель еще одной новой сущности. Для редактирования сущностей или других объектов модели необходимо перейти в режим указателя; кнопку категории. Категория, или категориальная связь, – специальный тип связи между сущностями, которая будет рассмотрена ниже. Для установления категориальной связи нужно щелкнуть левой кнопкой мыши по кнопке категории, затем один раз щелкнуть по сущности – родовому предку, затем – по сущности-потомку; кнопку внесения текстового блока. С ее помощью можно внести текстовый комментарий в любую часть графической модели. 2. Слева направо, нижний ряд: кнопку перенесения атрибутов внутри сущностей и между ними. Атрибуты могут быть перемещены способом drag&drop; кнопки создания связей: идентифицирующую, "многие-ко-многим" и неидентифицирующую. Рис. 36. Палитра инструментов на логическом уровне На физическом уровне (рис. 37) палитра инструментов имеет: • вместо кнопки категорий (третья справа кнопка в верхнем ряду) кнопку внесения представлений (view); • вместо кнопки связи "многие-ко-многим" (третья справа кнопка в нижнем ряду) кнопку связей представлений. Для создания моделей данных в ERwin можно использовать две нотации: IDEF1X и IE (Information Engineering). Методология IDEF1X была разработана для армии США и широко используется в государственных учреждениях США, финансовых и промышленных корпорациях. Методология IE, разработанная Мартином (Martin), Финкельштейном (Finkelstein) и другими авторами, используется преимущественно в промышленности. Переключение между нотациями можно сделать в закладке Methodology диалога Preferences (меню Option/Preferences) (рис. 38). В дальнейшем будет использоваться нотация IDEF1X. 58 Рис. 37. Палитра инструментов на физическом уровне Рис. 38. Переключение между нотациями ERwin имеет несколько уровней отображения диаграммы: уровень сущностей, уровень атрибутов, уровень определений, уровень первичных ключей и уровень иконок. Переключиться между первыми тремя уровнями можно с использованием кнопок панели инструментов. Переключиться на другие уровни отображения можно при помощи кон59 текстного меню, которое появляется, если "кликнуть" по любому месту диаграммы, не занятому объектами модели. В контекстном меню следут выбрать пункт Display Level и затем необходимый уровень отображения. ERwin позволяет связать с сущностью большую и малую иконки. При переключении на уровень иконок показывается большая иконка. Для отображения малой иконки следует выбрать в контекстном меню пункт Display Options/Entities и в каскадном меню включить опцию Entity Icon. Малая иконка будет показана слева от имени сущности на всех уровнях отображения модели. В табл. 5 показаны уровни отображения модели. Таблица 5 Уровни отображения модели 60 2.4.5. Создание логической модели данных Уровни логической модели Различают три уровня логической модели, отличающихся по глубине представления информации о данных: диаграмма сущность-связь (Entity Relationship Diagram, ERD); модель данных, основанная на ключах (Key Based model, KB); полная атрибутивная модель (Fully Attributed model, FA). Диаграмма сущность-связь представляет собой модель данных верхнего уровня. Она включает сущности и взаимосвязи, отражающие основные бизнес-правила предметной области. Такая диаграмма не слишком детализирована, в нее включаются основные сущности и связи между ними, которые удовлетворяют основным' требованиям, предъявляемым к ИС. Диаграмма сущность-связь может включать связи многие-ко-многим и не включать описание ключей. Как правило, ERD используется для презентаций и обсуждения структуры данных с экспертами предметной области. Модель данных, основанная на ключах, – более подробное представление данных. Она включает описание всех сущностей и первичных ключей и предназначена для представления структуры данных и ключей, которые соответствуют предметной области. Полная атрибутивная модель – наиболее детальное представление структуры данных: представляет данные в третьей нормальной форме и включает все сущности, атрибуты и связи. Сущности и атрибуты Основные компоненты диаграммы Erwin – это сущности, атрибуты и связи. Каждая сущность является множеством подобных индивидуальных объектов, называемых экземплярами. Каждый экземпляр индивидуален и должен отличаться от всех остальных экземпляров. Атрибут выражает определенное свойство объекта. С точки зрения БД (физическая модель) сущности соответствует таблица, экземпляру сущности – строка в таблице, а атрибуту – колонка таблицы. Построение модели данных предполагает определение сущностей и атрибутов, т. е. необходимо определить, какая информация будет храниться в конкретной сущности или атрибуте. Сущность можно определить как объект, событие или концепцию, информация о которых должна сохраняться. Сущности должны иметь наименование с четким смысловым значением, именоваться существительным в единственном числе, не носить "технических" наименований и быть достаточно важными для того, чтобы их моделировать. Именование сущности в единственном числе облегчает в дальнейшем чтение модели. Фактически имя 61 сущности дается по имени ее экземпляра. Примером может быть сущность Заказчик (но не Заказчики!) с атрибутами Номер заказчика, Фамилия заказчика и Адрес заказчика. На уровне физической модели ей может соответствовать таблица Customer с колонками Customer_number, Customerjname и Customer'_address. Для внесения сущности в модель необходимо (убедившись предварительно, что вы находитесь на уровне логической модели – переключателем между логической и физической моделью служит раскрывающийся список в правой части панели инструментов) "кликнуть" по кнопке сущности на панели инструментов (ERwin Toolbox), затем "кликнуть" по тому месту на диаграмме, где необходимо расположить новую сущность. Щелкнув правой кнопкой мыши по сущности и выбрав из всплывающего меню пункт Entity Editor, можно вызвать диалог Entity Editor, в котором определяются имя, описание и комментарии сущности. Каждая сущность должна быть полностью определена с помощью текстового описания в укладке Definition. Закладки Note, Note 2, Note 3, UDP (User Defined Properties – Свойства, определенные пользователем) служат для внесения дополнительных комментариев и определений к сущности. В прежних версиях ERwin закладкам Note 2 и Note 3 соответствовали окна Query и Sample. Закладка Definition используется для ввода определения сущности. Эти определения полезны как на логическом уровне, поскольку позволяют понять, что это за объект, так и на физическом уровне, поскольку их можно экспортировать как часть схемы и использовать в реальной БД (CREATE COMMENT on entity_name). Закладка Note позволяет добавлять дополнительные замечания о сущности, которые не были отражены в определении, введенном в закладке Definition. Здесь можно ввести полезное замечание, описывающее какое-либо бизнес-правило или соглашение по организации диаграммы. В закладке Note 2 можно задокументировать некоторые возможные запросы, которые, как ожидается, будут использоваться по отношению к сущности в БД. При переходе к физическому проектированию, записанные запросы помогут принимать такие решения в отношении проектирования, которые сделают БД более эффективной. Cвязи Связь является логическим соотношением между сущностями. Каждая связь должна именоваться глаголом или глагольной фразой (Relationship Verb Phrases) (рис. 39). Имя связи выражает некоторое ограничение или бизнес-правило и облегчает чтение диаграммы, например: Каждый КЛИЕНТ <размещает> ЗАКАЗЫ; Каждый ЗАКАЗ <выполняется> СОТРУДНИКОМ. 62 Рис. 39. Имя связи – Relationship Verb Phrases Связь показывает, какие именно заказы разместил клиент и какой именно сотрудник выполняет заказ. По умолчанию имя связи на диаграмме не показывается. Для отображения имени следует в контекстном меню, которое появляется, если щелкнуть левой кнопкой мыши по любому месту диаграммы, не занятому объектами модели, выбрать пункт Display Options/Relationship и затем включить опцию Verb Phrase. На логическом уровне можно установить идентифицирующую связь один-ко-многим, связь многие-ко-многим и неидентифицирующую связь один-ко-многим (соответственно это кнопки слева направо в палитре инструментов) В IDEF1X различают зависимые и независимые сущности. Тип сущности определяется ее связью с другими сущностями. Идентифицирующая связь устанавливается между независимой (родительский конец связи) и зависимой (дочерний конец связи) сущностями. Когда рисуется идентифицирующая связь, ERwin автоматически преобразует дочернюю сущность в зависимую. Зависимая сущность изображается прямоугольником со скругленными углами (сущность Заказ на рис. 40). Экземпляр зависимой сущности определяется только через отношение к родительской сущности, т.е. в структуре на рис. 6 информация о заказе не может быть внесена и не имеет смысла без информации о клиенте, который его размещает. При установлении идентифицирующей связи атрибуты первичного ключа родительской сущности автоматически переносятся в состав первичного ключа дочерней сущности. Эта операция дополнения атрибутов дочерней сущности при создании связи называется миграцией атрибутов. В дочерней сущности новые атрибуты помечаются как внешний ключ – (FK). В дальнейшем, при генерации схемы БД, атрибуты первичного ключа получат признак NOT NULL, что означает невозможность внесения записи в таблицу заказов без информации о номере клиента. При установлении неидентифицирующей связи (рис. 41) дочерняя сущность остается независимой, а атрибуты первичного ключа родительской сущности мигрируют в состав неключевых компонентов родительской сущности. Неидентифицирующая связь служит для связывания независимых сущностей. 63 Рис. 40. Идентифицирующая связь между независимой и зависимой таблицей Экземпляр сущности Сотрудник может существовать безотносительно к какому-либо экземпляру сущности Отдел, т. е. сотрудник может работать в организации, не числясь в каком-либо отделе. Идентифицирующая связь показывается на диаграмме сплошной линией с жирной точкой на дочернем конце связи (см. рис. 40), неидентифицирующая – пунктирной (рис. 41). Рис. 42. Неидентифицирующая связь Для создания новой связи следует: установить курсор на нужной кнопке в палитре инструментов (идентифицирующая или неидентифицирующая связь) и нажать левую кнопку мыши (рис. 2); щелкнуть сначала по родительской, а затем по дочерней сущности. В закладке General появившегося диалога можно задать мощность (степень связи), имя и тип связи (рис. 43). Мощность связи (Cardinality) – служит для обозначения отношения числа экземпляров родительской сущности к числу экземпляров дочерней. Различают четыре типа мощности (рис. 44): общий случай, когда одному экземпляру родительской сущности соответствуют О, 1 или много экземпляров дочерней сущности не помечается каким-либо символом; 64 символом Р помечается случай, когда одному экземпляру родительской сущности соответствуют 1 или много экземпляров дочерней сущности (исключено нулевое значение); символом Z помечается случай, когда одному экземпляру родительской сущности соответствуют 0 или 1 экземпляр дочерней сущности (исключены множественные значения); цифрой помечается случай точного соответствия, когда одному экземпляру родительской сущности соответствует заранее заданное число экземпляров дочерней сущности. Рис. 43. Диалог Relationship Editor По умолчанию символ, обозначающий мощность связи, не показывается на диаграмме. Для отображения имени следует в контекстном меню, которое появляется, если щелкнуть левой кнопкой мыши по любому месту диаграммы, не занятому объектами модели, выбрать пункт Display Options/Relationship и затем включить опцию Cardinality. 65 Рис. 44. Обозначения мощности Имя связи (Verb Phrase) – фраза, характеризующая отношение между родительской и дочерней сущностями. Для связи один-комногим идентифицирующей или неидентифицирующей достаточно указать имя, характеризующее отношение от родительской к дочерней сущности (Parent-to-Child). Для связи многие-ко-многим следует указывать имена как Parent-to-Child так и Child-to-Parent. Тип связи (идентифицирующая/неидентифицирующая). Для неидентифицирующей связи можно указать обязательность (Nulls). В случае обязательной связи (No Nulls) при генерации схемы БД атрибут внешнего ключа получит признак NOT NULL, несмотря на то что внешний ключ не войдет в состав первичного ключа дочерней сущности. В случае необязательной связи (Nulls Allowed) внешний ключ может принимать значение NULL. Необязательная неидентифицирующая связь помечается прозрачным ромбом со стороны родительской сущности (см. рис. 42). Рис. 45. Закладка Rolename/RI Actions диалога Relationship Editor 66 В закладке Definition можно дать более полное определение связи для того, чтобы в дальнейшем иметь возможность на него ссылаться. В закладке Rolename/RI Actions можно задать имя роли и правила ссылочной целостности (рис. 45). Ключи Каждый экземпляр сущности должен быть уникален и отличаться от других атрибутов. Первичный ключ (primary key) – это атрибут или группа атрибутов, однозначно идентифицирующая экземпляр сущности. Атрибуты первичного ключа на диаграмме не требуют специального обозначения – это те атрибуты, которые находятся в списке атрибутов выше горизонтальной линии. При внесении нового атрибута в диалоге Attribute Editor для того, чтобы сделать его атрибутом первичного ключа, нужно включить флажок Primary Key в нижней части закладки General. На диаграмме неключевой атрибут можно внести в состав первичного ключа, воспользовавшись режимом переноса атрибутов (кнопка в палитре инструментов). Выбор первичного ключа может оказаться непростой задачей, решение которой может повлиять на эффективность будущей ИС. В одной сущности могут оказаться несколько атрибутов или наборов атрибутов, претендующих на роль первичного ключа. Такие претенденты называются потенциальными ключами (candidate key). Каждая сущность должна иметь по крайней мере один потенциальный ключ. Многие сущности имеют только один потенциальный ключ. Такой ключ становится первичным. Некоторые сущности могут иметь более одного возможного ключа. Тогда один из них становится первичным, а остальные – альтернативными ключами. Альтернативный ключ (Alternate Key) – это потенциальный ключ, не ставший первичным. ERwin позволяет выделить атрибуты альтернативных ключей, и по умолчанию в дальнейшем при генерации схемы БД по этим атрибутам будет генерироваться уникальный индекс. 2.5. Оформление схем алгоритмов, программ, данных и систем Схемы алгоритмов, программ, данных и систем (далее — схемы) состоят из имеющих заданное значение символов, краткого пояснительного текста и соединяющих линий. В таблице 6 приведены условные обозначения для применения их в: 1) схемах данных; 2) схемах программ; 67 3) схемах работы системы; 4) схемах взаимодействия программ; 5) схемах ресурсов системы. Таблица 6 Символы, предназначенные для использования в документации по обработке данных Символ Наименование символа 1 2 Схема Схема Схема Схема Схема взаимо- ресурпро- работы дандействия сов грам- систеных просистемы мы грамм мы 3 4 5 6 7 Символы данных Основные Данные + + + + + Запоминаемые данные + - + + + Оперативное запоминающее устройство + - + + + Запоминающее устройство с последовательной выборкой + - + + + Запоминающее устройство с прямым доступом + - + + + Документ + - + + + Специфические 68 Продолжение табл. 6 1 2 3 4 5 6 7 Символы данных Ручной ввод + - + + + Карта + - + + + Бумажная лента + - + + + Дисплей + - + + + Символы процесса Основные Процесс + + + + + Предопределенный процесс - + + + - Ручная операция + - + + - Подготовка + + + + - Решение - + + - - Специфические 69 Продолжение табл. 6 1 2 Параллельные действия 3 4 5 6 7 - + + + - + + - - Граница цикла Символы линий Основные Линия + + + + + Передача управления - - - + - Канал связи + - + + + Пунктирная линия + + + + + Специфические Специальные символы Соединитель + + + + + Терминатор + + + - - Комментарий + + + + + Пропуск + + + + + Примечание: Знак «+» указывает, что символ используют в данной схеме, знак «-» – не используют. 70 Рис. 46. Схема программы 71 Рис. 47. Технологическая схема системы 72 2.6. Руководство пользователя Для разработанного ПС должно быть создано руководство пользователя согласно ГОСТ и содержать следующие разделы: 1) Введение Область применения Краткое описание возможностей Требования к уровню подготовки пользователя Перечень эксплуатационных документов, с которыми необходимо ознакомиться пользователю 2) Назначение и условия применения Виды деятельности и функции для автоматизации которых предназначено данное ПС Условия, при соблюдении которых обеспечивается применение ПС в соответствии с назначением 3) Подготовка к работе Состав и содержание дистрибутивного носителя данных Порядок загрузки данных и программ Порядок контроля и проверки работоспособности 4) Описание операций – для каждой операции обработки данных должно быть указано Наименование Условия, при соблюдении которых возможно выполнение операции Подготовительные действия Основные действия в требуемой последовательности Заключительные действия Ресурсы, расходуемые на операцию Описание всех выполняемых функций, задач, комплексов задач, процедур Описание операций технологического процесса обработки данных, необходимых для выполнения функций, комплексов программ, процедур. 5) Аварийные ситуации Действия в случае несоблюдения условий выполнения технологического процесса, в том числе при длительных отказах технических средств Действия по восстановлению программ и данных при отказе или обнаружении ошибок в данных Действия в случае обнаружения несанкционированного вмешательства в данные системы 73 2.7. Приложения К приложении к пояснительной записке помещают материал, дополняющий текст документа, который при включении в основную часть загромождал бы текст. Рекомендуется включать в приложения входные и выходные документы, схемы, модели, листинги программ и т.п. Для контрольного примера приведено только приложение Б с выходными документами. 3. ИНДИВИДУАЛЬНЫЕ ЗАДАНИЯ К КУРСОВОЙ РАБОТЕ Ниже представлен список вариантов индивидуальных заданий. Варианты индивидуальных заданий № варианта Тема Примечание 1 2 3 1 АРМ менеджера автосервиса Администрация службы автосервиса заказала разработку информационной системы для отдела работы с клиентами. Система предназначена для обработки данных о комплектующих, о заказах на комплектующие, расценках по оказываемым услугам, о машинах и их обслуживании. Система должна выдавать отчеты по запросу менеджера автосервиса: прайс-лист на оказываемые услуги, документы по заказам, квитанции по оплате услуг и т.д. АРМ «Операции с недвижимостью» Администрация агентства недвижимости заказала разработку информационной системы для отдела работы с клиентами. Система предназначена для обработки данных о квартирах, которые покупает и продает агентство, расценках на квартиры, расценках на оказываемые услуги, о покупателях и совершенных сделках.. Система должна выдавать отчеты по запросу менеджера: прайс-лист на квартиры (возможно с группировкой по различным признакам), на услуги, отчеты по возможным вариантам сделок для покупателей и продавцов 2 74 1 2 3 3 АРМ «Страхование населения» Руководство страховой компании заказало разработку информационной системы для отдела работы с клиентами. Система предназначена для обработки данных о видах страховок, их стоимость, о совершенных сделках, о клиентах, сроках действия страховки. Система должна выдавать отчеты по запросу менеджера: прайс-лист по видам страховки, бланк страхования, информация о клиентах и т.д. 4 АРМ «Медицинские услуги» Руководство частной медицинской клиники заказало разработку информационной системы для административной группы. Система предназначена для обработки данных о клиентах, врачах, их расписании, о перечне медицинских услуг (с расценками и описанием), стоимости медикаментов и их количества. Система должна выдавать отчеты по запросу менеджера клиники: наряд на посещение, гарантийный талон, бланк рецепта, бланк заказа на материалы, прайслисты по услугам 5 АРМ управляющего Рекламным агентств ом Руководство рекламного агентства заказало разработку информационной системы для отдела работы с клиентами. Система предназначена для обработки данных о клиентах, о продукции, предоставляемых услугах, стоимости пакета заказываемой рекламы и медиа-план для заказчика. Система должна выдавать отчеты по запросу менеджера: перечень изготавливаемо рекламной продукции со стоимостью (по видам продукции), квитанция для расчета, медиа-план, стоимость услуг и т.п. 6 Администрация ЖЭУ заказала разработку информационной системы для отдела по работе с квартиросъемщиками. Система предназначена для обработки данных о квартирах, их АРМ площади, количестве проживающих, льготах, расценках на оператооказываемые услуги. Система должна выдавать отчеты по ра ЖЭУ запросу менеджера: документы по оплате за квартиру и коммунальные услуги, а так же квитанции по оплате разовых услуг 7 АРМ оператора Агентст ва по трудоустройству Администрация агентства по трудоустройству заказала разработку информационной системы для отдела по работе с клиентами. Система предназначена для обработки данных о специалистах, стоящих на учете, фирмах, где требуются специалисты, и требованиях, которые к специалистам предъявляются. Кроме того в системе должны обрабатываться данные об услугах предоставляемых агентством. Система должна выдавать отчеты по запросу менеджера: Бланк анкеты, список вакансий по разделам, бланк направления на работу и прочие необходимые справки 75 1 2 3 8 Система исследования товарного рынка (товар на выбор) Администрация предприятия заказала разработку информационной системы для отдела маркетинга. Система предназначена для обработки данных о продажах товара за определенный промежуток времени (по подразделениям), ценах на этот же товар у конкурентов, статистике об альтернативных товарах, взаимозаменяющих элементах и т.п.. Система должна выдавать отчеты по запросу менеджера: отчет о динамике продаж с графическим анализом, отчет о движении товара, отчет о состоянии рынка и т.д. 9 Система учета заказов и их выполнение в строительной фирме (ремонт квартир) Администрация строительной компании, занимающейся ремонтом квартир, заказала разработку информационной системы для отдела работы с клиентами. Система предназначена для обработки данных о клиентах и перечне услуг, а также учете заказов, используемом материале и учет затрат по заказам. Кроме того, в системе должна храниться база фотографий с образцами ремонта и в целом отремонтированных квартир. Система должна выдавать отчеты по запросу менеджера: прайс-лист на оказываемые услуги, бланк расчета и другие документы необходимые для работы компании с клиентами 10 Система учета заказов и их выполнение в мебельном салоне Администрация компании по производству и продаже мебели, заказала разработку информационной системы для отдела работы с клиентами. Система предназначена для обработки данных о клиентах, о товарах (фотографии и характеристика товара, возможный материал изготовления), услугах, о учете заказов и учете затрат. Система должна выдавать отчеты по запросу менеджера: прайс-лист на оказываемые услуги, бланк расчета и другие документы необходимые для работы компании с клиентами 11 АРМ оператора отделения связи (подписка на издания) Руководство отделения связи Федеральной почтовой службы заказало разработку информационной системы для отдела оформления подписки на периодические издания. Система предназначена для обработки данных о клиентах, изданиях, каталогах со стоимостью подписки (по разделам и тематике), а также услугах, оказываемых подписчикам. Система должна выдавать отчеты по запросу менеджера: прайс-лист на оказываемые услуги, квитанция подписки, а также другие документы необходимые в процессе работы 76 1 2 3 12 Разработка автоматизированной системы заказов по каталогу Администрация торговой компании заказала разработку информационной системы заказов товаров по каталогам. Система предназначена для обработки данных о клиентах, товарах в каталогах (фотографии и характеристика товара, возможный материал изготовления и т.д.), сроках поставок и дополнительных услугах, оказываемых фирмой. Система должна выдавать отчеты по запросу менеджера: прайс-лист перечень товаров со стоимостью (по видам товара), квитанция для расчета, стоимость услуг и т.п. 13 АРМ продавца-консультанта магазина «Оптика» Администрация магазина «Оптика» заказала разработку ИС для отдела работы с покупателем. Система предназначена для обработки данных о клиенте, о материалах, учет заказов и затрат, перечень услуг. 14 15 16 АРМ «Расписание для спорткомплекса» АРМ «Система подсчета голосов в избирательных компаниях» АРМ администратора ресторана Система должна выдавать отчеты по запросу продавцаконсультанта магазина: расчеты с клиентами, прайс-лист на услуги Администрация спорткомплекса заказала разработку ИС для организации своей работы. Система предназначена для обработки данных о времени проведения занятий, о дне недели, кол-во человек в группе, вид занятий, учет помещений, фамилии тренеров. Система должна выдавать отчеты по запросу менеджера спорткомплекса: расписание, учет свободного времени, отчеты по загрузкам тренера и помещений Администрация города заказала разработку ИС для избиркома. Система предназначена для обработки данных об избирателях, о кандидатах, информация об избирательных участках. Система должна выдавать отчеты по запросу члена комиссии: бланк голосования, формирование итоговых протоколов по участкам, округам и городу. Ведомость учета избирателей Администрация ресторана заказала разработку ИС. Система предназначена для обработки данных о местах и площадях залов, информация о заказах на места, предварительный заказ блюд. Система должна выдавать отчеты по запросу администратора ресторана: бланк счета, информация о загрузке ресторана на определенную дату, меню. Отчеты по запросам 77 1 2 3 17 Администрация Ателье мод заказала разработку ИС. Система предназначена для обработки данных о клиентах, сроки АРМ админи- выполнения заказов, информация об исполнителях, перечень стратора услуг и их стоимость, учет затрат и заказов. Ателье Система должна выдавать отчеты по запросу администратоМод ра ателье мод: прайс-лист на услуги, квитанция для расчета с клиентами, отчеты по запросам 18 Система организации чемпионата по определенному виду спорта 19 20 Обработка оборотных ведомостей Администрация города заказала разработку ИС для спортивного комитета. Система предназначена для обработки данных о стадионах, о спортсменах, тренерах, а также о времени проведения игр. Система должна выдавать отчеты по запросу члена комитета: Расписание игр на каждый тур, протокол каждой игры, отчеты по запросам БД должна хранить и обновлять оборотные ведомости по материалам. Для различных материалов содержатся данные о цене, количестве и сумме. По цене и количеству необходимо иметь остатки на начало года или месяца, поступления от подотчетного лица и с центрального склада, выдачи в производство и остатки на конец года. Выходная информация: оборотные ведомости по месяцам БД должна содержать информацию об учете заработной платы сотрудников предприятия. Для каждого лица в базе должны содержаться данные о профессии, должности, начислениях заработной платы, премиях, начислениях по больничному листу, задолженностям по выплатам на начало месяца. БД должна содержать также для каждого сотрудника информацию об удержании, включая налоги, алименты и сумму к выдаче. АРМ бухгалтера расчетчика (задача начисления Выходная информация: ведомость на получение з/платы, з/платы) расчетные листки, бухгалтерские справки по доходам и расходам 78 1 21 22 2 3 БД должна содержать информацию об учете заработной платы сотрудников предприятия, работающих на условиях сдельной оплаты. Для каждого лица в базе должны содержаться данные о профессии, объем и перечень выполняемых работ, начислениях заработной платы, премиях, задолженностям по выплатам на начало года, а также информацию об удержании, включая налоги, алименты и сумму к выдаче. БД должна также содержать информацию о расценках выполняемых операций и информацию о бракованных деталях. АРМ бухгалтера расчетчика (задача начисления з/платы) Выходная информация: ведомость на получение з/платы, расчетные листки, бухгалтерские справки по доходам и расходам АРМ склад БД должна хранить и обновлять информацию по складскому учету материалов, включая следующие данные: наименование материала, сорт, профиль_размер, единица измерения, номенклатурный номер, цена, норма запаса, дата записи, номер документа, порядковый номер записи, от кого получено или кому отпущено, расход, приход, остаток. Выходная информация: накладная, счет-фактура, требование 23 БД должна содержать информацию о расчете с поставщиками продукции за месяц, включая данные: о документе на Расчеты основании которого произведен расчет с поставщиками, дате с постав- поставки и о самом поставщике, а также информацию о пощиками ставляемых изделиях. Выходная информация: документы по расчету с поставщиками, перечень имеющихся в наличии изделий 24 АРМ оператора кинотеатра (на примере кинотеатра «Иллюзион») Администрация кинотеатра заказала разработку ИС. Система предназначена для обработки данных о времени проведения сеансов, включая названия фильмов, о количестве мест в зале, о ценах в зависимости от места. Система должна выдавать отчеты по запросу оператора кинотеатра: Расписание сеансов со стоимость билетов, билет на определенный сеанс, ведомости проданных билетов на определенный день 79 4. УЧЕБНО-МЕТОДИЧЕСКОЕ И ИНФОРМАЦИОННОЕ ОБЕСПЕЧЕНИЕ ДИСЦИПЛИНЫ 4.1. Основная литература Агальцов, В.П. Базы данных: учебник для студентов вузов: в 2 кн. Кн. 1: Локальные базы данных / В.П. Агальцов. – 2-е изд., перераб. – М.: ФОРУМ: ИНФРА-М, 2011. – 352 с.: ил. Агальцов, В.П. Базы данных: учебник для студентов вузов: в 2 кн. Кн. 2: Распределенные и удаленные базы данных / В.П. Агальцов. – М.: ФОРУМ: ИНФРА-М, 2009. – 272 с.: ил. Андерсен, Б. Бизнес-процессы. Инструменты совершенствования / Б. Андерсен; пер. с англ. С.В. Ариничева; под науч. ред. Ю.П. Адлера. – 5-е изд. – М.: Стандарты и качество, 2008. – 272 с.: ил. – (Практический менеджмент). Баженова, И.Ю. Основы проектирования приложений баз данных: учебное пособие / И.Ю. Баженова; Интернет-ун-т информационных технологий (ИНТУИТ). – М.: БИНОМ: ЛЗ: ИНТУИТ.РУ, 2006. – 325 с. Бедрина, С.Л. Разработка и стандартизация программного обеспечения: учебное пособие для студ. вузов, обучающихся по спец. "Прикладная информатика (по областям)" / С.Л. Бедрина; Владивосток. гос. ун-т экономики и сервиса. – Владивосток: Изд-во ВГУЭС, 2007. – 180 с. Бедрина, С.Л. Разработка и стандартизация программных средств и информационных технологий: практикум / С.Л. Бедрина; Владивосток. гос. ун-т экономики и сервиса. – Владивосток: Изд-во ВГУЭС, 2011. – 116 с. Бородакий, Ю.В. Информационные технологии: Методы, процессы, системы / Ю.В. Бородакий, Ю.Г. Лободинский. – М.: Радио и связь, 2008. – 456 с.: ил.. – Библиогр.: с. 438. – ISBN 5-256-01566-4 Гагарина, Л.Г. Технология разработки программного обеспечения: учеб. пособие для студентов вузов / Л.Г. Гагарина, Е.В. Кокорева, Б.Д. Виснадул; под ред. Л.Г. Гагариной. – М.: ФОРУМ: ИНФРА-М, 2012. – 400 с. Диго, С.М. Базы данных: проектирование и создание: учебник для вузов / С.М. Диго. – М.: ЕАОИ, 2008. – 171 с. Елиферов, В.Г. Бизнес-процессы: регламентация и управление: учебное пособие для студентов вузов / В.Г. Елиферов, В.В. Репин; Ин-т экономики и финансов "Синергия". – М.: ИНФРА-М, 2011. – 319 с. – (Учебники программы МВА). WWW. GOST.RU; WWW. STANDARD.RU Калянов, Г.Н. Управление данными: учебник для студентов вузов, обучающихся по направлению "Информационные системы"; рец.: Г.Н. Калянов, В.А. Новиков, УМО вузов России. – М.: Академия, 2010. – 256 с. 80 Мартишин, С.А. Проектирование и реализация баз данных в СУБД MySQL с использованием MySQL Workbench: учеб. пособие для студентов вузов / С.А. Мартишин, В.Л. Симонов, М.В. Храпченко. – М.: ФОРУМ: ИНФРА-М, 2012. – 160 с. Хомоненко, А.Д. Базы данных: учебник для студентов вузов / А.Д. Хомоненко, В.М. Цыганков, М.Г. Мальцев; под ред. А.Д. Хомоненко. – 6-е изд., доп. – СПб.: КОРОНА-Век, 2009. – 736 с. 4.2. Дополнительная литература Автоматизированные информационные технологии в экономике: учебник / под ред. Г.А. Титоренко. – М.: Компьютер: ЮНИТИ, 1998. Алан Саймон. Стратегические технологии БД / Алан Саймон. – М.: Финансы и статистика, 1999. – 484 с. Благодатских, В.А. Экономика, разработка и использование программного обеспечения ЭВМ / В.А. Благодатских. – М: Финансы и статистика, 1995. Информатика. Базовый курс / под ред. С.В. Симоновича. – СПб., 2000. Корнеев, В.В. Базы данных. Интеллектуальная обработка информации / В.В. Корнеев, А.Ф. Гареев, С.В. Васютин, В.В. Райх. – М.: Нолидж, 2001. – 496 с. Компьютерные технологии обработки информации / под. ред. С.В. Назарова. – М.: Финансы и статистика, 1995 Леоненков, А.В. Самоучитель UML / А.В. Леоненков. – СПб.: БХВПетербург, 2001. Липаев, В.В. Надежность программных средств / В.В. Липаев. – М.: СИНТЕГ, 1998. Майерс, Г. Искусство тестирования программ / Г. Майерс; пер. с англ. – М.: Финансы и статистика, 1982. Пальчун Б.П. Оценка надежности программного обеспечения / Б.П. Пальчун, Р.М. Юсупов. – СПб.: Наука, 1994. Трофимов, С.А. CASE-технологии: практическая работа в Rational Rose. Изд. 2-е. – М.: Бином-Пресс, 2002. Ульман, Дж. Введение в системы баз данных / Дж. Ульман, Дж. Видом. – М.: Лори, 2000. – 374 с. Фридман, А.Л. Основы объектно-ориентированной разработки программных систем / А.Л. Фридман. – М: Финансы и статистика, 2000 Дейт, К. Дж. Введение в системы баз данных / К. Дж. Дейт. – 7-е издание. – К.; М.; СПб.: «Вильямс», 2006. – 848 с. 81 4.3. Список государственных стандартов ГОСТ 19.001-77 ЕСПД. Общие положения. ГОСТ 19.005-85 ЕСПД. Схемы алгоритмов и программ. Обозначения условные графические и правила выполнения. ГОСТ 19.101-77 ЕСПД. Виды программ и программных документов. ГОСТ 19.102-77 ЕСПД. Стадии разработки. ГОСТ 19.103-77 ЕСПД. Обозначение программ и программных документов. ГОСТ 19.104-78 ЕСПД. Основные надписи. ГОСТ 19.105-78 ЕСПД. Общие требования к программным документам. ГОСТ 19.106-78 ЕСПД. Требования к программным документам, выполненным печатным способом. ГОСТ 19.201-78 ЕСПД. Техническое задание. Требования к содержанию и оформлению. ГОСТ 19.202-78 ЕСПД. Спецификация. Требования к содержанию и оформлению. ГОСТ 19.301-79 ЕСПД. Порядок и методика испытаний. ГОСТ 19.401-78 ЕСПД. Текст программы. Требования к содержанию и оформлению. ГОСТ 19.402-78 ЕСПД. Описание программы. ГОСТ 19.403-79 ЕСПД. Ведомость держателей подлинников. ГОСТ 19.404-79 ЕСПД. Пояснительная записка. Требования к содержанию и оформлению. ГОСТ 19.501-78 ЕСПД. Формуляр. Требования к содержанию и оформлению. ГОСТ 19.502-78 ЕСПД. Описание применения. Требования к содержанию и оформлению. ГОСТ 19.503-79 ЕСПД. Руководство системного программиста. Требования к содержанию и оформлению. ГОСТ 19.504-79 ЕСПД. Руководство программиста. Требования к содержанию и оформлению. ГОСТ 19.505-79 ЕСПД. Руководство оператора. Требования к содержанию и оформлению. ГОСТ 19.506-79 ЕСПД. Описание языка. Требования к содержанию и оформлению. ГОСТ 19.507-79 ЕСПД. Ведомость эксплуатационных документов. ГОСТ 19.508-79 ЕСПД. Руководство по техническому обслуживанию. Требования к содержанию и оформлению. ГОСТ 19.601-78 ЕСПД. Общие правила дублирования, учета и хранения. ГОСТ 19.602-78 ЕСПД. Правила дублирования, учета и хранения программных документов, выполненных печатным образом. 82 ГОСТ 19.603-78 ЕСПД. Общие правила внесения изменений. ГОСТ 19.604-78 ЕСПД. Правила внесения изменений в программные документы, выполняемые печатным способом. ГОСТ 19.701-90 ЕСПД. Схемы алгоритмов, программ, данных и систем. Условные обозначения и правила выполнения. ГОСТ 19781-90. Обеспечение систем обработки информации программное. Термины и определения. ГОСТ 34.601-90. Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания. ГОСТ 34.602-89. Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы. ГОСТ 34.603-92. Информационная технология. Виды испытаний автоматизированных систем. MIL-STD-498. Разработка и документирование программного обеспечения. ISO 9126:1991. Информационная технология. Оценка программного продукта. Характеристики качества и руководство по их применению. IEEE 1074-1995. Процессы жизненного цикла для развития программного обеспечения. ANSI/IEEE 829-1983. Документация при тестировании программ. ANSI/IEEE 1008-1986. Тестирование программных модулей и компонентов ПС. ANSI/IEEE 983-1986. Руководство по планированию обеспечения качества программных средств. ГОСТ Р ИСО/МЭК 9294-93. Информационная технология. Руководство по управлению документированием программного обеспечения. ГОСТ Р ИСО/МЭК 9126-93. Информационная технология. Оценка программной продукции. Характеристики качества и руководство по их применению. ГОСТ Р ИСО/МЭК 9127-94. Системы обработки информации. Документация пользователя и информация на упаковке для потребительских программных пакетов. ГОСТ Р ИСО/МЭК 8631-94. Информационная технология. Программные конструктивы и условные обозначения для их представления. ГОСТ Р ИСО/МЭК 12119:1994. Информационная технология. Пакеты программных средств. Требования к качеству и испытания. ГОСТ Р ИСО/МЭК 12207. Процессы жизненного цикла программных средств. 83 СОДЕРЖАНИЕ ВВЕДЕНИЕ ................................................................................................... 3 1. ОРГАНИЗАЦИОННО-МЕТОДИЧЕСКИЕ УКАЗАНИЯ ...................... 4 1.1. Цели и задачи курсового проектирования 1 .................................... 4 1.2. Место курсового проектирования 1 в структуре ООП (связь с другими дисциплинами) ...................................................... 4 1.3. Компетенции обучающегося, формируемые в результате освоения учебной дисциплины ......................................................... 5 1.4. Основные виды занятий и особенности их проведения ............... 11 1.5. Техническое и программное обеспечение для выполнения курсовой работы .................................................. 12 1.6. Виды контроля и отчетности по дисциплине ................................ 12 2. МЕТОДИЧЕСКИЕ РЕКОМЕНДАЦИИ ПО ВЫПОЛНЕНИЮ КУРСОВОЙ РАБОТЫ ............................................................................ 14 2.1. Требования к выполнению курсового проектирования 1............. 14 2.2. Порядок выполнения курсовой работы.......................................... 15 2.3. Объем и содержание курсовой работы .......................................... 17 2.4. Методические рекомендации по использованию инструментальных средств.............................................................. 19 2.4.1. Инструментальная среда Bpwin 4.1 ...................................... 19 2.4.2. Создание модели в стандарте IDEF0 .................................... 27 2.4.4. Отображение модели данных в ERWIN ............................... 55 2.4.5. Создание логической модели данных .................................. 61 2.5. Оформление схем алгоритмов, программ, данных и систем ....... 67 2.6. Руководство пользователя ............................................................... 73 2.7. Приложения ...................................................................................... 74 3. ИНДИВИДУАЛЬНЫЕ ЗАДАНИЯ К КУРСОВОЙ РАБОТЕ ............ 74 4. УЧЕБНО-МЕТОДИЧЕСКОЕ И ИНФОРМАЦИОННОЕ ОБЕСПЕЧЕНИЕ ДИСЦИПЛИНЫ ........................................................ 80 4.1. Основная литература ....................................................................... 80 4.2. Дополнительная литература ............................................................ 81 4.3. Список государственных стандартов ............................................. 82
