Нотация sadt-технологии разработки программного обеспечения.

Методологию SADT, предложена Дугласом Россом. На ее основе разработана, в частности, известная методология IDEFO (Icam DEFinition). Методология SADT представляет собой набор методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области.

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

• графическое представление блочного моделирования. На SADT-диаграмме функции представляются в виде блока, а интерфейсы входа-выхода — в виде дуг, соответственно входящих в блок и выходящих из него. Интерфейсные дуги отображают взаимодействие функций друг с другом;

• строгость и точность отображения.

Правила SADT включают:

• уникальность меток и наименований;

• ограничение количества блоков на каждом уровне декомпозиции;

• синтаксические правила для графики;

• связность диаграмм;

• отделение организации от функции;

• разделение входов и управлений.

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

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

Блоки на диаграмме размещают по «ступенчатой» схеме в соответствии с последовательностью их работы или доминированием, которое понимается как влияние, оказываемое одним блоком на другие. В функциональных диаграммах SADT различают пять типов влияний блоков друг на друга [1]:

• вход-выход блока подается на вход блока с меньшим доминированием, т. е. следующего (рис. а);

• управление. Выход блока используется как управление для блока с меньшим доминированием (рис. б)

• обратная связь по входу. Выход блока подается на вход блока с большим доминированием (рис. в);

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

• выход-исполнитель. Выход блока используется как механизм для другого блока (рис. д).

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

На рис. 3.24 приведены четыре диаграммы и их взаимосвязи, показывающие структуру SADT-модели. Каждый компонент модели может быть декомпозирован на другой диаграмме. Детальная диаграмма иллюстрирует внутреннее строение блока «родительской» диаграммы.

DFD-технология разработки программного обеспечения. Процесс построение контекстной диаграммы.

DFD — общепринятое сокращение от англ. Data Flow Diagrams — диаграммы потоков данных. Так называется методология графического структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных, к которым осуществляется доступ.

Диаграмма потоков данных (data flow diagram, DFD) — один из основных инструментов структурного анализа и проектирования информационных систем, существовавших до широкого распространения UML. Несмотря на имеющее место в современных условиях смещение акцентов от структурного к объектно-ориентированному подходу к анализу и проектированию систем, «старинные» структурные нотации по-прежнему широко и эффективно используются как в бизнес-анализе, так и в анализе информационных систем.

Исторически сложилось так, что для описания диаграмм DFD используются две нотации — Йордана (Yourdon) и Гейна-Сарсона (Gane-Sarson), отличающиеся синтаксисом.

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

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

Кроме того, нотация DFD поддерживает понятие подсистемы — структурного компонента разрабатываемой системы.

Нотация DFD — удобное средство для формирования контекстной диаграммы, то есть диаграммы, показывающей разрабатываемую АИС в коммуникации с внешней средой. Это — диаграмма верхнего уровня в иерархии диаграмм DFD. Ее назначение — ограничить рамки системы, определить, где заканчивается разрабатываемая система и начинается среда. Другие нотации, часто используемые при формировании контекстной диаграммы — диаграмма SADT, Диаграмма вариантов использования.

1.1.      Идентификация внешних объектов, с которыми система взаимодей­ствует.

1.2.      Идентификация основных видов информации, циркулирующей меж­ду системой и внешними объектами.

1.3.      Идентификация подсистем бизнес-системы (если в этом есть необхо­димость).

1.4.      Идентификация основных видов информации, циркулирующей меж­ду подсистемами (в случае выполнения п. 1.3).

1.5.      Построение контекстной диаграммы, на которой подсистемы пред­ставляются в виде контекстных процессов, внешние объекты - в виде вне­шних сущностей, основные виды информации - в виде потоков между вне­шними сущностями и контекстными процессами (а также между контекст­ными процессами в случае выполнения п. 1.3).

1.6.      Группирование потоков (если в этом есть необходимость).

Шаг 2. Разработка диаграммы уровня основных процессов.

2.1.      Идентификация бизнес-процессов с указанием их типов.

2.2.      Группирование процессов по деятельностям.

2.3.      Определение связей между процессами и внешними объектами и их непосредственное связывание с использованием родительских потоков (по­токов между внешними сущностями и контекстным процессом).

2.4.      Определение информационных потоков между процессами.

