Понятия анализа и синтеза. Системный анализ.

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

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

Синтез– процесс соединения или объединения ранее разрозненных вещей или понятий в целое или набор.

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

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

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

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

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

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

Согласно классификации, все проблемы подразделяются на три класса:

· хорошо структурированные, или количественно сформулированные проблемы, в которых существенные зависимости выяснены очень хорошо;

· неструктурированные, или качественно выраженные проблемы, содержащие лишь описание важнейших ресурсов, признаков и характеристик, количественные зависимости между которыми совершенно неизвестны;

· слабо структурированные, которые содержат как качественные элементы, так и малоизвестные, неопределенные стороны, которые имеют тенденцию доминировать.

Процедура принятия решений согласно включает следующие основные этапы:

· формулировка проблемной ситуации;

· определение целей;

· определение критериев достижения целей;

· построение моделей для обоснования решений;

· поиск оптимального (допустимого) варианта решения;

· согласование решения;

· подготовка решения к реализации;

· утверждение решения;

· управление ходом реализации решения;

· проверка эффективности решения.

Нисходящее и восходящее проектирование и программирование

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

Восходящее - проектирование, в котором элементы проектируются раньше системы, и, следовательно, предположительный характер имеют требования к элементам.

На практике обычно сочетают восходящее и нисходящее проектирование.

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

Перекрестки (соединения)

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

Жизненный цикл программного обеспечения (ПО) — период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации.

Этапы жизненного цикла ПО:

Основные:

§ Приобретение. Поставка. Разработка. Эксплуатация. Сопровождение.

Вспомогательные

§ Документирование. Управление конфигурацией. Обеспечение качества. Верификация. Аттестация. Совместная оценка. Аудит. Разрешение проблем.

Организационные

§ Управление. Создание инфраструктуры. Усовершенствование. Обучение.

Стадия — часть процесса создания ПО, ограниченная определенными временными рамками и заканчивающаяся выпуском конкретного продукта (моделей, программных компонентов, документации), определяемого заданными для данной стадии требованиями.

На каждой стадии могут выполняться несколько процессов, определенных в стандарте ГОСТ Р ИСО/МЭК 12207-99, и наоборот, один и тот же процесс может выполняться на различных стадиях. Соотношение между процессами и стадиями также определяется используемой моделью жизненного цикла ПО.

Модели жизненного цикла ПО:

Итерационная модель

Модель IID предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает «мини-проект», включая все процессы разработки в применении к созданию меньших фрагментов функциональности, по сравнению с проектом в целом. Цель каждой итерации — получение работающей версии программной системы, включающей функциональность, определённую интегрированным содержанием всех предыдущих и текущей итерации. Результат финальной итерации содержит всю требуемую функциональность продукта. Таким образом, с завершением каждой итерации продукт получает приращение —инкремент — к его возможностям, которые, следовательно, развиваются эволюционно. Итеративность, инкрементальность и эволюционность в данном случае есть выражение одного и то же смысла разными словами со слегка разных точек зрения.

Спиральная модель

При использовании этой модели ПО создается в несколько итераций (витков спирали) методом прототипирования.

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

Порождающие шаблоны (англ. Creational patterns) — шаблоны проектирования, которые абстрагируют процесс инстанцирования. Они позволяют сделать систему независимой от способа создания, композиции и представления объектов. Шаблон, порождающий классы, использует наследование, чтобы изменять инстанцируемый класс, а шаблон, порождающий объекты, делегирует инстанцирование другому объекту.

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

Перечень порождающих шаблонов • абстрактная фабрика (abstract factory); • строитель (builder); • фабричный метод (factory method); • ленивая инициализация (lazy initialization); • объектный пул (object pool); • прототип (prototype); • одиночка (singleton).

Фабричный метод: class Value {...} class FactoryClass { private static Value comm; public FactoryClass(String command){ comm=new Value(command); } public static Value getCommand(){ return comm; }}

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

В разработке программного обеспечения, шаблон проектирования или паттерн (англ. design pattern) — повторимая архитектурная конструкция, представляющая собой решение проблемы проектирования в рамках некоторого часто возникающего контекста.

