Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

otvety_118

.pdf
Скачиваний:
60
Добавлен:
01.04.2015
Размер:
1.71 Mб
Скачать

41

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

24.Технологии доступа к данным.

Технологии доступа к данным: ODBC, JDBC, OLE DB, ADO, DAO, BDE ODBC

автор Zer0 рубрики ПРиС

(Open Database Connectivity) — открытый интерфейс баз данных.

Необходимость создания ODBC появилась вследствие того, что каждая фирма — разработчица СУБД использовала свой диалект SQL, что делало невозможным обмен данными между двумя БД различных форматов. Поэтому вначале был разработан общий стандарт на SQL, получивший название CLI (Common Language Interface). Затем каждая фирма разрабатывала драйвер перевода своего диалекта SQL в CLI и наоборот.

ODBC предназначена для обеспечения возможности взаимосвязи между различными SQL-совместимыми БД.

Технология ODBC предусматривает создание дополнительного уровня между приложением и используемой СУБД. В архитектуре ODBC используется один ODBC Driver Manager и несколько ODBC-драйверов, отвечающих за реализацию особенностей доступа к каждой отдельной СУБД.

Преимущества:

?простота разработки приложения;

?технология ODBC позволяет создавать распределенные гетерогенные приложения без учета конкретных СУБД, т.е. приложение становится независимым от СУБД.

Недостатки:

?снижение скорости доступа к данным, что связано с необходимостью трансляции запросов;

?увеличение время обработки запросов, что связано с введением дополнительного программного слоя;

?необходимы предварительная инсталляция и настройка ODBC-драйвера (указание драйвера СУБД, сетевого пути к серверу, базы данных и т.д.) на каждом рабочем месте. Параметры этой настройки являются статическими, т.е. приложение изменить их самостоятельно не может;

?предоставляет доступ только к реляционным SQL-ориентированным БД. OLE DB

Но данные в БД могут быть представлены в любом виде и формате (электронные таблицы, документы в rtfформате, почтовые системы и т.д.).

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

Это требование и реализует технология OLE DB.

OLE DB ( Object Linking and Embedding Data Base) — технология, предоставляющее решение обеспечения СОМ-приложениям доступ данным независимо от типа источника данных.

В технологии OLE DB используется механизм провайдеров, под которыми понимают поставщиков данных.

Провайдер представляет собой компонент СОМ, позволяющий принимать вызовы OLE DB и выполнять все необходимое для обработки запроса к источнику данных. Провайдер возвращает запрашиваемый объект — обычно это данные в табличном виде.

Кроме поставщика данных имеются также сервис провайдеры, реализующие самые различные сервисные функции.

ADO, DAO

Технологии ODBC и OLE DB считаются хорошими интерфейсами передачи данных, но как программные интерфейсы имеют много ограничений, поскольку являются низкоуровневыми.

Для снятия этих ограничений были предложены технологии DAO и ADO.

DAO (Data Access Objects).

ADO (ActiveX Data Objects).

42

Данные технологии представляют собой высокоуровневые объектные модели (библиотеки функций) и создают еще один уровень абстракции между приложением и функциями ODBC и OLE DB.

Технология ADO представляет иерархическую модель объектов для доступа к различным OLE DBпровайдерам данных. Объектная модель ADO включает объекты, обеспечивающие соединение с провайдером данных, создание SQL-запросов к данным и т.д.

Модель объекта не содержит таблиц, среды. Здесь основными объектами являются:

?объект Набор данных;

?объект Соединение, создающий связь с провайдером данных;

?объект Команда — выполнение процедуры.

Особенностью технологии ADO является возможность ее использования в Интернет/Интранет-приложениях для доступа к различным источникам данных.

В целом технологию ADO можно охарактеризовать как наиболее современную технологию разработки приложении для работы с распределенными БД по технологии клиентсервер.

Технология DAO предназначена преимущественно для создания БД с помощью СУБД MS Access, т.к. кроме замены функций ODBC она осуществляет также прямой доступ к функциям ядра MS Jet базы данных Access.

BDE

BDE (Borland Data Engine) — технология фирмы Borland.

Данная технология реализована в виде динамически подключаемых библиотек и имеет достаточно развитый интерфейс прикладных программ, названный IDAPI (Integrated Database

Application Program Interface).

Этот интерфейс представляет собой набор функций для работы с базами данных Является некоторым аналогом ODBC. Как и ODBC технология BDE имеет набор

драйверов для работы с различными СУБД. Если собственного драйвера для доступа к некоторой СУБД в BDE нет, то используется драйвер доступа к ODBC.

JDBC

