Ответы для государственного экзамена по курсу Проектирование информационных систем (ПрИС) специальность Бизнес-информатика 080500 - файл n1.docx

приобрести
Ответы для государственного экзамена по курсу Проектирование информационных систем (ПрИС) специальность Бизнес-информатика 080500
скачать (2138.5 kb.)
Доступные файлы (1):
n1.docx2139kb.14.09.2012 23:12скачать

n1.docx

1   2   3   4   5

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

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

Структурный анализ (Structured analysis) – это основанная на моделировании, ориентированная на процессы техника, используемая для анализа существующей системы, определения требований новой системы или того и другого. Для описания работы организации необходимо построить модель бизнес-процессов, адекватную предметной области. Эта модель в дальнейшем послужит основой проектирования ИС данной организации.

К моделям предметных областей предъявляются следующие требования:

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

Структурный аспект предполагает построение:

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

Процессный подход в описании предметной области

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

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

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

Процессная модель экономического объекта должна строиться с учетом следующих положений:

1. Верхний уровень модели должен отражать только контекст деятельности (т.е., контекстная диаграмма должна отражать взаимодействие моделируемого предприятия с внешним миром).

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

3.Каждое из направлений деятельностей должно быть детализировано на бизнес-процессы.

4. Детализация бизнес-процессов осуществляется посредством бизнес– функций.

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

6.Описание элементарной операции осуществляется с помощью миниспецификации.

  1. Метод функционального моделирования SADT. Методология IDEF0.

Метод функционального моделирования SADT

Методология SADT разработана Дугласом Россом и получила дальнейшее развитие в работе [4]. На ее основе разработана, в частности, известная методология IDEF0 (Icam DEFinition), которая является основной частью программы ICAM (Интеграция компьютерных и промышленных технологий), проводимой по инициативе ВВС США.

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

Основные элементы этой методологии основываются на следующих концепциях:

графическое представление блочного моделирования. Графика блоков и дуг SADT-диаграммы отображает функцию в виде блока, а интерфейсы входа/выхода представляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описываются посредством интерфейсных дуг, выражающих "ограничения", которые в свою очередь определяют, когда и каким образом функции выполняются и управляются;

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

ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков);

связность диаграмм (номера блоков);

уникальность меток и наименований (отсутствие повторяющихся имен);

синтаксические правила для графики (блоков и дуг);

разделение входов и управлений (правило определения роли данных).

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

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

Методология функционального моделирования IDEF0 Основные элементы и понятия IDEF0

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

Первым из них является понятие функционального блока (Activity Box). Функциональный блок графически изображается в виде прямоугольника (см. рис. 1) и олицетворяет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, "производить услуги”, а не "производство услуг”).

Каждая из четырех сторон функционального блока имеет своё определенное значение (роль), при этом:

Верхняя сторона имеет значение "Управление” (Control);

Левая сторона имеет значение "Вход” (Input);

Правая сторона имеет значение "Выход” (Output);

Нижняя сторона имеет значение "Механизм” (Mechanism).

Каждый функциональный блок в рамках единой рассматриваемой системы должен иметь свой уникальный идентификационный номер.



Рисунок 1. Функциональный блок.Вторым "китом” методологии IDEF0 является понятие интерфейсной дуги (Arrow). Также интерфейсные дуги часто называют потоками или стрелками. Интерфейсная дуга отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, отображенную данным функциональным блоком. Графическим отображением интерфейсной дуги является однонаправленная стрелка. Каждая интерфейсная дуга должна иметь свое уникальное наименование (Arrow Label). По требованию стандарта, наименование должно быть оборотом существительного.

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

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

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

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

Третьим основным понятием стандарта IDEF0 является декомпозиция (Decomposition). Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели.

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

16. Методология процессного моделирования IDEF3

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

Методология процессного моделирования IDEF3 позволяет описать логику взаимодействия информационных потоков, взаимоотношения между процессами обработки информации и объектами, являющимися частью этих процессов. Методология IDEF3 используется в моделировании деловых процессов для анализа завершенности процедур обработки информации. С их помощью описываются сценарии ведения процедур с учетом причинно-следственных связей между объектами системы. Единицами описания IDEF3 модели являются диаграммы и единицы работы (Unit of work (UOW)), также называемые работами (activity) и связи между ними.

Диаграмма является основной единицей описания, имеет имя и состоит из работ. Она может быть построена при декомпозиции функции IDEF0 модели или построена отдельно как IDEF3 диаграмма.



Правила определения работ:

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

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

3. Каждая работа в IDEF3 должна иметь ассоциированный документ, который включает текстовое описание компонентов работы: объектов (Objects), и фактов (Facts), связанных с работой, ограничений (Constraints), накладываемых на работу, и дополнительное описание работы (Description).

Окончание одной работы может служить сигналом к началу нескольких работ, или же одна работа для своего запуска может ожидать окончания нескольких работ. Тогда для отображения логики взаимодействия стрелок при слиянии и разветвлении или для отображения множества событий, которые должны произойти используются перекрестки. Все перекрестки на диаграмме нумеруются, каждый номер имеет префикс J. Стрелки могут сливаться и разветвляться только через перекрестки. Различают перекрестки для слияния (Fan- in Junction) и разветвления (Fan- out Junction) стрелок. Перекрестки бывают 5 типов.

