|
| |
 |
Главная » Мануалы 1 2 3 4 5 ... 32 Часть I Концептуальные основы системного проектирования в этой части книги дан постепенно детализируемый обзор языка Ада как средства проектирования систем. Подготовленный читатель (знакомый с языком Ада) может пропустить эту часть и перейти непосредственно к части II. Глава 1 Введение в проблему 1.1. Обоснование предлагаемого подхода В книге описывается подход к проектированию систем с использованием средств языка Ада - подход, который можно охарактеризовать как метод объектно-ориентированного структурного проектирования. Этот метод предоставляет в распоряжение разработчика средства для описания и проектирования систем в среде языка Ада с использованием концепции черного ящика и рисунков типа эскизов; такие рисунки понятны каждому и способствуют интуитивному пониманию физической сущности системы. Основным побудительным мотивом к разработке предлагаемого метода послужило твердое убеждение, что улучшение взаимопонимания между создателями систем и расширение возможностей отображения их интуитивных представлений должны привести в конечном счете к повышению качества конкретных проектов. Нам представляется правомерным утверждение, что одна доходчивая картинка говорит гораздо больше, чем тысячи строк какой-либо программы. Термин объект в данной книге относится к системной компоненте с характеристиками черного ящика. Другими словами, внутренняя организация этой компоненты неизвестна пользователю, который видит лишь спецификацию ее интерфейса. В соответствии с таким использованием термина объектами в языке Ада являются пакеты, задачи и процедуры. Понятия объектов в языке Ада и механизмов их взаимодействия представляют собой некие образы, позволяющие описывать систему как набор черных ящиков, закоммутированных кабелем, т. е. в виде аппаратных средств. Такое образное представление полезно и для удобства общения и для выбора интуитивных представлений. Данная глава посвящена главным образом обоснованию предлагаемого подхода и уточнению его роли в проектировании систем. В разд. 1.2 процесс проектирования рассматривается с позиций концепций жизненного цикла системы. Современные проблемы и перспективные направления развития методов проектирования и реализации систем, порожденные успехами тех-10логии ( технологическим взрывом ) и кризисом программного Йбеспечения, исследуются в разд. 1.3, а в разд. 1.4 резюмируются основные особенности предлагаемого подхода. Нетерпеливый читатель может без потери связности изложения пропустить разделы 1.2 и 1.3. 1.2. Проектирование системы и ее жизненный цикл в данной книге рассматриваются две стороны проектирования, связанные с получением ответа на вопрос как, а именно: 1) непосредственно процесс проектирования, т. е. методология создания проекта системы, 2) технические аспекты системного проектирования, иначе говоря, факторы, влияющие на структуру создаваемой системы. В контексте жизненного цикла системы проектирование является составной частью процесса разработки и развития системы в целом. Очень укрупненно фазы жизненного цикла системы можно представить следующим образом. 1. АНАЛИЗ В этой фазе анализируются конкретные практические потребности с целью определения возможности их удовлетворения. 2. ОПИСАНИЕ Эта фаза связана с выработкой внешних технических требований к системе. 3. ПРОЕКТИРОВАНИЕ Фаза, в которой разрабатывается проект всей системы в целом, включающий - интерфейс пользователя, - описание функций системы, - архитектурные принципы построения системы, - план испытаний, основанный на сформулированных технических требованиях к системе и общем ее проекте. 4. РЕАЛИЗАЦИЯ Фаза реализации системы состоит из этапов - конструирования отдельных модулей, - испытаний и отладки готовых модулей, - объединения модулей в подсистемы для окончательной компоновки системы. 5. ПОСТАВКА В этой фазе осуществляется передача системы заказчику с проведением - аттестации системы на основе плана испытаний, - приемо-сдаточных испытаний с участием заказчика. 6. ЭКСПЛУАТАЦИЯ И СОПРОВОЖДЕНИЕ Эта фаза охватывает процедуры внесения необходимых изменений для исправления ошибок и удовлетворения изменяющихся потребностей. Концепция жизненного цикла целостной системы рекурсивно связана с жизненными циклами, порождающими ее аппаратную и программную части. В данной книге рассматривается в основном разработка логической структуры системы как часть фазы системного проектирования. Остальные фазы жизненного цикла в явном виде не детализируются, однако на протяжении всей книги постоянно подчеркивается их влияние на процесс проектирования. В книге показывается, что процесс проектирования представляет собой совокупность неформальных процедур, поскольку невозможно, следуя некому рецепту, повернуть ту или иную ручку и получить готовый проект системы. Поэтому автор, отказавшись от попытки создания какой-либо формализованной методологии, сосредоточил внимание на изложении неформальных принципов реализации отдельных этапов системного проектирования, которъ1е иллюстрируются многочисленными примерами. В процессе проектирования логической структуры системы приходится иметь дело с целым рядом факторов технического характера, с тем чтобы обеспечить аккуратную разработку безошибочного проекта, удовлетворяющего всем системным требованиям. Этн факторы могут быть как качественными, так н количественными. Качественные аспекты проектирования включают модульность, гибкость и надежность системы. Количественные факторы связаны с описанием принципов функционирования системы сточки зрения обеспечиваемого времени реакции и производительности. Факторы, влияющие на надежность системы, рассматриваются как качественные. После введения такой классификации можно сказать, что особое значение в этой книге придается качественным техническим факторам проектирования систем. Особенность изложения материала заключается в разборе действия указанных факторов на конкретных примерах. 1.3. Некоторые замечания об аппаратных и программных средствах Исторически сложилось так, что две составные части любой системы-аппаратные и программные средства - имеют совершенно различные характеристики и всегда разрабатывались совсем непохожими методами. Наблюдаемый технологический взрыв в корне изменяет это положение дел. Внутренне присущая аппаратным средствам модульность навела специалистов по системам на мысль о новом подходе к созданию программных средств, которые в свою очередь позволяют проектировать и описывать и программы, и аппаратные средства с использованием программных методов. В этом смысле аппаратные и программные средства все более сближаются. В определенных сферах применения современные методы разработки программного обеспечения обещают подорвать авторитет исторически сложившейся концепции жизненного цикла. Более того, появление вездесущих персональных ЭВМ делает процесс разработки средств программного обеспечения доступным практически каждому. Цель этого раздела состоит в том, чтобы установить степень соответствия материала данной книги наблюдаемым тенденциям. 1.3.1. Аппаратные средства как источник идей для программных средств Представьте себе на мгновение счастливчика, разрабатывающего технические средства. Создаваемые им компоненты обладают изначально присущей им физической реальностью. Их можно с помощью кабелей и разъемов соединить в группы, подсистемы или системы с четко определенными характеристиками сопряжений (интерфейсов), что иллюстрирует рис. 1.1. Любой модуль, подсоединенный к другому с помощью кабеля и разъема, можно без ущерба для системы в целом отсоединить и заменить совместимым по разъему модулем с совершенно отличной внутренней структурой. Поскольку совместимость на уровне разъемов обеспечивает рост объемов производства компонентов систем, становится возможным принятие альтернативных решений о покупке отдельных модулей или изготовлении их собственными силами. Наконец, при исчезновении питания или блокировании функции, выполняемой конкретным модулем, в случае Рис. 1.1. Концептуальная модель ситемы в аппаратном представлении. Переключение черных ящиков путем блокирования функций системы, отключении ненуж -ного черного ящика и лодклкм чения нового  Г' Новый [ \ i черный ящик, I . совместимый ( I по разъему ( I--------£ аппаратных средств оказывается возможной их реконфигурация в процессе эксплуатации. Другая отличительная особенность аппаратных средств Типа тех, которые изображены на рис. 1.1,- это возможность параллельного функционирования двух и более модулей системы, причем любой модуль может сам состоять из параллельно работающих частей. Концепции совместимости на уровне разъемов и параллелизма настолько естественны в мире технических средств, что уже совершенно не допускают какого-либо иного образа мышления в этом плане. Однако в области программного обеспечения исторически ситуация сложилась по-другому. Получившие широкое распространение традиционные языки программирования не содержат ни средств обеспечения совместимости модулей, ни средств реализации параллелизма. До недавнего времени немногие языки, которые действительно обладали такими возможностями, либо не имели широкого распространения, либо не были доступны широкому кругу пользователей. Различные организации, осознавшие необходимость подобных функций, пытались нестандартными способами так расширить стандартные языки, чтобы они удовлетворяли указанным требованиям. В итоге широкое распространение получили нестандартные узкоспециализированные методы разработки программного обеспечения. В языке Ада, однако, идеи совместимости и параллелизма проводятся повсеместно и последовательно. В нем имеются средства для работы как с последовательными модулями (пакетами), так и с параллельными (задачами и содержащими их активными пакетами). Как пакеты, так и задачи снабжаются своего рода аналогами разъемов, причем каждому разъему соответствует отдельное описание. Изящная унифицированность средств языка Ада является следствием того факта, что при внешнем рассмотрении гнезда пакетов и задач очень схожи между собой. Благодаря этому облегчается описание системы, состоящей из взаимосвязанных модулей различных типов. Программа, написанная на языке Ада, почти в той же мере доступна для реконфигурации как и техническая система, в которой, прежде чем отключить старый модуль и подключить новый, необходимо либо отключить источник питания, либо заблокировать прежнюю функцию. Для подключения нового совместимого модуля необходимо, следуя терминологии языка Ада, разобрать программный комплекс на составляющие и отредактировать его заново. В этом смысле язык Ада не предоставляет универсальных средств реконфигурации, подобных тем, которые требуются для динамического подключения только что созданного модуля к уже функционирующей системе. По этой причине на языке Ада нельзя написать операционную систему общего назначения. Однако он прекрасно подходит для создания специализированных систем из набора существовавших ранее модулей. 1.3.2. Индустрия систем программного обеспечения: взгляд в будущее Язык Ада, позволяющий описывать системы в технических терминах, дает возможность представить себе предприятие по проидзодству систем, на котором как аппаратные, так и программные средства конструируются и описываются единообразно. В этих условиях программирование становится чем-то большим, нежели простое кодирование программных строк, и превращается в процесс структурированного построения систем, в рамках которого программы выстраиваются в структурные сборки из логических черных ящиков, закоммутированных логическими штекерами и кабелями. В таком виде программы могут соответствовать и аппаратным, и программным средствам, н только в теле тех модулей, которые относятся к программному обеспечению, они превращаются в кодированные строки. Рис, 1.2 иллюстрирует основанное на нашей концепции представление будущего предприятия по производству программного обеспечения. На рис. 1.3 показано, как с помощью языка типа Ады можно осуществлять программно-управляемое проектирование систем. Ключевым моментом такого подхода является концептуальное представление структуры системы, которое он обеспечивает руководителям, разработчикам, конструкторам, поставщикам, потребителям, торговым агентам и клиентам. Таким образом, и представители одной и той же группы спе-  КомпонентЬ[ ОТ поставщиков Рис. 1.2. Фабрика систем.
Постановка задачи на *1зыке Ада Проектирование и разработка аппарэтноп обеспечемир Техническое описание системь!, разработка модели и моделирование на языке Ада Принятие компромиссных решений относительно аппаратной и программной реализации Проектирование и разработка программного обеспеченин Компоновка системы Рабочее проектирование программного й аппаратного обеспечения ~ язык Ада используется как средство общения Автоматизированное Проектирование и изготовление аппаратных и програмадньис компонентов Рис. 1.3. Место языка Ада ь проектировании систем. циалистов, участвующих в разработке, и участники различных групп получают возможность обсуждать проект системы в одних и тех же терминах. Общее концептуальное представление используется как основа для обсуждения деталей проекта, графиков работ, потребностей в ресурсах и т. д. Однако вряд ли правомерно было бы ожидать от всех заинтересованных сторон одинаково свободного владения языком Ада. Поэтому от них требуется лишь умение пользоваться, графическими обозначениями основных деталей системного проекта, которые находились бы в прямом соответствии с элементами языка Ада. В других областях техники графические изображения компонентов системы называются ее эскизами. Основная цель данной книги-разработка графической нотации, которая послужила бы эквивалентом эскизного представления для программно-управляемого системного проектирования. Отметим в заключение, что описанная выше идея индустриального проектирования систем программного обеспечения предполагает прохождение всех фаз жизненного цикла. Это значит, что в соответствии с описанием жизненного цикла, приведенным в разд. 1.2, доллшы быть сформулированы все требования к системе еще до начала ее проектирования и реализации. Однако в некоторых прикладных областях уже зарождается новый подход к созданию программного обеспечения, идущий вразрез с концепцией жизненного цикла. Значение этих разработок и их связь с материалом данной книги обсуждаются в следующем подразделе. 1.3.3. Новые методы разработки программного обеспечения Одним из аспектов, так называемого кризиса программного обеспечения, являются практические трудности воплощения сформулированных технических требований в приемлемые системы без длительных подготовительных этапов и больших затрат, которые неизбежны при следовании концепции жизненного цикла, когда все существенные требования должны быть определены до того как заказчик сможет увидеть какие-то результаты. Широко используемые языки программирования, подобные языкам Паскаль и Ада, снабжаются трансляторами и ориентируются обычно на реализацию концепции жизненного цикла. В особенности это можно отнести к языку Ада, если учесть включенные в него средства разбиения системы на модули и отделение этапов описания модулей от их детальной реализации. Программные комплексы на языке Ада можно создавать только на основе подробных сведений о технических требовани- ЯХ К НИМ, причем любое изменение требований может нарушить их работоспособность. Однако в реальной жизни наивно ожидать четкого определения и согласования всех требований заказчика к сложной системе до тех пор, пока заказчик не увидит хотя бы частичное их воплошение. Причина этого кроется в неизбежном несовершенстве реально существующих организаций; люди бывают заняты, забывают некоторые подробности или вообще не интересуются ими; те, кому известны требования, не всегда участвуют в их определении, информация в процессе общения теряется. Различного рода оплошности, ошибки и упущения неизбежны, даже если приложить максимум усилий для их предотвращения. Вместе с тем программный комплекс на языке Ада, предназначенный для реализации некоторого требования, из-за упущенной детали может стать неприемлемым. Если же структура модуля, определенная в терминах типов данных, пакетов, задач, их интерфейсов и взаимодействий, становится неадекватной, то приходится модифицировать все модули или же поставлять систему, не отвечающую техническим требованиям. Очень желательно на ранних стадиях жизненного цикла системы возможно дольше воздерживаться от принятия таких проектных решений, которые в дальнейшем могли бы привести к необходимости крупных переделок в проекте. В идеале любые такие решения хорошо было бы отложить навсегда, предоставив заказчику возможность самому определять свои требования непосредственно в режиме удобного диалога с системой, ориентированной на удовлетворение потребностей пользователя.В некоторых прикладных сферах, например при поиске информации в базах данных, подобный подход постепенно становится все более и более реальным. В таких областях прикладные программы на языках высокого уровня не должны писаться прикладными программистами и затем транслироваться. Они конструируются высокоорганизованными программными средствами, входящими в состав интерфейса пользователя. Далее эти программы транслируются и выполняются в режиме интерпретации и в конечном итоге при необходимости модифицируются в процессе дальнейшего диалога пользователя с системой. В данном случае развитая возможность определения типов не требуется, поскольку природа объектов программирования может изменяться по мере эволюции самой системы. Такой подход можно определить как формулирование требований номере получения результатов, поскольку пользователь непосредственно видит результаты, к которым приводят его {требования, и имеет возможность уточнять их в интерактивном 24 Гмва 1 режиме для достижения необходимых целей. Этот подход называют также интерактивным макетированием. Метод, при котором требования формулируются по мере получения результатов, резко контрастирует с более традиционным подходом к разработке систем на основе концепции жизненного цикла, когда технические требования детально формулируются задолго до того, как удается увидеть результаты. Однако описываемый в данном разделе метод в принципе неприменим к задачам, которые не относятся к сфере автоматизации прикладного программирования. Такие задачи должны решаться в основном с ориентацией на концепцию жизненного цикла. Таким образом, использование языка Ада для описания и проектирования систем не накладывает никаких дополнительных ограничений на гибкость проектных решений по сравнению с органически присущими любому реальному проекту, выполненному на основе концепции жизненного цикла. Однако, каким бы ни был язык проектирования и реализации системы, изменения, вносимые в интерфейсы подсистем на последующих этапах проектирования, могут оказывать влияние на все подсистемы. При этом программирование или конструирование подсистем заново будет определять лишь часть общих затрат, вызванных подобным изменением в большом проекте. 1.3.4. Кустарное и промышленное производство программного обеспечения Вездесущие персональные ЭВМ делают процесс разработки программного обеспечения доступным практически каладому. Повсеместно начинает развиваться кустарное производство программных средств: пользователи, не являющиеся специалистами в области вычислительной техники, создают на своих персональных ЭВМ (зачастую весьма успешно) прикладное программное обеспечение для собственных нужд или даже на продажу. Такие люди обычно не склонны считать проектирование программ чем-то серьезным. Подобным образом ведут себя студенты, успешно освоившие несколько вводных курсов по программированию и уверенные, что они теперь с успехом смогут выполнять любую программистскую работу. Такое отношение довольно естественно, поскольку программирование может даТь само по себе впечатляющие результаты при сравнительно небольших затратах умственного труда на технологию программирования как таковую; достаточно изучить лишь несколько синтаксических правил языка и системных команд. В конце концов, для того чтобы создавать работающие программы, нужно не так уж много знать о самих ЭВМ. На самом элементарном уровне программирование - такое же ремесло, как плот- 1 2 3 4 5 ... 32 |