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




НазваниеАнализ предметной области представляет собой процесс определения того, что система должна уметь делать, какие обязанности она должна на себя взять и какой
страница1/13
Дата публикации28.03.2013
Размер0.94 Mb.
ТипЛекция
vbibl.ru > Информатика > Лекция
  1   2   3   4   5   6   7   8   9   ...   13
Лекция №1

Введение в объектно-ориентированный анализ.

Анализ предметной области представляет собой процесс определения того, что система должна уметь делать, какие обязанности она должна на себя взять и какой сервис она должна обеспечить; при этом делается акцент на том, что система должна делать, но не предусматривается, как это сделать. Конечная цель анализа – получение модели предметной области.

Есть две концепции построения мира:

  1. Концентрируем внимание на происходящих в нём процессах;

  2. Концентрируем внимание на сущностях, их порождающих.

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

Пример: Существует некий абстрактный модуль "трамвай", который работает с входными и выходными потоками "пассажиры". Алгоритм сводится к управлению потоками в трамвае и на остановках.

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

Пример: Теперь мы рассматриваем "трамвай", как объект с встроенными данными. И метод "открыть двери" приглашает объекты "пассажир" к выходу или входу.

Объекты, обладающие сходством структуры и поведения, образуют класс. Например, "трамвай №5" и "трамвай №7" – объекты класса "трамваи".

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

Принципиальное отличие между структурным подходом и объектно-ориентированным анализом заключается в том, что в первом случае обработка данных и их потоков рассматривается отдельно, а в объектно-ориентированном анализе– совместно.

Относительно выбора метода однозначного ответа нет. Но нельзя смешивать оба этих метода.

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

Все инструментальные средства можно поделить на 2 категории:

  1. традиционные объектно-ориентированные средства разработки: Visual Work, Smal Talk, Next Step, Visual Age;

  2. визуальные средства разработки вроде Visual Basic, Power Builder, Delphi, Visual Kafe, I++.

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

Среды, которые исповедуют объектно-ориентированный подход основаны на 4-ёх фундаментальных принципах:

  • абстракции,

  • инкапсуляции,

  • наследовании,

  • полиморфизме.

По сравнению с визуальными средами объектные среды обеспечивают создание приложений с более сложной структурой.

Главное достоинство объектно-ориентированных сред– возможность многократного использования объектов, стройная логика разработки и масштабируемость создаваемых систем.

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

Есть ещё третья категория: визуальные-объектно-ориентированные среды.

Они обеспечивают более высокий уровень абстракции и все лучшие черты первых двух категорий. Новые версии Power Age, Power Builder, Delphi, Small Talk 5.
^ О повторном использовании объектов.

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

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




U V

Ввод и F Интерпретация Реальный мир

кодирование и вывод

u f v Компьютер
ОО подход основан на систематическом использовании моделей для языковой независимой разработки программной системы на основе ее прагматики.

Симантика – смысл программы с точки зрения выполняющего его компьютера.

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

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

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




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

^ Объектно-ориентированная разработка программ


  1. ОО методологии (технологии разработки программных систем).

  2. Инструментальные средства, поддерживающие эти технологии.

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

ОО технология – ОМТ (Object Modeling Technique).

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

Сложность присущая программному обеспечению.

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

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

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

Существенной чертой этих программных средств является их сложность.

Сложность определяется 4-мя основными причинами:

  1. Сложность реальной предметной области;

  2. Трудностью управления процессом разработки;

  3. Необходимостью обеспечить достаточную гибкость конечного программного продукта;

  4. Неудовлетворительными способами описания больших дискретных систем.


^ Сложность проблемы.

Внешняя сложность– несоответствие требований и видения проблемы пользователем и разработчиком .

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

Дополнительная сложность возникает в процессе изменения требований к разработанной системе.

В процессе разработки больших программных систем происходит эволюция в разработке и использовании этих систем.

Сопровождение – устранение ошибок.

Эволюция – внесение изменений в систему в ответ на изменение требований.

Сохранение – использование всех возможных способов для поддержания жизни в старой системе.
Трудность управления процессом разработки.

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

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