Главная польза каждого отдельного шаблона состоит в том, что он описывает решение целого класса абстрактных проблем. Также тот факт, что каждый шаблон имеет свое имя, облегчает дискуссию об абстрактных структурах данных (ADT) между разработчиками, так как они могут ссылаться на известные шаблоны. Таким образом, за счёт шаблонов производится унификация терминологии, названий модулей и элементов проекта.

Правильно сформулированный шаблон проектирования позволяет, отыскав удачное решение, пользоваться им снова и снова.

40. Факторы качества написания программного кода:

Понятность - Назначение ПО должно быть понятным, из самой программы и документации.

Полнота - Все необходимые части программы должны быть представлены и полностью реализованы.

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

Портируемость - Лёгкость в адаптации программы к другому окружению: другой архитектуре, платформе, операционной системе или её версии.

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

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

Тестируемость - Позволяет ли программа выполнить проверку приёмочных характеристик, поддерживается ли возможность измерения производительности.

Удобство использования-Простота и удобство использования программы. Это требование относится прежде всего к интерфейсу пользователя.

Надёжность-отсутствие отказов и сбоев в работе программ, а также простота исправления дефектов и ошибок:

структурированность

эффективность-Насколько рационально программа относится к ресурсам (память, процессор) при выполнении своих задач.

безопасность

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

Качество программного обеспечения — характеристика программного обеспечения (ПО) как степени его соответствия требованиям. При этом требования могут трактоваться довольно широко, что порождает целый ряд независимых определений понятия. Чаще всего используется определение ISO 9001, согласно которому качество есть «степень соответствия присущих характеристи

Классы

1. Интерфейс класса должен формировать согласованную абстракцию. Многие проблемы объясняются нарушением одного этого принципа.

2. Интерфейс класса должен что-то скрывать – особенности взаимодействия с системой, аспекты проектирования или детали реализации.

3. Включение обычно предпочтительнее, чем наследование, если только вы не моделируете отношение «является».

4. Наследование – полезный инструмент, но оно повышает сложность, что противоречит принципам, которым является управление сложностью.

Высококачественные методы

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

2. Иногда огромную выгоду можно извлечь, создав отдельный метод для просто операции.

3. Связность методов можно разделить на несколько видов. Самая лучшая – функциональная – достижимая практически всегда.

4. Имя метода является признаком его качества. Плохое, но точное имя часто указывает на плохое проектирование метода. Плохое и неточное имя не описывает роль метода. Как бы то ни было, плохое имя предполагает, что программу нужно изменить.

5. Функцию следует использовать, только когда главной целью метода является возврат конкретного значения, описываемого именем функции.

Основные типы данных

1. Работа с определенными типами данных требует учета множества правил для каждого из них.

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

Нестандартные типы данных

1. Структуры могут помочь сделать программы менее сложными, упростить их понимание и сопровождение.

2. Работа с указателями чревата ошибками.

3. Избегайте глобальных переменных не только потому, что они опасны, но и потому что их можно заменить чем-то лучшим.

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

Smoke Test в тестировании программного обеспечения означает минимальный набор тестов на явные ошибки. Дымовой тест обычно выполняется самим программистом; не проходящую этот тест программу не имеет смысла отдавать на более глубокое тестирование.

Bootstrapper. Эта часть программы установки запускается первой и ее задача — подготовить все необходимое для работы installation engine. В частности, в случае использования Windows Installer, bootstrapper обеспечивает установку или обновление Windows Installer до требуемой версии.

Программа установки либо использует свой собственный installation engine, либо пользуется услугами сервиса Windows Installer. Installation engine выполняет всю основную работу: взаимодействует с пользователем через GUI, создает/удаляет папки и ключи реестра, копирует файлы, регистрирует компоненты

Инсталляторы

Скриптовые. Задают поведение инсталлятора — набором опций в GUI, либо в виде скрипта на внутреннем языке. Скрипт компилируется в машинный код на этапе создания дистрибутива (как в NSIS) либо интерпретируется во время инсталляции/деинсталляции (InnoSetup).

2. Использующие Windows Installer (последние версии InstallShield, WiX). Исходные файлы собираются в единый MSI-файл, который при установке используется сервисом Windows Installer.

Основные инсталляторы: InstallShield, NSIS, InnoSetup, WiX, Wise.

Язык XML и схемы данных.

