Преподаватель который помогает студентам и школьникам в учёбе.

Основы проектирования программ. Этапы создания программ (Общие положения теории проектирования)ного обеспечения

Содержание:

Введение

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

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

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

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

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

Возможность в последующем применить теоретические знания на практике.

Задачи курсовой работы :

- научиться основам проектирования программ;

- углубленно изучить основы программного обеспечения;

- изучить теорию оптимизации программных разработок;

- освоить технологию объектно-ориентированного программирования;

- выявить все этапы создания программного обеспечения ;

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

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

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

- подготовка к выполнению дипломной работы .

Объект курсовой работы - Программное обеспечение.

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

Предмет — Проектирование и создание ПО

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

Курсовая работа разделена на 3 главы:

В первой главе изложены основы проектирования программ и программного обеспечения.

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

В третьей главе описана технология объектно-ориентированного программирования.

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

1. ОСНОВЫ ПРОЕКТИРОВАНИЯ ПРОГРАММ

1.1. Общие положения теории проектирования

«Как без оформленного проекта можно построить скворечник, но не возможно строительство высотного здания или комплекса космодрома со строительной индустрией, жилыми, стартовыми и производственными комплексами, так и без проекта можно организовать лишь небольшую программу, но не автоматизированное рабочее место специалиста, а тем более автоматизированную систему управления большого предприятия.»^[2]

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

Программное изделие - программа, которую можно запускать, тестировать, исправлять, развивать, написанная в едином стиле, оттестирована до требуемого уровня надежности, сопровождена подробной документацией и подготовлена для выпуска в тираж^[3].

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

Автоматизированная система (АС) - организационно-техническая система, обеспечивающая выработку решений на основе автоматизации информационных процессов в различных сферах деятельности, система, состоящая из персонала и комплекса средств автоматизации их деятельности, реализующая информационную технологию выполнения установленных функций.^[4]

Программа — это очень сложный продукт, который состоит из сотен тысяч «мыслей». Сложность программы - это свойство, которое необходимо и определяется четырьмя основными причинами:

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

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

Спецификация в сфере проектной деятельности – это какое-либо описание в точных терминах^[5].

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

Алгоритм - строго определенная для исполнителя последовательность действий, приводящих к их решению.^[6]

Согласно Д. Кнуту^[7] – алгоритм имеет пять важных свойств:

Конечность (Алгоритм должен заканчиваться после выполнения конечного числа шагов);
Определенность (Каждый шаг алгоритма должен быть точно определен);
Наличие входных данных (Алгоритм имеет входные данные, задающиеся до начала его работы или определяющиеся динамически во время его выполнения);
Наличие выходных данных (Алгоритм имеет одно/несколько выходных данных, имеющих определенную связь с входными данными);
Эффективность (Алгоритм считается эффективным, если его операторы достаточно просты для того, чтобы их можно было точно выполнить при помощи бумаги и карандаша, в течении конечного промежутка времени).

Технология программирования, как наука изучает технологические процессы и порядок их прохождения (с использованием знаний, средств и методов)^[8]. Технологический процесс - это последовательность действий направленных на создание заданного объекта (технологических процедур и технологических операций), каждое из которых основано на каких-либо естественных процессах и деятельности человека^[9]. Знания, средства и методы могут использоваться в разных процессах и технологиях.

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

1. Общие принципы разработки программ

Программы различаются по выполняемым функциям, назначению, формам реализации. Существуют некоторые принципы, которые следует использовать при разработке программ^[10]:

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

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

Компонентный анализ - это рассмотрение, включающего в себя составные элементы и входящего в систему более высокого ранга объекта .^[12]
Структурный анализ - выявление элементов объекта и связей между ними.
Функциональный анализ - рассмотрение объекта как комплекса выполняемых им полезных и вредных функций.^[13]
Параметрический анализ - установление качественных пределов развития объекта - физических, экономических, экологических и др. Применительно к программам параметрами могут быть: время выполнения какого-нибудь алгоритма, размер занимаемой памяти и т.д. При этом выявляются ключевые технические противоречия, мешающие дальнейшему развитию объекта, и ставится задача их устранения за счет новых технических решений.
Генетический анализ - исследование объекта на его соответствие законам развития программных систем.^[14] В процессе анализа изучается история развития (генезис) исследуемого объекта: конструкции аналогов и возможных частей, технологии изготовления, объемы тиражирования, языки программирования и т.д.

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

