Главная страница
Навигация по странице:

  • 2. Классификация рынка ИС.

  • Таблица 1.2. Классификация рынка информационных систем Локальные системы

  • Крупные интегрированные системы (IC)

  • - Поэтапная модель с промежуточным контролем

  • Язык UML. История создания. Средства объектно-ориентированного проектирования.

  • Пользователям языка предоставлены возможности

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

  • Диаграммы вариантов использования. Актеры. Функции. Связи коммуникации, использования, расширения, обобщения. Пакеты.

  • 6.Документирование потока событий. Основной поток. Альтернативный поток. Исключения. Примеры.

  • Основной и альтернативный потоки событий

  • Основной поток

  • Альтернативный поток А1. Ввод неправильного идентификационного

  • Поток ошибок Е1. Ошибка в подтверждении запрашиваемой суммы.

  • 7. Диаграммы взаимодействия. Диаграммы последовательности. Объекты. Сообщения. Время жизни объекта. Рефлексивная связь. Примеры.

  • 8.Диаграммы взаимодействия. Диаграммы кооперации. Примеры.

  • 9.Диаграммы деятельностей. Потоки. Синхронизация, распараллеливание процессов. Примеры.

  • Д ействия

  • 1. Общая характеристика процесса проектирования ис. Структура ис. По типу хранимых данных



    Название1. Общая характеристика процесса проектирования ис. Структура ис. По типу хранимых данных
    АнкорOtvetyPIS.doc
    Дата25.04.2017
    Размер333 Kb.
    Формат файлаdoc
    Имя файлаOtvetyPIS.doc
    ТипДокументы
    #3173
    страница1 из 5
      1   2   3   4   5

    1. Общая характеристика процесса проектирования ИС. Структура ИС.

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

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

    В автоматических ИС все операции по переработке информации выполняются без участия человека.

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

    В зависимости от характера обработки данных ИС делятся на информационно-поисковые и информационно-решающие.

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

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

    В зависимости от сферы применения различают следующие классы ИС.

    Информационные системы организационного управления - предназначены для автоматизации функций управленческого персонала.

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

    ИС управления технологическими процессами (ТП) - служат для автоматизации функций производственного персонала по контролю и управлению производственными операциями.

    ИС автоматизированного проектирования (САПР) - предназначены для автоматизации функций инженеров-проектировщиков, конструкторов, архитекторов, дизайнеров при создании новой техники или технологии.

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

    2. Классификация рынка ИС.

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


    Таблица 1.2. Классификация рынка информационных систем

    Локальные системы

    Малые интегрированные системы

    Средние интегрированные системы

    Крупные интегрированные системы (IC)

    • БЭСТ

    • Инотек

    • Инфософт

    • Супер-Менеджер

    • Турбо-Бухгалтер

    • Инфо-Бухгалтер

    • Concorde XAL Exact

    • NS-2000 Platinum PRO/MIS

    • Scala SunSystems

    • БЭСТ-ПРО

    • 1C-Предприятие

    • БОСС-Корпорация

    • Галактика

    • Парус

    • Ресурс

    • Эталон

    • Microsoft-Business Solutions - Navision, Axapta

    • J D Edwards (Robertson & Blums)

    • MFG-Pro (QAD/BMS)

    • SyteLine (COKAП/SYMIX)

    • SAP/R3 (SAP AG)

    • Baan (Baan)

    • BPCS (ITS/SSA)

    • OEBS (Oracle E-Business Suite)

    Существует классификация ИС в зависимости от уровня управления, на котором система используется.

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

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

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

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

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

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

    3. Жизненный цикл программного обеспечения ИС

    Жизненный цикл ИС можно представить как ряд событий, происходящих с системой в процессе ее создания и использования.

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

    В настоящее время известны и используются следующие модели жизненного цикла [7,8]:

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

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

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

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

    - каскадная модель (характерна для периода 1970-1985 гг.);

    - спиральная модель (характерна для периода после 1986.г.).

    1. Язык UML. История создания. Средства объектно-ориентированного проектирования.

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

    UML представляет собой объектно-ориентированный язык моделирования, обладающий следующими основными характеристиками:

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

    - содержит механизмы расширения и специализации базовых концепций языка.

    UML - это стандартная нотация визуального моделирования программных систем, принятая консорциумом Object Managing Group (OMG) осенью 1997 г., и на сегодняшний день она поддерживается многими объектно-ориентированными CASE-продуктами.

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

    - строить модели на основе средств ядра, без использования механизмов расширения для большинства типовых приложений;

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

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

    Объектно-ориентированный подход к проектированию программных изделий предполагает:

    - проведение объектно-ориентированного анализа предметной области;

    - объектно-ориентированное проектирование;

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

    StarUML - это проект с открытым кодом для разработки быстрых, гибких, расширяемых, функциональных и, главное, бесплатно доступных для любого пользователя платформ UML/MDA для 32-разрядных систем Windows. Цель проекта StartUML - в создании универсальной бесплатной платформы для моделирования, которая послужит аналогом для таких коммерческих проектов.

    Open ModelSphere является большим инструментом моделирования для проектов матобеспечения любого размера. Вы можете Модели данных проектирования, Модели бизнес-процесса (BPM) и Модели UML

    В результате разработки проекта с помощью CASE-средства Rational Rose формируются следующие документы:

     диаграммы классов, состояний, сценариев, модулей, процессов;

     спецификации классов, объектов, атрибутов и операций;

     заготовки текстов программ;

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


    1. Диаграммы вариантов использования. Актеры. Функции. Связи коммуникации, использования, расширения, обобщения. Пакеты.

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

    • определить общие границы и контекст моделируемой предметной области;

    • сформулировать общие требования к функциональному поведению проектируемой системы;

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

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

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

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

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

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

    • ассоциации (association relationship);

    • расширения (extend relationship);

    • общения (generalization relationship);

    • включения (include relationship). Пакеты UML

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

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

    6.Документирование потока событий. Основной поток. Альтернативный поток. Исключения. Примеры.

    Каждый вариант использования должен иметь связанное с ним короткое описание того, что он будет делать. Например, вариант использования «Перевести деньги» системы АТМ может содержать следующее описание:

    Вариант Использования «Перевести деньги» позволяет клиенту или служащему банка переводить деньги с одного счета до востребования или сберегательного счета на другой.

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

    Основной и альтернативный потоки событий

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

    – способ запуска варианта использования;

    различные пути выполнения варианта использования;

    – нормальный, или основной, поток событий варианта использования;

    – отклонения от основного потока событий (так называемые

    альтернативные потоки);

    – потоки ошибок;

    – способ завершения варианта использования.

    Например, поток событий варианта использования «Снять деньги»

    может выглядеть следующим образом:

    Основной поток 1. Вариант использования начинается, когда клиент вставляет свою карточку в АТМ. 2. АТМ выводит приветствие и предлагает клиенту ввести свой персональный идентификационный номер. 3. Клиент вводит номер.

    4. АТМ подтверждает введ¨нный номер. Если номер не подтвержден, выполняется альтернативный поток событий А1.

    Альтернативный поток А1. Ввод неправильного идентификационного номера.

    Альтернативный вариант использования А2. Недостаточно денег на счету.

    Поток ошибок Е1. Ошибка в подтверждении запрашиваемой суммы.

    Постусловия

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

    Как и для предусловий, с помощью постусловий можно вводить информацию о порядке выполнения вариантов использования системы. Если, например, после одного из вариантов использования должен всегда выполняться другой, это можно описать как постусловие. Такие условия имеются не у каждого варианта использования.
    7. Диаграммы взаимодействия. Диаграммы последовательности. Объекты. Сообщения. Время жизни объекта. Рефлексивная связь. Примеры.

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

    объект, обозначается прямоугольником с записанным в нем именем объекта;

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

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



      

    8.Диаграммы взаимодействия. Диаграммы кооперации. Примеры.

    Диаграмма сотрудничества ( Collaboration diagram ) предназначена для описания методов взаимодействия между объектами. Для пояснения смысла и назначения диаграммы необходимо ввести такое понятие как сотрудничество.

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

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

        На диаграмме могут быть показаны связи между объектами представляющие:

    параметры процедур,

    локальные переменные,

    self ссылки (ссылки на сам объект).

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



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

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

        Диаграмма действий состоит из следующих элементов:

    Действия показывают выполнение некоторой неделимой операции. Каждое действие имеет имя, определяющее смысл этого действия.
      1   2   3   4   5
    написать администратору сайта