Типы перекрестков:

  1. Асинхронное «И» (Asynchronous AND). Все предшествующие процессы должны быть завершены, или все следующие запущены.

  2. Синхронное «И» (Synchronous AND). Все предшествующие процессы должны быть завершены одновременно, или все следующие одновременно запущены.

  3. Асинхронное «ИЛИ» (Asynchronous OR). Один или несколько предшествующих процессов должны быть завершены, или последующих запущены.

  4. Синхронное «ИЛИ» (Synchronous OR) .Один или несколько предшествующих процессов должны быть завершены одновременно, или последующих одновременно запущены.

  5. Исключающее «ИЛИ» (XOR или Exclusive OR). Только один предшествующий процесс завершен или только один следующий запускается.

Диаграммы IDEF3 применяются для;
• улучшения понимания результатов моделирования бизнес-процессов;
• определения момента окончания моделирования;
•сбора информации о схеме работы моделируемой компании.
Построение IDEF-моделей иногда позволяет упростить функциональное моделирование системы по методологии IDEF0 и получило заслуженное признание как удобный способ анализа потенциальных усовершенствований системы. Диаграммы IDEF3 обеспечивают дискретность моделирования процесса, что может использоваться для контроля хода выполнения работ.
17. Моделирование потоков данных. Построение DFD-диаграмм. Особенности применения функциональных и объектно-ориентированных методологий моделирования предметной области

Диаграммы потоков данных (Data Flow Diagrams — DFD) предназначены для демонстрации того, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.

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

-внешние сущности;

-функциональные блоки;

-потоки данных;

-хранилища данных.

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

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

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

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

Основные принципы проектирования DFD:

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

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

-Контекстная диаграмма (уровень 0) определяет границы системы, выдвигая на первый план источники и получатели.

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

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

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

1. Проверка синтаксиса 2. Проверка элементов данных

3. Взаимные ссылки 4. Проверка целей

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

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

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

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

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

18. Принципы и составные части объектно-ориентированной методологии.

ООП основан на выделении классов, объектов, установление характерных свойств и методов их разработки и создании иерархий классов

Объектно-ориентированное программирование – это метод программирования, при использовании которого главными элементами программ являются объекты.

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

В основе объектно-ориентированного подхода лежат три понятия:

- Инкапсуляция: объединение данных с процедурами и функциями в рамках единого целого – объекта.

- Наследование: возможность построения иерархии объектов с использованием наследования их характеристик.

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

Наиболее распространенными системами объектно-ориентированного визуального программирования являются Microsoft Visual Basic и Borland Delphi.

Принципиальные моменты, в которых объектно-ориентированный подход к развитию проектов отличается от традиционных последовательных методологий:

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

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

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

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

Составные части объектно-ориентированной методологии

Объектно-ориентированный анализ (ООА) направлен на создание моделей, более близких к реальности, с использованием объектно-ориентированного подхода; это методология, при которой требования формируются на основе понятий классов и объектов, составляющих

словарь предметной области.

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

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

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

Концептуально объектно-ориентированная методология опирается на объектный подход, который включает основные принципы:

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

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

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

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

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

Без любого из этих элементов модель не будет объектно-ориентированной. Кроме главных, имеется три дополнительных элемента, которые полезны в объектной модели, но не обязательны:

Типизация - описание в тексте системы типов всех объектов, с которыми она работает на этапе выполнения;

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

Сохраняемость или устойчивость (persistence) - свойство объектов сохранять свое состояние и принадлежность к определенному классу.

19 . Методология объектного проектирования на языке UML: диаграмма вариантов использования и диаграмма классов.

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


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

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

В UML для вариантов использования и действующих лиц поддерживается несколько типов связей:

- связь коммуникаций (association relationship) – это связь между вариантами использования и действующим лицом

- включение (include relationship) – применяется в тех случаях, когда имеется какой-либо фрагмент поведения системы, которая повторяется более чем в одном варианте использования

- связь с расширением (extend relationship) – применяется при наличии изменений в нормальном поведении системы, которые также вносятся в отдельный вариант использования

- связь-обобщение (generalization relationship) служит для указания того факта, что некоторый вариант использования А может быть обобщен до варианта использования В.

Диаграммой классов в терминологии UML называется диаграмма, на которой показан набор классов, а также связей между этими классами. Графическое представление класса – это прямоугольник, который может быть разделен на три части:



В диаграмме классов могут участвовать связи разных категорий: зависимость (dependency), обобщение (generalization), ассоциация (association) и реализация (realization).

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

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

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




20. Диаграммы взаимодействия. Диаграмма состояний (переходов)

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

Диаграммой последовательностей (Sequence diagram) называется диаграмма взаимодействия, на которой изображаются участвующие во взаимодействии объекты и последовательность сообщений, которыми они обмениваются. Одно из основных назначений данной диаграммы – отобразить последовательность действий для части или целого варианта использования (use case). На диаграмме последовательности объект изображается в виде прямоугольника на вершине пунктирной вертикальной линии. Эта линия называется "линией жизни" (life line) объекта. Сообщения появляются в том порядке, как они показаны на стрелке - сверху вниз.


1   2   3   4   5


Сущность структурного подхода. Структурная модель предметной области. Процессный подход в описании предметной области
Учебный материал
© nashaucheba.ru
При копировании укажите ссылку.
обратиться к администрации