Методология данного подхода базируется на трех концепциях:

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

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

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

При создании и развитии ПО рекомендуется применять следующие общесистемные принципы^[15]:

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

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

3) Принцип развития (предусматривающий в ПО возможность его совершенствования и наращивания компонентов и связей между ними);

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

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

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

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

Томас Кун в 1977 г. определил термин «парадигма» как свод норм научного мышления. Парадигма — это правило развития научного знания. Оно в течение определенного времени дает научному сообществу модель постановки проблем и их решений.^[16]

Когда какая-либо методология применяется во время стадии кодирования (реализации), ее очень часто называют парадигмой программирования - способом мышления в программировании.^[17]

В программировании существуют различные концепции языков (парадигмы), которые при написании программ могут приводить как к радикально различным подходам так к одним и тем же^[18]. Для ряда языков необходим свой тип мышления, особая школа обучения, особые технологии разработки. Множество программистов в рамках одной парадигмы используют в работе один-два языка программирования. Бывает программисту трудно понять чужую программу, реализованную в парадигме непривычной для него. В противовес изменению цели проекта под используемый язык в ряде проектных случаев рационально избрать иной язык программирования.^[19]

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

Список основных парадигм программирования вместе с присущими им видами абстракций^[20]:

Процедурно-ориентированные - алгоритмы;
Объектно-ориентированные - классы и объекты;
Логически-ориентированные - цели, выраженные в исчислении предикатов;
Ориентированные на правила - правила «если…, то…»;
Ориентированные на ограничения - инвариантные соотношения;
Параллельное программирование - потоки данных.

Существуют и другие парадигмы. Много их потому, что программирование - новая дисциплина и отчасти - из-за желания решать разные задачи. В настоящее время проводится большое число экспериментов с машинами, имеющими нестандартные архитектуры, многие из которых рассчитаны на применение других парадигм программирования, например числа Фибоначчи^[21]. Природа ЭВМ позволяет с большей или меньшей эффективностью моделировать одну архитектуру с помощью другой. Из архитектур наиболее удачны в которых за счет аппаратуры и программного обеспечения достигнута простота и наивысшая скорость использования.

Невозможно назвать какую-либо парадигму наилучшей во всех областях практического применения.^[22] Для проектирования баз знаний более пригодна парадигма, ориентированная на правила. Объектно-ориентированная парадигма является наиболее приемлемой для широкого круга задач, связанных с большими промышленными системами, в которых основной проблемой является сложность.

1. Стандарты программирования

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

Государственные стандарты отслеживают тенденции развития программирования и дают обязательные рекомендации по их соблюдению. Помимо государственных стандартов (ГОСТ^[23]) действуют отраслевые стандарты (ОСТ^[24]), стандарты предприятий (СТП).

Группа стандартов ГОСТ «Единая система программной документации» (ЕСПД) перенесла мало изменений с момента создания, пережила несколько поколений ЭВМ и революционных изменений технологий разработки программ. До настоящего времени не затрудняла новаций.

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

Необходимо также отметить стандарты ISO^[25].

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

Программист должен уметь не только использовать стандарты, но и разрабатывать новые^[26]. Так правила однотипного оформления исходного текста программы определяются стандартом проекта, который может быть изменен при начале разработки нового проекта. Однако в течение выполнения одного проекта оформление всех частей программы должно быть однотипным. Зачастую перед началом нового проекта конкретным программистам следует разрабатывать свои стандарты, которые не нарушают ГОСТ, ОСТ , СТП и действуют в пределах конкретного проекта.

2. ОПТИМИЗАЦИЯ ПРОГРАММНЫХ РАЗРАБОТОК

2.1. Выбор оптимального проектного решения

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

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

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

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

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

Понятие "оптимальное решение^[29]" в проектировании имеет определенное толкование - лучшее в том или ином смысле проектное решение, допускаемое обстоятельствами. В большинстве случаев проектная задача может быть решена несколькими способами, приводящими не только к различным выходным характеристикам, но и классам программ.

