35. Принципы структурного подхода к проектированию ис.

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

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

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

принцип формализации - заключается в необходимости строгого методического подхода к решению проблемы;

принцип непротиворечивости - заключается в обоснованности и согласованности элементов;

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

36. Отличия объектно-ориентированного и структурного подходов к проектированию ис.

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

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

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

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

Третье отличие двух подходов заключается в структурной организации внутри модулей системы. В структурном подходе модуль состоит из функций, иерархически связанных между собой отношением композиции (англ. part-of – часть-целое), т. е. функция состоит из подфункций, подфункция из подподфункций и т.д. В объектно-ориентированном подходе иерархия выстраивается с использованием двух отношений: композиции и наследования (англ. is-a – это есть). При этом в объектно-ориентированном подходе «объект-часть» может включаться сразу в несколько «объектов-целое». Таким образом, модуль в структурном подходе представляется в виде дерева, а в объектно-ориентированном подходе – в виде ориентированного графа, т. е. с помощью более общей структуры.

37. Диаграммы, используемые в объектно-ориентированном проектировании ИС. Какие из диаграмм используются для статического описания системы, а какие — для динамического описания системы? Объекты диаграмм и их элементы.

Основные типы UML-диаграмм, используемые в проектировании информационных систем

Графические изображения моделей системы в UML называются диаграммами. В терминах

языка UML определены следующие их  виды

• диаграмма классов(class diagram

• диаграмма вариантов использования или прецедентов(use case diagram

• диаграмма последовательности(sequence diagram

• диаграммы поведения(behavior diagrams

• диаграмма состояний(statechart diagram

• диаграмма деятельности(activity diagram

• диаграмма взаимодействия(interaction diagram

• диаграмма кооперации(collaboration diagram

• диаграммы реализации(implementation diagrams

• диаграмма компонентов(component diagram

• диаграмма развертывания(deployment diagram

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

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

Диаграмма

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

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

точка зрения спецификации — диаграмма классов применяется при проектировании информационных систем;

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

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

Диаграмма вариантов использования

Диаграмма вариантов использования (Use case diagram) — диаграмма, на которой отражены отношения, существующие между 4 вариантами использования .

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

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

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

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

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

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

Диаграммы взаимодействия

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

Диаграмма деятельности

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

38. Схемы организации работ при проектировании ИС.

1. Классическое проектирование

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

Этапы проектирования ЦОД, как части ИС:

"ЗАПУСК". Организация, разработка, проектирование ЦОД, издание приказа и/или заключение договора о разработке ИС, задания на выполнение работ;

"ОБСЛЕДОВАНИЕ". Предпроектное обследование, общий анализ ситуации на предприятии, разработка общего обоснования целесообразности создания ЦОД;

"КОНЦЕПЦИЯ", разработка Технического задания (ТЗ) на базе исследований бизнес-требований, рекомендаций для технического проектирования ЦОД, ТЗ на проектирование ЦОД в целом и частного ТЗ для подсистем;

"ЭСКИЗНЫЙ ПРОЕКТ". Разработка архитектуры будущей ИС;

"ОПЫТНЫЙ ВАРИАНТ ИС". Разработка пилотного проекта ИС для опытной эксплуатации;

"ОПЫТНАЯ ЭКСПЛУАТАЦИЯ ИС". разработка исправлений и дополнений к ТЗ;

"ТЕХНИЧЕСКИЙ ПРОЕКТ";

"РАБОЧАЯ ДОКУМЕНТАЦИЯ". Разработка рабочей документации проекта;

"ВНЕДРЕНИЕ " ИС на базе ЦОД.

Одно из использовавшихся в западной литературе названий классического проектирования: "водопадная модель" (waterfall mdel). Водопадная модель обязана включать итерационные процедуры уточнения требований к ИС и этапы рассмотрения вариантов проектных решений. Все эти процедуры и этапы носили, в основном, последовательный характер. Предметом проекта является проектируемая ИС, в системном ее представлении.