Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
otvety.doc
Скачиваний:
55
Добавлен:
28.03.2016
Размер:
292.35 Кб
Скачать

Типичные приемы применения

Использовать диаграмму деятельности для моделирования некоторого динамического аспекта системы можно в контексте практически любого элемента модели.

При моделировании динамических аспектов системы диаграммы деятельности применяются в основном двумя способами:

  • для моделирования рабочего процесса. Здесь внимание фокусируется на деятельности с точки зрения актеров, которые сотрудничают с системой. Рабочие процессы часто оказываются с внешней, обращенной к пользователю стороны программной системы и используются для визуализации, специфицирования, конструирования и документирования бизнес-процессов, составляющих существо разрабатываемой системы. Для такого применения диаграмм деятельности моделирование траекторий объектов имеет особенно важное значение;

  • для моделирования операции. В этом случае диаграммы деятельности используются как блок-схемы для моделирования деталей вычислений. Для такого применения особенно важно моделирование точек ветвления, разделения и слияния. При этом контекст диаграммы деятельности включает параметры операции и ее локальные объекты.

28. Понятие о паттернах (шаблонах) проектирования.

Шаблоны проектирования – это это архитектурные конструкции, предоставляющие решение общей проблемы проектирования в рамках конкретного контекста и описывающая значимость этого решения, в др. формулировке – это пара «проблема - решение», содержащая рекомендации для применения в разл. конкретных ситуациях.

Проектирование в категориях паттернов – это предельная формализация структуры системы с точки зрения объектно-ориентированного подхода. Основные принципы такого подхода:

  • Разделение осн функций системы

  • Разные функции не должны реализоваться в одних и тех же компонентах

  • Взаимодействие через объекты – через интерфейсы

  • Принцип «персональной ответственности»

Шаблоны используются при:

  • Реализации сложных проектов

  • Работе больших проектных коллективов

  • Использовании повторяемого кода

  • Необходимости оптимизации кода

  • Экстремальном проектировании

Классификация

  • Архитектурные п.

  • Проектирования

  • Анализа

  • Тестирования

  • Реализации

Применимость.

Когда:

  • Система не должна зависеть от того, как создаются, компонуются и представляются входящие в нее объекты

  • Входящие в семейтсво взаимосвязанные объекты должны использоваться вместе и вам необходимо обеспечить выполнение этого ограничения

  • Система должна конфигурироваться одним из семейств составления ее объектов

  • Нужно представить бибилиотек объектов раскрывая только их интерфейс, но не реализацию

Примеры:

  • GoF

Архитектурные паттерны – множество преварительно определенных посистем со спецификацией их ответственности, правил и базовых принципов устанавливающих отношения между ними

Предназначены для спецификации фундаментальных схем структуризации программных систем

29. Идеи и примеры использования диаграмм состояний

Диаграммы состояний - это один из пяти видов диаграмм в языке UML, используемых для моделирования динамических аспектов системы. Диаграмма состояний показывает автомат.

Основными элементами диаграммы состояний являются «Состояние» и «Переход». Диаграмма состояний имеет схожую семантику с диаграммой деятельности, только деятельность здесь заменена состоянием, переходы символизируют действия. Таким образом, если для диаграммы деятельности отличие между понятиями «Деятельность» и «Действие» заключается в возможности дальнейшей декомпозиции, то на диаграмме состояний деятельность символизирует состояние, в котором объект находится продолжительное количество времени, в то время как действие моментально. 

Состояние может содержать только имя или имя и дополнительно список внутренних действий. Список внутренних действий содержит перечень действий или деятельностей, которые выполняются во время нахождения объекта в данном состоянии. Данный список фиксированный. Список основных действий включает следующие значения:

  • entry - действие, которое выполняется в момент входа в данное состояние (входное действие);

  • exit - действие, которое выполняется в момент выхода из данного состояния (выходное действие);

  • do - выполняющаяся деятельность ("do activity") в течение всего времени, пока объект находится в данном состоянии

  • defer - событие, обработка которого предписывается в другом состоянии, но после того, как все операции в текущем будут завершены.

При использовании диаграммы состояний важно следовать следующим правилам:

  • Диаграмма состояний должна создаваться только для объектов, обладающих реактивным поведением. Не следует делать диаграмму автоматов для всех классов или объектов, достаточно выбрать только основные классы или объекты, обладающие сложным поведением.

  • Диаграмма состояний должна быть сосредоточена на описании только одного аспекта поведения объекта. Следует создавать диаграмму автомата, моделирующую поведение только одного объекта. Если необходимо показать поведение нескольких, взаимосвязанных объектов, допустимо создавать для них диаграмму состояний в рамках определенного варианта использования (диаграмма состояний для варианта использования).

  • На диаграмме состояний целесообразно использовать только те элементы, которые существенны для понимания описываемого аспекта.     

  1. Технологии оценки стоимости разработки информационной системы. Квалиметрическая оценка систем.

Метрики-количественные или полуколичественные параметры, позволяющие судить об эффективности операций и процессов в целом. Обычно метрики задают эксперты высокого класса. Но часто в задачу аналитика входит инициация этого процесса.

По функциональной модели строится:

Стоимостная оценка процесса

Временная оценка

Экспертным путем определяются «идеальные» параметры

показатели стоимости

Квалиметрия:

По операциям и процессу в целом определяются все значимые характеристики и их эталон

Оценивается общее качество процесса путем сравнения с эталонным:

i- номер свойства;j- номер оцениваемого объекта;qiэтиqiбр- соответственно эталонное и браковочное значения показателей свойства.

Если браковочное значение неизвестно, формула принимает вид:

31. Понятие о диаграмме развертывания и диаграмме компонентов.

Диаграммы развертывания представляют физическое расположение системы, показывая, на каком физическом оборудовании запускается та или иная составляющая программного обеспечения. Диаграммы развертывания очень просты, поэтому будем кратки.

Главными элементами диаграммы являются узлы, связанные информационными путями. Узел (node) – это то, что может содержать программное обеспечение. Узлы бывают двух типов. Устройство (device) – это физическое оборудование: компьютер или устройство, связанное с системой. Среда выполнения (execution environment) – это программное обеспечение, которое само может включать другое программное обеспечение, например операционную систему или процесс-контейнер.

Артефакты можно изображать в виде прямоугольников классов или перечислять их имена внутри узла. Можно сопровождать узлы или артефакты значениями в виде меток, чтобы указать различную интересную информацию об узле, например поставщика, операционную систему, местоположение – в общем, все, что придет вам в голову.

Артефакты часто являются реализацией компонентов. Это можно показать, задав значения-метки внутри прямоугольников артефактов.

Информационные пути между узлами представляют обмен информацией в системе. Можно сопровождать эти пути информацией об используемых информационных протоколах.

 С помощью диаграмм развертывания очень удобно показывать размещение элементов, поэтому в случае любого нетривиального развертывания они могут оказаться очень полезными.

Диаграмма компонентов, в отличие от ранее рассмотренных диаграмм, описывает особенности физического представления системы. Она позволяет определить архитектуру разрабатываемой системы, установив зависимости между программными компонентами, в роли которых может выступать исходный  и исполняемый код. Основными графическими элементами диаграммы компонентов являются компоненты, интерфейсы и зависимости между ними.

Диаграмма компонентов разрабатывается для следующих целей:

  • визуализации общей структуры исходного кода программной системы;

  • спецификации исполняемого варианта программной системы;

  • обеспечения многократного использования отдельных фрагментов программного кода;

  • представления концептуальной и физической схем баз данных.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]