SlideShare a Scribd company logo
1 of 17
Структурный подход к
разработке программного
обеспечения
Структурное (системное)
проектирование – это метод определения
подсистем, компонентов и способов их
соединения, задающий ограничения, при
которых система должна функционировать,
выбирающий наиболее эффективное
сочетание людей, машин и программного
обеспечения для реализации системы.
Сущность структурного подхода
Сущность структурного подхода к разработке ПО заключается в ее
декомпозиции (разбиении) на автоматизируемые функции: система
разбивается на функциональные подсистемы, которые в свою
очередь делятся на подфункции, подразделяемые на задачи и так
далее. Процесс разбиения продолжается вплоть до конкретных
процедур. При этом автоматизируемая система сохраняет
целостное представление, в котором все составляющие
компоненты взаимоувязаны. При разработке системы "снизу-вверх"
от отдельных задач ко всей системе целостность теряется,
возникают проблемы при информационной стыковке отдельных
компонентов.
• принцип "разделяй и властвуй" - принцип решения сложных
проблем путем их разбиения на множество меньших
независимых задач, легких для понимания и решения;
• принцип иерархического упорядочивания - принцип
организации составных частей проблемы в иерархические
древовидные структуры с добавлением новых деталей на
каждом уровне.
• принцип абстрагирования - заключается в выделении
существенных аспектов системы и отвлечения от
несущественных;
Принципы структурного подхода
• принцип структурирования данных - заключается в том,
что данные должны быть структурированы и иерархически
организованы.
• принцип непротиворечивости - заключается в обоснованности и
согласованности элементов;
• принцип формализации - заключается в необходимости
строгого методического подхода к решению проблемы;
В структурном анализе используются в основном две группы
средств, иллюстрирующих функции, выполняемые системой и
отношения между данными. Каждой группе средств
соответствуют определенные виды моделей (диаграмм),
наиболее распространенными среди которых являются
следующие:
• SADT (Structured Analysis and Design Technique)
модели и соответствующие функциональные
диаграммы;
• DFD (Data Flow Diagrams) диаграммы потоков данных;
• ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь".
Средства моделирования при структурном
анализе
1. Диаграммы, иллюстрирующие функции, которые
система должна выполнять, и связи между этими
функциями - DFD или SADT (IDEF0).
2. Диаграммы, моделирующие данные и их отношения
(ERD).
Методология SADT разработана Дугласом
Россом. На ее основе разработана, в частности,
известная методология IDEF0 (Icam DEFinition),
которая является основной частью программы
ICAM (Интеграция компьютерных и
промышленных технологий)
1.графическое представление блочного
моделирования;
2.строгость и точность;
3.ограничение количества блоков на каждом
уровне декомпозиции
4.связность диаграмм;
Основные элементы SADT-методологии
основываются на следующих концепциях:
5. уникальность меток и наименований
(отсутствие повторяющихся имен);
6.синтаксические правила для графики (блоков и
дуг);
7. разделение входов и управлений;
8. отделение организации от функции, т.е.
исключение влияния организационной структуры
на функциональную модель.
Пример использования контекстной диаграммы
• Принцип первый – принцип «черного ящика».
• Принцип второй – принцип неизменности точки
зрения.
• Принцип третий «функции – объекты»
Объекты изображаются дугами (стрелками) и именуются
существительными: «Личная информация»,
«Фотография», «Цитаты», «Место рождения» и т.д.
• Принцип четвертый – принцип декомпозиции
диаграмм.
Принципы:
• Принцип пятый – принцип сохранения дуг
Он означает, что при построении дочерней диаграммы все
граничные дуги родительской диаграммы должны быть
перенесены в неизменном виде.
• Принцип шестой – принцип декомпозиции дуг.
Дуга в SADT на верхних уровнях модели обычно представляет
набор объектов. На нижних уровнях модели бывает важно
уточнить, какие конкретно объекты связаны с выполнением
данной функции. Для этого дуги могут разветвляться и эти ветви
подсоединяться к различным блокам.
• Принцип седьмой – принцип единства оформления диаграмм.
Пример использования диаграммы декомпозиций
Методология DFD (Data Flow Diagram)
В основе данной методологии (другое название
– методология Gane/Sarson по имени авторов)
лежит представление жизненного цикла
информации в виде потоков данных, являющихся
результатом определенных процессов (сбора,
обработки, хранения, передачи) анализируемой
ИС – проектируемой или реально существующей.
Источники информации (внешние сущности) порождают
информационные потоки (потоки данных), переносящие
информацию к подсистемам или процессам. Те в свою очередь
преобразуют информацию и порождают новые потоки, которые
переносят информацию к другим процессам или подсистемам,
накопителям данных или внешним сущностям – потребителям
информации. Таким образом, основными компонентами диаграмм
потоков данных являются:
• внешние сущности;
• системы/подсистемы;
• процессы;
• накопители данных;
• потоки данных.

