- •Идеи и примеры использования er-моделей.
- •Информационные системы в современном бизнесе: классификация, области применения, решаемые задачи
- •Идеи и примеры использования sadt-моделей.
- •Основная функциональность и технологические особенности проектирования oltp-систем
- •Идеи и примеры использования dfd-моделей.
- •Поток данных определяет информацию (материальный объект), передаваемую через некоторое соединение от источника к приемнику.
- •Идеи и примеры использования SwimLine-моделей.
- •База данных как ядро современной информационной системы. Типы субд. Средства моделирования и проектирования баз данных в реляционной модели.
- •Идеи и примеры использования idef3-моделей.
- •Методы проектирования информационной системы: современные подходы, основные этапы. Методологические стратегии.
- •Идеи и примеры использования диаграмм классов.
- •Выявление и анализ требований. Методы описания бизнес-процессов.
- •Основные контуры (разделы) стандарта pm bok Guide
- •21.Модели управления командой разработчиков информационной системы. Основные роли и функции проекта. Планирование команды проекта.
- •22.Типовой сценарий и правила опроса эксперта с целью выявления требований к проекту.
- •23. Проект-ая док-я, тех зад, еспд
- •24.Идеи и примеры использования диаграмм прецедентов (Use Case).
- •Типичные примеры применения
- •26.Идеи и примеры использования диаграмм последовательностей и коопераций. Диаграммы последовательностей
- •Диаграммы кооперации
- •Типичные примеры применения
- •27. Объектный подход в проектировании и разработке ис. Понятие о методологии uml. Идеи и примеры использования диаграмм активности.
- •Типичные приемы применения
- •28. Понятие о паттернах (шаблонах) проектирования.
- •32. Технологии оценки эффективности использования проектируемой информационной системы. Методология bsc, kpi.
- •1. Возможность предупредительного информирования:
- •2. Текущий анализ доли рынка в сегментах и себестоимости в сравнении с конкурентами
- •3. Показатели эффективности работы предприятия в сравнении с конкурентами (бенчмаркинг)
- •34. Технологии управления рисками при проектировании и разработке информационных систем
- •37.Технологии моделирования прикладных интерфейсов и экранных форм
- •38. Возможные методологии моделирования функциональности и информационного обеспечения проектируемой системы (процесса)
Типичные приемы применения
Использовать диаграмму деятельности для моделирования некоторого динамического аспекта системы можно в контексте практически любого элемента модели.
При моделировании динамических аспектов системы диаграммы деятельности применяются в основном двумя способами:
для моделирования рабочего процесса. Здесь внимание фокусируется на деятельности с точки зрения актеров, которые сотрудничают с системой. Рабочие процессы часто оказываются с внешней, обращенной к пользователю стороны программной системы и используются для визуализации, специфицирования, конструирования и документирования бизнес-процессов, составляющих существо разрабатываемой системы. Для такого применения диаграмм деятельности моделирование траекторий объектов имеет особенно важное значение;
для моделирования операции. В этом случае диаграммы деятельности используются как блок-схемы для моделирования деталей вычислений. Для такого применения особенно важно моделирование точек ветвления, разделения и слияния. При этом контекст диаграммы деятельности включает параметры операции и ее локальные объекты.
28. Понятие о паттернах (шаблонах) проектирования.
Шаблоны проектирования – это это архитектурные конструкции, предоставляющие решение общей проблемы проектирования в рамках конкретного контекста и описывающая значимость этого решения, в др. формулировке – это пара «проблема - решение», содержащая рекомендации для применения в разл. конкретных ситуациях.
Проектирование в категориях паттернов – это предельная формализация структуры системы с точки зрения объектно-ориентированного подхода. Основные принципы такого подхода:
Разделение осн функций системы
Разные функции не должны реализоваться в одних и тех же компонентах
Взаимодействие через объекты – через интерфейсы
Принцип «персональной ответственности»
Шаблоны используются при:
Реализации сложных проектов
Работе больших проектных коллективов
Использовании повторяемого кода
Необходимости оптимизации кода
Экстремальном проектировании
Классификация
Архитектурные п.
Проектирования
Анализа
Тестирования
Реализации
Применимость.
Когда:
Система не должна зависеть от того, как создаются, компонуются и представляются входящие в нее объекты
Входящие в семейтсво взаимосвязанные объекты должны использоваться вместе и вам необходимо обеспечить выполнение этого ограничения
Система должна конфигурироваться одним из семейств составления ее объектов
Нужно представить бибилиотек объектов раскрывая только их интерфейс, но не реализацию
Примеры:
GoF
Архитектурные паттерны – множество преварительно определенных посистем со спецификацией их ответственности, правил и базовых принципов устанавливающих отношения между ними
Предназначены для спецификации фундаментальных схем структуризации программных систем
29. Идеи и примеры использования диаграмм состояний
Диаграммы состояний - это один из пяти видов диаграмм в языке UML, используемых для моделирования динамических аспектов системы. Диаграмма состояний показывает автомат.
Основными элементами диаграммы состояний являются «Состояние» и «Переход». Диаграмма состояний имеет схожую семантику с диаграммой деятельности, только деятельность здесь заменена состоянием, переходы символизируют действия. Таким образом, если для диаграммы деятельности отличие между понятиями «Деятельность» и «Действие» заключается в возможности дальнейшей декомпозиции, то на диаграмме состояний деятельность символизирует состояние, в котором объект находится продолжительное количество времени, в то время как действие моментально.
Состояние может содержать только имя или имя и дополнительно список внутренних действий. Список внутренних действий содержит перечень действий или деятельностей, которые выполняются во время нахождения объекта в данном состоянии. Данный список фиксированный. Список основных действий включает следующие значения:
entry - действие, которое выполняется в момент входа в данное состояние (входное действие);
exit - действие, которое выполняется в момент выхода из данного состояния (выходное действие);
do - выполняющаяся деятельность ("do activity") в течение всего времени, пока объект находится в данном состоянии
defer - событие, обработка которого предписывается в другом состоянии, но после того, как все операции в текущем будут завершены.
При использовании диаграммы состояний важно следовать следующим правилам:
Диаграмма состояний должна создаваться только для объектов, обладающих реактивным поведением. Не следует делать диаграмму автоматов для всех классов или объектов, достаточно выбрать только основные классы или объекты, обладающие сложным поведением.
Диаграмма состояний должна быть сосредоточена на описании только одного аспекта поведения объекта. Следует создавать диаграмму автомата, моделирующую поведение только одного объекта. Если необходимо показать поведение нескольких, взаимосвязанных объектов, допустимо создавать для них диаграмму состояний в рамках определенного варианта использования (диаграмма состояний для варианта использования).
На диаграмме состояний целесообразно использовать только те элементы, которые существенны для понимания описываемого аспекта.
Технологии оценки стоимости разработки информационной системы. Квалиметрическая оценка систем.
Метрики-количественные или полуколичественные параметры, позволяющие судить об эффективности операций и процессов в целом. Обычно метрики задают эксперты высокого класса. Но часто в задачу аналитика входит инициация этого процесса.
По функциональной модели строится:
Стоимостная оценка процесса
Временная оценка
Экспертным путем определяются «идеальные» параметры
показатели стоимости
Квалиметрия:
По операциям и процессу в целом определяются все значимые характеристики и их эталон
Оценивается общее качество процесса путем сравнения с эталонным:
i- номер свойства;j- номер оцениваемого объекта;qiэтиqiбр- соответственно эталонное и браковочное значения показателей свойства.
Если браковочное значение неизвестно, формула принимает вид:
31. Понятие о диаграмме развертывания и диаграмме компонентов.
Диаграммы развертывания представляют физическое расположение системы, показывая, на каком физическом оборудовании запускается та или иная составляющая программного обеспечения. Диаграммы развертывания очень просты, поэтому будем кратки.
Главными элементами диаграммы являются узлы, связанные информационными путями. Узел (node) – это то, что может содержать программное обеспечение. Узлы бывают двух типов. Устройство (device) – это физическое оборудование: компьютер или устройство, связанное с системой. Среда выполнения (execution environment) – это программное обеспечение, которое само может включать другое программное обеспечение, например операционную систему или процесс-контейнер.
Артефакты можно изображать в виде прямоугольников классов или перечислять их имена внутри узла. Можно сопровождать узлы или артефакты значениями в виде меток, чтобы указать различную интересную информацию об узле, например поставщика, операционную систему, местоположение – в общем, все, что придет вам в голову.
Артефакты часто являются реализацией компонентов. Это можно показать, задав значения-метки внутри прямоугольников артефактов.
Информационные пути между узлами представляют обмен информацией в системе. Можно сопровождать эти пути информацией об используемых информационных протоколах.
С помощью диаграмм развертывания очень удобно показывать размещение элементов, поэтому в случае любого нетривиального развертывания они могут оказаться очень полезными.
Диаграмма компонентов, в отличие от ранее рассмотренных диаграмм, описывает особенности физического представления системы. Она позволяет определить архитектуру разрабатываемой системы, установив зависимости между программными компонентами, в роли которых может выступать исходный и исполняемый код. Основными графическими элементами диаграммы компонентов являются компоненты, интерфейсы и зависимости между ними.
Диаграмма компонентов разрабатывается для следующих целей:
визуализации общей структуры исходного кода программной системы;
спецификации исполняемого варианта программной системы;
обеспечения многократного использования отдельных фрагментов программного кода;
представления концептуальной и физической схем баз данных.