Главная » Все файлы » Просмотр файлов из архивов » PDF-файлы » А.М. Вендров - Объектно-ориентированный анализ и проектирование

А.М. Вендров - Объектно-ориентированный анализ и проектирование, страница 25

PDF-файл А.М. Вендров - Объектно-ориентированный анализ и проектирование, страница 25, который располагается в категории "книги и методические указания" в предмете "объектно-ориентированный анализ и проектирование" изседьмого семестра. А.М. Вендров - Объектно-ориентированный анализ и проектирование, страница 25 - СтудИзба 2019-09-18 СтудИзба

Описание файла

PDF-файл из архива "А.М. Вендров - Объектно-ориентированный анализ и проектирование", который расположен в категории "книги и методические указания". Всё это находится в предмете "объектно-ориентированный анализ и проектирование" из седьмого семестра, которые можно найти в файловом архиве МГУ им. Ломоносова. Не смотря на прямую связь этого архива с МГУ им. Ломоносова, его также можно найти и в других разделах. .

Просмотр PDF-файла онлайн

Текст 25 страницы из PDF

Онвыполняет преобразование классов-сущностей в классы-таблицы споследующей генерацией описания БД на SQL. При этом применяетсяследующий набор стереотипов элементов модели:• таблица представляется в виде класса со стереотипом "Table";• обычная ассоциация и агрегация представляются в видеассоциации со стереотипом "Non-Identifying" (в терминологиистандарта IDEF1X - неидентифицирующей связи);• композиция представляется в виде ассоциации со стереотипом"Identifying" (в терминологии IDEF1X - идентифицирующей связи);• схема БД представляется в виде пакета со стереотипом "Schema",содержащего классы-таблицы;• ограничения целостности представляются в виде операций классовтаблиц со стереотипами.154Примеры преобразования, выполненного для классов вариантаиспользования "Зарегистрироваться на курсы" средствами Data Modeler,приведены на рис.

3.33 – 3.35.Рис. 3.33. Пример неидентифицирующих связей155Рис. 3.34. Пример преобразования обобщения156Рис. 3.35. Пример идентифицирующей связи? Вопросы для самоконтроля:1. Перечислите правила формирования схемы базы данных из модели«сущность-связь».2. К каким последствиям для системы может привести отсутствиеархитектурного анализа?3. Что дает использование образцов распределения обязанностей?4. Какие классы нуждаются в моделировании состояний?5. Охарактеризуйте достоинства и область применения методикианализа и проектирования Rational Unified Process.157Глава 4.

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

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

4.1). Каждому классумодели соответствует множество объектов (экземпляров), определяющихконкретные элементы ТС ПО: технологические процессы, технологическиеоперации, рабочие продукты, роли, CASE-средства и руководства.Рабочий вариант (экземпляр) конкретной ТС ПО представляет собойТС ПО, адаптированную к условиям объекта внедрения и проектамсоздания ПО.Рис. 4.1. Объектная модель ТС ПО4.2.

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

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

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

При детализированной оценке для каждой ТС ПОпретендента формируется ее детальное описание, основанное на общеймодели (рис. 4.1). Источники информации для описания - техническаядокументация поставщика, доступные данные о реальных внедрениях,результаты выполнения пилотных проектов.4) Выбор ТС ПО.

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

При изменении условий объекта внедрения и по результатаманализа эффективности внедрения ТС ПО принимается решение: а) овнесении изменений в рабочую конфигурацию ТС ПО; б) о переходе нановую ТС ПО. В случае перехода повторяются пп. 3)-4)-5).4.3.1. Оценка и выбор ТС ПОЦель оценки - определение функциональности и качества ТС ПО дляпоследующего выбора. Оценка выполняется в соответствии с конкретнымикритериями, ее результаты включают как объективные, так исубъективные данные по каждой ТС ПО.Процесс оценки включает следующие действия:• формулировка задачи оценки, включая информацию о цели имасштабах оценки;• определение критериев оценки, вытекающее из определениязадачи;• определение технологий-кандидатов путем просмотра спискакандидатов и анализа информации о конкретных технологиях;161• оценка технологий-кандидатов в контексте выбранных критериев.Необходимые для этого данные могут быть получены путеманализа самих технологий и их документации, опросапользователей, работы с демо-версиями, выполнения тестовыхпримеров, экспериментального применения и анализа результатовпредшествующих оценок;• подготовка отчета по результатам оценки.Одним из важнейших критериев в процессе оценки может бытьпотенциальная возможность интеграции между каждой из технологийкандидатов и другими технологиями, уже находящимися в эксплуатацииили планируемыми к использованию в данной организации.Список ТС ПО - возможных кандидатов формируется из различныхисточников: обзоров рынка ПО, информации поставщиков, обзоровтехнологий и др.Следующим шагом является получение информации о технологияхили получение их самих, или и то, и другое.

Свежие статьи
Популярно сейчас