МАГНИТОГОРСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ Вопросы государственного экзамена по информатике

МАГНИТОГОРСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ Вопросы государственного экзамена по информатике Направление «Бизнес-информатика» Дисциплина «ОПД. Ф. 05 Проектирование информационных систем» = www. masu-inform. ru

МАГНИТОГОРСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ 1. Основные компоненты технологии проектирования ИС. Выбор технологии проектирования ИС и краткая характеристика применяемых технологий проектирования. Требования, предъявляемые к технологии проектирования ИС • Основные компоненты технологии проектирования ИС (методология метод средства). Краткая характеристика и выбор технологии проектирования ИС (каноническое, типовое, автоматизированное). Требования, предъявляемые к технологии проектирования ИС. 2. Стадии и этапы процесса канонического проектирования ИС в соответствии с ГОСТ 34. 601 -90 «ИТ. Комплекс стандартов на АС. Стадии создания» . • Стадии и этапы процесса канонического проектирования ИС в соответствии с ГОСТ 34. 601 90 «ИТ. Комплекс стандартов на АС. Стадии создания» : Краткая характеристика стадий создания АС (Формирование требований к автоматизированной системе. Разработка концепции автоматизированной системы. Техническое задание. Эскизный проект. Технический проект. Рабочая документация. Ввод в действие. Сопровождение автоматизированной системы). 3. Предпроектное обследование предметной области в соответствии с ГОСТ 34. 601 -90 «ИТ. Комплекс стандартов на АС. Стадии создания» . • Состав работ на предпроектных стадиях, определенных ГОСТ 34. 601 90 «ИТ. Комплекс стандартов на АС. Стадии создания» . Цель, задачи и результаты предпроектного обследования. 4. Автоматизированное проектирование ИС на основе функционально-ориентированного и объектноориентированного подходов с использованием CASE-технологий. • Разработка моделей (SADT функциональная (IDEF 0); DFD; ERD (IDEF 1 X); STD; e. EPC; вариантов использования; прецедентов и т. д) в зависимости от используемых CASE технологий на соответствующих этапах проектирования ИС. www. masu-inform. ru 2

1. Основные компоненты технологии проектирования ИС. Выбор технологии проектирования ИС и краткая характеристика применяемых технологий проектирования. Требования, предъявляемые к технологии проектирования ИС Основные компоненты технологии проектирования ИС (методология метод средства). Краткая характеристика и выбор технологии проектирования ИС (каноническое, типовое, автоматизированное). Требования, предъявляемые к технологии проектирования ИС. Важным решением, принимаемым при создании ИС, является выбор и обоснование методологии и технологии разработки системы. Это дает возможность решить поставленную задачу с оптимальными затратами. Использование методологии при создании ИС упорядочивает процесс разработки и позволяет решить проблемы, возникающие из за повышенной сложности систем. Технология проектирования характеризуется рядом компонентов, определяющих подход к созданию информационной системы. Компоненты технологии проектирования выстраиваются в следующую парадигму проектирования: Методология – Метод - Средства. Методология разработки информационных систем – это «совокупность методов, применяемых в жизненном цикле разработки программного обеспечения и объединенных одним общим философским подходом. (Г. Буч)» . На сегодняшний день существуют два основных методологических подхода к разработке ИС, различие между которыми обусловлено критериями декомпозиции.

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

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

Основные требования, предъявляемые к технологии проектирования ИС 1. Технология проектирования должна обеспечивать выполнение требований заказчика к ИС в части функциональной полноты, достоверности и оперативности при минимизации стоимостных затрат на создание и эксплуатацию системы. Эти требования отражены в концептуальной модели проектирования ИС. 2. Выбираемая технология проектирования должна позволить проектировщикам разработать проект в установленные сроки. 3. Технология проектирования должна отвечать требованиям надежности функционирования ИС. 4. Важным требованием к технологии проектирования является требование адаптивности проектных решений в процессе эксплуатации информационной системы. 5. Наконец, должна быть обеспечена экономическая эффективность проектной деятельности, т. е. затраты на разработку проекта должны окупаться за счет доходов от его реализации. Требования 1 4 сформулированы в интересах заказчика, пятое требование предусматривает интересы разработчика. Методологии, технологии и инструментальные средства проектирования (CASE средства) составляют основу проекта любой ИС. Методология реализуется через конкретные технологии и поддерживающие их стандарты, методики и инструментальные средства, которые обеспечивают выполнение процессов ЖЦ. Технология проектирования определяется как совокупность трех составляющих: • пошаговой процедуры, определяющей последовательность технологических операций проектирования; • критериев и правил, используемых для оценки результатов выполнения технологических операций; • нотаций (графических и текстовых средств), используемых для описания проектируемой системы.