Всегда возникают значительные трудности с координацией хода работ над коллективным продуктом. Большое количество разработчиков подразумевает иерархические связи между ними. Главной проблемой является поддержание целостности основной идеи в ходе работы.

Лекция №2

Гибкость программного обеспечения.

Из-за отсутствия стандартов на программную продукцию программист сам должен для себя создавать стандарты и следовать им.
^ Сложность описания поведения отдельных систем.

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

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

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

Вывод: это является главной причиной обязательного тестирования программных систем. На данный момент полное тестирование таких систем провести невозможно.

В аналоговых системах небольшое изменение на входе вызовет небольшое отклонение на выходе. На данный момент у нас нет совершенных математических инструментов для исследования всех дискретных состояний этих систем.

^ Структура сложных систем.


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

Мы можем понять сложную систему только благодаря тому, что мы раскладываем ее на отдельные составляющие. Уровни иерархии представляют различные абстракции, где каждый может быть рассмотрен отдельно. На каждом уровне существует набор устройств, который совместно обеспечивает некоторые функции более высокого уровня.
^ Структура растений и животных
Животные и растения как пример сложных систем. Растение состоит из трех частей: корень, ствол, листья. Лист – различные клетки. Клетки ….

Пример, Материя – атомы – электроны – элементарные частицы… Все составляющие одного уровня взаимодействуют друг с другом.

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

В природе наблюдается экономия средств выражения.
^ Структура вещества
Скопления




Галактика Галактика
Звезды Планета Квазары
В природе действуют всего 4 силы:

  • гравитационная;

  • электромагнитная;

  • слабого взаимодействия;

  • сильного взаимодействия.


Структура социальных систем
Корпорация
Компания Компания




Отделения
Филиалы




Офисы
5 признаков сложных систем.

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

  2. Выбор низшего уровня абстракции достаточно произволен и в большой степени определяется наблюдателем.

  3. Внутри элементные связи обычно сильнее межэлементных. Поэтому высокочастотные взаимодействия внутри структуры оказываются естественным образом отделены от низкочастотных взаимодействий между структурами.

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

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


^ Организованная и неорганизованная сложность.

Каноническая форма сложной системы
Сложные системы содержат много различных иерархий.

В самолёте можно выделить иерархию системы электропитания, управления полётом и т.д. Такие иерархии – это системы типа «быть частью».


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

Их называют ещё структура объектов и структура классов соответственно.
2 иерархии:


  1. - быть частью – объектов;

  2. - это есть – иерархия классов.


Структура Структура объектов

классов


Рис. Каноническая форма сложной декомпозиции.


Лекция №3

Объединяя понятия структуры объектов и структуры классов с 5-ю признаками сложных систем, мы приходим к тому, что фактически все сложные системы можно представить одной и той же (канонической) формой, которая показана на рис (смю пред. лекцию).

Всё то, что сказано, является канонической формой сложной декомпозиции.

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

Выбор класса или объекта соответствует его низшему уровню абстракции и зависит от конкретной решаемой задачи.

Связи среди объектов одного уровня особенно сильны. Больше всего это касается структуры объектов.

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

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

Структуры классов и структуры объектов называют архитектурой.
^ Человеческие возможности и сложная система.

Известно, что человек может адекватно реагировать не более, чем на 7 раздражителей одновременно, т.е. это максимальное кол-во единиц информации, которое человеческий мозг способен одновременно обработать. Это связано с объёмом кратковременной памяти человека.

Человеку необходимо в среднем 5 сек. на каждое новое событие.

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

«devide et empera»

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

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

^ Алгоритмическая декомпозиция.


Структурное проектирование: структурная схема, которая использует связи между различными функциональными элементами системы, это проектирование «сверху-вниз».

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

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

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

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

^ Алгоритмическая и объектно-ориентированная декомпозиция.

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

Полезнее сначала применить объектно-ориентированный подход.

Преимущества объектной декомпозиции:

  1. ОД уменьшает размер программных систем за счет повторного использования общих механизмов;

  2. ОО системы более гибкие и проще эволюционируют, т.к. основаны на устойчивых промежуточных формах;

  3. ОД снижает риск при создании программных систем, т.к. развивается из меньших систем, которые уже проверены;

  4. ОД помогает разобраться в сложной программной системе.

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

