ЛЕКЦИЯ 3 1. Типовые приемы конструирования пакетов программ сложной структуры 2. Организация проектирования ПО: этапы процесса проектирования 3. Использование. - презентация

1 ЛЕКЦИЯ 3 1. Типовые приемы конструирования пакетов программ сложной структуры 2. Организация проектирования ПО: этапы процесса проектирования 3. Использование экспертных систем в разработке ПО

2 Типовые приемы конструирования пакетов программ сложной структуры

3 УНИФИЦИРОВАННЫЙ ЯЗЫК МОДЕЛИРОВАНИЯ Унифицированный язык моделирования (UML) является стандартным инструментом для создания документированных каркасов ("чертежей") программного обеспечения. С помощью UML можно визуализировать, специфицировать, конструировать и документировать процесс разработки программных систем.

4 Диаграмма классов, показывающая Агрегацию между двумя классами Диаграмма прецедентов для упрощенной модели работы ресторана

5 КРАТКИЙ ПЕРЕЧЕНЬ ПРОИЗВОДИТЕЛЕЙ И ПРОГРАММНЫХ ПРОДУКТОВ.

6 Фирма Rational Software - безусловный лидер в области объектно-ориентированного анализа и проектирования информационных систем с компонентной архитектурой.

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

8 Поддерживаются основные языки программирования С++, Java, Visual Basic, SmallTalk и др., а также популярные среды разработки - MS Visual Studio, Delphi, PowerBuilder.

9 Rational Rose - хорошо сбалансированный программный продукт с удобным интерфейсом и набором инструментов моделирования, ориентированным как на разработчиков программных систем, так и на бизнес- и системных аналитиков. На базе Rational Rose был создан Visual Modeler - средство визуального проектирования, включенное в состав среды разработки Microsoft Visual Studio (начиная с версии 6.0).

10 Широкую известность и признание у аналитиков всего мира получили CASE- средства BPWIN и ERWIN, теперь спектр продуктов компании Computer Associated Пакеты, предназначенные для визуального моделирования объектно-ориентированных программных систем, поддерживающих стандарты UML - Paradigm Plus (программный продукт фирмы Computer Associated) и SELECT (SELECT Software).

11 Широкую известность и признание у аналитиков всего мира получили CASE- средства BPWIN и ERWIN, спектр продуктов компании Computer Associated.

12 Пакеты, предназначенные для визуального моделирования объектно- ориентированных программных систем, поддерживающих стандарты UML - Paradigm Plus (программный продукт фирмы Computer Associated) и SELECT (SELECT Software).

13 Средство визуального моделирования Select ориентировано в основном, на аналитиков, он может использоваться и разработчиками программных систем. Этот продукт, также, поддерживает UML и компонентную технологию проектирования программных систем.

14 Организация проектирования ПО: этапы процесса проектирования

15 Организация проектирования ПО Этапы процесса проектирования Для организации эффективного процесса разработки в тех случаях, когда она ведется коллективом, в целях планирования разработки, тех. обработки контроля качества, принятия управляющих решений процесс разработки разлагается на составные части: стадии этапы комплексы работ работы

16 Стадии - наиболее укрупненные составляющие процесса разработки, для завершения которых характерно получение ПИ в определенной стадии готовности. Этапы - составные части стадии, которые выделяются в тех случаях, когда целесообразно разукрупнение стадий в целях конкретизации заданий исполнителя. Этап связан с изделием и с коллективом разработчиков в целом.

17 Существует 2 подхода к выделению элементов процесса разработки ПИ: 1. Разработка ведется большим коллективом 2. Разработка выполняется универсальным специалистом

18 1-й подход. Разработка ведется достаточно крупным коллективом, в котором существует специализация по видам работ. Делится на 5 стадий : Стадия технического задания (предпроектная стадия): сбор исходных данных обоснование и выбор критерия эффективности и качества разработки определяется на укрупненном уровне состав входной и выходной документации по решаемой задаче определяются принципиальные методы решения задач должны быть определены требования к техническим средствам, операционному окружению процесс разбивается на стадии и этапы с фиксацией срока определяются средства разработки результат фиксируется в документе «Техническое задание»

19 Эскизное проектирование Стадия применяется для принципиально новых и достаточно крупных разработок: детализация состава и структуры входной и выходной информации детализация метода решения задач Здесь нужно создать предварительную форму документа и выяснить принципиальные вопросы, устраняя возможные разногласия между разработчиком и заказчиком набрасывается предварительный технологический процесс решения задачи определяется эффективность результата решения задачи на конкретном объекте ведется освоение средств реализации Назначение этой стадии - устранение возможного непонимания сути решения проблемы между разработчиком и заказчиком (80% разработок обходится без этой стадии).

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

