Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
ололо,трололо,я водитель ололо.doc
Скачиваний:
17
Добавлен:
24.04.2019
Размер:
184.83 Кб
Скачать

74. Понятие case-средств.

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

75. Направление применения case-средств.

В настоящее время развиты 2 направления применения CASE-средств:

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

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

76. Классификация case-средств на основе функциональной ориентации:

  1. анализ и проектирование системы

  2. проектирование систем баз данных и знаний

  3. системы программирования

  4. реинжиниринг и сопровождение проектов

  5. управление проектами

  6. поддержка окружения

77. Принципы выбора case-систем.

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

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

В основе данного стандарта лежит:

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

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

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

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

78. Понятие графической нотации.

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

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

Нотация моделирования бизнес процессов (Business Process Modeling Notation, BPMN) — графическая нотация длямоделирования бизнес процессов. BPMN была разработана Business Process Management Initiative (BPMI) и поддерживается Object Management Group, после слияния организаций в 2005 году. Текущая версия BPMN — 1.2; ведётся разработка версии 2.0.

IDEF0 — Function Modeling — методология функционального моделирования и графическая нотация, предназначенная для формализации и описания бизнес-процессов. Отличительной особенностью IDEF0 является её акцент на соподчинённость объектов. В IDEF0 рассматриваются логические отношения между работами, а не их временна́я последовательность (WorkFlow).

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

Модель Сущность-Связь (ER-модель) (англ. entity-relationship model (ERM) или англ. entity-relationship diagram (ERD)) — модель данных, позволяющая описывать концептуальные схемы. Представляет собой графическую нотацию, основанную на блоках и соединяющих их линиях, с помощью которых можно описывать объекты и отношения между ними какой-либо другой модели данных. В этом смысле ER-модель является мета-моделью данных, то есть средством описания моделей данных.

«ПОСТ-нотация» (ПОСТ = процесс-объект-связь-технология) без труда может быть понята как разработчиком, так и заказчиком или пользователем. Простота обусловлена тем, что в основе этого языка лежат всего два базовых элемента: объекты и действия, интуитивно понятные любому. Использование данной нотации позволяет сделать коммуникацию заказчика и разработчика более эффективной.  Указанные особенности нагляднее всего рассмотреть опять же на примере простейшей бизнес проблемы, описываемой при помощи этой нотации. Предлагаемая ПОСТ модель графической коммуникации называется еще IPO (input-process-output) или нотация Беляева-Капустяна. Эта нотация описывает бизнес-процесс как последовательность, состоящую из входных объектов, самого процесса и его выходных объектов. Такова довольно простая синтактика этой нотации. Объекты обозначаются прямоугольниками. Процессы – эллипсами. В середине пишется дополнительная информация о том, что собой представляет данный объект или процесс. Объекты и процессы соединены стрелками. Ясно, что выходные объекты одного процесса могут служить входными объектами другого процесса. Синтактика этой нотации имеет довольно естественные ограничения. Например, два эллипса (процесса) или два объекта не могут непосредственно соединяться друг с другом. Действительно, один процесс не может переходить в другой без промежуточных результатов. Два объекта неразличимы, если между ними нет процесса, хоть как-то меняющими их. 

79. Понятие стандарта с применением графической нотации.

Для того чтобы, во-первых, с достаточной степенью точности формализовать процесс разработки информационных систем, его нужно описать. Описание можно проводить в словесной форме, но чаще это делают в графической форме, представляя бизнес процесс в виде диаграмм и графов. Описание обычно проводят с привлечением Case-средств (Computer Aided Software Engineering), например, таких как ARIS, Casewise, Rational Rose. Для того чтобы сделать процесс разработки и интеграции программного обеспечения более прозрачным были разработаны стандарты, ставшие уже нарицательными, IDEF и UML. В 2000 году был введен стандарт BPML (Business Process Modelling Language), в разработке которого приняли практически все ведущие софтверные компании, но стандарт несколько сдал свои позиции после того, как в 2002 году проект покинули IBM, Microsoft и BEA, предложив свой стандарт BPEL (Business Process Execution Language). 

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

DFDдиаграмма потоков данных – отражает передачу информации, энергии, вещества от одной функции к другой в рамках заданных технологий.

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

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

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