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

ОТВЕТЫ_ПО_ПИ

.docx
Скачиваний:
10
Добавлен:
16.03.2015
Размер:
3.09 Mб
Скачать

№1

В конце 60-х – начале 70-х годов прошлого века произошло событие, которое вошло в историю как первый кризис программирования. Событие состояло в том, что стоимость программного обеспечения стала приближаться к стоимости аппаратуры («железа»), а динамика роста этих стоимостей позволяла прогнозировать, что к середине 90-годов все человечество будет заниматься разработкой программ для компьютеров. Тогда и заговорили о программной инженерии (или технологии программирования, как это называлось в России) как о некоторой дисциплине, целью которой является сокращение стоимости программ.

№2

(программная инженерия) - впервые был озвучен в октябре 1968 года на конференции подкомитета НАТО по науке и технике.

Рассматривались проблемы проектирования, разработки, распространения и поддержки программ.

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

Все виды деятельности, выполняемые в процессе промышленного программирования и необходимые для успешного выполнения заказов называют программной инженерией (software engineering)

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

Установление и использование правильных инженерных принципов (методов) для экономичного получения надежного и работающего на реальных машинах программного обеспечения [Bauer 1972].

 Программная инженерия является такой формой инженерии, которая применяет принципы информатики (computer science) и математики для получения рентабельных решений в области программного обеспечения [CMU/SEI-90-TR-003].

 Наука о принципах и методологиях, применяемых при разработке и сопровождении программных систем. Она изучает применение систематического, упорядоченного и исчисляемого подхода к разработке, эксплуатации и сопровождению программного обеспечения (ПО), применение принципов инженерии по отношению к процессу разработки ПО [IEEE Std 610.12-1990]

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

№3

Этапы развития программной инженерии:

Повторное использование кода (модульное программирование)

Рост сложности программ (структурное программирование)

Модификация программ (ООП)

№4

Жизненный цикл – непрерывный процесс, начинающийся с момента принятия решения о создании ПО и заканчивающийся снятием его с эксплуатации. Жизненный цикл разбивается на отдельные процессы. Программный процесс — это набор действий и связанных с ними результатов, приводящих к созданию программного продукта. Основными процессами (иногда называют этапами или фазами) жизненного цикла являются: Разработка спецификации требований (результат – описания требований к программе, которые обязательны для выполнения – описание того, что программа должна делать); Разработка проекта программы (результат – описание того, как программа будет работать); Кодирование (результат – исходный код и файлы конфигурации); Тестирование программы (результат - контроль соответствия программы требованиям); Документирование (результат – документация к программе).

№5

Модель программного процесса - это упрощенное описание программного процесса, представленное с некоторой точки зрения. Модель задается в виде практических этапов, необходимых для создания ПО. Фаза (phase) – это определенный этап процесса, имеющий начало, конец и выходной результат. Например, фаза проверки осуществимости проекта, сдачи проекта и т.д. Фазы следуют друг за другом в линейном порядке, характеризуются предоставлением отчетности заказчику и, часто, выплатой денег за выполненную часть работы. Вид деятельности (activity) - это определенный тип работы, выполняемый в процессе разработки ПО. Разные виды деятельности часто требуют разные профессиональные навыки и выполняются разными специалистами. (менеджер управляет, программист кодирует и пр)

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

Спиральная (циклическая) модель

Отличительной особенностью этой модели является специальное внимание рискам, влияющим на организацию жизненного цикла

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

№6

№7