JDBC (Java Data Base Connectivity) — мобильный интерфейс к базам данных на платформе Java. Это интерфейс прикладного программирования для выполнения SQL-запросов к базам данных из программ, написанных на платформенно-независимом языке Java, позволяющем создавать как самостоятельные приложения, так и аплеты, встраиваемые в Webстраницы

25.Разработка пользовательского интерфейса. Стили пользовательского

интерфейса.

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

Singledocumentinterface (SDI) — способ организацииграфического

интерфейса приложений в отдельных окнах. Не существует «фонового» или «родительского» окна, содержащего меню или панели инструментов, по отношению к активному — каждое окно несѐт в себе эти элементы.

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

26.Принципы создания удобного пользовательского интерфейса. Основные факторы оценки удобства использования программы.

Факторы оценки удобства использования программАдекватность интерфейса – это его соответствие тем или иным задачам, которые

пользователи должны и хотели бы решать с его помощью.

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

Скорость обучения новых пользователей – количество задач к выполнению которых новый пользователь самостоятельно обучается за ед. времени

43

Эффективность предотвращения и преодоления ошибок пользователя – этот показатель тем лучше, чем реже пользователи ошибаются при работе с данным интерфейсом и чем меньше времени и усилий требуется для преодоления последствий уже сделанных ошибок

Субъективное удовлетворение пользователей

Специалисты по удобству формируют некоторый набор принципов и правил: -правило доступности -правило эффективности -пр. непрерывного развития -пр. поддержки -пр. соблюдения контекста

Принципы, позволяющие находить решения повышения удобства пользовательского интерфейса:

-принцип структуризации -пр. простоты -пр. видимости

-пр. обратной связи -пр. толерантности

-пр. повторного использования

27.Использование СУБД при проектировании информационных систем. Виды

СУБД.

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

Классификации СУБД По модели данных

Иерархические

Сетевые

Реляционные

Объектно-ориентированные

Объектно-реляционные По степени распределѐнности

Локальные СУБД (все части локальной СУБД размещаются на одном

компьютере)

Распределѐнные СУБД (части СУБД могут размещаться на двух и более компьютерах).

По способу доступа к БД

Файл-серверные (сервер-хранение; обработка данных происходит исключительно на стороне клиента)

В файл-серверных СУБД файлы данных располагаются централизованно на файлсервере. СУБД располагается на каждом клиентском компьютере (рабочей станции). Доступ СУБД к данным осуществляется через локальную сеть.

Примеры: Microsoft Access, Paradox, dBase, FoxPro, Visual FoxPro.

Клиент-серверные

Клиент-серверная СУБД располагается на сервере вместе с БД и осуществляет доступ к БД непосредственно, в монопольном режиме. Все клиентские запросы на обработку данных обрабатываются клиент-серверной СУБД централизованно. Недостаток клиент-серверных СУБД состоит в повышенных требованиях к серверу. Достоинства: потенциально более низкая загрузка локальной сети; удобство централизованного управления; удобство обеспечения таких важных характеристик как высокая надѐжность, высокая доступность и высокая безопасность.

Примеры: Oracle, Interbase, IBM DB2, Informix, MS SQL Server, MySQL,Caché, ЛИНТЕР.

Встраиваемые

Встраиваемая СУБД — СУБД, которая может поставляться как составная часть некоторого программного продукта, не требуя процедуры самостоятельной установки. Встраиваемая СУБД предназначена для локального хранения данных своего приложения и не рассчитана на коллективное использование в сети. Физически встраиваемая СУБД чаще всего

44

реализована в виде подключаемой библиотеки. Доступ к данным со стороны приложения может происходить через SQL либо через специальные программные интерфейсы.

Примеры: OpenEdge, SQLite, BerkeleyDB, Microsoft SQL Server Compact, ЛИНТЕР.

28. Манипулирование данными. SQL. Представление данных.

Оператор SQL SELECT,

предназначенногодлявыборкиданныхиимеетследующийсинтаксис:

SELECT [ ALL | DISTINCT ] select_item_commalist FROM table_reference_commalist

[ WHERE conditional_expression ]

[ GROUP BY column_name_commalist ] [ ORDER BY order_item_commalist ]

Если в операторе отсутствует раздел GROUP BY, то после этого происходит формирование результирующей таблицы запроса путем вычисления выражений, заданных в списке выборки оператора SELECT.

INSERT INTO exkur (nazv, span, IDSotr, price) VALUES ('$nazv', '$span', '$IDSotr', '$price') UPDATE zal SET Nazv='$Nazv',IDSotr ='$IDSotr',Ploshad='$Ploshad' WHERE

