вопрос. Диаграммы взаимодействия

Диаграммы взаимодействия описывают поведение совместно действующих групп объектов в рамках потока событий. На диаграмме отображается ряд объектов и сообщения, которыми они обмениваются между собой. Сообщение – это средство, с помощью которого объект-отправитель запрашивает у объекта-получателя выполнение одной из его операций. Существует два вида диаграмм взаимодействия: диаграммы кооперации (collaboration diagram) и диаграммы последовательности (sequence diagram). Семантически они эквивалентны. Ниже описываются основные свойства этих диаграмм.

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

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

 

Вопрос Диаграммы объектов

Диаграмма объектов (Object diagram) — демонстрирует полный или частичный снимок моделируемой системы в заданный момент времени. На диаграмме объектов отображаются экземпляры классов (объекты) системы с указанием текущих значений их атрибутов и связей между объектами.

 

26 вопрос Диаграмма развертывания

Диаграмма развёртывания (Deployment diagram, диаграмма размещения) — служит для моделирования работающих узлов (аппаратных средств, англ. node) и артефактов, развёрнутых на них. В UML 2 на узлах разворачиваются артефакты (англ. artifact), в то время как в UML 1 на узлах разворачивались компоненты. Между артефактом и логическим элементом (компонентом), который он реализует, устанавливается зависимость манифестации.

 

 

27 вопрос Диаграмма активностей

диаграммы активностей (Activity Diagrams) являются представлением алгоритмов неких действий (активностей), выполняющихся в системе. Мы уже знаем, что нотация UML предлагает пять представлений системы:

·Вид системы с точки зрения прецедентов.

Вид с точки зрения проектирования.

·Вид с точки зрения процессов.

·Вид с точки зрения развертывания.

Вид с точки зрения реализации.

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

 

28 вопрос Четыре представления модели Rational Rose

В модели Rose поддерживаются четыре представления - это представление вариантов использования, логическое представле­ние, представление компонентов и представление размещения. Каж­дое из них предназначено для своих целей. Представление вариантов использования содер­жит всех действующих лиц, все варианты использования и их ди­аграммы для конкретной системы. Оно может также содержать некоторые диаграммы последовательности и кооперативные ди­аграммы.

Представление вариантов использования содержит:

1. Действующих лиц.

2. Варианты использования.

3. Документацию по вариантам использования, описывающую происходящие в них процессы (потоки событий), включая обработку ошибок. Эта пиктограмма соответствует внешнему файлу, прикрепленному к модели Rose.

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

29. Определение требований к системе и ее анализ

Анализ требований — часть процесса разработки программного обеспечения, включающая в себя сбор требований к программному обеспечению (ПО), их систематизацию, выявление взаимосвязей, а также документирование.

Анализ требований включает три типа деятельности:

· Сбор требований — общение с клиентами и пользователями, чтобы определить, каковы их требования; анализ предметной области.

· Анализ требований — определение, являются ли собранные требования неясными, неполными, неоднозначными или противоречащими; решение этих проблем; выявление взаимосвязи требований.

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

 

30. Этапы проектирования реализации и тестирование системы.

Этап 1. Концептуальный - работа по изучению предметной области (типов, элементов, видов отношений, ограничений и требований по времени, ресурсам, способам переработки информации, цели функционирования системы).

Этап 2. Формализация - создание схемы системы на логическом уровне (т.е. с помощью математических отношений и выражений).

Этап 3. Оптимизация - это оптимизация структуры системы на уровне схемы до конкретного внедрения системы: для этого необходимо уметь оценивать проект на уровне структурной и функциональной сложности

Тестирование обеспечивает:

· Обнаружение ошибок.

· Демонстрацию соответствия функций программы ее назначению.

· Демонстрацию реализации требований к характеристикам программы.

· Отображение надежности как индикатора качества программы.

Тестирование не может показать отсутствие дефектов (оно может показывать только присутствие дефектов). Важно помнить это утверждение при проведении тестирования.

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

· Тестирование не повышает качества ПО - оно указывает на качество программы, но не влияет на него.

31. Диаграммы "сущность-связь"

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

32. Инструментальная среда BPwin

BPwin имеет достаточно простой и интуитивно понятный интерфейс пользователя. При запуске BPwin по умолчанию появляется основная панель инструментов, палитра инструментов (вид которой зависит от выбранной нотации) и, в левой части, навигатор модели — Model Explorer. BPwin поддерживает три методологии — IDEF0, IDEF3 и DFD, каждая из которых решает свои специфические задачи.. Модель в BPwin рассматривается как совокупность работ, каждая из которых оперирует с некоторым набором данных. Работа изображается в виде прямоугольников, данные — в виде стрелок. Если щелкнуть по любому объекту модели левой кнопкой мыши, появляется контекстное меню, каждый пункт которого соответствует редактору какого-либо свойства объекта.

33. Сто́имостный ана́лиз системы

Функциона́льно-сто́имостный ана́лиз (функционально-стоимостной анализ, ФСА) — метод системного исследования функций объекта с целью поиска баланса между себестоимостью и полезностью^[1]. Используется как методология непрерывного совершенствования продукции, услуг, производственных технологий, организационных структур.

