госы / итог
.doc
|
Экзаменационный билет № 1 |
Утверждаю Проректор по учебной работе
_____________ С.В. Михайлов
" " мая 2014 г. |
Кафедра бизнес-информатики
|
||
Итоговый междисциплинарный экзамен по специальности «Прикладная информатика в экономике». Специализации «Информационные системы в банковском деле» |
||
Операционная система – комплекс взаимосвязанных программ, который действует как интерфейс между приложениями и пользователями с одной стороны, и аппаратурой компьютера с другой стороны. Отсюда две группы функций ОС, определяющих ее двухстороннее назначение:
Первая группа функций операционной системы направлена на взаимодействие с пользователем ОС. При этом следует различать интерфейс прикладного программиста, создающий операционную среду, и пользовательский, человеко-машинный интерфейс. Вторая группа функций ОС направлена на взаимодействие с аппаратурой компьютера. Рациональное управления ресурсами компьютера повышает эффективность его использования.
Интерфейсная стрелка, интерфейсная дуга или поток (Arrow). Интерфейсная стрелка отображает элемент системы, который обрабатывается функциональным блоком или оказывает влияние на функцию, отображенную данным функциональным блоком. С дугами связаны надписи (или метки) на естественном языке, описывающие данные, которые они представляют. ОПР.: Взаимодействие между функциями (блоками) в IDEF0 представляется в виде дуги, которая отображает поток данных или материалов, поступающий с выхода одной функции на вход другой. Выходы одной функции могут быть Входами, Управлением или Механизмами для другой. В зависимости от того, с какой стороной блока связан поток, его называют соответственно “входным”, “выходным”, “управляющим”.
Одним из главных отличий стандарта IDEF0 от других методологий классов DFD (Data Flow Diagram) и WFD (Work Flow Diagram) является обязательное наличие управляющих интерфейсных стрелок. Дуги позволяют отражать взаимосвязи между блоками. По типу этой связи выделяют 5 видов взаимодействия (Error: Reference source not found). Примеры данных взаимодействий и их отражения на модели показаны на схемах Модель в IDEF0 Модель в IDEF0 представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм. Каждая диаграмма располагается на отдельном листе (Error: Reference source not found). Модель IDEF0 всегда начинается с представления системы как единого целого – одного функционального блока с интерфейсными стрелками, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой, и обозначается идентификатором А-0. Ни одна модель не может быть создана без конкретного объекта или цели. Формулировка цели должна ответить на следующие вопросы: почему был смоделирован данный процесс; что модель собирается показать; что с ней могут сделать читающие. Формулировка цели позволяет команде экспертов придерживаться ее в течение всего моделирования. Без формулировки цели моделирование может зайти в тупик. Модели создаются для получения ответа на ряд вопросов. Данные вопросы должны подготавливаться заранее и будут служить основой для создания цели модели. Примерные вопросы могут звучать следующим образом: каковы основные задачи сотрудника; кто отвечает за произведенную продукцию; кто управляет начальной стадией производства; какой требуется инструмент для каждого этапа. Точка зрения (Viewpoint). Особенно важно включать в процесс разработки модели представителей различных мнений, однако сама модель должна базироваться на единой точке зрения. Чаще всего разнообразные точки зрения кратко фиксируют на диаграмме ФЕО (FEO – For Exposition Only – только для комментариев). Эти диаграммы используются только в качестве материалов для презентаций. Точка зрения должна формулироваться исходя из цели построение диаграммы. При построении модели важно придерживаться одной точки зрения, которая должна содержать наименование должности, структурного подразделения или описание должностных обязанностей работника. Модели могут содержать разнообразные точки зрения с целью детальной фиксации всех действий (функций). В комментариях к контекстной диаграмме должна быть указана цель (Purpose) построения диаграммы в виде краткого описания и зафиксирована точка зрения (Viewpoint). Определение и формализация цели разработки и точки зрения IDEF0 – модели является крайне важным моментом. Фактически цель определяет соответствующие области в исследуемой системе, на которых необходимо обратить внимание в первую очередь. Точка зрения определяет основное направление развития модели и уровень необходимой детализации. Четкое фиксирование точки зрения позволяет разгрузить модель, отказавшись от детализации и исследования отдельных элементов, не являющихся необходимыми, исходя из выбранной точки зрения на систему. Диаграммы IDEF0 второго уровня называются дочерней (Child diagram) по отношению к первому (каждый из функциональных блоков, принадлежащих дочерней диаграмме соответственно называется дочерним блоком – Child Box). В свою очередь, функциональный блок – предок называется родительским блоком по отношению к дочерней диаграмме (Parent Box), а диаграмма, к которой он принадлежит – родительской диаграммой (Parent Diagram). При декомпозиции функционального блока все стрелки, входящие в данный блок, или исходящие из него фиксируются на дочерней диаграмме. Этим достигается структурная целостность IDEF0-модели. Каждый блок имеет свой уникальный порядковый номер на диаграмме (цифра в правом нижнем углу), а обозначение под правым углом указывает на номер дочерней для этого блока диаграммы. Отсутствие этого обозначения говорит о том, что декомпозиции для данного блока не существует. Туннели (Tunnels). Связывание интерфейсных стрелок используется в моделях для определения уровня детализации. Когда интерфейсная стрелка не возникает на базовой диаграмме, но не связана с другими стрелками, туннель используется для указания того, что интерфейсная стрелка входит или выходит из системы. Туннель используется, чтобы не загромождать базовую диаграмму. В других случаях туннель может быть использован в интерфейсной стрелке, ведущей к базовому действию. Это указывает, что взаимоотношения интерфейсной стрелки с дочерними действиями не определены. Глоссарий (Glossary). Для каждого из элементов IDEF0 (диаграмм, функциональных блоков, интерфейсных стрелок) существующий стандарт подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных изложений и т.д., которые характеризуют объект, отображенный данным элементом. Этот набор называется глоссарием и является описанием сущности данного элемента. Он дополняет наглядный графический язык, снабжая диаграммы необходимой дополнительной информацией.
Принципы IDEF0 Принцип функциональной декомпозиции. Принцип декомпозиции или, как его еще называют принцип «разделяй и властвуй» применяется при разбиении сложного процесса на составляющие его функции. Декомпозиция позволяет представить модель системы в виде иерархической структуры отдельных диаграмм, что делает ее менее перегруженной и легко усваиваемой. Суть принципа функциональной декомпозиции очень прост (Error: Reference source not found):
Принцип ограничения сложности При работе с IDEF0 диаграммами существенным является условие их разборчивости и удобочитаемости, поэтому количество блоков на диаграмме должно быть не менее двух и не более шести. Такой диапазон вызван учетом особенностей психологии человеческого восприятия. Практика показывает, что соблюдение этого принципа приводит к тому, что функциональные процессы, представленные в виде IDEF0 модели, хорошо структурированы, понятны и легко поддаются анализу. Принцип контекста (целеполагания) Как было указано выше любая модель должна отвечать на вопросы о системе («М есть модель системы S, если М может быть использована для получения ответов на вопросы относительно S с точностью А»). Это означает, что не может быть модели вообще. Любая модель – это лишь инструмент и чтобы правильно ее создать надо иметь однозначное представление о цели моделирования (Purpose), точке зрения (Viewpoint) и границах моделирования (Scope). Принцип целеполагания как раз и означает, что любая модель в SADT – должна быть определена прежде всего по перечисленным трем позициям. Правила построения IDEF0 диаграмм Выполнение вышеперечисленных принципов требует введения ряда ограничений, которые должен выполнять любой автор IDEF0 модели. Как было указано ранее, эти требования сведены в документе РД IDEF0-2000. Основные из этих правил приведем ниже с необходимыми комментариями. Правило контекста В составе модели должна присутствовать контекстная диаграмма number prefix-0 (например, А-0), которая содержит только один блок. Номер единственного блока на контекстной диаграмме А-0 должен быть 0 (Error: Reference source not found). Это правило обеспечивает выполнение принципа контекста. Правило «доминирования» Блоки на диаграмме должны располагаться по диагонали - от левого верхнего угла диаграммы до правого нижнего в порядке присвоенных номеров (Error: Reference source not found). Блоки на диаграмме, расположенные вверху слева «доминируют» над блоками, расположенными внизу справа. «Доминирование» понимается как влияние, которое блок оказывает на другие блоки диаграммы. Правило ограничения сложности Это правило дополняет одноименный принцип. Неконтекстные диаграммы должны содержать не более шести блоков. Это ограничение поддерживают сложность диаграмм на уровне, доступном для чтения, понимания и использования. Диаграммы с количеством блоков более шести сложны для восприятия читателями и вызывают у автора трудности при внесении в нее всех необходимых графических объектов и меток. Однако, несмотря на существование этого правила в реальной практике моделирования из него иногда допускаются исключения. Более подробно об этих исключениях будет рассказано ниже. Правило выбора управления Часто возникает проблема, когда автор модели не может однозначно определить, к какому из типов дуг отнести ту или иную интерфейсную стрелку. Прежде всего такая ситуация возникает, когда речь идет об отображении на диаграмме информационных потоков. Для преодоления этой проблемы и существует правило выбора управления. В соответствии с этим правилом если одни и те же данные служат и для управления, и для входа, вычерчивается только стрелка управления. Этим подчеркивается управляющий характер данных и уменьшается сложность диаграммы (Error: Reference source not found). Правила нумерации и именования диаграмм, блоков и дуг Правило нумерации блоков Каждый блок диаграммы декомпозиции получает номер, помещаемый в правом нижнем углу (Error: Reference source not found); порядок нумерации - от верхнего левого к нижнему правому блоку (в соответствии с доминированием блоков). Правило нумерации диаграмм Каждая диаграмма имеет свой уникальный код, который формируется следующим образом (Error: Reference source not found): Правило именования Имена блоков (выполняемых функций) и метки дуг должны быть уникальными (Error: Reference source not found). Если метки интерфейсных стрелок совпадают, это значит, что стрелки отображают тождественные данные. Правила компоновки объектов диаграмм Правило компоновки блоков Следует обеспечить максимальное расстояние между блоками и поворотами стрелок, а также между блоками и пересечениями стрелок для облегчения чтения диаграммы. Одновременно уменьшается вероятность перепутать две разные стрелки. Правило рисования стрелок Надо пытаться максимально увеличивать расстояние между параллельными стрелками (Error: Reference source not found), что облегчает размещение меток, их чтение и позволяет проследить пути стрелок. Правило минимизации пересечений При соединении большого числа блоков необходимо избегать необязательных пересечений стрелок. Следует минимизировать число петель и поворотов каждой стрелки (Error: Reference source not found Правило связывания дуг Дуги связываются (сливаются), если они представляют сходные данные и их источник не указан на диаграмме. Дуги объединяются, если они имеют общий источник или приемник, или они представляют связанные данные. Общее название лучше описывает суть данных. Следует минимизировать число дуг, касающихся каждой стороны блока, если, конечно, природа данных не слишком разнородна (Error: Reference source not found). Правило присоединения дуг к блокам Если возможно, дуги присоединяются к блокам в одной и той же позиции. Тогда соединение дуг конкретного типа с блоками будет согласованным и чтение диаграммы упростится (Error: Reference source not found). Процесс моделирования В одной из лучших книг по SADT-моделированию дается следующая характеристика этой методологии: «В значительной мере успех методологии SADT объясняется ее графическим языком, хотя не менее ценным является сам процесс моделирования. Процесс моделирования в SADT включает сбор информации об исследуемой области, документирование полученной информации и представление ее в виде модели и уточнение модели посредством итеративного рецензирования. Кроме того, этот процесс подсказывает вполне определенный путь выполнения согласованной и достоверной структурной декомпозиции, что является ключевым моментом в квалифицированном анализе системы. SADT уникальна в своей способности обеспечить как графический язык, так и процесс создания непротиворечивой и полезной системы описаний». Если процесс моделирования описанный в РД IDEF0-2000 представить в нотации IDEF0, то получится следующее видение (Error: Reference source not found Именно то, что SADT представляет собой не просто нотацию, но, прежде всего системный подход к анализу и синтезу сложных систем делает SADT полноценной методологией, которая нашла широкое распространение не только в сфере создания ИС, но и в областях связанных с оптимизацией организационно-экономических и производственно-технических систем.
3. Подключиться к серверу MS SQL2005 в локальной сети МБИ, подготовить и выполнить следующие запросы к базе данных SessiaGOS • Вывести список дисциплин, вынесенных на сессию по специальности «Прикладная информатика в экономике» • Вывести список лучших студентов, которые сдали все, что требуется на «отлично» и с первого раза • Вывести список дисциплин, по которым получены лучшие результаты сдачи сессии, т.е. получено больше всего пятерок. • Вывести список тех студентов, у кого более 2-х несданных экзаменов по сессии. • Вывести список специальностей, по которым учится больше всего студентов. |
|
Экзаменационный билет № 2 |
Утверждаю Проректор по учебной работе
_____________ С.В. Михайлов
" " мая 2014 г. |
Кафедра бизнес-информатики
|
||
Итоговый междисциплинарный экзамен по специальности «Прикладная информатика в экономике». Специализации «Информационные системы в банковском деле» |
||
В истории развития СУБД и БД можно выделить 4 основных этапа.
Первый этап развития СУБД связан с организацией баз данных на больших машинах типа IBM 360/370, ЕС-ЭВМ и мини-ЭВМ типа PDP11 (фирмы Digital Equipment Corporation — DEC), разных моделях HP (фирмы Hewlett Packard).
Короче, есть большая пребольшая центральная ЭВМ, у которой подключена внешняя память. В самой ЭВМ на тот момент была только оперативка, где данные храниться не могут. К ней подключалось некое количество терминалов. Они выч ресурсов не имели, с помощью них можно было только вводить и выводить инфу, т.е. процессоров и внешней памяти как у центральной ЭВМ у них не было. Особенности этого этапа развития выражаются в следующем:
Потом появились персональные компьютеры. Все стали ими пользоваться. Появилась туча самописных СУБД, настольных СУБД, все разного формата. Разрабатывались все новые и новые СУБД , и главная проблема заключалась в переносе данных с одной на другую. Одна база – один комп. Инета нет. Серваков с базами нет.
Концептуальная схемка(СУБД на компе):
Особенности этого этапа состоят в следующем:
В принципе, их даже трудно назвать полноценными СУБД. Яркие представители этого семейства — очень широко использовавшиеся до недавнего времени СУБД Dbase (DbaseIII+, DbaseIV), FoxPro, Clipper, Paradox (рис. 1.2).
Потом появились локальные сети, в которых инфа обрабатывалась между несколькими пользователями. Встала задача согласованности данных, хранящихся и обрабатывающихся в разных местах, но логически друг с другом связанных. Как следствие – появились распределенные базы данных.
Особенности данного этапа состоят в следующем.
Следующий этап характеризуется появлением новой технологии доступа к данным — Интранет. Основное отличие этого подхода от технологии «клиент-сервер» состоит в том, что отпадает необходимость использования специализированного клиентского программного обеспечения. Нужна только программа-обозреватель(браузер), которая шлет запросы и получает ответы от сервера. Архитектура «клиент-сервер».
Трехуровневая архитектура
Эта архитектура позволяет обеспечить логическую (между уровнями 1 и 2) и физическую (между уровнями 2 и 3) независимость при работе с данными. Логическая независимость предполагает возможность изменения одного приложения без корректировки других приложений, работающих с этой же базой данных. Физическая независимость предполагает возможность переноса хранимой информации с одних носителей на другие при сохранении работоспособности всех приложений, работающих с данной базой данных. Это именно то, чего не хватало при использовании файловых систем.
Интерфейсная стрелка, интерфейсная дуга или поток (Arrow). Интерфейсная стрелка отображает элемент системы, который обрабатывается функциональным блоком или оказывает влияние на функцию, отображенную данным функциональным блоком. С дугами связаны надписи (или метки) на естественном языке, описывающие данные, которые они представляют. ОПР.: Взаимодействие между функциями (блоками) в IDEF0 представляется в виде дуги, которая отображает поток данных или материалов, поступающий с выхода одной функции на вход другой. Выходы одной функции могут быть Входами, Управлением или Механизмами для другой. В зависимости от того, с какой стороной блока связан поток, его называют соответственно “входным”, “выходным”, “управляющим”.
Одним из главных отличий стандарта IDEF0 от других методологий классов DFD (Data Flow Diagram) и WFD (Work Flow Diagram) является обязательное наличие управляющих интерфейсных стрелок. Дуги позволяют отражать взаимосвязи между блоками. По типу этой связи выделяют 5 видов взаимодействия (Error: Reference source not found). Примеры данных взаимодействий и их отражения на модели показаны на схемах Модель в IDEF0 Модель в IDEF0 представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм. Каждая диаграмма располагается на отдельном листе (Error: Reference source not found). Модель IDEF0 всегда начинается с представления системы как единого целого – одного функционального блока с интерфейсными стрелками, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой, и обозначается идентификатором А-0. Ни одна модель не может быть создана без конкретного объекта или цели. Формулировка цели должна ответить на следующие вопросы: почему был смоделирован данный процесс; что модель собирается показать; что с ней могут сделать читающие. Формулировка цели позволяет команде экспертов придерживаться ее в течение всего моделирования. Без формулировки цели моделирование может зайти в тупик. Модели создаются для получения ответа на ряд вопросов. Данные вопросы должны подготавливаться заранее и будут служить основой для создания цели модели. Примерные вопросы могут звучать следующим образом: каковы основные задачи сотрудника; кто отвечает за произведенную продукцию; кто управляет начальной стадией производства; какой требуется инструмент для каждого этапа. Точка зрения (Viewpoint). Особенно важно включать в процесс разработки модели представителей различных мнений, однако сама модель должна базироваться на единой точке зрения. Чаще всего разнообразные точки зрения кратко фиксируют на диаграмме ФЕО (FEO – For Exposition Only – только для комментариев). Эти диаграммы используются только в качестве материалов для презентаций. Точка зрения должна формулироваться исходя из цели построение диаграммы. При построении модели важно придерживаться одной точки зрения, которая должна содержать наименование должности, структурного подразделения или описание должностных обязанностей работника. Модели могут содержать разнообразные точки зрения с целью детальной фиксации всех действий (функций). В комментариях к контекстной диаграмме должна быть указана цель (Purpose) построения диаграммы в виде краткого описания и зафиксирована точка зрения (Viewpoint). Определение и формализация цели разработки и точки зрения IDEF0 – модели является крайне важным моментом. Фактически цель определяет соответствующие области в исследуемой системе, на которых необходимо обратить внимание в первую очередь. Точка зрения определяет основное направление развития модели и уровень необходимой детализации. Четкое фиксирование точки зрения позволяет разгрузить модель, отказавшись от детализации и исследования отдельных элементов, не являющихся необходимыми, исходя из выбранной точки зрения на систему. Диаграммы IDEF0 второго уровня называются дочерней (Child diagram) по отношению к первому (каждый из функциональных блоков, принадлежащих дочерней диаграмме соответственно называется дочерним блоком – Child Box). В свою очередь, функциональный блок – предок называется родительским блоком по отношению к дочерней диаграмме (Parent Box), а диаграмма, к которой он принадлежит – родительской диаграммой (Parent Diagram). При декомпозиции функционального блока все стрелки, входящие в данный блок, или исходящие из него фиксируются на дочерней диаграмме. Этим достигается структурная целостность IDEF0-модели. Каждый блок имеет свой уникальный порядковый номер на диаграмме (цифра в правом нижнем углу), а обозначение под правым углом указывает на номер дочерней для этого блока диаграммы. Отсутствие этого обозначения говорит о том, что декомпозиции для данного блока не существует. Туннели (Tunnels). Связывание интерфейсных стрелок используется в моделях для определения уровня детализации. Когда интерфейсная стрелка не возникает на базовой диаграмме, но не связана с другими стрелками, туннель используется для указания того, что интерфейсная стрелка входит или выходит из системы. Туннель используется, чтобы не загромождать базовую диаграмму. В других случаях туннель может быть использован в интерфейсной стрелке, ведущей к базовому действию. Это указывает, что взаимоотношения интерфейсной стрелки с дочерними действиями не определены. Глоссарий (Glossary). Для каждого из элементов IDEF0 (диаграмм, функциональных блоков, интерфейсных стрелок) существующий стандарт подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных изложений и т.д., которые характеризуют объект, отображенный данным элементом. Этот набор называется глоссарием и является описанием сущности данного элемента. Он дополняет наглядный графический язык, снабжая диаграммы необходимой дополнительной информацией.
Принципы IDEF0 Принцип функциональной декомпозиции. Принцип декомпозиции или, как его еще называют принцип «разделяй и властвуй» применяется при разбиении сложного процесса на составляющие его функции. Декомпозиция позволяет представить модель системы в виде иерархической структуры отдельных диаграмм, что делает ее менее перегруженной и легко усваиваемой. Суть принципа функциональной декомпозиции очень прост (Error: Reference source not found):
Принцип ограничения сложности При работе с IDEF0 диаграммами существенным является условие их разборчивости и удобочитаемости, поэтому количество блоков на диаграмме должно быть не менее двух и не более шести. Такой диапазон вызван учетом особенностей психологии человеческого восприятия. Практика показывает, что соблюдение этого принципа приводит к тому, что функциональные процессы, представленные в виде IDEF0 модели, хорошо структурированы, понятны и легко поддаются анализу. Принцип контекста (целеполагания) Как было указано выше любая модель должна отвечать на вопросы о системе («М есть модель системы S, если М может быть использована для получения ответов на вопросы относительно S с точностью А»). Это означает, что не может быть модели вообще. Любая модель – это лишь инструмент и чтобы правильно ее создать надо иметь однозначное представление о цели моделирования (Purpose), точке зрения (Viewpoint) и границах моделирования (Scope). Принцип целеполагания как раз и означает, что любая модель в SADT – должна быть определена прежде всего по перечисленным трем позициям. Правила построения IDEF0 диаграмм Выполнение вышеперечисленных принципов требует введения ряда ограничений, которые должен выполнять любой автор IDEF0 модели. Как было указано ранее, эти требования сведены в документе РД IDEF0-2000. Основные из этих правил приведем ниже с необходимыми комментариями. Правило контекста В составе модели должна присутствовать контекстная диаграмма number prefix-0 (например, А-0), которая содержит только один блок. Номер единственного блока на контекстной диаграмме А-0 должен быть 0 (Error: Reference source not found). Это правило обеспечивает выполнение принципа контекста. Правило «доминирования» Блоки на диаграмме должны располагаться по диагонали - от левого верхнего угла диаграммы до правого нижнего в порядке присвоенных номеров (Error: Reference source not found). Блоки на диаграмме, расположенные вверху слева «доминируют» над блоками, расположенными внизу справа. «Доминирование» понимается как влияние, которое блок оказывает на другие блоки диаграммы. Правило ограничения сложности Это правило дополняет одноименный принцип. Неконтекстные диаграммы должны содержать не более шести блоков. Это ограничение поддерживают сложность диаграмм на уровне, доступном для чтения, понимания и использования. Диаграммы с количеством блоков более шести сложны для восприятия читателями и вызывают у автора трудности при внесении в нее всех необходимых графических объектов и меток. Однако, несмотря на существование этого правила в реальной практике моделирования из него иногда допускаются исключения. Более подробно об этих исключениях будет рассказано ниже. Правило выбора управления Часто возникает проблема, когда автор модели не может однозначно определить, к какому из типов дуг отнести ту или иную интерфейсную стрелку. Прежде всего такая ситуация возникает, когда речь идет об отображении на диаграмме информационных потоков. Для преодоления этой проблемы и существует правило выбора управления. В соответствии с этим правилом если одни и те же данные служат и для управления, и для входа, вычерчивается только стрелка управления. Этим подчеркивается управляющий характер данных и уменьшается сложность диаграммы (Error: Reference source not found). Правила нумерации и именования диаграмм, блоков и дуг Правило нумерации блоков Каждый блок диаграммы декомпозиции получает номер, помещаемый в правом нижнем углу (Error: Reference source not found); порядок нумерации - от верхнего левого к нижнему правому блоку (в соответствии с доминированием блоков). Правило нумерации диаграмм Каждая диаграмма имеет свой уникальный код, который формируется следующим образом (Error: Reference source not found): Правило именования Имена блоков (выполняемых функций) и метки дуг должны быть уникальными (Error: Reference source not found). Если метки интерфейсных стрелок совпадают, это значит, что стрелки отображают тождественные данные. Правила компоновки объектов диаграмм Правило компоновки блоков Следует обеспечить максимальное расстояние между блоками и поворотами стрелок, а также между блоками и пересечениями стрелок для облегчения чтения диаграммы. Одновременно уменьшается вероятность перепутать две разные стрелки. Правило рисования стрелок Надо пытаться максимально увеличивать расстояние между параллельными стрелками (Error: Reference source not found), что облегчает размещение меток, их чтение и позволяет проследить пути стрелок. Правило минимизации пересечений При соединении большого числа блоков необходимо избегать необязательных пересечений стрелок. Следует минимизировать число петель и поворотов каждой стрелки (Error: Reference source not found Правило связывания дуг Дуги связываются (сливаются), если они представляют сходные данные и их источник не указан на диаграмме. Дуги объединяются, если они имеют общий источник или приемник, или они представляют связанные данные. Общее название лучше описывает суть данных. Следует минимизировать число дуг, касающихся каждой стороны блока, если, конечно, природа данных не слишком разнородна (Error: Reference source not found). Правило присоединения дуг к блокам Если возможно, дуги присоединяются к блокам в одной и той же позиции. Тогда соединение дуг конкретного типа с блоками будет согласованным и чтение диаграммы упростится (Error: Reference source not found). Процесс моделирования В одной из лучших книг по SADT-моделированию дается следующая характеристика этой методологии: «В значительной мере успех методологии SADT объясняется ее графическим языком, хотя не менее ценным является сам процесс моделирования. Процесс моделирования в SADT включает сбор информации об исследуемой области, документирование полученной информации и представление ее в виде модели и уточнение модели посредством итеративного рецензирования. Кроме того, этот процесс подсказывает вполне определенный путь выполнения согласованной и достоверной структурной декомпозиции, что является ключевым моментом в квалифицированном анализе системы. SADT уникальна в своей способности обеспечить как графический язык, так и процесс создания непротиворечивой и полезной системы описаний». Если процесс моделирования описанный в РД IDEF0-2000 представить в нотации IDEF0, то получится следующее видение (Error: Reference source not found Именно то, что SADT представляет собой не просто нотацию, но, прежде всего системный подход к анализу и синтезу сложных систем делает SADT полноценной методологией, которая нашла широкое распространение не только в сфере создания ИС, но и в областях связанных с оптимизацией организационно-экономических и производственно-технических систем.
3. Выполнить ручную настройку сетевого интерфейса рабочей станции по заданным исходным данным и включить ее в указанный домен. Зайти в свойства сетевого окружения и посмотреть какой там ip и т.д. Затем в рабочей станции в dns прописать ip сервера. На рабочей станции включить компьютер в домен. В свойства компьютера это делается. Зайти в свойства компьютера на вкладку имя компьютера. И написать ivanov.local когда спросит пользователя и ввести администратор 123456. Зайти в актив директории в пользователи и компьютеры и проверить что среди компьютеров появился компьютер. И на рабочей станции попробовать зайти каким либо пользователем домена. Например, указываем администратор 123456. И внизу выбираем не этот компьютер а домен. И проверить что в DNS есть компьютер (на сервере администрирование- dns)
|