IDzala='$IDzala'

DELETE FROM sotrudnik WHERE id='$id'

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

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

29. Отчеты. Основные типы отчетов. Перекрестные запросы. Перекрестные таблицы и диаграммы. Многомерный куб.

Типы отчетов

Простой табличный отчет

Отчет "один-ко-многим"

отчет с вычисл.значен.

Отчет (report) — это объект базы данных, который используется для вывода на экран, в печать или файл структурированной информации. Reports позволяют извлечь из таблиц или запросов базы данных необходимую информацию и представить ее в виде удобном для восприятия.

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

Например, в таблице «Сотрудники» имеются сведения о зарплате каждого сотрудника, а также признаки, на какой кафедре и в какой должности работает каждый сотрудник. Требуется для каждой кафедры определить общий фонд зарплаты, а по каждой должности - среднюю по каждой кафедре зарплату.

При создании перекрестного запроса в качестве источника данных можно задать только одну таблицу (рис. 6.29). Если для реализации запроса требуются поля из разных таблиц, то надо предварительно создать вспомогательный запрос, который будет включать все требуемые поля. Так, если в создаваемом нами запросе требуется выводить название кафедры, то следует создать запрос, базирующийся на таблицах «Кафедра» и «Сотрудник», и этот запрос выбрать в качестве источника для создаваемого перекрестного запроса. Будем выводить в ответ «Код_кафедры» и поэтому выберем таблицу «Сотрудник».

45

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

Перекрестная таблица имеет преимущество перед электронной таблицей. Visual FoxPro автоматически разбивает данные на группы в соответствии с одним или несколькими факторами и выполняет групповые вычисления над данными, включенными в одну группу. После чего информация, полученная в результате групповых вычислений, сортируется и заносится в перекрестную таблицу.

Для создания простейших одномерных перекрестных таблиц можно использовать обычный итоговый запрос. Для построения двумерных и более сложных перекрестных таблиц в Visual FoxPro используется мастер создания перекрестных таблиц (Cross-Tab Wizard). С помощью этих средств можно не только просматривать и печатать построенную таблицу, но и сохранять ее в виде электронной таблицы.

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

OLAP-куб — многомерный массив данных, как правило, разреженный и долговременно хранимый. Может быть реализован на основе универсальных реляционных СУБД или специализированным программным обеспечением

OLAP (on-line analytical processing) — набор технологий для оперативной обработки информации, включающих динамическое построение отчѐтов в различных разрезах, анализ данных, мониторинг и прогнозирование ключевых показателей бизнеса. В основе OLAPтехнологий лежит представление информации в виде OLAP-кубов.

OLAP-кубы содержат бизнес-показатели, используемые для анализа и принятия управленческих решений, например: прибыль, рентабельность продукции, совокупные средства (активы), собственные средства, заемные средства и т.д.

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

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

Из OLAP-куба может быть составлен обычный плоский отчѐт. По столбикам и строчкам отчѐта будут бизнес-категории (грани куба), а в ячейках показатели.

46

30.Структурное тестирование программного обеспечения.

Структурное тестирование – тестирование основыванное на знании исходного кода (по принципу «белого ящика»)Тестирование — процесс выполнения программы с целью обнаружения ошибок. Шаги процесса задаются тестами.

Каждый тест определяет:

свой набор исходных данных и условий для запуска программы;

набор ожидаемых результатов работы программы.

Другое название теста — тестовый вариант. Полную проверку программы гарантирует исчерпывающее тестирование. Оно требует проверить все наборы исходных

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

Хорошим считают тестовый вариант с высокой вероятностью обнаружения еще не раскрытой ошибки. Успешным называют тест, который обнаруживает до сих пор не раскрытую ошибку.

Целью проектирования тестовых вариантов является систематическое обнаружение различных классов ошибок при минимальных затратах времени и стоимости.

Важен ответ на вопрос: что может тестирование?

Тестирование обеспечивает:

обнаружение ошибок;

демонстрацию соответствия функций программы ее назначению;

демонстрацию реализации требований к характеристикам программы;

отображение надежности как индикатора качества программы.

Ачего не может тестирование? Тестирование не может показать отсутствия дефектов (оно может показывать только присутствие дефектов). Важно помнить это (скорее печальное) утверждение при проведении тестирования.

Рассмотрим информационные потоки процесса тестирования. Они показаны на рис. 6.1.

Рис. 6.1. Информационные потоки процесса тестирования

На входе процесса тестирования три потока:

текст программы;

исходные данные для запуска программы;

ожидаемые результаты.

