В современных информационных технологиях важное место отводится инструментальным средствам и средам разработки АИС, в частности системам разработки и сопровождения их программного обеспечения.
Эти технологии и среды образуют системы, называемые CASE-системами [36].
Используется двоякое толкование аббревиатуры CASE, соот-ветствующее двум направлениям использования CASE-систем. Первое из них — Computer Aided Software Engineering — переводится как автоматизированное проектирование программного обеспечения, соответствующие CASE-системы часто называют инстру-ментальными средами разработки ПО (RAD — Rapid Application Development). Второе — Computer Aided System Engineering — подчеркивает направленность на поддержку концептуального проек-тирования сложных систем, преимущественно слабоструктурированных. Такие CASE-системы часто называют системами BPR (Business Process Reengineering).
Обзор технологий и рынка CASE-средств, наиболее распространенных в странах СНГ, приведен в приложении 2.
Инструментальные средства разработки ПО Лекция 2 06 10 15
Среди систем RAD различают интегрированные комплексы инструментальных средств для автоматизации всех этапов жизненного цикла ПО (такие системы называют Workbench) и специализированные инструментальные средства для выполнения отдельных функций (Tools).
Средства CASE по своему функциональному назначению принадлежат к одной из следующих групп:
средства управления программным проектом;
средства верификации (анализа) программ;
Проектирование ПО с помощью CASE-систем. Оно включает несколько этапов. Начальный этап — предварительное изучение пробле-мы. Результат представляется в виде исходной диаграммы потоков данных и согласуется с заказчиком. На следующем этапе выполняется детализация ограничений и функций программной системы, и по-лученная логическая модель вновь согласуется с заказчиком.
Далее разрабатывается физическая модель, т.е. определяется модульная структура программы, выполняется инфологическое проектирование базы данных, детализируются граф-схемы программной системы и ее модулей, проектируется пользовательский интерфейс.
Примерами широко известных инструментальных сред RAD служат VB (Visual Basic), Delphi, PowerBuilder соответственно фирм Microsoft, Borland, PowerSoft. Применение инструментальных сред существенно сокращает объем ручной работы программистов (особенно при разработке интерфейсных частей программ)..
В средах быстрой разработки приложений обычно реализуется способ программирования, называемый управлением событиями. При этом достигается автоматическое создание каркасов программ, существенно сокращается объем ручного кодирования, особенно при разработке интефейсных частей программ. В этих средах пользователь может работать одновременно с несколькими экранами (окнами). Типичными являются окна из следующего списка.
Окно меню с пунктами «file», «edit», «window» и т.п., реализующими функции, очевидные из названия пунктов.
Окно формы, на котором, собственно, и создается прототип экрана будущей прикладной программы.
Инструментальные средства разработки ПО Лекция 1 18 09 15
Палитра инструментов — набор изображений объектов пользовательского интерфейса, из них можно компоновать окно формы.
Окно свойств и событий, с помощью которого ставятся в соответствие друг другу объекты окна формы, события и обработчики событий. Событием в прикладной программе является нажатие клавиши или установка курсора мыши в объект формы. Каждому событию должна соответствовать событийная процедура (обработчик события), проверяющая код клавиши и вызывающая нужную реакцию.
Окно редактора кода, на котором пользователь записывает создаваемую вручную часть кода.
Окно проекта — список модулей и форм в создаваемой прог-рамме.
Для написания событийных процедур в Visual Basic используется язык и текстовый редактор языка Basic, в Delphi — язык и редактор языка Object Pascal. В CASE-системе фирмы IBM.
включающей части VisualAge (для клиентских приложений) и VisualGen (для серверных приложений), базовым языком выбран SmallTalk. В среде разработки приложений «клиент-сервер» SQLWindows оригинальные фрагменты программ пишутся на специальном языке SAL. Нужно заметить, что для реализации вычислительных процедур, в частности для написания мини-спецификаций, используется обычная для 3GL технология программирования.
Обычно после написания ПП на базовом языке компилятор системы переводит программу на промежуточный р-код. Вместе с интерпретатором р-кода эта программа рассматривается, как ЕХЕ-файл. В некоторых развитых средах компилируется обычный ЕХЕ-файл, не требующий интерпретации для своего исполнения.
Помимо упрощения написания пользовательского интерфейса, в средах RAD предусматриваются средства для реализации и ряда других функций. Так, в наиболее развитой версии Visual Basic к ним относятся средства выполнения следующих функций:
поддержка ODBC, что дает возможность работы с различными СУБД;
разработка баз данных;
разработка трехзвенных систем распределенных вычислений;
интерактивная отладка процедур на SQL Server;
управление версиями при групповой разработке ПО;
моделирование и анализ сценариев распределенных вычис-лений.
Создание сред RAD для сетевого программирования требует ре-шения ряда дополнительных проблем, обусловливаемых много- платформенностью, обилием применяемых форматов данных и т.п. Решение этих проблем, а также устранение некоторых особенностей языка С++, усложняющих программирование, достиг-нуто в языке программирования Java. Для этого языка разработа-на своя инструментальная среда JDK (Java Developer’s Kit). В ней имеются библиотека классов и инструментальные средства, такие, как компилятор байт-кодов, интерпретатор, просмотрщик апле- тов, отладчик, формирователь оконных форм и т.п. Значительное внимание уделяется разработке инструментальных сред для создания Web-узлов, примером такой среды может служить HAHTSite фирмы HAHTSoftware.
Для разработки Java-программ из готовых компонентов служит среда IBM Visial Age for Java, в которой имеются (как и в среде VB) учебная, профессиональная и общецелевая (Enterprise) версии.
Спецификации моделей информационных систем. Важное значение в процессе разработки информационных систем имеют средства спецификации их проектов. Средства спецификации в значительной мере определяют суть методов CASE.
Существует ряд способов представления моделей [36]. Практически все способы функциональных спецификаций имеют следующие общие черты:
модель имеет иерархическую структуру, представляемую в виде диаграмм нескольких уровней;
элементарной частью диаграммы каждого уровня является конструкция «вход — функция — выход»;
необходимая дополнительная информация содержится в файлах поясняющего текста.
В большинстве случаев функциональные диаграммы — это диаграммы потоков данных (DFD — Data Flow Diagram). В DFD блоки (прямоугольники) соответствуют функциям, дуги — входным и выходным потокам данных. Поясняющий текст дается в виде «словарей данных», в которых указываются компонентный состав потоков данных, число повторений циклов и т.п. Для описания структуры информационных потоков можно использовать нотацию Бэкуса — Наура.
Разработка DFD начинается с построения диаграммы верхнего уровня, отражающей связи программной системы, представленной в виде единого процесса, с внешней средой. Декомпозиция процесса проводится до уровня, где фигурируют элементарные процессы, которые могут быть представлены одностранич- ными описаниями алгоритмов (мини-спецификациями) на языке программирования.
Для описания информационных моделей наибольшее распро-странение получили диаграммы «сущность — связь» (ERD — Entity- Relations Diagrams), фигурирующие, например, в методике IDEF1X.
Поведенческие модели описывают процессы обработки ин-формации. В системах CASE их представляют в виде граф-схем, диаграмм перехода состояний, таблиц решений, псевдокодов (язы-ков спецификаций), языков программирования, в том числе языков четвертого поколения (4GL).
В граф-схемах блоки, как и в DFD, используют для задания процессов обработки, но дуги имеют иной смысл: они описывают последовательность передач управления (вместе со специальными блоками управления).
В диаграммах перехода состояний узлы соответствуют состояниям моделируемой системы, дуги — переходам из состояния в состояние, атрибуты дуг — условиям перехода и инициируемым при их выполнении действиям.
Очевидно, что, как и в других, конечно-автоматных моделях, кроме графической формы пред-ставления диаграмм перехода состояний, можно использовать также табличные формы. Так, при изоморфном представлении с помощью таблиц перехода состояний каждому переходу соответствует строка таблицы, в которой указываются исходное состояние, условие перехода, инициируемое при этом действие и новое состояние после перехода.
Близкий по своему характеру способ описания процессов ос-нован на таблицах (или деревьях) решений. Каждый столбец таблицы решений соответствует определенному сочетанию условий, при выполнении которых осуществляются действия, указанные в нижерасположенных клетках столбца.
В псевдокодах алгоритмы записываются с помощью как средств некоторого языка программирования (преимущественно для уп-равляющих операторов), так и естественного языка (для выражения содержания вычислительных блоков). Используются конструкции (операторы) следования (условные) цикла.
Языки четвертого поколения направлены на описание программ как совокупностей заранее разработанных программных модулей, поэтому возможно соответствие одной команды языка 4GL значительному фрагменту программы на языке 3GL. Примерами языков 4GL могут служить Informix-4GL, JAM, NewEra.
Мини-спецификации процессов могут быть выражены с помощью псевдокодов (языков спецификаций), визуальных языков проектирования или языков программирования.
Источник: inlib.biz
Презентация на тему Инструментальные средства разработки программного обеспечения
Программное обеспечение Под программным обеспечением (ПО) понимается совокупность программных и документальных средств для создания и эксплуатации систем обработки данных средствами вычислительной техники. В самом общем плане программное обеспечение для вычислительной техники
- Главная
- Менеджмент
- Инструментальные средства разработки программного обеспечения
Слайды и текст этой презентации
Слайд 1Инструментальные средства разработки программного обеспечения
Разработал: Горькин Б.М.
преподаватель
ТМК
ГАПОУ Самарской области
Тольяттинский машиностроительный колледж
2015
Слайд 2Программное обеспечение
Под программным обеспечением (ПО) понимается совокупность
программных и документальных средств для создания и
эксплуатации систем обработки данных средствами вычислительной техники. В самом общем плане программное обеспечение для вычислительной техники может быть разделено (в зависимости от назначения) на системное, инструментальное и прикладное (как и всякая классификация данное деление условно).
Инструментальное программное обеспечение используется для создания программных продуктов в любой области, включая и системные программы.
Слайд 3Общие сведения о CASE-технологиях
Под термином CASE-средства
понимаются программные средства, поддерживающие процессы создания и
сопровождения ИС, включая анализ и формулировку требований, проектирование прикладного ПО (приложений) и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы. CASE-средства вместе с системным ПО и техническими средствами образуют полную среду разработки ИС.
Основной целью CASE-технологии является разграничение процесса проектирования программных продуктов от процесса кодирования и последующих этапов разработки, максимально автоматизировать процесс разработки.
Слайд 4Методы структурного анализа и проектирования
Для выполнения поставленной
цели CASE-технологии используют два принципиально разных подхода
к проектированию: структурный и объектно-ориентированный.
Структурный подход предполагает декомпозицию (разделение) поставленной задачи на функции, которые необходимо автоматизировать. В свою очередь, функции также разбиваются на подфункции, задачи, процедуры. В результате получается упорядоченная иерархия функций и передаваемой информацией между функциями.
Структурный подход подразумевает использование определенных общепринятых методологий при моделировании различных информационных систем:
SADT (Structured Analysis and Design Technique);
DFD (Data Flow Diagrams);
ERD (Entity-Relationship Diagrams).
Существует три основных типа моделей, используемых при структурном подходе: функциональные, информационные и структурные.
Основным инструментом объектно-ориентированного подхода является язык UML — унифицированный язык моделирования, который предназначен для визуализации и документирования объектно-ориентированных систем с ориентацией их на разработку программного обеспечения. Данный язык включает в себя систему различных диаграмм, на основании которых может быть построено представление о проектируемой системе.
Слайд 5Методология функционального моделирования IDEFО. Общие сведения
IDEF0(ICAM DEFinition
language 0) — Function Modeling — методология
функционального моделирования. С помощью наглядного графического языка IDEF0 изучаемая система предстает перед разработчиками и аналитиками в виде набора взаимосвязанных функций (функциональных блоков — в терминах IDEF0). Как правило, моделирование средствами IDEF0 является первым этапом изучения любой системы.
Слайд 6Общие сведения методологии функционального моделирования IDEFО.
Графический
язык IDEF0 удивительно прост и гармоничен. В
основе методологии лежат четыре основных понятия.
Первым из них является понятие функционального блока (Activity Box). Функциональный блок графически изображается в виде прямоугольника и олицетворяет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, «производить услуги», а не «производство услуг»).
Слайд 7Общие сведения методологии функционального моделирования IDEFО.
Вторым
«китом» методологии IDEF0 является понятие интерфейсной дуги (Arrow).
Также интерфейсные дуги часто называют потоками или стрелками. Интерфейсная дуга отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, отображенную данным функциональным блоком.
Графическим отображением интерфейсной дуги является однонаправленная стрелка. Каждая интерфейсная дуга должна иметь свое уникальное наименование (Arrow Label). По требованию стандарта, наименование должно быть оборотом существительного.
С помощью интерфейсных дуг отображают различные объекты, в той или иной степени определяющие процессы, происходящие в системе. Такими объектами могут быть элементы реального мира (детали, вагоны, сотрудники и т. д.) или потоки данных и информации (документы, данные, инструкции и т. д.).
В зависимости от того, к какой из сторон подходит данная интерфейсная дуга, она носит название «входящей», «исходящей» или «управляющей». Кроме того, «источником» (началом) и «приемником» (концом) каждой функциональной дуги могут быть только функциональные блоки. Необходимо отметить, что любой функциональный блок по требованиям стандарта должен иметь по крайней мере одну управляющую интерфейсную дугу и одну исходящую.
Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта IDEF0 от других методологий классов DFD (Data Flow Diagram) и WFD (Work Flow Diagram).
Слайд 8Общие сведения методологии функционального моделирования IDEF0.
третьим
основным понятием стандарта IDEF0 является декомпозиция (Decomposition). Принцип
декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели.
Декомпозиция позволяет постепенно и структурированно представлять модель системы в виде иерархической структуры отдельных диаграмм, что делает ее менее перегруженной и легко усваиваемой.
Слайд 9Общие сведения методологии функционального моделирования IDEF0.
Последним
из понятий IDEF0 является глоссарий (Glossary). Для каждого
из элементов IDEF0: диаграмм, функциональных блоков, интерфейсных дуг существующий стандарт подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных изложений и т. д., которые характеризуют объект, отображенный данным элементом. Этот набор называется глоссарием и является описанием сущности данного элемента. Например, для управляющей интерфейсной дуги «распоряжение об оплате» глоссарий может содержать перечень полей соответствующего дуге документа, необходимый набор виз и т. д. Глоссарий гармонично дополняет наглядный графический язык, снабжая диаграммы необходимой дополнительной информацией.
Слайд 10Синтаксис IDEF0-диаграмм
Диаграммы являются основными рабочими элементами
IDEF0-модели. Диаграммы представляют входные-выходные преобразования и указывают
правила и средства этих преобразований. Каждая IDEF0-диаграмма содержит блоки (работы) и дуги (линии со стрелками). Блоки изображают функции моделируемой системы. Дуги связывают блоки вместе и отображают взаимодейст вия и взаимосвязи между ними.
Слайд 11Синтаксис блоков
Функциональные блоки на диаграмме изображаются прямоугольниками
. Блок представляет функцию или активную часть
Каждая сторона блока имеет определенное назначение. Левая сторона предназначена для входов, верхняя – для управления, правая – для выходов, нижняя – для механизмов и вызовов [1, 11, 12].
Слайд 12Назначение дуг
В IDEF0 различают пять типов дуг:
вход (input), управление (control), выход (output), механизм
(mechanism), вызов (call) [11]. В основе методологии IDEF0 лежат следующие правила:
вход представляет собой входные данные, используемые или преобразуемые функциональным блоком для получения результата (выхода); блок может не иметь ни одной входной дуги (например блок, выполняющий генерацию случайных чисел);
выход представляет собой результат работы блока; наличие выходной дуги для каждого блока является обязательным; управление ограничивает или определяет условия выполнения преобразований в блоке;
в качестве дуг управления могут использоваться некоторые условия, правила, стратегии, стандарты, которые влияют на выполнение функционального блока; наличие управляющей дуги для каждого блока является обязательным;
механизмы показывают, кто, что и как выполняет преобразования в блоке; механизмы определяют ресурсы, непосредственно осуществляющие эти преобразования (например, денежные средства, персонал, оборудование и т.п.); механизмы представляются стрелками, подключенными к нижней стороне блока и направленными вверх к блоку; наличие дуг механизмов для блока не является обязательным;
вызовы представляют собой специальный вид дуги и обозначают об- ращение из данной модели или из данной части модели к блоку, входящему в состав другой модели или другой части модели, обеспечивая их связь; с помощью дуги вызова разные модели или разные части одной модели могут совместно использовать один и тот же блок; вызовы не являются компонентом собственно методологии SADT , предназначены для организации коллективной работы над моделью, разделения модели на независимые модели и объединения различных моделей предметной области в одну модель; вызовы представляются стрелка- ми, подключенными к нижней стороне блока и направленными вниз от блока; наличие дуги вызова для блока не является обязательным.
Слайд 13Декомпозиция и её стратегии
Декомпозиция — это процесс
создания диаграммы, детализирующей определенный блок и связанные
с ним дуги. Результатом ее является описание, которое представляет собой «разламывание» родительского блока на меньшие и более частные функции. Прибавьте к этому еще и тот факт, что слово «анализ» означает разложение на составляющие, и вы получите исходное обоснование термина «структурный анализ». Но декомпозиция — это больше, чем анализ. Она включает также синтез.
Подлинная декомпозиция заключается в начальном разделении объекта на более мелкие части и последующем соединении их в более детальное описание объекта. Интересно отметить, что модель показывает только результат взаимодействия анализа и синтеза.
Слайд 14Декомпозиция и её стратегии
Декомпозиция — это процесс
создания диаграммы, детализирующей определенный блок и связанные
с ним дуги. Результатом ее является описание, которое представляет собой «разламывание» родительского блока на меньшие и более частные функции. Прибавьте к этому еще и тот факт, что слово «анализ» означает разложение на составляющие, и вы получите исходное обоснование термина «структурный анализ». Но декомпозиция — это больше, чем анализ. Она включает также синтез.
Подлинная декомпозиция заключается в начальном разделении объекта на более мелкие части и последующем соединении их в более детальное описание объекта. Интересно отметить, что модель показывает только результат взаимодействия анализа и синтеза.
Слайд 15Что такое IDEF1X?
Методология IDEF1X (IDEF1 Extended) –
язык для семантического моделирования данных, основанных на
концепции «сущность-связь». Является расширением стандарта IDEF1.
Диаграмма «сущность-связь» ERD (Entity-Relationship Diagram) предназначена для разработки модели данных и обеспечивает стандартный способ определения данных и отношений между ними.
Теоретической базой построения информационной модели является теория баз данных типа «сущность-связь».
Слайд 16Что такое IDEF1X?
Согласно стандарту , основными составляющими
модели IDEF1X являются:
1) люди, предметы, явления, о
которых хранится информация (далее – сущности)
2) связи между этими элементами (далее – отношения)
3) характеристики этих элементов (далее – атрибуты)
Слайд 17Понятие отношения
Отношения – связь между двумя и
более сущностями. Именование отношения осуществляется с помощью
грамматического оборота глагола (имеет, определяет, …).
Таким образом…
Сущности представляют собой базовый тип информации, хранимый в БД, а отношения показывают, как эти типы данных взаимосвязаны друг с другом.
Слайд 18Правила определения сущности
Сущность должна иметь уникальное имя
и именоваться существительным в единственном числе.
Пример:
Студент, Кредитная карта, Договор,…
Сущность обладает одним или несколькими атрибутами, которые ей либо принадлежат, либо наследуются через отношения.
Сущность обладает одним или несколькими атрибутами, которые однозначно идентифицируют каждый образец сущности и называются ключом (составным ключом).
Слайд 19Правила определения сущности
Каждая сущность может обладать любым
количеством отношений с другими сущностями.
Если внешний ключ
целиком используется в составе первичного ключа, то сущность является зависимой от идентификатора.
В нотации IDEF1X сущность изображается в виде прямоугольника, в зависимости от уровня представления данных могут быть некоторые различия
Слайд 20Графическое представление сущности
Различают следующие уровни представления сущности:
диаграмма «сущность-связь» (ERD), модель данных, основанная на
ключах (KB), полная атрибутивная модель (FA)
Слайд 21Правила определения атрибутов
Каждый атрибут каждой сущности обладает
уникальным именем.
Сущность может обладать любым количеством атрибутов.
Различают собственные и наследуемые атрибуты. Собственные атрибуты являются уникальными в рамках модели. Наследуемые передаются от сущности-родителя при определении идентифицирующей связи.
Источник: thepresentation.ru
Программные продукты и системы
(сведения по итогам 2021 г.)
2-летний импакт-фактор РИНЦ: 0,441
2-летний импакт-фактор РИНЦ без самоцитирования: 0,408
Двухлетний импакт-фактор РИНЦ с учетом цитирования из всех
источников: 0,704
5-летний импакт-фактор РИНЦ: 0,417
5-летний импакт-фактор РИНЦ без самоцитирования: 0,382
Суммарное число цитирований журнала в РИНЦ: 9837
Пятилетний индекс Херфиндаля по цитирующим журналам: 149
Индекс Херфиндаля по организациям авторов: 384
Десятилетний индекс Хирша: 71
Место в общем рейтинге SCIENCE INDEX за 2021 год: 196
Место в рейтинге SCIENCE INDEX за 2021 год по тематике «Автоматика. Вычислительная техника»: 4
Место в рейтинге SCIENCE INDEX за 2021 год по тематике «Кибернетика» 2
Источник: www.swsys.ru