40037

Методология RAD - Rapid Application Development

Реферат

Информатика, кибернетика и программирование

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

Русский

2013-10-13

31.05 KB

84 чел.

Методология RAD - Rapid Application Development

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

Основные особенности методологии RAD

    Методология разработки информационных систем, основанная на использовании средств быстрой разработки приложений, получила в последнее время широкое распространение и приобрела название методологии быстрой разработки приложений - RAD (Rapid Application Development). Данная методология охватывает все этапы жизненного цикла современных информационных систем.
    RAD - это комплекс специальных инструментальных средств быстрой разработки прикладных информационных систем, позволяющих оперировать с определенным набором графических объектов, функционально отображающих отдельные информационные компоненты приложений.
    Под методологией быстрой разработки приложений обычно понимается процесс разработки информационных систем, основанный на трех основных элементах:

  1.  небольшой команде программистов (обычно от 2 до 10 человек);
  2.  тщательно проработанный производственный график работ, рассчитанный на сравнительно короткий срок разработки (от 2 до 6 мес.);
  3.  итерационная модель разработки, основанная на тесном взаимодействии с заказчиком - по мере выполнения проекта разработчики уточняют и реализуют в продукте требования, выдвигаемые заказчиком.

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

  1.  используется итерационная (спиральная) модель разработки;
  2.  полное завершение работ на каждом из этапов жизненного цикла не обязательно;
  3.  в процессе разработки информационной системы необходимо тесное взаимодействие с заказчиком и будущими пользователями;
  4.  необходимо применение CASE-средств и средств быстрой разработки приложений;
  5.  необходимо применение средств управления конфигурацией, облегчающих внесение изменений в проект и сопровождение готовой системы;
  6.  необходимо использование прототипов, позволяющее полнее выяснить и реализовать потребности конечного пользователя;
  7.  тестирование и развитие проекта осуществляются одновременно с разработкой;
  8.  разработка ведется немногочисленной и хорошо управляемой командой профессионалов;
  9.  необходимы грамотное руководство разработкой системы, четкое планирование и контроль выполнения работ.

Объектно-ориентированный подход

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

ПРИМЕЧАНИЕ В данном разделе мы лишь поверхностно рассмотрели особенности и преимущества объектно-ориентированных методов проектирования. Более подробно этот вопрос будет обсуждаться далее.

Визуальное программирование

    Применение принципов объектно-ориентированного программирования позволило создать принципиально новые средства проектирования приложений, называемые средствами визуального программирования. Визуальные инструменты RAD позволяют создавать сложные графические интерфейсы пользователя вообще без написания кода программы. При этом разработчик может на любом этапе наблюдать то, что закладывается в основу принимаемых решений.
    Визуальные средства разработки оперируют в первую очередь со стандартными интерфейсными объектами - окнами, списками, текстами, которые легко можно связать с данными из базы данных и отобразить на экране монитора. Другая группа объектов представляет собой стандартные элементы управления - кнопки, переключатели, флажки, меню и т. п., с помощью которых осуществляется управление отображаемыми данными. Все эти объекты могут быть стандартным образом описаны средствами языка, а сами описания сохранены для дальнейшего повторного использования.
    В настоящее время существует довольно много различных визуальных средств разработки приложений. Но все они могут быть разделены на две группы - универсальные и специализированные.
    Среди универсальных систем визуального программирования сейчас наиболее распространены такие, как Borland Delphi и Visual Basic. Универсальными мы их называем потому, что они не ориентированы на разработку только приложений баз данных - с их помощью могут быть разработаны приложения почти любого типа, в том числе и информационные приложения. Причем программы, разрабатываемые с помощью универсальных систем, могут взаимодействовать практически с любыми системами управления базами данных. Это обеспечивается как использованием драйверов ODBC или OLE DB, так и применением специализированных средств (компонентов).
    Специализированные средства разработки ориентированы только на создание приложений баз данных. Причем, как правило, они привязаны к вполне определенным системам управления базами данных. В качестве примера таких систем можно привести Power Builder фирмы Sybase (естественно, предназначенный для работы с СУБД Sybase Anywhere Server) и Visual FoxPro фирмы Microsoft.
    Поскольку задачи создания прототипов и разработки пользовательского интерфейса, по существу, слились, программист получил непрерывную обратную связь с конечными пользователями, которые могут не только наблюдать за созданием приложения, но и активно участвовать в нем, корректировать результаты и свои требования. Это также способствует сокращению сроков разработки и является важным психологическим аспектом, который привлекает к RAD все большее число пользователей.
    Визуальные инструменты RAD позволяют максимально сблизить этапы создания информационных систем: анализ исходных условий, проектирование системы, разработка прототипов и окончательное формирование приложений становятся сходными, так как на каждом этапе разработчики оперируют визуальными объектами.

