
- •Основные этапы развития технологии создания ис.
- •Проблемы разработки сложных программныхсистем.
- •Блочно иерархический подход к созданию сложных систем.
- •Приемы обеспечения технологичности программных продуктов. Понятие технологичности программного обеспечения.
- •Модули и их свойства. Сцепление модулей. Связность модулей. Библиотека ресурсов.
- •Нисходящая и восходящая разработка программного обеспечения.
- •Средства описания структурных алгоритмов. Псевдокоды. Необязательно: ( Flow-формы, Диаграммы Несси-Шнейдермана.)
- •Программирование «с защитой от ошибок». Сайт.
- •Классификация программных продуктов по функциональному признаку.
- •Основные эксплуатационные требования к программным продуктам. Предпроектные исследования предметной области. Разработка технического задания.
- •Анализ требований и определенной спецификаций программного обеспечения ис при структурном подходе. Определение понятия «спецификация».
- •Создание формальной модели разрабатываемого по ис.
- •Классификация моделей разрабатываемого программного обеспечения, используемых на этапе определения спецификаций.
Проблемы разработки сложных программныхсистем.
Сайт. И Гради Буч(38).
Аннотация
Рассматривается понятие сложной программы и отличия сложных программ от простых.
Приводятся основные проблемы разработки сложных программ. В приложении к программной инженерии формулируются основные принципы работы со сложными системами, применимые к широкому кругу задач.
Ключевые слова
Сложное программное обеспечение, программная инженерия, компонентная разработка ПО, абстракция и уточнение, выделение модулей, разделение ответственности, переиспользование, адекватность интерфейса, полнота интерфейса, ортогональность интерфейса, простота интерфейса.
Брукс утверждает: "Сложность программного обеспечения является существенным,
а не случайным свойством" [3]. Это объясняется четырьмя причинами:
сложностью предметной области, трудностью управления разработкой программного
обеспечения, необходимостью обеспечить гибкость программ, а также сложностью
описания функционирования дискретных систем. Сложность предметной области: Пытаясь решить проблемы с помощью программного обеспечения, мы неизбежно
сталкиваемся с необходимостью удовлетворить множество различных, иногда
взаимоисключающих требований. Рассмотрим требования, предъявляемые к электронной системе многомоторного самолета, коммутатору сотового телефона и автономного робота. Механизмы функционирования таких систем уже сами по себе довольно сложны для понимания, а если прибавить к этому дополнительные требования (часто неявные), такие как удобство, производительность, стоимость, устойчивость и надежность, то сложность задачи может стать произвольной, о чем и предупреждал Брукс. Эта внешняя сложность обычно порождается "недопониманием", существующим между пользователями системы и ее разработчиками, поскольку пользователям очень трудно выразить свои потребности в форме, понятной разработчикам.
Трудности управления проектированием
Основная задача разработчиков программного обеспечения — создать иллюзию
простоты, чтобы защитить пользователей от огромной и часто произвольной
сложности проекта. Очевидно, что крупный масштаб системы программного
обеспечения не относится к ее основным достоинствам. Для уменьшения размеров
программ изобретаются хитроумные и мощные методы, создающие иллюзию
простоты и позволяющие повторно использовать существующие коды и проектные
решения.
Необходимость обеспечить гибкость программ
Строительные компании обычно не имеют собственного лесного хозяйства,
которое поставляло бы им лес для производства пиломатериалов, и не владеют
металлургическими заводами, изготавливающими стальные балки для будущих
зданий. Однако в программной индустрии такая практика получила широкое распространение. Программирование обладает предельной гибкостью и позволяет
проектировщику выражать абстракции любого уровня. Эта гибкость весьма привлекательна, поскольку она побуждает разработчика самостоятельно создавать
практически все базовые конструкции, из которых состоят абстракции более высоких
уровней.
Сложность описания дискретных систем
Внутри крупного приложения могут существовать сотни и даже тысячи переменных,
а также несколько потоков управления. Состояние прикладной программы
в каждый момент времени описывается совокупностью всех переменных, их
текущих значений, адресов и стеков вызова для каждого процесса. Так как программа
выполняется на цифровых компьютерах, возникает система с дискретными
состояниями. Аналоговые системы, такие как движение брошенного мяча, наоборот,
являются непрерывными. Парнас (Parnas) утверждает: "Когда мы говорим,
что система описывается непрерывной функцией, мы имеем в виду, что в ней нет
скрытых сюрпризов. Небольшие изменения входных параметров всегда вызывают
небольшие изменения результатов" [4]. С другой стороны, дискретные системы
имеют конечное число возможных состояний. В крупных системах наблюдается
так называемый комбинаторный взрыв, делающий это число очень большим.
Кратко: (с сайта)
Большинство современных программных систем объективно очень сложны. Эта сложность обуславливается многими причинами, главной из которых являетсялогическая сложность решаемых ими задач. Пока вычислительных установок было мало и ид. возможности были ограничены, ЭВМ применяли в очень узких областях науки и техники, причем, в первую очередь, там, где решаемые Задачи были хорошо детерминированы и требовали значительных вычислений. В наше время, когда созданы мощные компьютерные сети, появилась возможность переложить на них решение сложных ресурсоемких задач, о компьютеризации которых раньше никто я не думал. Сейчас в процесс компьютеризации вовлекаются совершенно новые предметные области, а для уже освоенных областей усложняются уже сложившиеся постановки задач. Дополнительными факторами, увеличивающими сложность разработки программных систем, являются [2]: • сложность формального определения требований к программным системам; • отсутствие удовлетворительных средств описания поведения дискретных систем с большим числом состояний при недетерминированной последовательности входных воздействий; • коллективная разработка; • необходимость увеличения степени повторяемости кодов.