More Related Content

Viewers also liked

Media a2 album cover analysis 5
Media a2 album cover analysis 5Media a2 album cover analysis 5
Media a2 album cover analysis 5mmorphy97
 
Qendix Web Slide Share 00
Qendix   Web Slide Share   00Qendix   Web Slide Share   00
Qendix Web Slide Share 00nirzohar
 
Trigonometry_150627_01
Trigonometry_150627_01Trigonometry_150627_01
Trigonometry_150627_01Art Traynor
 
PME34 presentation_Andonis Zagorianakos_
PME34 presentation_Andonis Zagorianakos_PME34 presentation_Andonis Zagorianakos_
PME34 presentation_Andonis Zagorianakos_Andonis Zagorianakos
 
BrightEdge Share15 - CM203: Scaling Content: Production, Process & Culture - ...
BrightEdge Share15 - CM203: Scaling Content: Production, Process & Culture - ...BrightEdge Share15 - CM203: Scaling Content: Production, Process & Culture - ...
BrightEdge Share15 - CM203: Scaling Content: Production, Process & Culture - ...BrightEdge Technologies
 
GESTION DE TRANSPORTE, INVENTARIO Y ALMACENES
GESTION DE TRANSPORTE, INVENTARIO Y ALMACENESGESTION DE TRANSPORTE, INVENTARIO Y ALMACENES
GESTION DE TRANSPORTE, INVENTARIO Y ALMACENESEmy Garcia
 
Jornal A Família Católica, 4 edição, setembro 2013
Jornal A Família Católica, 4 edição, setembro 2013Jornal A Família Católica, 4 edição, setembro 2013
Jornal A Família Católica, 4 edição, setembro 2013Thiago Guerino
 
formato de solicitud de capacitación
formato de solicitud de capacitaciónformato de solicitud de capacitación
formato de solicitud de capacitaciónKaren Lagos
 
Estatuto da Criança e do Adolescente ECA 2016 - Enfermagem - CENTEC
Estatuto da Criança e do Adolescente ECA 2016 - Enfermagem - CENTECEstatuto da Criança e do Adolescente ECA 2016 - Enfermagem - CENTEC
Estatuto da Criança e do Adolescente ECA 2016 - Enfermagem - CENTECWALFRIDO Farias Gomes
 

Viewers also liked (13)

Media a2 album cover analysis 5
Media a2 album cover analysis 5Media a2 album cover analysis 5
Media a2 album cover analysis 5
 
Qendix Web Slide Share 00
Qendix   Web Slide Share   00Qendix   Web Slide Share   00
Qendix Web Slide Share 00
 
Trigonometry_150627_01
Trigonometry_150627_01Trigonometry_150627_01
Trigonometry_150627_01
 
Eca
EcaEca
Eca
 
PME34 presentation_Andonis Zagorianakos_
PME34 presentation_Andonis Zagorianakos_PME34 presentation_Andonis Zagorianakos_
PME34 presentation_Andonis Zagorianakos_
 