Как мы обходим проблему восприятия человеком не более 7 событий.

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

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

Внутри системы обнаруживаются иерархии классов и объектов.

Структура объектов даёт схему взаимодействия друг с другом.

Структура классов определяет избыточность средств внутри системы.

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

Метод– это последовательный процесс создания ряда моделей, которые описывают вполне определёнными средствами различные стороны разрабатываемой программной системы.

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

Методы появились в ответ на растущую сложность программных систем.
В 60-70 г. наибольшее распространение получил метод структурного программирования (сверху-вниз) или комбинированный метод. Он основался на языках Fortran и Cobol. В этих языках основной базовой единицей является процедура, а программа в целом принимает вид дерева. В этом случае применяется алгоритмическая декомпозиция для разбиения большой системы на маленькие.

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

Поэтому появились модифицированные методы:

  1. Метод структурного программирования сверху-вниз;

  2. Метод организации потоков данных;

  3. Метод объектно-ориентированного проектирования.


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

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

^ Метод потоков данных:

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

Метод объектно-ориентированного программирования:

программная система представляется совокупностью объектов, взаимодействующих друг с другом. Каждый объект есть экземпляр определенного класса, классы образуют иерархию (SmallTalk, Object Pascal, Clos, Ada, C++).

Лекция №4

^ Проектирование сложных систем.
Цели проектирования.

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

Цель проектирования– создание системы, которая:

  1. Удовлетворяет данным функциональным спецификациям;

  2. Согласно с ограничениями, накладываемыми оборудованием, имеет приемлемую цену ;

  3. Удовлетворяет явным и неявным требованиям по эксплуатационным качествам и ресурсам потребления;

  4. Удовлетворяет явным и неявным критериям дизайна продукта;

  5. Удовлетворяет требованиям к самому процессу разработки – стоимость, продолжительность.


^ Важность построения модели.

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

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

Проектирование сложной программной системы не сводится к выполнению определенного списка действий. Проектирование- постепенный и интерактивный процесс.

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

  • Условные обозначения – язык для описания каждой модели;

  • Процесс – правило проектирования модели;

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

^ Модели объектно-ориентированного проектирования.




Рис. Модели ООП.
Необходимо создать такую модель системы, которая основывается на объектах, которые принадлежат проблемной области и сформирована как результат применения объектно-ориентированной декомпозиции.

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


^ Объектный подход.

Эволюция объектной модели.

Поколения языков программирования.

В основе ООП (OOD– object-oriented design) лежит объектный подход. Основные принципы: абстрагирование, типизация, параллелизм и устойчивость.

Тенденции развития методов программирования:

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

  2. Развитие и совершенствование языков программирования высокого уровня.


^ I-ое поколение 54-58 г.

Fortran 1

Algol-58 математические формулы

Flowmatic

IPL V

II-ое поколение 59-61 г.

Fortran II - подпрограммы, раздельная компиляция

Algol-60 - блочная структура, типы данных

Cobol - описание данных, работа с файлами

Lisp - обработка списков, указателей, сборка мусора

^ III-е поколение 62-70 г.

PL/1 - Fortran+Algol+Cobol

Algol-68 - более строгий приемник Algol-60

Pascal - менее строгий приемник Algol-60

Simula - классы, абстрактные данные.

^ IV-е поколение 70-80 г.

Small Talk

Ada объектные и объектно-ориентированные

Clos языки программирования

C++

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

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

Возникали целые клоны языков, такие как Ada – наследник Алгол, Pascal и Simula.

Возник язык C++=C+ Simula.

^ Топология языков I и начальной стадии II-го поколений.



Для таких языков как Fortran и Cobol основным элементом конструкции является подпрограмма. Программы, реализованные на таких языках, имеют относительно простую структуру, состоящую из области глобальных данных и подпрограмм. Ошибка в любой части программы может иметь не предсказуемые последствия. В больших программах может возникнуть путаница из-за большого количества перекрестных связей, запутанной схемой управления, что в результате приводит к снижению надёжности и достоверности.
^ Топология языков позднего II и раннего III-го поколений.


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

  1. В языках появились механизмы, поддерживающие передачи параметров;

  2. Заложены основы структурного программирования (механизм вложения подпрограмм, ограничение области действия (видимости) компонентов);

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