Схемы данных (Schemas) являются альтернативным способом создания правил построения XML-документов. По сравнению с DTD, схемы обладают более мощными средствами для определения сложных структур данных, обеспечивают более понятный способ описания грамматики языка, способны легко модернизироваться и расширяться. Безусловным достоинством схем является также то, что они позволяют описывать правила для XML- документа средствами самого же XML.

Создавая схемы данных, мы определяем в документе специальный элемент, <schema>;, внутри которого содержатся описания правил.

XML Schema — язык описания структуры XML-документа и используется для определения правил достоверного (valid) документа XML.

Как большинство языков описания XML, XML Schema была задумана для определения правил, которым должен подчиняться документ. Но, в отличие от других языков, XML Schema была разработана так, чтобы её можно было использовать в создании программного обеспечения для обработки документов XML.

После проверки документа на соответствие XML Schema читающая программа может создать модель данных документа, которая включает:

· словарь (названия элементов и атрибутов);

· модель содержания (отношения между элементами и атрибутами и их структура);

· типы данных.

Каждый элемент в этой модели ассоциируется с определённым типом данных, позволяя строить в памяти объект, соответствующий структуре XML-документа. Языкам объектно-ориентированного программирования гораздо легче иметь дело с таким объектом, чем с текстовым файлом.

Другим удобством XML Schema является то, что один словарь может ссылаться на другой, и, таким образом, разработчик может использовать уже существующие словари и легче устанавливать и распространять стандарты XML структуры для определённых задач (например, словарь протокола SOAP).

Файл, содержащий XML Schema, обычно имеет расширение «.xsd» (XML Schema definition).

Так же как DTD схема XML Schema определяет допустимые строительные блоки XML документа.

XML Schema:

· элементы, входящие в документ

· атрибуты, допустимые в документе

· дочерние элементы

· порядок дочерних элементов

· количество дочерних элементов

· может ли элемент быть пустым или может содержать текст

· типы элементов и атрибутов

· фиксированные и значения по умолчанию элементов и атрибутов

XSL-трансформация

С помощью XSL можно трансформировать XML-документ в любой вид, будь то HTML, WML, RTF, PDF, SQL, или даже SWF (flash-запускаемый модуль), а также XSL. XSL несёт в себе информацию о том, как будет оформлен документ, где и как должны располагаться данные.

Для того, чтобы обработать XML документ c помощью XSL, необходимо в XML документе написать следующую инструкцию:

<?xml-stylesheet type="text/xsl" href="my-style.xsl"?>

XSLT (eXtensible Stylesheet Language Transformations) — язык преобразования XML-документов. Спецификация XSLT входит в состав XSL и является рекомендацией W3C.

При применении таблицы стилей XSLT, состоящей из набора шаблонов, к XML-документу (исходное дерево) образуется конечное дерево, которое может быть сериализовано в виде XML-документа, XHTML-документа (только для XSLT 2.0), HTML-документа или простого текстового файла. Правила выбора (и, отчасти, преобразования) данных из исходного дерева пишутся на языке запросов XPath.

XSLT имеет множество различных применений, в основном в области web-программирования и генерации отчётов. Одной из задач, решаемых языком XSLT, является отделение данных от их представления, как часть общей парадигмы MVC (англ. Model-view-controller). Другой стандартной задачей является преобразование XML-документов из одной XML-схемы в другую.

Задачи, решаемые при использовании языка XSLT:

- отделение данных от их представления, как часть общей парадигмы MVC ( Model-view-controller).

- преобразование XML-документов из одной XML-схемы в другую.

Процесс выполнения XSLT-преобразования

В процессе выполнения XSLT-преобразования задействованы:

· один или несколько входных XML-документов;

· одна или несколько таблиц cтилей XSLT;

· XSLT-процессор;

· один или несколько выходных документов.

В простейшем случае XSLT-процессор получает на входе два документа — входной XML-документ и таблицу стилей XSLT — и создает на их основе выходной документ.

Язык XSLT является декларативным, а не процедурным. Вместо определения последовательности исполняемых операторов, этот язык определяет правила, которые будут применяться во время преобразования. Само преобразование ведется по фиксированному алгоритму.

Ancestor:: — Возвращает множество предков. attribute:: — Возвращает множество атрибутов текущего элемента. child:: — Возвращает множество потомков на один уровень ниже. descendant:: — Возвращает полное множество потомков. parent:: — Возвращает предка на один уровень назад. self:: — Возвращает текущий элемент. И др.