34. Обзор приложений Microsoft visio

Microsoft Visio — векторный графический редактор, редактор диаграмм и блок-схем для Windows.

Выпускается в трёх редакциях: Standard, Professional и Pro for Office 365

Первоначально Visio разрабатывался и выпускался компанией Visio Corporation. Microsoft приобрела компанию в 2000 году, тогда продукт назывался Visio 2000, был выполнен ребрендинг, и продукт был включен в состав Microsoft Office^[

 

Visio 1.0 (Standard, Lite, Home)

Visio 2.0

Visio 3.0

Visio 4.0 (Standard, Technical)

Visio 4.1 (Standard, Technical)

Visio 4.5 (Standard, Professional, Technical)

Visio 5.0 (Standard, Professional, Technical)

Visio 2000 (6.0; Standard, Professional, Technical, Enterprise)

Visio 2002 (10.0; Standard, Professional)

Visio Enterprise Network Tools, Visio Network Center

Visio for Enterprise Architects 2003 (VEA 2003) (based on Visio 2002 and included with Visual Studio.NET 2003

36.Проектирование систем реального времени

Процесс проектирования СРВ, представленный в [3]

1. Определение множества входных сигналов, которые будут обрабатываться системой, и соответствующих им системных реакций.

2. Для каждого входного сигнала и соответствующего ему ответного сигнала вычисляются временные ограничения.

3. Объединение процессов обработки входных и ответных сигналов в виде совокупности параллельных процессов. В корректной модели системной архитектуры каждый процесс связан с определённым классом входных и ответных сигналов.

4. Разработка алгоритмов, выполняющих необходимые вычисления для всех входных и выходных сигналов. Чтобы получить представление об объёмах вычислительных и временных затрат в процессе обработки сигналов, разработка алгоритмов обычно проводится на ранних этапах процесса проектирования.

5. Разработка временного графика работы системы.

6. Сборка системы, работающей под управлением диспетчера.

 

37. Обзор систем управления версиями для Windows

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

Такие системы наиболее широко используются при разработке программного обеспечения для хранения исходных кодов разрабатываемой программы.

Традиционные системы управления версиями используют централизованную модель, когда имеется единое хранилище документов, управляемое специальным сервером, который и выполняет бо́льшую часть функций по управлению версиями.

 

38. Система управления версиями Subvrsion

Subversion ^[3] (также известная как «SVN»^[4]) — свободная централизованная система управления версиями, официально выпущенная в 2004 году компанией CollabNet^[en].. Subversion используется многими сообществами разработчиков открытого программного обеспечения (в том числе сообществами, ранее использовавшими CVS)

Разработка Subversion была начата в 2000 году по инициативе и при финансовой поддержке CollabNet.. Выбрав её за основу, разработчики Subversion надеялись упростить разработку за счёт использования уже проверенных концепций и в то же время облегчить переход на новую систему многочисленным пользователям CVS.

39. Система планирования

В разных ОС процессы реализуются по-разному. Эти различия заключаются в том, какими структурами данных представлены процессы, как они именуются, какими способами защищены друг от друга и какие отношения существуют между ними. Процессы Windows NT имеют следующие характерные свойства:

Процессы Windows NT реализованы в форме объектов, и доступ к ним осуществляется посредством службы объектов.-

Процесс Windows NT имеет многонитевую организацию.-

Как объекты-процессы, так и объекты-нити имеют встроенные средства синхронизации.-

Менеджер процессов Windows NT не поддерживает между процессами отношений типа "родитель-потомок".-

В любой системе понятие "процесс" включает следующее:

исполняемый код,-

В Windows NT процесс - это просто объект, создаваемый и уничтожаемый менеджером объектов. Объект-процесс, как и другие объекты, содержит заголовок, который создает и инициализирует менеджер объектов. Менеджер процессов определяет атрибуты, хранимые в теле объекта-процесса, а также обеспечивает системный сервис, который восстанавливает и изменяет эти атрибуты.

 

 

40. Система планирования Microsoft Project

Microsoft Project (или MSP) — программа управления проектами, разработанная и продаваемая корпорацией Microsoft.

Microsoft Project создан, чтобы помочь менеджеру проекта в разработке планов, распределении ресурсов по задачам, отслеживании прогресса и анализе объёмов работ. Microsoft Project создаёт расписания критического пути. Расписания могут быть составлены с учётом используемых ресурсов. Цепочка визуализируется в диаграмме Ганта

Под маркой Microsoft Project доступны сразу несколько продуктов и решений:

· Microsoft Project Standard — однопользовательская версия для небольших проектов

· Microsoft Project Professional — корпоративная версия продукта, поддерживающая совместное управление проектами и ресурсами, а также управление портфелями проектов с помощью Microsoft Project Server.

· Microsoft Project Web Access — Web-интерфейс для отчетности о выполнении задач, а также просмотра портфелей проектов

· Microsoft Project Portfolio Server — продукт для отбора проектов для запуска на основе сбалансированных показателей, вошел в состав Microsoft Project Server с версии MS Project 2010

Начиная с 2013 года Microsoft начинает поставлять облачную версию Microsoft Project Online.