Branding
BrandingBranding
Branding
 
BrightEdge Share15 - CM203: Scaling Content: Production, Process & Culture - ...
BrightEdge Share15 - CM203: Scaling Content: Production, Process & Culture - ...BrightEdge Share15 - CM203: Scaling Content: Production, Process & Culture - ...
BrightEdge Share15 - CM203: Scaling Content: Production, Process & Culture - ...
 
Educación con tic´s
Educación con tic´sEducación con tic´s
Educación con tic´s
 
GESTION DE TRANSPORTE, INVENTARIO Y ALMACENES
GESTION DE TRANSPORTE, INVENTARIO Y ALMACENESGESTION DE TRANSPORTE, INVENTARIO Y ALMACENES
GESTION DE TRANSPORTE, INVENTARIO Y ALMACENES
 
Jornal A Família Católica, 4 edição, setembro 2013
Jornal A Família Católica, 4 edição, setembro 2013Jornal A Família Católica, 4 edição, setembro 2013
Jornal A Família Católica, 4 edição, setembro 2013
 
A família católica%2c 35 edição.
A família católica%2c 35 edição.A família católica%2c 35 edição.
A família católica%2c 35 edição.
 
formato de solicitud de capacitación
formato de solicitud de capacitaciónformato de solicitud de capacitación
formato de solicitud de capacitación
 
Estatuto da Criança e do Adolescente ECA 2016 - Enfermagem - CENTEC
Estatuto da Criança e do Adolescente ECA 2016 - Enfermagem - CENTECEstatuto da Criança e do Adolescente ECA 2016 - Enfermagem - CENTEC
Estatuto da Criança e do Adolescente ECA 2016 - Enfermagem - CENTEC
 

Similar to структурный подход (7)

Бизнес весна 2014 лекция 3
Бизнес весна 2014 лекция 3Бизнес весна 2014 лекция 3
Бизнес весна 2014 лекция 3Technopark
 
Getting Started to the System Design
Getting Started to the System DesignGetting Started to the System Design
Getting Started to the System DesignAnatoly Simkin
 
пр8 сем2 1_проектированиербд_er_model2014_02_27
пр8 сем2 1_проектированиербд_er_model2014_02_27пр8 сем2 1_проектированиербд_er_model2014_02_27
пр8 сем2 1_проектированиербд_er_model2014_02_27helenyakovleva
 
1 общие понятия о проектировании мехатронных систем
1 общие понятия о проектировании мехатронных систем1 общие понятия о проектировании мехатронных систем
1 общие понятия о проектировании мехатронных системMakhabbat Kalenova
 
Концепция применения онтологических структур в ERP-системах
Концепция применения онтологических структур в ERP-системахКонцепция применения онтологических структур в ERP-системах
Концепция применения онтологических структур в ERP-системахAnatoly Simkin
 
Проектирование_и_архитектура_ПС_2022_L06.ppt
Проектирование_и_архитектура_ПС_2022_L06.pptПроектирование_и_архитектура_ПС_2022_L06.ppt
Проектирование_и_архитектура_ПС_2022_L06.pptdinarium2016
 
Taxonomy vs folksonomy Tsepkov Analyst Days 2016
Taxonomy vs folksonomy Tsepkov Analyst Days 2016Taxonomy vs folksonomy Tsepkov Analyst Days 2016
Taxonomy vs folksonomy Tsepkov Analyst Days 2016Maxim Tsepkov
 
Коммуникация при различной структуре мышления - таксономия против фолксономии
Коммуникация при различной структуре мышления - таксономия против фолксономииКоммуникация при различной структуре мышления - таксономия против фолксономии
Коммуникация при различной структуре мышления - таксономия против фолксономииSQALab
 
лекция 6
лекция 6лекция 6
лекция 6cezium
 
