1) Программная инженерия. Особенности современных информационных систем

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

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

ОСНОВНЫЕ ОСОБЕННОСТИ СОВРЕМЕННЫХ ИС :

Первоначально дадим определение основным терминам, связанным с данной проблемой.

Прежде всего, определим дефиницию “система”. Ряд специалистов утверждает, что невозможно дать однозначного определения системе. Большинство из них полагают, что нет методик синтеза и анализа систем, которые можно было бы применить в любой области деятельности. В то же время, представляется возможным определить основные признаки системы:

1. Целостной структурой с интегративными свойствами,
2. Возможностью деления системы на элементы с формированием устойчивых связей между ними,
3. Наличием цели или функциональной направленности,
4. Иерархичностью структуры и возможностью развития системы.

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

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

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

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

Системный подход тесно связан с компонентами структуры системы, поэтому его пророй называют структурным подходом (см. п. 4.1).

В данной дисциплине рассматривается разновидность систем – информационные системы.

Информационная система (по законодательству РФ) – организационно упорядоченная совокупность документов (массивов документов) и информационных технологий, в том числе с использованием средств вычислительной техники и связи, реализующих информационные процессы.

Информационные системы предназначены для хранения, обработки, поиска, распространения, передачи и предоставления информации.

Технологии, предназначенные для решения информационных задач с помощью различных методов и программно-технических средств, называют информационными.

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

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

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

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

Считается, что существует три основных подхода к построению БД: иерархический, сетевой и реляционный.

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

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

В реляционной модели одинаково представлены элементы данных и их связи. Широко распространенной реляционной СУБД является программа Access, созданная фирмой Microsoft и входящая в состав интегрированного программного обеспечения Microsoft Office.

2. Основные системы стандартов, регламентирующие разработку информационных систем и ПО.

Международные организации по стандартизации:

 Международная организация стандартизации (ISO)

Международная организация ISO начала функционировать 23 февраля 1947 г. как добровольная, неправительственная организация. Она была учреждена на основе достигнутого на совещании в Лондоне в 1946 г. соглашения между представителями 25-ти индустриально развитых стран о создании организации, обладающей полномочиями координировать на международном уровне разработку различных промышленных стандартов и осуществлять процедуру принятия их в качестве международных стандартов.

International Electrotechnical Commission (Международная электротехническая комиссия)

Организация IEC (МЭК), образованная в 1906 г., является добровольной неправительственной организацией. Ее деятельность в основном связана со стандартизацией физических характеристик электротехнического и электронного оборудования. Основное внимание IEC уделяет таким вопросам, как, например, электроизмерения, тестирование, утилизация, безопасность электротехнического и электронного оборудования. Членами IEC являются национальные организации (комитеты) стандартизации технологий в соответствующих отраслях, представляющие интересы своих стран в деле международной стандартизации

Язык оригинала стандартов МЭК - английский.

International Telecommunication Union (Международный Союз Электросвязи)

ITU — международная межправительственная организация в области стандартизации электросвязи. Организация объединяет более 500 правительственных и неправительственных организаций. В ее состав входят телефонные, телекоммуникационные и почтовые министерства, ведомства и агентства разных стран, а также организации-поставщики оборудования для обеспечения телекоммуникационного сервиса. Основная задача ITU состоит в координации разработки гармонизированных на международном уровне правил и рекомендаций, предназначенных для построения и использования глобальных телесетей и их сервисов. В 1947 г. ITU получила статус специализированного агентства Организации Объединенных Наций (ООН).

IEEE (Institute of Electrical and Electronic Engineers, Институт инженеров по электротехнике и электронике) — профессиональная международная организация.

ANSI (American National Standards Institute) — американский институт национальных стандартов. Организация, определяющая государственные стандарты в США в различных сферах деятельности, включая фотопродукцию, автомобилестроение, кораблестроительную, авиационную и другие виды промышленности, а также компьютерные технологии.

ГОСТ 34.601-90

3. Понятие жизненного цикла ПО

Жизненный цикл программного обеспечения (ПО) — период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации[1]. Этот цикл — процесс построения и развития ПО.

4. Процессы жизненного цикла ПО. Общая характеристика

Основные:

Приобретение (действия и задачи заказчика, приобретающего ПО)

Поставка (действия и задачи поставщика, который снабжает заказчика программным продуктом или услугой)

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

Эксплуатация (действия и задачи оператора — организации, эксплуатирующей систему)

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

Вспомогательные

Документирование (формализованное описание информации, созданной в течение ЖЦ ПО)

Управление конфигурацией (применение административных и технических процедур на всем протяжении ЖЦ ПО для определения состояния компонентов ПО, управления его модификациями).

Обеспечение качества (обеспечение гарантий того, что ИС и процессы ее ЖЦ соответствуют заданным требованиям и утвержденным планам)

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