Событийное программирование

    Логика приложения, построенного с помощью RAD, является событийно-ориентированной. Это означает следующее: каждый объект, входящий в состав приложения, может генерировать события и реагировать на события, генерируемые другими объектами. Примерами событий могут быть: открытие и закрытие окон, нажатие кнопки, нажатие клавиши клавиатуры, движение мыши, изменение данных в базе данных и т. п.
    Разработчик реализует логику приложения путем определения обработчика каждого события - процедуры, выполняемой объектом при наступлении соответствующего события. Например, обработчик события "нажатие кнопки" может открыть диалоговое окно. Таким образом, управление объектами осуществляется с помощью событий.
    Обработчики событий, связанных с управлением базой данных (DELETE, INSERT, UPDATE), могут реализовываться в виде триггеров на клиентском или серверном узле. Такие обработчики позволяют обеспечить ссылочную целостность базы данных при операциях удаления, вставки и обновления, а также автоматическую генерацию первичных ключей.

Фазы жизненного цикла в рамках методологии RAD

    При использовании методологии быстрой разработки приложений жизненный цикл информационной системы состоит из четырех фаз:

  1.  фаза анализа и планирования требований;
  2.  фаза проектирования;
  3.  фаза построения;
  4.  фаза внедрения.

    Рассмотрим каждую из них более подробно.

Фаза анализа и планирования требований

    На данной фазе выполняются следующие работы:

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

ПРИМЕЧАНИЕ Определение указанных выше требований выполняется совместно будущими пользователями системы и разработчиками.

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

    Если реализация проекта принципиально возможна, то результатом фазы анализа и планирования требований будет список функций разрабатываемой информационной системы с указанием их приоритетов и предварительные функциональные и информационные модели системы.

Фаза проектирования

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

ПРИМЕЧАНИЕ Термин CASE (Computer Aided Software/System Engineering) используется в настоящее время в весьма широком смысле. Первоначальное значение термина CASE ограничивалось лишь вопросами автоматизации разработки программного обеспечения. Однако в дальнейшем значение этого термина расширилось и приобрело новый смысл, охватывающий процесс разработки сложных информационных систем в целом. Теперь под термином "CASE-средства" понимаются программные средства, поддерживающие процессы создания и сопровождения информационных систем, включая анализ и формулировку требований, проектирование прикладного программного обеспечения и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы. Подробному рассмотрению CASE-технологий в данной книге посвящена глава 6 "Проектирование структуры базы данных".

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

ПРИМЕЧАНИЕ Для построения всех моделей и прототипов должны быть использованы именно те CASE-средства, которые будут затем применяться при построении системы. Данное требование связано с тем, что при передаче информации о проекте с этапа на этап может произойти фактически неконтролируемое искажение данных. Применение единой среды хранения информации о проекте позволяет избежать этой опасности.

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

  1.  общая информационная модель системы;
  2.  функциональные модели системы в целом и подсистем, реализуемых отдельными командами разработчиков;
  3.  точно определенные с помощью CASE-средства интерфейсы между автономно разрабатываемыми подсистемами;
  4.  построенные прототипы экранов, диалогов и отчетов.

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

Фаза построения

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

  1.  определяется необходимость распределения данных;
  2.  производится анализ использования данных;
  3.  производится физическое проектирование базы данных;
  4.  определяются требования к аппаратным ресурсам;
  5.  определяются способы увеличения производительности;
  6.  завершается разработка документации проекта.

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

Фаза внедрения

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

ПРИМЕЧАНИЕ Приведенная схема разработки информационной системы не является универсальной. Вполне возможны различные отклонения от нее. Это связано с зависимостью схемы выполнения проекта от начальных условий, при которых начинается разработка (например, разрабатывается совершенно новая система или на предприятии уже существует некоторая информационная система). Во втором случае существующая система может либо использоваться в качестве прототипа новой системы, либо интегрироваться в новую разработку в качестве одной из подсистем.

Ограничения методологии RAD

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

Стандарты и методики

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

  1.  стандарты на продукты и услуги;
  2.  стандарты на процессы и технологии;
  3.  стандарты на формы коллективной деятельности, или управленческие стандарты.

Виды стандартов

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

  1.  по предмету стандартизации. К этой группе можно отнести функциональные стандарты (стандарты на языки программирования, интерфейсы, протоколы) и стандарты на организацию жизненного цикла создания и использования информационных систем и программного обеспечения;
  2.  по утверждающей организации. Здесь можно выделить официальные международные, официальные национальные или национальные ведомственные стандарты (например, ГОСТы, ANSI, IDEF0/1), стандарты международных консорциумов и комитетов по стандартизации (например, консорциума OMG), стандарты "де-факто" - официально никем не утвержденные, но фактически действующие (например, стандартом "де-факто" долгое время были язык взаимодействия с реляционными базами данных SQL и язык программирования C), фирменные стандарты (например, Microsoft ODBC);
  3.  по методическому источнику. К этой группе относятся различного рода методические материалы ведущих фирм-разработчиков программного обеспечения, фирм-консультантов, научных центров, консорциумов по стандартизации.


 

А также другие работы, которые могут Вас заинтересовать