21 Рабочее проектирование: Результат рабочего проектирования - получение ПИ в состоянии операционной готовности. Выявлены синтаксические и семантические ошибки, существует программная документация. Основные работы этой стадии: программная реализация (написание текстов программ, привязка ППП к специфике конкретного объекта, настройка ППП, адаптация, заимствование погрешности решения) проводится отладка (автономная и комплексная) Параллельно с этим: ведется разработка эксплуатационной документации проработка основных моментов, связанных с внедрением ПИ

22 Внедрение. Существенным моментом стадии является подготовка объекта к внедрению: подготовка персонала к эксплуатации подготовка базы данных После подготовки приступают к проверке работоспособности ПИ на реальных данных (опытная эксплуатация). Окончательно выявляются семантические ошибки. По отдельным компонентам может быть откат на предыдущие стадии. В процессе разработки могут объединяться стадии технического и рабочего проектирования.

23 2-й подход. Если разработка выполняется универсальным специалистом, который непосредственно взаимодействует с пользователем и осуществляет сопровождение ПИ, то стадии следующие: 1) Стадия системного анализа (анализ требований) предметной области. Те же работы что и в п. 1. В результате необязательно формируется тех. задание в его стандартном варианте, но каким-либо документом закрепляется соглашение по требования к ПИ между разработчиком и пользователем (в одной организации). Сначала анализ потребностей пользователя, затем разработка целей, формулировка задачи. Задачи ставятся перед отдельными производителями. Выбор методов реализации задачи. Формирование задания разработки. (Имеется в виду спецификация ПИ).

24 2) Общее проектирование ПИ (внешнее). - выработка проектных решений, представляющих собой внешнюю сторону работы ПИ (форма входных и выходных документов, интерфейс, общий технический процесс) Результатом внешнего проектирования является подготовка документа «Внешняя спецификация», которая соглашается между разработчиком и пользователем. 3) Внутреннее (детальное, структурное) проектирование. (выработка программных решений раскрывающих внутреннюю часть ПИ). Определение структуры программного комплекса, состава и структуры БД, из каких файлов и какова их структура, связь с модулями, составление алгоритма.

25 4) Кодирование или подготовка программного кода 5) Автономная отладка отдельных программных компонентов, отладка модулей, их связей 6) Комплексирование компонент или комплексная отладка. Параллельно с этим выполняется подготовка эксплуатационной документации. По времени она должна совпадать по времени с завершением компьютерной отладки. 7) Испытание. Проверка работоспособности изделия в реальных условиях эксплуатации.

26 Основы устройства и использование экспертных систем в разработке адаптируемого программного обеспечения

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

28 База знаний - семантическая модель, описывающая предметную область и позволяющая отвечать на такие вопросы из этой предметной области, ответы на которые в явном виде не присутствуют в базе. БЗ является основным компонентом интеллектуальных и экспертных систем.

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

30 Подсистема объяснений - программа, позволяющая пользователю получить ответы на вопросы: - "Как было получено то или иное решение?"; обычно ответ на этот вопрос представляет собой трассировку всего процесса вывода решения с указанием использованных фрагментов базы знаний; и -"Почему было принято такое решение?"; обычно ответ на этот вопрос есть ссылка на умозаключение, непосредственно предшествовавшее полученному решению.

31 ПРИМЕНЕНИЕ ЭКСПЕРТНОЙ СИСТЕМЫ ПРИ РАЗРАБОТКЕ ПО Разработка ПО начинается с этапа анализа предметной области и создания моделей. Применение моделей необходимо, чтобы разделить предметную область на части, проанализировать её, а потом создать проект, техническую спецификацию и документацию для разрабатываемой системы.

32 Разработчик, используя модели, полученные на этапах анализа и проектирования, и основываясь на своих специальных знаниях, начинает создавать задуманную информационную систему (ИС). Если моделирование осуществлялось на UML, то частично код программы в виде описания классов обычно можно сгенерировать.

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

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

35 Поэтому все шире используются интеллектуальные средства, в частности экспертные системы (ЭС), при разработке ПО. Все данные моделей находятся в базе знаний (БЗ). Для описания проблемной области используются параметры, ситуации и правила, понятия и отношения. Совокупность их описаний образует БЗ, которая определяет не только знания о предметной области, но также принимают участие в процессе консультации и поиска решений.

36 Преимущества применения ЭС при разработке программного обеспечения: знания сотрудников можно консолидировать в общую БЗ и использовать совместно, с применением ЭС можно отслеживать, чтобы использовались стандартизированные решения, количество рутинной работы разработчика уменьшается, так как возможно автоматическое генерирование кода программы.