Самые универсальные программы - текстовые редакторы^[30], допускающие использование графики. Они позволяют производить вывод на печать, оформлять исходные данные, осуществлять ручной набор обоснования решения с результатами расчета. Для некоторых целей более удобны электронные таблицы. Многих пользователей вполне устраивают интегрированные системы, включающие текстовый процессор, электронных таблиц, процессор графические процессоры (рисунков и деловой графики), систему управления базой данных^[31] (СУБД), системы сетевой и модемной связи пользователей. При этом одно из решений может превосходить остальные по одним показателям и уступать по другим. Может оказаться что разные решения характеризуются разным набором показателей. В этих условиях трудно сказать, какая программная система оптимальна, даже трудно указать какая предпочтительнее.

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

База знаний совокупностей показателей должна состоять как из общих (общепрограммных), так и специальных (предметно-ориентированных^[32]) показателей.

В настоящее время используют следующие классификации показателей^[33]:

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

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

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

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

5) Эстетические показатели (характеризующие внешние свойства системы: выразительность, оригинальность, целостность, гармоничность, соответствие стилю и среде);

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

7) Патентно-правовые показатели (определяющие число используемых патентов, патентную чистоту, степень патентной защиты);

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

Среда проекта характеризуется:

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

2.2. Анализ требований к системе (системный анализ) и формулировка целей

Задача оптимизации разработки программ состоит в достижении целей при минимально возможной затрате ресурсов.

Системный анализ в отличие от предварительного системного исследования - это углубленное изучение информационных потребностей пользователей, которое будет положено в основу детального проектирования новой автоматизированной системы^[34] (АС^[35]).

Конечный продукт данного этапа - набор выполняемых функций, или функциональные требования, т.е. документированная постановка системных требований к новой АС^[36]. Когда речь идет о создании большой системы, этот документ представляет собой отчет о системном анализе, который осуществляется по этапам, показанным на рис. 1.

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

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

Важно выяснить:

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

Такой перечень целей следует иметь как памятку в личном дневнике исследователя системы.

Рис. 1. Этапы проведения системного анализа информационных систем^[40]

Второй этап системного анализа самый сложный шаг в массу метаинформации^[41], т.е. "данных о данных^[42]". Важными ориентирами в организации метаинформации являются объекты (совокупности, диаграммы, документы, аналитические записки и тексты, экономические показатели), также процессы создания объектов, их передачи, хранения и обработки.

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

Третий этап системного анализа - определение того, что должно быть в новой АС. Это методологический этап синтеза требований к новой системе^[43], которые вытекают из двух первых шагов анализа, также из специальных знаний и средств системных аналитиков. Специалисты по системному анализу знают, одной из коварных ловушек в их работе это возможность спутать анализ существующей системы с тем, что должно быть. Поэтому второй и третий этапы системного анализа четко разделены. Об этом важно помнить, чтобы не ошибиться в оценках основы, на которой новая система строиться. В системотехнической методологии анализ существующего отделяется от анализа черт будущего, чтобы не воспринять желаемое за действительное.

Четвертый этап системного анализа (документирование требований к новой системе) должен обобщить имеющиеся аналитические материалы и создать документированное отображение функциональных требований к новой АС. Документ "Требования к системе^[44]", или "Функциональные требования^[45]", является основой дальнейшей работы специалистов информационного отдела для создания детального проекта новой системы, для создания спецификаций всех ее инструкций, элементов, программ.

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

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

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

2) Заказчик, в свою очередь, не имеет достаточной информации о проблеме обработки данных, чтобы судить, что является выполнимым, а что - нет;

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

4) Спецификация системы из-за технических терминов и объема непонятна для заказчика;

5) В случае понятности спецификации для заказчика, она будет недостаточной для создающих систему разработчиков.

Итак, на данном этапе эволюционного развития ситуация в области проектирования АС выглядит следующим образом^[47]:

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

• имеется перечень потребностей, которые необходимо удовлетворить;

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

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

Формулировка целей – важнейший и первый этап процесса проектирования^[48]. Именно на этом этапе закладываются основы успеха в решении всей задачи. Ошибки в выборе и формулировке цели не могут быть скомпенсированы на последующих этапах. Причина проста - все, что проделывается на последующих этапах разработки, идет от поставленных целей. Такие ошибки невозможно скомпенсировать никакими методами на последующих этапах.