Аттестация (определение полноты соответствия заданных требований и созданной системы их конкретному функциональному назначению)

Совместная оценка (оценка состояния работ по проекту: контроль планирования и управления ресурсами, персоналом, аппаратурой, инструментальными средствами)

Аудит (определение соответствия требованиям, планам и условиям договора)

Разрешение проблем (анализ и решение проблем, независимо от их происхождения или источника, которые обнаружены в ходе разработки, эксплуатации, сопровождения или других процессов)

Организационные

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

Создание инфраструктуры (выбор и сопровождение технологии, стандартов и инструментальных средств, выбор и установка аппаратных и программных средств, используемых для разработки, эксплуатации или сопровождения ПО)

Усовершенствование (оценка, измерение, контроль и усовершенствование процессов ЖЦ)

Обучение (первоначальное обучение и последующее постоянное повышение квалификации персонала)

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

Инициирование приобретения

Подготовка заявочных предложений

Подготовка и корректировка договора

Надзор за деятельностью поставщика

Приемка и завершение работ

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

Формирование требований к системе

Формирование списка программных продуктов

Установление условий и соглашений

Описание технических ограничений (среда функционирования системы и т. д.)

5-9) Основные процессы жизненного цикла

Приобретение (5)
Процесс приобретения (как его называют в ГОСТ – “заказа”) определяет работы и задачи заказчика, приобретающего программное обеспечение или услуги, связанные с ПО, на основе контрактных отношений. Процесс приобретения состоит из следующих работ (названия ГОСТ 12207 даны в скобках, если предлагают другой перевод названий работ оригинального стандарта):

Inititation – инициирование (подготовка)

Request-for-proposal preparation – подготовка запроса на предложение (подготовка заявки на подряд)

Contract preparation and update –подготовка и корректировка договора

Supplier monitoring – мониторинг поставщика (надзор за поставщиком)

Acceptance and completion – приемка и завершение (приемка и закрытие договора)

Все работы проводятся в рамках проектного подхода.

Поставка (6)
Процесс поставки, в свою очередь, определяет работы и задачи поставщика. Работы также проводятся с использованием проектного подхода. Процесс включает следующие работы:

Inititation – инициирование (подготовка)

Preparation of response – подготовка предложения (подготовка ответа)

Contract – разработка контракта (подготовка договора)

Planning - планирование

Execution and control – выполнение и контроль

Review and evaluation –проверка и оценка

Delivery and completion – поставка и завершение (поставка и закрытие договора)

Разработка (7)
Процесс разработки определяет работы и задачи разработчика. Процесс состоит из следующих работ:

Process implementation – определение процесса (подготовка процесса)

System requirements analysis – анализ системных требований (анализ требований к системе)

System design – проектирование системы (проектирование системной архитектуры)

Software requirements analysis – анализ программных требований (анализ требований к программным средствам)

Software architectural design – проектирование программной архитектуры

Software detailed design – детальное проектирование программной системы (техническое проектирование программных средств)

Software coding and testing – кодирование и тестирование (программирование и тестирование программных средств)

Software integration – интеграция программной системы (сборка программных средств)

Software qualification testing – квалификационные испытания программных средств

System integration – интеграция системы в целом (сборка системы)

System qualification testing – квалификационные испытания системы

Software installation – установка (ввод в действие)

Software acceptance support – обеспечение приемки программных средств

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

Эксплуатация (8)
Процесс разработки определяет работы и задачи оператора службы поддержки. Процесс включает следующие работы:

Process implementation – определение процесса (подготовка процесса)

Operational testing – операционное тестирование (эксплуатационные испытания)

System operation – эксплуатация системы

User support – поддержка пользователя

Сопровождение (9)
Процесс разработки определяет работы и задачи, проводимые специалистами службы сопровождения. Процесс включает следующие работы:

Process implementation – определение процесса (подготовка процесса)

Problem and modification analysis – анализ проблем и изменений

Modification implementation – внесение изменений

Maintenance review/acceptance – проверка и приемка при сопровождении

Migration – миграция (перенос)

Software retirement – вывод программной системы из эксплуатации (снятие с эксплуатации)

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

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

 

Процесс документирования предусматривает формализованное описание информации, созданной в течение ЖЦ ПО

подготовительная работа

проектирование и разработка

выпуск документации

сопровождение

Процесс управления конфигурацией предполагает применение административных и технических процедур на всём протяжении ЖЦ ПО для определения состояния компонентов ПО в системе, управления модификациями ПО, описания и подготовки отчётов о состоянии компонентов ПО и запросов на их модификацию, обеспечения полноты и корректности компонентов ПО, управления хранением и поставкой ПО.

