Функции системы и используемые ими ресурсы моделируются с использованием стандарта

Содержание
  1. Способ описания функциональных требований к системе и ее функций с использованием стандартов и универсального языка моделирования
  2. Авторы: Алфимов Р.В., Красникова С.А., Золотухина Е.Б. (сертифицированный специалист по решениям IBM Rational, преподаватель в Учебно-Консалтинговом центре компании «Интерфейс»).
  3. Шаблон описания требования
  4. Практика формирования требований в ИТ проектах от А до Я. Часть 3. Функции системы и Границы проекта
  5. VI Определяем функции системы и границы проекта
  6. 1. Используем нотацию IDEF0 для определения функций системы и границ проекта
  7. 2. Пример описания функции “Управление требованиями”
  8. 3. Пример описания функции “Сбор потребностей заказчика”
  9. 4. Пример описания функции “Управления спецификациями требований”
  10. 5. Пример описания функции “Управление заданиями”
  11. 6. Пример описания функции “Управление выполнением”
  12. 7. Подведем итоги процесса определения функций системы и границ проекта
  13. Функции системы и используемые ими ресурсы моделируются с использованием стандарта
  14. Проектирование информационных систем
  15. Методология IDEF0
  16. Методология Data Flow Diagram
  17. Внешние сущности:
  18. Процессы:
  19. Хранилища данных:
  20. Потоки данных:
  21. Алгоритм построения диаграммы
  22. Типичные ошибки построения DF-диаграмм
  23. Роль методологий в анализе моделируемого объекта (Выводы)
  24. Использование UML для проектирования систем

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

Авторы: Алфимов Р.В., Красникова С.А., Золотухина Е.Б. (сертифицированный специалист по решениям IBM Rational, преподаватель в Учебно-Консалтинговом центре компании «Интерфейс»).

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

В данной статье представлен способ описания функциональных требований к АС и ее функций с использованием стандартов в области информационных технологий, современных методологий создания АС, и диаграмм «Use Case Diagram» и «Actvity Diagram» универсального языка моделирования UML 2.0. Авторы рассчитывают, что использование «Use Case» в контексте определения требований в соответствии со стандартами создания АС приобретет большую ясность.

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

При использовании стандартов создания АС в соответствии с [1, 2] на стадии «Техническое задание» в документе техническое задание (ТЗ) фиксируются функциональные и нефункциональные требования к АС. Схема функциональной структуры АС разрабатывается на стадии «Эскизное проектирование» и «Техническое проектирование», описание автоматизируемых функций АС производится на стадии «Техническое проектирование».

При разработке АС в соответствии с [1] должны быть отслежены связи между функциональными требованиями к системе и функциями системы, их реализующими. Функции системы в свою очередь должны быть детально описаны.

В табл. 1. представлены стадии работ по созданию АС и документы, формируемыми на стадиях, связанных с описанием требований и функций 1.

Как видно из табл. 1, создание АС на стадиях 3-5, подразумевает подготовку:

Таблица 1. Стадии создания АС и документы, связанные с требованиями к АС и функциями, их реализующими

№ стадии по ГОСТ 34.601-90

Наименование
стадии по ГОСТ 34.601-90

Документы, модели, создаваемые на стадиях по

ГОСТ 34.602-89,
ГОСТ 34.201-89

ГОСТ, в котором описан документ

Техническое задание (ТЗ)

Схема функциональной структуры

Схема функциональной структуры

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

Не функциональные требования есть ограничения, накладываемые на работу системы, и стандарты, которым должна соответствовать система [5].

В схеме функциональной структуры [7] отображаются элементы функциональной структуры АС (подсистемы АС), автоматизированные функции и (или) задачи (комплексы задач), совокупности действий (операций), выполняемых при реализации автоматизированных функций только техническими средствами (автоматически) или только человеком.

В описании автоматизируемых функций [7] приводят:

Рассмотрим, например, подход компании Sparx System, являющейся производителем инструментария Еnterprise Architect, поддерживающим создание моделей предметной области и АС с использованием UML 2.0. Ими предложен шаблон модели требований, представленный на рис. 1. На рис. 2 представлен пример модели требования с использованием шаблона.

Как видно из шаблона модели требований и его примера для моделирования требований предлагается использовать элемент UML «Requirement». Для моделирования функций системы предлагается использовать элемент «Use Case». При этом элемент «Use Case» в описании UML, представленном в инструменте Еenterprise Architect, трактуется следующим образом: «Use Case elements are used to build Use Case models. These describe the functionality of the system to be built. Use Case Model describes a system’s functionality in terms of Use Cases».

Другими словами, элемент «Use Case» используется для построения модели «Use case Model». Модель «Use case Model» используется для описания функциональности системы.

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