Артефакты - это некоторые продукты проекта, порождаемые или используемые в нем при работе над окончательным продуктом (файлы, документы, шаблоны, коды …

№8

Метод программной инженерии — это структурный подход к созданию ПО, который способствует производству высококачественного продукта эффективным в экономическом аспекте способом. #: Метод структурного анализа и проектирования Том ДеМарко - В структурном анализе и проектировании используются различные модели, описывающие: o функциональную структуру системы; определяется как иерархия диаграмм потоков данных, описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи потребителю. Метод объектно-ориентированного анализа - это методология-, при которой требования к системе воспринимаются с точки зрения классов и объектов, выявленных в предметной области. Границы между стадиями анализа и проектирования размыты, но решаемые ими задачи определяются достаточно четко. В процессе анализа мы моделируем проблему, обнаруживая классы и объекты, которые составляют словарь проблемной области. При объектно-ориентированном проектировании мы изобретаем абстракции и механизмы, обеспечивающие поведение, требуемое моделью. Метод сущность-связь проектирования информационных систем –

№9

DFD — общепринятое сокращение от англ. Data Flow Diagrams — диаграммы потоков данных. Так называется методология графического структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных, к которым осуществляется доступ. Диаграмма потоков данных (data flow diagram, DFD) — один из основных инструментов структурного анализа и проектирования информационных систем, существовавших до широкого распространения UML. Несмотря на имеющее место в современных условиях смещение акцентов от структурного к объектно-ориентированному подходу к анализу и проектированию систем, «старинные» структурные нотации по-прежнему широко и эффективно используются как в бизнес-анализе, так и в анализе информационных систем.

IDEF0 — Function Modeling — методология функционального моделирования и графическая нотация, предназначенная для формализации и описания бизнес-процессов. Отличительной особенностью IDEF0 является её акцент на соподчинённость объектов. В IDEF0 рассматриваются логические отношения между работами, а не их временна́я последовательность (WorkFlow).

UML (англ. Unified Modeling Language — унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения. UML является языком широкого профиля, это — открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML-моделью. UML был создан для определения, визуализации, проектирования и документирования, в основном, программных систем.

№10

Диаграммы вариантов использования (Use Case) - описывает функциональное назначение системы или, другими словами, то, что система будет делать в процессе своего функционирования. Актером (actor) или действующим лицом называется любая сущность, взаимодействующая с системой извне. В свою очередь, вариант использования (use case) служит для описания сервисов, которые система предоставляет актеру. Диаграмма вариантов использования представляет собой граф специального вида, который является графической нотацией для представления конкретных вариантов использования, актеров, возможно некоторых интерфейсов, и отношений между этими элементами.

№11

На Бизнес Диаграмме ВИ (БДВИ) отображается, как взаимодействуют внешние пользователи с вашей организацией для достижения бизнес целей. На ней обычно показывают внешних по отношению к вашей организации актеров, например, клиентов и  внешние организации. Данная диаграмма используется на этапе Бизнес Моделирования. Очень важно на этом этапе показать диаграмму Бизнес Объектов, которая отображает основные бизнес-сущности (и их свойства) и взаимосвязи между ними.

На Системной Диаграмме ВИ (СВИ) отображается, как взаимодействуют ваши внутренние Пользователи с вашей автоматизированной Системой, т.е. отображаются пользовательские функциональные требования к ПО. Данная диаграмма используется на этапе Системного Анализа и формализации требований к ПО.

№12

Диаграмма деятельности— UML-диаграмма, на которой показано разложение некоторой деятельности на её составные части. Под деятельностью (англ. activity) понимается спецификация исполняемого поведения в виде координированного последовательного и параллельного выполнения подчинённых элементов — вложенных видов деятельности и отдельных действий англ. action, соединённых между собой потоками, которые идут от выходов одного узла ко входам другого. Диаграммы деятельности используются при моделировании бизнес-процессов, технологических процессов, последовательных и параллельных вычислений.

№13

ER-диаграммы в нотации Баркера - Согласно этой модели, любой фрагмент предметной области может быть представлен как множество сущностей, между которыми существует некоторое множество связей. Сущность (entity) - это класс однотипных объектов, информация о которых должна быть учтена в модели. Экземпляр сущности - это конкретный представитель данной сущности. Атрибут сущности - это именованная характеристика, являющаяся некоторым свойством сущности. Ключ сущности - это неизбыточный набор атрибутов, значения которых в совокупности являются уникальными для каждого экземпляра сущности. Связь - это некоторая ассоциация между двумя сущностями.

№14

№15

№16

№17

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

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

Точка зрения (viewpoint) — это определенный взгляд на систему, который осуществляется для выполнения какой-то определенной задачи кем-либо из участников проекта. Важнейшими характеристиками точки зрения моделирования является цель (зачем создается модель) и целевая аудитория (то есть, для кого она предназначается).

№18

Требования можно разделить на 2 группы – функциональные и нефункциональные.

Функциональные требования являются детальным описанием поведения и сервисов системы, ее функционала. Они определяют то, что система должна уметь делать.

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

Свойства требований: Ясность, недвусмысленность — однозначность понимания требований заказчиком и разработчиками; Полнота и непротиворечивость; Необходимый уровень детализации. Требования должны обладать ясно осознаваемым уровнем детализации, стилем описания, способом формализации; Прослеживаемость — важно видеть то или иное требование в различных моделях, документах, наконец, в коде системы; Тестируемость и проверяемость — необходимо, чтобы существовали способы тестировать и проверить данное требование; Модифицируемость. Определяет процедуры внесения изменений в требования.

№19

Варианты формализации требований:

Неформальная постановка требований в переписке по электронной почте.

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

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

Требования в виде графа с зависимостями в одном из средств поддержки требований (IBM Rational RequisitePro, и др.). Такое представление удобно при частом изменении требований, при отслеживании выполнения требований, при организации «привязки» к требованиям задач, людей, тестов, кода.

Формальная модель требований для верификации, модельно-ориентированного тестирования и т.д.

№20

Выделение требований (requirements elicitation), нацеленное на выявление всех возможных источников требований и ограничений на работу системы и извлечение требований из этих источников.

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

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

Валидация требований (requirements validation), которая решает задачу оценки понятности сформулированных требований и их характеристик, необходимых, чтобы разрабатывать ПО на их основе, в первую очередь, непротиворечивости и полноты, а также соответствия корпоративным стандартам на техническую документацию.

№21

Язык структурированных запросов SQL (Structured Query Language) — "родной" язык реляционных баз данных, поэтому программа Access не может его не понимать. При работе с Access «используется диалект Jet SQL. Язык JetSQL используют для прямого взаимодействия с данными средствами механизма Jet. Все его инструкции можно формально разделить на две части: Язык управления данными (DML). Этот язык используется для извлечения, изменения и удаления существующих данных, а также для добавления новых данных. Язык определения данных (DDL). Этот язык используется для управлениями объектами в базе данных, в приложении мы не будем его рассматривать.

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

SELECT ALL|DISTINCT список_полей|* FROM источник_данных [WHERE условие]

[GROUP BY столбец1[,столбец2 ..]][HAVING условие]

[ORDER BY столбец1[ASC|DESC] [,столбец2..]

Если опустить компонент all | DISTINCT, SQL предполагает наличие первого из них. Аналогично, в предложении ORDER BY по умолчанию предполагается наличие ключевого слова ASC. Символ звездочки предполагает отбор всех полей в источнике данных. Аргумент список_полей представляет собой, как и следует из названия, список имен полей источника данных, разделенных запятыми: SELECT поле1 [AS псевдоним] [, поле2 [AS псевдоним]...] где поле1, поле2 и т.д. представляют имена полей. Полю, которое в источнике данных имело некоторое имя, можно в результатах запроса присвоить псевдоним. Предложение FROM является обязательным, и его полная форма имеет следующий вид:

FROM источник_данных | таблица_один СВЯЗЬ таблица_много ON таблица_один. первичный_ключ = таблица _много. вторичный_ключ

где таблица_один и таблица_много указывают на две таблицы, участвующие в отношении "один ко многим". Аргумент СВЯЗЬ идентифицирует тип связи между таблицами: INNER JOIN, LEFT или RIGHT. Предложение WHERE предназначено ограничивать объем извлекаемых, обновляемых или удаляемых данных.

Это предложение имеет следующий синтаксис: WHERE условное_выражение. В предложении WHERE можно комбинировать множество условий с помощью логических булевых операторов and, or и not. Предложение ORDER BY может осуществлять сортировку по текстовым и числовым данным, а также по датам. Синтаксис: ORDER BY столбец1 [ASC | DESC][, столбец2 [ASC | DESC]...]. Предложение GROUP BY определяет группы и иногда выполняет вычисление итогов по группе. Синтаксис : GROUP BY столбец1 [, столбец2...] где столбец1, столбец2 и т.д. являются ссылками на фактические столбцы или вычисляемые поля. Предложение HAVING ограничивает результаты группировки, произведенной предложением GROUP by. Механизм Jet применяет предложение having уже после группировки данных. Условие like использует символы макроподстановки для поиска строк, соответствующих заданному шаблону. Функция AVG

Эта функция применяется для вычисления средних значений.

Функция COUNT (Выражение / *)

Функция COUNT (*) предназначена для вычисления количества строк в результатах запроса. Для начала рассмотрим одну из наиболее широко применяемых разновидностей запроса.

UPDATE - Инструкция update языка SQL аналогична запросу обновления, выполняемому в интерфейсе пользователя Access для изменения существующих данных. Эта инструкция использует следующий синтаксис:

UPDATE источник_данных

SET столбец1 = выражение1[, столбец2 = выражение2...]

[WHERE условие]

Удаление записей с помощью инструкции DELETE

синтаксис :

DELETE

FROM источник_данных [WHERE условие]

INSERT данные из одной таблицы копируются в другую, или в некоторой таблице создается новая запись. синтаксис: INSERT INTO таблица_приемник SELECT таблица_источник. Для добавления записей (по одной) в таблицу используют следующий синтаксис:

INSERT INTO таблица [столбец1[, столбец2...]] VALUES [значение1[, значение2...] ]

Для успешного использования этой формы инструкции следует учесть следующие правила: Ссылки на столбцы не обязательны; когда они опущены, значения должны передаваться для всех полей таблицы по порядку. Значения в предложении values должны иметь тот же порядок, что и в списке полей таблицы инструкции INSERT INTO. Этот порядок может отличаться от заложенного в исходной конструкции таблицы.

№22

ADO.NET — технология, предоставляющая доступ к данным для приложений, основанных на Microsoft .NET. Является не развитием более ранней технологии ADO, а самостоятельной технологией, частью фреймворка .NET.

Microsoft ADO.NET (ActiveX Daia Objects) — объектная модель доступа к данным, набор средств, позволяющих приложению управлять и взаимодействовать со своим файловым или серверным хранилищем данных. Библиотеки ADO.NET включают классы, которые служат для подсоединения к источнику данных, выполнения запросов и обработки их результатов.

№23

Подсоединенные объекты - используются для управления соединением, транзакциями, для выборки данных и передачи изменений они взаимодействуют непосредственно с БД. Большинство подключенных объектов реализовано в рамках того, что называется поставщиками данных. ПОСТАВЩИКИ ДАННЫХ .NET - .NЕТ data provider - это набор классов, предназначенных для взаимодействия с хранилищем данных определенного типа. Архитектура .NET Framework включает в себя четыре поставщика: SQL Client .NET Data Provider, Oracle Client .NET Data Provider, ODBC .NET Data Provider OLE DB .NET Data Provider. Поставщики ODBC и OLE DB .NET являются связующими компонентами с действующими технологиями ODBC и OLE DB. С их помощью можно взаимодействовать с различными хранилищами данных посредством ODBC­драйверов и OLE DB­поставщиков соответственно.

№24

Отсоединенные объекты - Объекты, составляющие автономную часть модели ADO.NET, не взаимодействуют напрямую с подсоединенными объектами, для этого используется DataAdapter. Автономные объекты не должны знать о базе данных, поэтому они могут совместно использоваться различными базами. Автономные приложения ADO.NET подключаются к базе как можно позже и отключаются как можно раньше. При работе в автономном режиме ADO.NET ведет пул реальных физических подключений для различных запросов, таким образом многократно повышая свою производительность с помощью подобного пула подключений.

№25

Класс Connection - Применяется для соединения с БД и отсоединения от нее. С помощью свойств этого объекта можно задать тип источника, его расположение пр. Объект Connection выступает в качестве канала, по которому другие классы, например DataAdapter и Command, взаимодействуют с БД для передачи изменении и выборки их результатов. создать экземпляр класса Connection

Dim testConnection Аs New OleDblConnection

Задать строку подключения

Указать тип соединения

Соединение с использованием безопасности Windows

Integrated Security =True

Соединение с помощью безопасности ервера имени пользователя и пароля

Persist Security Info=True; UserID=<user name>; Password=<your password>

Строка подключения к Access

[oledb];

Provider=Microsoft.Jet.OLEDB.4.0;

Data Source=E:\МММ_access.mdb;

Persist Security Info=False

№26

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

№27

Файл конфигурации - это текстовый файл в формате XML, где хранятся настройки, используемые приложением в процессе работы. Для исполняемого файла - имя конфигурационного файла представляет собой имя исполняемого файла с расширением .config — например, myApplication.exe.config Он располагается в том же каталоге, что и исполняемый файл. Файлы конфигурации позволяют настраивать параметры приложения без перекомпиляции. Строки соединения в файлах конфигурации обычно хранятся в элементе <connectionStrings>. Элемент <configuration> - Корневой элемент в любом файле конфигурации, используемом средой CLR и приложениями .NET Framework.

<configuration> 

<!-- configuration settings --> 

</configuration>

Раздел connectionStrings - Строки соединения могут храниться в файлt конфигурации приложения в виде пар «ключ=значение» в разделе connectionStrings элемента configuration. Дочерние элементы : add, clear и remove.

№28

Класс Command - Могут осуществлять запрос к БД, вызов хранимой процедуры или прямой запрос на возврат содержимого конкретной таблицы. Команда может возвратить или нет какой-либо результат (в зависимости от этого выполнение объекта Command запускается различными методами). КАК СОЗДАТЬ ОБЪЕКТ Command: ИмяОбъектаСОММАND= New OleDbCommand(SQLзапрос,ИмяПодключения)

№29

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

№30

Класс Parameter - Используется для создания параметризованного объекта Command. Для использования параметров создайте классы Parameter, соответствующие всем параметрам запроса, и добавьте их в класс Parameters объекта Command. Класс Parameter ADO.NET предоставляет свойства и методы, позволяющие определить тип данных и значение параметров.

№31

Класс DataSet - содержит набор данных. Данные в нем отсоединены от БД. Все изменения данных кэшируются в объектах DataRow. Кроме того, класс DataSet предоставляет функции чтения и записи в файл и область памяти. Можно сохранить только содержимое объекта DataSet, только его структуру или и то и другое. ADO.NET хранит эти данные в виде XML-документа.

Класс DataTable - похож на таблицу базы данных. Он состоит из объектов DataColumn, DataRow и различных налагаемых па них ограничений. Он хранит данные в формате строк и столбцов. При автономной работе с данными живое соединение с БД не понадобится, однако вы не увидите изменений, внесенных другими пользователями после выполнения вами исходного запроса.

Класс DataRow - Объект DataTable предоставляет через набор Rows содержимое всех записей данных. Когда вы изменяете содержимое записи, DataRow кэширует эти изменения, чтобы позже передать их в БД. При изменении значения поля записи объект DataRow хранит оригинальное и текущее значения поля, что обеспечивает успешное обновление содержимого БД.

№32

Существует 2 метода для поиска данных по заданному критерию: Метод Find —позволяет искать записи по значениям первичного ключа. Аргумент метода Find - значение первичного ключа искомой записи. Результат выполнения метода Find - не более одного объекта Data Row. Метод Select — играет роль фильтра,

Аргумент метода = строковое выражение, записанное по правилам Where запроса Select.

Результат - строки данных DataRow. Полный синтаксис метода –

DataTable.Select(ВыражениеФильтр,СтолбецСортировки,ВыражениеФильтраСостоянияСтроки)

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