презентация3
презентация3презентация3
презентация3student_kai
 
Проектирование_и_архитектура_ПС_2022_L08s.ppt
Проектирование_и_архитектура_ПС_2022_L08s.pptПроектирование_и_архитектура_ПС_2022_L08s.ppt
Проектирование_и_архитектура_ПС_2022_L08s.pptdinarium2016
 
А.Левенчук -- Понятие системы в системной инженерии
А.Левенчук -- Понятие системы в системной инженерииА.Левенчук -- Понятие системы в системной инженерии
А.Левенчук -- Понятие системы в системной инженерииAnatoly Levenchuk
 
лекция 7
лекция 7лекция 7
лекция 7cezium
 
лекция 7
лекция 7лекция 7
лекция 7cezium
 
разработка технического задания
разработка технического заданияразработка технического задания
разработка технического заданияolalapim10
 
МАПО 2013 Лекция 07 Моделирование IDEF
МАПО 2013 Лекция 07 Моделирование IDEFМАПО 2013 Лекция 07 Моделирование IDEF
МАПО 2013 Лекция 07 Моделирование IDEFОлег Гудаев
 

Similar to структурный подход (7) (20)

Бизнес весна 2014 лекция 3
Бизнес весна 2014 лекция 3Бизнес весна 2014 лекция 3
Бизнес весна 2014 лекция 3
 
Getting Started to the System Design
Getting Started to the System DesignGetting Started to the System Design
Getting Started to the System Design
 
пр8 сем2 1_проектированиербд_er_model2014_02_27
пр8 сем2 1_проектированиербд_er_model2014_02_27пр8 сем2 1_проектированиербд_er_model2014_02_27
пр8 сем2 1_проектированиербд_er_model2014_02_27
 
Present architect
Present architectPresent architect
Present architect
 
1 общие понятия о проектировании мехатронных систем
1 общие понятия о проектировании мехатронных систем1 общие понятия о проектировании мехатронных систем
1 общие понятия о проектировании мехатронных систем
 
Концепция применения онтологических структур в ERP-системах
Концепция применения онтологических структур в ERP-системахКонцепция применения онтологических структур в ERP-системах
Концепция применения онтологических структур в ERP-системах
 
Проектирование_и_архитектура_ПС_2022_L06.ppt
Проектирование_и_архитектура_ПС_2022_L06.pptПроектирование_и_архитектура_ПС_2022_L06.ppt
Проектирование_и_архитектура_ПС_2022_L06.ppt
 
Taxonomy vs folksonomy Tsepkov Analyst Days 2016
Taxonomy vs folksonomy Tsepkov Analyst Days 2016Taxonomy vs folksonomy Tsepkov Analyst Days 2016
Taxonomy vs folksonomy Tsepkov Analyst Days 2016
 
Коммуникация при различной структуре мышления - таксономия против фолксономии
Коммуникация при различной структуре мышления - таксономия против фолксономииКоммуникация при различной структуре мышления - таксономия против фолксономии
Коммуникация при различной структуре мышления - таксономия против фолксономии
 
тема 6
тема 6тема 6
тема 6
 
лекция 6
лекция 6лекция 6
лекция 6
 
презентация3
презентация3презентация3
презентация3
 
Проектирование_и_архитектура_ПС_2022_L08s.ppt
Проектирование_и_архитектура_ПС_2022_L08s.pptПроектирование_и_архитектура_ПС_2022_L08s.ppt
Проектирование_и_архитектура_ПС_2022_L08s.ppt
 
А.Левенчук -- Понятие системы в системной инженерии
А.Левенчук -- Понятие системы в системной инженерииА.Левенчук -- Понятие системы в системной инженерии
А.Левенчук -- Понятие системы в системной инженерии
 
лекция 2 (4часа)
лекция 2 (4часа)лекция 2 (4часа)
лекция 2 (4часа)
 
лекция 7
лекция 7лекция 7
лекция 7
 
