Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Копия УП_РсПСиИТ.docx
Скачиваний:
33
Добавлен:
24.08.2019
Размер:
530.92 Кб
Скачать

6. Проектирование программного продукта

6.1. Общая характеристика и компоненты проектирования

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

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

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

Результаты проектирования представляются в виде описания компонент проектирования по определенному набору атрибутов.

6.2. Эволюция разработки программного продукта

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

На первых этапах развитие вычислительной техники было ори­ентировано на решение технических проблем. Предметом работ была прежде всего аппаратура, вычислительная машина как тако­вая. По мере того, как вычислительные машины становились все мощнее и надежнее, значение программного обеспечения осоз­навалось все большим числом ученых и практиков. Важнейший прорыв произошел в конце 1950-х годов, когда появились языки программирования высокого уровня – Fortran, Algol и др. Их по­явление было обусловлено прежде всего тем, что написание про­грамм без таких языков становилось все более сложной задачей. Решив текущие проблемы, эти языки создали новые. Ускорив и упростив программирование, они существенно расширили круг задач, решаемых с помощью ЭВМ. Появление новых задач, более сложных, чем решавшиеся раньше, привело к тому, что имеющихся средств снова стало недостаточно для успешного их ре­шения. В сложившейся ситуации усилия программистов были сосредо­точены прежде всего на создании новых языков программирова­ния. Появился язык Cobol, дающий возможность решать задачи обработки экономической информации. Он создавался таким образом, чтобы программа на нем выглядела почти как текст на английском языке. Появился язык PL/I, объединивший в себе все возможности, которые только могут иметь языки программиро­вания.

Языки Fortran, Algol, PL/I поддерживают процедурный стиль программирования. Программа разрабатывается в терминах тех действий, которые она выполняет. Основной единицей програм­мы является процедура. Процедуры вызывают другие процедуры для решения задачи. Появление перечисленных языков стало следствием круга задач, которые решались с помощью вычислительной техники. Применение ЭВМ для решения задач искусственного интеллекта и обработки текстов привело к созданию функциональных языков. В частности, языка Lisp. Эти языки имеют также хорошо проработанное математическое основание – лямбда-исчисление. В отличие от языков типа Algol, в которых действия в основном выражаются в виде итерации (повторения какого-либо фрагмента программы несколько раз), в языке Lisp вычисления произво­дятся с помощью рекурсии – вызова функцией самой себя, а основной структурой данных является список.

В 1960-е годы многие теоретики и практики осознали, что одно лишь создание новых, более совершенных языков програм­мирования не может решить все проблемы разработки программ. Начались интенсивные исследования в области тестирования про­грамм, организации процесса разработки программного обеспе­чения и др. Усилия преобразовать программирование из эмпирического процесса в процесс более упорядоченный, придать ему более «инженерный» характер привели к созданию методик программирования. Это был очень существенный шаг. Разработка методов построения программ с одной стороны создавала основу для массового про­мышленного программирования, а с другой, обобщая и анализируя текущее состояние программного обеспечения, дава­ла мощный импульс созданию новых языков программирования, операционных систем, сред программирования.

Одной из наиболее широко применяемых методик программи­рования стал структурный подход к программированию. Создате­лем его считается Э. Дейкстра. Фактически структур­ный подход к программированию – это первая законченная ме­тодика программирования.

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

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

1) прочитать адрес;

2) сверить адрес с базой имеющихся адресов;

3) если результат проверки положителен, напечатать «Да», в противном случае напечатать «Нет».

Такая запись один к одному отображается в программе на язы­ке высокого уровня, например, на Pascal или С.

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

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

Структурное программирование поддерживалось языками про­граммирования, появившимися в конце 1960-х годов (Pascal, Algol­8, Fortran и др.). Именно к тому времени было осознано значение программного обеспечения при решении задач с помощью вычис­тельной техники. Эти языки поддерживали разнообразные влож­енные процедуры, разные способы передачи параметров.

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

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

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

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

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

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

Объектно-ориентированный подход к программированию связывают прежде всего с языками программирования, такими как Smalltalk, С++, Java и т.д. Эта позиция имеет существенные основания. Поскольку языки являются главными инструментами объек­тно-ориентирсванного программирования, именно при их разра­ботке появилось большинство тех идей, которые и составляют основу объектно-ориентированного метода в настоящее время.

Накопление новых идей шло в течение примерно 10 лет, начи­ная с конца 1960-x годов. К концу 1970-х годов переход на новый уровень абстракции стал свершившимся фактом в академических кругах. Потребовалось еще около 10 лет, чтобы новые идеи про­никли в промышленность. Пожалуй, первым шагом на пути со­здания собственно объектной модели следует считать появление абстрактных типов данных. Первым на необходимость структуризации систем по уровням абстракции указал Э. Дейкстра. Идея инкапсуляции (скрытия ин­формации) была высказана Д. Парнасом. Позднее был разработан механизм абстрактных типов данных, который был дополнен в теории типов и подтипов.

Считается, что первой полной реализацией абстрактных типов данных в языках программирования является язык Simula, кото­рый, в свою очередь, опирается на языки Modula, CLU, Euc1id и др. Первым «настоящим» объектно-ориентированным языком программирования принято считать Smalltalk, разработанный в лаборатории компании «Ксерокс» в Паоло-Альто. Затем появились (и продолжают появ­ляться) другие объектно-ориентированные языки, которые оп­ределяют современное состояние программирования. Наиболее рас­пространенными из них стали С++, CLOS, Eiffel, Java.

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

Развитие вычислительной техники, в частности аппаратная поддержка основных концепций операционных систем и постро­ение функционально-ориентированных систем. При проектиро­вании вычислительных машин использование понятия объекта началось с исследований по нефоннеймановской архитектуре. Попытки сократить семантический разрыв между низкоуровне­вой архитектурой традиционных процессоров и высокоуровневы­ми понятиями операционных систем предпринимались при пост­роении таких систем, как Барроус, Intеl i432, IВM/38 и др. Тесно связанные с ними разработки объектно-ориентированных опера­ционных систем начались, пожалуй, с проекта ТНЕ под руковод­ством Э. Дейкстры, были продолжены в системах iMAX для Intеl i432 и др. Сравнительно недавние проекты Cairo Micгosoft и Taligent Рink (хотя и остановившиеся на исследовательском этапе) – это также проекты объектно-ориентированных операционных систем.

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

Следствием интенсивных исследований в области методов про­граммирования явилось появление большого числа средств автоматизации разработки программ, или САSЕ-средств (Computerided Software Еnginееring). Предполагалось, что после записи за­дачи на каком-либо высокоуровневом языке эти системы автома­тически (или хотя бы с минимальным участием человека) сгене­рируют готовую, правильно работающую программу, которая адек­ватно решит поставленную задачу.

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

Несмотря на провал при попытке достичь основной цели, опыт разработки CASE-средств сделал очень много для развития методов программирования. Небольшая часть систем используется напря­мую (например, генераторы компиляторов lex и уасс), часть идей была использована при создании современных средств быстрой разработки программ (RAD – Rapid Аpplicatiоn Development), таких как Builder, Delphi, Powerbuilder и др.

Приведенный исторический экскурс развития методологии программирования, совершенно не претендующий на полноту, иллюстрирует то, что все время программирование «боролось» за возможность решать все более сложные задачи, создавать все бо­лее сложные программные системы и делать это как можно быст­рее. Периодически то или иное достижение объявлялось панацеей (будь то структурное программирование, САSЕ-средства или что­ либо еще). Однако всегда оказывалось, что широко разреклами­рованное средство не способно решить все проблемы.