Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Вопросы к экзамену 2012.docx
Скачиваний:
4
Добавлен:
20.09.2019
Размер:
583.63 Кб
Скачать
  1. Case-средства.

Ответ: Разработчикам необходимы средства для автоматизированного проектирования и создания программ или так называемые CASE-средства (Computer Assisted Software Engineering – CASE). CASE – средства позволяют хранить и получать доступ к моделям через центральный репозиторий, а также манипулировать этими моделями на экране компьютера в графическом и текстовом режимах. В идеале репозиторий должен обеспечивать одновременный доступ многих пользователей (многих разработчиков) к моделям.

Перечень типичных функций CASE-средств (репозитория).

  • координация доступа к моделям.

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

  • хранение нескольких версия моделей.

  • идентификация различий между версиями.

  • возможность совместного использования одних и тех же концептов в различных моделях.

  • проверка непротиворечивости и целостности моделей.

  • генерация проектных отчетов и документов.

  • генерация структур данных и программного кода (конструирование ПО)

  • генерация моделей по существующей реализации (реконструкция ПО) и.т.д.

Следует отметить, что зачастую программа, сгенерированная с помощью CASE средств, представляет собой на самом деле всего лишь «скелет» программы – вычислительный алгоритм, который необходимо дорабатывать программисту как при обычном программировании.

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

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

Рассмотренные выше особенности применения CASE-средств не должны натолкнуть вас на мысль, что CASE-технология – «рискованное дело». Она может и не дать вам ожидаемых выгод, если вы пытаетесь использовать ее для того, чтобы направлять работу всей группы проекта, а группа проекта не готова следовать нужному процессу. Однако, те же методы и CASE – средства безусловно могут обеспечить повышение личной продуктивности и качества работы отдельных разработчиков, которые используют технологию на своих локальных рабочих станциях. Моделировать программные артефакты с помощью карандаша и бумаги уместно только в аудитории, но никак ни при работе над реальным проектом.

Архитектура CASE-средства

Архитектура CASE-средства состоит из 6 компонентов:

  1. Репозиторий данных

  2. Графический редактор диаграмм

  3. Верификатор диаграмм

  4. Документатор проекта

  5. Администратор проекта

  6. Сервис

Репозиторий данных

Является специализированной базой данных для отображения состояния проектируемой ЭИС в любой момент времени. В нём хранится информация об объектах проектироуемой системы и все подсистемы обмениваются данными с ним.

Графический редактор диаграмм

Графический редактор диаграмм предназначен для отображения в графическом виде в заданной нотации проектируемой ЭИС. Он позволяет:

  • создавать элементы диаграмм и взаимосвязи между ними

  • задавать описания элементов диаграмм

  • задавать описания связей между элементами диаграмм

  • редактировать элементы диаграмм, их взаимосвязи и описания

Верификатор диаграмм

Верификатор диаграмм служит для контроля правильности построения диаграмм в заданной методологии проектирования ЭИС. Он выполняет:

  • мониторинг правильности построения диаграмм

  • диагностику и выдачу сообщений об ошибках

  • выделение на диаграмме ошибочных элементов

Документатор проекта

Документатор проекта позволяет получать информацию о состоянии проекта в виде различных отчётов. Отчёты могут строиться по нескольким признакам, например по времени, автору, элементам диаграмм, диаграмме или проекту в целом.

Администратор проекта

Администратор проекта представляет собой инструменты, необходимые для выполнения следующих административных функций:

  • инициализация проекта

  • задания начальных параметров проекта

  • назначения и изменения прав доступа к элементам проекта

  • мониторинга выполнения работ

Сервис

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

  1. Требования к системе FURPS+.

Ответ: Требования (requirements) – это возможности или условия, которым должна соответствовать система или проект. Основная задача этапа определения требований – найти, обсудить и зафиксировать, что действительно требуется от системы в форме, понятной и заказчикам ПО и членам команды разработчиков.

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

–  функциональные требования (Functionality) – свойства, возможности, безопасность;

–  требования к удобству использования (Usability) – человеческий фактор, справочная система, документация;

–  требование к надежности (Reliability) – частота сбоев, возможность восстановления и предсказуемость поведения;

–  требования к производительности (Performance) – время отклика, точность, доступность использования ресурсов;

–  требования возможности сопровождения (Supportability) – адаптивность, возможность поддержки, соответствие международным стандартам, возможность конфигурирования, возможность расширения.

При этом символом “+” обозначены дополнительные условия, к которым относятся:

–  проектные ограничения;

–  требования управления системой;

–  требования к графическому интерфейсу пользователя;

–  физические требования;

–  юридические требования – авторское право и т. п.

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

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

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

Помимо требований, классифицированных по модели FURPS+, полезно рассмотреть следующие вопросы:

–  cовместимости (система должна быть совместима с существующими и проектируемыми информационными системами для данного объекта);

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

–  адаптируемости, гибкости и возможности настройки под конкретные нужды пользователей;

–  высокой степени защищенности информации от несанкционированного доступа и сбоев оборудования;

–  единой внутренней логики работы системы, открытость для внесения необходимых изменений, устойчивость к организационным изменениям;

–  обеспечения разделенного доступа пользователей к ресурсам системы и обеспечение сетевого режима функционирования;

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

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