• • • технология должна поддерживать полный ЖЦ ПО технология должна обеспечивать гарантированное достижение целей разработки ИС с заданным качеством и в установленное время технология должна обеспечивать возможность выполнения крупных проектов в виде подсистем (т. е. возможность декомпозиции проекта на составные части, разрабатываемые группами исполнителей ограниченной численности с последующей интеграцией составных частей) технология должна предусматривать возможность управления конфигурацией проекта, ведения версий проекта и его составляющих, возможность автоматического выпуска проектной документации и синхронизацию ее версий с версиями проекта технология должна обеспечивать независимость выполняемых проектных решений от средств реализации ИС (СУБД, операционных систем, языков и систем программирования) технология должна быть поддержана комплексом согласованных CASE-средств, обеспечивающих автоматизацию процессов, выполняемых на всех стадиях ЖЦ

2. Стадии и этапы процесса канонического проектирования ИС в соответствии с ГОСТ 34. 601 -90 «ИТ. Комплекс стандартов на АС. Стадии создания» . Стадии и этапы процесса канонического проектирования ИС в соответствии с ГОСТ 34. 601 90 «ИТ. Комплекс стандартов на АС. Стадии создания» : Краткая характеристика стадий создания АС (Формирование требований к автоматизированной системе. Разработка концепции автоматизированной системы. Техническое задание. Эскизный проект. Технический проект. Рабочая документация. Ввод в действие. Сопровождение автоматизированной системы). Идея деления процесса проектирования на стадии и этапы состоит в том, чтобы постепенно, проектируя «сверху вниз» , разрабатывать проектные решения сначала укрупнено, а затем детализировано. 8 стадий процесса проектирования ИС: 1. Формирование требований к автоматизированной системе. 2. Разработка концепции автоматизированной системы. 3. Техническое задание. 4. Эскизный проект. 5. Технический проект. 6. Рабочая документация. 7. Ввод в действие. 8. Сопровождение автоматизированной системы. Стадии и этапы, выполняемые организациями участниками работ по созданию АС, устанавливаются в договорах и техническом задании. Степень обязательности: прежняя полная обязательность отсутствует, материалы ГОСТ 34 стали методической поддержкой, причем чаще для заказчиков, имеющих в стандарте набор требований к содержанию ТЗ и проведению испытаний АС. Использование средств автоматизации проектирования, в т. ч. CASE технологий позволяет существенно сократить сроки разработки системы и повысить ее качество и надежность

В каноническом проектировании используется каскадная или итерационная модели ЖЦ информационной системы. Итерационная модель — это каскадная модель с промежуточным контролем. Ошибки или недоработки предыдущих стадий, обнаруженные на последующих стадиях, устраняются путем возврата к предыдущим стадиям, т. е итерацион ным путем. Можно выделить 3 укрупненные стадии проектирования ИС: • предпроектную, включающую стадии 1, 2, 3 (Формирование требований к автоматизированной системе; разработка концепции автоматизированной системы; техническое задание); • проектную, включающую стадии 4, 5, 6 (Эскизный проект; технический проект; рабочая документация); • послепроектную стадию, включающую стадии 7, 8 (Ввод в действие; сопровождение автоматизированной системы) Стадия 1. Формирование требований к автоматизированной системе Главное на этой стадии — провести предпроектное обследование и дать технико экономическое обоснование (ТЭО) целесообразности создания системы. Формируются требования к функциональной части, обеспечивающим подсистемам, методу проектирования. Стадия 2. Разработка концепции автоматизированной системы Включает научно исследовательские работы, разработку нескольких вариантов системы и выбор оптимального. Выполняется ориентировочный расчет ожидаемой экономической эффективности и дается оценка научно технического уровня системы на основании сбора данных об отечественных и зарубежных системах. Оформление отчета и утверждение концепции ИС.