2.5.      Идентификация базовых накопителей.

2.6.      Определение информационных потоков между процессами и нако­пителями.

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

DFD-технология разработки программного обеспечения. Процесс построение диаграмм иерархии.

DFD — общепринятое сокращение от англ. Data Flow Diagrams — диаграммы потоков данных. Так называется методология графического структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных, к которым осуществляется доступ.

Диаграмма потоков данных (data flow diagram, DFD) — один из основных инструментов структурного анализа и проектирования информационных систем, существовавших до широкого распространения UML. Несмотря на имеющее место в современных условиях смещение акцентов от структурного к объектно-ориентированному подходу к анализу и проектированию систем, «старинные» структурные нотации по-прежнему широко и эффективно используются как в бизнес-анализе, так и в анализе информационных систем.

Исторически сложилось так, что для описания диаграмм DFD используются две нотации — Йордана (Yourdon) и Гейна-Сарсона (Gane-Sarson), отличающиеся синтаксисом.

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

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

Кроме того, нотация DFD поддерживает понятие подсистемы — структурного компонента разрабатываемой системы.

Нотация DFD — удобное средство для формирования контекстной диаграммы, то есть диаграммы, показывающей разрабатываемую АИС в коммуникации с внешней средой. Это — диаграмма верхнего уровня в иерархии диаграмм DFD. Ее назначение — ограничить рамки системы, определить, где заканчивается разрабатываемая система и начинается среда. Другие нотации, часто используемые при формировании контекстной диаграммы — диаграмма SADT, Диаграмма вариантов использования.

Шаг 2. Разработка диаграммы уровня основных процессов.

2.1.      Идентификация бизнес-процессов с указанием их типов.

2.2.      Группирование процессов по деятельностям.

2.3.      Определение связей между процессами и внешними объектами и их непосредственное связывание с использованием родительских потоков (по­токов между внешними сущностями и контекстным процессом).

2.4.      Определение информационных потоков между процессами.

2.5.      Идентификация базовых накопителей.

2.6.      Определение информационных потоков между процессами и нако­пителями.

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

3.1.      Декомпозиция каждого процесса текущей DFD с помощью детали­зирующей диаграммы или спецификации процесса.

3.2.      Идентификация функций и операций каждого из процессов.

3.3.      Определение связей между функциями (операциями) и внешними объектами и их непосредственное связывание с использованием родитель­ских потоков (потоков между детализируемым процессом и другими процес­сами и накопителями родительской диаграммы).

3.4.      Определение информационных потоков между функциями (операци­ями).

3.5.      По необходимости введение накопителей уровня процесса, детализи­рующих базовые накопители.

3.6.      Определение информационных потоков между функциями (операци­ями) и накопителями уровня процесса.

3.7.      Построение DFD соответствующего уровня на базе функций (опера­ций).

Нотация Йордана DFD-технологии разработки программного обеспечения.

Нотация Гейна – Сарсона DFD-технологии разработки программного обеспечения.

Назначение языка UML.

Язык UML предназначен для решения следующих задач:

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

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

2.Снабдить исходные понятия языка UML возможностью расширения и специализации для более точного представления моделей систем в конкретной предметной области.

Хотя язык UML является формальным языком — спецификаций, формальность его описания отличается от синтаксиса как традиционных формально-логических языков, так и известных языков программирования. Разработчики из OMG предполагают, что язык UML как никакой другой может быть приспособлен для конкретных предметных областей. Язык UML допускает также специализацию базовых понятий. Речь идет о том, что в конкретных⁷ приложениях пользователи должны уметь дополнять имеющиеся базовые понятия новыми характеристиками или свойствами, которые не противоречат семантике этих понятий в языке UML.

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

Речь идет о том, что ни одна из конструкций языка UML не должна зависеть от особенностей ее реализации в известных языках программирования. С другой стороны, язык UML должен обладать потенциальной возможностью реализации своих конструкций на том или ином языке программирования. имеются в виду языки, поддерживающие концепцию ООП, такие как C++, Java, Object Pascal. Именно это свойство языка UML делает его современным средством решения задач моделирования сложных систем. В то же время, предполагается, что для программной поддержки конструкций языка UML могут быть разработаны специальные инструментальные CASE-средства.