Вопрос. Цели и история создания унифицированного языка UML

Вопрос. Цели и история создания унифицированного языка UML

Официально создание UML началось в октябре 1994 года. Первоначальной целью было объединение методов Буча и ОМТ/

Первая пробная версия 0.8 Унифицированного Метода (Unified Method), как его тогда называли, появилась в октябре 1995 года. Приблизительно в это же время в компанию Rational перешел Джекобсон, и проект UML был расширен с целью включить в него язык OOSE. В результате совместных усилий в июне 1996 года вышла версия 0.9 языка UML. Версия 1.0 языка появилась в результате совместных усилий компаний Digital Equipment Corporation, Hewlett Packard. Между январем и июнем 1997 года консорциум UML расширился, в него вошли практически все компании, откликнувшиеся на призыв OMG. Дальнейшая работа по развитию UML проводилась Группой по усовершенствованию (Revision Task Force, RTF) OMG под руководством Криса Кобрина. В июне 1998 года вышла версия UML 1.2, а осенью 1998 – UML 1.3.

Вопрос. Средства языка UML

Создатели UML представляют его как язык для определения, представления, проектирования и документирования программных систем, организационно-экономических систем, технических систем и других систем различной природы. UML содержит стандартный набор диаграмм и нотаций самых разнообразных видов. Стандарт UML версии 1.1, принятый OMG в 1997 г., предлагает следующий набор диаграмм для моделирования:

диаграммы вариантов использования (use case diagrams) – для моделирования бизнес-процессов организации и требований к создаваемой системе);

– диаграммы классов (class diagrams) – для моделирования статической структуры классов системы и связей между ними;

– диаграммы поведения системы (behavior diagrams):

· диаграммы взаимодействия (interaction diagrams):

¨ диаграммы последовательности (sequence diagrams) и

¨ кооперативные диаграммы (collaboration diagrams) – для моделирования процесса обмена сообщениями между объектами;

· диаграммы состояний (statechart diagrams) – для моделирования поведения объектов системы при переходе из одного состояния в другое;

· диаграммы деятельностей (activity diagrams) – для моделирования поведения системы в рамках различных вариантов использования, или моделирования деятельностей;

– диаграммы реализации (implementation diagrams):

· диаграммы компонентов (component diagrams) – для моделирования иерархии компонентов (подсистем) системы;

· диаграммы размещения (deployment diagrams) – для моделирования физической архитектуры системы.

 

 

Вопрос. Структура языка UML

Язык UML имеет сложную иерархическую структуру, показанную на Рис.3.2.

 

Вопрос. Обзор принципов разработки

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

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

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

Вопрос. Уровни прецедентов

Базо­вый прецедент находится на «уровне моря». Прецеденты уровня моря (sea level) обычно представляют отдельное взаимодействие ведущего актера и системы, которые существуют в системе, только если они включены в прецеденты уровня моря, называются прецедентами уровня рыб (fish level). Прецеденты высшего уровня, уровня воздуш­ного змея (kite-level), показывают, как прецеденты уровня моря на­страиваются на более широкое взаимодействие с бизнес-процессами. Обычно прецеденты уровня воздушного змея являются прецедентами бизнес-процессов, а на уровне моря и на уровне рыб находятся преце­денты системы.

 

 

 

Вопрос. Диаграммы классов

Диаграмма классов (англ. Static Structure diagram) — диаграмма, демонстрирующая классы системы, их атрибуты, методы и взаимосвязи между ними.

Существует два вида:

Статический вид диаграммы рассматривает логические взаимосвязи классов между собой;

Аналитический вид диаграммы рассматривает общий вид и взаимосвязи классов, входящих в систему.

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

Концептуальная точка зрения — диаграмма классов описывает модель предметной области, в ней присутствуют только классы прикладных объектов;

Точка зрения спецификации — диаграмма классов применяется при проектировании информационных систем;

Точка зрения реализации — диаграмма классов содержит классы, используемые непосредственно в программном коде (при использовании объектно-ориентированных языков программирования).

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

В верхней части написано имя класса. Имя класса выравнивается по центру и пишется полужирным шрифтом. Имена классов начинаются с заглавной буквы. Если класс абстрактный — то его имя пишется полужирным курсивом.

Посередине располагаются поля (атрибуты) класса. Они выравнены по левому краю и начинаются с маленькой буквы.

Нижняя часть содержит методы класса. Они также выравнены по левому краю и пишутся с маленькой буквы.

Декомпозиции операции

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

МЕТОД ДЕКОМПОЗИЦИИ - расчленение сложных явлений на более простые. Чем проще элементы, тем полнее проникновение в глубь явлений и определение его сущности.

Декомпозиция функций управления — это расчленение функций на составляющие их управленческие процедуры, а процедуры — на операции.

Декомпозиция (детализация) инспекционного задания до операционного уровня.

 

Вопрос. потоки и рёбра

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

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

 

 

22 вопрос. Коммуникационные диаграммы.

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

 

23 вопрос. Диаграммы компонентов

Диагра́мма компоне́нтов, Component 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.

 

вопрос. Цели и история создания унифицированного языка UML

Официально создание UML началось в октябре 1994 года. Первоначальной целью было объединение методов Буча и ОМТ/

Первая пробная версия 0.8 Унифицированного Метода (Unified Method), как его тогда называли, появилась в октябре 1995 года. Приблизительно в это же время в компанию Rational перешел Джекобсон, и проект UML был расширен с целью включить в него язык OOSE. В результате совместных усилий в июне 1996 года вышла версия 0.9 языка UML. Версия 1.0 языка появилась в результате совместных усилий компаний Digital Equipment Corporation, Hewlett Packard. Между январем и июнем 1997 года консорциум UML расширился, в него вошли практически все компании, откликнувшиеся на призыв OMG. Дальнейшая работа по развитию UML проводилась Группой по усовершенствованию (Revision Task Force, RTF) OMG под руководством Криса Кобрина. В июне 1998 года вышла версия UML 1.2, а осенью 1998 – UML 1.3.

Вопрос. Средства языка UML

Создатели UML представляют его как язык для определения, представления, проектирования и документирования программных систем, организационно-экономических систем, технических систем и других систем различной природы. UML содержит стандартный набор диаграмм и нотаций самых разнообразных видов. Стандарт UML версии 1.1, принятый OMG в 1997 г., предлагает следующий набор диаграмм для моделирования:

диаграммы вариантов использования (use case diagrams) – для моделирования бизнес-процессов организации и требований к создаваемой системе);

– диаграммы классов (class diagrams) – для моделирования статической структуры классов системы и связей между ними;

– диаграммы поведения системы (behavior diagrams):

· диаграммы взаимодействия (interaction diagrams):

¨ диаграммы последовательности (sequence diagrams) и

¨ кооперативные диаграммы (collaboration diagrams) – для моделирования процесса обмена сообщениями между объектами;

· диаграммы состояний (statechart diagrams) – для моделирования поведения объектов системы при переходе из одного состояния в другое;

· диаграммы деятельностей (activity diagrams) – для моделирования поведения системы в рамках различных вариантов использования, или моделирования деятельностей;

– диаграммы реализации (implementation diagrams):

· диаграммы компонентов (component diagrams) – для моделирования иерархии компонентов (подсистем) системы;

· диаграммы размещения (deployment diagrams) – для моделирования физической архитектуры системы.

 

 

Вопрос. Структура языка UML

Язык UML имеет сложную иерархическую структуру, показанную на Рис.3.2.