Стадия 3. Техническое задание (ТЗ) — итог предпроектной работы по созданию информационной системы. ТЗ это документ, обращенный к Исполнителю. Главным здесь является состав функциональных задач будущей системы и требования к обеспечивающим подсистемам. Этот документ формируется по материалам первых 2 стадий и составляется в соответствии с ГОСТ 34. 602 -89 «Техническое задание на создание автоматизированной системы» . Техническое задание это документ, утвержденный в установленном порядке, определяющий цели, требования и основные исходные данные, необходимые для разработки ИС, и содержащий предварительную оценку экономической эффективности системы. При каноническом проектировании основной единицей обработки данных является задача. Поэтому функциональная структура предметной области на стадии предпроектного обследования изучается в разрезе решаемых задач и их комплексов. Согласно ГОСТу, задача (Problem) — часть автоматизированной функции управления, характеризуемая конечным результатом в конкретной форме. Стадия 4. Эскизный проект Применительно к информационной системе в экономике выполняется редко. Цель — разработка предварительных решений. Стадия 5. Технический проект Основанием для разработки технического проекта системы является техническое задание, утвержденное заказчиком. Технический проект системы это техническая документация, утвержденная в установленном порядке, содержащая общесистемные проектные решения, алгоритм решения задач, а также оценку экономической эффективности автоматизированной системы управления и перечень мероприятий по подготовке объекта к внедрению. Технический проект разрабатывается в целях определения основных проектных решений по созданию системы.

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

3. Предпроектное обследование предметной области в соответствии с ГОСТ 34. 601 -90 «ИТ. Комплекс стандартов на АС. Стадии создания» . Состав работ на предпроектных стадиях, определенных ГОСТ 34. 601 90 «ИТ. Комплекс стандартов на АС. Стадии создания» . Цель, задачи и результаты предпроектного обследования. Сложность объектов, подлежащих информатизации привела к тому, что в настоящее время методики создания ИС делают акцент на начальные стадии разработки. Для подготовки, организации и регламентирования всего последующего ЖЦ ИС введено понятие системного проектирования. Процесс системного проектирования ИС является фундаментом для обеспечения функциональной адекватности и качества всего ЖЦ ИС. От полноты и качества системного проектирования зависит эффективность реализации функций ИС и степень удовлетворения ожиданий и требований заказчика и пользователей Этапы стадии системного проектирования: 1. Предпроектное обследование. 2. Создание концепции новой ИС 3. Разработка системного проекта новой ИС и определение методов и инструментальных средств дальнейшего детального проектирования и сопровождения всего жизненного цикла ИС. • цель системного проектирования – подготовить и обосновать замыслы и решения заказчика и разработчика о необходимости, направлениях и концепции создания или модернизации существующей ИС. • Результат – системный проект, ТЗ и контракт на продолжение проектирования или решение о его нецелесообразности и прекращении.

Любой проект начинается с обследования объекта информатизации, системного анализа предметной области и выявления потребности создания информационной системы для достижения поставленной цели. Перечень работ по обследованию предметной области регламентирован стандартами ГОСТ 34 (РД 50 34. 698 90), ГОСТ Р ИСО/МЭК 12207 99 (пункт 5. 3. 1. ): 1. Сбор исходной информации и документов о существующей информационной системе компании. 2. Интервьюирование специалистов и заполнение анкет о функциональных характеристиках и особенностях эксплуатации существующей информационной системы. 3. Разработка модели бизнес процессов и деятельности существующей ИС. 4. Выбор критериев и метрик оценки деятельности существующей ИС. 5. Анализ недостатков и обобщение предложений по совершенствованию функциональных, структурных и эксплуатационных характеристик существующей ИС. 6. Обобщение результатов обследования объекта информатизации и определение потребности создания новой или модифицированной ИС и составление отчета. Источниками информации об объекте являются измерения, наблюдения, документы, интервью и личное участие в работе. В качестве исходной информации проведении обследования могут служить: • данные об организационной структуре предприятия; • нормативно – справочная информация, включающая как внутренние нормативные документы (устав предприятия, положения о подразделениях и т. д. ), так и документы, описывающие взаимодействие с внешней средой (ГОСТы на производство продукции, государственные документы о системе налогов и сборов, положения о работе с заказчиками и т. д. ); • система делопроизводства предприятия; • документы о технологии производства; • данные об имеющихся на предприятии средствах информатизации (документы на «старую» ИС, на имеющиеся автоматизированные рабочие места и т. д. ); • стратегические цели предприятия и перспективы развития; • результаты анкетирования сотрудников; • результаты интервьюирования сотрудников. • При проведении обследования применяются следующие методы: – сбор документов; – анкетирование; – интервьюирование.