В спецификациях OMG UML ( UML Superstructure Specification, v2.0, p. 17 ) элемент «Use Case» определяется как: «The specification of a sequence of actions, including variants, that a system (or other entity) can perform, interacting with actors of the system».

Другими словами, элемент «Use Case» определяет последовательность действий системы, которые она может выполнять, включая ее взаимодействие с пользователем системы.

16728 65040549

Рис. 1. Способ моделирования требований к системе

16728 65040550

В дополнении к сказанному выше, хотелось представить определение модели «Use Case Model» из популярного в нашей стране и за рубежом процесса разработки систем Rational Unified Process компании IBM: «The use-case model is a model of the system’s intended functions and its environment …»[5] (рис. 3).

16728 65040551

Рис. 3. Определение модели «Use Case Model»

Модель «Use case Model» есть модель предполагаемых функций системы и ее окружения, и служит контрактом между клиентами и разработчиками. Модель используется как существенные входные данные в деятельности по анализу, проектированию и тестированию.

В табл. 2 представлено сравнение определений схемы функциональной структуры в соответствии с ГОСТ и модели «Use Case Model», функции системы и элемента «Use Case» в соответствии с описанием UML 2.0.

Таблица 2. Сравнение определений моделей и их элементов

Определение схемы функциональной структуры

Определение модели «UseCaseModel»

В схеме функциональной структуры отображаются элементы функциональной структуры АС (подсистемы АС), автоматизированные функции и (или) задачи (комплексы задач), совокупности действий (операций), выполняемых при реализации автоматизированных функций только техническими средствами (автоматически) или только человеком

Use Case elements are used to build Use Case models. These describe the functionality of the system to be built.

Use Case Model describes a system’s functionality in terms of Use Cases

Определение элемента «UseCase»

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

The specification of a sequence of actions, including variants, that a system (or other entity) can perform, interacting with actors of the system.

Сравнение определения схемы функциональной структуры с определением модели Use Case Model, определения функции системы и элементов «Use Case» показывает, что эти модели и элементы сопоставимы друг с другом.

Таким образом, для моделирования требований к АС мы будем использовать элемент требование «Requirement», а функций, реализующих требование, элемент «Use Case».

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

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

Шаблон описания требования

Общие сведения о требовании

Должно быть автоматизировано формирование отчета об остатках товара

Цель, которая будет
достигнута при реализации
требования

Оперативное получение информации о текущих остатках на складе компании

Требование руководителя компании

Пользователи, которым
доступна работа с функциями системы, реализующими требование

Источник данных (ручной ввод, использование записей БД, данных из смежной системы)

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

Правила, связанные с
требованием

Отчет формируется в двух экземплярах

Функции, реализующие требования

Формирование отчета «Остатки товара»

Связи между требованием и функциями

В разделе должно быть представлена модель, отображающая связи между требования и функциями, реализующими требование, и если требуется, описание связей. Модель «Требование и функции»:

16728 65040552

Описание процесса выполнения функции

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

Источник

Практика формирования требований в ИТ проектах от А до Я. Часть 3. Функции системы и Границы проекта

VI Определяем функции системы и границы проекта

Каждая модель ограничена в своих ответах, но нет ограничения на то, как и что моделирует модель, как нет ограничения на человеческую мысль
Дуглас Т. Росс

06d14059a0514b939013da53ed98eba4

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

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

Границы проекта (project scope) показывают, какая область конечного продукта будет реализована в текущем проекте. Другими словами, определяется черта между тем, что мы будем делать сейчас и тем, что отложим на потом или от чего вообще сможем отказаться. Для этого в арсенале команды должен быть инструмент, позволяющий не просто строить модели создаваемого продукта, а помогающий наглядно очертить рамки автоматизируемых процессов, а также предоставлять возможность легко выносить процессы за границу или включать их обратно. Это очень важно для осознания и более качественного планирования объемов работ. Подобный инструмент полезен не только для «борьбы» с непомерными желаниями заказчика, но и для маневров менеджмента со стороны разработчиков.

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

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

16db3c058c274cb2853a00fb025ddab9
Рисунок 6.1 — модель процесса определения функций

1. Используем нотацию IDEF0 для определения функций системы и границ проекта

Наиболее удобной методикой функционального моделирования, с точки зрения определения границ проекта, на мой взгляд является “старая добрая” методология проектирования SADT, использующая иерархическую декомпозицию сверху вниз. Применение диаграмм IDEF0 имеет следующие преимущества перед аналогами:

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

Этот вид моделирования позволит нам также определить процессы, которые были выпущены из поля зрения на предыдущих этапах.

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

2. Пример описания функции “Управление требованиями”

