Архитектура программной системы, принципы и подходы создания системы
И.А. КОРОЛЬ
КУРС ЛЕКЦИЙ
«ПроектированиЕ программных систем»
Минск, 2017
СОДЕРЖАНИЕ
1. ОСНОВЫ ТЕОРИИ ПРОЕКТИРОВАНИЯ.. 5
1.1. Термины и определения. 5
1.2. Архитектура программной системы, принципы и подходы создания системы.. 15
1.3. Стандарты, стадии и этапы разработки программ.. 17
1.4. Выводы.. 22
1.5. Контрольные вопросы.. 23
1.6. Дополнительная литература и источники. 24
2. ВВЕДЕНИЕ В ПРОГРАММНУЮ ИНЖЕНЕРИЮ.... 25
2.1. История и основные понятия. 25
2.2. Отличия программной инженерии от других отраслей. 28
2.3. Модели процесса разработки программного обеспечения. 34
2.4. Успех программного продукта: что делать?. 41
2.5. Выводы.. 43
2.6. Контрольные вопросы.. 44
2.7. Дополнительная литература и источники. 44
3. Жизненный цикл программных систем... 46
3.1. Модели жизненного цикла программных систем.. 46
3.2. Каскадная модель жизненного цикла. 49
3.3. Спиральная модель жизненного цикла. 51
3.4. Процессы жизненного цикла и стандарты.. 52
3.5. СТБ ИСО/МЭК 12207-2003. 53
3.6. ГОСТ Р ИСО/МЭК 15288-2005. 56
3.7. Выводы.. 59
3.8. Контрольные вопросы.. 60
3.9. Дополнительная литература и источники. 61
4. Управление проектами. Определения и концепции.. 63
4.1. Проект – основа инноваций. 63
4.2. Критерии успешности проекта. 66
4.3. Проект и организационная структура компании. 68
4.4. Организация проектной команды.. 72
4.5. Жизненный цикл проекта. Фазы и продукты.. 76
4.6. Выводы.. 79
4.7. Контрольные вопросы.. 80
|
|
|
4.8. Дополнительная литература и источники. 81
5. ИНИЦИАЦИЯ (ЗАПУСК) ПРОЕКТА.. 82
5.1. Управление приоритетами проектов. 82
5.2. Концепция проекта. 85
5.3. Цели и результаты проекта. 86
5.4. Допущения и ограничения. 88
5.5. Ключевые участники и заинтересованные стороны.. 90
5.6. Ресурсы.. 91
5.7. Сроки. 94
5.8. Риски. 96
5.9. Критерии приемки. 97
5.10. Обоснование полезности проекта. 97
5.11. Выводы.. 98
5.12. Контрольные вопросы.. 99
5.13. Дополнительная литература и источники. 100
6. ПЛАНИРОВАНИЕ ПРОЕКТА.. 101
6.1. Уточнение содержания и состава работ. 101
6.2. Планирование управления содержанием.. 104
6.3. Планирование организационной структуры.. 105
6.4. Планирование управления конфигурациями. 106
6.5. Планирование управления качеством.. 106
6.6. Базовое расписание проекта. 107
6.7. Выводы.. 112
6.8. Контрольные вопросы.. 113
6.9. Дополнительная литература и источники. 114
7. УПРАВЛЕНИЕ РИСКАМИ ПРОЕКТА.. 115
7.1. Основные понятия. 115
7.2. Планирование управления рисками. 117
7.3. Идентификация рисков. 120
7.4. Качественный анализ рисков. 124
7.5. Количественный анализ рисков. 126
7.6. Планирование реагирования на риски. 128
7.7. Главные риски и способы реагирования. 131
7.8. Снижение рисков при управлении проектом.. 133
7.9. Мониторинг и контроль рисков. 136
|
|
|
7.10. Выводы.. 137
7.11. Контрольные вопросы.. 138
7.12. Дополнительная литература и источники. 138
8. Оценка трудоемкости и сроков разработки программного обеспечения.. 140
8.1. Оценка – вероятностное утверждение. 140
8.2. Негативные последствия «агрессивного» расписания. 142
8.3. Прагматичный подход (метод PERT) 144
8.4. Обзор метода функциональных точек. 146
8.5. Обзор методики COCOMO II 156
8.6. Белорусская методика оценки трудоемкости. 161
8.7. Выводы.. 164
8.7. Контрольные вопросы.. 165
8.8. Дополнительная литература и источники. 166
9. Формирование команды... 167
9.1. Лидерство и управление. 167
9.2. Правильные люди. 170
9.3. Мотивация. 172
9.4. Эффективное взаимодействие. 174
9.5. Выводы.. 177
9.6. Контрольные вопросы.. 178
9.7. Дополнительная литература и источники. 178
10. Реализация проекта.. 179
10.1. Рабочее планирование. 179
10.2. Принципы количественного управления. 180
10.3. Завершение проекта. 185
10.4. Выводы.. 186
10.5. Заключение. Растите профессионалов. 187
10.6. Контрольные вопросы.. 188
10.7. Дополнительная литература и источники. 188
11. ПЛАТФОРМЫ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ 189
11.1. Технологии разработки программного обеспечения. 189
11.1.1. Microsoft Foundation Classes. 189
11.1.2. Microsoft Active Template Library. 191
11.1.3. Active Server Pages. 191
|
|
|
11.1.4. Java Platform, Enterprise Edition. 192
11.1.5. Microsoft .NET Framework. 193
11.2. Визуальное программирование. 195
11.2.1. Общее понятие визуального программирования. 195
11.2.2. Технология визуального программирования. 199
11.3. Платформы для построения и поддержки порталов. 199
11.4. Выводы.. 201
11.5. Контрольные вопросы.. 202
11.6. Дополнительные литература и источники. 202
ОСНОВЫ ТЕОРИИ ПРОЕКТИРОВАНИЯ
Термины и определения
Как без оформленного проекта вполне можно построить скворечник, но невозможно строительство высотного здания или комплекса космодрома со строительной индустрией, жилыми, стартовыми и производственными комплексами, так и без проекта можно реализовать лишь небольшую программу, но не автоматизированное рабочее место специалиста, а тем более автоматизированную систему управления большого предприятия.
Что же производят программисты? Программисты производят программный продукт. В терминах автоматизированных систем программисты создают программное обеспечение.
Программный продукт — программа, которую можно запускать, тестировать, исправлять и развивать. Такая программа должна быть написана в едином стиле, тщательно оттестирована до требуемого уровня надежности, сопровождена подробной документацией и подготовлена для тиражирования.
|
|
|
Программная продукция[Software Product] – программный объект, предназначенный для поставки пользователю (ГОСТ Р ИСО/МЭК 9126-93).
Программа; компьютерная программа[Program; Computer Program] –синтаксическая единица, подчиняющаяся правилам специфического языка программирования и состоящая из описаний и операторов или команд, необходимых для решения определенной функции, задачи или проблемы.
Программный модуль[Software Unit] – отдельно компилируемая часть программного кода (программы).
Программное изделие — программа на носителе данных, являющаяся продуктом промышленного производства.
Программное обеспечение[Software] – программы, процедуры, правила и любая соответствующая документация, относящиеся к работе вычислительной системы (ГОСТ Р ИСО/МЭК 9126-93).
Программные средства (информационной технологии) – совокупность алгоритмов и программ, используемых при реализации информационного процесса с помощью вычислительной техники (СТБ 982-94).
Программное обеспечение автоматизированных систем – совокупность программ на носителях данных и программных документов, предназначенная для отладки, функционирования и проверки работоспособности автоматизированных систем.
Система [System] – комплекс, состоящий из процессов, технических и программных средств, устройств и персонала, обладающий возможностью удовлетворять установленным потребностям или целям.
Информационная система – организованная совокупность информационных технологий, объектов и отношений между ними, образующая единое целое (СТБ 982-94).
Информационная система[Information System] – система обработки информации в совокупности с относящимися к ней ресурсами организации, такими как люди, технические и финансовые ресурсы, которая предоставляет и распределяет информацию (ГОСТ ИСО/МЭК 2382-1-99).
Автоматизированная система (АС)– комплекс технических, программных, других средств и персонала, предназначенный для автоматизации различных процессов.
Автоматизированная или автоматическая информационная система –совокупность информационных технологий и комплекса программно-технических средств, осуществляющих информационные процессы в человеко-машинном или автоматическом режиме.
Необходимость в проекте вызвана сложностью задачи.
Следующий пример показывает нелинейную зависимость роста сложности задачи от ее размера. Необходимо в уме сложить числа 4 и 3. Ответ, разумеется, — 7. Необходимо в уме перемножить числа 7 и 9. Ответ, конечно, — 63. Но если не знаете таблицу умножения, то надо выполнить нестандартное преобразование в виде многократного сложения. Трудно ли оно для вас? Необходимо в уме перемножить числа 289 и 347. Если вы не феноменальный счетчик, то хватит ли в вашей голове оперативной памяти? А сможете ли вы перемножить в уме шестизначные числа? Но если декомпозировать данную задачу на вычисление ряда произведений одного из сомножителей на отдельные цифры другого сомножителя и затем найденные произведения сложить (при этом записывать на бумаге все промежуточные результаты), то с этой задачей вполне может справиться заурядный человек.
Еще пример, показывающий один из путей снижения сложности задачи за счет ее декомпозиции на обозримые части. Обычный нормальный человек со средними способностями может одновременно в своей голове удержать не более семи мыслей. В школе задачи с шестью действиями считаются задачами повышенной сложности и помечаются символом «*». В армиях разных стран, времен и народов производилось деление на десятки, сотни, тысячи. У командиров в подчинении находилось либо десять воинов, либо десять младших командиров.
Программа — очень сложный объект, содержащий до сотен тысяч и даже нескольких миллионов мыслей. Сложность программного продукта — отнюдь не случайное свойство, скорее необходимое. Его сложность определяется четырьмя основными причинами: сложностью задачи, сложностью управления процессом разработки, сложностью описания поведения отдельных подсистем, сложностью обеспечения гибкости конечного программного продукта.
Проектирование — это разработка проекта, процесс создания спецификации, необходимой для построения в заданных условиях еще несуществующего объекта на основе первичного описания этого объекта. Результатом проектирования является проектное решение или совокупность проектных решений, удовлетворяющих заданным требованиям. Заданные требования обязательно должны включать форму представления решения.
Спецификация в сфере проектной деятельности — это какое-либо описание в точных терминах.
Проектным документом называют документ, выполненный по заданной форме, в котором представлено какое-либо проектное решение. В программировании проектные решения оформляются в виде программной документации. Различают внешнюю программную документацию, которая согласуется с заказчиком, и внутреннюю промежуточную документацию проекта, которая необходима самим программистам для их работы.
Проект (от лат. projectus — брошенный вперед) — совокупность проектных документов в соответствии с установленным перечнем, которая представляет результат проектирования.
Проектной ситуацией называют реальность (ситуацию), в которой ведется проектирование. Паровоз и электровоз проектировались в разных проектных ситуациях, определенных уровнем знаний человечества. Именно поэтому XIX в. стал веком паровоза.
Любая задача характеризуется необходимостью преобразования некоторой исходной ситуации в ситуацию, называемую решением. Говоря о любой задаче, всегда имеем ее информационные элементы:
· информация об условии (условие задачи) — что задано;
· информация о решении (признаки исходной ситуации) — что требуется получить;
· информация о технологии преобразования условия в решение – как решить.
Проектная задача (англ. Engineering Task) характеризуется неопределенностью априори информации: что требуется получить, что задано. Более того, способ решения задачи является объектом проектирования. И наконец, решение проектной задачи должно быть найдено в рамках ограничений внешней среды проектирования: доступных денежных средств, заранее заданных сроков, возможностями технических средств и инструментария программирования, научных знаний, программных заделов и т. д.
Проектные задачи по плечу только тем, кто способен воспринимать явление целиком и в мельчайших деталях одновременно, остроумно связывая эти детали между собой. Именно таких людей всегда называли инженерами, да и сам термин происходит от латинского ingenium, что означает природный ум, а также изобретательность. Инженер-программист — специалист по решению проектных задач. Инженер-системотехник — инженер инженеров, специалист по решению проектных задач создания таких особо сложных искусственных систем, как автоматизированные системы.
Источником, первопричиной всякой проектной деятельности является субъект — человек или группа людей, испытывающие дискомфорт в существующей ситуации.
«Лежа на теплой печи» (находясь в комфортной ситуации), можно мечтать о решении мировых проблем и ничего не делать. Однако страх перед грядущим дискомфортом (замерзание, голод) вернет мечтателя в реальную ситуацию и потребует нахождения способа решения и самого решения проблемы дальнейшего его существования (заготовка дров и продуктов).
Дискомфорт субъекта может быть конкретизирован в виде потребности, удовлетворение которой снимает его.
Для удовлетворения потребности нужен некоторый объект проектирования (в нашем случае программный продукт), наличие которого, его свойства и состояние удовлетворяют потребностям субъекта.
Ответив на вопрос, какими свойствами должен обладать объект, подготовим исходные данные для следующего вопроса: как должен быть устроен объект, чтобы иметь такие свойства? Для решения этой задачи также необходимо раскрыть исходную ситуацию. Причем такое раскрытие требуется на разных уровнях конкретизации объекта. Таким образом, получается, что процедура раскрытия проектной ситуации может повторяться многократно и на разных этапах решения общей проектной задачи. При этом все решения взаимосвязаны: решения, принятые на одном этапе, должны быть учтены при выполнении других. Каким-либо образом формализовать и учесть это влияние затруднительно, поэтому процесс решения носит итерационный характер.
Для удовлетворения потребности должна быть реализована некоторая деятельность, конечным результатом которой (целью) и будет создание объекта и (или) приведение его в желаемое (целевое) состояние. Эта деятельность тоже является объектом, требующим проектирования. По отношению к ней также должна решаться аналогичная задача. Иначе говоря, сам процесс проектирования является объектом проектирования.
Метод (от греч. methodos — способ исследования или познания, теория или учение) — прием или система приемов практического осуществления чего-нибудь в какой-либо предметной области, совокупность приемов или операций практического или теоретического освоения действительности, подчиненных решению конкретных задач. Метод включает средства — с помощью чего осуществляется действие и способы — каким образом осуществляется действие.
Методика (от греч. methodize) — упорядоченная совокупность методов практического выполнения чего-нибудь.
Методики проектирования излагаются в виде описаний проектных процедур и проектных операций.
Метод проектирования программного обеспечения[Software Design Method]–целенаправленная совокупность процедур, позволяющая получить в результате описание разрабатываемой программной системы с такой степенью детализации, которая достаточна для ее реализации. Современные индустриальные технологии проектирования основаны главным образом на методах, использующих структурное или объектное моделирование разрабатываемой системы. (Наряду со структурными и объектными методами на практике используются также и более элитарные формальные методы спецификации систем).
Под проектной процедурой понимают формализованную совокупность действий, выполнение которых оканчивается проектным решением. Например, проектной процедурой являются процедуры раскрытия проектной ситуации и разработки структуры программы.
Действие или формализованную совокупность действий, составляющих часть проектной процедуры, алгоритм которых остается неизменным для ряда проектных процедур, называют проектной операцией. Например, вычерчивание схемы, дифференцирование функции.
Проектные процедуры могут включать другие проектные процедуры и т. д. до проектных операций. Проектные процедуры могут представлять собой алгоритмы (только для тривиальных нетворческих операций) и эвроритмы (которыми излагаются эвристические операции).
Алгоритм — строго однозначно определенная для исполнителя последовательность действий, приводящих к решению задач. Современное значение слова «алгоритм» во многом аналогично таким понятиям, как рецепт, процесс, методика, способ. Согласно Д. Кнуту, алгоритм имеет пять важных свойств.
Конечность. Алгоритм всегда должен заканчиваться после выполнения конечного числа шагов.
Определенность. Каждый шаг алгоритма должен быть точно определен.
Наличие входных данных. Алгоритм имеет некоторое число входных данных, задающихся до начала его работы или определяющихся динамически во время его выполнения.
Наличие выходных данных. Алгоритм имеет одно или несколько выходных данных, имеющих определенную связь с входными данными.
Эффективность. Алгоритм обычно считается эффективным, если его операторы достаточно просты для того, чтобы их можно было точно выполнить при помощи карандаша и бумаги в течение конечного промежутка времени.
Термин «эвроритм» науки эвристика образован от легендарного возгласа Архимеда «Эврика!», что в переводе с греческого означает «нашел, открыл». Алгоритм в процессе выполнения не изменяется бездумным исполнителем (процессором). В отличие от алгоритма эвроритм выполняется мыслящим человеком, который может усовершенствовать порядок своей работы в процессе ее выполнения. Эвроритм может включать алгоритмы. Например, инструкция пользования программой — это эвроритм, особенно если одни и те же действия можно выполнить разными способами (через пункт меню или нажатием кнопки).
Эвристика — наука, раскрывающая природу мыслительных операций человека при решении конкретных задач независимо от их конкретного содержания. В более узком смысле эвристика — это догадки, основанные на опыте решения родственных задач.
Инженерия программирования (англ. software engineering, в терминах автоматизированных систем — разработка программного обеспечения) — инженерное дело, творческая техническая деятельность. Инженерия опирается на специфические методы и методики, в том числе эвристические. Инженерия изучает различные методы и инструментальные средства с точки зрения определенных целей, т. е. имеет очевидную практическую направленность.
Основная идея инженерии программирования в том, что разработка программного обеспечения является формальным процессом, который можно изучать, выражать в методиках и совершенствовать.
Инженерия программирования имеет четкую определенную дату рождения — 1968 г. Причина ее появления — реакция на так называемый «кризис программного обеспечения», вызванный достижением непреодолимого уровня сложности. Характерные вопросы и задачи инженерии программирования, изложенные Фредериком Бруксом, актуальны и по сегодняшний день.
Как проектировать и строить программы, образующие системы?
Как проектировать и строить программы и системы, являющиеся надежным, отлаженным, документированным и сопровождаемым продуктом?
Как осуществлять интеллектуальный контроль в условиях большой сложности?
Инженерная деятельность базируется на совокупности общенаучных методов системного подхода, аналитико-синтетическом методе блочно-иерархического подхода к проектированию сложных систем, аналитико-синтетическом методе стадии и этапы разработки. Дополнительно инженеры используют методы и методики, специализированные по отношению к объекту проектирования или изготовления.
Важными при разработке процессов проектирования являются такие понятия, как стратегия и тактика.
Стратегия (от греч. stratos — войско и ago — веду) — наука, искусство генерации наиболее существенных общих долгосрочных целей и наиболее общего плана достижения преимущества, курса действий и распределения ресурсов еще до выполнения реальных действий.
Тактика (от греч. taktika — искусство приводить в порядок) — фиксированная в своей последовательности совокупность средств и приемов для достижения намеченной цели и искусство ее применения, способы действия, ориентированные на достижение конкретных целей, являющиеся звеньями реализации стратегических целей. Целью применения способа действия является совершение оптимальных действий, в заранее не предсказанных стратегическим планом ситуациях, уже в процессе выполнения реальных действий.
Стратегия охватывает теорию и практику подготовки к выполнению проекта, а также наиболее общее планирование тактик ведения проектов. Стратегия определяет, куда, в каком направлении двигаться, куда держать курс еще до начала проекта. А тактика определяет, как, каким способом двигаться, какие конкретные действия предпринимать при затруднениях в ходе выполнения проекта.
Стратегия выполнения конкретного проекта описывается в программном документе — техническом задании.
Методология (от греч. methodos и logos — слово, учение о методах) — система принципов и способов организации и построения теоретической и практической деятельности, а также учение об этой системе.
Методология программирования изучает методы с точки зрения основ построения. Это объединенная единым философским подходом совокупность методов, применяемых в процессе разработки программных продуктов. Любая методология создается на основе уже накопленных в предметной области эмпирических фактов и практических результатов.
Технология (от греч. techne — искусство, мастерство, умение и logos — слово, учение) — совокупность производственных процессов в определенной отрасли производства, а также научное описание способов производства, совокупность приемов, применяемых в каком-либо деле, мастерстве, искусстве.
Современная методология проектирования позволила довести методы проектирования до технологий с набором методик.
Технология программирования как наука изучает технологические процессы и порядок их прохождения (с использованием знаний, методов и средств). Технологический процесс — последовательность направленных на создание заданного объекта действий (технологических процедур и операций), каждое из которых основано на каких-либо естественных процессах и человеческой деятельности. Знания, методы и средства могут использоваться в разных процессах и, следовательно, в технологиях.
Технология программирования — для инженера это научная и практически апробированная стратегия создания программ, содержащая описание совокупности методов и средств разработки программ, а также порядок применения этих методов и средств.
Технология автоматизированной разработки программного обеспечения[Computer Aided Software Engineering, CASE],Технология автоматизированной разработки систем[Computer Aided System Engineering, CASE], CASE-технология[CASE Technology] – автоматизированная технология, обеспечивающая с помощью предназначенного для этих целей инструментария (CASE-систем) комплексную поддержку разработки либо поддержку отдельных стадий жизненного цикла сложных программных или информационных систем.
В реальных проектных ситуациях необходим синтез рациональной стратегии каждого конкретного проекта. Инженеры часто этот синтез осуществляют на основе одной, двух и даже трех технологий.
Инженерное дело (деятельность по созданию и использованию технологий) охватывает не только проектирование и производство, но и структуры организаций с взаимодействием людей. В терминах инженерного дела технология — инструментарий инженера, интеллектуальный либо отчужденный в виде искусственных систем.
Главное различие между технологией программирования и программной инженерией заключается в способе рассмотрения и систематизации материала. В технологии программирования акцент делается на изучении процессов разработки программ (технологических процессов) в порядке их прохождения — методы и инструментальные средства разработки программ используются в этих процессах (их применение и образуют технологические процессы).
В программной инженерии изучаются прежде всего методы и инструментальные средства разработки программ с точки зрения достижения определенных целей — они могут использоваться в разных технологических процессах (и в разных технологиях программирования). Как эти методы и средства образуют технологические процессы — вопрос второстепенный.
Не следует также путать технологию программирования с методологией программирования, хотя в обоих случаях изучаются методы. В технологии программирования методы рассматриваются «сверху» — с точки зрения организации технологических процессов, в методологии — «снизу» — с точки зрения основ их построения.
Перед нами стоит вопрос, ранее уже упоминавшийся: «Как определить, достигнута ли цель, привела ли деятельность к желаемому результату: тот ли объект создан, который нам нужен, обладает ли нужными свойствами?» Для этого используются показатели качества (иногда их называют критериями) — величины, свойства, понятия, характеризующие систему с точки зрения субъекта, позволяющие оценить степень удовлетворения его потребностей. На начальном этапе проектирования анализ потребностей позволяет определить вид объекта; его функции (что объект делает при функционировании), свойства и состояние, при которых удовлетворяются потребности, а также уровень качества объекта.
При исследовании систем решаются задачи анализа и синтеза.
Анализ (от греч. analysis — разложение, расчленение) — прием умственной деятельности, связанный с мысленным (или реальным) расчленением на части предмета, явления или процесса.
Синтез (от греч. synthesis — соединение, сочетание, составление) — метод научного исследования явлений действительности в их единстве и целостности, во взаимодействии их частей, обобщение, сведение в единое целое.
Синтез неразрывно связан с анализом и не существует отдельно от него, а также связан с другими мыслительными процессами. Без синтеза невозможно выполнение процедур обобщения, систематизации, сравнения (выбора), вместе с которыми он оставляет логический аппарат мышления.
В теории проектирования используются следующие понятия анализа и синтеза.
Анализ – процесс определения функционирования по заданному описанию системы.
Синтез — процесс построения описания системы по заданному функционированию.
Одним из определений задачи оптимизации разработки программ является нахождение разумного компромисса между достигаемой целью и затрачиваемыми на это ресурсами, что может приводить как к пересмотру целей разработки, так и к изменению лимита ресурсов. Решение этой задачи особенно важно, так как программы являются дорогостоящим продуктом, и, правильно проведя разработку, можно добиться значительного ее удешевления.
По своей природе программа (т. е. набор инструкций) гораздо ближе к технологии (точнее, к описанию технологического процесса преобразования входной информации в выходную информацию), чем к изделию. Это означает, что для оценки производительности труда программиста не нужно искать способ оценки количества продукции, выпускаемой им, поскольку никакая физическая продукция не производится и, следовательно, нет ее объема. При использовании стандартного термина «программное изделие» возникают методологические, правовые и чисто технические сложности. Так, например, программисту не составит никакого труда вставить в программу любое количество модулей с любым объемом незадействованных операторов. Товарные свойства программного продукта — не товарные свойства этого изделия, а товарные свойства технологии. Причем технологии — это тоже объекты, традиционно проектируемые инженерами.
Программный продукт является разработанной программистом информационной технологией, которая материализуется у заказчика в виде изделия, становясь автоматизированными системами и инструментами их обслуживания. Это объяснение, по-видимому, снимает многие правовые проблемы, а также проблемы ценообразования.
Архитектура программной системы, принципы и подходы создания системы
Разработка архитектуры системы — это процесс разбиения большой системы на более мелкие части. Для обозначения этих частей придумано множество названий: программы, компоненты, подсистемы...
Процесс разработки архитектуры — этап, необходимый при проектировании систем или комплексов, но необязательный при создании программы. Если внешние спецификации (экранные формы, организация файлов и т. д.) описывают программную систему с точки зрения пользователя, то следующий шаг проектирования состоит в разработке архитектуры, а за ним следует проектирование структуры каждой программы.
Несмотря на то, что нет точного определения программной системы, можно сказать, что она представляет собой набор решений множества различных, но связанных между собой задач, и далее положиться на интуицию в случаях, когда надо отличить программу от системы.
Примеры систем: ОС, СУБД, система продажи авиабилетов и др.
Примеры программ: редактор текстов, компилятор, программы посылки запросов от кассира и др.
Понятие архитектуры программной системы можно проиллюстрировать на следующем примере. Пусть имеется на неком предприятии некая САПР. Допустим, что предприятие достаточно крупное, и САПР будет являться целым комплексом различных программных продуктов, причем зачастую различных производителей. Архитектурой этой системы будет являться описание связей этих программных средств в одно целое. Глазами программиста: САПР – комплекс комплексов программ.
Системный подход — общенаучный обобщенный эвроритм, предусматривающий всестороннее исследование сложного объекта с использованием компонентного, структурного, функционального, параметрического и генетического видов анализа.
Компонентный анализ — рассмотрение объекта, включающего в себя составные элементы и входящего, в свою очередь, в систему более высокого ранга.
Структурный анализ — выявление элементов объекта и связей между ними.
Функциональный анализ — рассмотрение объекта как комплекса выполняемых им полезных и вредных функций.
Параметрический анализ — установление качественных пределов развития объекта — физических, экономических, экологических и др. Применительно к программам параметрами могут быть: время выполнения какого-нибудь алгоритма, размер занимаемой памяти и т. д. При этом выявляются ключевые технические противоречия, мешающие дальнейшему развитию объекта, и ставится задача их устранения за счет новых технических решений.
Генетический анализ — исследование объекта на его соответствие законам развития программных систем. В процессе анализа изучается история развития (генезис) исследуемого объекта: конструкции аналогов и возможных частей, технологии изготовления, объемы тиражирования, языки программирования и т. д.
При блочно-иерархическом подходе (частном эвроритме системного подхода, который используется часто в технике и программировании) процесс проектирования и представления о самом объекте расчленяется на уровни. На высшем уровне используется наименее детализированное представление, отражающее самые общие черты и особенности проектируемой системы. На каждом новом последовательном уровне разработки степень подробности рассмотрения возрастает, при этом система рассматривается не в целом, а отдельными блоками.
Методология блочно-иерархического подхода базируется на трех концепциях: разбиения и локальной оптимизации, абстрагирования, повторяемости.
Концепция разбиения позволяет сложную задачу проектирования объекта или системы свести к решению более простых задач с учетом их взаимосвязи.
Локальная оптимизация подразумевает улучшение параметров внутри каждой простой задачи.
Абстрагируемость заключается в построении моделей, отражающих только значимые в данных условиях свойства объектов.
Повторяемость — в использовании существующего опыта проектирования.
Блочно-иерархический подход позволяет на каждом уровне решать задачи приемлемой сложности. Разбиение на блоки должно быть таким, чтобы документация на любом уровне была обозрима и воспринимаема одним человеком.
Главным недостатком блочно-иерархического подхода является то, что на верхних уровнях имеют дело с неточными моделями объекта, и решения принимаются в условиях недостаточной информации. Следовательно, при этом подходе высока вероятность проектных ошибок.
При создании и развитии программного обеспечения (ПО) рекомендуется применять следующие общесистемные принципы:
1) принцип включения, предусматривающий, что требования к созданию, функционированию и развитию ПО определяются со стороны более сложной, включающей его в себя системы;
2) принцип системного единства, состоящий в том, что на всех стадиях создания, функционирования и развития ПО его целостность будет обеспечиваться связями между подсистемами, а также функционированием подсистемы управления;
3) принцип развития, предусматривающий в ПО возможность его наращивания и совершенствования компонентов и связей между ними;
4) принцип комплексности, заключающийся в том, что ПО обеспечивает связанность обработки информации как отдельных элементов, так и всего объема данных в целом на всех стадиях обработки;
5) принцип информационного единства, т. е. во всех, подсистемах, средствах обеспечения и компонентах ПО используются единые термины, символы, условные обозначения и способы представления;
6) принцип совместимости, состоящий в том, что язык, символы, коды и средства программного обеспечения согласованы, обеспечивают совместное функционирование всех подсистем и сохраняют открытой структуру системы в целом;
7) принцип инвариантности, предопределяющий, что подсистемы и компоненты ПО инвариантны к обрабатываемой информации, т, е. являются универсальными или типовыми.
Инвариантность – 1) свойство величин оставаться неизменными, сохраняться при тех или иных преобразованиях; 2) неизменность, независимость от чего-либо.
Дата добавления: 2018-05-02; просмотров: 992; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!