лекция 7
лекция 7лекция 7
лекция 7
 
разработка технического задания
разработка технического заданияразработка технического задания
разработка технического задания
 
лекция 2 (4часа)
лекция 2 (4часа)лекция 2 (4часа)
лекция 2 (4часа)
 
МАПО 2013 Лекция 07 Моделирование IDEF
МАПО 2013 Лекция 07 Моделирование IDEFМАПО 2013 Лекция 07 Моделирование IDEF
МАПО 2013 Лекция 07 Моделирование IDEF
 

More from romachka_pole

защита информации (53)
защита информации (53)защита информации (53)
защита информации (53)romachka_pole
 
управление конфигураций и документирование программного обеспечения (49)
управление конфигураций и документирование программного обеспечения (49)управление конфигураций и документирование программного обеспечения (49)
управление конфигураций и документирование программного обеспечения (49)romachka_pole
 
технология и отладка по (47)
технология и отладка по (47)технология и отладка по (47)
технология и отладка по (47)romachka_pole
 
методология Rad (46)
методология Rad (46)методология Rad (46)
методология Rad (46)romachka_pole
 
метод Oracle (45)
метод Oracle (45)метод Oracle (45)
метод Oracle (45)romachka_pole
 
технология Rational unified process (44)
технология Rational unified process (44)технология Rational unified process (44)
технология Rational unified process (44)romachka_pole
 
шаблоны проектирования (42)
шаблоны проектирования (42)шаблоны проектирования (42)
шаблоны проектирования (42)romachka_pole
 
Xp программирование (41)
Xp программирование (41)Xp программирование (41)
Xp программирование (41)romachka_pole
 
принципы проектирования интерфейса (37)
принципы проектирования интерфейса (37)принципы проектирования интерфейса (37)
принципы проектирования интерфейса (37)romachka_pole
 
модульное программирование (35)
модульное программирование  (35)модульное программирование  (35)
модульное программирование (35)romachka_pole
 
диаграмма кооперации, реализации(25 26 33 34 )
диаграмма кооперации, реализации(25 26 33 34 )диаграмма кооперации, реализации(25 26 33 34 )
диаграмма кооперации, реализации(25 26 33 34 )romachka_pole
 
диаграмма кооперации, реализации(25 26 33 34 )
диаграмма кооперации, реализации(25 26 33 34 )диаграмма кооперации, реализации(25 26 33 34 )
диаграмма кооперации, реализации(25 26 33 34 )romachka_pole
 
принцип построения диаграммы последовательности (24 32)
принцип построения диаграммы последовательности (24 32)принцип построения диаграммы последовательности (24 32)
принцип построения диаграммы последовательности (24 32)romachka_pole
 
диаграмма кооперации, реализации(25 26 33 34 )
диаграмма кооперации, реализации(25 26 33 34 )диаграмма кооперации, реализации(25 26 33 34 )
диаграмма кооперации, реализации(25 26 33 34 )romachka_pole
 
диаграмма кооперации, реализации(25 26 33 34 )
диаграмма кооперации, реализации(25 26 33 34 )диаграмма кооперации, реализации(25 26 33 34 )
диаграмма кооперации, реализации(25 26 33 34 )romachka_pole
 
принцип построения диаграммы последовательности (24 32)
принцип построения диаграммы последовательности (24 32)принцип построения диаграммы последовательности (24 32)
принцип построения диаграммы последовательности (24 32)romachka_pole
 
язык Uml. диаграмма использования. (19)
язык Uml. диаграмма использования. (19)язык Uml. диаграмма использования. (19)
язык Uml. диаграмма использования. (19)romachka_pole
 
Case средства (16 17)
Case средства (16 17)Case средства (16 17)
Case средства (16 17)romachka_pole
 
этапы создания по при обьективном подходе( ) (16)
этапы создания по при обьективном подходе( ) (16)этапы создания по при обьективном подходе( ) (16)
этапы создания по при обьективном подходе( ) (16)romachka_pole
 
