В чем заключается методика константайна
Структурные карты Константайна
Техника структурных карт (схем) используется на фазе проектирования для того, чтобы продемонстрировать, каким образом системные требования будут отражаться комбинацией программных структур. При этом наиболее часто применяются две техники: структурные карты Константайна (Constantine), и структурные карты Джексона (Jackson).
Структурные карты Константайна (Constantine) предназначены для описания отношений между модулями.
Базовыми строительными блоками программной системы являются модули. Все виды модулей в любом языке программирования имеют ряд общих свойств, нижеперечисленные из которых существенны при структурном проектировании:
· модуль состоит из множества операторов языка программирования, записанных последовательно;
· модуль имеет имя, по которому к нему можно ссылаться как к единому фрагменту;
· модуль может принимать и/или передавать данные как параметры в вызывающей последовательности или связывать данные через фиксированные ячейки или общие области.
Структурные карты Константайна являются моделью отношений иерархии между программными модулями. Узлы структурных карт соответствуют модулям и областям данных, потоки изображают межмодульные вызовы. При этом циклические и условные вызовы модулей моделируются специальными узлами, поэтому потоки должны быть изображены проходящими через эти специальные узлы. Межмодульные связи по данным и управлению также моделируются специальными узлами, привязанными к потокам (т.е. к вызовам модулей), стрелками указываются направления потоков и связей. (слайд 6)
Базовым элементом структурной карты является модуль. Возможно использовать различные типы модулей (слайд 7):
1. Собственно МОДУЛЬ. Используется для представления обрабатывающего фрагмента для его локализации на диаграмме.
2. ПОДСИСТЕМА. Ранее определенный модуль, детализированный посредством декомпозиции ранее определенных диаграмм. Может повторно использоваться любое число раз на любых структурных картах.
3. БИБЛИОТЕКА. Отличается от подсистемы тем, что определена вне проекта данной системы.
4. ОБЛАСТЬ ДАННЫХ. Используется для указания модулей, содержащих исключительно области глобальных/распределенных данных.
При построении структурных карт добавление модулей и увязывание их вместе осуществляется с использований потоков, демонстрирующих иерархию вызовов. (слайд 7) При последовательном вызове модули вызываются в порядке их следования. При параллельном вызове модули могут вызываться в любом порядке или одновременно (параллельно).
Для моделирования условных и циклических вызовов применяются следующие узлы (слайд 8):
Итерационный узел используется для того, чтобы показать, что модуль-наследник вызывается в цикле. Он изображается полуокружностью со стрелкой с выходящими из него потоками.
Связи по данным и управлению между модулями (передаваемые как параметры) раскрываются аннотированием потоков-вызовов (слайд 8). Стрелками отмечаются направления связей.
Пример структурной карты Константайна. (слайд 9)
Структурные карты Джексона
Структурные карты Джексона (Jackson), предназначенные для описания внутренней структуры модулей.
Техника структурных карт Джексона основана на методологии структурного программирования Джексона и заключается в продуцировании диаграмм (структурных карт) для графического иллюстрирования внутримодульных (а иногда и межмодульных) связей и документирования проекта архитектуры системы ПО. При этом техника позволяет осуществлять проектирование нижнего уровня структуры ПО и на этом этапе является близкой к традиционным блок-схемам.
По аналогии со структурными картами Константайна диаграмма Джексона может включать объекты следующих типов:
· СТРУКТУРНЫЙ блок (базовая компонента методологии) представляет частную функцию или блок кодов с одним входом и одним выходом.
· ПРОЦЕДУРНЫЙ блок является специальным видом структурного блока, представляющим вызов ранее определенной процедуры.
· БИБЛИОТЕЧНЫЙ блок аналогичен процедурному и представляет вызов библиотечного модуля.
Для взаимоувязывания блоков используются связи следующих типов:
· последовательная связь, обеспечивающая последовательное выполнение слева направо;
· параллельная связь, обеспечивающая одновременное выполнение блоков;
· условная связь, обеспечивающая выбор одной из альтернатив;
· итерационная связь, обеспечивающая выполнение блока в цикле.
Пример структурной карты Джексона. (слайд 10)
Метод Ericsson-Penker
Метод Ericsson-Penker представляет интерес прежде всего в связи с попыткой применения языка объектного моделирования UML (изначально предназначенного для моделирования архитектуры систем ПО) для моделирования бизнес-процессов. Это стало возможным благодаря наличию в UML механизмов расширения.
Авторы метода создали свой профиль UML для моделирования бизнес-процессов, введя набор стереотипов, описывающих процессы, ресурсы, правила и цели деятельности организации. Основной диаграммой, используемой в этом подходе, является диаграмма деятельности (activity diagram). В результате получился процесс, альтернативный RUP, в котором не применяются варианты использования.
Метод использует четыре основные категории бизнес-модели:
Все эти категории связаны между собой: правило может определять способ структурирования ресурсов, ресурс назначается конкретному процессу, цель связана с выполнением конкретного процесса. Метамодель, определяющая связи между категориями. (слайд 1)
Основной диаграммой UML, используемой в данном методе, является диаграмма деятельности.
Бизнес-процесс в самом простом виде может быть описан как множество деятельностей. Метод Eriksson-Penker представляет образец процесса на диаграмме деятельности (слайд 12) в виде деятельности со стереотипом «process» (в качестве основы данного образца использовано представление процесса в методе IDEF0, расширенное за счет введения цели процесса). Процесс использует входные ресурсы и формирует выходные ресурсы, показанные в виде объектов со стереотипом «resourse», соединенных с процессом связями зависимости. Ресурсы, играющие в методе IDEF0 роли «управления» и «механизма», также соединены с процессом связями зависимости со стереотипами «supply» и «control». Цель процесса показана как объект со стереотипом «goal».
Полная бизнес-модель включает множество представлений. Каждое представление выражено в одной или более диаграммах. Диаграммы могут иметь различные типы и изображать процессы, правила, цели и ресурсы во взаимодействиях друг с другом. Метод Eriksson-Penker использует четыре различных представления бизнес-модели:
· концептуальное представление — структура целей и проблем (дерево целей, представленное в виде диаграммы объектов);
· представление процессов — взаимодействие между процессами и ресурсами (в виде набора диаграмм деятельности);
· структурное представление — структура организации и ресурсов (в виде диаграмм классов);
· представление поведения — поведение отдельных ресурсов и детализация процессов (в виде диаграмм деятельности, состояний и взаимодействия).
Метод Ericsson-Penker активно использует набор образцов моделирования бизнес-процессов. Образец (pattern) можно определить как общее решение некоторой проблемной ситуации в заданном контексте. Образец состоит из четырех основных элементов: имя; проблема; решение; следствия.
Дата добавления: 2021-07-19 ; просмотров: 15 ; Мы поможем в написании вашей работы!
В чем заключается методика константайна
Цель работы: изучить вопросы проектирования программного обеспечения, сформировать навыки проектирования приложений с использованием методов структурного и объектного подходов к разработке.
ТЕОРЕТИЧЕСКАЯ ЧАСТЬ
Проект технический – образ намеченного к созданию объекта, представленный в виде его описания, схем, чертежей, расчетов, обоснований, числовых показателей.
Цель технического проекта – определение основных методов, используемых при создании информационной системы, и окончательное определение ее сметной стоимости.
Техническое проектирование подсистем осуществляется в соответствии с утвержденным техническим заданием.
Технический проект программной системы подробно описывает:
Технический проект должен включать данные об объемах и интенсивности потоков обрабатываемой информации, количестве пользователей программной системы, характеристиках оборудования и программного обеспечения, взаимодействующего с проектируемым программным продуктом.
При разработке технического проекта оформляются:
Структурная схема определяется архитектурой разрабатываемого ПО.
Структурная схема программного комплекса определяет в основных чертах и внешний вид проектируемой системы и принципы взаимодействия с пользователем. Схема проектируемой системы будет представлять собой иерархическую древовидную структуру, описывающую процедуры ввода, обработки и вывода данных. Построение программ информационно-справочного класса по такому принципу позволяет довольно легко производить модификацию системы в целом и облегчает восприятие и понимание принципа работы программы. Для построения структурной схемы необходимо определить иерархию и связь перечисленных выше процедур обработки данных. Естественно установить иерархию процедур в том виде, в каком они были описаны в предыдущей главе, поскольку таковая схема соответствует схеме «важности» и «употребимости» процедур. Пример структурной схемы программы представлен на рисунке 1.
Функциональная схема — это схема взаимодействия компо¬нентов программного обеспечения с описанием информационных потоков, состава данных в потоках и указанием используемых файлов и устройств.
Метод пошаговой детализации реализует нисходящий подход к программированию и предполагает пошаговую разработку алгоритма.
Технология нисходящего проектирования с пошаговой детализацией является неотъемлемой частью создания хорошо структурированных программ. Разработка алгоритма методом пошаговой детализации заключается в следующем:
Но если исполнитель не обучен исполнять заданное предписание, то возникает необходимость представить данное предписание в виде некоторой совокупности более простых предписаний. Если исполнитель не может выполнить и некоторые из них, то такие предписания вновь представляются в виде совокупности еще более простых предписаний.
Объединяя так полученные предписания в единую совокупность выполняемых в определенном порядке предписаний получают выполнение исходного задания в целом.
Достоинства метода пошаговой детализации:
В процессе создания программы особое внимание нужно уделять разработке алгоритмов. Такой подход поможет избежать ошибок, допущенных при проектировании программного продукта. Наличие подобных ошибок потребует массу времени на исправление, возврат на предыдущие этапы разработки с целью их доработки.
При разработке алгоритмов обычно используют метод пошаговой детализации (поэтапно):
Методика структурных карт используется на этапе проектирования ПО для того, чтобы продемонстрировать, каким образом программный продукт выполняет системные требования. Структурные карты Константайна предназначены для описания отношений между модулями.
Техника структурных карт Джексона основана на методе структурного программирования Джексона, который выявляет соответствие между структурой потоков данных и структурой программы. Основное внимание в методе сконцентрировано на соответствии входных и выходных потоков данных.
Описание функциональной схемы программного продукта
Пример функциональной схемы «Разработка виртуальной экскурсии», представлена на рисунке 2, отражает основные функции исследования.
Программа должна соответственно реагировать на действия пользователя. Результат должен быть ожидаемым. Действия пользователя не должно оставаться без результата.
ПОРЯДОК ВЫПОЛНЕНИЯ РАБОТЫ
Защита отчета по практической работе заключается в предъявлении преподавателю полученных результатов (на экране монитора), демонстрации полученных навыков и ответах на вопросы преподавателя.
Структурные карты Константайна
Базовыми строительными блоками программной системы являются модули. Все виды модулей в любом языке программирования имеют ряд общих свойств, нижеперечисленные из которых существенны при структурном проектировании:
Структурные карты Константайна являются моделью отношений иерархии между программными модулями. Узлы структурных карт соответствуют модулям и областям данных, потоки изображают межмодульные вызовы. При этом циклические и условные вызовы модулей моделируются специальными узлами, поэтому потоки должны быть изображены проходящими через эти специальные узлы. Межмодульные связи по данным и управлению также моделируются специальными узлами, привязанными к потокам (т.е. к вызовам модулей), стрелками указываются направления потоков и связей. Фундаментальные элементы структурных карт в соответствии со стандартами IBM, ISO и ANSI приведены на рис. 1.1.
Базовым элементом структурной карты является модуль. Возможно использовать различные типы модулей (см. рис. 1.2):
Различают четыре типа вершин:
1. модуль – подпрограмма;
2. подсистема – программа;
3. библиотека – совокупность подпрограмм, размещенных в отдельном модуле;
4. область данных – специальным образом оформленная совокупность данных, к которой возможно обращение извне.
При построении структурных карт добавление модулей и увязывание их вместе осуществляется с использований потоков, демонстрирующих иерархию вызовов. Типы используемых при этом потоков приведены на рис. 1.3. При последовательном вызове модули вызываются в порядке их следования. При параллельном вызове модули могут вызываться в любом порядке или одновременно (параллельно).
Для моделирования условных и циклических вызовов применяются следующие узлы (рис. 1.4):
Рис. 1.1. Элементы структурных карт
Итерационный узел используется для того, чтобы показать, что модуль-наследник вызывается в цикле. Он изображается полуокружностью со стрелкой с выходящими из него потоками.
Рис. 1.2. Типы модулей
Рис.1.3. Типы вызовов модулей
Рис. 1.4. Условные и циклические вызовы модулей
Связи по данным и управлению между модулями (передаваемые как параметры) раскрываются аннотированием потоков-вызовов (рис. 1.5). Стрелками отмечаются направления связей.
Рис. 1.5. Связи по данным и управлению
Пример структурной карты, описывающей межмодульные отношения в рассмотренном ранее фрагменте банковской системы, приведен на рис. 1.6.
Рис. 1.6. Пример структурной карты Константайна
В чем заключается методика константайна
Файл: Технол_разраб_прогр_обесп_Гагарина_Кокарева.doc
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлена: 20.11.2019
Просмотров: 3473
Скачиваний: 58
Назовите функциональные и эксплуатационные требования к программному продукту .
Перечислите составляющие эскизного проекта .
ЛАБОРАТОРНАЯ РАБОТА № 3. Структурный подход к программированию. Стадия «Технический проект»
Цель работы: изучить вопросы проектирования программного обеспечения.
Лабораторная работа рассчитана на 4 академических часа.
1. Ознакомиться с лекционным материалом по теме «Этапы
разработки программного обеспечения. Проектирование про-
граммного обеспечения» учебной дисциплины «Технология раз-
работки программного обеспечения».
Изучить соответствующие разделы в изданиях [1, 39, 47, 53].
Ознакомиться с разд. 4.1—4.3 настоящего пособия.
ПРОЕКТ ТЕХНИЧЕСКИЙ — образ намеченного к созданию объекта, представленный в виде его описания, схем, чертежей, расчетов, обоснований, числовых показателей.
Цель технического проекта — определение основных методов, используемых при создании информационной системы, и окончательное определение ее сметной стоимости.
Техническое проектирование подсистем осуществляется в соответствии с утвержденным техническим заданием.
Технический проект программной системы подробно описывает:
выполняемые функции и варианты их использования;
соответствующие им документы;
структуры обрабатываемых баз данных;
алгоритмы их обработки.
Технический проект должен включать данные об объемах и интенсивности потоков обрабатываемой информации, количестве пользователей программной системы, характеристиках оборудования и программного обеспечения, взаимодействующего с проектируемым программным продуктом.
При разработке технического проекта оформляются:
ведомость технического проекта. Общая информация по проекту;
пояснительная записка к техническому проекту. Вводная информация, позволяющая ее потребителю быстро освоить данные по конкретному проекту;
описание систем классификации и кодирования;
перечень входных данных (документов). Перечень информации, которая используется как входящий поток и служит источником накопления;
перечень выходных данных (документов). Перечень информации, которая используется для анализа накопленных данных;
описание используемого программного обеспечения. Перечень программного обеспечения и СУБД, которые планируется использовать для создания информационной системы;
описание используемых технических средств. Перечень аппаратных средств, на которых планируется работа проектируемого программного продукта;
проектная оценка надежности системы. Экспертная оценка надежности с выявлением наиболее благополучных участков программной системы и ее узких мест;
ведомость оборудования и материалов. Перечень оборудования и материалов, которые потребуются в ходе реализации проекта.
Структурной называют схему, отражающую состав и взаимодействие по управлению частями разрабатываемого программного обеспечения. Структурная схема определяется архитектурой разрабатываемого ПО (см. разд. 4.1.1).
Функциональная схема — это схема взаимодействия компонентов программного обеспечения с описанием информационных потоков, состава данных в потоках и указанием используемых файлов и устройств (см. разд. 4.1.2).
Метод пошаговой детализации реализует нисходящий подход к программированию и предполагает пошаговую разработку алгоритма (см. разд. 4.1.3).
Методика структурных карт используется на этапе проектирования ПО для того, чтобы продемонстрировать, каким образом программный продукт выполняет системные требования. Структурные карты Константайна предназначены для описания отношений между модулями (см. разд. 4.2).
Техника структурных карт Джексона основана на методе структурного программирования Джексона, который выявляет соответствие между структурой потоков данных и структурой программы. Основное внимание в методе сконцентрировано на соответствии входных и выходных потоков данных (см. разд. 4.3).
На основе технического задания из лабораторной работы № 1 и спецификаций из лабораторной работы № 2 разработать уточненные алгоритмы программ, составляющих заданный программный модуль. Использовать метод пошаговой детализации (см. разд. 4.1.3).
На основе уточненных и доработанных алгоритмов разработать структурную схему программного продукта (разд. 4.1.1).
Разработать функциональную схему программного продукта (разд. 4.1.2).
Представить структурную схему в виде структурных карт Константайна (см. разд. 4.2).
Представить структурную схему в виде структурных карт Джексона (см. разд. 4.3).
Оформить результаты, используя MS Office или MS Visio в виде технического проекта.
Сдать и защитить работу.
Отчет по лабораторной работе должен состоять из:
Структурной схемы программного продукта.
Структурной карты Константайна.
Структурной карты Джексона.
Законченного технического проекта программного модуля.
Защита отчета по лабораторной работе заключается в предъявлении преподавателю полученных результатов (на экране монитора), демонстрации полученных навыков и ответах на вопросы преподавателя.
Назовите этапы разработки программного обеспечения .
В чем заключается проектирование программного обеспечения ?
Перечислите составляющие технического проекта .
Охарактеризуйте структурный подход к программированию .
Охарактеризуйте метод пошаговой детализации при составлении алгоритмов программ .
ЛАБОРАТОРНАЯ РАБОТА № 4.
Этапы разработки программного обеспечения.
Цель работы: разработать программный продукт в соответствии с заданным вариантом.
Лабораторная работа рассчитана на 4 академических часа.
Ознакомиться с лекционным материалом по теме «Этапы разработки программного обеспечения. Структурный подход к программированию» учебной дисциплины «Технология разработки программного обеспечения».
Изучить соответствующие разделы в изданиях [1, 2, 5, 7, 40].
3. Ознакомиться с гл. 6 настоящего пособия.
Важным этапом разработки программного продукта является составление программной документации. Жизненный цикл программного обеспечения содержит специальный процесс, посвященный этому вопросу. На каждый программный продукт должны составляться два типа документации — для разработчиков и для различных групп пользователей. Программная документация пользователей должна содержать все необходимые сведения по эксплуатации ПО. Аналогично, документация разработчика должна содержать сведения, необходимые для разработки и сопровождения программного обеспечения.
Виды программных документов
Документирование программного обеспечения осуществляется в соответствии с Единой системой программной документации (ГОСТ 19.ХХХ). ГОСТ 19.101—77 содержит виды программных документов для программного обеспечения различных типов. В данном ГОСТе перечислены документы следующих типов:
спецификация должна содержать перечень и краткое описание назначения всех файлов программного обеспечения, в том числе и файлов документации на него, и является обязательной для программных систем, а также их компонентов, имеющих самостоятельное применение;
ведомость держателей подлинников (код вида документа — 05) должна содержать список предприятий, на которых хранятся подлинники программных документов. Необходимость этого документа определяется на этапе разработки и утверждения технического задания только для программного обеспечения со сложной архитектурой;
текст программы (код вида документа — 12) должен содержать текст программы с необходимыми комментариями. Необходимость этого документа определяется на этапе разработки и утверждения технического задания;
описание программы (код вида документа — 13) должно содержать сведения о логической структуре и функционировании программы. Необходимость данного документа также определяется на этапе разработки и утверждения технического задания;
ведомость эксплуатационных документов (код вида документа — 20) должна содержать перечень эксплуатационных документов на программу, к которым относятся документы с кодами 30, 31, 32, 33, 34, 35, 46. Необходимость этого документа также определяется на этапе разработки и утверждения технического задания;
формуляр (код вида документа — 30) должен содержать основные характеристики программного обеспечения, комплектность и сведения об эксплуатации программы;
описание применения (код вида документа — 31) должно содержать сведения о назначении программного обеспечения, области применения, применяемых методах, классе решаемых задач, ограничениях для применения, минимальной конфигурации технических средств;
руководство системного программиста (код вида документа — 32) должно содержать сведения для проверки, обеспечения функционирования и настройки программы на условия конкретного применения;
руководство программиста (код вида документа 33) должно содержать сведения для эксплуатации программного обеспечения;
руководство оператора (код вида документа — 34) содержит сведения для обеспечения процедуры общения оператора с вычислительной системой в процессе выполнения программы;
описание языка (код вида документа — 35) — описание синтаксиса и семантики языка программы;
руководство по техническому обслуживанию (код вида документа — 46) содержит сведения для применения программы при обслуживании технических средств.
1. По результатам лабораторных работ № 1—3 написать код
программ для решения поставленной задачи на языке програм-
мирования, выбранном на этапе эскизного проектирования.
Отладить программный модуль.
Получить результаты работы.
4. Оформить документацию к разработанному программному
обеспечению.
5. Сдать и защитить работу.
Отчет по лабораторной работе должен состоять из:
Документации к программному обеспечению (руководство пользователя, руководство системного программиста, руководство программиста, руководство оператора).
Результатов работы программ.
Защита отчета по лабораторной работе заключается в предъявлении преподавателю полученных результатов (на экране монитора), демонстрации полученных навыков и ответах на вопросы преподавателя.
Какие существуют инструментальные средства разработки ?
Охарактеризуйте этап стихийного программирования .
Охарактеризуйте этапы структурного и модульного программирования .