Недостаток: не смогла решить задачу обеспечения программирования высоко уровня и использования многообразия данных.

Топология языков III-го поколения.

Модули



Данные

Подпро-граммы


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

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



Абстрагирование, достигаемое посредством использования процедур, подходит для описания абстрактных действий, но не годится для описания абстрактных объектов. Иногда в сложных системах именно сложность объектов определяет сложность проблемы. Следует два вывода:

  1. Возникают методы проектирования управляемыми данными;

  2. Появляется теория типов, которая воплощается в языках типа Pascal.

Естественным завершением этих идей явилось создание объектных и ОО языков.

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

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

Если процедуры и функции – глаголы, а данные – существительные, то процедурные программы состоят из глаголов, а ОО – из существительных.

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

ОО анализ и ОО проектирование отражают эволюционное развитие проектирования. Алгоритмическая декомпозиция помогает только до определенного предела и обращение к ОО декомпозиции необходимо.

^ Объектно-ориентированное проектирование,

объектно-ориентированный дизайн,

объектно-ориентированный анализ

Лекция №5
  1   2   3   4   5   6   7   8   9   ...   13

Добавить документ в свой блог или на сайт

Похожие:

Анализ предметной области представляет собой процесс определения того, что система должна уметь делать, какие обязанности она должна на себя взять и какой iconВнедрение информационно-коммуникативных технологий в образовательный процесс Каякентского района
Вствовать себя комфортно в новых социально- экономических условиях жизни? Какую роль должна играть школа, и какой она должна быть...

Анализ предметной области представляет собой процесс определения того, что система должна уметь делать, какие обязанности она должна на себя взять и какой iconУчебное занятие в системе дополнительного образования представляет...
Педагог имеет право самостоятельно отработать удобную для себя модель плана учебного занятия, которая должна содержать

Анализ предметной области представляет собой процесс определения того, что система должна уметь делать, какие обязанности она должна на себя взять и какой iconВопросы: Проблемы автоматизации документооборота
Система описывает сценарии использования, и выясняет у пользователя, какой из сценариев ему близок более других. Например, помогая...

Анализ предметной области представляет собой процесс определения того, что система должна уметь делать, какие обязанности она должна на себя взять и какой iconПоходная аптечка велотуриста это все равно что ремнабор для его байка!...
Как всегда перед тем, как описать то, что необходимо взять с собой, применим "научный подход" рассмотрим статистику, что же случается...

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

Анализ предметной области представляет собой процесс определения того, что система должна уметь делать, какие обязанности она должна на себя взять и какой iconТема: «Духовная сторона сражения»
Церковь должна не просто гордиться тем, что она религиозная община, а должна быть народом Божьим. Это не место с условиями, это народ...

Анализ предметной области представляет собой процесс определения того, что система должна уметь делать, какие обязанности она должна на себя взять и какой iconИ засчитывается ли ей этот день или она должна возместить его?
Первый вопрос: если женщина очистилась от кровотечения сразу после утреннего намаза, должна ли она воздержаться от еды, питья и т...

Анализ предметной области представляет собой процесс определения того, что система должна уметь делать, какие обязанности она должна на себя взять и какой iconИсследования
20-40 станиц, должна называться в соответствии с ее содержанием, например: «Современное состояние проблемы изменения умственной работоспособности...

Анализ предметной области представляет собой процесс определения того, что система должна уметь делать, какие обязанности она должна на себя взять и какой iconСьюзен Виггз «Просто дыши»
Здесь к ней приходит понимание, что прежде всего она должна быть самостоятельной и уметь радоваться жизни, как это делает Ширил —...

Анализ предметной области представляет собой процесс определения того, что система должна уметь делать, какие обязанности она должна на себя взять и какой iconВот и лето пришло пора планировать отпуск и собирать чемоданы. Что...
Что стоит обязательно взять с собой? Какие вещи особенно актуальны в наступающем сезоне и помогут вам стать настоящей курортной звездой?...

Вы можете разместить ссылку на наш сайт:
Школьные материалы


При копировании материала укажите ссылку © 2013
контакты
vbibl.ru
Главная страница