Технология программирования Методология объектно- ориентированного анализа и проектирования. - презентация

1 Технология программирования Методология объектно- ориентированного анализа и проектирования

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

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

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

5 Предметная область Процесс выделения или идентификации компонентов предметной области получил название концептуализации предметной области. При этом под компонентой понимают некоторую абстрактную единицу, которая обладает функциональностью, т. е. может выполнять определенные действия, связанные с решением поставленных задач. На предварительном этапе концептуализации рекомендуется использовать так называемые CRC- карточки (Component, Responsibility, Collaborator– компонента, обязанность, сотрудники). Для каждой выделенной компоненты предметной области разрабатывается собственная CRC-карточка (рис).

6 Предметная область Рис Общий вид CRC-карточки для описания компонентов предметной области

7 Методология ООАП Появление методологии ООАП потребовало 1)разработки различных средств концептуализации предметной области, и – 2) соответствующих специалистов, которые владели бы этой методологией. На данном этапе появляется относительно новый тип специалиста, который получил название аналитика или архитектора. Наряду со специалистами по предметной области аналитик участвует в построении концептуальной схемы будущей программы, которая затем преобразуется программистами в код. Отдельные компоненты выбираются таким образом, чтобы при последующей разработке их было удобно представить в форме классов и объектов.

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

9 Стандарты жизненного цикла Международные организации: IEEE читается «ай-трипл-и», Institute of Electrical and Electronic Engineers, Институт инженеров по электротехнике и электронике; ISO International Standards Organization, Международная организация по стандартизации; EIA Electronic Industry Association, Ассоциация электронной промышленности; IEC International Electrotechnical Commission, Международная комиссия по электротехнике;

10 Стандарты жизненного цикла Национальные и региональные институты и организации: ANSI American National Standards Institute, Американский национальный институт стандартов; SEI Software Engineering Institute, Институт программной инженерии; ECMA European Computer Manufactures Association, Европейская ассоциация производителей компьютерного оборудования;

11 Развитие стандарта ISO Стандарт ISO/IEC был опубликован 1 августа 1995 г. и явился первым международным стандартом, содержавшим представительный набор процессов ЖЦ, действий и задач в отношении ПО, которое рассматривалось как часть большей системы, а также применительно к программным продуктам и услугам. В 2002 года последовал стандарт ISO/IEC 15288, посвященный процессам ЖЦ систем. Широта применения ПС привела к тому, что ПО и процессы его разработки не могли рассматриваться в отрыве от систем, но только как составная часть системы и процесса её создания. В Дополнениях к стандарту ISO/IEC в 2004 вышел стандарт ISO/IEC , где были введены цель процесса и его выходы и определена эталонная модель процесса. Международный стандарт ISO/IEC 12207:2008, представляет собой переработанные и исправленные дополнения к стандарту ISO/IEC и является первым шагом в стратегии SC7 по гармонизации спецификаций, имеющей целью создание полностью интегрированного набора процессов ЖЦ систем и программных средств и руководства по их применению. ISO/IEC Standard for Information Technology Software Life Cycle Processes (процессы жизненного цикла ПО, есть его российский аналог ГОСТ Р process.ru/software_engineering/software_engineering_iso_iec_ html). process.ru/software_engineering/software_engineering_iso_iec_ html Определяет общую структуру жизненного цикла ПО в виде 3-х ступенчатой модели, состоящей из: процессов, видов деятельности и задач. Стандарт описывает вводимые элементы в терминах их целей и результатов, тем самым задавая неявно возможные взаимосвязи между ними, но не определяя четко структуру этих связей, возможную организацию элементов в рамках проекта и метрики, по которым можно было бы отслеживать ход работ и их результативность.

12 Группа стандартов ISO В основе практически всех современных промышленных технологий создания ПС лежит международный стандарт ISO/IEC «Системная и программная инженерия. Процессы жизненного цикла программных средств.» В состав семейства стандартов входят: ISO/IEC 12207:1995 «Information technology–Software life cycle processes» российский аналог - ГОСТ Р ИСО/МЭК … ISO/IEC 12207:2008 Systems and software engineering Software life cycle processes стандарт ISO, описывающий процессы жизненного цикла программного обеспечения. Федеральным агентством по техническому регулированию и метрологии РФ г. взамен ГОСТ Р ИСО/МЭК принят стандарт ГОСТ Р ИСО/МЭК «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств», идентичный международному стандарту ISO/IEC 12207:2008 «System and software engineering Software life cycle processes».

13 Группа стандартов ISO ГОСТ Р ИСО/МЭК Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств Данная редакция: включает и развивает положения Дополнений 2002 г. и 2004 г. использует терминологию, согласованную со стандартом ISO/IEC 15288:2008; по возможности использует наименование и структуру процессов аналогичную той, что содержится в стандарте ISO/IEC 15288:2008; дает возможность сообществу пользователей получить полностью гармонизированные стандарты и обеспечивает стабильность - стандарт в максимальной мере совместим с прошлыми редакциями; использует результаты десятилетнего опыта разработки и применения стандартов ISO/IEC и ISO/IEC

14 Группа стандартов ISO Стандарт ISO/IEC определяет общую структуру жизненного цикла ПО в виде 3-х ступенчатой модели, состоящей из: процессов, видов деятельности и задач. Стандарт описывает вводимые элементы в терминах их целей и результатов, тем самым задавая -неявно возможные взаимосвязи между ними, но не определяя четко структуру этих связей, - возможную организацию элементов в рамках проекта и - метрики, по которым можно было бы отслеживать ход работ и их результативность.

