- •Учреждение «университет «туран»
- •Кафедра «компьютерная и программная инженерия» учебно-методический комплекс по дисциплине «методы структурного анализа и проектирования»
- •Алматы, 2012
- •Учреждение «Университет «Туран»
- •Алматы, 2012
- •Пояснительная записка
- •Общие данные по рабочей программе
- •Краткое описание дисциплины
- •Цель преподавания дисциплины
- •Задачи изучения дисциплины
- •Уровень знаний, умений, навыков и компетенций, приобретаемый магистрантом по завершении изучения данной дисциплины:
- •Пререквизиты дисциплины
- •Постреквизиты дисциплины
- •Тематика срм
- •Список рекомендуемой литературы
- •Официальные интернет издания
- •Алматы, 2012
- •Пояснительная записка
- •Общие данные по рабочей программе
- •Краткое описание дисциплины
- •Цель преподавания дисциплины
- •Задачи изучения дисциплины
- •Уровень знаний, умений, навыков и компетенций, приобретаемый магистрантом по завершении изучения данной дисциплины:
- •Пререквизиты дисциплины
- •Постреквизиты дисциплины
- •Темы и продолжительность их изучения
- •Тематика семинарских (практических) занятий
- •График сдачи срм и время консультаций
- •Тематика срм
- •Вопросы для проведения контроля
- •Информация по оценке знаний
- •Критерии оценки знаний обучающихся (обобщенные)
- •Определение итоговой оценки по вск
- •Итоговая оценка
- •Процедура апелляции
- •Требования преподавателя Политика и процедуры курса
- •Правила поведения на аудиторных занятиях
- •График выполнения и сдачи заданий по дисциплине задания самостоятельной работы:
- •Тематика и график сдачи срмп
- •График сдачи срм и время консультаций
- •Тематика срм
- •Учреждение «Университет «Туран»
- •1.2. Идеи, лежащие в основе структурных методов
- •1.3. Принципы структурного анализа
- •1.4. Средства структурного анализа и их взаимоотношения
- •2.1. Основные символы
- •2.2. Контекстная диаграмма и детализация процессов
- •2.3. Декомпозиция данных и соответствующие расширения диаграмм потоков данных
- •2.4. Построение модели
- •2.5. Расширения реального времени
- •[Gl]Тема 3. Словарь данных. Методы задания спецификаций.[:]
- •3.1. Содержимое словаря данных
- •Методы задания спецификаций процессов
- •3.4. Таблицы и деревья решений
- •3.5. Визуальные языки проектирования спецификаций
- •3.6. Сравнение методов
- •[Gl]Тема 4. Диаграммы “сущность-связь”[:]
- •4.1. Сущности, отношения и связи в нотации Чена
- •4.2. Диаграммы атрибутов
- •4.3. Категоризация сущностей
- •4.4. Нотация Баркера
- •4.5. Построение модели
- •[Gl]Тема 5. Средства структурного проектирования [:]
- •5.1. Структурные карты Константайна
- •5.2. Структурные карты Джексона
- •5.3. Характеристики хорошей модели реализации
- •5.3.1. Сцепление
- •5.3.2. Связность
- •5.3.3. Другие принципы проектирования
- •5.4. Транзакционный и трансформационный анализ или как получить структурные карты из диаграмм потоков данных
- •6.1. Методологии структурного анализа Йодана/Де Марко и Гейна-Сарсона
- •6.2. Sadt - технология структурного анализа и проектирования
- •6.3. Сравнительный анализ sadt-моделей и потоковых моделей
- •6.4. Методология ssadm
- •6.5. Методологии, ориентированные на данные
- •6.6. Основные этапы подхода Мартина
- •8.1. Эволюция case - средств
- •8.2. Case-модель жизненного цикла по
- •8.3. Состав, структура и функциональные особенности case-средств
- •8.4. Поддержка графических моделей
- •8.5. Контроль ошибок
- •8.6. Организация и поддержка репозитария
- •8.7. Поддержка процесса проектирования и разработки
- •[Gl] тема 9. Классификация case - средств[:]
- •Среди большого числа методов оценки деятельности предприятий наибольшее распространение (по крайней мере в отечественных консалтинговых проектах) получили следующие два:
- •10.1. Динамическое моделирование с использованием сетей Петри
- •План семинарских (практических)занятий
- •Методические рекомендации по изучению дисциплины
- •«Методы структурного анализа и проектирования»
- •(По работе с учебно-методическим комплексом)
- •Основания, целевая аудитория и ориентированность учебно-методического комплекса
- •Структура, содержание и образовательные возможности учебно-методического комплекса
- •Рекомендуемый порядок работы с учебно-методическим комплексом
- •Материалы для самостоятельной работы обучающегося
- •Методические рекомендации по выполнению срм по дисциплине «методы структурного анализа и проектирования»
- •Самостоятельная внеаудиторная работа
- •Критерии оценки знаний, навыков
- •Примерная тематика исследований срм:
- •Тематика и график сдачи срмп
- •Требования к выполнению контрольных заданий по дисциплине «методы структурного анализа и проектирования»
- •Некоторые варианты самостоятельных заданий для магистрантов по дисциплине «методы структурного анализа и проектирования»
- •Тема 1. Понятие консалтинга в области информационных технологий
- •Тема 3. Методы задания спецификаций процессов
- •2. Таблицы и деревья решений
- •4.3. Визуальные языки проектирования спецификаций
- •4. Сравнение методов
- •Тема 4. Проведение обследования деятельности предприятия
- •4.1. Цели и основные этапы консалтинга
- •4.2. Проведение обследования
- •1) Положение о подразделении
- •2) Набор документальных форм без внутреннего наполнения, т.Е. Используемые формы, бланки и др. (например, карточка складского учета, отчет по форме n, наряд-задание, товарно-транспортная накладная)
- •Тема 5. Построение моделей
- •5.1. Построение и анализ моделей деятельности предприятия
- •5.2. Разработка системного проекта
- •Некоторые практические занятия
- •Формирование структурного представления системы
- •Диаграммы компонентов
- •Пример Теста промежуточного контроля
- •Программное и мультимедийное сопровождение учебных занятий по дисциплине «методы структурного анализа и проектирования»
- •Перечень специализированных аудиторий, кабинетов и лабораторий
- •Карта обеспеченности дисциплины учебной и учебно-методической литературой
6.6. Основные этапы подхода Мартина
IE-методология Мартина предоставляет общую стратегию разработки информационных систем, фокусирующую внимание на стратегическом планировании и бизнес-процессах. В то же время она является и инженерным подходом к разработке ПО, т.к. обеспечивает нисходящую пошаговую процедуру построения информационной системы (позволяя при этом работать с неиерархическими структурами данных). Подход Мартина базируется на двух концепциях:
послойного целостного подхода к разработке интегрированных приложений, базирующегося на стратегическом плане развития информационных систем;
первоначальной направленности на моделирование данных, а затем на функциональное моделирование
Основные этапы подхода Мартина приведены на рис. 6.7.
Рис. 6.7. Основные этапы подхода Мартина
Этап стратегического информационного планированияначинается с построения стратегического плана для бизнес-системы, включающего цели и стратегии их достижения. Далее строится модель предметной области, отражающая существующую специфику и определяющая основные бизнес-процессы и организационную структуру бизнес-системы, а также определяется порядок разработки информационной системы. При моделировании используются диаграммы декомпозиции (иерархические древовидные структурные диаграммы) и диаграммы "сущность-связь" для представления основных бизнес-процессов и структур данных, соответственно.
На этапе анализаосновные бизнес-процессы, разработанные на этапе 1), используются для разбиения общей задачи на частные, при этом основное внимание уделяется определению информационной и функциональной моделей для частных задач. При этом диаграммы "сущность-связь" трансформируются в нормализованную модель данных, а диаграммы декомпозиции распределяются по подзадачам. Для представления процессов служат DFD, диаграммы зависимости данных (диалект DFD) и диаграммы декомпозиции, а для соотнесения данных и процессов, в которых эти данные используются, применяются матрицы "сущность/процесс".
На этапе логического проектированияIE становится аналогична SE для разработки ПО. Базой для проектирования являются процессы, разработанные на этапе анализа. Используя методики нисходящей функциональной декомпозиции, проектируются спецификации обработки в процессах и их логические структуры данных. При этом используются диаграммы структуры данных (диалект ERD), определяющие типы сущностей, их атрибуты и связи, диаграммы декомпозиции и диаграммы деятельности (вид миниспецификации), детализирующие логику процессов. Для согласования требований пользователя создаются прототипы пользовательских интерфейсов с помощью схем экранов/отчетов.
На этапе физического проектированияи реализации производится преобразование логической модели ИС в физическую и ее реализация.[kgl]
[gl] ТЕМА 7. АРХИТЕКТУРА СОВРЕМЕННЫХ СИСТЕМ И МЕТОДОЛОГИИ [:]
В центре любой методологии находится некоторая системная архитектура, и лишь затем совокупность стратегий и методов анализа и проектирования. Архитектура современных систем является трехслойной (рис.7.1) и имеет следующие характеристики:
четко определенные слои
формальные и явные интерфейсы между слоями
скрытые и защищенные детали внутри каждого слоя.
ПОЛЬЗОВАТЕЛЬ
ДОКУМЕНТЫ |
ПРАВИЛА БИЗНЕСА |
БАЗА ДАННЫХ |
ОПЕРАЦИОННАЯ СИСТЕМА
Рис. 7.1. Архитектура современной системы
Три слоя (база данных, правила бизнеса, документы) отражают возрастание уровня абстракции в рассматриваемой системной архитектуре. Наиболее детальным слоем является база данных, более высокий уровень абстракции - слой правил бизнеса, наивысший уровень абстракции - слой документов. В данной архитектуре слой правил бизнеса является относительно новой концепцией, соответствующей функциям руководителей среднего звена. Процессы данного слоя отражают:
выполнение требуемых задач
принятие решений в соответствующей компетенции
запуск других задач в слое правил бизнеса и других слоях.
Независимость слоев трехслойной системной архитектуры обеспечивает следующие основные преимущества:
улучшение базы данных - отделение базы данных от изменений в технологиях, а, следовательно, поддержка согласованности и осмысленности данных в течение длительного периода времени;
гибкость интерфейсов пользователя - изменение интерфейсов без влияния на бизнес-процессы и наоборот;
разделение усилий коллектива разработчиков.
Трехслойная архитектура (а именно, выделение слоя бизнес-правил) требует модификации существующих методологий, в первую очередь, информационно-ориентированных методологий и методологий, ориентированных на данные. Такие методологии имеют следующие две характеристики, нуждающиеся в изменении:
информационная модель (и база данных) рассматриваются как центральные понятия при анализе и проектировании;
функциональная модель (а, следовательно, и правила бизнеса) является некоторым дополнением к информационной модели.
Согласно такому подходу, информационная модель является первичной, занимает центральное место и регламентирует весь процесс анализа и проектирования, что приводит к следующим ограничениям:
построенная на ее основе функциональная модель либо является слабо связанной с информационной моделью, либо неадекватно отражает существующие бизнес-процессы и правила;
сама по себе информационная модель является недостаточной (хотя и важной) для решения задач консалтинга;
информационная модель плохо понимаема неспециалистами, поэтому попытки вовлечь руководство в разработку обречены на неудачу.
С другой стороны, руководство прекрасно ориентируется в технологиях и бизнес-процессах предприятия. Более того, функциональные модели (например, на базе диаграмм потоков данных) интуитивно понимаемы неспециалистами.
Таким образом, в центре современного проекта лежат две вещи - база данных и бизнес-процесс. При этом основным центром является бизнес-процесс, база данных - менее важный из двух центров, т.е. процесс становится первичным и во многом определяет весь проект. Модель процесса является ценным средством для размышлений и совместной работы над перспективами развития предприятия и системной разработкой. Тем не менее, информационная модель продолжает оставаться важной и соответствующим образом влиять на разрабатываемую функциональную модель.
В таблице 7.1 представлена трехслойная системная архитектура в разрезе регламентируемых методологией этапов разработки (анализ требований, проектирование, реализация).
Таблица 7.1
Слои |
Анализ |
Проектирование |
Реализация |
Документы |
Поток работ |
Поток форм |
Формы |
Правила бизнеса |
Поток процессов |
Модель компонентов |
Программы |
База данных |
Модель данных |
Схема базы данных |
Таблицы и т.п. |
Анализ требований. В слое документа рассматриваются обобщенные потоки между подразделениями и конкретными сотрудниками предприятия без подробного описания каких-либо учетных форм и интерфейсов. На уровне правил бизнеса рассматриваются детальные модели требований. На уровне базы данных строится концептуальная модель, увязанная с функциональной моделью требований на уровне укрупненных подсхем будущей информационной модели.
Проектирование. На уровне документа макетируются последовательности форм. На уровне бизнес-правил осуществляется детальное проектирование будущих рабочих мест с привязкой к конкретным сущностям информационной модели. На уровне базы данных концептуальная модель преобразуется в диаграмму “сущность-связь”.
Реализация. На данном этапе проект преобразуется в систему.
[kgl]
[gl] ТЕМА 8. КОНЦЕПТУАЛЬНЫЕ ОСНОВЫ CASE – ТЕХНОЛОГИЙ [:]