IEEE-90: конфигурация ПО – совокупность его функциональных и физических характеристик, установленных в технической документации и реализованных в ПО

подготовительная работа

планирование управления конфигурацией

идентификация конфигурации

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

контроль конфигурации

систематическая оценка предполагаемых модификаций ПО и координированной их реализации

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

учёт состояния конфигурации

регистрация состояния компонентов ПО

подготовка отчётов о всех реализованных и отвергнутых модификациях

оценка конфигурации

оценка функциональной полноты компонентов ПО

оценка соответствия физического их состояния текущему техническому описанию

управление выпуском и поставка

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

11. Вспомогательные процессы жизненного цикла ПО. Процесс обеспечения качества

Процесс обеспечения качества обеспечивает соответствующие гарантии того, что ПО и процессы его ЖЦ соответствуют заданным требованиям и утверждённым планам.

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

 подготовительная работа

координация с другими вспомогательными процессами

планирование процесса обеспечения качества

2) обеспечение качества продукта

гарантирование полного соответствия ПО и его документации требованиям заказчика, предусмотренным в договоре

3) обеспечение качества процесса

гарантирование соответствия процессов ЖЦ ПО, методов разработки, среды разработки и квалификации персонала условиям договора, установленным стандартам и процедурам

4) обеспечение прочих показателей качества системы

осуществляется в соответствии с условиями договор

12. Вспомогательные процессы жизненного цикла ПО. Процесс верификации

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

1) подготовительная работа

2) верификация, в процессе которой проверяются следующие условия

непротиворечивость требований к системе и степень учёта потребностей пользователя

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

соответствие выбранных процессов ЖЦ ПО условиям договора

адекватность стандартов, процедур и среды разработки процессам ЖЦ ПО

соответствие проектных спецификаций ПО заданным требованиям

корректность описания в проектных спецификациях входных и выходных данных, последовательности событий, интерфейсов, логики и т.д.

соответствие кода проектным спецификациям и требованиям

тестируемость и корректность кода, его соответствие принятым стандартам кодирования

корректность интеграции компонентов ПО в систему

адекватность, полнота и непротиворечивость документации

13. Вспомогательные процессы жизненного цикла ПО. Процесс аттестации

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

Аттестация -  подтверждение и оценка достоверности проведённого тестирования ПО.

 подготовительная работа

2) аттестация

 

14. Вспомогательные процессы жизненного цикла ПО. Процесс совместной оценки

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

 подготовительная работа

2) оценка управления проектом

3) техническая оценка

15. Вспомогательные процессы жизненного цикла ПО. Процессы аудита и разрешения проблем

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

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

 подготовительная работа

2) аудит

Процесс разрешения проблем – предусматривает анализ и решение проблем, которые обнаружены в ходе разработки, эксплуатации, сопровождения или других процессов.

Каждая проблема должна быть идентифицирована, описана, проанализирована и разрешена.

 подготовительная работа

2) разрешение проблем

16. Организационные процессы жизненного цикла ПО

Процесс управления

инициирование и определение области управления

убедиться, что необходимые для управления ресурсы (персонал, оборудование и технология) имеются в достаточном количестве

планирование

составление графика выполнения работ

оценка затрат

выделение требуемых ресурсов

распределение ответственности

оценка рисков, связанных с конкретными задачами

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

выполнение и контроль

проверка и оценка

завершение

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

подготовительная работа

создание инфраструктуры

сопровождение инфраструктуры

Процесс усовершенствования – оценка, измерение, контроль и усовершенствование процессов ЖЦ ПО

 создание процесса

 оценка процесса

 усовершенствование процесса

Процесс обучения – первоначальное обучение и повышение квалификации персонала

подготовительная работа

разработка учебных материалов

реализация плана обучения

17. Взаимосвязь между процессами жизненного цикла

18. Модели жизненного цикла. Их характеристики.

19. Модели проектирования – каскадная, поэтапная, спиральная. Их достоинства, недостатки и области применения.

20. Стадии жизненного цикла ПО. Взаимосвязь между стадиями и процессами жизненного цикла.

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

планирование разработки;

определение требований к системе;

2.1 выработка требований;

2.2 анализ требований;

проектирование системы;

3.1 проектирование архитектуры системы;

3.2 детальное проектирование компонент системы, в т.ч. для программного обеспечения;

3.2.1 общее проектирование программного обеспечения;

3.2.2 проектирование отдельных программных компонент;

реализация и тестирование системы;

4.1 создание отдельных компонент системы, в т.ч. для программного обеспечения;

4.1.1 создание отдельных программных модулей;

4.1.2 тестирование отдельных программных модулей;

4.2 тестирование компонент системы, в т.ч. программного обеспечения как единого компонента системы;

4.3 интегрирование отдельных компонент в систему;

выпуск системы;

эксплуатация системы;