Все ошибки начальных этапов, как правило, выявленные на последующих этапах, имеют причины такие как:

1) Постановка недостижимой цели;

2) Стремление разработчика и постановщика задачи упростить задачу;

3) Неумение разработчика выделить из формулировки постановщика отдельно описание проблемы и постановку задачи;

4) Не выявленные ограничения.

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

Можно сформулировать последовательность рекомендаций^[49] (контрольных вопросов):

Рекомендация №1. Не доверяйте имеющимся формулировкам задачи

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

Рекомендация №2. Уточните требования к конечному результату:

1) Какие функции и с какими показателями качества должен выполнять функции объект?

2) Какой эффект будет получен в случае успешного решения задачи?

3) Каковы допустимые затраты, как они связаны с показателями качества?

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

Рекомендация №3.^[50] Уточните условия, в которых предполагается реализация найденного решения:

1) Подробно исследуйте ограничения и убедитесь, что они действительно имеют место;

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

Рекомендация №4. Изучите задачу, используя следующую информацию:

1) Как решаются задачи, близкие к рассматриваемой?

2) Как решаются задачи, обратные рассматриваемой? (Следует обратить особое внимание на области применения, для которых подобные задачи наиболее актуальны.)

Рекомендация №5. Мысленно измените условия задачи и исследуйте ее решение в новых условиях: изменяйте от нуля до бесконечности сложность объекта, затраты, время процесса, условия среды.

Рекомендация №6. Внимательно отработайте формулировку задачи, желательно с использованием наиболее общих терминов и понятий.

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

Анализ требований^[51] сосредоточен на интерфейсе системы человек - программа - машина и информационных потоках между ними. Здесь решается, что делает человек, а что и как делает машина. В ходе анализа решается вопрос о целесообразности применения ЭВМ^[52].

В процессе анализа рассматриваются^[53]:

1) Работа без и с ЭВМ с разной степенью автоматизации;

2) Варианты использования существующих программ как без так и с модификациями;

3) Варианты с программами специально созданными;

4) Время обработки информации;

5) Стоимость обработки информации;

6) Вероятность ошибок, последствия их и качество обработки информации.

Анализ требований способствует достижению наилучшего удовлетворения потребности и лучшему пониманию системы.

В ходе проведения системного анализа^[54] анализируются надсистема, система и подсистема в виде составных частей проектируемой системы.

При проектировании необходимо учитывать следующие эффекты.

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

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

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

"Хорошие цели всегда являются компромиссом между желанием наилучшим образом удовлетворить потребности и ограничениями, накладываемыми реализацией и средствами^[55]".

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

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

Формулировка и формализация целей. Интересна интерпретация целей через потребности и ограничения по ресурсам. Можно выделить три варианта формулировки целей^[56]:

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

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

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

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

Требования^[57] к показателям качества могут быть заданы в трех видах^[58]:

1. приравнять;

ограничить;
добиться экстремума.

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

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

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

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

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

Проектная процедура основывается на владении системным подходом применительно к анализу программных систем^[60]. Изначально рассматривается система - человек, программа, ЭВМ, другие объекты, пример: технические, выполняющее весь комплекс обработки информации. Дальше элементы рассматриваются по отдельности для уточнения требований. Программа имеет только информационный вход и выход. Облегчить генерацию целей на первичных этапах позволяет модель "черного ящика^[61]", рис. 2.

Суть проектной процедуры:

Шаг 1. Проанализируйте выход системы, определите состав и форму выходных данных.

Шаг 2. Проанализируйте вход системы, определите форму и состав входных данных.

Шаг 3. Определите критерии качества преобразования входной информации в выходную информацию.

Шаг 4. Определите ограничения.

Рис. 2. Модель "черного ящика" проектируемого объекта

Шаг 5. Определите основные алгоритмы обработки информации и рассчитайте время их выполнения.

Шаг 6. Доопределите ограничения.

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

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

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

3. ТЕХНОЛОГИЯ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПРОГРАММИРОВАНИЯ

3.1. Этапы и модели объектно-ориентированной технологии

