…жна только тогда, когда базовый класс определяет метод сравнения.

Преимущества объектного подхода. Объектный подход позволяет создавать системы, которые воплощают пять атрибутов (свойств) сложных (хорошо структурированных) систем (иерархия, разделение на подсистемы, внутренние и внешние связи, низший уровень абстракции, развитие от простого к сложному). Еще пять преимуществ:

1. 1. Объектный подход позволяет в полной мере использовать выразительные возможности объектных и объектно-ориентированных языков программирования (их преимущества не всегда очевидны)

   2. Использование объектного подхода существенно повышает качество разработки в целом и её фрагментов.

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

   4. Объектный подход уменьшает риск разработки сложных систем потому что:

а) процесс интеграции растягивается во времени жизненного цикла системы;

б) объектный подход включает ряд хорошо продуманных этапов проектирования (что также уменьшает степень риска и повышает степень уверенности в правильности принимаемых решений).

1. 1. Объектный подход ориентирован на человеческое восприятие мира (для многих людей является естественным ООП к системам)

Общие выводы по теме «Объектный подход»

1. Развитие программной технологии привело к созданию методов О.О. Анализа, Проектирования и Программирования, которые направлены на решение задачи программирования больших систем.

2. Существует ряд приемов (стилей) программирования: процедурно-ориентированный, объектно-ориентированный, логически-ориентированный, ориентированный на правила и ориентированный на ограничения.

3. Объектный подход образует концептуальную основу для объектно-ориентированной методологии; он включает принципы абстрагирования, ограничения доступа, модульности, иерархии, типизации, параллелизма и устойчивости.

4. Абстрагирование означает выделения таких существенных характеристик объекта, которые отличают его от всех других объектов и, таким образом, четко определяют особенности данного объекта с точки зрения дальнейшего его рассмотрения.

5. Ограничение доступа – процесс защиты отдельных элементов объекта, не затрагивающий существенных характеристик объекта как целого.

6. Модульность – свойство системы, связанное с возможностью ее декомпозиции на ряд тесно связанных модулей.

7. Иерархия – ранжированная или упорядоченная система абстракций.

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

9. Параллелизм – свойство, отличающее активные объекты от неактивных.

10. Устойчивость – свойство объектов существовать во времени и (или) пространстве.

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

 

59__RAD-технология разработки информационных систем.

Одним из возможных подходов к разработке ПО в рамках спиральной модели ЖЦ является получившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки ПО, содержащий 3 элемента:

• небольшую команду программистов (от 2 до 10 человек);

• короткий, но тщательно проработанный производственный график (от 2 до 6 мес.);

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

Команда разработчиков должна представлять из себя группу профессионалов, имеющих опыт в анализе, проектировании, генерации кода и тестировании ПО с использованием CASE-средств. Члены коллектива должны также уметь трансформировать в рабочие прототипы предложения конечных пользователей.

Жизненный цикл ПО по методологии RAD состоит из четырех фаз:

• фаза анализа и планирования требований;

• фаза проектирования;

• фаза построения;

• фаза внедрения.

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

На фазе проектирования часть пользователей принимает участие в техническом проектировании системы под руководством специалистов-разработчиков. CASE-средства используются для быстрого получения работающих прототипов приложений. Пользователи, непосредственно взаимодействуя с ними, уточняют и дополняют требования к системе, которые не были выявлены на предыдущей фазе. Более подробно рассматриваются процессы системы. Анализируется и, при необходимости, корректируется функциональная модель. Каждый процесс рассматривается детально. При необходимости для каждого элементарного процесса создается частичный прототип: экран, диалог, отчет, устраняющий неясности или неоднозначности. Определяются требования разграничения доступа к данным. На этой же фазе происходит определение набора необходимой документации.

После детального определения состава процессов оценивается количество функциональных элементов разрабатываемой системы и принимается решение о разделении ИС на подсистемы, поддающиеся реализации одной командой разработчиков за приемлемое для RAD-проектов время - порядка 60 - 90 дней. С использованием CASE-средств проект распределяется между различными командами (делится функциональная модель). Результатом данной фазы должны быть:

• общая информационная модель системы;

• функциональные модели системы в целом и подсистем, реализуемых отдельными командами разработчиков;

• точно определенные с помощью CASE-средства интерфейсы между автономно разрабатываемыми подсистемами;

• построенные прототипы экранов, отчетов, диалогов.

Все модели и прототипы должны быть получены с применением тех CASE-средств, которые будут использоваться в дальнейшем при построении системы. Данное требование вызвано тем, что в традиционном подходе при передаче информации о проекте с этапа на этап может произойти фактически неконтролируемое искажение данных. Применение единой среды хранения информации о проекте позволяет избежать этой опасности.

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

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

После окончания работ каждой отдельной команды разработчиков производится постепенная интеграция данной части системы с остальными, формируется полный программный код, выполняется тестирование совместной работы данной части приложения с остальными, а затем тестирование системы в целом. Завершается физическое проектирование системы:

• определяется необходимость распределения данных;

• производится анализ использования данных;

• производится физическое проектирование базы данных;

• определяются требования к аппаратным ресурсам;

• определяются способы увеличения производительности;

• завершается разработка документации проекта.

Результатом фазы является готовая система, удовлетворяющая всем согласованным требованиям.

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

