4. Проектирование сложных объектов. Основные принципы проектирования. Аспекты и стадии проектирования
Прое́кт — это уникальная деятельность, имеющая начало и конец во времени, направленная на достижение заранее определённого результата/цели, создание определённого, уникального продукта или услуги, при заданных ограничениях по ресурсам и срокам, а также требованиям к качеству и допустимому уровню риска.
В ходе анализа ищется ответ на вопрос: «Что должна делать будущая система?». Именно на этой стадии закладывается фундамент успеха всего проекта. Известно множество неудачных реализаций из-за неполноты и неточностей в определении требований к системе.
В процессе синтеза формируется ответ на вопрос: «Каким образом система будет реализовывать предъявляемые к ней требования?». Выделяют три этапа синтеза: проектирование ПС, кодирование ПС, тестирование ПС.
Информационная модель описывает информацию, которую, по мнению заказчика, должна обрабатывать ПС. Функциональная модель определяет перечень функций обработки. Поведенческая модель фиксирует желаемую динамику системы (режимы ее работы).
На выходе этапа проектирования — разработка данных (результат преобразования), разработка архитектуры (основные компоненты) и процедурная разработка (последовательность действий) ПС.
Известно, что технологический цикл конструирования программной системы (ПС) включает три процесса — анализ, синтез и сопровождение.
В ходе анализа ищется ответ на вопрос: «Что должна делать будущая система?». Именно на этой стадии закладывается фундамент успеха всего проекта. Известно множество неудачных реализаций из-за неполноты и неточностей в определении требований к системе.
В процессе синтеза формируется ответ на вопрос: «Каким образом система будет реализовывать предъявляемые к ней требования?». Выделяют три этапа синтеза: проектирование ПС, кодирование ПС, тестирование ПС.
5. Развитие парадигмы программирования
Сначала строится модульная структура программы в виде дерева. Затем поочередно программируются модули программы, начиная с модуля самого верхнего уровня (головного), переходя к программированию какого-либо другого модуля только в том случае, если уже запрограммирован модуль, который к нему обращается. После того, как все модули программы запрограммированы, производится их поочередное тестирование и отладка в таком же (нисходящем) порядке. Восходящей разработки. Сначала строится модульная структура программы в виде дерева. Затем поочередно программируются модули программы, начиная с модулей самого нижнего уровня, в таком порядке, чтобы для каждого программируемого модуля были уже запрограммированы все модули, к которым он может обращаться. После того, как все модули программы запрограммированы, производится их поочередное тестирование и отладка в принципе в таком же (восходящем) порядке, в каком велось их программирование.
Нисходящей разработки. Сначала строится модульная структура программы в виде дерева. Затем поочередно программируются модули программы, начиная с модуля самого верхнего уровня (головного), переходя к программированию какого-либо другого модуля только в том случае, если уже запрограммирован модуль, который к нему обращается. После того, как все модули программы запрограммированы, производится их поочередное тестирование и отладка в таком же (нисходящем) порядке.
Структурное программирование – это процесс пошагового разбиения алгоритма на все более мелкие части, с целью получить такие элементы, для которых можно легко написать конкретные предписания.
Два принципа структурного программирования:
1.последовательная детализация «сверху – вниз»
2.ограниченность базового набора структур для построения алгоритмов любой степени сложности
Требования структурного программирования:
1.программа должна составлятся мелкими шагами, таким образом сложная задача разбивается на достаточно простые, легко воспринимаемые части
2.логика программы должна опираться на минимальное число достаточно базовых управляющих структур.
Приступая к разработке каждой программы ПС, следует иметь ввиду, что она является большой системой, поэтому нужно принимать меры для ее упрощения. Для этого программу разрабатывают по частям, которые называются программными модулями. Такой метод программирования называют модульным программированием.
6. Функциональное моделирование. Стандарты IDEF0, IDEF3.
Модели SADT (IDEF0) традиционно используются для моделирования организационных систем (бизнес-процессов). Следует отметить, что метод SADT успешно работает только при описании хорошо специфицированных и стандартизованных бизнес-процессов в зарубежных корпорациях, поэтому он и принят в США в качестве типового. Достоинствами применения моделей SADT для описания бизнес-процессов являются:
-полнота описания бизнес-процесса (управление, информационные и материальные потоки, обратные связи);
-жесткие требования метода, обеспечивающих получение моделей стандартного вида;
-соответствие подхода к описанию процессов стандартам ISO 9000.
Недостатки: В большинстве российских организаций бизнес-процессы начали формироваться и развиваться сравнительно недавно, они слабо типизированы, поэтому разумнее ориентироваться на менее жесткие модели.
Метод моделирования IDEF3 [22] предназначен для таких моделей процессов, в которых важно понять последовательность выполнения действий и взаимозависимости между ними. Хотя IDEF3 и не достиг статуса федерального стандарта США, он приобрел широкое распространение среди системных аналитиков как дополнение к методу функционального моделирования IDEF0 (модели IDEF3 могут использоваться для детализации функциональных блоков IDEF0, не имеющих диаграмм декомпозиции). Основой модели IDEF3 служит так называемый сценарий процесса, который выделяет последовательность действий и подпроцессов анализируемой системы.
7. Информационное моделирование. Стандарты IDEF1, IDEF1X/
IDEF1 — Information Modeling — методология моделирования информационных потоков внутри системы, позволяющая отображать и анализировать их структуру и взаимосвязи;
IDEF1X (IDEF1 Extended) — Data Modeling — методология построения реляционных структур (баз данных), относится к типу методологий «Сущность-взаимосвязь» (ER — Entity-Relationship) и, как правило, используется для моделирования реляционных баз данных, имеющих отношение к рассматриваемой системе; Диаграммы потоков данных (Data Flow Diagrams - DFD) [6] представляют собой иерархию функциональных процессов, связанных потоками данных. Цель такого представления - продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.
С другой стороны, эти разновидности средств структурного анализа примерно одинаковы с точки зрения возможностей изобразительных средств моделирования. При этом одним из основных критериев выбора того или иного метода является степень владения им со стороны консультанта или аналитика, грамотность выражения своих мыслей на языке моделирования. В противном случае в моделях, построенных с использованием любого метода, будет невозможно разобраться.
Базовые средства диаграммы не обеспечивают полного описания требований к программному изделию. Очевидно, что должны быть описаны стрелки — потоки данных — и преобразователи — процессы. Для этих целей используются словарь требований (данных) и спецификации процессов.
8. Средства и элементы статистических и динамических моделей объектно-ориентированных систем (статические и динамические диаграммы UML).
Логическое представление описывает перечень и смысл ключевых абстракций и механизмов, которые формируют предм. область или определяют архитектуру системы.
Большинство современных методов ООАП основаны на использовании языка UML. Унифицированный язык моделир-ия UML представляет собой язык для определения, представления, проектирования и документирования програм. систем, организационно-экономических систем, технических систем и других систем различной природы. UML содержит стандартный набор диаграмм и нотаций самых разнообразных видов. Главными в разработке UML были следующие цели:
1.предоставить пользователям готовый к использованию 2.выразительный язык визуального моделирования;
3.предусмотреть механизмы расширяемости и специализации для расширения базовых концепций;
4.обеспечить независимость от конкретных языков программирования и процессов разработки.
5.обеспечить основу для понимания этого языка
6.стимулировать рост рынка объектно-ориентированных инструментальных средств;
7.интегрировать лучший практический опыт.
Статические: диаграммы классов, диаграммы объектов, диаграммы модулей, диаграммы процессов.
Динамические: состояний и взаимодействий.
Структурные (structural) модели:
диаграммы классов (class diagrams) - для моделирования статической структуры классов системы и связей между ними;
диаграммы компонентов (component diagrams) - для моделирования иерархии компонентов (подсистем) системы;
диаграммы размещения (deployment diagrams) - для моделирования физической архитектуры системы.
Модели поведения (behavioral):
диаграммы вариантов использования (use case diagrams) - для моделир-ия функциональных требований к системе;
диаграммы взаимодействия (interaction diagrams):
диаграммы последов-ти (sequence diagrams) и кооперативные диаграммы (collaboration diagrams) - для моделирования процесса обмена сообщениями м/у объектами;
диаграммы состояний (statechart diagrams) - для моделирования поведения объектов системы при переходе из одного состояния в другое;
диаграммы деятельности (activity diagrams) - для моделирования поведения системы в рамках различных вариантов использования, или потоков управления.
9.Порождающие паттерны. Назначение, обобщенные свойства, применение. Пример реализации.
Абстрактная фабрика .Строитель (Builder). Прототип.
Фабричный метод (Factory Method). Одиночка (Singleton).
Пусть Ваша программа управляет файлами в различных файловой системе, для чего Вы от класса CFile порождаете потомки CFATFile и CNTFSFile. А еще файлы могут быть либо текстовыми, либо двоичными - да еще и в каждой файловой системой
// Это классы отвечающие за физическую реализацию
class CFile {
public: virtual void doIt1 () = 0; virtual void doIt2 () = 0;};
// В конкретных классах виртуальные функции исполняют несколько полезных вещей непосредственно
// с файловой системой.
class CFATFile : public CFile {
public:
void doIt1 () { format("c:"); };
void doIt2 () { loadVirus("OneHalf"); };};
class CNTFSFile : public CFile {
public: void doIt1 () { mustdie("windows"); };
void doIt2 () { catchHim("Bill"); };};
// А это классы, отвеч. за файлы на более выс. уровне
class CAbstractFile : {
public:virtual void processFile () = 0;
private: CFile* m_file;};
class CTextFile : public CAbstractFile {
public:void processFile () { m_file->doIt1(); };};
class CBinFile : public CAbstractFile {
public:void processFile () { m_file->doIt2(); };};
Таким образом паттерн Мост (Bridge) разделяет абстракцию и ее реализацию. Вот структура паттерна.
10. Структурные паттерны. Назначение, обобщенные свойства, применение. Пример реализации.
Adapter/Адаптер, Wrapper Bridge/Мост, Handle/Body
Composite/Компоновщик Decorator/Декоратор, Wrapper
Facade/Фасад Flyweight/Приспособленец
Proxy/Заместитель, Surrogate
Адаптер, Adapter — структурный шаблон проектирования, предназначенный для организации использования функций объекта, недоступного для модификации, через специально созданный интерфейс.
Система поддерживает требуемые данные и поведение, но имеет неподходящий интерфейс. Чаще всего шаблон Адаптер применяется если необходимо создать класс, производный от вновь определяемого или уже существующего абстрактного класса.
Шаблон Адаптер позволяет включать уже существующие объекты в новые объектные структуры, независимо от различий в их интерфейсах.
11.Паттерны поведения. Назначение, обобщенные свойства, применение. Пример реализации
Command/Команда, Interpreter/Интерпретатор
Iterator/Итератор,Cursor,Mediator/Посредник Memento/Хранитель,Observer/Наблюдатель,
Наблюдатель - паттерн поведения объектов, устанавливающий систему оповещения объектами своих соседей в процессе их деятельности. Известен также под именами: Dependents (подчиненные), Publish-Subscribe (издатель-подписчик). оригинал источник codelab.ru codelab.ru
Очень часто в процессе функционирования и взаимодействия объектов системы нужно оповещать других участников по завершении какой-нибудь значимой операции.
В каждый класс, производящий знач. действия добавлять обращение к этим всем другим заинтересованным объектам, но этот способ довольно губителен: мало того, что таким образом мы «хардкодим» как попало новые связи между объектами – это еще и в разы затруднит последующую модификацию каких либо участников.
12. Язык XML: средства, назначения и особенности использования. XML и DTD.
XML-это потомок (одна из возможных реализаций спецификации, как и HTML) языка Standard Generalized Markup Language (SGML), который является очень мощным, но сложным языком разметки. XML используется для описания данных (объектов). Документы XML — это простые текстовые документы с независимым от платформы способом представления данных. XML чувствителен к регистру и требует либо откры¬вающего и закрывающего тэгов, либо тэга, который как открывает, так и закрывает элемент. Название элемента должно начинаться с буквы, символа подчеркивания или двоеточия, хотя на практике двоеточие использовать не следует. Название не должно начинаться со строчки "XML" из любых комбинаций букв верхнего или нижнего регистров.
Документ XML состоит из необязательного пролога, который, как правило, описывает версию XML, тела, которое содержит информацию, и необязательного эпилога, который содержит комментарии или инструкции обработки.
13. Язык XML и схемы данных.
XML-это потомок языка Standard Generalized Markup Language (SGML), который является очень мощным, но сложным языком разметки. XML используется для описания данных (объектов). Документы XML — это простые текстовые документы с независимым от платформы способом представления данных. XML чувствителен к регистру и требует либо откры¬вающего и закрывающего тэгов, либо тэга, который как открывает, так и закрывает элемент. Название элемента должно начинаться с буквы, символа подчеркивания или двоеточия, хотя на практике двоеточие использовать не следует. Название не должно начинаться со строчки "XML" из любых комбинаций букв верхнего или нижнего регистров.
14.Методы и средства обработки XML документов с использ-ем моделей DOM и SAX, преимущ-ва и недостатки.
Для выполнения анализа данных разрабатываются различные методы, технологии и реализации.
Так, наиболее распространены 2 подхода: объектная модель документа DOM и SimpleAPI for XML. Эти программные интерфейсы кардинально отличаются друг от друга.
DOM - это рекомендация W3C для обработки документов XML. DOM API загружает весь документ XML в память в виде древовидной структуры и позволяет манипулировать структурой документа посредством добавления, удаления и изменения узлов.
SAX - это управляемый событиями подход к обработке документов XML. SAX API анализирует документ XML динамически, вызывая соответствующие методы при появлении элементов разметки, вместо загрузки всего документа в память.
15.Языки Extensible Markup Language(XSL) и XSL Transformations (XSLT): назначение и особенности использования.
Расширяемый Язык Таблиц -. это язык, используемый для указания того, как структурированное содержимое XML должно быть представлено; то есть, как содержимое-источник должно быть стилизовано, расположено и разбито на страницы для конкретного носителя представления, такого как окно Web-браузера, или портативное ручное устройство, или набор физических страниц в каталоге, отчёте, или книге.
XSL Transformations - используется для преобразования документов XML из одной формы в другую.
XSL Formatting Objects - используется для описания формата просматриваемых документов XML.
XSLT (не считая собственных запросов) чаще всего требует написания таблиц стилей, которые сами являются XML-документами. програмирование XSLT может рассматриваться как написание скриптов.
16. Язык XPath и его применение для доступа к элементам XML.
Язык XPath и его применение для доступа к элементам XML.
XPath -используется для произвольного выбора узлов из документов XML.
17.Фазы, итерации и циклы разработки. Рабочие процессы, модели и артефакты.
Итерация — это полный цикл разработки, вырабатывающий промежуточный продукт. По мере перехода от итерации к итерации промежуточный продукт инкрементно усложняется, постепенно превращаясь в конечную систему. В состав каждой итерации входят все рабочие потоки — от сбора требований до тестирования. От итерации к итерации меняется лишь удельный вес каждого рабочего потока — он зависит от этапа. На этапе Начало основное внимание уделяется сбору требований, на этапе Развитие — анализу и проектированию, на этапе Конструирование — реализации, на этапе Переход — тестированию.
Рабочие потоки процесса имеют следующее содержание:
1.Сбор требований — описание, что система д. делать;
2.Анализ — преобразование требований к системе в классы и объекты, выявляемые в предметной области;
3.Проектирование — создание статического и динамического представления системы, выполняющего выявленные требования и являющегося эскизом реализации;
4.Реализация — производство программного кода, который превращается в исполняемую систему;
5.Тестирование — проверка всей системы в целом.
Каждый рабочий поток определяет набор связанных артефактов и действий. Артефакт — это документ, отчет или выполняемый элемент. Артефакт может вырабатываться, обрабатываться или потребляться. Действие описывает задачи — шаги обдумывания, шаги исполнения и шаги проверки. Шаги выполняются участниками процесса.
19. Особенности модели распределенных объектов. Модель rpc.
Идея вызова удаленных процедур (Remote Procedure Call - RPC) состоит в расширении известного механизма передачи управления и данных внутри программы, выполняющейся на одной машине, на передачу управления и данных через сеть.
Цель RPC - сделать вызов удаленной процедуры внешне аналогичным вызову локальной процедуры, т.е., сделать RPC прозрачным: вызывающей процедуре не требуется знать, что вызываемая процедура находится на другой машине, и наоборот.
Т.о., средства удаленного вызова процедур предназначены для облегчения организации распределенных вычислений. Наибольшая эффективность использования RPC достигается в тех приложениях, в которых существует интерактивная связь между удаленными компонентами с небольшим временем ответов и относительно малым количеством передаваемых данных. Реализация удаленных вызовов существенно сложнее реализации вызовов локальных процедур.
1.Поскольку вызывающая и вызываемая процедуры выполняются на разных машинах, то они имеют разные адресные пространства, и это создает проблемы при передаче параметров и результатов.
2.Так как RPC не может рассчитывать на разделяемую память, значения параметров должны копироваться с одного компьютера на другой.
3.RPC – вызов использует нижележащую систему связи, однако это не должно быть явно видно ни в определении процедур, ни в самих процедурах. Удаленность вносит проблемы.
4.В отл-е от выполнения вызывающей программы и вызываемой локальной процедуры на одной машине в реализации RPC участвуют как минимум два процесса - по одному на каждой машине.
5.Существует ряд проблем, связанных с неоднородностью языков программирования и операционных сред: структуры данных и структуры вызова процедур, поддерживаемые в каком-либо одном языке программирования, не поддерживаются точно так же во всех других языках.
20. Архитектура механизмов rmi.
RMI - технология построения распределенных приложений, предложенная в спецификации языка Java. Объект, доступный для удаленных приложений, виден через опубликованный Java-интерфейс, содержащий некоторое множество методов. Один Java-объект может иметь несколько интерфейсов, каждый из которых характеризует определенное поведение этого объекта. Клиент взаимодействует с объектом через ссылку на один из интерфейсов, реализованных объектом. Обращение к удаленному объекту происходит аналогично обычному локальному вызову метода, т.е. прозрачно для разработчика. RMI поддерживает также передачу объектов из одного адресного пространства в другое, для чего используется технология сериализации объекта. Технология сериализации разработана специально для языка Java и обеспечивает распределение объектов по сети в реальном смысле этого слова.
Реализация RMI, по существу, состоит из трех абстрактных уровней:
Уровень заглушки и скелета обслуживающий пользователя. Этот уровень перехватывает вызовы методов, произведенные клиентом при помощи переменной - ссылки на интерфейс, и переадресует их в удаленную службу RMI. В прокси -модели , используемой в RMI, роль прокси выполняет класс заглушки , а роль RealSubject выполняет класс , реализующий удаленную службу . Скелет является вспомогательным классом , который создается для использования RMI. Скелет понимает, как взаимодействовать с заглушкой при RMI-соединении. Он читает параметры для вызова метода из соединения, производит вызов объекта, реализующего удаленную службу, принимает возвращаемое значение и записывает его обратно в заглушку .
Уровень удаленных ссылок
Этот уровень понимает, как интерпретировать и управлять ссылками на удаленные объекты служб. Уровни удаленных ссылок определяют и поддерживают семантику вызовов соединения RMI. Этот уровень предоставляет объект RemoteRef, который обеспечивает соединение с объектами, реализующими удаленные службы .
Реализация RMI в JDK 1.1 обеспечивает только один способ соединения клиентов с реализациями удаленных служб : однонаправленное соединение типа точка -точка . Перед тем , как клиент сможет использовать удаленную службу , экземпляр объекта , реализующего ее , должен быть создан на сервере и экспортирован в систему RMI.
Реализация RMI в Java 2 SDK добавляет новую семантику для соединения клиент - сервер . В этой версии RMI поддерживает способные к активизации удаленные объекты . Когда производится вызов метода прокси для такого объекта , RMI определяет, находится ли объект, реализующий удаленную службу, в пассивном состоянии . Если да , то RMI создаст экземпляр объекта и восстановит его состояние из дискового файла . Как только объект активизируется в памяти, он начинает вести себя так же, как и объект, реализующий удаленную службу JDK 1.1.
Транспортный уровень: при использовании уровневой архитектуры каждый из уровней может быть изменен или заменен без воздействия на остальную систему. Например, транспортный уровень может быть заменен протоколом UDP/IP без изменения остальных уровней.
Транспортный уровень осуществляет соединение между различными JVM. Все соединения представляют собой основанные на потоках сетевые соединения, использующие TCP/IP. Даже если две JVM работают на одном и том же физическом компьютере, они соединяются через стек сетевых протоколов TCP/IP.Этот соединение основано на адресе IP и номере порта.
На вершине TCP/IP RMI использует протокол уровня соединения, называемый Java Remote Method Protocol (JRMP). JRMP является частным, основанным на потоках, протоколом.
Хотя транспортный уровень предпочитает использовать несколько TCP/IP соединений, некоторые сетевые конфигурации разрешают только одно TCP/IP-соединение между клиентом и сервером. В этом случае, транспортный уровень распределяет несколько виртуальных соединений внутри одного TCP/IP-соединения.
Классы и интерфейсы механизма RMI.
Интерфейсы: основа RMI
На основе использования интерфейсов было достигнуто разделения описания поведения и реализации этого поведения. Такое разделение соответствует принятой практике, в которой клиенты знают об определениях служб, а серверы предоставляют эти службы. В RMI интерфейсы определяют поведение, а классы - реализацию.RMI поддерживает два класса, реализующих один и тот же интерфейс:
первый реализует поведения и исполняется на сервере;
второй класс работает как промежуточный интерфейс для удаленной службы и исполняется на клиентской машине.
Интерфейсы и классы, которые ответственные за работу с удаленными объектами в системе RMI, определены в иерархии пакета java.rmi.
Интерфейс java.rmi.Remote – это интерфейс, который объявляет набор методов, которые могут быть вызваны с удаленной машины. Удаленный интерфейс должен удовлетворять следующим требованиям:
1) удаленный интерфейс должен расширять интерфейс java.rmi.Remote.
2) каждое объявление метода в удаленном интерфейсе или его над-интерфейсах должно включать исключение java.rmi.RemoteException (или его суперклассы) в разделе throws вдобавок к остальным имеющимся исключениям.
3) в объявлении удаленного метода удаленный объект, объявленный как параметр или возвращаемое значение должен быть объявлен как удаленный интерфейс, а не реализация (implementation) класса того интерфейса.
Общие правила для класса, который реализует удаленный интерфейс:
Класс обычно расширяет java.rmi.server.UnicastRemoteObject
Класс может реализовывать любое количество удаленных интерфейсов
Класс может расширять другой удаленный класс
Класс может определять методы, которые не находятся на удаленном интерфейсе, но использовать их следует только локально.