завершение разработки.

Стадия — часть процесса создания ПО, ограниченная определенными временными рамками и заканчивающаяся выпуском конкретного продукта (моделей, программных компонентов, документации), определяемого заданными для данной стадии требованиями. На каждой стадии могут выполняться несколько процессов, определенных в стандарте ГОСТ Р ИСО/МЭК 12207-99, и наоборот, один и тот же процесс может выполняться на различных стадиях. Соотношение между процессами и стадиями также определяется используемой моделью жизненного цикла ПО.

21. Участники разработки: заказчик, пользователь, руководитель проекта, разработчик, поставщик

Заказчик — лицо (физическое или юридическое), заинтересованное в выполнении исполнителем какого-либо объема работ или приобретении у продавца какого-либо продукта, и оформляющее в связи с этим заказ.

Пользователь — лицо или организация, которое использует действующую систему для выполнения конкретной функции. В частности, Пользователь АС — лицо, участвующее в функционировании автоматизированной системы или использующее результаты её функционирования.

Менеджер проекта (руководитель проекта) — лицо, ответственное за управление проектом. Менеджер проекта несет ответственность за достижение целей проекта в рамках бюджета, в срок и с заданным уровнем качества. Руководитель проекта обеспечивает ежедневное управление проектом, командой проекта, в разрезе всех основных управленческих функций (управление по срокам, затратам, рискам и др.). В зависимости от размера проекта, менеджер проекта может получать поддержку со стороны администратора проекта, или команды поддержки (офиса проекта).

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

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

22. Сущность подхода RAD – быстрой разработки приложений

Технология RAD (Rapid Application Development – Быстрая разработка приложений). Эта технология ориентирована, как следует из названия, на максимально быстрое получение первых версий разрабатываемого программного обеспечения. Она предусматривает выполнение следующих условий:

• ведение разработки небольшими группами разработчиков (3-7 человек), каждая из которых проектирует и   реализует отдельные подсистемы проекта - позволяет улучшить управляемость проекта;

• использование итерационного подхода способствует уменьшению времени получения работоспособного прототипа;

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

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

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

Под функциональной точкой в технологии RAD понимают любой из следующих

функциональных элементов разрабатываемой системы:

• входной элемент приложения (входной документ или экранная форма);

• выходной элемент приложения (отчет, документ или экранная форма);

• запрос (пара «вопрос/ответ»);

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

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

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

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

Технология RAD хорошо зарекомендовала себя для относительно небольших проектов, разрабатываемых для конкретного заказчика. Такие системы не требуют высокого уровня планирования и жесткой дисциплины проектирования. Однако эта технология не применима для построения сложных расчетных программ, операционных систем или программ управления сложными объектами u1074 в реальном масштабе времени, т. е. программ с большим процентом уникального кода. Не годится она и в случае создания приложений, от которых зависит безопасность людей, например, систем управления самолетами или атомными электростанциями, так как технология RAD предполагает, что первые несколько версий не будут полностью работоспособны, что в данном случае полностью исключается.

23. Стандарты проектирования, оформления документации, интерфейса системы с пользователем.

Стандарт проектирования должен устанавливать:

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

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

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

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

Стандарт оформления проектной документации должен устанавливать:

комплектность, состав и структуру документации на каждой стадии проектирования;

требования к ее оформлению (включая требования к содержанию разделов, подразделов, пунктов, таблиц и т.д.),

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

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

требования к настройке CASE-средств для обеспечения подготовки документации в соответствии с установленными требованиями.

Стандарт интерфейса пользователя должен устанавливать:

правила оформления экранов (шрифты и цветовая палитра), состав и расположение окон и элементов управления;

правила использования клавиатуры и мыши;

правила оформления текстов помощи;

перечень стандартных сообщений;

правила обработки реакции пользователя.

24. Сущность структурного подхода к проектированию ПО

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

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

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

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

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

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

принцип формализации - заключается в необходимости строгого методического подхода к решению проблемы;

принцип непротиворечивости - заключается в обоснованности и согласованности элементов;

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

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

SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы (подраздел 2.2);

DFD (Data Flow Diagrams) диаграммы потоков данных (подраздел 2.3);

ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь" (подраздел 2.4).

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

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

25. Диаграммы потоков данных (DFD). Правила построения диаграмм

26. Диаграммы потоков данных (DFD). Построение иерархии диаграмм

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

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

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

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

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

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

правило нумерации - означает, что при детализации процессов должна поддерживаться их иерархическая нумерация. Например, процессы, детализирующие процесс с номером 12, получают номера 12.1, 12.2, 12.3 и т.д.

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

27. Структурный подход к программированию. Основные типы операторов.

28. Метод структурного анализа и проектирования (SADT)