Case средства (16 17)
Case средства (16 17)Case средства (16 17)
Case средства (16 17)romachka_pole
 

More from romachka_pole (20)

защита информации (53)
защита информации (53)защита информации (53)
защита информации (53)
 
управление конфигураций и документирование программного обеспечения (49)
управление конфигураций и документирование программного обеспечения (49)управление конфигураций и документирование программного обеспечения (49)
управление конфигураций и документирование программного обеспечения (49)
 
технология и отладка по (47)
технология и отладка по (47)технология и отладка по (47)
технология и отладка по (47)
 
методология Rad (46)
методология Rad (46)методология Rad (46)
методология Rad (46)
 
метод Oracle (45)
метод Oracle (45)метод Oracle (45)
метод Oracle (45)
 
технология Rational unified process (44)
технология Rational unified process (44)технология Rational unified process (44)
технология Rational unified process (44)
 
шаблоны проектирования (42)
шаблоны проектирования (42)шаблоны проектирования (42)
шаблоны проектирования (42)
 
Xp программирование (41)
Xp программирование (41)Xp программирование (41)
Xp программирование (41)
 
принципы проектирования интерфейса (37)
принципы проектирования интерфейса (37)принципы проектирования интерфейса (37)
принципы проектирования интерфейса (37)
 
модульное программирование (35)
модульное программирование  (35)модульное программирование  (35)
модульное программирование (35)
 
диаграмма кооперации, реализации(25 26 33 34 )
диаграмма кооперации, реализации(25 26 33 34 )диаграмма кооперации, реализации(25 26 33 34 )
диаграмма кооперации, реализации(25 26 33 34 )
 
диаграмма кооперации, реализации(25 26 33 34 )
диаграмма кооперации, реализации(25 26 33 34 )диаграмма кооперации, реализации(25 26 33 34 )
диаграмма кооперации, реализации(25 26 33 34 )
 
принцип построения диаграммы последовательности (24 32)
принцип построения диаграммы последовательности (24 32)принцип построения диаграммы последовательности (24 32)
принцип построения диаграммы последовательности (24 32)
 
диаграмма кооперации, реализации(25 26 33 34 )
диаграмма кооперации, реализации(25 26 33 34 )диаграмма кооперации, реализации(25 26 33 34 )
диаграмма кооперации, реализации(25 26 33 34 )
 
диаграмма кооперации, реализации(25 26 33 34 )
диаграмма кооперации, реализации(25 26 33 34 )диаграмма кооперации, реализации(25 26 33 34 )
диаграмма кооперации, реализации(25 26 33 34 )
 
принцип построения диаграммы последовательности (24 32)
принцип построения диаграммы последовательности (24 32)принцип построения диаграммы последовательности (24 32)
принцип построения диаграммы последовательности (24 32)
 
язык Uml. диаграмма использования. (19)
язык Uml. диаграмма использования. (19)язык Uml. диаграмма использования. (19)
язык Uml. диаграмма использования. (19)
 
Case средства (16 17)
Case средства (16 17)Case средства (16 17)
Case средства (16 17)
 
этапы создания по при обьективном подходе( ) (16)
этапы создания по при обьективном подходе( ) (16)этапы создания по при обьективном подходе( ) (16)
этапы создания по при обьективном подходе( ) (16)
 
Case средства (16 17)
Case средства (16 17)Case средства (16 17)
Case средства (16 17)
 

