PosobieASOIU0_5

4.Перекресток для слияния типа исключающего «ИЛИ» не может следовать за перекрестком для разветвления типа «И»;

5.Перекресток, имеющий одну стрелку на одной стороне, должен иметь более одной стрелки на другой.

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

безусловные (unconditional), синхронные (synchronous) и асинхронные (asynchronous).

При внесении объектов ссылок помимо имени следует указывать тип объекта ссылки. Типы объектов ссылок приведены в таблице 3.2.

Таблица 3.2 – Типы объектов ссылки

В IDEF3 декомпозиция используется для детализации работ. Методология IDEF3 позволяет декомпозировать работу многократно,

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

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

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

3.5Рекомендации по построению модели SADT

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

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

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

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

Поскольку разные фрагменты модели могут быть созданы разными группами аналитиков в разное время, инструментальные средства поддерживают механизмы групповой работы, в виде организации циклов писатель/читатель, разделение работ с помощью присвоения разных номеров и т.д. Более подробно эти вопросы изложены в [14, 15, 16]

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

3.6Методология объектно-ориентированного проектирования UML

Язык UML (Unified Modeling Language) представляет собой унифицированный язык визуального моделирования, который разработан для специфицирования (создания спецификации), конструирования, визуализации, и документирования артефактов программных систем – компонентов программного обеспечения, бизнес-процессов и т.д. Артефактами, в контексте проектирования на UML, можно называть принятые в процессе анализа и проектирования решения, которые определенным образом визуализированы с помощью различных диаграмм, условных обозначений на диаграммах и различных связей между этими обозначениями. Язык UML одновременно является простым и мощным средством моделирования, который может быть эффективно использован для построения концептуальных, логических и графических моделей сложных систем самого различного целевого назначения. При этом UML и поддерживающие его инструменты – это не самоцель; UML предполагает, но не обязывает использование определенных методологий при объектно-ориентированном анализе и процессов при объектно-ориентированном проектировании [8, 9, 13, 15, 24, 26, 27, 40, 48, 49].

Конструктивное использование языка UML основывается на понимании общих принципов моделирования сложных систем и особенностей процесса объектно-ориентированного анализа и проектирования в частности:

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

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

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

рамках фиксированных представлений.

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

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

•вариантов использования (use case);

•классов (class);

•поведения (behavior):

o состояний (statechart); o деятельности (activity);

oвзаимодействия (interaction):

последовательности (sequence);

кооперации (collaboration);

•реализации (implementation): o компонентов (component); o развертывания (deployment).

Диаграмма вариантов использования является исходным

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

Разработка диаграммы вариантов использования преследует цели:

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

•сформулировать общие требования к функциональному поведению проектируемой системы;

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

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

Суть данной диаграммы состоит в следующем: проектируемая система представляется в виде множества сущностей или актеров, взаимодействие которых с системой отображается в виде так называемых вариантов использования. При этом актером (actor) или действующим лицом называется любая сущность, взаимодействующая с системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая служит источником воздействия на моделируемую систему так, как определит сам разработчик. В свою очередь, вариант использования (use case) служит для описания сервисов, которые система предоставляет актеру или прецедентов использования системы.

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

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

•включения – указывает, что некоторое заданное поведение для одного варианта использования включается в качестве составного компонента в последовательность поведения другого варианта использования. Данное отношение является направленным и бинарным;

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

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

Класс (class) в языке UML служит для обозначения множества объектов, которые обладают одинаковой структурой, поведением и

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

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

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

•обобщения – отношение между более общим элементом (родителем или предком) и более частным и специальным элементом (дочерним или потомком).

•ассоциации – соответствует наличию некоторого отношения между классами.

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

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

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

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

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

Состояние определяется именем и списком внутренних действий (деятельностей), которые выполняются в процессе нахождения моделируемого элемента в данном состоянии и характеризуются меткой действия (entry, exit, do, include).

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

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

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

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

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

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

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

В контексте языка UML деятельность (activity) представляет собой некоторую совокупность отдельных вычислений, выполняемых автоматом. При этом отдельные элементарные вычисления могут приводить к некоторому результату или действию (action). На диаграмме деятельности отображается логика или последовательность перехода от одной деятельности к другой, при этом внимание фиксируется на результате деятельности. Сам же результат может привести к изменению состояния системы или возвращению некоторого значения.

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

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

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

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

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

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

В языке UML могут встречаться несколько разновидностей сообщений:

•вызов процедур, выполнение операций или обозначение отдельных вложенных потоков управления;

•обозначение простого (не вложенного) потока управления;

•асинхронное сообщение между двумя объектами в некоторой процедурной последовательности;

•возврат из вызова процедуры.

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

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

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

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

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

Кооперация может быть представлена на двух уровнях:

•на уровне спецификации – показывает роли классификаторов и роли ассоциаций в рассматриваемом взаимодействии;

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

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

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

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

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

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

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

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

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

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

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

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

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

4Примеры

4.1Описание каскадной модели проектирования по методологии SADT

Вкачестве примера рассмотрим каскадную (водопадную) модель проектирования и разработки АСОИУ, выполненную в методологии SADT.

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

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

Рис. 4.1. Контекстная диаграмма А-0

Вцелом, каскадная модель жизненного цикла описана на рис.

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

Рис. 4.2. Диаграмма декомпозиции верхнего уровня А0

На этапе анализа предметной области и формулировки требований осуществляется определение функций, которые должна выполнять разрабатываемая система (см. рис. 4.3.). Эту работу выполняют аналитики (менеджеры) совместно со специалистами предметной области (клиентом).

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

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

(см. рис. 4.4.)

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

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

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

На рисунках 4.6 – 4.7 приведено описание бизнес-процессов по работе с требованиями (декомпозиция блока А11) и корректировке плана проекта (декомпозиция блока А24), выполненное по стандарту

IDEF3.

Рис. 4.3. Диаграмма А1. Подготовить проект

Рис. 4.4. Диаграмма DFD A11. Работать с требованиями клиента

Рис. 4.5. Диаграмма А2. Проектировать автоматизированную систему

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

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

Рис. 4.6. Диаграмма A13 (IDEF3)

Рис. 4.7. Диаграмма А24 (IDEF3)

Рис. 4.8. Диаграмма А31 (IDEF3)