SADT (акроним от англ. Structured Analysis and Design Technique) — методология структурного анализа и проектирования, интегрирующая процесс моделирования, управление конфигурацией проекта, использование дополнительных языковых средств и руководство проектом со своим графическим языком. Процесс моделирования может быть разделен на несколько этапов: опрос экспертов, создание диаграмм и моделей, распространение документации, оценка адекватности моделей и принятие их для дальнейшего использования. Этот процесс хорошо отлажен, потому что при разработке проекта специалисты выполняют конкретные обязанности, а библиотекарь обеспечивает своевременный обмен информацией.

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

Анализ — определение того, что система будет делать,

Проектирование — определение подсистем и их взаимодействие,

Реализация — разработка подсистем по отдельности, объединение — соединение подсистем в единое целое,

Тестирование — проверка работы системы,

Установка — введение системы в действие,

Эксплуатация — использование системы.

29. Диаграммы «сущность-связь» (ERD)

Модель Сущность-Связь (ER-модель) (англ. entity-relationship model (ERM) или англ. entity-relationship diagram (ERD)) — модель данных, позволяющая описывать концептуальные схемы. Предоставляет собой графическую нотацию, основанную на блоках и соединяющих их линиях, с помощью которых можно описывать объекты и отношения между ними какой-либо другой модели данных. В этом смысле ER-модель является мета-моделью данных, то есть средством описания моделей данных.

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

ER-модель является одной из самых простых визуальных моделей данных (графических нотаций). Она позволяет обозначить структуру «крупными мазками», в общих чертах. Это общее описание структуры называется ER-диаграммой или онтологией выбранной предметной области (area of interest).

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

Модель «сущность-связь» была предложена в 1976 году Питером Пин-Шен Ченом – американским профессором компьютерных наук в университете штата Луизиана. Фактически Чен не изобретал модель, он взял идеи из более ранних работ таких практиков, как А. Браун и других. Однако Питер Чен сделал больше, чем кто бы то ни было до него для формализации и популяризации ER-модели, а также для её внедрения в научную литературу.

Согласно данной нотации, сущность изображается в виде прямоугольника, содержащем её имя, выражаемое существительным. Имя сущности должно быть уникальным в рамках одной модели. При этом, имя сущности - это имя типа, а не конкретного экземпляра данного типа. Экземпляром сущности называется конкретный представитель данной сущности.

Связь изображается линией, которая связывает две сущности, участвующие в отношении. Степень конца связи указывается графически, множественность связи изображается в виде "вилки" на конце связи. Модальность связи так же изображается графически - необязательность связи помечается кружком на конце связи. Именование обычно выражается одним глаголом в изъявительном наклонении настоящего времени: «Имеет», «Принадлежит» и т. д.; или глаголом с поясняющими словами: «Включает_в_себя», и т.п. Наименование может быть одно для всей связи или два для каждого из концов связи. Во втором случае, название левого конца связи указывается над линией связи, а правого – под линией. Каждое из названий располагаются рядом с сущностью, к которой оно относится.

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

30. Метод Баркера проектирования структуры данных

31. Сущность объектно-ориентированного подхода к проектированию ПО

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

Принципиальное различие между структурным и объектно-ориентирован­ным подходом заключается в способе декомпозиции системы. Объектно-ориен­тированный подход использует объектную декомпозицию, при этом статиче­ская структура системы описывается в терминах объектов и связей между ними, а поведение системы описывается в терминах обме­на сообщениями ме­жду объектами. Каждый объект системы обладает своим собственным поведе­нием, моделирующим поведение объекта реального мира. Понятие "объект" впервые было использовано около 30 лет назад в технических средствах при попытках отойти от традиционной архи­тектуры фон Неймана и преодолеть барьер между высоким уровнем про­граммных абстракций и низким уровнем абстрагирования на уровне компьютеров. С объектно-ориентированной архи­тектурой также тесно связаны объектно-ориентированные операционные сис­темы. Однако наиболее значительный вклад в объектный подход был внесен объект­ными и объектно-ориентированными языками программирования: Simula, Smalltalk, C++, Object Pascal. На объектный подход оказали влияние также развивавшиеся достаточно независимо методы модели­рования баз дан­ных, в особенности подход "сущность-связь".

Концептуальной основой объектно-ориентированного подхода яв­ляется объектная модель. Основными се элементами являются:

• абстрагирование (abstraction);

• инкапсуляция (encapsulation);

• модульность (modularity);

• иерархия (hierarchy).

Кроме основных имеются еще три дополнительных элемента, не являю­щихся в отличие от основных строго обязательными:

• типизация (typing)',

• параллелизм (concurrency)',

• устойчивость (persistence).