Создание модели AS-IS бизнес-процессов деятельности компании • Модель AS IS или модель «как есть» представляет собой модель бизнес процессов на момент обследования предприятия и строится с целью понять, как функционирует данное предприятие с позиций системного анализа. Эта модель строится с целью выявления ошибок и узких мест, а также формулировки предложений по улучшению ситуации. Создание модели информационных потоков предметной области компании • Информационные потоки отображаются в документах и других (телефонные сообщения, устные сообщения) видах сообщений. «Узкие» места будем определять на основе анализа построенных моделей бизнес процессов и документооборота. При этом анализ будем проводить по следующим направлениям: • анализ функциональной деятельности выбранной предметной области; • анализ функционального взаимодействия выбранной предметной области с внешними объектами; • анализ внутреннего документооборота выбранной предметной области; • анализ информационных потоков и информационного взаимодействия с внешними объектами; • анализ информационной инфраструктуры выбранной предметной области и предприятия в целом. Работы по созданию концепции новой ИС регламентированы : ГОСТ 34, ГОСТ 12207, ISO 9000 3. 1. Анализ предложений по усовершенствованию характеристик старой системы и первичное формулирование целей и требований к новой ИС. 2. Разработка предварительного описания постановки комплекса функциональных задач новой ИС. 3. Разработка предварительного описания характеристик внешней среды новой ИС. 4. Предварительное определение доступных ресурсов и ограничений проектирования новой ИС. 5. Технико экономическое обоснование проекта и предварительная оценка технико экономических показателей новой ИС, а также степени риска. 6. Разработка идеальной предварительной модели бизнес процессов и функционирования новой ИС без учета реальных ограничений. 7. Разработка и документирование концепции и предложений по созданию новой ИС – целей, методов, требований и потенциальных решений без учета реальных ресурсов и ограничений.

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

Создание технического задания на проект ИС • Созданию любого проекта предшествует стадия создания технического задания на проект. Техническое задание это документ, формально определяющий существование проекта. Техническое задание на проектирование должно содержать, согласно ГОСТ 34. 602 89, поэтапно уточняющиеся и детализирующиеся при детальном и рабочем проектировании разделы: • 1) общие сведения; • 2) назначение и цели создания (развития) системы; • 3) характеристика объектов автоматизации; • 4) требования к системе; • 5} состав и содержание работ по созданию системы; • 6) порядок контроля и приемки системы; • 7) требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие; • 8) требования к документированию; • 9) источники разработки. При этом для технического задания создается титульный лист с утверждающими и согласующими подписями.

4. Автоматизированное проектирование ИС на основе функционально-ориентированного и объектно-ориентированного подходов с использованием CASE-технологий. Разработка моделей (SADT функциональная (IDEF 0); DFD; ERD (IDEF 1 X); STD; e. EPC; вариантов использования; прецедентов и т. д) в зависимости от используемых CASE технологий на соответствующих этапах проектирования ИС. Структурный подход зародился в середине 70 х годов. Его отличительная особенность – ориентация в первую очередь на описание процессов. Сущность структурного подхода заключается в декомпозиции системы. Декомпозиция системы производится следующим образом: система разбивается на функциональные подсистемы, которые делятся на подфункции, те – на задачи и так далее до конкретных процедур. Методология SADT (Structured Analysis and Design Technique) основана Россом в 1973 году и является методологией, ориентированной на описание процессов. С точки зрения SADT модель может основываться либо на функциях системы, либо на ее предметах. Соответствующие модели принято называть функциональными (активностными) моделями и моделями данных. В основе структурного подхода лежат следующие принципы: • принцип декомпозиции ( «разделяй и властвуй» ); • принцип иерархического упорядочения (организация составных частей системы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне); • принцип абстрагирования (выделение существенных аспектов системы и отвлечение от несущественных); • принцип непротиворечивости (обоснованность и согласованность элементов системы); • принцип структурирования данных (данные должны быть структурированы и иерархически организованы).

