ИГА. Понятие базы данных
 Скачать 0.77 Mb.
|
CASE-средства. Общая характеристика и классификацияСовременные CASE-средства охватывают обширную область поддержки многочисленных технологий проектирования ИС: от простых средств анализа и документирования до полномасштабных средств автоматизации, покрывающих весь жизненный цикл ПО. Наиболее трудоемкими этапами разработки ИС являются этапы анализа и проектирования, в процессе которых CASE-средства обеспечивают качество принимаемых технических решений и подготовку проектной документации. При этом большую роль играют методы визуального представления информации. Это предполагает построение структурных или иных диаграмм в реальном масштабе времени, использование многообразной цветовой палитры, сквозную проверку синтаксических правил. Графические средства моделирования предметной области позволяют разработчикам в наглядном виде изучать существующую ИС, перестраивать ее в соответствии с поставленными целями и имеющимися ограничениями. В разряд CASE-средств попадают как относительно дешевые системы для персональных компьютеров с весьма ограниченными возможностями, так и дорогостоящие системы для неоднородных вычислительных платформ и операционных сред. Так, современный Рынок программных средств насчитывает около 300 различных CASE-средств, наиболее мощные из которых так или иначе используются практически всеми ведущими западными фирмами. Обычно к CASE-средствам относят любое программное средство, автоматизирующее ту или иную совокупность процессов жизненного цикла ПО и обладающее следующими основными характерными особенностями: мощными графическими средствами для описания и документирования АИС, обеспечивающими удобный интерфейс с разработчиком и развивающими его творческие возможности; интеграцией отдельных компонент CASE-средств, обеспечивающей управляемость процессом разработки АИС; использованием специальным образом организованного хранилища проектных метаданных (репозитория). Классификация по типам в основном совпадает с компонентным составом CASE-средств и включает следующие основные типы (после названия средства в скобках указана фирма-разработчик): средства анализа (UpperCASE), предназначенные для построения и анализа моделей предметной области (Design / IDEF (Meta Software), BPwin (Logic Works)); средства анализа и проектирования (Middle CASE ), поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций ( VantageTeamBuilder( Cayenne ),Designer /2000 (ORACLE), Silvernm (CSA), PRO - IV (McDonnell Douglas), CASE. Аналитик (Макро Проджект)). Выходом таких средств являются спецификации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных; средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее распространенных СУБД. К нимо тносятся ERwin (Logic Works), S-Designor (SDP) и DataBase Designer (ORACLE). Средства проектирования баз данных имеются также в составе CASE-средств Vantage Team Builder, Designer /2000, Silvernm и PRO - IV; средства разработки приложений. К ним относятся средства 4 GL (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer /2000 (ORACLE), NewEra (Informix), SQL Windows (Gupta ), Delphi (Borland) и др.) и генераторы кодов, входящие в состав Vantage Team Builder, PRO -ГУ и частично — в Silvernm; средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций. Средства анализа схем БД и формирования ERD входят в состав Vantage TeamBuilder, PRO -ГУ, Silvernm, Designer /2000, ERwin и S-Designor . В области анализа программных кодов наибольшее распространение получают объектно-ориентированные CASE-средства, обеспечивающие реинжиниринг программ на языке C++ ( RationalRose (Rational Software), ObjectTeam (Cayenne)). Вспомогательные типы включают: средства планирования и управления проектом (SECompanion, Microsoft Project и др.); средства конфигурационного управления (PVCS (Intersolv)); средства тестирования(Quality Works (Segue Software)); средства документ ирования (SoDA (Rational Software)). Размерно-ориентированные метрики.Измерения помогают оценить как продукт, так и сам процесс его разработки. В результате измерений определяется мера - количественная характеристика какого-либо свойства объекта. Некоторые измерения позволяют сразу определить свойства объекта. А остальные можно получить лишь за счет вычисления от значений опорных характеристик. Результаты подобных вычислений называют метриками. Зачастую понятие мера и метрика рассматривают как равноценные определения. Измерения при разработке ПО необходимы для того, чтобы: - определить или показать качество продукции; - оценить производительность труда персонала, занятого разработкой; - оценить выгоды (прибыль или доход), которые могут быть получены в результате разработки новых программных средств; - сформировать основу (базовую линию) для последующих оценок; - получить данные для обоснования запросов на дополнительные средства, обучение и т.п. Измерения бывают прямые и косвенные. Результаты прямых измерений процесса разработки и сопровождения программного изделия: трудозатраты и стоимость, число строк кода (LOC - lines-of-code), размер требуемой памяти, скорость выполнения программы, число ошибок (дефектов), обнаруженных за определенный период времени. Косвенные измерения дают оценку функциональных возможностей, показателей качества программного продукта (надежность, эффективность, пригодность к сопровождению и т.п.). Существует деление метрик на 3 группы: метрики производительности, метрики качества продукции и технические характеристики продукта. Метрики производительности фокусируются на выходе процессов разработки ПО. Метрики качества позволяют судить о том, насколько близко соответствие программного изделия явным и подразумеваемым требованиям пользователя, т.е. пригодности изделия к использованию. Технические метрики в большей степени относятся к особенностям программного изделия, а не к процессу его разработки (например, логическая сложность изделия, модульность проекта и т.п.). Вторая классификация метрик - классификация по признаку их ориентации: - размеро-ориентированные метрики, использующиеся для сбора результатов прямых измерений программного продукта и его качества, а также процесса разработки; - функционально-ориентированные метрики, которые являются косвенными мерами, характеризующими функциональное назначение продукта и особенности его входных и выходных данных; - человеко-ориентированные метрики, которые также являются косвенными мерами, позволяющими судить об отношении персонала (разработчиков и пользователей), об эффективности и качестве работы программного изделия, удобстве взаимодействия с ним, простоте обучения и т.д. Размерно-ориентированные метрики Размерно-ориентированные метрики прямо измеряют программный продукт и процесс его разработки. Основываются такие метрики на LOC-оценках (Lines Of Code). LOC-оценка - это количество строк в программном продукте. Принято регистрировать следующие показатели: - общие затраты (в человеко-месяцах - чел.-мес); - объем программного изделия (в тысячах строк исходного кода -KLOC); - стоимость разработки (в тыс.рублей или в долларах $); - объем документации (в страницах документов -СД); - ошибки, обнаруженные в течение первого года эксплуатации (число ошибок - ЧО); - число людей, работавших над изделием (человек); - срок разработки (в календарных месяцах). На основе перечисленных показателей вычисляются размерно-ориентированные метрики производительности и качества (для каждого проекта): Достоинства размерно-ориентированных метрик: 1) широко распространены; 2) просты и легко вычисляются. Недостатки размерно-ориентированных метрик: 1) зависимы от языка программирования; 2) требуют исходных данных, которые трудно получить на начальной стадии проекта; 3) не приспособлены к непроцедурным языкам программирования. Функционально-ориентированные метрики Функционально-ориентированные метрики косвенно измеряют программный продукт и процесс его разработки. Вместо подсчета LOC-оценки при этом рассматривается не размер, а функциональность или полезность продукта. Используется 5 информационных характеристик. 1. Количество внешних вводов. Подсчитываются все вводы пользователя, по которым поступают разные прикладные данные. Вводы должны быть отделены от запросов, которые подсчитываются отдельно. 2. Количество внешних выводов. Подсчитываются все выводы, по которым к пользователю поступают результаты, вычисленные программным приложением. В этом контексте выводы означают отчеты, экраны, распечатки, сообщения об ошибках. Индивидуальные единицы данных внутри отчета отдельно не подсчитываются. 3. Количество внешних запросов. Под запросом понимается диалоговый ввод, который приводит к немедленному программному ответу в форме диалогового вывода. При этом диалоговый ввод в приложении не сохраняется, а диалоговый вывод не требует выполнения вычислений. Подсчитываются все запросы - каждый учитывается отдельно. 4. Количество внутренних логических файлов. Подсчитываются все логические файлы (то есть логические группы данных, которые могут быть частью базы данных или отдельным файлом). 5. Количество внешних интерфейсных файлов. Подсчитываются все логические файлы из других приложений, на которые ссылается данное приложение. Количество функциональных указателей вычисляется по формуле После вычисления FP на его основе формируются метрики производительности, качества и т. д.: Область применения метода функциональных указателей - коммерческие информационные системы. Для продуктов с высокой алгоритмической сложностью используются метрики указателей свойств (Features Points). Они применимы к системному и инженерному ПО. ПО реального времени и встроенному ПО. Для вычисления указателя свойств добавляется одна характеристика - количество алгоритмов. Алгоритм здесь определяется как ограниченная подпрограмма вычислений, которая включается в общую компьютерную программу. Примеры алгоритмов: обработка прерываний, инвертирование матрицы, расшифровка битовой строки. Для формирования указателя свойств составляется табл. 6. Достоинства функционально-ориентированных метрик: 1. Не зависят от языка программирования. 2. Легко вычисляются на любой стадии проекта. Недостаток функционально-ориентированных метрик: результаты основаны на субъективных данных, используются не прямые, а косвенные измерения. FP-оценки легко пересчитать в LOC-оценки. Результаты пересчета зависят от языка программирования, используемого для реализации ПО. |