Абстрагирование — это выделение существенных характеристик не­кото­рого объекта, которые отличают его от всех других видов объектов и, таким образом, четко определяют его концептуальные границы относи­тельно даль­нейшего рассмотрения и анализа. Абстрагирование концен­трирует внимание на внешних особенностях объекта и позволяет отде­лить самые существенные осо­бенности его поведения от деталей их ре­ализации. Выбор правильного набора абстракций для заданной предмет­ной области представляет собой главную за­дачу объектно-ориентирован­ного проектирования.

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

Объектно-ориентированный подход

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

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

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

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

Устойчивость — свойство объекта существовать но времени (вне зависи­мости от процесса, породившего данный объект) и/или в пространстве (при пе­ремещении объекта из адресного пространства, в котором он был создан).

Основные понятия объектно-ориентированного подхода - объект и класс.

Объект определяется как осязаемая реальность (tangible entity) — предмет или явление, имеющие четко определяемое поведе­ние. Объект обладает со­стоянием, поведением и индивидуаль­ностью; структура и поведение схожих объектов определяют общий для них класс. Термины "экземпляр класса" и "объект'' являются эквивалентными. Состояние объекта характеризуется переч­нем всех возможных (статических) свойств данного объек­та и текущими значе­ниями (динамическими) каждого из этих свойств. Поведение характеризует воздействие объекта на дру­гие объекты и наоборот относительно изменения со­стояния этих объектов и передачи сообщений. Иначе говоря, поведение объек­та полностью определяется его действиями. Индивидуальность — это свойства объекта, отличающие его от всех других объектов.

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

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

Следующую группу важных понятий объектного подхода состав­ляют на­следование и полиморфизм. Понятие полиморфизма может быть интерпретиро­вано как способность класса принадлежать более чем одному типу. Наследова­ние означает построение новых классов на основе существующих с возможно­стью добавления или переоп­ределения данных и методов.

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

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

32. Основные элементы объектной модели

COM (англ. Component Object Model — Объектная Модель Компонентов; произносится как [ком]) — это технологический стандарт от компании Microsoft, предназначенный для создания программного обеспечения на основе взаимодействующих распределённых компонентов, каждый из которых может использоваться во многих программах одновременно. Стандарт воплощает в себе идеи полиморфизма и инкапсуляции объектно-ориентированного программирования. Стандарт COM не мог быть универсальным и закрепился в основном на операционных системах семейства Microsoft Windows. В современных версиях Windows COM используется очень широко. На основе COM были созданы технологии: Microsoft OLE Automation, ActiveX, DCOM, COM+, а также XPCOM.

Принципы работы COM

Основным понятием, которым оперирует стандарт COM, является COM-компонент. Программы, построенные на стандарте COM, фактически не являются автономными программами, а представляют собой набор взаимодействующих между собой COM-компонентов. Каждый компонент имеет уникальный идентификатор (GUID) и может одновременно использоваться многими программами. Компонент взаимодействует с другими программами через COM-интерфейсы — наборы абстрактных функций и свойств. Каждый COM-компонент должен, как минимум, поддерживать стандартный интерфейс «IUnknown», который предоставляет базовые средства для работы с компонентом. Интерфейс «IUnknown» включает в себя три метода: QueryInterface, AddRef, Release.

Windows API предоставляет базовые функции, позволяющие использовать COM-компоненты. Библиотеки MFC и, особенно, ATL/WTL предоставляют гораздо более гибкие и удобные средства для работы с COM. Библиотека ATL от Microsoft до сих пор остаётся самым популярным средством создания COM-компонентов. Но, зачастую, COM-разработка остаётся ещё довольно сложным делом, программистам приходится вручную выполнять многие рутинные задачи, связанные с COM (особенно это заметно в случае разработки на C++). Впоследствии (в технологиях COM+ и особенно .NET) Microsoft попыталась упростить задачу разработки COM-компонентов.

Технологии, основанные на стандарте COM

DCOM

COM+

.NET и будущее COM

DCOM через интернет и решение проблемы XP SP2

OPC

OLE

33. Понятие объекта, его состояние, идентификация, интерфейс

Объект- это осязаемая сущность, которая четко проявляет свое поведение.

Объект состоит из следующих трех частей:

имя объекта;

состояние (переменные состояния);

методы (операции).

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

Термин объект в программном обеспечении впервые был введен в языке Simula и применялся для моделирования реальности. Объект обладает состоянием, поведением и идентичностью; структура и поведение схожих объектов определяет общий для них класс; термины «экземпляр класса» и «объект» взаимозаменяемы. [2]

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

Экземпляр класса (англ. instance) — это описание конкретного объекта в памяти. Класс описывает свойства и методы, которые будут доступны у объекта, построенного по описанию, заложенному в классе. Экземпляры используют для представления (моделирования) конкретных сущностей реального мира. Например объектом может быть ваша стиральная машина, и иметь следующие атрибуты: компания-производитель «Вятка», наименование модели «Вятка-автомат», серийный номер изделия ВЯТ454647, емкость 20 л.

