Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
|
Версия шаблона |
1.1 |
|
Филиал |
Петропавловский филиал ИТ |
|
Вид работы |
Электронная письменная предзащита |
|
Название дисциплины |
Научно-исследовательская работа |
|
Тема |
Сопоставление и взаимосвязь структурного и объектно-ориентированного подходов к проектированию программного обеспечения распределенных информационных систем |
|
Фамилия выпускника |
Жанбекова |
|
Имя выпускника |
Алтынай |
|
Отчество выпускника |
Есенкельдиновна |
|
№ контракта |
1421111403521 |
Введение
1 Технологии создания программного обеспечения
1.1 Технология структурного программирования
1.2 Технология объектно-ориентированного программирования
1.3 Технология Rational Unified Process (IBM Rational Software)
1.4 Технология Oracle
1.5 Технология Borland
2 Методические основы технологий создания программного обеспечения
2.1 Визуальное моделирование
2.2 Методы структурного анализа и проектирования программного обеспечения
2.3 Методы объектно-ориентированного анализа и проектирования программного обеспечения
2.4 Методы моделирования бизнес-процессов и спецификации требований
2.5 Методы анализа и проектирования программного обеспечения
3 Структурное и объектно-ориентированное программирование в проектировании программного обеспечения распределенных информационных систем
3.1 Проектирование программного обеспечения распределенных информационных систем
3.2 Структурный подход к проектированию информационных систем
3.3 Проектирование информационных систем на основе объектно-ориентированного подхода
3.4 Сопоставление и взаимосвязь структурного и объектно-ориентированного подходов
3.5 Проблемы преподавания структурного и объектно-ориентированного программирования
Заключение
Глоссарий
Список использованных источников
Литература
Создание систем программного обеспечения - это сложная и трудоемкая работа, требующая высокой квалификации участвующих в ней специалистов. Однако создание таких систем выполняется на интуитивном уровне с применением неформализованных методов, основанных на искусстве, практическом опыте, экспертных оценках и дорогостоящих экспериментальных проверках качества функционирования программного обеспечения. По данным Института программной инженерии (Software Engineering Institute, SEI) в последние годы до 80% всего эксплуатируемого программного обеспечения разрабатывалось без использования какой-либо дисциплины проектирования, методом «code and fix» (кодирования и исправления ошибок).
В конце 60-х годов прошлого века в США было отмечено явление под названием «software crisis» (кризис программного обеспечения). Это выражалось в том, что большие проекты стали выполняться с отставанием от графика или с превышением сметы расходов, разработанный продукт не обладал требуемыми функциональными возможностями, производительность его была низка, качество получаемого программного обеспечения не устраивало потребителей.
Проблема исследования обусловлена противоречием между существующими подходами к обучению объектно-ориентированному программированию, требующему значительных временных затрат на освоение базовых знаний структурного программирования, не реализующими современные технологии разработки программных продуктов, и необходимостью реализации возможностей объектно-ориентированного программирования (без предварительного рассмотрения алгоритмических конструкций структурного языка).
Актуальность исследования определяется современными тенденциями проектирования программного обеспечения распределенных информационных систем со структурным и объектно-ориентированным подходом.
Цель исследования состоит в изучении взаимосвязи структурного и объектно-ориентированного подходов к проектированию программного обеспечения распределенных информационных систем.
Для достижения цели определены следующие задачи исследования:
1. Проведение анализа научно-технической литературы в аспекте структуры и содержания курсов, ориентированных на изучение объектно-ориентированного и структурного программирования.
2. Изучение теоретических основ структурного и объектно-ориентированного подходов, технологии создания программного обеспечения.
3. Ознакомление с методическими основами создания программного обеспечения.
4. Рассмотрение внедрения технологий создания программного обеспечения в организации для реализации выполнения пилотного проекта.
5. Обосновать сопоставление и взаимосвязь структурного и объектно-ориентированного подходов при создании программного обеспечения распределенных информационных систем.
Объект исследования - процесс обучения объектно-ориентированному программированию с предварительным рассмотрением алгоритмических конструкций структурного языка.
Предмет исследования - теоретические и методические подходы к обучению структурного и объектно-ориентированного программирования.
Гипотеза исследования - если методические подходы к обучению объектно-ориентированному программированию без предварительных знаний алгоритмических конструкций структурного языка реализуют принципы обучения объектно-ориентированному программированию, то они будут способствовать достижению творческого уровня обученности студентов объектно-ориентированному программированию.
Для решения поставленных задач использованы следующие методы исследования: анализ работ в области теоретической информатики, ресурсов сети Интернет по проблемам объектно-ориентированного программирования; наблюдение, выявление взаимосвязанности структурного и объектно-ориентированного программирования.
Научная и практическая значимость исследования – создание и использование систем эффективной разработки программного обеспечения является важной задачей, требующей своего решения в самых разных областях деятельности.
Аналитические исследования и обзоры, выполняемые в течение ряда последних лет ведущими зарубежными аналитиками, показывали не слишком обнадеживающие результаты. Результаты исследований, выполненных в 1995 году компанией Standish Group, которая проанализировала работу 364 американских корпораций и итоги выполнения более 23 тысяч проектов, связанных с разработкой программного обеспечения, выглядели следующим образом:
- только 16,2% завершились в срок, не превысили запланированный бюджет и реализовали все требуемые функции и возможности;
- 52,7% проектов завершились с опозданием, расходы превысили запланированный бюджет, требуемые функции не были реализованы в полном объеме;
- 31,1% проектов были аннулированы до завершения;
- для двух последних категорий проектов бюджет среднего проекта оказался превышенным на 89%, а срок выполнения - на 122%.
В 1998 году процентное соотношение трех перечисленных категорий проектов лишь немного изменилось в лучшую сторону (26%, 46% и 28% соответственно).
В последние годы процентное соотношение трех перечисленных категорий проектов также незначительно изменяется в лучшую сторону, однако, по оценкам ведущих аналитиков, это происходит в основном за счет снижения масштаба выполняемых проектов, а не за счет повышения управляемости и качества проектирования.
В числе причин возможных неудач, по мнению разработчиков, фигурируют:
нечеткая и неполная формулировка требований к программному обеспечению;
недостаточное вовлечение пользователей в работу над проектом;
отсутствие необходимых ресурсов;
неудовлетворительное планирование и отсутствие грамотного управления проектом;
частое изменение требований и спецификаций;
новизна и несовершенство используемой технологии;
недостаточная поддержка со стороны высшего руководства;
недостаточно высокая квалификация разработчиков, отсутствие необходимого опыта.
Объективная потребность контролировать процесс разработки сложных систем программного обеспечения, прогнозировать и гарантировать стоимость разработки, сроки и качество результатов привела в конце 60-х годов прошлого века к необходимости перехода от кустарных к индустриальным способам создания программного обеспечения и появлению совокупности инженерных методов и средств создания программного обеспечения, объединенных общим названием «программная инженерия» (software engineering). В основе программной инженерии лежит одна фундаментальная идея: проектирование программного обеспечения является формальным процессом, который можно изучать и совершенствовать. Освоение и правильное применение методов и средств создания программного обеспечения позволяет повысить его качество, обеспечить управляемость процесса проектирования программного обеспечения и увеличить срок его жизни. В то же время, попытки чрезмерной формализации процесса, а также прямого заимствования идей и методов из других областей инженерной деятельности (строительства, производства) привели к ряду серьезных проблем. После двух десятилетий напрасных ожиданий повышения продуктивности процессов создания программного обеспечения, возлагаемых на новые методы и технологии, специалисты в индустрии программного обеспечения пришли к пониманию, что фундаментальная проблема в этой области - неспособность эффективного управления проектами создания программного обеспечения. Невозможно достичь удовлетворительных результатов от применения даже самых совершенных технологий и инструментальных средств, если они применяются бессистемно, разработчики не обладают необходимой квалификацией для работы с ними, и сам проект выполняется и управляется хаотически, в режиме «тушения пожара». Бессистемное применение технологий создания программного обеспечения, в свою очередь, порождает разочарование в используемых методах и средствах (анализ мнений разработчиков показывает, что среди факторов, влияющих на эффективность создания программного обеспечения, используемым методам и средствам придается гораздо меньшее значение, чем квалификации и опыту разработчиков). Если в таких условиях отдельные проекты завершаются успешно, то этот успех достигается за счет героических усилий фанатично настроенного коллектива разработчиков. Постоянное повышение качества создаваемого программного обеспечения и снижение его стоимости может быть обеспечено только при условии достижения организацией необходимой технологической зрелости, создании эффективной инфраструктуры как в сфере разработки программного обеспечения, так и в управлении проектами. В соответствии с моделью SEI СММ (Capability Maturity Model), в хорошо подготовленной (зрелой) организации персонал обладает технологией и инструментарием оценки качества процессов создания программного обеспечения на протяжении всего жизненного цикла программного обеспечения и на уровне всей организации.
Одна из причин распространенности «хаотического» процесса создания программного обеспечения - стремление сэкономить на стадии разработки, не затрачивая времени и средств на обучение разработчиков и внедрение технологического процесса создания программного обеспечения. Эти затраты до недавнего времени были довольно значительными и составляли, по различным оценкам (в частности, Gartner Group), более $100 тыс. и около трех лет на внедрение развитой технологии создания программного обеспечения, охватывающей большинство процессов жизненного цикла программного обеспечения, в многочисленной команде разработчиков. Причина - в «тяжести» технологических процессов. «Тяжелый» процесс обладает следующими особенностями:
- необходимость документировать каждое действие разработчиков;
- множество рабочих продуктов (в первую очередь - документов), создаваемых в бюрократической атмосфере;
- отсутствие гибкости;
- детерминированность (долгосрочное детальное планирование и предсказуемость всех видов деятельности, а также распределение человеческих ресурсов на длительный срок), охватывающий большую часть проекта.
Альтернативой «тяжелому» процессу является адаптивный (гибкий) процесс, основанный на принципах «быстрой разработки программного обеспечения», интенсивно развиваемых в последнее десятилетие.
В начале 2001 года ряд ведущих специалистов в области программной инженерии (Алистер Коберн, Мартин Фаулер, Джим Хайсмит,Кент Бек и другие) сформировали группу под названием Agile Alliance. Слово agile (быстрый, ловкий, стремительный) отражало в целом их подход к разработке программного обеспечения, основанный на богатом опыте участия в разнообразных проектах в течение многих лет. Этот подход под названием «Быстрая разработка программного обеспечения» (Agile software development) базируется на четырех идеях, сформулированных ими в документе «Манифест быстрой разработки программного обеспечения» (Agile Alliance’s Manifesto) и заключающихся в следующем:
- индивидуумы и взаимодействия между ними ценятся выше процессов и инструментов;
- работающее программное обеспечение ценится выше всеобъемлющей документации;
- сотрудничество с заказчиками ценится выше формальных договоров;
- реагирование на изменения ценится выше строгого следования плану.
При таком подходе технология занимает в процессе создания программного обеспечения вполне определенное место. Она повышает эффективность деятельности разработчиков при наличии любых из следующих четырех условий:
- когда она позволяет людям легче выразить свои мысли;
- когда она выполняет задачи, невыполнимые вручную;
- когда она автоматизирует утомительные и подверженные ошибкам действия;
- когда она облегчает общение между людьми;
Технология не должна действовать против характера культурных ценностей и познавательной способности человека. При этом следует четко понимать: при всех достоинствах быстрой разработки программного обеспечения этот подход не является универсальным и применим только в проектах определенного класса. Для характеристики таких проектов Алистер Коберн ввел два параметра – критичность и масштаб. Критичность определяется последствиями, вызываемыми дефектами в программном обеспечении, ее уровень может иметь одно из четырех значений:
- C – дефекты вызывают потерю удобства;
- D – дефекты вызывают потерю возместимых средств (материальных или финансовых);
- E – дефекты вызывают потерю невозместимых средств;
- L – дефекты создают угрозу человеческой жизни.
Масштаб определяется количеством разработчиков, участвующих в проекте:
- от 1 до 6 человек – малый масштаб;
- от 6 до 20 человек – средний масштаб;
- свыше 20 человек – большой масштаб.
По оценке Коберна, быстрая разработка программного обеспечения применима только в проектах малого и среднего масштаба с низкой критичностью (C или D). Общие принципы оценки технологий в таких проектах заключаются в следующем:
- интерактивное общение лицом к лицу – это самый дешевый и быстрый способ обмена информацией;
- избыточная «тяжесть» технологии стоит дорого;
- более многочисленные команды требуют более «тяжелых» и формальных технологий;
- большая формальность подходит для проектов с большей критичностью;
- возрастание обратной связи и коммуникации сокращает потребность в промежуточных и конечных продуктах;
- дисциплина, умение и понимание противостоят процессу, формальности и документированию;
- потеря эффективности в некритических видах деятельности вполне допустима.
Одним из наиболее известных примеров практической реализации подхода быстрой разработки программного обеспечения является «Экстремальное программирование» (Extreme Programming - EP). Этот метод предназначен для небольших компактных команд, нацеленных на получение как можно более высокого качества и продуктивности, и достигает этого посредством насыщенной, неформальной коммуникации, придания на персональном уровне особого значения умению и навыкам, дисциплине и пониманию, сводя к минимуму все промежуточные рабочие продукты.
1.1 Технология структурного программирования
Структурный подход к программированию представляет собой как методологию, так и технологию создания программ. В свое время его внедрение обеспечило повышение производительности труда программистов при написании и отладке программ; получение программ, которые состоят из модулей и пригодны для сопровождения; создание программ коллективом разработчиков; окончание создания программы в заданный срок.
Структурное программирование - это подход, при котором для передачи управления в программе используются конструкции, допускающие последовательную, условную и итеративную передачи управления. Безусловная передача управления оператором goto запрещается. В результате каждая сложная команда в программе, являющаяся комбинацией последовательных, условных и циклических операторов, имеет только одну точку входа и выхода, что обеспечивает разбиение программы на относительно самостоятельные фрагменты.
Структурное программирование является результатом применения аппликативных методов к императивным программам. Для этого используются процедурно-ориентированные языки, в которых имеется возможность описания программы как совокупности процедур. Процедуры могут вызывать друг друга, и каждая из них может быть вызвана основной программой, которую также можно рассматривать как процедуру.
Структура программы – это искусственно выделенные программистом взаимодействующие части программы. Использование рациональной структуры устраняет проблему сложности разработки, делает программу понятной пользователям, повышает надежность работы программы при сокращении срока ее тестирования и сроков разработки.
Очень часто некоторую последовательность инструкций требуется повторить в разных местах программы. Для того чтобы программисту не приходилось тратить время и усилия на копирование этих инструкций, во многих языках программирования предусматриваются средства для организации подпрограмм. Программист получает возможность присвоить последовательности инструкций произвольное имя и использовать это имя в качестве сокращенной записи в тех местах, где встречается соответствующая последовательность инструкций. Итак, подпрограмма – это некоторая последовательность инструкций, которая может вызываться в нескольких местах программы. Подпрограммы принято называть процедурами и функциями.
Описание подпрограммы состоит из двух частей: заголовки и тела. Заголовок содержит идентификатор подпрограммы и переменные используемые в ней. Тело состоит из одной или нескольких инструкций. Идентификатор подпрограммы используется в качестве сокращенной записи в тех местах программы, где встречается соответствующая последовательность инструкций.
Процедуры и функции, называемые подпрограммами, являются одним из тех немногих фундаментальных инструментов в искусстве программирования, которые оказывают решающее влияние на стиль и качество работы программиста.
Процедура – это не только способ сокращения программного текста, но и, средство разложения программы на логически связанные, замкнутые элементы, определяющие ее структуру. Разложение программы на части существенно для понимания программы, особенно если программа сложная и тяжело обозрима из-за большой длины текста. Разложение на подпрограммы необходимо как для документирования, так и для верификации программы. Поэтому желательно оформлять последовательность инструкций в виде подпрограммы, даже если программа используется однократно и, следовательно, отсутствует мотив, связанный с сокращением текста программы.
Информация о переменных или об условия, которым должны удовлетворять аргументы, задается в заголовке процедуры. О полезности процедуры, в частности, о ее роли при структуризации программы, неоспоримо свидетельствуют еще два понятия в программировании. Вспомогательные или локальные переменные, используемые внутри процедуры, не имеют смысла за ее пределами. В программе существо проще разобраться, если явно указаны области действия таких переменных. Процедура выступает как естественная текстовая единица, с помощью которой ограничивается область существования локальных переменных.
Наиболее общая тактика программирования состоит в разложении процесса на отдельные действия:
- функционального описания на подфункции;
- соответствующие программы на отдельные инструкции.
На каждом таком шаге декомпозиции нужно удостовериться, что решения частных задач приводят к решению общей задачи, выбранная последовательность отдельных действий разумна и позволяет получить инструкции, в каком-либо смысле более близкие к языку, на котором будет реализована программа. Это требование исключает возможность прямолинейного продвижения от первоначальной постановки задачи к конечной программе, которая должна получиться в конечном итоге. Каждый этап декомпозиции сопровождается формулированием частных подпрограмм. В процессе этой работы может обнаружиться, что выбранная декомпозиция неудачна в том смысле хотя бы потому, что подпрограммы неудобно выражать с помощью имеющихся средств. В этом случае один или несколько предыдущих шагов декомпозиции следует пересмотреть заново.
Если видеть в поэтапной декомпозиции и одновременном развитии и детализации программы постепенное продвижение в глубь, то такой метод при решении задач можно охарактеризовать как нисходящий (сверху вниз). И наоборот, возможен такой подход к решению задачи, когда программист сначала изучает имеющиеся в его распоряжении вычислительную машину или язык программирования, затем собирает некоторые последовательности инструкций в элементарные процедуры, типичные для решаемой задачи. Затем элементарные процедуры используются на следующем уровне иерархии процедур. Такой метод перехода от примитивных машинных команд к требуемой реализации программы называется восходящим (снизу вверх).
На практике разработку программы никогда не удается провести строго в одном направлении – сверху вниз или снизу вверх. Однако при конструировании новых алгоритмов нисходящей метод обычно доминирует. С другой стороны, при адаптации программы к несколько измененным требованиям предпочтение зачастую отдается восходящему методу.
Оба метода позволяют разрабатывать программы, которым присуща структура – свойство, отличающее их от аморфных линейных последовательностей инструкций или команд машины. Важно, чтобы используемый язык в полной мере отражал эту структуру. Только тогда окончательный вид полученной программы позволит применить систематические методы верификации.
Если программа разбивается на подпрограммы, то для представления результатов и аргументов часто приходится вводить новые переменные и таким образом устанавливать связь между подпрограммами. Такие переменные следует вводить и описывать на том этапе разработки, на котором они потребовались. Более того, детализация описания процесса может сопровождаться детализацией описания структуры используемых переменных. Следовательно, в языке должны быть средства для отражения иерархической структуры данных. Что показывает, какую важную роль играет при пошаговой разработке программы понятие процедуры, локальности процедур и данных, структурирования данных.
Проектирование начинается с фиксации внешних спецификаций. На основании внешних спецификаций составляется описание внутреннего алгоритма программы, обязательно со структурой внутренних данных. Далее крупные функции разбиваются на подфункции до достижения подфункции размера модуля – подпрограммы языка программирования, к которым предъявляются особые дополнительные требования.
Фундаментальным понятием и функциональным элементом технологии структурного программирования является – модуль.
Модуль – это подпрограмма, но оформленная в соответствии со следующими правилами:
1. модуль должен иметь один вход и один выход и выполнять строго однозначную функцию, которая описывается простым распространенным предложением естественного (русского) языка или даже предложением без сказуемого;
2. модуль должен обеспечивать компиляцию, независимую от других модулей, с «забыванием» всех внутренних значений модулей;
3. модуль может вызывать другие модули по их именам;
4. хороший модуль не использует глобальные переменные для общения с другим модулем, так как потом трудно отыскать модуль, который портит данные. При использовании глобальных переменных, нужно четко комментировать те модули, которые только читают, и те модули, которые могут менять данные;
5. модуль кодируется только стандартными структурами и тщательно комментируется.
В понятие структуры программы включаются состав и описание связей всех модулей, которые реализуют самостоятельные функции программы и описание носителей данных, участвующих в обмене, как между отдельными подпрограммами, так и вводимые и выводимые с внешних устройств.
В случае сложной, большой программы необходимо овладеть специальными приемами получения рациональной структуры программы. Рациональная структура программы обеспечивает почти двукратное сокращение объема программирования и многократное сокращение объемов и сроков тестирования, следовательно, принципиально снижает затраты на разработку.
Подчиненность модулей удобно изображать схемой иерархии. Схема иерархии отражает только подчиненность подпрограмм, но не порядок их вызова или функционирование программы.
До составления схемы иерархии целесообразно составить внешние спецификации программы и составить функциональные описания программы вместе с описанием переменных – носителей данных. Особое внимание надо уделить иерархии типов структурированных данных и их комментированию. Декомпозиция программы на подпрограммы производится по принципу от общего к частному, более детальному. Процесс составления функционального описания и составления схемы иерархии является итерационным. Выбор наилучшего варианта является многокритериальным.
Структурный подход рекомендует соблюдать следующие принципы при создании программного продукта:
- модульность программ;
- структурное кодирование модулей программ;
- нисходящее проектирование рациональной иерархии модулей программ;
- нисходящая реализация программы с использованием заглушек;
- осуществление планирования на всех стадиях проекта;
- сквозной структурный контроль программных комплексов в целом и составляющих их модулей.
Модульность программ характеризуется тем, что вся программа состоит из модулей. Некоторые смысловые группы модулей сосредотачиваются в отдельных файлах. Например, в отдельных файлах (Unit) могут быть сосредоточены модули текстового редактора и модули иерархического меню.
Структурное кодирование модулей программ заключается в особом оформлении их текстов. У модуля должен быть легко различимый заголовок с комментарием, поясняющим функциональное назначение модуля. Имена переменных должны быть мнемоническими. Суть переменных и порядок размещения в них информации должны быть пояснены комментариями, код модуля закодирован с использованием типовых алгоритмических структур с использованием отступов.
Нисходящее проектирование рациональной иерархии модулей программ заключается в выделении первоначальных модулей самого верхнего уровня иерархии, а затем подчиненных модулей.
Нисходящая реализация программы состоит в первичной реализации группы модулей верхних уровней, которые называются ядром программы, и далее постепенно, в соответствии с планом, реализуются модули нижних уровней. Необходимые для линковки программы, недостающие модули имитируются заглушками.
Осуществление планирования на всех стадиях проекта позволяет первоначально спланировать как состав стадий, таки продолжительность всех этапов работ. Такое планирование позволяет завершить разработку в заданный срок при заданных затратах на разработку.
Сквозной структурный контроль заключается в соблюдении заранее намеченного плана тестирования, который охватывает период от разработки внешних спецификаций, далее внутренних спецификаций и их корректировку в периоде реализации вплоть до приемо-сдаточных испытаний. Составляющие программу модули тестируются как во время написания их кода, так и при автономном тестировании, инспекции их исходного кода, при тестировании сразу по подключении к ядру.
При структурном программировании программа в основном реализуется (собирается и тестируется) сверху вниз. Сначала из 20-30 модулей пишется ядро. Чтобы начать тестировать, недостающие модули нижних уровней заменяются заглушками. По окончании тестирования ядра, заглушки заменяются новыми готовыми модулями, но если программа еще не закончена, то для успешной ее линковки понадобятся все новые заглушки недостающих модулей. Затем проводится тестирование собранной части и т.д.
Заглушка – это макет модуля. Самая простая заглушка – это попрограмма или функция без действий. Более сложная заглушка может выводить сообщение о том, что отработал такой-то модуль. Еще более сложные заглушки могут выводить входную информацию в какой-нибудь файл отладки. Наконец, еще более сложные заглушки выдают на выход тестовую информацию, необходимую для проверки уже реализованных модулей. Написание заглушек – лишняя работа, но требуется искусство проектировщика, чтобы максимальное количество заглушек были простыми, а тестирование уже собранной части программы было бы полным.
Проектированию структуры программы предшествует разработка внешних функциональных описаний. Функциональные описания (алгоритмы выполнения программы) для достижения их восприятия должны быть декомпозированы от общего к частному. Также они должны включать описания форм представления и объема внутренних данных.
Для начала имеется первый вариант схемы иерархии, полученный путем простого членения функций программы на подфункции с указанием переменных, необходимых для размещения данных на разных шагах обработки. Скорее этот вариант не является оптимальным, и требуются проектные итерации для улучшения топологии схемы.
Каждый новый вариант сравнивается с предшествующим вариантом по описанным здесь критериям. Генерация вариантов прекращается при невозможности дальнейших улучшений.
Фонд критериев оптимальности схем иерархии является необходимым подспорьем при оптимизации схем иерархии и состоит из следующих критериев:
- полнота выполнения специфицированных функций;
- возможность быстрого и дешевого пополнения новыми, ранее не специфицированными функциями;
- обозримость для проектировщика составных частей программы;
- максимальная независимость по данным отдельных частей программы;
- возможность связывания программы с обширной многоуровневой схемой иерархии конкретным редактором связей (линковщиком). Если начинается работа над новой программой, то очень полезно выполнить на эВМ ее модель в виде пустых заглушек модулей, которые не содержат никаких действий;
- достаточность оперативной памяти. Здесь рассматриваются варианты с описанием особенно структурированных статических и динамических переменных на разных уровнях схемы иерархии. Проверка удовлетворения данного критерия осуществляется расчетами с некоторыми машинными экспериментами;
- оценка влияния топологии схемы иерархии на скорость выполнения программы при использовании оверлеев (динамической загрузки программы) и механизма подкачки страниц при разработке программы, которая целиком не может быть размещена в оперативной памяти;
- отсутствие разных модулей, выполняющих похожие действия. В идеале – один и тот же модуль вызывается на разных уровня схемы иерархии;
- достижение при реализации программы такого сетевого графика работы коллектива программистов, который обеспечивает равномерную загрузку коллектива по ключевым датам проекта;
- всемерно сокращение затрат на тестирование уже собранного ядра программы по ключевым датам сетевого графика реализации. Характеризуется простотой используемых заглушек и качеством тестирования по всем вычислительным маршрутам модулей. Достигается первичной реализацией сверху вниз модулей ввода и вывода программы с отсрочкой реализации остальных ветвей схемы иерархии. Обычно затраты на тестирование составляют около 60% стоимости всего проекта. Хорошая схема иерархии сокращает затраты на тестирование по сравнению с первоначальным вариантом в 2-5 раз и более;
- использованием в данном проекте как можно большего числа разработанных в предшествующих проектах модулей и библиотек при минимальном объеме изготавливаемых заново частей;
- удачное распределение модулей по компилируемым файлам программы и библиотекам;
- накопление уже готовых модулей и библиотек модулей для использования их во всех новых разработках.
В заключении можно отметить что, структурный подход к программированию воспринял и использует многие методы из области проектирования сложных технических систем. Среди них блочно-иерархический подход к проектированию сложных систем, стадийность создания программ, нисходящее проектирование, методы оценки и планирования.
1.2 Технология объектно-ориентированного программирования
По мере развития вычислительной техники создавались новые подходы, помогающие справляться с растущим усложнением программ. Использование структурного программирования при написании умеренно сложных программ принесло свои результаты, однако оказалось несамостоятельным тогда, когда программа достигала определенной длины. Чтобы писать более сложные программы, были разработаны принципы объектно-ориентированного программирования. Объектно-ориентированное программирование – это подход к разработке программного обеспечения, основанный на объектах, а не на процедурах. Этот подход позволяет максимизировать принципы модульности и «сокрытия информации». Объектно-ориентированное программирование базируется на связывании или инкапсуляции структур данных и процедуры, которая работает с данными в структуре, с модулем.
Объектно-ориентированное программирование позволяет разложить проблему на составные части. В этом случае вся процедура упрощается, и появляется возможность оперировать с гораздо более объемными программами. Каждая составляющая становится самостоятельным объектом, содержащим свои собственные коды и данные, относящиеся к нему.
Объект – это замкнутая независимая сущность, взаимодействующая с внешним миром через строго определенный интерфейс в виде принимаемых сообщений. Объекты обладают определенным набором свойств, методов и способностью реагировать на события (нажатие кнопок мыши, интервалы времени и т.д.). в отличие от процедурного программирования, где порядок выполнения операторов программы определяется порядком их следования и командами управления в объектно-ориентированном программировании порядок выполнения процедур и функций определяется событиями. Объекты с одинаковыми свойствами и поведением объединяются в классы. Программа на объектно-ориентированном языке представляет собой совокупность описаний классов. Классы в свою очередь, представляют собой описания свойств и поведения составляющих их объектов. Свойства представляются другими, более простыми объектами. Поведение описывается обменивающимися сообщениями объектов.
В применении к объектно-ориентированным языкам программирования понятие объекта и класса конкретизируется следующими понятиями:
- объект – обладающий именем набора данных (полей объекта), физически находящихся в памяти компьютера, и методов, имеющих доступ к ним. Имя используется для доступа к полям и методам, составляющим объект. В предельных случаях объект может не содержать полей и методов, а также не иметь имени;
- любой объект относится к определенному классу. Класс содержит описание данных и операций над ними. В классе дается обобщенное описание некоторого набора родственных, реально существующих объектов. Объект- конкретный экземпляр класса.
Объектно-ориентированное программирование основано на следующих принципах:
- абстрагирования данных;
- инкапсуляции;
- наследования;
- полиморфизма;
- «позднего связывания».
Абстрагирование является одним из основных методов, используемых для решения сложных задач. Хоар считает, что «абстрагирование проявляется в нахождении сходств между определенными объектами, ситуациями или процессами реального мира, и в принятии решений на основе этих сходств, отвлекаясь на время от имеющихся различий» [42]. Шоу определила это понятие так: «Упрощенное описание или изложение системы, при котором одни свойства и детали выделяются, а другие опускаются. Хорошей является такая абстракция, которая подчеркивает детали, существенные для рассмотрения и использования, и отпускает те, которые на данный момент несущественны» [43]. Берзинс, Грей и Науман рекомендовали, чтобы «идея квалифицировалась как абстракция только, если она может быть изложена, понята и проанализирована независимо от механизма, который будет в дальнейшем принят для ее реализации» [44]. Суммирую эти разные точки зрения, получается следующее определение абстракции: Абстракция выделяет существенные характеристики некоторого объекта, отличающие его от всех других видов объектов и, таким образом, четко определяет его концептуальные границы с точки зрения наблюдателя.
Инкапсуляция (encapsulation) – это принцип, объединяющий данные и код, манипулирующий этими данными, а также защищающий в первую очередь данные от прямого внешнего доступа и неправильного использования. Другими словами, доступ к данным класса возможен только посредством методов этого же класса.
Наследование (inheritance) – это процесс, посредством которого один объект может приобретать свойства другого. То есть, объект может наследовать основные свойства другого объекта и добавлять к ним свойства и методы, характерные только для него.
Наследование делится на два вида:
1. одиночное наследование – класс (он же подкласс) имеет один и только один суперкласс (предок);
2. множественное наследование – класс может иметь любое количество предков (в Java запрещено).
Полиморфизм (polymorphism) – это механизм, использующий одно и то же имя метода для решения двух или более похожих, но несколько отличающихся задач.
Целью полиморфизма применительно к объектно-ориентированному программированию является использование одного имени для задания общих для класса действий. Концепцией полиморфизма является идея «один интерфейс, множество методов».
Механизм «позднего связывания» в процессе выполнения программы определяет принадлежность объекта конкретному классу и производит вызов метода, относящегося к классу, объект которого был использован.
Краеугольным камнем наследования и полиморфизма предстает следующая парадигма: «объект подкласса может использоваться всюду, где используется объект суперкласса».
При вызове метода класса он ищется в самом классе. Если метод существует, то он вызывается. Если же метод в текущем классе отсутствует, то обращение происходит к родительскому классу и вызываемый метод ищется у него. Если поиск неудачен, то он продолжается вверх по иерархическому дереву вплоть до корня (верхнего класса) иерархии.
Объектно-ориентированная технология основывается на так называемой объектной модели. Основными ее принципами являются, как уже отмечено выше: абстрагирование, инкапсуляция, модульность, иерархичность, типизация, параллелизм и сохраняемость. Каждый из этих принципов сам по себе нов, но в объектной модели они впервые применены в совокупности.
Объектно-ориентированный анализ и проектирование принципиально отличаются от традиционных подходов структурного проектирования: процесс декомпозиции представляется по другому, а архитектура получающегося программного продукта в значительной степени выходит за рамки представлений, традиционных для структурного программирования. Отличия обусловлены тем, что структурное проектирование основано на структурном программировании, тогда как в основе объектно-ориентированного программирования лежит методология объектно-ориентированного программирования.
Основываясь на истории развития программирования, можно отметить следующие две сменяющие друг друга тенденции:
- смещение акцентов от программирования отдельных деталей к программированию более крупных компонент;
- развитие и совершенствование языков программирования высокого уровня.
Большинство современных коммерческих программных систем больше и существенно сложнее, чем были их предшественники даже несколько лет тому назад. Этот рост сложности вызвал большое число прикладных исследований по методологии проектирования, особенно, по декомпозиции, абстрагированию и иерархиям. Создание более выразительных языков программирования пополнило достижения в этой области. Возникла тенденция перехода от языков, указывающих компьютеру, что делать (императивные языки). К языкам, описывающим ключевые абстракции проблемной области (декларативные языки).
Из огромного числа языков программирования, появившихся за период развития информационных технологий, лишь наиболее удобные и совершенные были приняты обществом разработчиков и отстояли свое право на существование. Анализируя языки программирования и обстоятельства, сопутствующие их появлению, можно обнаружить множество общих черт. Это позволяет сгруппировать языки по основным используемым принципам и выделить поколения в их развитии. Романова Ю.Д. приводит следующую классификацию:
1. Первое поколение (1954-1958):
- FORTRAN I – математические формулы;
- ALGOL -58 –математические формулы;
- FLOWMATIC - математические формулы;
- IPL V - математические формулы.
2. Второе поколение (1959-1961):
- FORTRAN II – подпрограммы, раздельная компиляция%
- ALGOL-60 – блочные структуры, типы данных;
- COBOL – описание данных, работа с файлами.
3. Третье поколение (1962-1970):
- PL/1 FORTRAN+ALGOL+COBOL;
- ALGOL-68 более строгий преемник ALGOL-60;
- PASCAL – более простой преемник ALGOL-60;
- SIMULA – классы, абстрактные данные.
Многие идеи, лежащие в основе современных языков программирования, появились в том или ином виде уже к 1970 году. Все последующие языки являются потомками или результатом обобщения и развития вышеперечисленных языков. Этому во многом способствовало как широкое распространение мини и микро ЭВМ и связанный с ним рост числа разработчиков программного обеспечения, так и многообразие операционных систем и различных сфер применения информационных технологий.
Первое поколение языков программирования были ограничены следующими особенностями:
- малым объемом оперативной памяти;
- несовершенством системы ввода-вывода.
Ввиду данных ограничений, а также малого количества и дороговизны этих машин, на них работали исключительно высококвалифицированные специалисты, способные управлять ими непосредственно на уровне двоичных кодов. Для облегчения процесса программирования вскоре были созданы языки первого поколения. Это были первые языки, которые приближали программирование к предметной области и отдаляли его от конкретной машины. Их словарь практически полностью был математическим.
Программы, реализованные на языках первого и начала второго поколение, имели относительно простую структуру, состоящую из подпрограмм и данных, лежащих в глобальной области видимости. Механизмы языков не поддерживали разделения разнотипных данных, что сильно осложняло написание больших программ.
На момент своего появления, подпрограммы расценивались лишь как средство облегчающее процесс написания программ. Будучи минимальными единицами пере использования, они стали «кирпичиками» для построения первых библиотек. Постепенно они стали играть фундаментальную роль в декомпозиции программных систем.
Выделение подпрограмм, как механизма абстрагирования, имело следующие важные последствия. Были разработаны различные механизмы передачи параметров. Были заложены основания для структурного программирования, что выражалось в появлении языковой поддержки механизмов вложенности подпрограмм и научной разработке структур управления и областей видимости. Возникли методы структурного проектирования, основой которых служило использование процедур или подпрограмм в качестве отдельных строительных блоков.
Первоначально языки программирования не имели достаточно развитых механизмов защиты данных одного модуля от использования их процедурами другого. Во многом эта задача ложилась на коллективы разработчиков. Появившиеся различные подходы в разработке программных систем благоприятствовали возникновению огромного количества языков, имеющих те или иные сильные и слабые стороны в реализации этих принципов. Одним из наиболее развитых представителей языков третьего поколения стал язык ALGOL-68. Будучи универсальным и реализуя почти все разработанные к тому времени механизмы в алгоритмических языках, он был достаточно труден для первоначального освоения, однако позволял разрабатывать системы корпоративного масштабы для больших ЭВМ.
Процедурно-ориентированные языки мало подходят для написания программных систем, где центральное место занимают данные, а не алгоритмы. С определенного момента возникла острая необходимость в языковой поддержке описания произвольных объектов окружающего мира. Вводятся абстрактные типы данных.
Первым языком, в котором нашли свое выражение идеи построения программ на основе данных и объектов стал язык Simula 67. Концепции, заложенные в языке Simula получили свое развитие в серии языков Smaltalk-72,-74,-76,-80, а также в языках C++ и Objective C. При внесении объектно-ориентированного подхода в язык Pascal появился язык Object Pascal. В 90-х годах компания Sun представила миру язык Java, как воплощение идеи платформенной независимости и наиболее полную реализацию концепций объектно-ориентированного программирования, положенных в основу языков Simula 67, Smalltalk, C++.
Объектно-ориентированные системы предъявляют повышенные требования к аппаратуре. Практика использования ТМООП на IBM PC/AT показала замедление скорости выполнения программ в 5-7 раз по сравнению с аналогичными программами на Си или Паскале. При этом время получения готовой программы сократилось в 2-3 раза, программы стали выглядеть яснее, лучше приспособлены для повторного использования. Далее рассматриваются примеры технологий создания программных обеспечений различных компаний-поставщиков.
1.3. Технология Rational Unified Process (IBM Rational Software)
Одна из наиболее совершенных технологий, претендующих на роль мирового корпоративного стандарта - Rational Unified Process (RUP). RUP представляет собой программный продукт, разработанный компанией Rational Software, которая в настоящее время входит в состав IBM.
RUP в значительной степени соответствует стандартам и нормативным документам, связанным с процессами жизненного цикла программного обеспечения и оценкой технологической зрелости организаций-разработчиков (ISO 12207, ISO 9000, CMM и др.). Ее основными принципами являются:
- Итерационный и инкрементный (наращиваемый) подход к созданию программного обеспечения.
- Планирование и управление проектом на основе функциональных требований к системе - вариантов использования.
Первый принцип является определяющим. В соответствии с ним разработка системы выполняется в виде нескольких краткосрочных мини-проектов фиксированной длительности (от 2 до 6 недель), называемых итерациями. Каждая итерация включает свои собственные этапы анализа требований, проектирования, реализации, тестирования, интеграции и завершается созданием работающей системы.
Итерационный цикл основывается на постоянном расширении и дополнении системы в процессе нескольких итераций с периодической обратной связью и адаптацией добавляемых модулей к существующему ядру системы. Система постоянно разрастается шаг за шагом, поэтому такой подход называют итерационным и инкрементным.
Общее представление RUP в двух измерениях представлено в приложении. (Приложение А) Горизонтальное измерение представляет время, отражает динамические аспекты процессов и оперирует такими понятиями, как стадии, итерации и контрольные точки. Вертикальное измерение отражает статические аспекты процессов и оперирует такими понятиями, как виды деятельности (технологические операции), рабочие продукты, исполнители и дисциплины (технологические процессы).
Согласно RUP, жизненный цикл программного обеспечения разбивается на отдельные циклы, в каждом из которых создается новое поколение продукта. Каждый цикл, в свою очередь, разбивается на следующие последовательные стадии:
- начальная стадия (inception);
- стадия разработки (elaboration);
- стадия конструирования (construction);
- стадия ввода в действие (transition).
Каждая стадия завершается в четко определенной контрольной точке (milestone). В этот момент времени должны достигаться важные результаты и приниматься критически важные решения о дальнейшей разработке.
Начальная стадия может принимать множество разных форм. Для крупных проектов начальная стадия может вылиться во всестороннее изучение всех возможностей реализации проекта, которое займет месяцы. Во время начальной стадии вырабатывается бизнес-план проекта - определяется, сколько приблизительно он будет стоить и какой доход принесет. Определяются также границы проекта, и выполняется некоторый начальный анализ для оценки размеров проекта.
Результатами начальной стадии являются:
- общее описание системы: основные требования к проекту, его характеристики и ограничения;
- начальная модель вариантов использования (степень готовности - 10-20%);
- начальный проектный глоссарий (словарь терминов);
- начальный бизнес-план;
- план проекта, отражающий стадии и итерации;
- один или несколько прототипов.
На стадии разработки выявляются более детальные требования к системе, выполняется высокоуровневый анализ предметной области и проектирование для построения базовой архитектуры системы, создается план конструирования и устраняются наиболее рискованные элементы проекта.
Результатами стадии разработки являются:
- модель вариантов использования (завершенная по крайней мере на 80%), определяющая функциональные требования к системе;
- перечень дополнительных требований, включая требования нефункционального характера и требования, не связанные с конкретными вариантами использования;
- описание базовой архитектуры будущей системы;
- работающий прототип;
- уточненный бизнес-план;
- план разработки всего проекта, отражающий итерации и критерии оценки для каждой итерации.
Самым важным результатом стадии разработки является описание базовой архитектуры будущей системы. Эта архитектура включает:
модель предметной области, которая отражает понимание бизнеса и служит отправным пунктом для формирования основных классов предметной области;
технологическую платформу, определяющую основные элементы технологии реализации системы и их взаимодействие.
Эта архитектура является основой всей дальнейшей разработки, она служит своего рода проектом для последующих стадий. В дальнейшем неизбежны незначительные изменения в деталях архитектуры, однако, серьезные изменения маловероятны.
Стадия разработки занимает около пятой части общей продолжительности проекта. Основными признаками завершения стадии разработки являются два события:
разработчики в состоянии оценить с достаточно высокой точностью, сколько времени потребуется на реализацию каждого варианта использования;
идентифицированы все наиболее серьезные риски, и степень понимания наиболее важных из них такова, что известно, как справиться с ними.
Сущность планирования заключается в определении последовательности итераций конструирования и вариантов использования, реализуемых на каждой итерации.
Итерации на стадии конструирования являются одновременно инкрементными и повторяющимися:
итерации являются инкрементными в соответствии с той функцией, которую они выполняют. Каждая итерация добавляет очередные конструкции к вариантам использования, реализованным во время предыдущих итераций;
итерации являются повторяющимися по отношению к разрабатываемому коду.
На каждой итерации некоторая часть существующего кода переписывается с целью сделать его более гибким.
Результатом стадии конструирования является продукт, готовый к передаче конечным пользователям. Он содержит следующие понятия:
программное обеспечение, интегрированное на требуемых платформах;
руководства пользователя;
описание текущей реализации.
Назначением стадии ввода в действие является передача готового продукта в распоряжение пользователей. Данная стадия включает:
бета-тестирование, позволяющее убедиться, что новая система соответствует ожиданиям пользователей;
параллельное функционирование с существующей (legacy) системой, которая подлежит постепенной замене;
конвертирование баз данных;
оптимизацию производительности;
обучение пользователей и специалистов службы сопровождения.
Статический аспект RUP представлен следующими основными элементами:
роли;
виды деятельности;
рабочие продукты;
дисциплины.
Понятие «роль» (role) определяет поведение и ответственность личности или группы личностей, составляющих проектную команду. Одна личность может играть в проекте много различных ролей.
Под видом деятельности конкретного исполнителя понимается единица выполняемой им работы. Вид деятельности (activity) соответствует понятию технологической операции. Он имеет четко определенную цель, обычно выражаемую в терминах получения или модификации некоторых рабочих продуктов (artifacts), таких, как модель, элемент модели, документ, исходный код или план. Каждый вид деятельности связан с конкретной ролью. Продолжительность вида деятельности составляет от нескольких часов до нескольких дней, он обычно выполняется одним исполнителем и порождает только один или весьма небольшое количество рабочих продуктов. Любой вид деятельности должен являться элементом процесса планирования. Примерами видов деятельности могут быть планирование итерации, определение вариантов использования и действующих лиц, выполнение теста на производительность. Каждый вид деятельности сопровождается набором руководств (guidelines), представляющих собой методики выполнения технологических операций.
Дисциплина (discipline) соответствует понятию технологического процесса и представляет собой последовательность действий, приводящую к получению значимого результата.
В рамках RUP определены следующие основные дисциплины:
построение бизнес-моделей;
определение требований;
анализ и проектирование;
реализация;
тестирование;
oразвертывание;
и вспомогательные:
управление конфигурацией и изменениями;
управление проектом;
создание инфраструктуры.
RUP как продукт входит в состав комплекса Rational Suite, причем каждая из перечисленных выше дисциплин поддерживается определенным инструментальным средством комплекса.
Адаптация RUP к потребностям конкретной организации или проекта обеспечивается с помощью Rational Process Workbench (RPW) - специального набора инструментов и шаблонов для настройки и публикации Web-сайтов на основе RUP. RPW поддерживает три основные функции моделирования технологических процессов:
определение процесса;
описание процесса;
представление процесса.
Библиотека элементов процесса содержит текстовую информацию о каждом элементе в модели процесса, все текстовые страницы RUP, а RPW - необходимые шаблоны для создания новых страниц описания. RPW генерирует описание процессов, включающее текст и графику, в виде Web-сайта, соединяя модели процессов и библиотеку описаний в единое целое.
Одно из основных инструментальных средств комплекса Rational Rose [9] представляет собой семейство объектно-ориентированных CASE-средств и предназначено для автоматизации процессов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации. Rational Rose реализует процесс объектно-ориентированного анализа и проектирования программного обеспечения, описанный в RUP. В основе работы Rational Rose лежит построение диаграмм и спецификаций UML, определяющих архитектуру системы, ее статические и динамические аспекты. В составе Rational Rose можно выделить шесть основных структурных компонентов: репозиторий, графический интерфейс пользователя, средства просмотра проекта (браузер), средства контроля проекта, средства сбора статистики и генератор документов. К ним добавляются генераторы кодов для каждого поддерживаемого языка, состав которых меняется от версии к версии.
Репозиторий представляет собой базу данных проекта. Браузер обеспечивает «навигацию» по проекту, в том числе перемещение по иерархиям классов и подсистем, переключение от одного вида диаграмм к другому и т. д. Средства контроля и сбора статистики дают возможность находить и устранять ошибки по мере развития проекта, а не после завершения его описания. Генератор отчетов формирует тексты выходных документов на основе содержащейся в репозитории информации.
Средства автоматической генерации кода, используя информацию, содержащуюся в диаграммах классов и компонентов, формируют файлы описаний классов. Создаваемый таким образом скелет программы может быть уточнен путем прямого программирования на соответствующем языке (основные языки, поддерживаемые Rational Rose - С++ и Java).
В результате разработки проекта с помощью Rational Rose формируются следующие документы:
диаграммы UML, в совокупности представляющие собой модель разрабатываемой программной системы;
спецификации классов, объектов, атрибутов и операций;
заготовки текстов программ.
Тексты программ являются заготовками для последующей работы программистов. Состав информации, включаемой в программные файлы, определяется либо по умолчанию, либо по усмотрению пользователя. В дальнейшем эти исходные тексты развиваются программистами в полноценные программы.
1.4 Технология Oracle
Методическую основу технологических средств программного обеспечения корпорации Oracle (www.oracle.com) составляет метод Oracle (Oracle Method) - комплекс методов, охватывающий большинство процессов жизненного цикла программного обеспечения. В состав комплекса входят:
CDM (Custom Development Method) - разработка прикладного программного обеспечения;
PJM (Project Management Method) - управление проектом;
AIM (Application Implementation Method) - внедрение прикладного программного обеспечения;
BPR (Business Process Reengineering) - реинжиниринг бизнес-процессов;
OCM (Organizational Change Management) - управление изменениями, и др.
Метод CDM оформлен в виде консалтингового продукта CDM Advantage - библиотеки стандартов и руководств (включающего также PJM). Он представляет собой развитие достаточно давно созданного Oracle CASE-Method, известного по использованию CASE-средств фирмы Oracle и книгам Р. Баркера. CDM является методическим руководством по разработке прикладного программного обеспечения с использованием инструментального комплекса Oracle Developer Suite, а сам процесс проектирования и разработки тесно связан с Oracle Designer и Oracle Forms.
В соответствии с CDM жизненный цикл программного обеспечения формируется из определенных этапов (фаз) проекта и процессов, каждый из которых выполняется в течение нескольких этапов (Приложение Б):
стратегия (определение требований);
анализ (формулирование детальных требований к системе);
проектирование (преобразование требований в детальные спецификации системы);
реализация (написание и тестирование приложений);
внедрение (установка новой прикладной системы, подготовка к началу эксплуатации);
эксплуатация.
На этапе стратегии определяются цели создания системы, приоритеты и ограничения, разрабатывается системная архитектура и составляется план разработки. На этапе анализа строятся модель информационных потребностей (диаграмма «сущность-связь»), диаграмма функциональной иерархии (на основе функциональной декомпозиции системы), матрица перекрестных ссылок и диаграмма потоков данных.
На этапе проектирования разрабатывается подробная архитектура системы, проектируются схема реляционной БД и программные модули, устанавливаются перекрестные ссылки между компонентами системы для анализа их взаимного влияния и контроля за изменениями.
На этапе реализации создается БД, строятся прикладные системы, производится их тестирование, проверка качества и соответствия требованиям пользователей. Создается системная документация, материалы для обучения и руководства пользователей.
На этапах внедрения и эксплуатации анализируются производительность и целостность системы, выполняется поддержка и, при необходимости, модификация системы.
Процессы CDM выполняют следующие действия:
определение бизнес-требований, или постановка задачи (Business Requirements Definition);
исследование существующих систем (Existing Systems Examination). Выполнение этого процесса должно обеспечить понимание состояния существующего технического и программного обеспечения для планирования необходимых изменений;
определение технической архитектуры (Technical Architecture);
проектирование и реализация базы данных (Database Design and Build). Процесс предусматривает проектирование и реализацию реляционной базы данных, включая создание индексов и других объектов БД;
проектирование и реализация модулей (Module Design and Build). Этот процесс является основным в проекте. Он включает непосредственное проектирование приложения и создание кода прикладной программы;
конвертирование данных (Data Conversion). Цель этого процесса - преобразовывать, перенести и проверить согласованность и непротиворечивость данных, оставшихся в наследство от "старой" системы и необходимых для работы в новой системе;
документирование (Documentation);
тестирование (Testing);
обучение (Training);
внедрение, или переход к новой системе (Transition). Этот процесс включает решение задач установки, ввода новой системы в эксплуатацию, прекращения эксплуатации старых систем;
поддержка и сопровождение (Post-System Support).
Процессы состоят из последовательностей взаимосвязанных задач.
CDM предоставляет возможность выбрать требуемый подход к разработке. Это возможно, поскольку каждый процесс базируется на известных зависимостях между задачами одного типа и не зависит от того, на какие этапы будет разбит проект.
При определении подхода к разработке оценивается масштаб, степень сложности и критичность будущей системы. При этом учитываются стабильность требований, сложность и количество бизнес-правил, количество автоматически выполняемых функций, разнообразие и количество пользователей, степень взаимодействия с другими системами, критичность приложения для основного бизнес-процесса компании и целый ряд других.
В соответствии с этими факторами в CDM выделяются два основных подхода к разработке:
Классический подход (Classic). Этапы данного подхода представлены. (Приложение Б) Классический подход применяется для наиболее сложных и масштабных проектов, он предусматривает последовательный и детерминированный порядок выполнения задач. Для таких проектов характерно большое количество реализуемых бизнес-правил, распределенная архитектура, критичность приложения. Применение классического подхода также рекомендуется при нехватке опыта у разработчиков, неподготовленности пользователей, нечетко определенной задаче. Продолжительность таких проектов от 8 до 36 месяцев.
Подход быстрой разработки (Fast Track). Данный подход, в отличие от каскадного классического, является итерационным и основан на методе DSDM (Dynamic Systems Development Method). В этом подходе четыре этапа - стратегия, моделирование требований, проектирование и генерация системы и внедрение в эксплуатацию. Подход используется для реализации небольших и средних проектов с несложной архитектурой системы, гибкими сроками и четкой постановкой задач. Продолжительность проекта от 4 до 16 месяцев.
PJM - это определенная дисциплина ведения проекта, позволяющая гарантировать, что цели проекта, четко определенные в его начале, остаются в центре внимания на протяжении всего проекта. В основе PJM лежит метод, ориентированный на выполнение самостоятельных процессов (под процессом понимается набор связанных задач, выполнением которых достигается определенная цель проекта). Так же, как и CDM, метод руководства проектом представляется в виде четко определенной операционной схемы, в которой выделяются процессы, этапы, задачи, результаты решения задач и зависимости между задачами:
Управление проектом и предоставление отчетности (Control and Reporting). Этот процесс содержит задачи, в результате решения которых определяются границы проекта и подход к разработке, происходит управление изменениями и контролируется возможный риск;
Управление работой (Work Management). Процесс содержит задачи, помогающие контролировать работы, выполняемые в проекте;
Управление ресурсами (Resource Management). Здесь решаются задачи, связанные с обеспечением каждого этапа исполнителями;
Управление качеством (Quality Management). Процесс управления качеством гарантирует, что проект отвечает требованиям пользователя в течение всего процесса разработки;
Управление конфигурацией (Configuration Management).
Цикл решения задач PJM состоит из отдельных этапов. Количество этапов зависит от выбранного подхода к разработке. Задачи PJM распределяются внутри каждого процесса по трем группам - задачи планирования, управления и завершения, и по уровням - отнести задачу на уровень проекта или на уровень отдельного этапа.
По аналогии с CDM, в PJM предусмотрено широкое использование шаблонов разрабатываемых документов.
Комплекс Oracle Developer Suite содержит набор интегрированных средств разработки для быстрого создания приложений. Он включает средства моделирования, программирования на Java, разработки компонентов, бизнес-анализа и составления отчетов. Все эти средства используют общие ресурсы, что позволяет совместно работать над одним проектом группе разработчиков. Oracle Developer Suite интегрирован с Oracle Database и Oracle Application Server, образуя единую платформу для создания и установки приложений.
В Oracle Developer Suite встроена поддержка языка UML для разработки приложений на основе моделей. Модели хранятся в общем репозитории Oracle, который предназначен для поддержки больших коллективов разработчиков.
CASE-средство Oracle Designer является интегрированным средством, обеспечивающим в совокупности со средствами разработки приложений поддержку жизненного цикла программного обеспечения.
Oracle Designer представляет собой семейство методов и поддерживающих их программных продуктов. Базовый метод Oracle Designer (CDM) - структурный метод проектирования систем, охватывающий полностью все стадии жизненного цикла программного обеспечения. Версия Oracle Designer для объектно-реляционной СУБД Oracle содержит также расширение в виде средств объектного моделирования, базирующихся на стандарте UML.
Oracle Designer обеспечивает графический интерфейс при разработке различных моделей (диаграмм) предметной области. В процессе построения моделей информация о них заносится в репозиторий. В состав Oracle Designer входят следующие компоненты:
Repository Administrator - средства управления репозиторием (создание и удаление приложений, управление доступом к данным со стороны различных пользователей, экспорт и импорт данных);
Repository Object Navigator - средство доступа к репозиторию, обеспечивающее многооконный объектно-ориентированный интерфейс доступа ко всем элементам репозитория;
Process Modeler - средство анализа и моделирования бизнес-процессов;
Systems Modeler - набор средств построения функциональных и информационных моделей проектируемой системы, включающий средства для построения диаграмм "сущность-связь" (Entity-Relationship Diagrammer), диаграмм функциональных иерархий (Function Hierarchy Diagrammer), диаграмм потоков данных (Data Flow Diagrammer) и средство анализа и модификации связей объектов репозитория различных типов (Matrix Diagrammer);
Systems Designer - набор средств проектирования программного обеспечения, включающий средство построения структуры реляционной базы данных (Data Diagrammer), а также средства построения диаграмм, отображающих взаимодействие с данными, иерархию, структуру и логику приложений, реализуемую хранимыми процедурами на языке PL/SQL (Module Data Diagrammer, Module Structure Diagrammer и Module Logic Navigator);
Server Generator - генератор описаний объектов БД Oracle (таблиц, индексов, ключей, последовательностей и т.д.);
Forms Generator - генератор приложений для Oracle Forms. Генерируемые приложения включают в себя различные экранные формы, средства контроля данных, проверки ограничений целостности и автоматические подсказки;
Repository Reports - генератор стандартных отчетов, интегрированный с Oracle Reports.
Репозиторий Oracle Designer представляет собой хранилище всех проектных данных и может работать в многопользовательском режиме, обеспечивая параллельное обновление информации несколькими разработчиками. В процессе проектирования автоматически поддерживаются перекрестные ссылки между объектами словаря и могут генерироваться более 70 стандартных отчетов о моделируемой предметной области. Физическая среда хранения репозитория - база данных Oracle.
1.5 Технология Borland
Компания Borland (www.borland.com) в результате развития собственных разработок и приобретения целого ряда компаний представила интегрированный комплекс инструментальных средств, реализующих управление полным жизненным циклом приложений (Application Life Cycle Management, ALM). В соответствии с технологией Borland процесс создания программного обеспечения включает в себя пять основных этапов:
определение требований;
анализ и проектирование;
разработка;
тестирование и профилирование;
развертывание.
Выполнение всех этапов координируется процессом управления конфигурацией и изменениями.
Определение требований реализуется с помощью системы управления требованиями CaliberRM, которая стала частью семейства продуктов Borland в результате покупки компании Starbase. CaliberRM сохраняет требования в базе данных, документы с их описанием создаются с помощью встроенного механизма генерации документов MS Word на базе заданных шаблонов. Система обеспечивает экспорт данных в таблицы MS Access и импорт из MS Word. CaliberRM поддерживает различные методы визуализации зависимостей между требованиями, с помощью которых пользователь может ограничить область анализа, необходимого в случае изменения того или иного требования. Имеется модуль, который использует данные требования для оценки трудозатрат, рисков и расходов, связанных с реализацией требований.
Средство анализа и проектирования Together ControlCenter [8] разработано компанией TogetherSoft. В основе его применения лежит один из вариантов подхода «Быстрой разработки программного обеспечения» под названием Feature Driven Development (FDD) [18].
Together ControlCenter - интегрированная среда проектирования и разработки, поддерживающая визуальное моделирование на UML с последующим написанием приложений для платформ J2EE (Java) и .Net (С#, C++ и Visual Basic). Кроме базовой версии, имеется уменьшенный вариант системы для индивидуальных разработчиков и небольших групп (Together Solo), а также редакции для платформы IBM WebSphere и среды разработки Jbuilder.
В системе реализована технология LiveSource, которая обеспечивает синхронизацию между проектом приложения и изменениями - при внесении изменений в исходные тексты меняется модель программы, а при изменении модели надлежащим образом изменяется текст на языке программирования. Это исключает необходимость вручную модифицировать модель или переписывать код. Контроль версий осуществляется благодаря функциональной интеграции Together и системы StarTeam. Поддерживается также интеграция с системой управления конфигурацией Rational ClearCase.
Инструментальные средства тестирования появились в составе комплекса Borland в результате покупки компании Optimizeit. К ним относятся Optimizeit Suite 5, Optimizeit Profiler for .NET и Optimizeit ServerTrace. Первые две системы позволяют выявить потенциальные проблемы использования аппаратных ресурсов - памяти и процессорных мощностей на платформах J2EE и .Net соответственно. Интеграция Optimizeit Suite 5 в среду разработки Jbuilder, а Optimizeit Profiler - в C#Builder и Visual Basic .Net позволяет проводить контрольные испытания приложений по мере разработки и ликвидировать узкие места производительности. Система Optimizeit ServerTrace предназначена для управления производительностью серверных J2EE-приложений с точки зрения достижения заданного уровня обслуживания и сбора контрольных данных по виртуальным Java-машинам.
Сущность концепции ALM сосредоточена в системе управления конфигурацией и изменениями: именно она объединяет основные фазы жизненного цикла программного обеспечения. Такой системой является StarTeam, разработанная компанией Starbase. Она выполняет функции контроля версий, управления изменениями, отслеживания дефектов, управления требованиями (в интеграции с CaliberRM), управления потоком задач и управления проектом.
StarTeam совместима с интерфейсом Microsoft Source Code Control и интегрируется с любой системой разработки, которая поддерживает этот API. Кроме того, в системе реализованы средства интеграции со средствами разработки и моделирования Together, JBuilder, Delphi, C++Builder и C#Builder.
В технологии Borland выделяется три уровня интеграции. Функциональная (touch-point) интеграция позволяет обратиться из одной системы к функциям другой, выбрав соответствующий пункт меню. Например, интерфейс управления изменениями StarTeam непосредственно отображается в системах Together, C#Builder и Visual Studio .Net. Такая интеграция дает возможность разделять информацию между системами, но не обеспечивает единого рабочего пространства, вынуждает пользователя переключать окна и приводит к дублированию процессов управления структурой проекта. Встроенная (embedded)интеграция обеспечивает работу с одной системой непосредственно в среде другой. Например, не выходя из среды разработки Jbuilder, можно просматривать графики производительности, которые создает система Optimizeit. Самый высокий уровень интеграции -синергетический (synergistic), позволяющий сочетать функции двух различных продуктов незаметно для разработчиков. Для большинства продуктов Borland и других поставщиков синергетическая интеграция пока остается делом будущего, однако ее принципы уже начинают реализовываться.
2.1 Визуальное моделирование
На сегодняшний день одной из важнейших процедур в информационных технологиях является отображение данных. Зрение является наиболее активным органом чувств человека. Поэтому процедуры отображения информационных данных, преследуют цель как можно лучше представить информацию для визуального наблюдения и анализа.
С помощью графического режима представления данных проще анализировать любую информацию, кроме этого, появляется возможность изменять масштаб, проекцию, цвет и т.п. изображения.
Визуальное моделирование возникло как синтез визуализации других направлений.
Визуальное моделирование использует в своей основе изображения. Изображение обычно обладает большей информативностью (на 2-3 порядка больше чем текст) и меньшей степенью абстрактности, то есть является более гибким каналом, чем текст или цифра.
Поэтому в настоящее время возрастает роль изображения в современном коммуникативном процессе. Визуальное моделирование развивается, опираясь, прежде всего, на иконические знаки. Поэтому при создании систем визуального моделирования необходимо учитывать специфику этих процессов.
Визуальная модель как знаковая система первична по отношению к символическим знакам, в том числе и к печатному слову. Первоначально знак, обозначающий определенный предмет, представлял собой всего лишь изображение этого предмета и включал две функции: изображения и понятия (значения).
В процессе эволюции человечества и коммуникативных процессов понятие все более отделялось от изображения, что привело к письменным (символическим) знакам, которые с одной стороны абстрагировались от обозначаемых ими предметов, а затем преобразовались в специальные системы (алфавиты). В этих системах понятия объектов отображались словами, состоящими из знаков алфавита.
На этих принципах построено лингвистическое моделирование, цифровое моделирование, математическое моделирование, экономико-математическое моделирование, и другие виды, работающие с символическими знаками. Только картографическое моделирование сохранило в себе два первоначальных свойства: изображения и символа.
В современных условиях актуальна задача исследования комплексного взаимодействия различных знаковых систем в процессе визуального моделирования. Наиболее часто приходится сталкиваться с одномоментным использованием иконических знаков и вербальных элементов, при помощи которых и формируется визуальная модель.
Под моделью программного обеспечения в общем случае понимается формализованное описание системы программного обеспечения на определенном уровне абстракции. Каждая модель определяет конкретный аспект системы, использует набор диаграмм и документов заданного формата, а также отражает точку зрения и является объектом деятельности различных людей с конкретными интересами, ролями или задачами.
Графические (визуальные) модели представляют собой средства для визуализации, описания, проектирования и документирования архитектуры системы. Разработка модели системы программного обеспечения промышленного характера в такой же мере необходима, как и наличие проекта при строительстве большого здания. Хорошие модели являются основой взаимодействия участников проекта и гарантируют корректность архитектуры. Поскольку сложность систем повышается, важно располагать хорошими методами моделирования. Хотя имеется много других факторов, от которых зависит успех проекта, но наличие строгого стандарта языка моделирования является весьма существенным.
Состав моделей, используемых в каждом конкретном проекте, и степень их детальности в общем случае зависят от следующих факторов:
сложности проектируемой системы;
необходимой полноты ее описания;
знаний и навыков участников проекта;
времени, отведенного на проектирование.
Визуальное моделирование (visual modeling) является методом, применяемым в разработке программного обеспечения, который:
использует графовые модели для визуализации программного обеспечения;
предлагает моделировать программное обеспечение с разных точек зрения;
может применяться в разработки и эволюции программного обеспечения, а также в различных видах деятельности по его созданию.
Визуальные модели, как правило, не составляют «сплошных» спецификаций, подобно программам, но часто являются, скорее, фрагментами, формально не связанными друг с другом. Эти модели описывают отдельные аспекты программного обеспечения, которые нужно прояснить в определенной ситуации для той или иной категории лиц, участвующих в проекте или как-либо с ним связанных. В целом визуальное моделирование служит для повышения понимания решений проекта людьми - разными категориями задействованных в проекте специалистов (инженеров-электронщиков, менеджеров, заказчика и т. д.).
Визуальное моделирование может применяться как при разработке, так и при сопровождении программного обеспечения. При разработке - главным образом при проектировании и анализе системы, которые предшествуют непосредственному программированию. При сопровождении - когда новые разработчики изучают доставшееся им программное обеспечение. Визуальное моделирование может также использоваться в разных видах деятельности процесса разработки программного обеспечения: главным образом при анализе и проектировании, но также и при документировании, тестировании, разработке требований и т. д.
Визуальное моделирование применяется на практике с помощью методов, языков и соответствующих программных инструментов (Приложение В).
Средства, реализующие языки и методы визуального моделирования, бывают двух видов - универсальные и предметно-ориентированные.
Универсальные инструменты являются коробочными и многофункциональными пакетами, предназначенными для анализа и проектирования программного обеспечения, то есть без какой-либо специализированной ориентации. Как правило, сегодня такие пакеты строятся на базе языка UML и называются CASE-пакетами. Самыми известными CASE-пакетами являются IBM Rational Rose, Borland Together, Telelogic Tau, Microsoft Visio/UML Add-on. Эти средства поддерживают различные виды диаграмм, удобную среду их разработки с такими функциями, как печать и копирование диаграмм, различные способы редактирования графических символов, средства просмотра и поиска в визуальной модели, различные режимы отображения диаграмм и многое другое. Они также обеспечивают генерацию программного кода в разные целевые платформы программирования, версионный контроль визуальных моделей, часто являются кросс-платформенными (например, работают под управлением операционных систем Windows и Linux), обеспечивают интеграционные «мосты» с другими средствами разработки программного обеспечения, например, со средствами управления требованиями. Как правило, все современные CASE-пакеты имеют открытые программные интерфейсы и позволяют расширять свою базовую функциональность.
Термин CASE (Computer Aided Software Engineering) появился в индустрии разработки программного обеспечения в начале 1980-х годов. Довольно быстро он стал обозначать графические средства анализа и проектирования программного обеспечения, отражая надежды и упования создать на основе визуального моделирования универсальный процесс разработки программного обеспечения. Пик развития этих средств приходится на начало 1990-х годов, когда они стали использоваться на базе платформы IBM Mainframe для автоматизации бизнеса крупных компаний. CASE-системы предоставляли мощные средства генерации кода, являясь не только инструментами анализа и проектирования, но и средами разработки программного обеспечения. CASE-средства интегрировали многообразные и разрозненные средства разработки под Mainframe-платформой - инструменты разработки пользовательского интерфейса и баз данных, средства взаимодействия основного приложения с операционной системой и пр. Типичное крупное Mainframe-приложение состояло из тестов примерно на 3-5 разных языках программирования, для которых существовало (и активно использовалось в других приложениях) множество альтернативных вариаций. Одна из самых известных систем такого рода - ADW (Application Developing Workbench). В итоге было разработано много промышленных информационных систем с использованием этих CASE-средств, успешно работающих и по сей день. В результате данные CASE-системы до сих пор поддерживаются и развиваются, чтобы созданные на их основе информационные системы могли успешно функционировать и модернизироваться под современные бизнес-потребности. Почти все подобные CASE-системы и, в частности, ADWб, в настоящее время куплены компанией Computer Associates International.
С середины 1990-х годов, в связи с прекращением распространения Mainframe-платформ, развитие этих CASE-систем прекратилось, и стали появляться CASE-системы для персональных компьютеров. Современные CASE-пакеты не являются комплексными средами разработки, а заняли нишу средств анализа и проектирования, и в основном используются без средств кода генерации, а лишь как инструменты для построения проектных спецификаций.
Предметно-ориентированные (domain-specific) программные инструменты поддержки визуального моделирования предназначены для определенных областей разработки программного обеспечения и тоже могут быть коробочными, как, например, пакет WebRatio для моделирования web-приложений. Однако предметно-ориентированные инструменты могут создаваться и отдельными компаниями для своих собственных проектов, особенно в рамках линеек программных продуктов (product lines). Это особенно удобно, поскольку во-первых, такие средства могут хорошо решать задачи именно того процесса, той компании, для которых они создаются. А во-вторых, сейчас на рынке имеются развитые среды для разработки средств визуального моделирования, самые известные из которых - Microsoft Visio, Microsoft DSL Tools и Eclipse/GMF. Эти и другие пакеты делают задачу создания собственного графического редактора посильной для обычных, рядовых компаний-разработчиков.
2.2 Методы структурного анализа и проектирования программного обеспечения
В структурном анализе и проектировании используются различные модели, которые описывают следующие действия:
функциональную структуру системы;
последовательность выполняемых действий;
передачу информации между функциональными процессами;
отношения между данными.
Наиболее распространенными моделями первых трех групп являются:
функциональная модель SADT (Structured Analysis and Design Technique);
модель IDEF3;
DFD (Data Flow Diagrams) - диаграммы потоков данных.
Метод SADT [17] представляет собой совокупность правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями.
Метод SADT разработан Дугласом Россом (SoftTech, Inc.) в 1969 году для моделирования искусственных систем средней сложности. Данный метод успешно использовался в военных, промышленных и коммерческих организациях США для решения широкого круга задач, таких, как долгосрочное и стратегическое планирование, автоматизированное производство и проектирование, разработка программного обеспечения для оборонных систем, управление финансами и материально-техническим снабжением и др. Метод SADT поддерживается Министерством обороны США, которое было инициатором разработки семейства стандартов IDEF (Icam DEFinition), являющегося основной частью программы ICAM (интегрированная компьютеризация производства), проводимой по инициативе ВВС США. Метод SADT реализован в одном стандарте этого семейства - IDEF0, который был утвержден в качестве федерального стандарта США в 1993 г., его подробные спецификации можно найти на сайте http://www.idef.com.
Модели SADT (IDEF0) традиционно используются для моделирования организационных систем (бизнес-процессов). Следует отметить, что метод SADT успешно работает только при описании хорошо специфицированных и стандартизованных бизнес-процессов в зарубежных корпорациях, поэтому он и принят в США в качестве типового метода. Достоинствами применения моделей SADT для описания бизнес-процессов являются:
полнота описания бизнес-процесса (управление, информационные и материальные потоки, обратные связи);
жесткие требования метода, обеспечивающие получение моделей стандартного вида;
соответствие подхода к описанию процессов стандартам ISO 9000.
Метод моделирования IDEF3 [22], являющийся частью семейства стандартов IDEF, был разработан в конце 1980-х годов для закрытого проекта ВВС США. Этот метод предназначен для таких моделей процессов, в которых важно понять последовательность выполнения действий и взаимозависимости между ними. Хотя IDEF3 и не достиг статуса федерального стандарта США, он приобрел широкое распространение среди системных аналитиков как дополнение к методу функционального моделирования IDEF0 (модели IDEF3 могут использоваться для детализации функциональных блоков IDEF0, не имеющих диаграмм декомпозиции). Основой модели IDEF3 служит так называемый сценарий процесса, который выделяет последовательность действий и подпроцессов анализируемой системы.
Диаграммы потоков данных (Data Flow Diagrams - DFD) [6] представляют собой иерархию функциональных процессов, связанных потоками данных. Цель такого представления - продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.
Для построения DFD традиционно используются две различные нотации, соответствующие методам Йордона-ДеМарко и Гейна-Сэрсона. Эти нотации незначительно отличаются друг от друга графическим изображением символов. В соответствии с данными методами модель системы определяется как иерархия диаграмм потоков данных, описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи потребителю. Практически любой класс систем успешно моделируется при помощи DFD-ориентированных методов. Они с самого начала создавались как средство проектирования информационных систем (тогда как SADT - как средство моделирования систем вообще) и имеют более богатый набор элементов, адекватно отражающих специфику таких систем (например, хранилища данных являются прообразами файлов или баз данных, внешние сущности отражают взаимодействие моделируемой системы с внешним миром).
С другой стороны, эти разновидности средств структурного анализа примерно одинаковы с точки зрения возможностей изобразительных средств моделирования. При этом одним из основных критериев выбора того или иного метода является степень владения им со стороны консультанта или аналитика, грамотность выражения своих мыслей на языке моделирования. В противном случае в моделях, построенных с использованием любого метода, будет невозможно разобраться.
Наиболее распространенным средством моделирования данных (предметной области) является модель «сущность-связь» (Entity-Relationship Model - ERМ) [12]. Она была впервые введена Питером Ченом в 1976 г. Эта модель традиционно используется в структурном анализе и проектировании, однако, по существу, представляет собой подмножество объектной модели предметной области. Одна из разновидностей модели «сущность-связь» используется в методе IDEF1Х, входящем в семейство стандартов IDEF и реализованном в ряде распространенных CASE-средств (в частности, AllFusion ERwin Data Modeler).
2.3. Методы объектно-ориентированного анализа и проектирования программного обеспечения
Методология объектно-ориентированного программирования пришла на смену процедурной или алгоритмической организации структуры программного кода, когда стало очевидно, что традиционные методы процедурного программирования не способны справиться ни с растущей сложностью программ и их разработки, ни с повышением их надежности. Во второй половине 80-х годов возникла настоятельная потребность в новой методологии программирования, которая бы позволила решить весь этот комплекс проблем. Такой методологией стало объектно-ориентированное программирование.
Концептуальной основой объектно-ориентированного анализа и проектирования программного обеспечения является объектная модель. Ее основные принципы (абстрагирование, инкапсуляция, модульность и иерархия) и понятия (объект, класс, атрибут, операция, интерфейс и др.) наиболее четко сформулированы Гради Бучем в его фундаментальной книге [2] и последующих работах.
Большинство современных методов объектно-ориентированного анализа и проектирования [5], [9], [14], [20] основаны на использовании языка UML. Унифицированный язык моделирования UML (Unified Modeling Language) [3], [19], [21] представляет собой язык для определения, представления, проектирования и документирования программных систем, организационно-экономических систем, технических систем и других систем различной природы. UML содержит стандартный набор диаграмм и нотаций самых разнообразных видов.
UML - это преемник того поколения методов объектно-ориентированного анализа и проектирования, которые появились в конце 1980-х и начале 1990-х годов. Создание UML фактически началось в конце 1994 г., когда Гради Буч и Джеймс Рамбо начали работу по объединению их методов Booch и OMT (Object Modeling Technique) под эгидой компании Rational Software. К концу 1995 г. они создали первую спецификацию объединенного метода, названного ими Unified Method, версия 0.8. Тогда же в 1995 году к ним присоединился создатель метода OOSE (Object-Oriented Software Engineering) Ивар Якобсон. Таким образом, UML является прямым объединением и унификацией методов Буча, Рамбо и Якобсона, однако дополняет их новыми возможностями. Главными в разработке UML были следующие цели:
предоставить пользователям готовый к использованию выразительный язык визуального моделирования, позволяющий им разрабатывать осмысленные модели и обмениваться ими;
предусмотреть механизмы расширяемости и специализации для расширения базовых концепций;
обеспечить независимость от конкретных языков программирования и процессов разработки;
обеспечить формальную основу для понимания этого языка моделирования (язык должен быть одновременно точным и доступным для понимания, без лишнего формализма);
стимулировать рост рынка объектно-ориентированных инструментальных средств;
интегрировать лучший практический опыт.
UML находится в процессе стандартизации, проводимом OMG (Object Management Group) - организацией по стандартизации в области объектно-ориентированных методов и технологий, в настоящее время принят в качестве стандартного языка моделирования и получил широкую поддержку в индустрии ПО. UML принят на вооружение практически всеми крупнейшими компаниями - производителями программного обеспечения (Microsoft, Oracle, IBM, Hewlett-Packard, Sybase и др.). Кроме того, практически все мировые производители CASE-средств, помимо IBM Rational Software, поддерживают UML в своих продуктах (Oracle Designer, Together Control Center (Borland), AllFusion Component Modeler (Computer Associates), Microsoft Visual Modeler и др.). Полное описание UML можно найти на сайтах http://www.omg.org и http://www.rational.com.
Стандарт UML версии 1.1, принятый OMG в 1997 году, содержит следующий набор диаграмм:
Структурные (structural) модели:
диаграммы классов (class diagrams) - для моделирования статической структуры классов системы и связей между ними;
диаграммы компонентов (component diagrams) - для моделирования иерархии компонентов (подсистем) системы;
диаграммы размещения (deployment diagrams) - для моделирования физической архитектуры системы.
Модели поведения (behavioral):
диаграммы вариантов использования (use case diagrams) - для моделирования функциональных требований к системе (в виде сценариев взаимодействия пользователей с системой);
диаграммы взаимодействия (interaction diagrams):
диаграммы последовательности (sequence diagrams) и кооперативные диаграммы (collaboration diagrams) - для моделирования процесса обмена сообщениями между объектами;
диаграммы состояний (statechart diagrams) - для моделирования поведения объектов системы при переходе из одного состояния в другое;
диаграммы деятельности (activity diagrams) - для моделирования поведения системы в рамках различных вариантов использования, или потоков управления.
Диаграммы вариантов использования показывают взаимодействия между вариантами использования и действующими лицами, отражая функциональные требования к системе с точки зрения пользователя. Цель построения диаграмм вариантов использования - это документирование функциональных требований в самом общем виде, поэтому они должны быть предельно простыми.
Вариант использования представляет собой последовательность действий (транзакций), выполняемых системой в ответ на событие, инициируемое некоторым внешним объектом (действующим лицом). Вариант использования описывает типичное взаимодействие между пользователем и системой и отражает представление о поведении системы с точки зрения пользователя. В простейшем случае вариант использования определяется в процессе обсуждения с пользователем тех функций, которые он хотел бы реализовать, или целей, которые он преследует по отношению к разрабатываемой системе.
Диаграмма вариантов использования является самым общим представлением функциональных требований к системе. Для последующего проектирования системы требуются более конкретные детали, которые описываются в документе, называемом «сценарием варианта использования» или «потоком событий» (flow of events). Сценарий подробно документирует процесс взаимодействия действующего лица с системой, реализуемого в рамках варианта использования [11]. Основной поток событий описывает нормальный ход событий (при отсутствии ошибок). Альтернативные потоки описывают отклонения от нормального хода событий (ошибочные ситуации) и их обработку.
Достоинства модели вариантов использования заключаются в том, что она:
определяет пользователей и границы системы;
определяет системный интерфейс;
удобна для общения пользователей с разработчиками;
используется для написания тестов;
является основой для написания пользовательской документации;
хорошо вписывается в любые методы проектирования (как объектно-ориентированные, так и структурные).
Диаграммы взаимодействия описывают поведение взаимодействующих групп объектов (в рамках варианта использования или некоторой операции класса). Как правило, диаграмма взаимодействия охватывает поведение объектов в рамках только одного потока событий варианта использования. На такой диаграмме отображается ряд объектов и те сообщения, которыми они обмениваются между собой. Существует два вида диаграмм взаимодействия: диаграммы последовательности и кооперативные диаграммы.
Диаграммы последовательности отражают временную последовательность событий, происходящих в рамках варианта использования, а кооперативные диаграммы концентрируют внимание на связях между объектами.
Диаграмма классов определяет типы классов системы и различного рода статические связи, которые существуют между ними. На диаграммах классов изображаются также атрибуты классов, операции классов и ограничения, которые накладываются на связи между классами. Вид и интерпретация диаграммы классов существенно зависит от точки зрения (уровня абстракции): классы могут представлять сущности предметной области (в процессе анализа) или элементы программной системы (в процессах проектирования и реализации).
Диаграммы состояний определяют все возможные состояния, в которых может находиться конкретный объект, а также процесс смены состояний объекта в результате наступления некоторых событий. Диаграммы состояний не надо создавать для каждого класса, они применяются только в сложных случаях. Если объект класса может существовать в нескольких состояниях и в каждом из них ведет себя по-разному, для него может потребоваться такая диаграмма.
Диаграммы деятельности, в отличие от большинства других средств UML, заимствуют идеи из нескольких различных методов, в частности, метода моделирования состояний SDL и сетей Петри. Эти диаграммы особенно полезны в описании поведения, включающего большое количество параллельных процессов. Диаграммы деятельности являются также полезными при параллельном программировании, поскольку можно графически изобразить все ветви и определить, когда их необходимо синхронизировать.
Диаграммы деятельности можно применять для описания потоков событий в вариантах использования. С помощью текстового описания можно достаточно подробно рассказать о потоке событий, но в сложных и запутанных потоках с множеством альтернативных ветвей будет трудно понять логику событий. Диаграммы деятельности предоставляют ту же информацию, что и текстовое описание потока событий, но в наглядной графической форме.
Диаграммы компонентов моделируют физический уровень системы. На них изображаются компоненты программного обеспечения и связи между ними. На такой диаграмме обычно выделяют два типа компонентов: исполняемые компоненты и библиотеки кода.
Каждый класс модели (или подсистема) преобразуется в компонент исходного кода. Между отдельными компонентами изображают зависимости, соответствующие зависимостям на этапе компиляции или выполнения программы.
Диаграммы компонентов применяются теми участниками проекта, кто отвечает за компиляцию и сборку системы. Они нужны там, где начинается генерация кода.
Диаграмма размещения отражает физические взаимосвязи между программными и аппаратными компонентами системы. Она является хорошим средством для того, чтобы показать размещение объектов и компонентов в распределенной системе.
Диаграмма размещения показывает физическое расположение сети и местонахождение в ней различных компонентов. Ее основными элементами являются узел (вычислительный ресурс) и соединение - канал взаимодействия узлов (сеть).
Диаграмма размещения используется менеджером проекта, пользователями, архитектором системы и эксплуатационным персоналом, чтобы понять физическое размещение системы и расположение ее отдельных подсистем.
UML обладает механизмами расширения, предназначенными для того, чтобы разработчики могли адаптировать язык моделирования к своим конкретным нуждам, не меняя при этом его метамодель. Наличие механизмов расширения принципиально отличает UML от таких средств моделирования, как IDEF0, IDEF1X, IDEF3, DFD и ERM. Перечисленные языки моделирования можно определить как сильно типизированные (по аналогии с языками программирования), поскольку они не допускают произвольной интерпретации семантики элементов моделей. UML, допуская такую интерпретацию (в основном за счет стереотипов), является слабо типизированным языком. К его механизмам расширения относятся:
стереотипы;
тегированные (именованные) значения;
ограничения.
Стереотип - это новый тип элемента модели, который определяется на основе уже существующего элемента. Стереотипы расширяют нотацию модели и могут применяться к любым элементам модели. Стереотипы классов - это механизм, позволяющий разделять классы на категории. Разработчики программного обеспечения могут создавать свои собственные наборы стереотипов, формируя тем самым специализированные подмножества UML (например, для описания бизнес-процессов, Web-приложений, баз данных и т.д.). Такие подмножества (наборы стереотипов) в стандарте языка UML носят название профилей языка.
Именованное значение – «тег = значение», или «имя = содержимое», в которых, хранится дополнительная информация о каком-либо элементе системы, например, время создания, статус разработки или тестирования, время окончания работы над ним и т.п.
Ограничение - это семантическое ограничение, имеющее вид текстового выражения на естественном или формальном языке (OCL - Object Constraint Language), которое невозможно выразить с помощью нотации UML.
2.4 Методы моделирования бизнес-процессов и спецификации требований
В 70-80-х годах началось массовое снижение конкурентоспособности американских бизнес-компаний. В частности, японские компании стали успешно конкурировать с американскими прямо на внутреннем рынке США. В связи с этим в начале 90-ъ годов появилась новая стратегия организации бизнеса, основанная на поддержке процессов. Вошли в обиход такие термины как бизнес-процесс (business process), реинжиниринг бизнеса (business reengineering), реинжиниринг бизнес-процессов (business process reengineering), моделирование бизнес-процессов (business process modeling).
До этого момента в бизнесе господствовала идея функционального разделения труда. Эту идею в конце 18-го века впервые сформулировал Адам Смит, на ее основе были созданы мануфактуры, которые в 19-м веке вытеснили ремесленные цеха и кустарное производство товаров. В начале 20-го века Генри Форд усовершенствовал эту идею и создал сборочный конвейер на своих автомобильных заводах, что позволило сильно увеличить производительность труда. Сейчас такие конвейеры существуют во многих отраслях промышленности. После этого Альфред Стоун, руководитель компании «Дженерал моторс», применил идею разделения труда к управлению крупным производством.
В начале 90-х годов Майкл Хаммер и Джеймс Чампли предложили иную форму организации бизнеса, ориентированную на процессы (бизнес-процессы). Бизнес-процесс – это цепочка действий от поступления заказа до полного завершения его обработки. Такой подход позволяет управлять и контролировать бизнес как деятельность, нацеленную на конечный результат. Иначе заказы и сервисы оказываются «размазанными» по функциональным отделам компании, у каждого из которых нет заинтересованности в конечном результате. В итоге падает качество сервисов, заказы обрабатываются не оптимально, с большими издержками.
Моделирование бизнес-процессов включает в себя тщательное продумывание новых правил бизнеса, а также формализацию. Основными характеристиками хорошей формализации являются:
1. формализация позволяет сделать наши мысли предметом широкого обсуждения;
2. формализация позволяет донести новые правила работы до тех сотрудников, которые должны будут их выполнять;
3. формализованные бизнес-процессы легче изменять и модернизировать;
4. формализация бизнес-процессов является хорошей основой для последующей автоматизации бизнеса в компании, то есть создания/настройки различных информационных систем, а также для настройки стандартных пакетов автоматизации.
Моделирование бизнес-процессов является важной составной частью проектов по созданию крупномасштабных систем программного обеспечения. Отсутствие таких моделей является одной из главных причин неудач многих проектов.
Назначением будущего программного обеспечения является, в первую очередь, решение проблем бизнеса. Требования к программному обеспечению формируются на основе бизнес-модели, а критерии проектирования систем прежде всего основываются на наиболее полном их удовлетворении.
Модели бизнес-процессов являются не просто промежуточным результатом, используемым консультантом для выработки каких-либо рекомендаций и заключений. Они представляют собой самостоятельный результат, имеющий большое практическое значение.
На сегодняшний день в моделировании бизнес-процессов преобладает процессный подход. Его основной принцип заключается в структурировании деятельности организации в соответствии с ее бизнес-процессами, а не организационно-штатной структурой. Модель, основанная на организационно-штатной структуре, может продемонстрировать лишь хаос, царящий в организации (о котором в принципе руководству и так известно, иначе оно бы не инициировало соответствующие работы), на ее основе можно только внести предложения об изменении этой структуры. С другой стороны, модель, основанная на бизнес-процессах, содержит в себе и организационно-штатную структуру предприятия.
Процессный подход может использовать любые из перечисленных выше средств моделирования. Однако, в настоящее время наблюдается тенденция интеграции разнообразных методов моделирования и анализа систем, проявляющаяся в форме создания интегрированных средств моделирования. Одним из таких средств является продукт, носящий название ARIS - Architecture of Integrated Information System, разработанный германской фирмой IDS Scheer [7].
Система ARIS представляет собой комплекс средств анализа и моделирования деятельности предприятия. Ее методическую основу составляет совокупность различных методов моделирования, отражающих разные взгляды на исследуемую систему. Одна и та же модель может разрабатываться с использованием нескольких методов, что позволяет использовать ARIS специалистам с различными теоретическими знаниями и настраивать его на работу с системами, имеющими свою специфику.
ARIS поддерживает четыре типа моделей, отражающих различные аспекты исследуемой системы:
организационные модели, представляющие структуру системы - иерархию организационных подразделений, должностей и конкретных лиц, связи между ними, а также территориальную привязку структурных подразделений;
функциональные модели, содержащие иерархию целей, стоящих перед аппаратом управления, с совокупностью деревьев функций, необходимых для достижения поставленных целей;
информационные модели, отражающие структуру информации, необходимой для реализации всей совокупности функций системы;
модели управления, представляющие комплексный взгляд на реализацию бизнес-процессов в рамках системы.
Для построения перечисленных типов моделей используются как собственные методы моделирования ARIS, так и различные известные методы и языки моделирования - ERM, UML, OMT и др.
В процессе моделирования каждый аспект деятельности предприятия сначала рассматривается отдельно, а после детальной проработки всех аспектов строится интегрированная модель, отражающая все связи между различными аспектами.
Модели в ARIS представляют собой диаграммы, элементами которых являются разнообразные объекты – «функция», «событие», «структурное подразделение», «документ» и т.п. Между объектами устанавливаются разнообразные связи. Каждому объекту соответствует определенный набор атрибутов, которые позволяют ввести дополнительную информацию о конкретном объекте. Значения атрибутов могут использоваться при имитационном моделировании или для проведения стоимостного анализа.
Основная бизнес-модель ARIS - eEPC (extended Event Driven Process Chain - расширенная модель цепочки процессов, управляемых событиями). По существу, она расширяет возможности IDEF0, IDEF3 и DFD, обладая всеми их достоинствами и недостатками. Применение большого числа различных объектов, связанных различными типами связей, может значительно увеличить размер модели и сделать ее плохо читаемой.
Бизнес-процесс в нотации eEPC представляет собой поток последовательно выполняемых работ (процедур, функций), расположенных в порядке их выполнения. Реальная длительность выполнения процедур в eEPC визуально не отражается. Это приводит к тому, что при создании моделей возможны ситуации, когда на одного исполнителя будет возложено выполнение двух задач одновременно. Используемые при построении модели символы логики позволяют отразить ветвление и слияние бизнес-процесса. Для получения информации о реальной длительности процессов необходимо использовать другие инструменты описания, например графики Ганта в системе MS Project.
Ряд современных методов моделирования бизнес-процессов основан на использовании языка UML. Хотя UML изначально предназначался для моделирования систем программного обеспечения, его использование в другой области стало возможным благодаря наличию в UML механизмов расширения (стереотипов).
Среди таких методов наиболее известными являются метод Ericsson-Penker и метод, реализованный в технологии Rational Unified Process (RUP).
Метод Ericsson-Penker [23] представляет интерес прежде всего в связи с попыткой применения UML в рамках процессного подхода к моделированию бизнес-процессов. Авторы метода создали свой профиль UML для моделирования бизнес-процессов, введя набор стереотипов, описывающих процессы, ресурсы, правила и цели деятельности организации. Метод использует четыре основные категории бизнес-модели:
Ресурсы - различные объекты, используемые или участвующие в бизнес-процессах (люди, материалы, информация или продукты).
Процессы - виды деятельности, изменяющие состояние ресурсов в соответствии с бизнес-правилами.
Цели - назначение бизнес-процессов Цели могут быть разбиты на подцели и соотнесены с отдельными процессами.
Бизнес-правила - условия или ограничения выполнения процессов (функциональные, поведенческие или структурные). Правила могут быть определены с использованием языка OCL.
Основной диаграммой UML, используемой в данном методе, является диаграмма деятельности. Метод Eriksson-Penker представляет процесс в виде деятельности со стереотипом "process" (основой данного представления является расширение метода IDEF0). Полная бизнес-модель включает множество представлений, подобных представлениям архитектуры программного обеспечения. Каждое представление выражено в одной или более диаграммах UML. Диаграммы могут иметь различные типы и изображать процессы, правила, цели и ресурсы во взаимодействиях друг с другом. Метод использует четыре различных представления бизнес-модели:
концептуальное представление - структура целей и проблем;
представление процессов - взаимодействие между процессами и ресурсами (в виде набора диаграмм деятельности);
структурное представление - структура организации и ресурсов (в виде диаграмм классов);
представление поведения - поведение отдельных ресурсов и детализация процессов (в виде диаграмм деятельности, состояний и взаимодействия).
Методика моделирования RUP [13] предусматривает построение двух моделей:
модели бизнес-процессов (Business Use Case Model);
модели бизнес-анализа (Business Analysis Model).
Модель бизнес-процессов представляет собой расширение модели вариантов использования UML за счет введения набора стереотипов - Business Actor (стереотип действующего лица) и Business Use Case (стереотип варианта использования). Business Actor (действующее лицо бизнес-процессов) - это некоторая роль, внешняя по отношению к бизнес-процессам организации. Business Use Case (вариант использования с точки зрения бизнес-процессов) определяется как описание последовательности действий (потока событий) в рамках некоторого бизнес-процесса, приносящей ощутимый результат конкретному действующему лицу. Это определение подобно общему определению бизнес-процесса, но имеет более точный смысл. В терминах объектной модели Business Use Case представляет собой класс, объектами которого являются конкретные потоки событий в рамках описываемого бизнес-процесса.
Описание Business Use Case может сопровождаться целью процесса, которая, так же, как и в методе Eriksson-Penker, моделируется с помощью класса со стереотипом «goal», а дерево целей изображается в виде диаграммы классов.
Для каждого Business Use Case строится модель бизнес-анализа - объектная модель, описывающая реализацию бизнес-процесса в терминах взаимодействующих объектов (бизнес-объектов - Business Object), принадлежащих к двум классам - Business Worker и Business Entity. Business Worker (исполнитель) - класс, представляющий собой абстракцию исполнителя, выполняющего некоторые действия в рамках бизнес-процесса. Исполнители взаимодействуют между собой и манипулируют различными сущностями, участвуя в реализациях сценариев Business Use Case. Business Entity (сущность) является объектом различных действий со стороны исполнителей.
Кроме диаграммы данных классов, модель бизнес-анализа может включать:
Диаграммы последовательности (и кооперативные диаграммы), описывающие сценарии Business Use Case в виде последовательности обмена сообщениями между объектами-действующими лицами и объектами-исполнителями. Такие диаграммы помогают явно определить в модели обязанности каждого исполнителя в виде набора его операций.
Диаграммы деятельности, описывающие взаимосвязи между сценариями одного или различных Business Use Case.
Диаграммы состояний, описывающие поведение отдельных бизнес-объектов.
Методика моделирования Rational Unified Process обладает следующими достоинствами:
модель бизнес-процессов строится вокруг участников процессов (заинтересованных лиц) и их целей, помогая выявить все потребности клиентов организации. Такой подход в наибольшей степени применим для организаций, работающих в сфере оказания услуг (торговые организации, банки, страховые компании и т.д.);
моделирование на основе вариантов использования способствует хорошему пониманию бизнес-модели со стороны заказчиков.
Однако следует отметить, что при моделировании деятельности крупной организации, занимающейся как производством продукции, так и оказанием услуг, необходимо применять различные методики моделирования, поскольку для моделирования производственных процессов более предпочтительным является процессный подход (например, метод Eriksson-Penker).
Спецификация требований к программному обеспечению является составной частью процесса управления требованиями [15]. Выявленные в результате применения перечисленных методов требования к программному обеспечению оформляются в виде ряда документов и моделей. Так, в технологии RUP функциональные требования к системе моделируются и документируются с помощью вариантов использовании. Стиль их написания зависит от масштаба, количества участников и критичности проекта.
Спецификация требований в RUP не требует обязательного моделирования бизнес-процессов организации, для которых создается ПО, однако, наличие бизнес-моделей существенно упрощает построение системной модели вариантов использования.
2.5 Методы анализа и проектирования программного обеспечения
Целью анализа требований является трансформация функциональных требований к программному обеспечению в предварительный системный проект и создание стабильной основы архитектуры системы. В процессе проектирования системный проект «погружается» в среду реализации с учетом всех нефункциональных требований.
Все современные технологии создания программного обеспечения реализуют ту или иную методику анализа и проектирования программного обеспечения. Одна из типичных методик ООП реализована в технологии RUP. Согласно этой методике, объектно-ориентированный анализ включает два вида деятельности: архитектурный анализ и анализ вариантов использования. Архитектурный анализ выполняется архитектором системы и включает в себя:
утверждение общих стандартов (соглашений) моделирования и документирования системы;
предварительное выявление архитектурных механизмов (надежности, безопасности и т.д.);
формирование набора основных абстракций предметной области (классов анализа);
формирование начального представления архитектурных уровней.
Анализ вариантов использования выполняется проектировщиками и включает в себя:
идентификацию классов, участвующих в реализации потоков событий варианта использования;
распределение поведения, реализуемого вариантом использования, между классами (определение обязанностей классов);
определение атрибутов и ассоциаций классов.
Сравнительный анализ данных методов структурного анализа проводится по следующим параметрам:
адекватность средств решаемым задачам;
согласованность с другими средствами структурного анализа;
интеграция с другими процессами жизненного цикла программного обспечения (прежде всего с процессом проектирования).
Адекватность средств решаемым задачам. Модели SADT (IDEF0) традиционно используются для моделирования организационных систем (бизнес-процессов). С другой стороны, не существует никаких принципиальных ограничений на использовании DFD в качестве средства моделирования бизнес-процессов. Следует отметить, что метод SADT успешно работает только при описании хорошо специфицированных и стандартизованных бизнес-процессов в зарубежных корпорациях, поэтому он и принят в CШA в качестве типового. Достоинствами применения моделей SADT для описания бизнес-процессов являются:
полнота описания бизнес-процесса (управление, информационные и материальные потоки, обратные связи);
комплексная декомпозиция; возможность агрегирования и детализации потоков данных и управления (разделение и слияние стрелок);
жесткие требования метода, обеспечивающие получение моделей стандартного вида;
соответствие подхода к описанию процессов стандартам ISO 9000.
В большинстве российских организаций бизнес-процессы начали формироваться и развиваться сравнительно недавно, они слабо типизированы, поэтому разумнее ориентироваться на модели, основанные на потоковых диаграммах. Кроме того, на практике у большинства моделей SADT отмечается ряд недостатков, в частности:
сложность восприятия (большое количество стрелок);
большое количество уровней декомпозиции;
трудность увязки нескольких процессов, представленных в различных моделях одной и той же организации.
Практически любой класс систем успешно моделируется при помощи DFD-ориентированных методов. SADT-диаграммы оказываются значительно менее выразительными и удобными при моделировании программного обеспечения. Так, дуги в SADT жестко типизированы (вход, выход, управление, механизм). В то же время применительно к программному обеспечению стирается смысловое различие между входами и выходами, с одной стороны, и управлениями и механизмами, с другой: входы, выходы и управления являются потоками данных и правилами их преобразования. Анализ системы при помощи потоков данных и процессов, их преобразующих, является более прозрачным и недвусмысленным.
В SADT вообще отсутствуют выразительные средства для моделирования особенностей ИС. DFD же с самого начала создавались как средство проектирования ИС (тогда как SADT — как средство моделирования систем вообще) и имеют более богатый набор элементов, адекватно отражающих специфику таких систем (например, хранилища данных являются прообразами файлов или баз данных, внешние сущности отражают взаимодействие моделируемой системы с внешним миром).
Наличие в DFD спецификаций процессов нижнего уровня позволяет преодолеть логическую незавершенность SADT (а именно, обрыв модели на некотором достаточно низком уровне, когда дальнейшая ее детализация становится бессмысленной) и построить полную функциональную спецификацию разрабатываемой системы.
Жесткие ограничения SADT, запрещающие использовать более 6—7 блоков на диафрагме, в ряде случаев вынуждают искусственно детализировать процесс, что затрудняет понимание модели заказчиком, резко увеличивает ее объем и, как следствие, ведет к неадекватности модели реальной предметной области. В качестве примера достаточно рассмотреть модель операции по снятию денег с вклада физического лица в банке. В настоящий момент существуют более тридцати типов таких вкладов. Для моделирования соответствующих операций целесообразно использовать единственную DFD, поскольку все без исключения операции имеют одни и те же входы (сберегательная книжка и расходный ордер) и выходы (сберегательная книжка и наличные деньги) и различаются лишь механизмами начисления процентов. Если же попытаться структурировать эти операции путем группирования по какому-либо признаку (срочные, пенсионные, размеры процентов и т.п.) в соответствии с ограничениями SADT, то получится как минимум 6 диаграмм (верхний уровень и округленная в большую сторону дробь 30/7), сложность каждой из которых не меньше сложности единственной диаграммы, моделирующей все операции.
Согласованность с другими средствами структурного анализа. Главным достоинством любых моделей является возможность их интеграции с моделями других типов. В данном случае речь идет о согласованности функциональных моделей со средствами моделирования данных. Согласование SADT-модели с ERM практически невозможно или носит искусственный характер. В свою очередь, DFD и ERM взаимно дополняют друг друга и являются согласованными, поскольку в DFD присутствует описание структур данных, непосредственно используемое для построения ERM.
Интеграция с другими процессами жизненного цикла программного обеспечения. Важная характеристика модели — ее совместимость с моделями, используемыми в последующих процессах (прежде всего в процессе проектирования).
DFD могут быть легко преобразованы в модели проектируемой системы. Известен ряд алгоритмов автоматического преобразования иерархии DFD в структурные карты различных видов, что обеспечивает логичный и безболезненный переход от формирования требований к проектированию системы. С другой стороны, формальные методы преобразования SADT-диаграмм в проектные решения отсутствуют.
Необходимо отметить, что рассмотренные разновидности средств структурного анализа примерно одинаковы с учетом возможностей изобразительных средств моделирования. При этом одним из основных критериев выбора того или иного метода является степень владения им со стороны консультанта или аналитика, грамотность выражения своих мыслей на языке моделирования. В противном случае в моделях, построенных с использованием любого метода, будет невозможно разобраться.
В потоках событий варианта использования выявляются классы трех типов:
Граничные классы (Boundary) - служат посредниками при взаимодействии внешних объектов с системой. Типы граничных классов: пользовательский интерфейс (обмен информацией с пользователем, без деталей интерфейса - кнопок, списков, окон), системный интерфейс и аппаратный интерфейс (используемые протоколы, без деталей их реализации).
Классы-сущности (Entity) - представляют собой основные абстракции (понятия) разрабатываемой системы, рассматриваемые в рамках конкретного варианта использования.
Управляющие классы (Control) - обеспечивают координацию поведения объектов в системе. Примеры управляющих классов: менеджер транзакций, координатор ресурсов, обработчик ошибок.
Классы анализа отражают функциональные требования к системе и моделируют объекты предметной области. Совокупность классов анализа представляет собой начальную концептуальную модель системы
Наиболее важной частью объектно-ориентированного анализа является распределение обязанностей между классами (в виде операций классов). Оно выполняется с помощью диаграмм взаимодействия. При построении диаграмм взаимодействия возникают проблемы правильного распределения обязанностей между классами. Для их решения существует ряд образцов [14].
Атрибуты классов анализа определяются, исходя из знаний о предметной области и требований к системе. Связи между классами (ассоциации) определяются на основе анализа кооперативных диаграмм, затем анализируются и уточняются.
Целью объектно-ориентированного проектирования является адаптация предварительного системного проекта (набора классов «анализа»), составляющего стабильную основу архитектуры системы, к среде реализации с учетом всех нефункциональных требований.
Объектно-ориентированное проектирование включает два вида деятельности:
проектирование архитектуры системы;
проектирование элементов системы.
Проектирование архитектуры системы выполняется архитектором системы и включает в себя:
идентификацию архитектурных решений и механизмов, необходимых для проектирования системы;
анализ взаимодействий между классами анализа, выявление подсистем и интерфейсов;
формирование архитектурных уровней;
проектирование конфигурации системы.
Проектирование элементов системы включает в себя:
проектирование классов (детализация классов, уточнение операций и атрибутов, моделирование состояний, уточнение связей между классами);
проектирование баз данных (в зависимости от типа используемой для хранения данных СУБД - объектной или реляционной).
3.1 Проектирование программного обеспечения распределенных информационных систем
Проектирование программного обеспечения информационных систем требует большой и трудоемкой работы. Современные крупные проекты информационных систем характеризуются, следующими особенностями:
сложность описания (достаточно большое количество функций, процессов, элементов данных и сложные взаимосвязи между ними), требующая тщательного моделирования и анализа данных и процессов;
наличие совокупности тесно взаимодействующих компонентов (подсистем), имеющих свои локальные задачи и цели функционирования (например, традиционных приложений, связанных с обработкой транзакций и решением регламентных задач, и приложений аналитической обработки (поддержки принятия решений), использующих нерегламентированные запросы к данным большого объема);
отсутствие прямых аналогов, ограничивающее возможность использования каких-либо типовых проектных решений и прикладных систем;
необходимость интеграции существующих и вновь разрабатываемых приложений;
функционирование в неоднородной среде на нескольких аппаратных платформах;
разобщенность и разнородность отдельных групп разработчиков по уровню квалификации и сложившимся традициям использования тех или иных инструментальных средств;
существенная временная протяженность проекта, обусловленная, с одной стороны, ограниченными возможностями коллектива разработчиков, и, с другой стороны, масштабами организации-заказчика и различной степенью готовности отдельных ее подразделений к внедрению ИС.
Для успешной реализации проекта объект проектирования должен быть прежде всего адекватно описан, должны быть построены полные и непротиворечивые функциональные и информационные модели информационной системы. Однако до недавнего времени проектирование информационных систем выполнялось в основном на интуитивном уровне с применением неформализованных методов, основанных на искусстве, практическом опыте, экспертных оценках и дорогостоящих экспериментальных проверках качества функционирования информационных систем. Кроме того, в процессе создания и функционирования информационных систем информационные потребности пользователей могут изменяться или уточняться, что еще более усложняет разработку и сопровождение таких систем.
Перечисленные факторы способствовали развитию исследований в области методологии программирования. Программирование обрело черты системного подхода с разработкой и внедрением языков высокого уровня, методов структурного и модульного программирования, языков проектирования и средств их поддержки, формальных и неформальных языков описаний системных требований и спецификаций и т.д.
Для целенаправленного выполнения проекта должен быть выполнен ряд работ, различных как по своему назначению, так и по квалификационным требованиям, предъявляемым к разработчикам. Иными словами, в ходе развития проекта командой разработчиков выполняются те или иные функции.
Функции, выполняемые разработчиками, — понятие неформализованное. В разных проектах оно может обретать свое содержание. Тем не менее типовые функции, которые предполагают практически все программные проекты, можно перечислить. Так, в любом программном проекте есть функции кодирования, т.е. записи программы на алгоритмическом языке по имеющимся спецификациям, анализа требований, т.е. выявления истинной потребности в создаваемой программе, тестирования и отладки. В рамках деятельности менеджера любого проекта необходимо организовать распределение функций проекта между исполнителями. Вполне естественно считать эти действия одной из функций менеджера. В результате ее выполнения члены команды, выполняющей проект, начинают играть соответствующие роли.
Состав и значимость ролей разработчиков и тех, кто с ними связан, различаются в зависимости от выполняемого проекта, от коллектива исполнителей, принятой технологии, от других факторов. Неоднозначность выбора ролей приводит к тому, что их список часто становится большим (иллюстрацией тому может служить первая редакция документации по Rational Unified Processing (RUP), в которой определено свыше 20 ролей; в последующих версиях документа это число сокращено до обозримого уровня [30]). Чрезмерное увеличение числа есть следствие отождествления роли и функции и, соответственно, игнорирования понятия родственности функций. В то же время, если ролей выбрано недостаточно, есть опасность, что не все нужные в проекте функции будут охвачены планированием и управлением.
Разработка современного программного комплекса представляет собой сложный и длительный процесс, который состоит из следующих этапов:
Предпроектные исследования, или анализ;
Проектирование и подготовка спецификаций;
Программирование, или кодирование;
Отладка;
Тестирование.
Во время предпроектного исследования собирается информация о предметной области, подбираются исходные данные и определяются функциональные требования к системе. Изучаются необходимые потребительские характеристики разрабатываемого программного обеспечения.
На этапе проектирования широко используется литература, стандарты и нормативные документы. Рассматриваются различные варианты реализации тех или иных функций и выбираются оптимальные. Здесь же разрабатывается архитектура, программный комплекс разбивается на подсистемы, определяются способы их взаимодействия. Результатом этого этапа является документация, с которой можно приступать к программированию, а именно: блок-схемы, SDL-диаграммы, функциональные схемы, описания алгоритмов.
На стадии программирования, или кодирования, происходит воплощение всех наработок, сделанных на предыдущем этапе в работающую систему. Все действия фиксируются как на уровне комментариев в исходных кодах программ, так и в проектной документации. Необходимо организовать процесс таким образом, чтобы в любой момент времени был возможен откат на несколько шагов назад.
Отладка тесно связана с программированием, эти этапы разделяются весьма условно. Отладка может производиться либо непосредственно на оборудовании, для которого предназначено разрабатываемое программное обеспечение, либо на различных эмуляторах. После программирования и отладки должна быть получена законченная рабочая система.
Тестирование представляет собой проверку всех функциональных возможностей разработанного программного обеспечения на том оборудовании, для которого оно разрабатывалось и в условиях, максимально приближенных к реальным. Важным моментом, обеспечивающим объективность, является необходимость проведения тестирования людьми, не участвовавшими в программировании.
На каждом этапе применяются специализированные средства разработки: во время разработки алгоритмов и архитектуры в основном используются различные редакторы; при программировании применяются компиляторы и линковщики, при отладке – отладчики, при тестировании может использоваться специальное тестовое оборудование. В самом простом случае, без какой-либо автоматизации, все перечисленные средства являются автономными и никак не связанны между собой.
Кроме чисто технических задач процесс разработки программного обеспечения, включает также функции планирования и управления, а в условиях распределённого проектирования эти функции становятся особенно актуальными. В рамках планирования производится определение временных параметров проектирования, распределение подсистем между коллективами разработчиков. Кроме того, в течение всего процесса разработки необходимо отслеживать текущее состояние проекта для осуществления контроля и оперативного управления, а также для обеспечения синхронизации проектных процедур.
Исходя из вышесказанного, схема процесса создания программного комплекса будет выглядеть следующим образом (Приложение Г).
3.2 Структурный подход к проектированию информационных систем
Сущность структурного подхода к разработке информационных систем заключается в ее декомпозиции (разбиении) на автоматизируемые функции: система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и так далее. Процесс разбиения продолжается вплоть до конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимосвязаны. При разработке системы «снизу-вверх» от отдельных задач ко всей системе целостность теряется, возникают проблемы при информационной стыковке отдельных компонентов.
Структурный подход к программированию представляет собой методологию создания программ. Его внедрение обеспечивает:
повышение производительности труда программистов при написании и контроле программ;
получение программ, которые более пригодны для сопровождения, так как состоят из отдельных модулей;
создание программ коллективом разработчиков;
окончание создания программ в заданный срок.
В структурированных программах обычно легко прослеживается основной алгоритм, они удобнее в отладке и менее чувствительны к ошибкам программирования. Эти свойства являются следствием важной особенности подпрограмм, каждая из которых представляет собой во многом самостоятельный фрагмент программы, связанный с основной программой лишь с помощью нескольких параметров. Такая самостоятельность подпрограмм позволяет локализовать в них все детали программной реализации того или иного алгоритмического действия, и поэтому изменение этих деталей, например в процессе отладки, обычно не приводит к изменениям основной программы.
Все наиболее распространенные методологии структурного подхода [9,11,12,13] базируются на ряде общих принципов [3]. В качестве двух базовых используются следующие принципы:
1. принцип «разделяй и властвуй» - принцип решения сложных проблем путем их разбиения на множество меньших независимых задач, легких для понимания и решения;
2. принцип иерархического упорядочивания - принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.
Выделение двух базовых принципов не означает, что остальные принципы являются второстепенными, поскольку игнорирование любого из них может привести к непредсказуемым последствиям (в том числе и к провалу всего проекта). Основными из них являются следующие принципы:
принцип абстрагирования - заключается в выделении существенных аспектов системы и отвлечения от несущественных аспектов;
принцип формализации - заключается в необходимости строгого методического подхода к решению проблемы;
принцип непротиворечивости - заключается в обоснованности и согласованности элементов;
принцип структурирования данных - заключается в том, что данные должны быть структурированы и иерархически организованы.
В структурном анализе используются в основном две группы средств, иллюстрирующих функции, выполняемые системой и отношения между данными. Каждой группе средств соответствуют определенные виды моделей (диаграмм), наиболее распространенными среди которых, являются следующие:
SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы;
DFD (Data Flow Diagrams) диаграммы потоков данных;
ERD (Entity-Relationship Diagrams) диаграммы «сущность-связь».
На стадии проектирования информационной системы модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения: архитектуру программного обеспечения, структурные схемы программ и диаграммы экранных форм.
Перечисленные модели в совокупности дают полное описание информационных систем независимо от того, является ли она существующей или вновь разрабатываемой. Состав диаграмм в каждом конкретном случае зависит от необходимой полноты описания системы.
Структурное проектирование позволяет одновременно сосредотачиваться на меньшем количестве деталей.
Нисходящее проектирование хорошо работает , когда проблема имеет ясно выраженный иерархический характер.
3.3 Проектирование информационных систем на основе объектно-ориентированного подхода
Структурное проектирование работает хорошо, потому что оно позволяет нам одновременно сосредотачиваться на меньшем количестве деталей. Это логичная методика, которая поощряет организованную доводку системы и уменьшает уровень сложности (степени интеграции) на каждой из последующих стадий проекта. По очевидным причинам, нисходящее (структурное) проектирование подходит лучше всего тогда, когда применяется к проблемам, которые имеют ясно выраженный иерархический характер. К сожалению, многие из реальных проблем не иерархические. Проект, основанный на построении сверху вниз, имеет также и следующие ограничения, которые станут очевидными при разработке и сопровождении больших программных систем:
функциональную точку зрения трудно развивать;
реальные системы трудно охарактеризовать функционально;
фокусирование на функциональности теряет из виду данные;
функциональная ориентация производит код, менее пригодный для многократного использования.
Методы структурного проектирования помогают упростить процесс разработки сложных систем за счет использования алгоритмов как готовых строительных блоков. Аналогично, методы объектно-ориентированного проектирования созданы, чтобы помочь разработчикам применять мощные выразительные средства объектного и объектно-ориентированного программирования, использующего в качестве блоков классы и объекты.
Структурное проектирование характеризуется перемещением от общей формулировки того, что программа делает к все более детализированным формулировкам этого относительно каждой специфической задачи.
Структурное проектирование не подходит для разработки больших программных систем, потому что оно выторговывает краткосрочное удобство в обмен на отсутствие гибкости при длительном сопровождении. Существует незаконная привилегия одной функции над другими, теряются из виду данные, оставаясь на заднем плане задачи. Затрудняется возможность многократного использования.
Первое отличие структурного подхода от объектно-ориентированного подхода заключается в принципах декомпозиции и структурной организации элементов (компонентов, модулей) системы. Согласно этим принципам система представляет собой структуру, состоящую из четко выраженных модулей, связанных между собой определенными отношениями.
При использовании структурного подхода (первый вид декомпозиции) выполняется функциональная (процедурная, алгоритмическая) декомпозиция системы, т. е. она представляется в виде иерархии (дерева) взаимосвязанных функций. На высшем уровне система представляется единым целым с наивысшей степенью абстракции и по мере детализации (добавления уровней) разбивается на функциональные компоненты с более конкретным содержанием.
Второй вид декомпозиции – объектно-ориентированный. В рамках этого подхода система разбивается на набор объектов, соответствующих объектам реального мира, взаимодействующих между собой путем посылки сообщений.
Вторым отличием является объединение в объекте как атрибутивных данных (характеристики, свойства), так и поведения (функции, методы). В функционально-ориентированных системах функции и данные хранятся (существуют) отдельно.
Третье отличие двух подходов заключается в структурной организации внутри модулей системы. В структурном подходе модуль состоит из функций, иерархически связанных между собой отношением композиции, т. е. функция состоит из подфункций, подфункция из подподфункций и т.д. В объектно-ориентированном подходе иерархия выстраивается с использованием двух отношений: композиции и наследования. При этом в объектно-ориентированном подходе «объект-часть» может включаться сразу в несколько «объектов-целое». Таким образом, модуль в структурном подходе представляется в виде дерева, а в объектно-ориентированном подходе – в виде ориентированного графа, т. е. с помощью более общей структуры.
Объектно-ориентированное проектирование – это конструирование программных систем как структурных коллекций, реализующих абстрактные типы данных.
Объектно-ориентированное проектирование и объектно-ориентированное программирование улучшают возможности нисходящего проектирования, концентрируя больше внимание на данных системы, а не на том, что система делает. Это подход позволяет создавать системы, которые легче сопровождать, они более гибкие, более устойчивые и более приспособлены к многократному использованию, чем создаваемые при нисходящем структурном подходе.
Преимущества объектно-ориентированного метода:
- работают на более высоком уровне абстракции;
- нет «прыжков» между фазами;
- поддерживают данные, которые имеют тенденцию, к большей стабильности, чем функции;
- поощряют и поддерживают классические достоинства хорошего программирования и проектирования;
- сопровождаются инструментами, обеспечивающими поддержку повторного использование кода.
Объектно-ориентированный подход имеет два аспекта:
объектно-ориентированная разработка программного обеспечения;
объектно-ориентированная реализация программного обеспечения.
Объектно-ориентированная разработка программного обеспечения связана с применением объектно-ориентированных моделей при разработке программных систем и их компонентов. К объектно-ориентированной разработке относятся:
- объектно-ориентированные технологии разработки программных систем;
- инструментальные средства, поддерживающие эти технологии.
Объектно-ориентированная разработка может начаться на самом первом этапе жизненного цикла; она не связана с языком программирования, на котором предполагается реализовать разрабатываемую программную систему: этот язык может и не быть объектно-ориентированным.
Объектно-ориентированная разработка программного обеспечения связана с применением объектно-ориентированных технологий. Обычно эти объектно-ориентированные методологии поддерживаются инструментальными программными средствами, но и без таких средств они полезны, так как позволяют хорошо понять различные аспекты и свойства разрабатываемой программной системы, что в последующем существенно облегчает ее реализацию, тестирование, сопровождение, разработку новых версий и более существенную модификацию.
Можно выделить следующие объектно-ориентированные методологии разработки программного обеспечения:
- RUP (Rational Unified Process);
- OMT (Object Modeling Technique);
- SA/SD (Structured Analysis/Structured Design);
- JSD (Jackson Structured Development);
- OSA (Object-Oriented System Analysis)
Объектно-ориентированный подход в проектировании, как и функционально-ориентированный, предполагает декомпозицию информационных систем. Если в функционально-ориентированном подходе декомпозиции подлежат процессы обработки, то в объектно-ориентированном подходе декомпозиции подлежат объекты, которые характеризуются определенной структурой данных. Здесь декомпозиция идет от данных. В объектно-ориентированном подходе выделяют классы объектов. Каждый класс содержит однородные объекты. Объектам одного класса присуще одинаковое множество методов реагирования на внешние сообщения. Иерархическая декомпозиция системы представляется в виде иерархии классов объектов, а функционирование системы – в виде взаимодействия объектов, обменивающихся сообщениями.
Среди свойств объектов в объектно-ориентированном подходе можно отметить:
- инкапсуляция, что означает скрытие информации. Смысл этого свойства в том, что состав и структура атрибутов объекта не зависит от сообщений, поступающих извне;
- наследование – это свойство, связанное с выделением иерархических классов объектов, то есть существуют родительские и дочерние классы. Оно проявляется в том, что, методы реагирования объекта, предусмотренные родительским классом, автоматически присваивают объектам дочерних классов, то есть родительские классы имеют общие методы, а дочерние – как общие, так и частные;
- полиморфизм – возможность выбора объектом в ответ на получаемые им сообщения какого-либо метода из множества методов в зависимости от того, какое пришло сообщение.
Наличие этих свойств у объекта позволяет в объектно-ориентированном подходе добиться параллельности и автономности разработки отдельных компонент системы, т.е. возможно создание прототипов с дальнейшей интеграцией отдельных прототипов в единую систему и использование итерационного подхода к разработке информационных систем.
Другое достоинство объектно-ориентированного подхода состоит в упрощении накопления типовых проектных решений с тем, чтобы в дальнейших разработках новых информационных систем осуществить сбор новой системы из готовых компонент. Эта особенность связана с тем, что классы объектов повторяются в определенной мере при переходе от одной информационной системы к другой, а для повторяющихся классов уже запрограммированы методы, разработаны и описаны структуры объектов данных.
Модель проектирования информационных систем на основе объектно-ориентированного подхода представлена в приложении (Приложение Д)
Отличительной чертой модели объектно-ориентированного проектирования является отсутствие строгой последовательности в выполнении стадий как в прямом, так и в обратном направлениях процесса проектирования по отдельным компонентам.
Основное преимущество объектно-ориентированного подхода состоит в упрощении проектирования информационных систем, при наличии типовых проектных решений по отдельным компонентам, а также легкости модификации, поскольку модификация касается лишь отдельных компонент.
3.4. Сопоставление и взаимосвязь структурного и объектно-ориентированного подходов
Гради Буч сформулировал главное достоинство объектно-ориентированного подхода следующим образом: объектно-ориентированные системы более открыты и легче поддаются внесению изменений, поскольку их конструкция базируется на устойчивых формах. Это дает возможность системе развиваться постепенно и не приводит к полной ее переработке даже в случае существенных изменений исходных требований.
Буч отметил ряд следующих преимуществ объектно-ориентированного подхода:
объектная декомпозиция дает возможность создавать программные системы меньшего размера путем использования общих механизмов, обеспечивающих необходимую экономию выразительных средств. Использование объектно-ориентированного программирования существенно повышает уровень унификации разработки и пригодность для повторного использования не только программного обеспечения, но и проектов, что в конце концов ведет к сборочному созданию программного обеспечения. Системы зачастую получаются более компактными, чем их не объектно-ориентированные эквиваленты, что означает не только уменьшение объема программного кода, но и удешевление проекта за счет использования предыдущих разработок;
объектная декомпозиция уменьшает риск создания сложных систем программного обеспечения, так как она предполагает эволюционный путь развития системы на базе относительно небольших подсистем. Процесс интеграции системы растягивается на все время разработки, а не превращается в единовременное событие;
объектная модель вполне естественна, поскольку в первую очередь ориентирована на человеческое восприятие мира, а не на компьютерную реализацию;
объектная модель позволяет в полной мере использовать выразительные возможности объектных и объектно-ориентированных языков программирования.
К недостаткам объектно-ориентированного программирования относятся некоторое снижение производительности функционирования программного обеспечения (которое, однако, по мере роста производительности компьютеров становится все менее заметным) и высокие начальные затраты. Объектная декомпозиция существенно отличается от функциональной, поэтому, переход на новую технологию связан как с преодолением психологических трудностей, так и дополнительными финансовыми затратами.
Объектно-ориентированный подход не дает немедленной отдачи. Эффект от его применения начинает сказываться после разработки двух-трех проектов и накопления повторно используемых компонентов, отражающих типовые проектные решения в данной области. Переход организации на объектно-ориентированную технологию - это смена мировоззрения, а не просто изучение новых CASE-средств и языков программирования.
Таким образом, структурный подход по-прежнему сохраняет свою значимость и достаточно широко используется на практике. На примере языка UML хорошо видно, что его авторы заимствовали то рациональное, что можно было взять из структурного подхода: элементы функциональной декомпозиции в диаграммах вариантов использования, диаграммы состояний, диаграммы деятельности и др. Очевидно, что в конкретном проекте сложной системы невозможно обойтись только одним способом декомпозиции. Можно начать декомпозицию каким-либо одним способом, а затем, используя полученные результаты, попытаться рассмотреть систему с другой точки зрения.
Основой взаимосвязи между структурным и объектно-ориентированным подходами является общность ряда категорий и понятий обоих подходов (процесс и вариант использования, сущность и класс и др.). Эта взаимосвязь может проявляться в различных формах. Так, одним из возможных вариантов является использование структурного анализа как основы для объектно-ориентированного проектирования. При этом структурный анализ следует прекращать, как только структурные модели начнут отражать не только деятельность организации (бизнес-процессы), а и систему программного обеспечения. После выполнения структурного анализа можно различными способами приступить к определению классов и объектов. Так, если взять какую-либо отдельную диаграмму потоков данных, то кандидатами в классы могут быть элементы структур данных.
Другой формой проявления взаимосвязи можно считать интеграцию объектной и реляционной технологий. Реляционные СУБД являются на сегодняшний день основным средством реализации крупномасштабных баз данных и хранилищ данных. Причины этого достаточно очевидны: реляционная технология используется достаточно долго, освоена огромным количеством пользователей и разработчиков, стала промышленным стандартом, в нее вложены значительные средства и создано множество корпоративных базах данных в самых различных отраслях, реляционная модель проста и имеет строгое математическое основание; существует большое разнообразие промышленных средств проектирования, реализации и эксплуатации реляционных баз данных. Вследствие этого реляционные базы данных в основном используются для хранения и поиска объектов в так называемых объектно-реляционных системах.
Взаимосвязь между структурным и объектно-ориентированным подходами достаточно четко просматривается в различных технологиях создания программного обеспечения.
Главный недостаток структурного подхода заключается в следующем: процессы и данные существуют отдельно друг от друга (как в модели деятельности организации, так и в модели программной системы), причем проектирование ведется от процессов к данным. Таким образом, помимо функциональной декомпозиции, существует также структура данных, находящаяся на втором плане.
В объектно-ориентированном подходе основная категория объектной модели - класс - объединяет в себе на элементарном уровне как данные, так и операции, которые над ними выполняются (методы). Именно с этой точки зрения изменения, связанные с переходом от структурного к объектно-ориентированному подходу, являются наиболее заметными. Разделение процессов и данных преодолено, однако остается проблема преодоления сложности системы, которая решается путем использования механизма компонентов.
Данные по сравнению с процессами являются более стабильной и относительно редко изменяющейся частью системы. Отсюда следует главное достоинство объектно-ориентированного подхода: объектно-ориентированные системы более открыты и легче поддаются внесению изменений, поскольку их конструкция базируется на устойчивых формах.
Безусловно, объектно-ориентированная модель наиболее адекватно отражает реальный мир, представляющий собой совокупность взаимодействующих (посредством обмена сообщениями) объектов. Но на практике в настоящий момент продолжается формирование стандарта языка объектно-ориентированного моделирования UML, и количество CASE-средств, поддерживающих объектно-ориентированный подход, невелико по сравнению с поддерживающими структурный подход. Кроме того, диаграммы, отражающие специфику объектного подхода (диаграммы классов и т.п.), гораздо менее наглядны и плохо понимаемы непрофессионалами. Поэтому одна из главных целей внедрения CASE-технологии, а именно снабжение всех участников проекта (в том числе и заказчика) общим языком «для передачи понимания», обеспечивается на сегодняшний день только структурными методами.
При переходе от структурного подхода к объектному, как при всякой смене технологии, необходимо вкладывать деньги в приобретение новых инструментальных средств. Здесь следует учесть и расходы на обучение (овладение методом, инструментальными средствами и языком программирования). Для некоторых организаций эти обстоятельства могут стать серьезными препятствиями.
Несмотря на отдельные критические замечания в адрес ООП, в настоящее время именно эта парадигма используется в подавляющем большинстве промышленных проектов. Однако, нельзя считать, что ООП является наилучшей из методик программирования во всех случаях.
Процедурное программирование лучше подходит для случаев, когда важны быстродействие и используемые программой ресурсы, но требует большего времени для разработки.
Объектное программирование подходит когда важна управляемость проекта и его модифицируемость, а также скорость разработки.
Исследование Thomas E. Potok, Mladen Vouk и Andy Rindos показало отсутствие значимой разницы в продуктивности разработки программного обеспечения между ООП и процедурным подходом.
Кристофер Дэйт указывает на невозможность сравнения ООП и других технологий во многом из-за отсутствия строгого и общепризнанного определения ООП.
Александр Степанов, в одном из своих интервью, указывал на то, что ООП «методологически неправильно» и что «… ООП практически такая же мистификация как и искусственный интеллект…».
Фредерик Брукс (Frederick P. Brooks, Jr.) в своей статье «No Silver Bullet. Essence and Accidents of Software Engineering» (Computer Magazine; April 1987) указывает на то, что наиболее сложной частью создания программного обеспечения является « … спецификация, дизайн и тестирование концептуальных конструкций, а отнюдь не работа по выражению этих концептуальных конструкций…». ООП (наряду с такими технологиями как искусственный интеллект, верификация программ, автоматическое программирование, графическое программирование, экспертные системы и др.), по его мнению, не является «серебряной пулей», которая могла бы на порядок величины (то есть примерно в 10 раз, как говорится в статье) снизить сложность разработки программных систем. Согласно Бруксу, «…ООП позволяет сократить только привнесённую сложность в выражение дизайна. Дизайн остаётся сложным по своей природе…».
Эдсгер Дейкстра указывал: «… то о чём общество в большинстве случаев просит - это змеиное масло. Естественно, «змеиное масло» имеет очень впечатляющие имена, иначе будет очень трудно что-то продать: «Структурный анализ и Дизайн», «Программная инженерия», «Модели зрелости», «Управляющие информационные системы» (Management Information Systems), «Интегрированные среды поддержки проектов», «Объектная ориентированность», «Реинжиниринг бизнес-процессов»…».
Никлаус Вирт считает, что ООП - не более чем тривиальная надстройка над структурным программированием, и преувеличение её значимости, выражающееся, в том числе, во включении в языки программирования всё новых модных «объектно-ориентированных» средств, вредит качеству разрабатываемого программного обеспечения.
Патрик Киллелиа в своей книге «Тюнинг веб-сервера» писал: «… объектно-ориентированное программирование предоставляет вам множество способов замедлить работу ваших программ …»
Известная обзорная статья проблем современного объектно-ориентированного программирования перечисляет некоторые типичные проблемы объектно-ориентированного программирования.
При классификации критических высказываний в адрес объектно-ориентированного программирования, можно выделить несколько аспектов критики данного подхода к программированию:
1. Критика рекламы объектно-ориентированного программирования.
Критикуется явно высказываемое или подразумеваемое в работах некоторых пропагандистов объектно-ориентированного программирования, а также в рекламных материалах «объектно-ориентированных» средств разработки представление об объектном программировании как о некоем всемогущем подходе, который магическим образом устраняет сложность программирования. Как замечали многие, в том числе Брукс и Дейкстра, «серебряной пули не существует» - независимо от того, какой парадигмы программирования придерживается разработчик, создание нетривиальной сложной программной системы всегда сопряжено со значительными затратами интеллектуальных ресурсов и времени. Из наиболее квалифицированных специалистов в области объектно-ориентированного программирования никто, как правило, не отрицает справедливость критики этого типа.
2. Оспаривание эффективности разработки методами объектно-ориентированного программирования.
Критики оспаривают тезис о том, что разработка объектно-ориентированных программ требует меньше ресурсов или приводит к созданию более качественного программного обеспечения. Проводится сравнение затрат на разработку разными методами, на основании которого делается вывод об отсутствии у объектно-ориентированного программирования преимуществ в данном направлении. Учитывая крайнюю сложность объективного сравнения различных разработок, подобные сопоставления, как минимум, спорны.
3. Производительность объектно-ориентированных программ.
Указывается на то, что целый ряд «врождённых особенностей» объектно-ориентированные технологии делают построенные на её основе программы технически менее эффективными, по сравнению с аналогичными необъектными программами. Не отрицая действительно имеющихся дополнительных накладных расходов на организацию работы объектно-ориентированных программ, нужно, однако, отметить, что значение снижения производительности часто преувеличивается критиками. В современных условиях, когда технические возможности компьютеров чрезвычайно велики и постоянно растут, для большинства прикладных программ техническая эффективность оказывается, менее существенна, чем функциональность, скорость разработки и сопровождаемость. Лишь для некоторого, очень ограниченного класса программ (программное обеспечение встроенных систем, драйверы устройств, низкоуровневая часть системного программного обеспечения, научное программное обеспечение) производительность остаётся критическим фактором.
4. Критика отдельных технологических решений в объектно-ориентированных-языках и библиотеках.
Эта критика многочисленна, но затрагивает она не объектно-ориентированное программирование как таковое, а приемлемость и применимость в конкретных случаях тех или иных реализаций её механизмов. Одним из излюбленных объектов критики является язык C++, входящий в число наиболее распространённых промышленных объектно-ориентированных-языков.
Гради Буч указывает на следующие причины, приводящие к снижению производительности программ из-за использования объектно-ориентированных средств:
1.Динамическое связывание методов.
Обеспечение полиморфного поведения объектов приводит к необходимости связывать методы, вызываемые программой (то есть определять, какой конкретно метод будет вызываться) не на этапе компиляции, а в процессе исполнения программы, на что тратится дополнительное время. При этом реально динамическое связывание требуется не более чем для 20 % вызовов, но некоторые объектно-ориентированные-языки используют его постоянно.
2.Значительная глубина абстракции.
Объектно-ориентированная-разработка часто приводит к созданию «многослойных» приложений, где выполнение объектом требуемого действия сводится к множеству обращений к объектам более низкого уровня. В таком приложении происходит очень много вызовов методов и возвратов из методов, что, естественно, сказывается на производительности.
3.Наследование «размывает» код.
Код, относящийся к «оконечным» классам иерархии наследования (которые обычно и используются программой непосредственно) - находится не только в самих этих классах, но и в их классах-предках. Относящиеся к одному классу методы фактически описываются в разных классах. Это приводит к двум неприятным моментам:
- снижается скорость трансляции, так как компоновщику приходится подгружать описания всех классов иерархии;
- снижается производительность программы в системе со страничной памятью поскольку методы одного класса физически находятся в разных местах кода, далеко друг от друга, при работе фрагментов программы, активно обращающихся к унаследованным методам, система вынуждена производить частые переключения страниц.
4. Инкапсуляция снижает скорость доступа к данным.
Запрет на прямой доступ к полям класса извне приводит к необходимости создания и использования методов доступа. И написание, и компиляция, и исполнение методов доступа сопряжено с дополнительными расходами.
5.Динамическое создание и уничтожение объектов.
Динамически создаваемые объекты, как правило, размещаются в куче, что менее эффективно, чем размещение их на стеке и, тем более, статическое выделение памяти под них на этапе компиляции.
Несмотря на отмеченные недостатки, выгоды от использования объектно-ориентированного программирования более весомы. Кроме того, повышение производительности за счёт лучшей организации объектно-ориентированного-кода, в некоторых случаях компенсирует дополнительные накладные расходы на организацию функционирования программы. Можно также заметить, что многие эффекты снижения производительности могут сглаживаться или даже полностью устраняться за счёт качественной оптимизации кода компилятором. Например, упомянутое выше снижение скорости доступа к полям класса из-за использования методов доступа устраняется, если компилятор вместо вызова метода доступа использует онлайн-подстановку (современные компиляторы делают это вполне уверенно).
3.5. Проблемы преподавания структурного и объектно-ориентированного программирования
В современном программировании объектно-ориентированный подход является одним из популярнейших. Средства для поддержки объектно-ориентированного программирования вошли практически во все профессиональные системы программирования. Этот стиль вместе с организационными нововведениями резко повысил качество программ, производительность труда отдельного программиста, эффективность коллективной работы программистов. Поэтому объектно-ориентированное программирование и объектно-ориентированная технология программирования уже стали неотъемлемой частью вузовских учебных программ по направлению «Информатика и вычислительная техника».
Однако, чтобы начать изучение объектно-ориентированного программирования, необходимы знания и умения основных принципов структурного программирования. Начальное обучение программированию осуществляется без использования объектно-ориентированных средств, неизбежно базируется на структурном программировании, на функциональной декомпозиции решаемых задач. У студента вырабатывается стереотип процедурного мышления. Переход к объектно-ориентированному программированию содержит в себе много неожиданностей. Использование объектной декомпозиции решаемых задач предполагает полную перестройку системного мышления. Поэтому разъяснение метафоры объектного программирования должно занимать существенную часть лекционного курса.
Объектно-ориентированное программирование, являясь в значительной мере развитой дисциплиной, включает как теоретические обоснования, так и богатый набор профессиональных практических приемов и рекомендаций. В качестве теоретической основы в объектно-ориентированном программировании используются абстрактные типы данных. Целью данной теории является обоснование автоматизированной процедуры формирования понятий, изменения понятий в процессе наследования, использования для определения одних понятий других понятий. Очень важной стадией развития объектно-ориентированного программирования является объектно-ориентированная технология проектирования программных систем, которая предоставила средства и приемы предварительного описания и документирования сложных задач автоматизации.
Однако наличие совершенных для современного уровня развития инструментов не гарантирует получение качественных программ: необходимо в совершенстве овладеть как самими инструментами, так и приемами их совместного использования, приемами работы в коллективе.
Освоение программирования можно характеризовать тремя историческими этапами, отличающимися уровнем сложности получения профессиональной квалификации.
Ранний этап характерен очень высоким уровнем сложности. Программирование осуществляется на языке кодов компьютера, позже – на языке ассемблера. От программиста требуются глубокие знания архитектуры компьютера: системы команд, методов управления памятью и управления вычислительным процессом и т.д. Появившаяся в те времена профессия «программист» относилась к элитным, загадочным.
С появлением языков программирования высокого уровня начался второй этап, характеризующийся резким снижением уровня начальной профессиональной подготовки. Идеи языка программирования стали доступны широкому кругу различных специалистов и, как следствие, программистская деятельность стала составной частью многих профессий. В этот период было создано огромное число достаточно простых программ. Потребность в автоматизации несложных задач была удовлетворена. Однако в конце двадцатого века стали резко усложняться передаваемые компьютеру задачи. На этом фоне усилились предъявляемые к программам требования: надежности, корректности, дружественного к пользователю интерфейса, простоты совершенствования и развития. Переход к технологии персональных компьютеров, сделавший этот инструмент массовым, способствовал созданию специальных средств управления вычислительным процессом. В практику программирования были введены концепции событийного программирования и защищенных от ошибок программных кодов.
С появлением объектно-ориентированного программирования начался новый, третий, этап в сложности получения базовых знаний для занятия программистской деятельностью. Теперь весьма поверхностное освоение приемов программирования позволяет создавать несложные программы. Чаще всего качество таких программ не удовлетворяет современным требованиям надежности, модифицируемости и, как следствие, время жизни программы будет небольшим. Легкость получения работающей программы создает у программистов иллюзию достаточной подготовленности. Однако для создания отвечающего всем современным требованиям сложного программного изделия необходимо глубокое понимание идей, принципов объектно-ориентированного программирования, реализации их в системе программирования, устройства объектно-ориентированной программы, объектно-ориентированной технологии создания программных систем.
Основные проблемы, возникающие в учебном процессе по освоению объектно-ориентированного программирования.
1. Объектно-ориентированное программирование ориентировано в первую очередь на создание сложных программ, а студент, выполняя лабораторные работы, решает простые задачи. В курсовых работах студент чаще всего решает локальные задачи. Руководителем проекта является преподаватель, на нем лежит ответственность за проект в целом. В результате, большая часть студентов не получает опыт создания сложных программ и, тем более, руководства процессом их разработки.
2. Объектно-ориентированное программирование создает хорошие возможности модификации программ, но эти возможности закладываются еще на этапе проектирования программы.
3. Большинство преподавателей высшей школы являются представителями старшего поколения. Как правило, они получили огромный опыт использования технологии структурного проектирования программ, основанной на алгоритмической декомпозиции больших систем. Большинство служащих примерами успешных программ разработано с применением технологии структурного проектирования. Поэтому обучение объектно-ориентированному программированию находится под (объективным и субъективным) влиянием идей структурного проектирования программ. Накопление полезного опыта объектно-ориентированного программирования в этом случае становится делом самостоятельным на основе метода проб и ошибок.
4. Наука программирования быстро развивается, поэтому полученные обычно на начальных курсах знания приемов программирования к моменту окончания ВУЗа в значительной мере устаревают. Поэтому учебный процесс должен прививать специалисту качества оперативной реакции на новые идеи и технологии программирования.
5. Сложность задач автоматизации неуклонно растет. Поэтому молодой специалист, получив представление об одном уровне сложности программных систем, попадает в условия следующего уровня сложности. Поэтому неизбежен этап адаптации к новым условиям. От выпускника опять требуются качества оперативного реагирования на изменившиеся условия работы.
6. Качественная программа должна не только решать прикладную задачу, но и быть легко читаемой, легко понимаемой. В программистской практике нередка ситуация, когда уже разработанная программа передается другому программисту для ее сопровождения и развития, работа этого программиста начинается с изучения программы. Использование хороших правил именования идентификаторов и аналогичных методических приемов существенно повышает преемственность. Поэтому доступность понимания программы является, прежде всего, практическим принципом: как показывают научные исследования, при отладке программ до 90% времени тратится на чтение исходного текста. У программиста «пишущего» программу создается иллюзия ее ясности. С целью экономии времени студенты используют заложенные в систему программирования правила именования идентификаторов, после двух недель приходится восстанавливать в памяти то, что написано ранее. В результате, на вопрос «Какое назначение кнопки Button8?», студент отвечает только после внимательного просмотра и изучения своей программы. Большую помощь в чтении программы оказывает применение правил именования идентификаторов, однако часто студенты пренебрегают этими правилами.
7. Особенность организации учебного процесса в ВУЗе состоит в том, что студент должен изучить большое число общеобразовательных, общетехнических и специальных дисциплин. Дифференциация наук достигла большого размаха и не прошла мимо объектно-ориентированного программирования, которое опирается на теорию алгоритмов, теорию абстрактных типов данных, теорию проектирования программ и др. Освоение разных дисциплин осуществляется под руководством разных преподавателей, в результате чего у студентов возникают затруднения в осознании целостности распределенного по разным дисциплинам учебного материала.
8. Перед преподавателем стоит проблема оценки знаний и навыков студентов в области объектно-ориентированного программирования, которая в значительной мере затрагивает интересы студента. Учитывая, что обсуждаемая технология ориентирована на создание сложных программ, преподавателю приходиться преодолевать серьезные трудности при выборе адекватных средств контроля или упрощать картину. Контроль знаний на уровне синтаксиса конструкций языка программирования трудно назвать удовлетворительным для объектно-ориентированного программирования.
9. Создатели программных средств, как правило, считают реализацию программ коммерческой тайной, подробно раскрывается только внешняя логика программы. Поэтому хорошие примеры реализации объектно-ориентированных программ с комментариями по выбору решений фактически отсутствуют. По этой причине, предлагая примеры программ студентам, преподаватель действует субъективно, а студенты находятся в зависимости от профессиональных пристрастий конкретного преподавателя.
Следующие проблемы это традиционные для учебного процесса.
1. Студенческий контингент неоднороден: одни студенты пришли получить профессию, другие – диплом, третьи – по рекомендации. Перед преподавателем стоит проблема выбора студента, который будет изучать программирование, углублено.
2. Практические занятия опережают теоретические занятия. Преподаватель должен организовать самостоятельную работу студентов по предварительному овладению теоретическими знаниями.
3. Последовательность дисциплин в учебном процессе часто не отвечает требованиям первичности-вторичности получения знаний. И причина здесь не в плохой организации учебного процесса, а в сильной взаимосвязи многих дисциплин в рамках одной специальности. В последнем случае преподавателю часто приходиться отвлекаться на краткие экскурсы в другие дисциплины.
Основным инструментом программиста является система программирования, которая содержит средства для построения всего спектра современных информационных технологий. Многие учебники по объектно-ориентированному программированию представляют, по сути, справочники по визуальным компонентам и приемам их задействования в программе. Однако все визуальные компоненты в обозначенное учебным планом время подробно рассмотреть невозможно. Поэтому преподавателю, решая задачу выбора перечня рассматриваемых компонентов, приходиться ранжировать компоненты, определяя важность, значимость каждого из них. Однозначно просмотреть и изучить все компоненты невозможно, поэтому часто здесь присутствует субъективизм и личные пристрастия. Этим можно объяснить и тот факт, что в разных учебниках рассматриваются разные наборы визуальных компонентов. Основной путь получения профессиональных знаний и навыков использования визуальных компонентов заключается в самостоятельной работе. Не случайно появилось высказывание: «Чтобы научиться программированию, нужно программировать».
В этих условиях основной задачей преподавателя является обучение методике освоения программирования с использованием библиотеки визуальных компонентов. Во-первых, необходимо рассмотреть иерархию компонентов, которая является своеобразным путеводителем по компонентам и помогает понять взаимодействие компонентов. Во-вторых, целесообразно изучение начинать с корня иерархии компонентов, для каждого компонента подробно рассматриваются только те методы и свойства, которые впервые появились в нем, вспоминая при этом свойства и методы, которые компонент унаследовал. Полученные знания позволят студентам самостоятельно добраться до листьев иерархии визуальных компонентов. В-третьих, необходимо изучить окружение программы, в котором работают компоненты.
Конечной целью обучения программированию является умение самостоятельно создавать качественные программные изделия. Система контроля по дисциплине «Объектно-ориентированное программирование» должна быть ориентирована в первую очередь на оценку навыков разработки программ. Как правило, знание теории позволяет студенту и специалисту создавать качественные программы.
Таким, образом, в условиях учебного процесса студент не всегда имеет возможность в полной мере ощутить потребность в использовании рекомендаций объектно-ориентированного программирования и оценить их по достоинству. Выпускник ВУЗа, получивший образование в области информатики и вычислительной техники на примере простых программ, под руководством «структурно-ориентированных» преподавателей и на примере успешных «структурно-ориентированных» программ вынужден во время получения образования и на начальном этапе профессиональной деятельности самостоятельно отфильтровывать идеи структурного проектирования программ, несовместимые с идеями объектно-ориентированной технологии. Кроме того, современные системы программирования уже не содержат средства поддержки структурного проектирования программ.
Первая глава магистерской диссертации описывает технологии структурного и объектно-ориентированного подходов а также примеры технологий создания программных обеспечений различных компаний-поставщиков, таких как: Rational Unified Process (IBM Rational Software), Oracle, Borland, Computer Associates.
По прогнозам IDC, рынок технологий создания программного обеспечения, испытавший определенный кризис в 2002 году, в ближайшее пятилетие ожидает устойчивый рост в среднем на 6,3% в год. Определяющим фактором для развития этой тенденции является стремление компаний-разработчиков повысить продуктивность своей работы, сократить сроки вывода новых продуктов на рынок, контролировать расходы и быстро получать отдачу от инвестиций. Достижению этих целей способствует использование сред разработки, позволяющих снизить сложность процессов создания программного обеспечения, увеличить их эффективность, уменьшить затраты на разработку и максимально использовать потенциал новых технологий. Аналитики сходятся на том, что основное направление развития инструментальных средств - их сквозная интеграция, переход от частично интегрированных средств к интегрированным комплексам, объединяющим возможности управления требованиями, моделирования, разработки, тестирования, управления конфигурацией и изменениями и развертывания приложений. В ближайшие годы такие комплексы, помимо перечисленных возможностей будут включать в себя средства управления потоками работ и проектами. Рынок таких инструментальных средств ожидает глобальная консолидация, обещающая принести значительные выгоды разработчикам. В то же время проблема обоснованного выбора и эффективного применения технологии создания программного обеспечения в крупномасштабных проектах остается актуальной. Невозможно достичь удовлетворительных результатов от применения даже самых совершенных технологий, если они применяются бессистемно, разработчики не обладают необходимой квалификацией для работы с ними, и сам проект выполняется и управляется хаотически. Систематический, обоснованный подход к выбору и применению технологии создания программного обеспечения может сократить время и повысить качество разработки программного обеспечения, обеспечить высокую степень его независимости от конкретных разработчиков, а также снизить затраты на разработку и сопровождение программного обеспечения.
Вторая глава диссертации рассматривает методические основы технологий создания программного обеспечения. Среди современных информационных технологий программирование занимает особое место. В технологиях программирования в определенной степени синтезируются все достижения информатики на каждом этапе ее развития. Визуальное программирование - одна из современных технологий программирования. В ее основе лежит объектно-ориентированный подход к описанию процессов (явлений), который, по утверждению ряда исследователей, является одним из наиболее эффективных и удобных средств, используемых сегодня программистами для создания больших программных систем. Кроме того, при визуальном программировании учитывается вероятностная природа решаемых задач, что, естественно, более соответствует реальной действительности. Навыки программирования в среде визуального программирования в настоящее время становятся перспективным компонентом профессиональной деятельности преподавателя информатики.
Сопоставление и взаимосвязь структурного и объектно-ориентированного подхода к проектированию программного обеспечения информационных систем рассматривается в третьей главе диссертации. В данной главе описываются структурный и объектно-ориентированный подходы в проектировании программного обеспечения информационных систем. Изучены проблемы преподавания структурного и объектно-ориентированного программирования. Несмотря на то, что изучение основ структурного программирования входит в государственный образовательный стандарт общего и среднего образования по информатике, значительная часть первокурсников имеет весьма слабое представление о программировании вообще. Значительные затруднения при изучении разделов программы, связанных с алгоритмизацией и программированием, испытывают и те студенты, которые изучали основы программирования в рамках школьного курса информатики. Успешной является их весьма незначительная часть (примерно до 10% от их общего числа). Такая ситуация является достаточно стабильной в течение последних лет.
Таким образом, программирование стало одновременно и простым, и сложным, а учебный процесс по изучению объектно-ориентированного программирования накопил целый ряд противоречий объективного и субъективного характера.
|
№ п/п |
Понятие |
Определение |
|
1 |
Абстрагирование |
мысленное выделение, вычленение некоторых элементов конкретного множества и отвлечение их от прочих элементов данного множества. |
|
2 |
Адаптация |
процесс накопления информации в системе, направленный на достижение оптимального состояния. |
|
3 |
Алгоритм |
предписание, задающее на базе системы правил последовательность операций, точное выполнение коих позволяет решать задачи определенного класса. |
|
4 |
Архитектура компьютера |
логическая организация, структура и ресурсы компьютера, которые может использовать программист |
|
5 |
Верификация |
установление соответствия принятой и переданной информации с помощью логических методов |
|
6 |
Визуальное программирование |
программирование, предусматривающее создание приложений с помощью наглядных средств. При этом программист показывает, что должно получиться в результате, а текст программы генерируется автоматически с помощью визуального прототип |
|
7 |
Генерация |
функция построения, при которой настоящие действующие процессы, работая в режиме объединения с другими встречающимися процессами, образуют связующие концепции. |
|
8 |
Декомпозиция |
метод, использующий структуру задачи и позволяющий заменить решение одной большой задачи решением серии меньших задач. |
|
9 |
Заглушка |
процедура, представленная точной спецификацией заголовка и пустым телом. |
|
10 |
Инкапсуляция |
сокрытие внутренней структуры данных и реализации методов объекта от остальной программы |
|
11 |
Интеграция |
состояние связанности отдельных дифференцируемых частей и функций системы в целое, а также процесс, ведущий к такому состоянию. |
|
12 |
Итерация |
повторное применение математической операции в серии аналогичных операций, производимых для получения результата. |
|
13 |
Концепция |
основополагающая идея теории |
|
14 |
Методология |
система принципов и способов организации и построения теоретической и практической деятельности, а также учение об этой системе. |
|
15 |
Наследование |
свойство объекта, заключающееся в том, что характеристики одного объекта (объекта-предка) могут передаваться другому объекту (объекту-потомку) без их повторного описания |
|
16 |
Подход |
комплекс парадигматических, синтагматических и прагматических структур и механизмов в познании и/или практике, характеризующий конкурирующие между собой (или исторически сменяющие друг друга) стратегии и программы |
|
17 |
Полиморфизм |
способность объекта выбирать правильный метод в зависимости от типа данных, полученных в сообщении |
|
18 |
Программирование |
процесс подготовки задач для их решения с помощью компьютера; итерационный процесс составления программ |
|
19 |
Программист |
специалист, занимающийся разработкой и проверкой программ |
|
20 |
Процедура |
часть программы, предназначенная для выполнения некоторых стандартных действий, зависящих, в общем случае, от входных параметров |
|
21 |
Реинжиринг |
радикальное переосмысление и перепроектирование деловых процессов для достижения резких, скачкообразных улучшений главных современных показателей деятельности компании, таких, как стоимость, качество, сервис и темпы. |
|
22 |
Репозиторий |
хранилище место, где хранятся и поддерживаются какие либо данные. |
|
23 |
Стратегия |
набор правил, согласно которым предпринимаемые действия должны зависеть от обстоятельств, включая естественные события и действия других людей. |
|
24 |
Типизация данных |
классификация данных по областям их значений; и по операциям, в которых они участвуют |
|
25 |
Функция |
поименованная часть программы, которая может вызываться из других частей программы столько раз, сколько необходимо. |
|
1 |
Hans-Erik Eriksson , Magnus Penker -- Business Modeling with UML: Business Patterns at work. -Wiley Computer Publishing, 2000 |
|
2 |
IEEE Std 1209-1992. IEEE Recommended Practice for the Evaluation and Selection of CASE Tools. |
|
3 |
IEEE Std 1348-1995. IEEE Recommended Practice for the Adoption of Computer-Aided Software Engineering (CASE) Tools. |
|
4 |
ISO/IEC 14102:1995(E). Information technology - Guideline for the evaluation and selection of CASE Tools. |
|
5 |
Worldwide Analysis, Modeling, and Design Tools Forecast and Analysis, 2002 -2006. -- IDC, http://www.idc.com, 2002 |
|
6 |
Worldwide Analysis, Modeling, Design and Construction Tools Competitive Analysis, 2003: 2002 Shares and Current Outlook. -- IDC, http://www.idc.com, 2003 |
|
7 |
Worldwide Application Development and Deployment Forecast Summary, 2003 - 2007. -- IDC, http://www.idc.com, 2003 |
|
8 |
А. Вендров Современные CASE-технологии – интернет, http://www.citforum.ru/win/database/kbd97/ |
|
9 |
А. Коберн -- Быстрая разработка программного обеспечения.: Пер. с англ. -- М.: ЛОРИ, 2002 |
|
10 |
А. Коберн -- Современные методы описания функциональных требований к системам.: Пер. с англ. -- М.: ЛОРИ, 2002 |
|
11 |
А.М. Вендров -- Проектирование программного обеспечения экономических информационных систем: Учебник. -- М.: Финансы и статистика, 2000 |
|
12 |
А.Н. Калашян , Г.Н. Калянов -- Структурные модели бизнеса: DFD-технологии. -- М.: Финансы и статистика, 2003 |
|
13 |
Ален И. Голуб С и С++. Правила программирования. – М.: Восточная Книжная Компания, 1996. |
|
14 |
Архангельский А.Я. Программирование в C++Builder 5.-M.: БИНОМ, 2000. – 1152 с: ил + CD. |
|
15 |
Архангельский, А. Я. 100 компонентов общего назначения Delphi [Текст]: Бином-Пресс/ Алексей Яковлевич Архангельский –Тверь: Комсомольский проспект, 2003. – 562 с. : ил.; 20 см. Загл. пер. и корешка: 100 компонентов общего назначения Delphi - 1-е изд.; компьютерная верстка – И.О. Бурова; - 2500 экз. – ISBN 5-9518-0025-3 (рус.). |
|
16 |
Архангельский, А. Я. Программирование в Delphi 7[Текст]: Бином-Пресс/ Алексей Яковлевич Архангельский –Тверь: Комсомольский проспект, 2003. – 1152 с. : ил.; 25 см. - Загл. пер. и корешка: Программирование в Delphi 7- 1-е изд.; компьютерная верстка – С.В. Свиридова; - 4000 экз. – ISBN 5-9518-0042-0 (рус.). |
|
17 |
Архангельский, А.Я. Приемы программирования в Delphi [Текст]: Бином-Пресс/ Алексей Яковлевич Архангельский – Тверь: Комсомольский проспект, 2004. – 906 с. : ил.; 20 см.; Загл. пер. и корешка: Приемы программирования в Delphi - 1-е изд.; компьютерная верстка – С.В. Свиридова; - 4000 экз. – ISBN 5-9125-0049-0 (рус.). |
|
18 |
Ахо А., Ульман Дж. «Теория синтаксического анализа, перевода и компиляции» в 2 тт., том 1., М., Мир, 1978. |
|
19 |
Бабушкина, И.А. Практикум по объектно-ориентированному программированию [Текст]: Бином-Пресс/ Бабушкина И.А., Окулов С.М.: Лаборатория знаний, 2004. - 366 с. - ISBN: 5-94774-129-6 |
|
20 |
Бадд Т. Объектно-ориентированное программирование в действии = An Introduction to Object-Oriented Programming. - СПб.: «Питер», 2007. - 464 с. |
|
21 |
Баженова И. Ю. Delphi 7 Самоучитель программиста [Текст]: Кудиц-Образ / Баженова, И. Ю. - М.: Варшавное шоссе, 2003. – 447с.: ил.; Загл. пер. и корешка: Delphi 7 Самоучитель программиста – 3000 экз. – ISBN 5-9125-1849-0 (рус.). |
|
22 |
Башмаков, А.И., Башмаков И.А. Разработка компьютерных учебников и обучающих систем. М.: Информационно-издательский дом «Филинъ», 2003. 616 с. ISBN 5-9216-0044-Х |
|
23 |
Бертран, М. Объектно-ориентированное конструирование программных систем / Пер. с англ. - М.: Издательско-торговый дом «Русская Редакция», 2005. - 1232 стр. ISBN: 5-7502-0255-0 |
|
24 |
Бобровский, С. И. Delphi 7. Учебный курс [Текст]: Питер/ Сергей Игоревич Бобровский, СПб.: Измайловский проспект, 2004. – 736с.: ил.; Загл. пер. и корешка: Delphi 7. Учебный курс - 1-е изд.; 5000 экз. – ISBN 5-94157-267-0 (рус.). |
|
25 |
Бондаревская, Е.В. Теория и практика личностно-ориентированного образования. – Ростов: Изд-во Ростов. пед. ун-та, 2000. – 352 с. ISBN 5-86340-090-0 |
|
26 |
Брушлинский, А. В Мышление: процесс, деятельность, общение / Под ред. А. В. Брушлинского. М.: Наука, 1982 – 286с. ISBN 5-7695-0084-0 |
|
27 |
Брушлинский, А. В. Психология мышления и кибернетика. М.: Мысль, 1970. 191 с. |
|
28 |
Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений на С++ / Пер. И.Романовский, Ф.Андреев. - 2-е изд. - М., СПб.: «Бином», «Невский диалект», 2008. - 344 с. |
|
29 |
Буч, Г. Объектно-ориентированный анализ и проектирование с примерами приложений на С++, 2-е изд. / Пер. с англ. - М.: «Издательство Бином», СПб: «Невский диалект», 1998г. - 560 с. ISBN: 5-7940-0017-1 |
|
30 |
Буч, Г. Объектно-ориентированный анализ и проектирование с примерами приложений [Текст] / Буч Г. , Максимчук Р., Энгл М., Янг Б., Коналлен Д., Хьюстон К. 3-е изд.: Пер. с англ. – М.: ООО «И.Д. Вильямс», 2008. – 720с.: ил. ISBN 978-5-8459-1401-9 |
|
31 |
В.П. Румянцев. Азбука программирования в Win 32 API. – 3-е изд.: – Москва, «Горячая линия – телеком», 2001. |
|
32 |
В.Пэйдж, Н.Хьюз и др. «Использование Oracle8». Специальное Издание -(К.; М.; СПб.: «Вильямс», 1998, 752 стр.); [оригинал: William G Page, Jr., and Nathan Hughes, et al. «Using Oracle8. Special Edition» Que Corporation, 1998] |
|
33 |
В.Юринский, А.Бачин, В.Абрамов «Oracle7. Практическое руководство» (М.: «Софтсервис», 1997 стр.) |
|
34 |
Вильяме А. Системное программирование в Windows 2000 /Пер. с англ. П. Анджан.-СПб. – М. – Харьков – Минск: Питер, 2001. – 621 с: ил. + CD-ROM. |
|
35 |
Влиссидес, Д. Приемы объектно-ориентированного проектирования. Паттерны проектирования. [Текст] / Влиссидес Д., Джонсон Р., Хелм Р., Гамма Э. Пер. с англ. СПб.: «Питер», 2003 г. - 400 стр. ISBN: 5-272-00355-1 |
|
36 |
Волкова В.Н. Искусство формализации – СПб.: Изд-во СПбГТУ, 1999. |
|
37 |
Галисеев, Г.В. Самоучитель. Программирование в среде Delphi for .Net. [Текст]: Вильямс/ Геннадий Владимирович Галисеев – М.: ул. Лесная, 2004. – 304 с. : ил.; 20 см.; Загл. пер. и корешка: Самоучитель. Программирование в среде Delphi for .Net. - 1-е изд.; - 5000 экз. – ISBN 5-8459-0644-Х (рус.). |
|
38 |
Гофман, В. Delphi. Быстрый старт [Текст]: БХВ-Петербург / Гофман, В., Хоменко А. – СПб., 2003. – 289 с. : ил.; 20 см.; Загл. пер. и корешка: Delphi. Быстрый старт - 1-е изд.; - 1500 экз. – ISBN 5-8459-0546-6 (рус.). |
|
39 |
Грэхем, И. Объектно-ориентированные методы. Принципы и практика = Object-Oriented Methods: Principles & Practice. — 3-е изд. — М.: «Вильямс», 2004. — С. 880. — ISBN 0-201-61913-X |
|
40 |
Гура, В.В. Проблема разработки педагогических целей при проектировании медиаобразовательной среды//Известия Южного отделения Российской академии образования. Вып. III. - Ростов, 2001. – С. 139-142. |
|
41 |
Гура, В.В. Разработка мультимедийных информационно-обучающих систем для педагогов//Философия в системе духовной культуры на рубеже XXI века. – Курск, 1997. |
|
42 |
Д. Леффингуэлл , Д. Уидриг -- Принципы работы с требованиями к программному обеспечению. Унифицированный подход.: Пер. с англ. -- М.: Вильямс, 2002 |
|
43 |
Д. Розенберг , К. Скотт -- Применение объектно-ориентированного моделирования с использованием UML и анализ прецедентов.: Пер. с англ. -- М.: ДМК, 2002 |
|
44 |
Д.А. Марка , К. МакГоуэн -- Методология структурного анализа и проектирования. -- М.: МетаТехнология, 1993 |
|
45 |
Д.Энсор, Й.Стивенсон "Oracle8: Рекомендации разработчикам" (К.: Изд.группа BHV, 1998, 126 стр.); [оригинал: Dave Ensor and Jan Stevenson. "Oracle8 Design Tis" O'Reilly & Associates, Inc., 1997] |
|
46 |
Дейкстра Э. Заметки по структурному программированию.- М.:Дрофа, 2006, - 455 с. |
|
47 |
Дейл Н., Уимз Ч., Хедингтон М. Программирование на C++: Пер. с англ..-М.: ДМК, 2000. – 672 с. |
|
48 |
Дж. Рамбо , Г. Буч , А. Якобсон -- UML. Специальный справочник: Пер. с англ. -- СПб: Питер, 2002 |
|
49 |
Долинер, Л.И. Информационные и коммуникационные технологии в обучении: психолого-педагогические и методические аспекты. Екатеринбург: Изд-во Рос. гос. проф.-пед. ун-та, 2003. 344 с. |
|
50 |
Ершов А.П. Введение в теоретическое программирование.- М.:РОСТО, 2008, - 288 с. |
|
51 |
Ефимов, В.С. Педагогическое образование в России: современное состояние, проблемы, перспективы//Преподавание социально-гуманитарных дисциплин в вузах России: состояние, проблемы, перспективы. – М.: Логос, 2001. – С. 166-177. |
|
52 |
Жельников В., Криптография от папируса до компьютера. М.: ABF, 1996. |
|
53 |
Жуков А., Изучаем Delphi [Текст]: Питер/ Жуков А., СПб.: Измайловский проспект, 2001. – 586с. : ил.; Загл. пер. и корешка: Изучаем Delphi - 1-е изд.; 3000 экз. – ISBN 5-8046-0056-3 (рус.). |
|
54 |
Захарова И.Г. Информационные технологии в образовании: Учеб. пособие для студ. высш. пед. учеб. заведений. – М.: Издательский центр «Академия», 2003. – 192 с. |
|
55 |
Иванова Г.С. Объектно-ориентированное программирование: Учебник для вузов. – 3-е изд., стер./Под ред. Г.С. Ивановой, Ничушкиной Т.Н., Пугачева Е.К. – М.: Изд-во МГТУ им. Н.Э. Баумана, 2007. – 368 с. ISBN: 5-7038-2280-7 |
|
56 |
К. Ларман -- Применение UML и шаблонов проектирования. 2-е издание.: Пер. с англ. - М.: Вильямс, 2002 |
|
57 |
Калянов Г., Лебедев В. CASE-средства и качество АБС – интернет, http://www.bizcom.ru/win/bt/1996/nr4/15 |
|
58 |
Кнут Д. Искусство программирования для ЭВМ, т.1. М.: 2006, 735 с. |
|
59 |
Коган Д.И., Бабкина Т.С. «Основы теории конечных автоматов и регулярных языков. Учебное пособие» Издательство ННГУ, 2002. - 97 с. |
|
60 |
Колесов, Ю. Моделирование систем. Объектно-ориентированный подход. [Учебное пособие] / Колесов Ю. , Сениченков Ю. издательство "BHV", 2006 г. - 192 стр. ISBN: 5-94157-579-3 |
|
61 |
Компания Advanced Information Systems и др. "Oracle8. Энциклопедия пользователя" (К.: "ДиаСофт", 1998, 864 стр.); [оригинал: Advanced Information Systems, INC., et al "Oracle. Second Edition. UNLEASHED" SAMS Corporation, 1997] |
|
62 |
Кречетников К.Г. Особенности проектирования интерфейса средств обучения // Информатика и образование. 2002. № 4. С. 65-73. |
|
63 |
Круглински Д.Д., Уингоу С, Шеферд Д. Программирование на Microsoft Visual C++ 6.0: Пер. с англ..-СПб. – М. Харьков – Минск: Питер; Русская редакция, 2000. – 821 с: ил. + CD-ROM. |
|
64 |
Круглова, Н. Ф. Концепция осознанной саморегуляции деятельности и учебная успеваемость // Прикладная психология. 2003. № 6. С. 19-21. |
|
65 |
Культин, Н. Б. Основы программирования в Delphi 7 [Текст]: БХВ-Петербург / Никита Борисович Культин – СПб., 2003. – 608 с. : ил.; 20 см.; Загл. пер. и корешка: Основы программирования в Delphi 7 - 1-е изд.; - 5000 экз. – ISBN 5-94157-269-7 (рус.). |
|
66 |
Кэнту, М. Delphi 7: Для профессионалов [Текст]: Питер/ Марко Кэнту, СПб.: Измайловский проспект, 2004. – 1104 с. : ил.; Загл. пер. и корешка: Delphi 7: Для профессионалов - 1-е изд.; 3000 экз. – ISBN 5-94723-593-5 (рус.). |
|
67 |
Лесневский, А.С. Объектно-ориентированное программирование для начинающих. – М.: БИНОМ. Лаборатория знаний, 2005. – 232с.: илл. – 2 экз. ISBN: 5-94774-251-9 |
|
68 |
М. Каменнова , А. Громов , М. Ферапонтов , А. Шматалюк -- Моделирование бизнеса. Методология ARIS. -- М.: Весть-МетаТехнология, 2001 |
|
69 |
М. Фаулер , К. Скотт -- UML в кратком изложении. Применение стандартного языка объектного моделирования.: Пер. с англ. -- М.: Мир, 1999 |
|
70 |
М.Ричардс и др. "Oracle7.3. Энциклопедия пользователя" (К.: "ДиаСофт", 1997, 830 стр.); [оригинал: Michael Richards at al. "Oracle. UNLEASHED" SAMS Corporation, 1996] |
|
71 |
М.Эбби, М.Кори "Oracle8: Первое знакомство" (М.: "Лори", 1998, 470 стр.); [оригинал: Michael Abbey, Michael J.Correy "Oracle8: Beginner's Guide" Osborne/McGraw-Hill, 1997] |
|
72 |
Майер, Б. Объектно-ориентированное программирование. Концепции разработки (с CD-ROM). , М.: "Русская Редакция", 2004 г. - 600 стр. ISBN: 5-7502-0260-7 |
|
73 |
Майерс Г. Надежность программного обеспечения.- М.: Дрофа, 2008, - 360 с. |
|
74 |
Мендельсон Э. Введение в математическую логику, М.: Инси, 2001, - 320 с. |
|
75 |
Мешков А., Тихомиров Ю. Visual C++ и MFC.:B трех томах. Том 3 – Cn6.:BHV – Санкт – Петербург, 1997. – 384 с., ил. |
|
76 |
Миронченко А.С., Императивное и объектно-ориентированное программирование на Turbo Pascal и Delphi. Глубокое погружение [Текст]: ВМВ/ Миронченко, А.С. Одесса, 2007. – 408 с.: ил.; Загл. пер. и корешка: Императивное и объектно-ориентированное программирование на Turbo Pascal и Delphi.Глубокое погружение - 2000 экз. – ISBN 978-966-413-039-1 (рус.). |
|
77 |
Парижский, С.М. Delphi. Учимся на примерах [Текст]: МК-Пресс / Сергей Михайлович Парижский. Киев, 2005. – 216 с.: ил.; Загл. пер. и корешка: Delphi. Учимся на примерах - 2000 экз. – ISBN 966-8806-02-6 (рус.). |
|
78 |
Пестриков В. Delphi на примерах [Текст]: БХВ-Петербург / Виктор Пестриков, Артур Маслобоев.- СПб.: ул. Есенина, 2005. – 496 с.: ил.; Загл. пер. и корешка: Delphi на примерах - 4000 экз. – ISBN 5-94157-713-3 (рус.). |
|
79 |
Подбельский В.В., Фомин С.С. Программирование на языке Си: – 2-е изд., доп..-M.: Финансы и статистика, 2001. – 600 с. |
|
80 |
Пышкин, Е. Основные концепции и механизмы объектно-ориентированное программирования, СПб.: «BHV-Санкт-Петербург» 2005 г. - 640 с. ISBN: 5-94157-554-8 |
|
81 |
Ревич, Ю.В. Нестандартные приемы программирования на Delphi [Текст]: БХВ-Петербург / Юрий Ревич.- СПб.: ул. Есенина, 2005. – 560 с.: ил.; Загл. пер. и корешка: Нестандартные приемы программирования на Delphi - 4000 экз. – ISBN 5-94157-686-2 (рус.). |
|
82 |
Ричард Лейнекер. Энциклопедия Visual C++ – СПб.: Питер, 1999. – 1147 с. |
|
83 |
Романова Ю.Д. Информатика и информационные технологии: учебное пособие/Ю.Д. Романова, И.Г. Лесничая, В.И. Шестаков, И.В. Миссинг, П.А. Музычкин; под ред. Ю.Д. Романовой. – 3-е изд., перераб. и доп. – М.:Эксмо, 2008.-592 с. |
|
84 |
Рудаков А.В. Технология разработки программных продуктов. М.: Издательский центр «Академия», 2006. – 306 с. |
|
85 |
С.Бобровски «Oracle8: Архитектура» (М.: «Лори», 1998, 210 стр.); [оригинал: Steve Bobrowski «Oracle8. Architecture» Osborne/McGraw-Hill, 1998] |
|
86 |
С.В. Маклаков -- Создание информационных систем с AllFusion Modeling Suite. -- М.: Диалог-МИФИ, 2003 |
|
87 |
С.В. Черемных , И.О. Семенов , В.С. Ручкин -- Структурный анализ систем: IDEF-технологии. -- М.: Финансы и статистика, 2001 |
|
88 |
С.Р. Палмер , Дж.М. Фелсинг -- Практическое руководство по функционально-ориентированной разработке ПО.: Пер. с англ. -- М.: Вильямс, 2002 |
|
89 |
С.Смирнов «Работаем с Oracle». Учебное пособие. (М.: "Гелиос", 1998, 318 стр.) |
|
90 |
Сoxop, A.M. Логическая структура учебного материала. Вопросы дидактического анализа. М.: Педагогика, 1974. 192 с. |
|
91 |
Свешникова Е.Ю. Анализ режимов детерминированного хаоса в переходных процессах электроэнергетических систем. М.: Издательство «Агат», 2008. - 181 с. |
|
92 |
Сингх, Лей, Сафьян и др. «Oracle7.3. Руководство разработчика» (К.: «ДиаСофт», 1998, 730 стр.); [оригинал: Singh, Letgh, Zafian, et al. «Oracle7.3. Developer's Guide» SAMS Corporation, 1997] |
|
93 |
Синтес, А. Освой самостоятельно объектно-ориентированное программирование за 21 день, М.: ООО «И.Д. Вильямс», 2002 г. - 672 с. ISBN: 5-8459-0281-9 |
|
94 |
Скотт Урман. «ORACLE 8. Программирование на языке PL/SQL». (М.: «Лори», 1999, 608 стр.); [оригинал: Scott Urman «Oracle8 PL/SQL Programming» Osborne/McGraw-Hill, 1997] |
|
95 |
Современные средства разработки Borland для Oracle и MS SQL Server (+ CD-ROM): Андрей Боровский — Москва, БХВ-Петербург, 2007 г.- 400 с. |
|
96 |
Стернберг, Р.Дж. Практический интеллект / Под общ. ред. Р. Дж. Стернберга. СПб., Питер твердый, год издания: 2002, страниц: 272 ISBN: 5-318-00013-4 |
|
97 |
Стивенс, Р. Delphi. Готовые алгоритмы [Текст]: ДМК пресс [пер. с англ.] /Род Стивенс.- М., 2004. – 384с.: ил.; Загл. пер. и корешка: Delphi. Готовые алгоритмы - 6000 экз. – ISBN 5-94074-106-1 (рус.). |
|
98 |
Сухарев, М.В. Основы Delphi. Профессиональный подход[Текст]: Наука и Техника / Сухарев, М.В.- М., 2004. – 504с.: ил.; Загл. пер. и корешка: Основы Delphi. Профессиональный подход - 1000 экз. – ISBN 5-940-1069-2 (рус.) |
|
99 |
Т. Кватрани -- Визуальное моделирование с помощью Rational Rose 2002 и UML..: Пер. с англ. -- М.: Вильямс, 2003 |
|
100 |
Т. Конноли , К. Бегг -- Базы данных: проектирование, реализация и сопровождение. Теория и практика. 3-е издание.: Пер. с англ. -- М.: Вильямс, 2003 |
|
101 |
Технологии объектно-ориентированного программирования. Учебное пособие: П. Б. Хорев — Санкт-Петербург, Академия, 2004 г.- 448 с |
|
102 |
Тыугу Э.Х. Концептуальное программирование. - М.: Наука, 2001, - 256 с. |
|
103 |
Ф. Брукс -- Мифический человеко-месяц или как создаются программные системы: Пер. с англ. -- СПб.: Символ-Плюс, 1999 |
|
104 |
Ф. Крачтен -- Введение в Rational Unified Process.: Пер. с англ. -- М.: Вильямс, 2002 |
|
105 |
Федоров, А.В. Медиаобразование в педагогических вузах. –Таганрог: Изд-во Кучма, 2003 - 124 c. ISBN 5-901625-07-2 |
|
106 |
Фленов, М. Delphi в шутку и всерьез. Что умеют хакеры [Текст]: Питер/ Михаил Фленов, СПб.: Измайловский проспект, 2006. – 271 с. ил.; 24 см + 1 электрон. опт. диск. Загл. пер. и корешка: Delphi в шутку и всерьез. Что умеют хакеры - 1-е изд.; 4000 экз. – ISBN 5-469-00570-4 (рус.). |
|
107 |
Фленов, М. Библия для программиста в среде Delphi [Текст]: Питер/ Михаил Фленов, СПб.: Измайловский проспект, 2002. – 504 с. : ил.; Загл. пер. и корешка: Библия для программиста в среде Delphi - 1-е изд.; 2000 экз. – ISBN 5-94723-568-5 (рус.). |
|
108 |
Франка П. C++: 26 уроков для освоения языка; Учебный курс /Пер. с англ. П. Бибиков.-СПб.: Питер, 2000. – 521 с. |
|
109 |
Х. Гома -- UML. Проектирование систем реального времени, распределенных и параллельных приложений.: Пер. с англ. -- М.: ДМК, 2002 |
|
110 |
Хомоненко, А.Д. Delphi 7 в подлиннике [Текст]: БХВ-Петербург / Хомоненко, А.Д.– СПб.: Измайловский проспект, 2003. – 1216 с. : ил.; 20 см.; Загл. пер. и корешка: Delphi 7 в подлиннике - 1-е изд.; - 5000 экз. – ISBN 5-94157-299-7 (рус.). |
|
111 |
Хопкрофт Дж., Мотвани Р., Ульман Дж. «Введение в теорию автоматов, языков и вычислений» - М.: Издательство ВИЛЬЯМС, 2002. - 527с. |
|
112 |
Хьюз Дж., Мичтом Дж. Структурный подход к программированию. - М.: Мир, 2000, - 278 с. |
|
113 |
Чиртик, А. Трюки & эффекты Delphi [Текст]: Питер/ Чиртик, А., Борисок, В., Корвель, Ю., СПб.: Петергофское шоссе, 2007. – 400 с. ил.; 24 см 1 электрон. опт. диск. Загл. пер. и корешка: Трюки & эффекты Delphi - 1-е изд.; 2500 экз. – ISBN 978-5-91180-219-6 (рус.). |
|
114 |
Шадриков, В. Д. Познавательные процессы и способности в обучении: [Учеб. пособие для студентов пед. ин-тов.] / Шадриков В. Д., Ансимова Н. П., Корнеева Е. Н., М.: Просвещение. 1990. 142 с. ISBN 5-09-003061-8 |
|
115 |
Шилдт. Самоучитель С++:Пер. с англ. – 3-е изд.: – СПб.:БХВ-Петербург, 2001. -688 с. |
|
116 |
Шпак, Ю. А. Delphi 7 на примерах [Текст]: Юниор / Юрий Алексеевич Шпак, К.: ул. Совхозная, 2003. – 384 с. : ил.; Загл. пер. и корешка: Delphi 7 на примерах - 1-е изд.; 2000 экз. – ISBN 966-7323-28-5 (рус.). |
|
117 |
Э. Кармайкл , Д. Хейвуд -- Быстрая и качественная разработка программного обеспечения.: Пер. с англ. -- М.: Вильямс, 2003 |
|
А |
Общее представление RUP.doc |
|
Б |
Этапы и процессы CDM.doc |
|
В |
Средства визуального моделирования.doc |
|
Г |
Схема процесса создания программного комплекса.doc |
|
Д |
Модель проектирования ИС на основе объектно-ориентированного подхода.doc |