Методология IDEF состоит из нескольких методологий моделирования, основанных на графическом представлении систем. • IDEF 0 – методология создания функциональной модели, которая является структурированным изображением функций производственной системы или среды, а также информации и объектов, связывающих эти функции. • Полученная модель позволяет сформировать архитектуру среды моделируемой системы. • Назначение модели графически представляет основные функциональные связи, идентификацию информационных потоков • В качестве нотации- «метод блочного моделирования» • Основной рабочий элемент – диаграмма, • В состав диаграммы входят блоки, изображающие производственную операцию, • Интерфейсы вход/выход изображаются дугами. В качестве методологии блочного моделирования была выбрана методология SADT. • Методология SADT (Structured Analysis and Design Technique) основана Россом в 1973 году и является методологией, ориентированной на описание процессов. С точки зрения SADT модель может основываться либо на функциях системы, либо на ее предметах. Соответствующие модели принято называть функциональными (активностными) моделями и моделями данных. • Функциональная модель представляет с нужной степенью точности систему функций, которые в свою очередь отражают свои взаимоотношения через предметы системы. Модели данных двойственны к функциональным моделям и представляют собой подробное описание предметов системы, связанных системными функциями. Полная методология SADT заключается в построении моделей обеих типов для более точного описания сложной системы. • Основным рабочим элементом при моделировании является диаграмма. Модель SADT объединяет и организует диаграммы в иерархические древовидные структуры, при этом, чем выше уровень диаграммы, тем она менее детализирована. • В состав диаграммы входят блоки, изображающие функции моделируемой системы, и дуги, связывающие блоки вместе и изображающие взаимодействия и взаимосвязи между блоками. Методология SADT требует, чтобы в диаграмме было 3 6 блоков; в этих пределах диаграммы и модели удобны для чтения, понимания и использования.

Создание функциональных моделей и диаграмм происходит последовательности: 1. Сбор информации 2. Декомпозиция объекта исследования. 3. Моделирование • 3. 1. Выбор цели и точки зрения • 3. 2. Составление списка данных. • 3. 3. Составление списка функций. • 3. 4. Построение и обобщение диаграммы А 0 (А 0 – А 0). • 3. 5. Декомпозиция ограниченного объекта. • Итерационный процесс рецензирования BPwin в следующей является мощным инструментом для создания моделей, позволяющих анализировать, документировать и планировать изменения сложных бизнес процессов. BPwin предлагает средство для сбора всей необходимой информации о работе предприятия и графического изображения этой информации в виде целостной и непротиворечивой модели. BPwin поддерживает три методологии: IDEF 0, DFD и IDEF 3, позволяющие анализировать бизнес с трех ключевых точек зрения: • с точки зрения функциональности системы; • с точки зрения потоков информации (документооборота) в системе; • с точки зрения последовательности выполняемых работ.

Объектно-ориентированный подход (ООП) использует объектную декомпозицию. При этом структура системы описывается в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщениями между объектами. Каждый объект системы обладает своим собственным поведением, моделирующим поведение объекта реального мира. • Концептуальной основой объектно ориентированного подхода является объектная модель. Ее основными понятиями являются: объекты и атрибуты, целое и часть, классы и экземпляры. • Объект определяется как осязаемая реальность (tangible entity) предмет или явление, имеющий четко определяемое поведение. Объект обладает состоянием, поведением и индивидуальностью; структура и поведение схожих объектов определяют общий для них класс. Термины «экземпляр класса» и «объект» являются эквивалентными. • Класс это множество объектов, связанных общностью структуры и поведения. Класс инкапсулирует (объединяет) в себе данные (атрибуты) и поведение (операции). Любой объект является экземпляром класса. Основными механизмами объектной модели являются: • абстрагирование (abstraction) это выделение существенных характеристики некоторого объекта, которые отличают его от всех других видов объектов и, таким образом, четко определяют его концептуальные границы с точки зрения дальнейшего рассмотрения и анализа • инкапсуляция (encapsulation) это объединение в рамках объекта операций и атрибутов, отражающих его состояние, с целью обеспечить доступность и изменяемость состояния только посредством интерфейса, предоставляемого объектом. Инкапсуляция служит для того, чтобы изолировать интерфейс объекта, отражающий его внешнее поведение, от внутренней реализации объекта. • наследование (inheritance) означает построение новых классов на основе существующих с возможностью добавления или переопределения данных и методов.