Имя объекта начинается обычно со строчной буквы.

Анонимный объект (англ. anonymous object) — это объект который принадлежит некоторому классу, но не имеет имени.

Инициализация (англ. initialization) — присвоение начальных значений полям объекта.

Объект может быть идентифицирован с помощью имени.

Идентификация объекта может быть осуществлена с помощью специального набора атрибутов.

34. Понятие класса. Диаграммы классов

35. Ассоциации, атрибуты, операции

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

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

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

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

Атрибуты (Поля классов)

Поле класса (переменная-член, data member, class field, instance variable) в объектно-ориентированном программировании — переменная, связанная с классом или объектом. Все данные объекта хранятся в его полях. Доступ к полям осуществляется по их имени. Обычно тип данных каждого поля задаётся в описании класса, членом которого является поле.

Поля структур

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

Статические поля

Обычно каждому объекту соответствуют собственные значения всех его полей. Также к полям класса относят статические поля (static data members, static class fields, class variables) — поля, общие для всех объектов класса.

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

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

Битовые поля

Некоторые языки, такие как C++, позволяют определять битовые поля. Эти поля занимают менее одной единицы памяти (байт, слово); компилятор сам упаковывает несколько битовых полей в одну единицу памяти, позволяя при этом обращаться к битовым полям как к отдельным полям класса.

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

Советы по использованию

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

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

Операция (Метод) в объектно-ориентированном программировании — это функция, принадлежащая какому-то классу или объекту.

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

Различают методы класса и метакласса (или в другом толковании статические методы):

первые работают с данными объекта,

вторые имеют доступ только к данным класса, и общие для всех объектов данного класса.

Для статических методов класса не требуется создание объекта.