структурный подход (7)

  • 1. Структурный подход к разработке программного обеспечения
  • 2. Структурное (системное) проектирование – это метод определения подсистем, компонентов и способов их соединения, задающий ограничения, при которых система должна функционировать, выбирающий наиболее эффективное сочетание людей, машин и программного обеспечения для реализации системы.
  • 3. Сущность структурного подхода Сущность структурного подхода к разработке ПО заключается в ее декомпозиции (разбиении) на автоматизируемые функции: система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и так далее. Процесс разбиения продолжается вплоть до конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. При разработке системы "снизу-вверх" от отдельных задач ко всей системе целостность теряется, возникают проблемы при информационной стыковке отдельных компонентов.
  • 4.
  • 5. • принцип "разделяй и властвуй" - принцип решения сложных проблем путем их разбиения на множество меньших независимых задач, легких для понимания и решения; • принцип иерархического упорядочивания - принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне. • принцип абстрагирования - заключается в выделении существенных аспектов системы и отвлечения от несущественных; Принципы структурного подхода
  • 6. • принцип структурирования данных - заключается в том, что данные должны быть структурированы и иерархически организованы. • принцип непротиворечивости - заключается в обоснованности и согласованности элементов; • принцип формализации - заключается в необходимости строгого методического подхода к решению проблемы;
  • 7. В структурном анализе используются в основном две группы средств, иллюстрирующих функции, выполняемые системой и отношения между данными. Каждой группе средств соответствуют определенные виды моделей (диаграмм), наиболее распространенными среди которых являются следующие: • SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы; • DFD (Data Flow Diagrams) диаграммы потоков данных; • ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь".
  • 8. Средства моделирования при структурном анализе 1. Диаграммы, иллюстрирующие функции, которые система должна выполнять, и связи между этими функциями - DFD или SADT (IDEF0). 2. Диаграммы, моделирующие данные и их отношения (ERD).
  • 9. Методология SADT разработана Дугласом Россом. На ее основе разработана, в частности, известная методология IDEF0 (Icam DEFinition), которая является основной частью программы ICAM (Интеграция компьютерных и промышленных технологий)
  • 10. 1.графическое представление блочного моделирования; 2.строгость и точность; 3.ограничение количества блоков на каждом уровне декомпозиции 4.связность диаграмм; Основные элементы SADT-методологии основываются на следующих концепциях:
  • 11. 5. уникальность меток и наименований (отсутствие повторяющихся имен); 6.синтаксические правила для графики (блоков и дуг); 7. разделение входов и управлений; 8. отделение организации от функции, т.е. исключение влияния организационной структуры на функциональную модель.
  • 13. • Принцип первый – принцип «черного ящика». • Принцип второй – принцип неизменности точки зрения. • Принцип третий «функции – объекты» Объекты изображаются дугами (стрелками) и именуются существительными: «Личная информация», «Фотография», «Цитаты», «Место рождения» и т.д. • Принцип четвертый – принцип декомпозиции диаграмм. Принципы:
  • 14. • Принцип пятый – принцип сохранения дуг Он означает, что при построении дочерней диаграммы все граничные дуги родительской диаграммы должны быть перенесены в неизменном виде. • Принцип шестой – принцип декомпозиции дуг. Дуга в SADT на верхних уровнях модели обычно представляет набор объектов. На нижних уровнях модели бывает важно уточнить, какие конкретно объекты связаны с выполнением данной функции. Для этого дуги могут разветвляться и эти ветви подсоединяться к различным блокам. • Принцип седьмой – принцип единства оформления диаграмм.
  • 16. Методология DFD (Data Flow Diagram) В основе данной методологии (другое название – методология Gane/Sarson по имени авторов) лежит представление жизненного цикла информации в виде потоков данных, являющихся результатом определенных процессов (сбора, обработки, хранения, передачи) анализируемой ИС – проектируемой или реально существующей.
  • 17. Источники информации (внешние сущности) порождают информационные потоки (потоки данных), переносящие информацию к подсистемам или процессам. Те в свою очередь преобразуют информацию и порождают новые потоки, которые переносят информацию к другим процессам или подсистемам, накопителям данных или внешним сущностям – потребителям информации. Таким образом, основными компонентами диаграмм потоков данных являются: • внешние сущности; • системы/подсистемы; • процессы; • накопители данных; • потоки данных.