Выполняются тесты, все полученные результаты оцениваются. Это значит, что реальные результаты тестов сравниваются с ожидаемыми результатами. Когда обнаруживается

47

несовпадение, фиксируется ошибка — начинается отладка. Процесс отладки непредсказуем по времени. На поиск места дефекта и исправление может потребоваться час, день, месяц. Неопределенность в отладке приводит к большим трудностям в планировании действий.

После сбора и оценивания результатов тестирования начинается отображение качества и надежности ПО. Если регулярно встречаются серьезные ошибки, требующие проектных изменений, то качество и надежность ПО подозрительны, констатируется необходимость усиления тестирования. С другой стороны, если функции ПО реализованы правильно, а обнаруженные ошибки легко исправляются, может быть сделан один из двух выводов:

качество и надежность ПО удовлетворительны;

тесты не способны обнаруживать серьезные ошибки.

Вконечном счете, если тесты не обнаруживают ошибок, появляется сомнение в том, что тестовые варианты достаточно продуманы и что в ПО нет скрытых ошибок. Такие ошибки будут, в конечном итоге, обнаруживаться пользователями и корректироваться разработчиком на этапе сопровождения (когда стоимость исправления возрастает в 60-100 раз по сравнению с этапом разработки).

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

Существуют 2 принципа тестирования программы:

функциональное тестирование (тестирование «черного ящика»);

структурное тестирование (тестирование «белого ящика»).

Тестирование «черного ящика»

Известны: функции программы.

Исследуется: работа каждой функции на всей области определения.

Как показано на рис. 6.2, основное место приложения тестов «черного ящика» — интерфейс ПО.

Рис. 6.2. Тестирование «черного ящика»

Эти тесты демонстрируют:

как выполняются функции программ;

как принимаются исходные данные;

как вырабатываются результаты;

как сохраняется целостность внешней информации.

При тестировании «черного ящика» рассматриваются системные характеристики программ, игнорируется их внутренняя логическая структура. Исчерпывающее тестирование, как правило, невозможно. Например, если в программе 10 входных величин и каждая принимает по 10 значений, то потребуется 1010 тестовых вариантов. Отметим также, что тестирование «черного

48

ящика» не реагирует на многие особенности программных ошибок.

Тестирование «белого ящика»

Известна: внутренняя структура программы.

Исследуются: внутренние элементы программы и связи между ними (рис. 6.3).

Рис. 6.3. Тестирование «белого ящика»

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

Особенности тестирования «белого ящика»

Обычно тестирование «белого ящика» основано на анализе управляющей структуры программы [2], [13]. Программа считается полностью проверенной, если проведено исчерпывающее тестирование маршрутов (путей) ее графа управления.

Вэтом случае формируются тестовые варианты, в которых:

гарантируется проверка всех независимых маршрутов программы;

проходятся ветви True, False для всех логических решений;

выполняются все циклы (в пределах их границ и диапазонов);

анализируется правильность внутренних структур данных.

Недостатки тестирования «белого ящика»:

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

.

При п = 5 и k = 20 количество маршрутов т = 1014. Примем, что на разработку, выполнение и оценку теста по одному маршруту расходуется 1 мс. Тогда при работе 24 часа в сутки 365 дней в году на тестирование уйдет 3170 лет.

2.Исчерпывающее тестирование маршрутов не гарантирует соответствия программы исходным требованиям к ней.

3.В программе могут быть пропущены некоторые маршруты.

4.Нельзя обнаружить ошибки, появление которых зависит от обрабатываемых данных (это ошибки, обусловленные выражениями типа if abs (a-b) < eps..., if(a+b+c)/3=a...).

49

Достоинства тестирования «белого ящика» связаны с тем, что принцип «белого ящика» позволяет учесть особенности программных ошибок:

1.Количество ошибок минимально в «центре» и максимально на «периферии» программы.

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

3.При записи алгоритма ПО в виде текста на языке программирования возможно внесение типовых ошибок трансляции (синтаксических и семантических).

4.Некоторые результаты в программе зависят не от исходных данных, а от внутренних состояний программы.

Каждая из этих причин является аргументом для проведения тестирования по принципу «белого ящика». Тесты «черного ящика» не смогут реагировать на ошибки таких типов.

31.Системное тестирование.

Систе́мноетести́рованиепрогра́ммногообеспече́ния — это тестирование программного обеспечения (ПО), выполняемое на полной, интегрированной системе, с целью проверки соответствия системы исходным требованиям. Системное тестирование относится к методам тестирования чѐрного ящика, и, тем самым, не требует знаний о внутреннем устройстве системы.