Хочу напомнить основные постулаты стандарта IDEFO. Графическую конструкцию стандарта составляют: понятие «Работа» (Activity) для обозначения действия, представленная в виде блока; четыре вида интерфейса: «Вход» (Input), «Выход» (Output), «Управление» (Control) и «Механизм» (Mechanism), представленный в виде дуг. Левая сторона блока предназначена для входов, верхняя — для управления, правая — для выходов, нижняя — для механизмов. Для более подробного изучения этой темы обратитесь к [2].

На первом шаге моделирования необходимо определить все потоки данных, поступающих в систему из вне (входные сигналы). В нашем случае это:

f34a430008ec425b9ec9c9659c6812b6
Рис.6.2 – Функциональная модель системы Управления требованиями верхнего уровня

Проваливаясь во внутрь функции (блока «Работа») мы попадаем на следующий уровень абстракции функциональности системы. Вначале мы видим только потоки данных, выявленные на предыдущем этапе (уровне), см. рис. 6.3.

dcdf7cad4e304c35aa06b9c414e809df
Рис.6.3 – Начало работы по детализации функции Управление ИТ проектами

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

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

0a0d4e86a42f485eae5a2ae1cbfbf79f
Рис.6.4 – Определение подпроцессов для функции Управление ИТ проектами

В нашем проекте, согласно изложенным в главе IV целям и выявленным на первом этапе потокам данных, необходимо автоматизировать следующую группу процессов:

Поскольку большинство процессов логически связаны между собой, необходимо установить все потоки данных, обеспечивающие эти связи. Таким образом от функции к функции на диаграмме появляются дуги. Позже, каждая такая дуга (связь), входящая в блок «Работы», должна будет, при моделировании следующего вложенного уровня, “получить” свой процесс обработки.

Пример модели этих функций с уже установленными взаимосвязями отображены на Диаграмме см. Рис. 6.5.

eaab8d60e5ba4117b154e5583f6bc12e
Рис.6.5 – Функциональная модель системы Управления требованиями

Если такие диаграммы используют в документе необходимо сопровождать их подробным описанием. Дальше приведен пример описания:

На рисунке видно, что функциональную архитектуру нашего проекта представлена в виде четырех доменов:

Из диаграммы видно, что блок “А1” имеет обратную связь от блока “А2”, в виде управляющей информации, доводящей о степени реализации требований, сформированных по Пользовательским историям (дуга «Отчет о реализации требований»). Эта связь позволяет отследить ход и полноту реализации Пользовательской истории в конечном продукте по цепочке, через спецификации требований.

Второй блок, как показано на схеме, получает на вход обработанные пожелания заказчика в виде Пользовательских историй, потребностей пользователей и т.п. уже в формализованном виде. На основании этих данных в нем формируются функциональные требования к разрабатываемому продукту и формализуются в виде спецификаций требований. Дальше эти спецификации передаются в четвертый блок “А4”, отвечающий за выставление задания исполнителям на их реализацию. Из диаграммы видно, что задания могут выставляться и на выполнение работ с требованиями (дуга «Задания», входящая в качестве управления в блок “А2”). Обратите внимание на то, что во второй функциональный блок возвращаются данные об исполнении заданий по спецификациям, что позволяет в этом домене определить приращение функциональности, полученное в ходе разработки.

В третий блок направим из блока “А2”, в качестве управляющих инструкций, ключевые показатели спецификаций. На основании их можно определить степень достижения заданной функциональности, используя отчет о выполнении задний, выставленных по этим спецификациям исполнителям. Отчет поступает в виде входящих параметров из блока “А4”.

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

3. Пример описания функции “Сбор потребностей заказчика”

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

Заглянем в блок А1 на рисунке 6.4, представляющий домен «Сбор потребностей заказчика». Его детализация показана на рисунке 6.5. Все потоки данных, которые входили в блок А1 на рисунке 6.4, соответственно попали и в детализирующую его диаграмму см. рис. 6.6.

cb41ec1d57584af89329ddcdd73d97eb
Рис. 6.6 – Схема домена Сбор потребностей заказчика

Функционально домен мы разделили на четыре процесса:

4. Пример описания функции “Управления спецификациями требований”

Следующее уточнение произведем с доменом «Управление спецификациями требований проекта» (А2). На рисунке 6.7 изображена диаграмма этой модели.

Функционально домен делим на четыре процесса:

5. Пример описания функции “Управление заданиями”

На рисунке 6.8 изображена диаграмма, представляющая домен Управления Заданиями проекта (А4). Функционально домен мы разделили на четыре процесса:

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

Для процесса 5.2 опишем следующую Пользовательскую историю:

US12. На основании плана итераций проекта отобрать пул задач, которые необходимо реализовать на данном этапе.
Цель: Получить список задач для реализации в текущей итерации проекта.

Процесс 5.3 затрагивает несколько Пользовательских историй:

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

В случае наступления риска, выполняется пользовательская история US8.