15 Группа стандартов ISO Самыми крупными элементами являются процессы жизненного цикла ПО (lifecycle processes). Всего выделено 18 процессов, которые объединены в 4 группы. Первая Группа: Основные процессы : Заказ ПО; Поставка ПО (в использование); Разработка ПО; Эксплуатация ПО; Сопровождение ПО

16 Группа стандартов ISO Процессы жизненного цикла ПО (lifecycle processes): Вторая группа: Поддерживающие процессы : Документирование; Управление конфигурациями; Обеспечение качества; Верификация; Валидация; Совместные экспертизы; Аудит; Разрешение проблем

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

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

19 Группа стандартов ISO Процессы жизненного цикла ПО (lifecycle processes): Третья группа: Организационные процессы : Управление проектом; Управление инфраструктурой; Усовершенствование процессов; Управление персоналом

20 Группа стандартов ISO процессы жизненного цикла ПО (lifecycle processes) Четвертая группа: Адаптация Адаптация описываемых стандартом процессов под нужды конкретного проекта

21 Группа стандартов ISO Самыми крупными элементами являются процессы жизненного цикла ПО (lifecycle processes). Всего выделено 18 процессов, которые объединены в 4 группы. Основные процессы Поддерживающие процессы Организационные процессы Адаптация Заказ ПО; Поставка ПО (в использование); Разработка ПО; Эксплуатация ПО; Сопровождение ПО Документирование; Управление конфигурациями; Обеспечение качества; Верификация; Валидация; Совместные экспертизы; Аудит; Разрешение проблем Управление проектом; Управление инфраструктурой; Усовершенствовани е процессов; Управление персоналом Адаптация описываемых стандартом процессов под нужды конкретного проекта

22 Группа стандартов ISO Процессы строятся из отдельных видов деятельности (activities). Стандартом определены 74 вида деятельности, связанной с разработкой и поддержкой ПО. Ниже мы упомянем только некоторые из них: Поставка ПО включает такие виды деятельности: инициация приобретения, подготовка запроса предложений, подготовка контракта, анализ поставщиков, получение ПО и завершение приобретения.

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

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

25 Группа стандартов ISO Управление проектом включает запуск проекта и определение его рамок, планирование, выполнение проекта и надзор за его выполнением, экспертизу и оценку проекта, свертывание проекта. Каждый вид деятельности нацелен на решение одной или нескольких задач (tasks). Всего определено 224 различные задачи. Например: Развертывание процесса разработки состоит из определения модели жизненного цикла, документирования и контроля результатов отдельных работ, выбора используемых стандартов, языков, инструментов и пр, Перенос ПО между платформами состоит из разработки плана переноса, оповещения пользователей, выполнения анализа произведенных действий и пр.

26 Группа стандартов ISO Согласно принятым взглядам ЖЦ программы состоит из следующих этапов: Анализа предметной области и формулировки требований к программе Проектирования структуры программы Реализации программы в кодах (собственно программирования) Внедрения программы Сопровождения программы Отказа от использования программы

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

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

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

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

31 Методология ООАП CASE - средства Методология ООАП тесно связана с концепцией автоматизированной разработки программного обеспечения (Computer Aided Software Engineering, CASE). Ранние CASE-средства были простой надстройкой над некоторой системой управления базами данных (СУБД). Хотя визуализация процесса разработки концептуальной схемы БД имеет немаловажное значение, она не решает проблем разработки приложений других типов. Неоднозначная графическая нотация, реализованная в том или ином CASE-средстве. Если языки программирования имеют строгий синтаксис, то попытки предложить подходящий синтаксис для визуального представления концептуальных схем БД были восприняты далеко неоднозначно. На этом фоне появление унифицированного языка моделирования (Unified Modeling Language, UML), который ориентирован на решение задач первых двух этапов ЖЦ программ, было воспринято с большим оптимизмом всем сообществом корпоративных программистов

32 Методология ООАП Последнее, на что следует обратить внимание, это осознание необходимости построения предварительной модели программной системы, которую, согласно современным концепциям ООАП, следует считать результатом первых этапов ЖЦ программы. Язык UML даже в своем названии имеет отношение к моделированию. Таким образом, мы переходим к теме, которая традиционно не рассматривается в изданиях по ООАП, но имеющая самое прямое отношение к процессу построения моделей и, собственно, моделированию. Речь идет о методологии системного анализа и системного моделирования.

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

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

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

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

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

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

39 Методология системного анализа и системного моделирования Наиболее общей моделью системы является так называемая модель «черного ящика». В этом случае система представляется в виде прямоугольника, внутреннее устройство которого скрыто от аналитика или неизвестно. Однако система не является полностью изолированной от внешней среды, поскольку последняя оказывает на систему некоторые информационные или материальные воздействия. Такие воздействия получили название входных воздействий. В свою очередь, система также оказывает на среду или другие системы определенные информационные или материальные воздействия, которые получили название выходных воздействий. Графически данная модель может быть изображена следующим образом (рис).

40 Методология системного анализа и системного моделирования Рис Графическое изображение модели системы в виде «черного ящика» Ценность моделей, подобных модели «черного ящика», весьма условна.

41 Методология системного анализа и системного моделирования Для построения адекватных моделей и их последующего конструктивного применения были разработаны достаточно серьезные теоретические методы, основанные на развитии математических и логических средств моделирования, а также предложены различные формальные и графические нотации, отражающие специфику решаемых задач. Важно представлять, что унификация любого языка моделирования тесно связана с методологией системного моделирования, т. е. с системой воззрений и принципов рассмотрения сложных явлений и объектов как моделей сложных систем. Рассмотрение особенностей языка UML связано с вопросами логического и информационного моделирования систем

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

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