Методы в некоторых языках (таких как C++ или C#) могут иметь модификаторы доступа, которые ограничивают места в программном коде, где могут быть вызваны эти методы (например, модификатор private сделает метод доступным только внутри класса).

36. Обобщения, ограничения

37. Инкапсуляция, наследование, полиморфизм

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

Пользователь может взаимодействовать с объектом только через этот интерфейс. Реализуется с помощью ключевого слова: public.

Пользователь не может использовать закрытые данные и методы. Реализуется с помощью ключевых слов: private, protected, internal.

Инкапсуляция — один из четырёх важнейших механизмов объектно-ориентированного программирования (наряду с абстракцией, полиморфизмом и наследованием).

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

предельная локализация изменений при необходимости таких изменений,

прогнозируемость изменений (какие изменения в коде надо сделать для заданного изменения функциональности) и прогнозируемость последствий изменений.

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

Пример:

В Delphi для создания скрытых полей или методов их достаточно объявить в секции private.

  TMyClass = class

  private

    FMyField: Integer;

    procedure SetMyField(const Value: Integer);

    function GetMyField: Integer;

  protected

  public

    property MyField: Integer read GetMyField write SetMyField;

  end;

Насле́дование – механизм позволяющий описать новый класс на основе уже существующего (родительского), при этом свойства и функциональность родительского класса заимствуются новым классом.

 

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

Типы наследования:

простое наследование - Класс, от которого произошло наследование, называется базовым или родительским (англ. base class). Классы, которые произошли от базового, называются потомками, наследниками или производными классами;

множественное наследование - при множественном наследовании у класса может быть более одного предка.

Пример:

Для использования механизма наследования в Delphi необходимо в объявлении класса справа от слова class указать класс предок:

Предок:

TAncestor = class

  private

  protected

  public

    //Виртуальная процедура.

    procedure VirtualProcedure; virtual; abstract;

    procedure StaticProcedure;

end;

Наследник:

TDescendant = class(TAncestor)

  private

  protected

  public

    //Перекрытие виртуальной процедуры.

    procedure VirtualProcedure; override;

    procedure StaticProcedure;

end;

Абсолютно все классы в Delphi являются потомками класса TObject. Если класс-предок не указан, то подразумевается, что новый класс является прямым потомком класса TObject.

Множественное наследование в Delphi не поддерживается.

Полиморфи́зм — взаимозаменяемость объектов с одинаковым интерфейсом.

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

Кратко смысл полиморфизма можно выразить фразой: «Один интерфейс, множество реализаций».

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

внешняя общность проявляется как одинаковый набор методов с одинаковыми именами и сигнатурами (именем методов и типами аргументов и их количеством);

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

Пример:

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

38. Абстрактные и интерфейсные классы

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

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

Абстрактные методы часто являются и виртуальными, в связи с чем понятия «абстрактный» и «виртуальный» иногда путают.

(абстрактный метод — метод класса, реализация для которого отсутствует.)

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

Пользователи интерфейсного класса работают с указателями и сcылками на Object, т.к. экземпляр класса создать невозможно. Соответственно как и в случае с классами-дескрипторами если не изменяется интерфейс нет необходимости делать перекомпиляцию. Для создания новых объектов, класс Object имеет статическую функцию Create, которая называется функцией-фабрикой. Такие функции возвращают указатели (лучше интеллектуальные) на динамически созданные объекты (потомки Object), которые поддерживают интерфейс интерфейсного класса.

Основное назначение ИК – построение гибких объектных моделей с возможностью создания обычных (реальных) классов на основе нескольких ИК с обязательной реализацией всех заявленных методов.

Отличие интерфейсных классов от абстрактных

Абстрактные классы могут содержать реализацию некоторых методов, интерфейсные – нет;

Абстрактные классы поддерживают только простое наследование, а интерфейсные – множественные;

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

Общим для интерфейсных и абстрактных классов является то, что они не предназначены для создания объектов.

Их назначение – построение иерархий классов на достаточно высоком уровне абстракции.

39. Множественное наследование

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

Множественное наследование позволяет классу перенимать функциональность у множества других классов.

Delphi – не поддерживает множественное наследование

40. Диаграммы взаимодействия

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

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

Существует два вида диаграмм взаимодействия: диаграммы последовательности (sequence diagrams) и кооперативные диаграммы (collaboration diagrams).

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

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

41. Диаграммы состояний

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

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

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

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

 42. Диаграммы компонентов

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

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

Визуализации общей структуры исходного кода программной системы.

Спецификации исполнимого варианта программной системы.

Обеспечения многократного использования отдельных фрагментов программного кода.

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

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

43. Диаграммы размещения

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

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

Диаграмма размещения показывает физическое расположение сети и местонахождения в ней различных компонентов.

Его основные элементы:

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

Соединение - это канал взаимодействия узлов (сеть).

44. Аттестация и сертификация ПО

Сертификация и аттестация программных средств

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

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

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

Таким образом, методически процесс сертификации представляет особую совокупность испытаний программ, для которых необходимы специальные стандарты, методики, средства автоматизации и подготовленные специалисты. Работы по сертификации объединяются в технологический процесс, на каждом этапе которого регистрируются документы, отражающие состояние и качество результатов разработки. Без таких проверочных и испытательных операций не разрешается переходить на следующий этап разработки. В результате процессы аттестации и сертификации отличаются от обычных испытаний ПС более высоким уровнем формализации и документального оформления всех условий и результатов испытаний, проводимых специальным испытательным органом.

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

в соответствии с требованиями к достоверности показателей качества должны определяться и минимизироваться содержание и объемы испытаний версий ПС;

для обеспечения юридической ответственности за результаты испытаний должны быть разработаны эффективные методы и нормативные документы аттестации и сертификации различных видов ПС;

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

исследование и обобщение опыта аттестации и сертификации

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

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

45. Программная документация. Состав и содержание ПО

Документация на программное обеспечение — это документы, сопровождающие некоторое программное обеспечение (ПО) — программу или программный продукт. Эти документы описывают то, как работает программа и/или то, как её использовать.

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

Типы документации

Существует четыре основных типа документации на ПО:

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

техническая — документация на код, алгоритмы, интерфейсы, API

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

маркетинговая

Архитектурная/проектная документация

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

Техническая документация

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

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

Часто при составлении технической документации используются автоматизированные средства — генераторы документации, такие как Doxygen, javadoc, NDoc и другие. Они получают информацию из специальным образом оформленных комментариев в исходном коде, и создают справочные руководства в каком-либо формате, например, в виде текста или HTML. Использование генераторов документации и документирующих комментариев многими программистами признаётся удобным средством, по различным причинам. В частности, при таком подходе документация является частью исходного кода, и одни и те же инструменты могут использоваться для сборки программы и одновременной сборки документации к ней. Это также упрощает поддержку документации в актуальном состоянии.

Пользовательская документация

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

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

Обычно, пользовательская документация представляет из себя руководство пользователя, которое описывает каждую функцию программы, а также шаги, которые нужно выполнить для использования этой функции. Хорошая пользовательская документация идёт ещё дальше и предоставляет инструкции о том что делать в случае возникновения проблем. Очень важно, чтобы документация не вводила в заблуждение и была актуальной. Руководство должно иметь чёткую структуру; очень полезно, если имеется сквозной предметный указатель. Логическая связность и простота также имеют большое значение.

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

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

Маркетинговая документация

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

подогреть интерес к продукту у потенциальных пользователей

информировать их о том, что именно делает продукт, с тем чтобы их ожидания совпадали с тем что они получат

объяснить положение продукта по сравнению с конкурирующими решениями

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

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