МЕТОДОЛОГИИ ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ.
презентация к уроку
вопрос о методологии проектирования ИС
Скачать:
Вложение | Размер |
---|---|
metodologii_proektirovaniya_informatsionnyh_sistem.ppt | 1.23 МБ |
Предварительный просмотр:
Подписи к слайдам:
3.1 Методология структурного моделирования SADT Сущность структурного подхода Основные принципы структурного подхода
Сущность структурного подхода к моделированию систем Система разбивается на функциональные подсистемы, которые, в свою очередь, делятся на подфункции, подфункции – на задачи и т.д. до конкретных процедур Система Функция 1 Функция 2 … Функция n Подфункция 2 … … Задача 2 … Подфункция 1 … Задача 1 … … Задача n … … Подфункция n …
Ключевые понятия структурного анализа Структурным анализом принято называть метод исследования системы, которое начинается с ее общего обзора, а затем детализируется, приобретая иерархическую структуру с все большим числом уровней. Функция – совокупность операций, сгруппированных по определенному признаку. Бизнес-процесс — связанная совокупность функций, в ходе выполнения которой потребляются определенные ресурсы и создается продукт (предмет, услуга, научное открытие, идея), представляющая ценность для потребителя. Подпроцесс – это бизнес-процесс, являющийся структурным элементом некоторого бизнес-процесса и представляющий ценность для потребителя. Бизнес-модель – структурированное графическое описание сети процессов и операций, связанных с данными, документами, организационными единицами и прочими объектами, отражающими существующую или предполагаемую деятельность предприятия.
Базовые принципы структурного подхода принцип "разделяй и властвуй" – принцип решения сложных проблем путем их разбиения на множество меньших независимых задач, легких для понимания и решения; принцип иерархического упорядочивания – принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.
Основные принципы структурного подхода Принцип абстрагирования – выделение существенных с некоторых позиций аспектов системы и отвлечении от несущественных с целью представления проблемы в простом общем виде. Принцип формализации –необходимость строгого методического подхода к решению проблемы. Принцип упрятывания –упрятывание несущественной на конкретном этапе информации: каждая часть "знает" только необходимую ей информацию. Принцип концептуальной общности –следование единой философии на всех этапах ЖЦ информационных систем (структурный анализ – структурное проектирование – структурное программирование – структурное тестирование). Принцип полноты –контроль на присутствие лишних элементов. Принцип непротиворечивости –обоснованность и согласованность элементов. Принцип логической независимости – заключается в концентрации внимания на логическом проектировании для обеспечения независимости от физического проектирования. Принцип независимости данных –модели данных должны быть проанализированы и спроектированы независимо от процессов их логической обработки, а также от их физической структуры и распределения. Принцип структурирования данных –данные должны быть структурированы и иерархически организованы. Принцип доступа конечного пользователя –пользователь должен иметь средства доступа к базе данных, которые он может использовать непосредственно (без программирования).
Структурный подход к проектированию ИС SADT ( Structured Analysis and Design Technique - Технология структурного анализа и проектирования) - одна из самых известных и широко используемых систем проектирования. Создатель методологии SADT – Дуглас Росс. На ее основе разработана известная методология IDEF0 (Icam DEFinition), которая является основной частью программы “Интеграция компьютерных и промышленных технологий”, проводимой по инициативе ВВС США.
Основные положения методологии SADT графическое изображение блоков и дуг SADT-диаграммы отображает функцию в виде блока, а входы и выходы представляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описываются с помощью дуг, выражающих "ограничения", которые определяют, когда и каким образом функции выполняются и управляются; выполнение правил SADT требует строгости и точности, не накладывая в то же время сильных ограничений на действия аналитика. Правила SADT: ограничение количества блоков на каждом уровне декомпозиции (как правило 3-6 блоков); связь диаграмм осуществляется при помощи нумерации блоков; метки и наименования должны быть уникальными, т.е. не допускается повторение имен; входы и управления должна разделяться.
С тандарт ы IDEF ( Integrated Computer Aided Manufacturing DEFinition ) IDEF0 - методология функционального моделирования. Система отображается в виде набора взаимосвязанных функциональных блоков. IDEF1 – методология моделирования информационных потоков внутри системы, позволяющая отображать и анализировать их структуру и взаимосвязи; IDEF1X (IDEF1 еХtended) – методология построения реляционных структур. IDEF1X относится к типу методологий “Сущность-взаимосвязь” (ER – Entity-Relationship) и используется для моделирования реляционных баз данных в системе; IDEF3 – методология документирования процессов. С помощью IDEF3 описываются сценарий и последовательность операций для каждого процесса. IDEF4 – методология построения объектно-ориентированных систем.
Сущность функционального моделирования В основе функционального моделирования лежит функциональное содержание системы , в качестве отношений между функциями рассматривается информация об объектах , связывающих эти фун кции.
Состав функциональной модели SADT-модель - это описание системы, у которого есть единственный субъект, цель и одна точка зрения. Цель - набор вопросов, на которые должна ответить модель. Точка зрения - позиция, с которой описывается система.
Синтаксис SADT -диаграмм Диаграммы содержат блоки и дуги; Блоки представляют функции; Блоки имеют доминирование (выражается в их ступенчатом расположении, причем доминирующий блок располагается в левом верхнем углу диаграммы); Дуги изображают наборы объектов, передаваемых между блоками; Дуги изображают различные типы взаимосвязей между блоками: выход – управление выход – вход обратная связь по управлению обратная связь по входу выход – механизм.
Декомпозиция функциональных диаграмм Подфункция функция Подфункция 1 Подфункция 1 Подфункция 2 Подфункция 3 А0 А1 А2 А3 Контекстная диаграмма определяет все функции, входы и выходы, которые могут появиться на диаграммах нижних уровней Каждая подфункция может содержать только те элементы, которые входят в исходную функцию. Выход Выход Управление Вход IDEF0
Пример SADT- диаграмм(контекстная диаграмма)
3.1.1 Методология IDEF0 Сущность методологии функционального моделирования IDEF0 Основные понятия методологии IDEF0 Правила построения моделей IDEF0 Пример функциональной модели в нотации IDEF 0
Основные понятия методологии IDEF0 Модель – искусственный объект, представляющий собой отображение (образ) системы и ее компонентов. Система представляет собой совокупность взаимосвязанных и взаимодействующих частей, выполняющих некоторую полезную работу. Лаконичность и точность. Документация, описывающая систему, должна быть точной и лаконичной. Передача информации. Средства IDEF0 облегчают передачу информации от одного участника разработки модели (отдельного разработчика или рабочей группы) к другому. Строгость и формализм. Разработка моделей IDEF0 требует соблюдения ряда строгих формальных правил, обеспечивающих преимущества методологии в отношении однозначности, точности и целостности сложных многоуровневых моделей. Итеративное моделирование. Разработка модели в IDEF0 представляет собой пошаговую, итеративную процедуру. Отделение «организации» от «функций». При разработке моделей следует избегать изначальной «привязки» функций исследуемой системы к существующей организационной структуре моделируемого объекта (предприятия, фирмы).
Функциональный блок Олицетворяет некоторую конкретную функцию или работу в рамках рассматриваемой системы РД IDEF0 – 2000 : прямоугольник, содержащий имя и номер и используемый для описания функции Управлять предприятием А0 управление вход выход механизм Наименование осуществляется оборотом глагола или существительного Каждый блок в рамках единой системы имеет уникальный номер Каждая сторона функционального блока имеет свое назначение
Интерфейсная дуга Интерфейсная дуга отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, отображаемую функциональным блоком. Графически изображается в виде однонаправленной стрелки. Каждая дуга должна иметь свое уникальное название , сформулированное оборотом существительного (должно отвечать на вопросы кто?, что?). Примеры : информация, разработчик, документ, обработанная заявка. В зависимости от того, к какой стороне блока она подходит, интерфейсная дуга будет являться входящей, выходящей, управления, механизма .
Интерфейсная дуга Функциональный блок А0 управление вход выход механизм Ресурсы, необходимые для проведения работы (человеческие ресурсы, оборудование, ИС). Ресурсы, перерабатываемые системой Регулирует работу системы, управляет (нормативная документация и т.п.) Результат работы системы, переработанные ресурсы, продукт деятельности Стрелки входа может не быть. Остальные интерфейсные дуги обязательны.
Декомпозиция Принцип декомпозиции применяется при разбиении сложных процессов на составляющие его функции. При этом уровень детализации определяется непосредственно разработчиком модели. Модель IDEF 0 всегда начинается с рассмотрения системы как единого целого, т.е. одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма называется контекстной , она обозначается идентификатором А-0. Для определения границ системы на контекстной диаграмме обязательно должны быть цель и точка зрения.
Контекстная диаграмма верхнего уровня Эта диаграмма называется A-0 (А ноль). Стрелки на этой диаграмме отображают связи объекта моделирования с окружающей средой.
Цель моделирования Цель моделирования должна отвечать на следующие вопросы: Почему процесс должен быть смоделирован? Что должна показывать модель? Что может получить читатель? Примеры целей : «Идентифицировать слабые стороны процесса сбора данных», «Определить ответственность сотрудников для написания должностных инструкций» и т.п.
Точка зрения Точка зрения – позиция, с которой будет строиться модель. В качестве точки зрения берется взгляд человека, который видит систему в нужном для моделирования аспекте. Как правило, выбирается точка зрения человека, ответственного за выполнение моделируемой работы. Между целью и точкой зрения должно быть жесткое соответствие .
Декомпозиция А0 Цель: Т.зрения: А-0 А1 А3 А2 А0 А11 А13 А12 А1 А31 А33 А32 А3 Контекстная диаграмма Декомпозиция контекстной диаграммы Декомпозиция блока А1 Декомпозиция блока А3
Декомпозиция А0 А1 А2 А3 А11 А12 А13 А0 ____________ А1____________ А11___________ А12___________ А13___________ А2____________ А3____________ Дерево узлов Индекс узлов
Нумерация работ и диаграмм А0 Цель: Т.зрения: А-0 А1 А3 А2 А0 А11 А13 А12 А1 А31 А33 А32 А3 Номер контекстной диаграммы Номер функционального блока на контекстной диаграмме Диаграммы декомпозиции имеют номер декомпозируемого блока Формат номера блока: Префикс Номер родительской работы 3. Собственный порядковый номер
Основные правила построения диаграмм 1. На одной диаграмме рекомендуется рисовать от 3 до 6 блоков. Иначе диаграмма будет плохо читаемой. 2. Функциональные блоки должны располагаться слева направо сверху вниз в порядке доминирования. 3. Следует избегать излишнего пересечения стрелок.
Основные правила построения диаграмм 4. Выход одного блока может являться входом (управлением) для другого. Могут быть и обратные связи по входу и управлению. Связь по входу Связь по управлению
Основные правила построения диаграмм а) обратная связь по входу б) обратная связь по управлению Обратная связь по входу , как правило, используется для описания циклов. Обратная связь по управлению – выход нижестоящей работы передается на управление вышестоящей Обратная связь по механизму – выход нижестоящей работы создает ресурсы, выполняющие вышестоящую работу в) обратная связь по механизму
Основные правила построения диаграмм 5. Стрелки могут быть сливающимися и разветвляющимися Слияние стрелок Разветвление стрелок
Ветвление и слияние сегментов стрелок непомеченные сегменты содержат все объекты, указанные в метке стрелки перед ветвлением (т.е. все объекты принадлежат каждому из сегментов)
Ветвление и слияние сегментов стрелок сегменты, помеченные после точки ветвления, содержат все объекты, указанные в метке стрелки перед ветвлением, или их часть, описываемую меткой каждого конкретного сегмента;
Ветвление и слияние сегментов стрелок при слиянии непомеченных сегментов объединенный сегмент стрелки содержит все объекты, принадлежащие сливаемым сегментам и указанные в общей метке стрелки после слияния
Ветвление и слияние сегментов стрелок при слиянии помеченных сегментов объединенный сегмент содержит все или некоторые объекты, принадлежащие сливаемым сегментам и перечисленные в общей метке после слияния; если общая метка после слияния отсутствует, это означает, что общий сегмент передает все объекты, принадлежащие сливаемым сегментам;
Туннельные стрелки Иногда необходимо отобразить граничные стрелки, которые значимы на данном уровне и не значимы на родительской диаграмме. Например, некоторые данные используются только на данном уровне и не используются на других. Без использования механизма туннелирования малозначимая стрелка появится на всех уровнях модели, что затруднит чтение диаграмм.
Пример модели процесса постройки садового домика Построить дом Материалы Строители Дом Проект дома Цель: Определить действия, необходимые для постройки дачного домика Точка зрения: владельца дачного участка 1. Строим контекстную диаграмму .
Пример модели процесса постройки садового домика 2. Декомпозируем контекстную диаграмму Заложить фундамент Возвести стены Положить крышу Выполнить отделку Материалы Проект дома Строители Дом Каменщики Плотники Кровельщики Мастера по отделке Фундамент Стены Крыша
3.1.2 Диаграммы потоков данных ( DFD ) Определение и функциональное назначение DFD -моделей Основные компоненты DFD -моделей Иерархия DFD
Что такое DFD -модель DFD – Data Flow Diagrams – диаграммы потоков данных Модель системы определяется как иерархия диаграмм потоков данных, описывающих асинхронный процесс преобразования информации от ее входа в систему до выдачи пользователю.
Что такое DFD -модель? Главная цель такого представления – продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами. Примечание . DFD -модели могут быть использованы в дополнение к модели IDEF 0 для более наглядного отображения текущих операций документооборота в корпоративных системах обработки информации.
Основные компоненты диаграмм потоков данных Основными компонентами диаграмм потоков данных являются: внешние сущности системы и подсистемы процессы накопители данных потоки данных.
Нотации, используемые в DFD -моделировании Нотации DFD -моделирования Гейна-Сарсона (Gene-Sarson) Йордона-ДеМарко ( Yordon-DeMarco ) Примечание . В зависимости от используемой нотации графическое представление элементов диаграмм будет различным
Внешняя сущность Представляет собой материальный объект или физическое лицо , являющееся источником или приемником информации (например, заказчики, клиенты, поставщики, склад, персонал, банк). Внешняя сущность находится за пределами границ анализируемой системы. Одна и та же внешняя сущность может быть использована многократно на одной или нескольких диаграммах. Внешняя сущность в нотации Гейна-Сарсона Внешняя сущность в нотации Йордона-ДеМарко Имя
Система и подсистема При построении модели сложной системы она может быть представлена в самом общем виде на так называемой контекстной диаграмме в виде одной системы , либо в виде ряда подсистем . Наименование системы/подсистемы представляется в виде словосочетания с отглагольным существительным (рассмотрение повестки дня, решение задачи, получение денег и т.п.). Наименование системы 1 Персонал, оборуд-е Поле идентификации Поле имени Поле физической реализации Система/подсистема в нотации Гейна-Сарсона Имя системы/ подсистемы 1 имя или Система/подсистема в нотации Йордона-ДеМарко
Процесс Представляет собой преобразование входных потоков в выходные в соответствии с определенным алгоритмом. Примеры : обработка входных документов и выпуск отчетности определенным подразделением, процессы физически реализованного устройства. Процесс именуется в виде словосочетания с активным глаголом в неопределенной форме, за которым следует существительное в винительном падеже.
Процесс Наименование процесса 1.1 Персонал, оборуд-е Поле идентификации Поле имени Поле физической реализации Процесс в нотации Гейна-Сарсона !!!!! Процесс отличается от системы/подсистемы по полю наименования !!!! Процесс в нотации Йордона-ДеМарко Имя процесса 1 имя или
Накопитель данных Это абстрактное устройство для хранения информации, которую можно в любой момент поместить в накопитель и через некоторое время извлечь. Примеры : ящик в картотеке, таблицы в ОЗУ, файл на электронном носителе Примечание: В нотациях Гейна-Сарсона и Йордона-ДеМарко графическое представление данного элемента аналогичное.
Поток данных Определяет информацию, передаваемую через некоторые соединения от источника к приемнику. Реальный поток данных может быть информацией, передаваемой по кабелю между двумя устройствами, пересылаемыми по почте письмами и т.п. Деканат Заполнить ведомость Преподаватель 1.1.1 Ведомость
Нумерация объектов Системы, подсистемы [ Префикс ] + собственный номер Процессы [ Префикс ] +номер родительской подсистемы+собственный номер Внешние сущности [ Префикс ] +номер Хранилища данных [ Префикс ] +номер
Уровни DFD -модели Уровень системы Уровень подсистемы Уровень процесса
Построение иерархии DFD 1. Построение диаграмм уровня системы и подсистемы
Построение иерархии DFD 2. Построение диаграмм уровня процесса
Пример DFD -модели постройки дачного домика 1. Контекстная диаграмма уровня системы
Пример DFD -модели постройки дачного домика 2. Диаграмма уровня подсистемы
Пример DFD -модели постройки дачного домика 3. Диаграмма уровня процесса
3.1.3 Методология IDEF 3 Понятие динамического моделирования Методология IDEF3 Основные элементы динамической модели Правила и особенности построения IDEF3 -модели Декомпозиция в IDEF3
Что отражает модель IDEF3 ? В общем случае, процесс – это упорядоченная последовательность действий . Следовательно, процессная модель IDEF3 позволяет : Отразить последовательность процессов Показать логику взаимодействия элементов системы. Цель IDEF 3 - дать возможность аналитикам описать ситуацию, когда процессы выполняются в определенной последовательности, а также объекты, участвующие совместно в одном процессе.
Основные элементы диаграмм IDEF3 Точка зрения на модель - это точка зрения человека, ответственного за работу в целом. Цель модели — те вопросы, на которые призвана ответить модель. Единицы работы - Unit of Work (UOW) , также называемые работами ( activity ), являются центральными компонентами модели. Связи . Связи показывают взаимоотношения работ. Перекрестки - используются для отображения логики взаимодействия стрелок при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы. Объект ссылки - в IDEF 3 выражает некую идею, концепцию или данные, которые нельзя связать со стрелкой, перекрестком или работой.
Единицы работ Единица работ ( UOW , Unit of Work ) является центральным компонентом модели. Номер работы является уникальным, присваивается при ее создании и не меняется никогда Словосочетание с отглагольным существительным , изображающим действие (выполнение, изготовление,…) Или Инфинитив глагола (изготовить продукцию)
Связи Связи показывают взаимоотношения работ. Связи однонаправлены и могут быть направлены куда угодно Обычно диаграммы рисуют таким образом, чтобы связи были направлены слева направо Различают 3 типа связей: Старшая стрелка Стрелка отношений Поток объектов.
Связь «старшая стрелка» Связь типа « временное предшествование » - Precedence Соединяет единицы работ Показывает, что работа-источник должна быть закончена прежде , чем начнется работа-цель 1.1 1.1 ´ 1. 2 1. 2 ´
Стрелка отношений Связь типа нечеткое отношение - Relational Изображается в виде пунктирной линии , используется для изображения связи между единицами работ, а также между единицами работ и объектами ссылок 1.1 1.2 1.1 ´ 1. 2 ´
Поток объектов Стрелка, изображающая поток объектов - Object Flow Применяется для описания того факта, что объект используется в двух и более единицах работ, например, когда объект порождается в одной работе и используется в другой
Перекрестки (соединения) Используются для отображения логики взаимодействия стрелок при их слиянии или разветвлении , для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы. Различают перекрестки для слияния и разветвления стрелок. Перекрестки не могут быть одновременно использованы для слияния и разветвления стрелок. Все перекрестки на диаграммах нумеруются , каждый номер имеет префикс J . В отличие от других методологий ( IDEF 0, DFD ) стрелки могут сливаться или разветвляться только через перекрестки .
Типы перекрестков Обозна-чение Наименование Смысл в случае слияния стрелок Смысл в случае разветвления стрелок Асинхрон-ное «И» Все предшествующие процессы должны быть завершены Все последующие процессы должны быть запущены Синхрон-ное «И» Все предшествующие процессы должны быть завершены одновременно Все последующие процессы запускаются одновременно Асинхрон-ное «ИЛИ» Один или несколько предшествующих процессов должны быть завершены Один или несколько следующих процессов должны быть запущены
Типы перекрестков Обозна-чение Наименование Смысл в случае слияния стрелок Смысл в случае разветвления стрелок Синхронное «ИЛИ» Один или несколько предшествующих процессов должны быть завершены одновременно Один или несколько следующих процессов должны быть запущены одновременно Эксклюзивное (исключающее) «ИЛИ» Только один предшествующий процесс должен быть завершен Только один следующий процесс запускается
Правила создания перекрестков 1. Каждому перекрестку для слияния должен предшествовать перекресток для разветвления . 2. Перекресток для слияния «И» не может следовать за перекрестком для разветвления типа синхронного или асинхронного «ИЛИ»
Правила создания перекрестков 3. Перекресток для слияния «И» не может следовать за перекрестком типа исключительного «ИЛИ»
Правила создания перекрестков 4. Перекресток для слияния типа исключительного «ИЛИ» не может следовать за перекрестком для разветвления типа «И» 5. Перекресток, имеющий одну стрелку на одной стороне, должен иметь более одной стрелки на другой.
Примеры
Примеры
Примеры
Комбинации перекрестков Перекрестки могут комбинироваться для создания сложных соединений
Объект ссылок выражает идею , концепцию данных , которые нельзя связать со стрелкой, перекрестком, работой используется при построении диаграммы для привлечения внимания пользователя к каким-либо важным аспектам модели
Объект ссылок Официальная спецификация IDEF 3 различает 3 стиля объектов ссылок – безусловные ( unconditional ), синхронные ( synchronous ), асинхронные ( asynchronous ). BPWin поддерживает только безусловные объекты ссылок.
Типы объектов ссылок Тип объекта ссылок Назначение 1. Object Используется для описания того, что в действии принимает участие какой-либо заслуживающий отдельного внимания объект 2. Ссылка GOTO Используется для реализации цикличности выполнения действий. Этот объект также может относиться к перекрестку 3. Единица действий UOB ( Unit of Behavior) Используется для многократного отображения на диаграмме одного и того же действия, но без цикла
Типы объектов ссылок Тип объекта ссылок Назначение 4. Заметка ( Note ) Используется для документирования какой-либо важной информации общего характера, относящейся к изображаемому на диаграммах. Служит альтернативой методу помещения текстовых заметок непосредственно на диаграммах 5. Уточнение Elaboration ( ELAB ) Для уточнения или более подробного описания изображаемого на диаграмме. Обычно используется для детального описания разветвления или слияния стрелок на перекрестках
Декомпозиция работ в IDEF3 В IDEF 3 декомпозиция используется для детализации работ. Методология IDEF 3 позволяет декомпозировать работу многократно , т.е. работа может иметь множество дочерних работ. Это позволяет в одной модели описать альтернативные потоки . Возможность множественной декомпозиции предъявляет дополнительные требования к нумерации работ
Нумерация работ в IDEF3 Номер работы состоит из номера родительской работы , версии декомпозиции и собственного номера работы на текущей диаграмме Номер родительской работы Версия декомпозиции Собственный номер единицы работ
Первая декомпозиция работы 1.2 Структура множественной декомпозиции работ Вторая декомпозиция работы 1.2
Пример построения модели IDEF3 Рассмотрим на примере построения динамической модели процесса «Выполнение курсовой работы» Начнем с построения контекстной диаграммы 1.1 Выполнение курсовой работы
Пример построения модели IDEF3 1.1.2 Получение задания 1.1.3 Подбор литературы 1.1.4 Выполнение разделов к/р 1.1.5 Посещение консультаций 1.1.6 Оформление пояснит. записки 1.1.7 Защита OBJECT/ Преподаватель Примечание : Обратите внимание на нумерацию единиц работ. Родительской является работа с собственным номером 1 . Она декомпозируется первый раз, следовательно, версия декомпозиции = 1 , далее следует собственный номер единицы работ в рамках модели ( 2 - 7 ). Выполним декомпозицию контекстной диаграммы: & J1 & J2
Пример построения модели IDEF3 4 .1.8 Написание теор.части 4 .1.9 Выполнение расчетов 4 .1.10 Построение графиков 4 .1.11 Оформление ELAB/ Если есть ошибки в расчетах – внесение исправлений Выполним декомпозицию UOW №4 – «Выполнение разделов к/р» & J3 & J4 Х J5 Х J6
Пример построения модели IDEF3 Продекомпозируем повторно контекстную диаграмму (в виде сценария IDEF3 для выполнения курсовой работы по «Информатике и программированию») 1.2.12 Получение задания 1.2.13 Построение блок-схемы 1.2.14 Математическое моделирование 1.2.15 Написание программы 1.2.16 Тестирование и отладка 1.2.17 Оформление поясн. записки GOTO/ При обнаружении ошибок при тестировании возврат к 1.2.15 & J7 & J8
Построение информационной модели процесса постройки садового домика 1. На основе функциональной модели IDEF0 составим пул – список потенциальных сущностей. Пул: 1. Дом 2. Крыша 3. Материалы 4. Проект дома 5. Стены 6. Строители 7. Фундамент 8. Каменщики 9. Плотники 10. Кровельщики 11. Мастера по отделке
Построение информационной модели процесса постройки садового домика 2. Определим сущности
Построение информационной модели процесса постройки садового домика 3. Зададим атрибуты для каждой сущности и установим связи между ними
По теме: методические разработки, презентации и конспекты
ФОНДЫ ОЦЕНОЧНЫХ СРЕДСТВ по междисциплинарному курсу «Информационные технологии и платформы разработки информационных систем» (МДК.02.01) профессионального модуля «Разработка информационных систем» (ПМ.02)
Фонд оценочных средств содержит материал для промежуточной аттестации студентов 2 курса 4 семестра....
Методические рекомендации к курсовому проектированию по дисциплине ОП.15 Системы автоматизированного проектирования информационного вычислительных сетей специальность 090903 Информационная безопасность автоматизированных систем
Методические рекомендации к курсовому проектированию по дисциплине ОП.15 Системы автоматизированного проектирования информационного вычислительных сетей ...
ПМ.05. ПРОЕКТИРОВАНИЕ И РАЗРАБОТКА ИНФОРМАЦИОННЫХ СИСТЕМ
Методические указания по выполнению практических работ по МДК. 05.01 Проектирование и дизайн информационных систем разработаны в соответствии с рабочей программой ПМ.05. Проектирование и разработка ин...
Контрольно-оценочное средство по ПМ.05 Проектирование и разработка информационных систем
Комплект оценочных средств предназначен для оценки результатов освоения профессионального модуля ПМ.05.Проектирование и разработка информационных систем обязательной части основной профессиональной об...
ДИДАКТИЧЕСКОЕ ОБЕСПЕЧЕНИЕ РАЗДЕЛА «ПОСТРОЕНИЕ ФУНКЦИОНАЛЬНЫХ И ОБЪЕКТНО-ОРИЕНТИРОВАННЫХ МОДЕЛЕЙ ИНФОРМАЦИОННЫХ СИСТЕМ» ДИСЦИПЛИНЫ «ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ» С ИСПОЛЬЗОВАНИЕМ ИНСТРУМЕНТАЛЬНОЙ СРЕДЫ MS VISIO
Информационные системы играют большую роль в деятельности современных предприятий и организаций. Важная составляющая информационных систем – это их проектирование, в процессе которого создаются ...
Рабочая программа ПМ05. Проектирование и разработка информационных систем
Рабочая программа ПМ05. Проектирование и разработка информационных систем для специальности 09.02.07 Информационные системы и программировние...
МЕТОДИЧЕСКИЕ РЕКОМЕНДАЦИИ ПО ВЫПОЛНЕНИЮ И ОФОРМЛЕНИЮ КУРСОВОЙ РАБОТЫ по ПМ 05.Проектирование и разработка информационных систем
Методические рекомендации по выполнению и оформлению курсовой работы подготовлены для специальности 09.02.07 Информационные системы и программирование ГБПОУ "Саткинский горно-керамический колледж...