Основными механизмами объектной модели являются: • полиморфизм (polymorphism) может быть интерпретирован, как способность класса принадлежать более чем одному типу. Этот механизм позволяет определить единственное имя операции или атрибута более чем в одном классе, причем в каждом из этих классов ему могут соответствовать различные реализации. • модульность (modularity) это свойство системы, связанное с возможностью ее декомпозиции на ряд внутренне связных, но слабо связанных между собой модулей. • иерархия (hierarchy) это ранжированная или упорядоченная система абстракций, расположение их по уровням. Основными видами иерархических структур применительно к сложным системам являются структура классов (иерархия по номенклатуре) и структура объектов (иерархия по составу). Примерами иерархии классов являются простое и множественное наследование (один класс использует структурную или функциональную часть соответственно одного или нескольких других классов), а иерархии объектов агрегация. В качестве инструмента ООП служит нотация, принятая в языке UML • Язык UML служит для определения, отображения и описания элементов объектно ориентированных систем в процессе их создания. • Он объединяет объектную модель, нотации Буча и ОМТ, а также лучшие идеи, предложенные авторами других методик. Таким образом, язык UML является стандартом де факто в области объектно ориентированного анализа и проектирования.

Стандарт UML версии 1. 1, принятый OMG в 1997 г. , предлагает следующий набор диаграмм для моделирования: • диаграммы вариантов использования (use case diagrams) для моделирования бизнес процессов организации (требований к системе); • диаграммы классов (class diagrams) для моделирования статической структуры классов системы и связей между ними; • диаграммы поведения системы (behavior diagrams): • диаграммы взаимодействия (interaction diagrams): • диаграммы последовательности (sequence diagrams) и кооперативные диаграммы (collaboration diagrams) – для моделирования процесса обмена сообщениями между объектами; • диаграммы состояний (statechart diagrams) для моделирования поведения объектов системы при переходе из одного состояния в другое; • диаграммы деятельностей (activity diagrams) для моделирования поведения системы в рамках различных вариантов использования, или моделирования деятельностей; • диаграммы реализации (implementation diagrams): • диаграммы компонентов (component diagrams) для моделирования иерархии компонентов (подсистем) системы; • диаграммы размещения (deployment diagrams) для моделирования физической архитектуры системы.

Поведение разрабатываемой системы (то есть функциональность, обеспечиваемая системой) описывается с помощью функциональной модели, которая отображает системные прецеденты (use cases), системное окружение (действующих лиц или актеров actors) и связи между прецедентами и актерами (диаграммы прецедентов use cases diagrams). В нотации UML их чаще называют диаграммами вариантов использования. Основная задача модели прецедентов или диаграмм вариантов использования представлять собой единое средство, дающее возможность заказчику, конечному пользователю и разработчику совместно обсуждать функциональность и поведение системы. Разработка модели прецедентов происходит на стадии планирования проекта для формирования требований к системе. Она начинается с выбора актеров и определения общих принципов функционирования системы. Затем на этапе проработки модель дополняется детальной информацией к существующим прецедентам, а при необходимости добавляются новые. • • • Диаграмма вариантов использования или диаграмма прецедентов (use case diagram) – это графическое представление всех или части актеров, прецедентов и их взаимодействий в системе. Актеры не являются частью системы они представляют собой кого то или что то, что должно взаимодействовать с системой прецедент это последовательность транзакций, выполняемых системой, которая приводит к значимому результату для определенного актера. Между актером и прецедентом может существовать ассоциативное отношение. В языке UML существует понятие стереотипа (stereotype), с помощью которого создаются новые элементы модели путем расширения функциональности базовых элементов. (communicate, include, extend).

Спасибо за внимание !