Типы системных тестов

Функциональное тестирование

Тестирование пользовательского интерфейса

Юзабилити-тестирование

Тестирование совместимости

Тестирование безопасности

Автоматическое тестирование

32. Оптимизация приложений.

Оптимизация скорости работы приложения Основной способ оптимизации скорости работы — это оптимизация кода приложения.

При этом желательно прислушаться к рекомендациям разработчиков VisualBasic 6.

Избегайте переменных типа variant и присваивайте соответствующие их применению типы. При использовании в выражениях переменных типа Variant теряется время на их приведение к конкретному типу в соответствии с типом выражения.

Используйте для арифметических вычислений переменные типа Long или Integer, поскольку они, в отличие от currency, single или Double, более всего соответствуют машинному коду.

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

Оптимизация размера приложения Для оптимизации размера кода подойдут такие основные рекомендации:

уменьшайте в формах, насколько это возможно, количество элементов

управления.

для вывода тестовых значений максимально используйте объекты Label

вместо TextBox;

для хранения данных используйте файл ресурсов и загружайте данные только при необходимости;

избегайте переменных типа variant, требующих 16 байт для хранения. Для сравнения переменные типа integer требуют 2 байта, переменные типа Double — 8 байт;

50

избегайте "мертвого" кода — то есть процедур и переменных, которые когда-то требовались, но в настоящее время не используются. Их надо удалить или закомментировать.

Оптимизация размера графики приложения Графика занимает существенный размер приложения, поэтому важно использовать ее

оптимально. Для этого подходят такие рекомендации:

загружайте изображения только при необходимости, а не храните их в элементах

управления;

33.Распространение разработанных приложений. Мастера упаковки. Мастера развертывания.

Приложения AIR распространяются в виде единого установочного файла AIR, содержащего код и все файлы приложения. Этот файл может распространяться любыми привычными средствами: загружаться, отправляться по электронной почте, записываться на компакт-диск. Для установки пользователю нужно дважды щелкнуть по файлу AIR. Можно использовать функцию непрерывной установки, которая позволяет установить приложение AIR (и, если требуется, Adobe® AIR™) всего одним нажатием ссылки на веб-странице.

Перед распространением установочный файл AIR необходимо запаковать и снабдить сертификатом подписи кода и закрытым ключом. Цифровая подпись гарантирует, что после подписания приложение не модифицировалось. Кроме того, если цифровой сертификат выписан известным сертифицирующим органом, то доверие пользователей к вам как к издателю будет выше. Файл AIR подписывается при создании пакета приложения с помощью инструмента AIR Developer Tool (ADT).

Информацию о том, как создать файл-пакет для приложения AIR с помощью обновления AIR для Flash, см. в разделе Создание файлов приложения и программы установки AIR.

Информацию о том, как создать файл-пакет для приложения AIR с помощью комплекта Adobe® AIR™ SDK, см. в разделе Упаковка установочных файлов AIR с помощью средства

ADT.

34.Унифицированный язык моделирования. Предметы в UML.

ВUML имеются четыре разновидности предметов:

структурные предметы;

предметы поведения;

группирующие предметы;

поясняющие предметы.

Эти предметы являются базовыми объектно-ориентированными строительными блоками. Они используются для написания моделей.

Структурные предметы являются существительными в UML-моделях. Они представляют статические части модели — понятийные или физические элементы.

1.Класс — описание множества объектов, которые разделяют одинаковые свойства, операции, отношения и семантику (смысл). Класс реализует один или несколько интерфейсов

2.Интерфейс — набор операций, которые определяют услуги класса или компонента. Интерфейс описывает поведение элемента, видимое извне.

3.Кооперация (сотрудничество) определяет взаимодействие и является совокупностью ролей и других элементов, которые работают вместе для обеспечения коллективного поведения более сложного, чем простая сумма всех элементов.

4.Актер — набор согласованных ролей, которые могут играть пользователи при взаимодействии с системой (ее элементами UseCase).

5.Элемент Use Case (Прецедент) — описание последовательности действий (или нескольких последовательностей), выполняемых системой в интересах отдельного актера и производящих видимый для актера результат.

6.Активный класс — класс, чьи объекты имеют один или несколько процессов (или потоков) и поэтому могут инициировать управляющую деятельность.

7.Компонент — физическая и заменяемая часть системы, которая соответствует набору интерфейсов и обеспечивает реализацию этого набора интерфейсов.

8.Узел — физический элемент, который существует в период работы системы и представляет ресурс, обычно имеющий память и возможности обработки. В узле размещается набор компонентов, который может перемещаться от узла к узлу.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]