26997. Понятие и признаки нормы права.структура юридической нормы 6.87 KB
  понятие и признаки нормы права.структура юридической нормы. ПРИЗНАКИ: 1 регулятор типовых общественных отношенийсоциальная роль нормы; 2 общий НЕПЕРСОНИФИЦИРОВАННЫЙ характер; 3 ОБЩЕОБЯЗАТЕЛЬНЫЙ характер; 4 имеет предоставительнообязывающий характерс одной стороны свобода действийнаправленных на удовлетворение интересовс другойобязывает совершать или не совершать определенные действияограничивая свободу отдельных лиц; 5 устанавливается или САНКЦИОНИРУЕТСЯ ГОСМ; 6 реализация нормы обеспечивается мерами ГОС.ответственность за...
26998. Классификация норм права 6.38 KB
  ПРИЗНАКИ: 1 регулятор типовых общественных отношенийсоциальная роль нормы; 2 общий НЕПЕРСОНИФИЦИРОВАННЫЙ характер; 3 ОБЩЕОБЯЗАТЕЛЬНЫЙ характер; 4 имеет предоставительнообязывающий характерс одной стороны свобода действийнаправленных на удовлетворение интересовс другойобязывает совершать или не совершать определенные действияограничивая свободу отдельных лиц; 5 устанавливается или САНКЦИОНИРУЕТСЯ ГОСМ; 6 реализация нормы обеспечивается мерами ГОС.ответственность за нарушение норм; 7 ФОРМАЛЬНАЯ ОПРЕДЕЛЕННОСТЬимеет строго...
27000. Способы изложения норм права в статьях НПА 4.22 KB
  Способы изложения норм права в статьях НПА. НПАакт правотворчества принятый в особом порядке строго определенными субъектами и содержащий норму права. Статья НПАформа выражения способ изложения правовой нормы.Логическая структура нормы совпадает со структурой статьи НПА.
27001. Правоотношения: понятие, состав, виды 6.22 KB
  ПРАВООТНОШЕНИЯ – охраняемые государством и урегулированные нормами права общественные отношениявозникающие вследствие воздействия норм права на поведение людей и характеризующиеся наличием субъективных прав и юридических обязанностей для их участников. ПРИЗНАКИ: 1 Это разновидность социальных отношений в обществе 2 возникаютпрекращаются или изменяютсякак правилона основе норм права в случае наступления предусмотренных нормой фактов. 3 Сторонами правоотношения могут быть лицаобладающие качествами субъекта права правосубъектностью 4 В...
27002. Субъекты правоотношений. Правосубъектность. Правоспособность, дееспособность, деликтоспособность 7.43 KB
  ПРАВООТНОШЕНИЯ–охраняемые государством и урегулированные нормами права общественные отношениявозникающие вследствие воздействия норм права на поведение людей и характеризующиеся наличием субъективных прав и юридических обязанностей для их участников. СУБЪЕКТЫ–участники правоотношенийимеющие субъективные права и юридические обязанностизакрепленные в нормах права. Коллективные субъекты: государственные государствоорганысубъектыгос предприятияучреждения социальные общности нациинаселение определенного районатрудовой коллектив...
27003. Содержание правоотношения. Субъективное право и юридическая обязанность 6.28 KB
  ПРАВООТНОШЕНИЕохраняемые государством и урегулированные нормами права общественные отношениявозникающие вследствие воздействия норм права на поведение людей и характеризующиеся наличием субъективных прав и юридических обязанностей для их участников. СОДЕРЖАНИЕ правоотношения составляют субъективные права и юридические обязанности. ЮРИДИЧЕСКОЕ СОДЕРЖАНИЕ–это возможность определенных действийуправомоченным лицомдолжностнымнеобходимость выполнения тех или иных действий обязанным лицома также необходимость соблюдения запретовустановленных...
27004. Объекты правоотношений их виды 5.99 KB
  их виды ПРАВООТНОШЕНИЕохраняемые государством и урегулированные нормами права общественные отношениявозникающие вследствие воздействия норм права на поведение людей и характеризующиеся наличием субъективных прав и юридических обязанностей для их участников. ПРИЗНАКИ: 1 Это разновидность социальных отношений в обществе 2 возникаютпрекращаются или изменяютсякак правилона основе норм права в случае наступления предусмотренных нормой фактов. 3 Сторонами правоотношения могут быть лицаобладающие качествами субъекта права правосубъектностью...
27005. Понятие и признаки правонарушений 3.82 KB
  Правонарушениевиновное поведение праводееспособного индивидакоторе противоречит предписаниям норм правапричиняет вред другим лицам и влечет за собой юридическую ответственность. строго определенные признакипозволяющие отличить правонарушение от нарушений других нормобщественного приличия: 1 такое поведение человекакоторое выражается в ДЕЙСТВИИ или БЕЗДЕЙСТВИИдолжен был совершить определенные действияпредусмотренные нормой правано не совершил их. 2 такое поведение человекакоторое противоречит предписаниям ПРАВАПРОТИВОПРАВНОЕ...