Объектно-ориентированная технология создания программ^[63] основывается на так называемом объектном подходе. Одним из проявлений этого подхода является: сначала довольно долго создаются и оптимизируются объектная модель и иные модели и лишь затем осуществляется кодирование.

Обычно проектируемая программная система первоначально представляется в виде трех моделей которые взаимосвязаны^[64]:

1) Объектная модель (представляет структурные и статические аспекты системы);

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

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

Данные виды моделей позволяют рассмотреть три взаимно-ортогональных представления системы в одной системе обозначений.

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

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

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

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

Используя функциональную модель^[65], можно начинать работу с динамической моделью, наделяя объекты необходимыми данными и методами.

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

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

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

Объектную модель можно описать следующим образом:

1) Основные элементы модели – сообщения и объекты;

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

3) Выполнение программы заключается в создании объектов и передаче им последовательности сообщений.

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

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

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

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

Инкапсуляция и абстракция дополняют друг друга: абстрагирование направлено на наблюдаемое поведение объекта, инкапсуляция занимается внутренним устройством^[68]. Часто инкапсуляция дополняется сокрытием информации, маскировкой внутренних деталей, не влияющих на внешнее поведение. Объектный подход предполагает, что собственные ресурсы, которыми могут манипулировать только методы объекта, скрыты от внешних компонентов.

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

Принципы абстрагирования, модульности и инкапсуляции являются взаимодополняющими. Логически объект определяет границы определенной абстракции, а модульность и инкапсуляция делают их физически незыблемыми^[70].

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

3.2. Стадии и этапы разработки программ по ГОСТ 19.102-77

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

Таблица 1. Стадии разработки, этапы и содержание работ^[71]

Стадии разработки	Этапы работ	Содержание работ
1. Техническое задание	Обоснование необходимости разработки программы	Постановка задачи. Сбор исходных материалов. Выбор и обоснование критериев качества и эффективности разрабатываемой программы. Обоснование необходимости проведения научно-исследовательских работ.
	Научно-исследовательские работы	Определение структуры выходных и входных данных. Определение требований к техническим средствам. Обоснование целесообразности применения уже разработанных программ. Выбор методов решения задач. Обоснование принципиальной возможности решения поставленной задачи.
	Разработка и утверждение технического задания	Выбор языков программирования. Определение требований к программе. Определение этапов, стадий и сроков разработки программы и ее документации. Разработка технико-экономического обоснования разработки программы. Определение необходимости проведения научно-исследовательских работ на последующих стадиях. Утверждение и согласование технического задания.
2. Эскизный проект	Разработка эскизного проекта	Предварительная разработка структуры выходных и входных данных. Разработка описания алгоритма решения задачи. Определение методов решения задачи. Разработка технико-экономического обоснования.
2. Эскизный проект	Утверждение эскизного проекта	Разработка пояснительной записки. Согласование и утверждение эскизного проекта.
3. Технический проект	Разработка технического проекта	Уточнение структуры выходных и входных данных. Определение формы представления входных и выходных данных. Разработка алгоритма решения задачи. Определение семантики и синтаксиса языка. Разработка структуры программы. Окончательное определение конфигурации технических средств.
3. Технический проект	Утверждение технического проекта	Разработка пояснительной записки. Согласование и утверждение эскизного проекта.
4. Рабочий проект	Разработка программы	Программирование и отладка программы
	Разработка программной документации	Разработка программных документов в соответствии с требованиями ГОСТ 19.101-77
	Испытания программы	Разработка, согласование и утверждение порядка и методики испытаний. Корректировка программы и программной документации по результатам испытаний.
5. Внедрение	Подготовка и передача программы	Подготовка и передача программы и программной документации для сопровождения и (или) изготовления. Проведение предварительных государственных, межведомственных, приемо-сдаточных и других видов испытаний. Оформление и утверждение акта о передаче программы на сопровождение и (или) изготовление. Передача программы в фонд алгоритмов и программ.

Примечания^[72]:

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

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

Заключение:

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

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

Поставленные задачи были выполнены:

- Освоены основы проектирования программ

- Освоены основы программного обеспечения

- Ознакомлена с теорией оптимизации программных разработок

- Ознакомлена с технологией объектно-ориентированного программирования