6. Пример описания функции “Управление выполнением”

На рисунке 6.9 изображена диаграмма, представляющая домен Управления выполнения проекта. Реализация этого домена немного выходит за рамки нашего проекта, но тесно с ним связана. Поэтому рассмотрим и его.

49543f1eac8b449eb5004672c4ba5962
Рис. 6.9 – Схема домен Управления выполнения проекта

Функционально домен мы разделили на четыре процесса:

7. Подведем итоги процесса определения функций системы и границ проекта

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

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

В итоге, опираясь на разработанные нами диаграммы, мы можем на первом этапе вынести за рамки проекта функции группы «А3 Управления выполнением», а также функции «А4.2 Формирование заданий на итерацию» и «А4.3 Формирование заданий при наступлении риска». Из диаграммы видно, что в результате система лишится потока данных — «задания исполнителям», обусловленных работами по нивелированию рисков.

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

В следующей части мы будем детализировать процессы, включенные в рамки системы ссылка
.

Источник

Функции системы и используемые ими ресурсы моделируются с использованием стандарта

image003

Проектирование информационных систем

Жизненный цикл разработки информационной системы

image004

Одним из важных понятий при разработке программного обеспечения является «концептуальная модель».

При этом «концептуальная модель» это:

image005

Методология IDEF0

Одной из распространенных методологий построения концептуальных моделей является IDEF0.

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

Поясним суть методологии IDEF0 на примере производства товара. Процесс производства условно изображен на слайде.

image006

В терминах IDEF0 моделируемое информационной системой производство представляется блоком и дугами, как показано на слайде.

Правила интерпретации модели:

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

image007

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

image008

Методология Data Flow Diagram

image009

Основы методологии построения диаграмм потоков данных DFD были описаны в 1979 году C. Gane и T. Sarson в книге «Structured Systems Analysis».

image010

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

image011

Аналогично IDEF0, для удобства DF-диаграммы разделяют на уровни.

На 1 уровне выделяются основные компоненты системы. С 0-го уровня сюда переносятся все потоки данных. Диаграмма дополняется потоками данных внутри системы и хранилищами данных.

На 2 и далее уровнях происходит постепенная детализация информационной системы.

image012

Внешние сущности:

image013

Процессы:

image014

Хранилища данных:

image015

Потоки данных:

image016

image017

image018

Алгоритм построения диаграммы

image019

Типичные ошибки построения DF-диаграмм

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

На DFD диаграмме не отображаются точки начала и окончания, решения(if) и циклы.

image020

Внешние сущности не могут быть связаны потоками информации (это выходит за рамки моделируемой системы)

Внешние сущности не могут напрямую обращаться к хранилищам данных

image021

Хранилище данных не может напрямую обращаться к другому хранилищу. Между ними должен быть процесс.

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

image022

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

Избегайте процессов которые не имеют входящих потоков информации.

Избегайте процессов которые не имеют исходящих потоков информации.

image023

Давайте построим DF-диаграмму для информационной системы риэлтерской конторы.

Фирма функционирует следующим образом:

image024

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

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

image025

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

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

image026

Роль методологий в анализе моделируемого объекта (Выводы)

В результате анализа моделируемого информационной системой объекта на основе построения IDEF0 и DFD-диаграмм:

Определяют главную функцию проектируемой системы. Например, «сопровождать аренду недвижи­мости».

Описывают происходящие в моделируемом объекте бизнес процессы.

Определяют обрабатываемые бизнес процессами информационными потоки. Например, так: «отправка договора менеджеру».

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

Как видим назначение концептуальной модели объекта:

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

image028

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

image029

image030

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

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

image031

Этот вид диаграмм предназначен для анализа аппаратной части системы, то есть «железа», а не программ. В прямом переводе с английского Deployment означает «развертывание», но термин «топология» точнее отражает сущность этого типа диаграмм.

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

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

image032

State Maсhine diagram (диаграммы состояний)

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

Statechart diagram (диаграмма состояний)

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

image033

Activity diagram (диаграммы активности)

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

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

image034

Interaction diagram (диаграммы взаимодействия)

Этот тип диаграмм включает в себя диаграммы Sequence diagram (диаграммы последовательностей действий) и Collaboration diagram (диаграммы сотрудничества). Эти диаграммы позволяют с разных точек зрения рассмотреть взаимодействие объектов в создаваемой системе.

Sequence diagram (диаграммы последовательностей действий)

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

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

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

image035

Collaboration diagram (диаграммы сотрудничества)

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

image036

Class diagram (диаграммы классов)

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

image037

Component diagram (диаграммы компонентов)

Этот тип диаграмм предназначен для распределения классов и объектов по компонентам при физическом проектировании системы. Часто данный тип диаграмм называют диаграммами модулей.

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

Источник

Комфорт
Adblock
detector