Следует, однако, отметить, что методология RAD, как и любая другая, не может претендовать на универсальность, она хороша в первую очередь для относительно небольших проектов, разрабатываемых для конкретного заказчика. Если же разрабатывается типовая система, которая не является законченным продуктом, а представляет собой комплекс типовых компонент, централизованно сопровождаемых, адаптируемых к программно-техническим платформам, СУБД, средствам телекоммуникации, организационно-экономическим особенностям объектов внедрения и интегрируемых с существующими разработками, на первый план выступают такие показатели проекта, как управляемость и качество, которые могут войти в противоречие с простотой и скоростью разработки. Для таких проектов необходимы высокий уровень планирования и жесткая дисциплина проектирования, строгое следование заранее разработанным протоколам и интерфейсам, что снижает скорость разработки.

Методология RAD неприменима для построения сложных расчетных программ, операционных систем или программ управления космическими кораблями, т.е. программ, требующих написания большого объема (сотни тысяч строк) уникального кода.

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

В качестве итога перечислим основные принципы методологии RAD:

• разработка приложений итерациями;

• необязательность полного завершения работ на каждом из этапов жизненного цикла;

• обязательное вовлечение пользователей в процесс разработки ИС;

• необходимое применение CASE-средств, обеспечивающих целостность проекта;

• применение средств управления конфигурацией, облегчающих внесение изменений в проект и сопровождение готовой системы;

• необходимое использование генераторов кода;

• использование прототипирования, позволяющее полнее выяснить и удовлетворить потребности конечного пользователя;

• тестирование и развитие проекта, осуществляемые одновременно с разработкой;

• ведение разработки немногочисленной хорошо управляемой командой профессионалов;

• грамотное руководство разработкой системы, четкое планирование и контроль выполнения работ.

 

60__Каскадный и спиральный жизненные циклы разработки информационных систем.

Под моделью ЖЦ понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ. Модель ЖЦ зависит от специфики ИС и специфики условий, в которых последняя создается и функционирует

К настоящему времени наибольшее распространение получили следующие две основные модели ЖЦ:

• каскадная модель (70-85 г.г.);

• спиральная модель (86-90 г.г.).

В изначально существовавших однородных ИС каждое приложение представляло собой единое целое. Для разработки такого типа приложений применялся каскадный способ. Его основной характеристикой является разбиение всей разработки на этапы, причем переход с одного этапа на следующий происходит только после того, как будет полностью завершена работа на текущем (рис. 1.1). Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.

Положительные стороны применения каскадного подхода заключаются в следующем:

• на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности;

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

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

Основным недостатком каскадного подхода является существенное запаздывание с получением результатов. Согласование результатов с пользователями производится только в точках, планируемых после завершения каждого этапа работ, требования к ИС "заморожены" в виде технического задания на все время ее создания. Таким образом, пользователи могут внести свои замечания только после того, как работа над системой будет полностью завершена. В случае неточного изложения требований или их изменения в течение длительного периода создания ПО, пользователи получают систему, не удовлетворяющую их потребностям. Модели (как функциональные, так и информационные) автоматизируемого объекта могут устареть одновременно с их утверждением.

Для преодоления перечисленных проблем была предложена спиральная модель ЖЦ, делающая упор на начальные этапы ЖЦ: анализ и проектирование. На этих этапах реализуемость технических решений проверяется путем создания прототипов. Каждый виток спирали соответствует созданию фрагмента или версии ПО, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации.

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

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

 

61__Виды обеспечения и этапы разработки автоматизированных информационных систем

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

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

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

Составляющие АИС управления

Обеспечивающая часть:
1.    Техническое обеспечение.
2.    Математическое обеспечение.
3.    Программное обеспечение.
4.    Информационное обеспечение.
5.    Организационное обеспечение.
6.    Методическое обеспечение.
7.    Правовое обеспечение.
8.    Лингвистическое обеспечение.

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

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

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

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

Методологическое и организационное обеспечение – это совокупность методов средств и документов, регулирующих взаимодействие персонала ИС с техническими средствами и между собой в процессе разработки и эксплуатации ИС.

Организационное обеспечение реализует следующие функции:

1. Анализ существующей системы управления организацией и выявление задач подлежащих автоматизации.

2. Подготовка задач к решению на компьютере, включая техническое задание на проектирование ИС и технико-экономическое обоснование её эффективности.

3. Разработка управленческих решений по составу и структуре организации методологии решения задач, направленных на повышение эффективности решения.

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

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

Функциональная часть – обеспечивает выполнение задач и назначение ИС, обычно в ИС функциональная часть разбивается на подсистемы по функциональным признакам.

Функциональная часть представляет собой:

• уровень управления (высший, средний, низкий);

• вид управляемого ресурса (материальные, трудовые, финансовые и т.д.);

• сферу применения;

• функции управления и период управления;

Стадии разработки автоматизированных информационных систем:

1. Техническое задание – выполняется информационное обследование.

2. Эскизный проект – детализация технического задания.

3. Технический проект – разработка и оценка проекта.

4. Рабочий проект – построение и тестирование.

5. Внедрение, управление проектом и оценка риска.

В случае применения CASE-технологии разработки информационной системы первые три стадии (ТЗ, ЭП и ТП) объединяются в одну стадию "Предварительное проектирование", за которой следуют стадии РП и ВН.

Разработка включает в себя все работы по созданию ПО и его компонент в соответствии с заданными требованиями, включая оформление проектной и эксплуатационной документации, подготовку материалов, необходимых для проверки работоспособности и соответствующего качества программных продуктов, материалов, необходимых для организации обучения персонала и т.д. Разработка ПО включает в себя, как правило, анализ, проектирование и реализацию (программирование).

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

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