- Были выявлены все этапы создания программного обеспечения

- Было развито умение самостоятельной работы по сбору, изучению, анализу и обобщению материала

- Была широко раскрыта тема работы

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

Список литературы

ISO/IEC 26514:2008 Systems and Software Engineering — Requirements for designers and developers of user documentation

Технологии программирования: Учебник/В.А.Камаев, В.В.Костерин. 2-е изд.

ГОСТ 19.004-80 Единая система программной документации

РД 50-680-88 «Методические указания»

Технологии программирования: Учебник/В.А.Камаев, В.В.Костерин. 2-е изд.

http://cs-companion.ru/nemnogo-teorii/slovari

Кормен, Т., Лейзерсон, Ч., Ривест, Р., Штайн, К. Алгоритмы: построение и анализ = Introduction to Algorithms / Под ред. И. В. Красикова. — 2-е изд. — М.: Вильямс, 2005.

Технологии программирования: Учебник/В.А.Камаев,В.В.Костерин-2-е изд., 2006.

ГОСТ 3.1109-82

Технологии программирования: Учебник/В.А.Камаев,В.В.Костерин-2-е изд., 2006.

Технологии программирования: Учебник/В.А.Камаев, В.В.Костерин-2-е изд., 2006.

Кузнецов А. М. Компонентного анализа метод // Лингвистический энциклопедический словарь / Главный редактор В. Н. Ярцева. — М.: Советская энциклопедия, 1990. — 685 с.

Копачевский Н.Д.Функциональный анализ: Учебное пособие. –2008. – 140 с

Технологии программирования: Учебник/В.А.Камаев, В.В.Костерин-2-е изд., 2006.

О.Л. Голицына, Т. Л. Партыка, И. И. Попов. ЯЗЫКИ ПРОГРАММИРОВАНИЯ,2008

R. W. Floyd. The Paradigms of Programming Communications of the ACM, 22(8):455—460, 1979. Русский перевод см. в кн.: Лекции лауреатов премии Тьюринга за первые двадцать лет (1966—1985), М.: МИР, 1993.

Роганов, 2001, подраздел «Парадигмы программирования»

Технологии программирования: Учебник/В.А.Камаев, В.В.Костерин-2-е изд., 2006.

Грэди Буч "Объектно-ориентированный анализ и проектирование с примерами приложений" (3-е издание)

Числа Фибоначчи // Большая советская энциклопедия : [в 30 т.] / гл. ред. А. М. Прохоров. — 3-е изд. — М. : Советская энциклопедия, 1969—1978.

Технологии программирования: Учебник/В.А.Камаев, В.В.Костерин-2-е изд., 2006.

ГОСТ 1.1-2002 Межгосударственная система стандартизации. Термины и определения п.4.1.1.3

ОСТ — Большая советская энциклопедия. — М.: Советская энциклопедия. 1969—1978.

ISO/IEC Guide 2:2004 Standardization and related activities — General vocabulary

Технологии программирования: Учебник/В.А.Камаев, В.В.Костерин-2-е изд., 2006.

Лисьев Г. А. Технологии поддержки принятия решений [электронный ресурс]: учеб. пособие / Г. А. Лисьев, И. В. Попова. — 2-е изд., стереотип. — М.: ФЛИНТА, 2011. — 133 c. ISBN 978-5-9765-1300-6

Технологии программирования: Учебник/В.А.Камаев,В.В.Костерин-2-е изд., 2006.

Вентцель Е.С. Исследование операций: задачи, принципы, методология. — М.: Наука, 1988. — С. 206.

Каймин В. А. 1.4. Редактирование текстов на ЭВМ // Информатика: учебник. — 2-е изд., перераб. и доп. — М.: ИНФРА-М, 2001. — 272 с. — («Высшее образование»). — ISBN 5-16-000612-5.

Кузнецов С. Д. Основы баз данных.— 2-е изд.— М.: Интернет-университет информационных технологий; БИНОМ. Лаборатория знаний, 2007.— 484с.

А. Я. Фридланд, Л. С. Чанамирова. Информатика и компьютерные технологии: основные термины : толковый словарь. — Астрель, 2003.01.01. — 270 с. — ISBN 9785170145461.