Эволюция программных систем 2 страница

материалы, сырь? и полуфабрикаты, и информационные объекты (заказы, накладные и счета).

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

Строится обобщенное представление структуры ПО.

Внутренний уровень: отображается вид БД, входных и выходных документов. Например,

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

классификаторов, ценников. А динамические объекты – документами.

Функционально – ориентированная методика

ПО представляется в виде совокупности функций, каждая из которых, преобразует входные

данные в выходные.

__

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

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

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

Бизнес – процессы и информационные процессы, обычно, неразрывны, т.е. какой – то

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

отгрузка готовой продукции осуществляется на основе документа «Заказ», при этом порождается

документ «Накладная», который сопровождает партию, отгруженную товаром.

Функция может быть одним действием или совокупностью действий.

На внешнем уровне определяется список основных бизнес – функций или видов бизнес –

процессов. (15-20 шт.)

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

взаимосвязанных функций.

На внутреннем уровне отображается структура информационного процесса в компьютере,

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

Итог разработки архитектуры:

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

12. Модели управления. Централизованное управление: модель вызова/возврата, модель диспетчера. Модели, управляемые событиями Их достоинства и недостатки.

Модели управления

Можно выделить два основных типа управления:

1) Централизованное

2) Управление событиями

Каким бы образом не была бы описана структура системы (структурно – функциональным или

объектно-ориентированным), она состоит из набора структурных единиц. Чтобы они

функционировали, как единое целое ими надо управлять, а информация по управлению

отсутствует в статистических диаграммах (диаграммах статики).

В моделях управления на уровне архитектуры проектируется поток управления между

системами.

Централизованное управление:

Одна из подсистем полностью отвечает за управление, запускает и завершает работу отдельных

подсистем. Управление от первой подсистемы может перейти к другой, однако, потом

обязательно возвращается к первой. Две разновидности ЦУ:

1)Модель вызова возврата – широко известная иерархическая модель управления. Управление

начинается на вершине иерархии процедур и через вызовы передается на более нижние уровни

иерархии. Применима только в последовательных системах.

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

Управление событиями

В отличие от одной системы, ответственной как за управление, так и на реакцию на внешние события, существует модель, применяемая практически во всех приложениях, например, под Windows. Там любое внешнее событие, например, нажатие клавиши, нажатие кнопки мыши и т.д., считается событием. Каждому событию соответствует определенный код, которому могут сопутствовать параметры. Программе посылается сообщение о данном событие. Разработчик программ при их написании предусматривает, на какие события и как именно будет реагировать программа. Существует, так называемая, очередь сообщений. В не? включаются макросы тех событий, для которых предусмотрена реакция в данной программе. Если совершается событие из числа макросов, включенных в очередь, отрабатывает программа – обработчик данного события. Если реакция на событие не предусмотрена, то либо реакция отсутствует вообще, либо на не? реагирует операционная система, используя, библиотечные обработчики событий.

13. Модели модульной декомпозиции: объектные модели и модели потоков данных.

Модульная декомпозиция

Это третья составляющая архитектуры проекта. Она строится в соответствии с выбранной методологией:

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

определяют потоки данных от одного модуля к другому.

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

• DFD (Data Flow Diagrams) диаграммы потоков данных. Диаграммы DFD обычно строятся для наглядного изображения текущей работы системы документооборота организации. Как правило, диаграммы DFD используют в качестве дополнения модели бизнес-процессов, выполненной в IDEF0.

14. Диаграммы IDEF0 и DFD– их назначение и особенности.

Функциональная методика IDEF базируется на 4 основных понятиях: 1)функциональный блок; 2)интерфейсная дуга; 3)декомпозиция; 4)глоссарий;

Функциональный блок (Activity Box) представляет собой некоторую конкретную функцию в рамках рассматриваемой системы.

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

верхняя сторона имеет значение «Управление» (Control); левая сторона имеет значение «Вход» (Input); правая сторона имеет значение «Выход» (Output); нижняя сторона имеет значение «Механизм» (Mechanism).

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

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

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

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

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

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

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

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

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

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

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

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

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

В любом случае декомпозиции все интерфейсные дуги, входящие в родительский блок, фиксируются на дочерней диаграмме. Этим достигается структурная целостность IDEF проекта. Иногда отдельные интерфейсные дуги высшего уровня не имеет смысла продолжать рассматривать на диаграммах нижнего уровня или наоборот, так как это усложняет восприятие. Для таких случаев стандарт IDEF предусматривает понятие тоннелирования. Обозначения «тоннеля» в виде двух круглых скобок вокруг начала интерфейсной дуги означает, что эта дуга не была унаследована от родительского блока и появилась из «тоннеля» только на этой диаграмме. Аналогично такое же обозначение вокруг конца интерфейсной дуги вблизи от блока приёмника означает, что в дочерней диаграмме данного блока эта дуга рассматриваться не будет.

Обычно, IDEF – диаграммы несут в себе сложную и концентрированную информацию. Чтобы сделать их удобно читаемыми, в стандарты приняты ограничения сложности: - представлять на диаграмме от 3-х до 6-ти функциональных блоков;

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

четырёх.

15. Диаграммы объектов и классов. Объекты (объект, атрибуты, значения атрибутов). Классы, отношения между классами (ассоциация, обобщение, агрегация)

Диаграмма классов

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

Класс определяет атрибуты и методы набора объектов. Все объекты класса (называемые экземплярами) имеют одинаковое поведение и одинаковый набор атрибутов (у каждого объекта - собственный набор атрибутов).

В UML классы представлены прямоугольниками с именем класса, которые могут отображать атрибуты и операции класса, помещённые внутри прямоугольника.

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

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

Ассоциация

Ассоциация— это структурная связь между классами.

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

Обобщение

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

Ассоциации отображают взаимодействие между классами и структуру связей между объектами.

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

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

Агрегация

Агрегация— это специальный вид ассоциации, обозначающий отношение целое/часть", при котором один или несколько классов являются "частями" одного целого".

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

Композиция – это более тесная агрегация, означающая, что часть не может существовать без целого.

___

Диаграммы объектов

языке UML совпадают с обозначением классов. Но существует три

Обозначения объектов в отличия.

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

• Содержимое верхней секции для объектов подчеркивается.

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

16. Применение UML для описания требований, диаграммы прецедентов.

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

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

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

2. Диаграммы классов отображают классы и взаимодействие между ними.

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

4. Диаграммы состояния отображают состояния, изменения состояний и события в объектах или компонентах системы.

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

6. Диаграммы компонентов показывают компоненты верхнего уровня (такие как KParts или Java Beans).

7. Диаграммы объектов показывают множество объектов - экземпляров классов (изображенных на диаграмме классов) и отношений между ними в некоторый момент времени.

8. Диаграммы коопераций.

Статику системы описывают диаграммы классов и объектов. Остальные диаграммы описывают динамику системы.

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

Диаграмма прецедентов

В диаграмме прецедентов есть два основных понятия – исполнитель (актер – действующее лицо) и прецедент.

Исполнитель представляет один из двух аспектов.

• Роль, которую пользователь играет по отношению к системе.

• Сущность (например, другую систему или базу данных) за пределами системы.

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

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

Прецедент— это набор действий, совершаемых исполнителем в системе, для достижения определенной цели.

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

Прецедент обозначается эллипсом и кратким именем.

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

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

Диаграммы прецедентов

Исполнители и прецеденты изображаются на диаграммах прецедентов.

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

• Прецеденты помещаются в центре.

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

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

При работе с прецедентами следует помнить:

1. Каждый прецедент относится как минимум к одному исполнителю.

2. Каждый прецедент имеет инициатора.

3. Прецеденты могут взаимодействовать с другими прецедентами. Здесь имеется в виду:

- включение - данный прецедент встраивается в другой прецедент,

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

- обобщение – прецедент наследует свойства родительского прецедента.

17. Объект – сущность, пограничный объект, управляющий объект Диаграммы устойчивости

Диаграмма кооперации (устойчивости)

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

Затем эти объекты классифицируются на основе их характеристик.

Существует три типа классов: пограничные классы, классы сущностей и управляющие классы. Рассмотрим названные классы в терминах объектов, являющихся экземплярами этих классов.

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

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

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

18. Динамика работы ИС. Диаграммы последовательностей

Диаграммы последовательностей

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

Диаграмма последовательностей содержит четыре ключевых элемента:

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

• Линия жизни— пунктирная линия, обозначающая период существования объекта.

• Фокус управления— это длинный узкий прямоугольник, находящийся на линии жизни объекта. Прямоугольник представляет период времени, в течение которого объект контролирует поток событий (указывать не обязательно).

• Сообщения иллюстрируют действия, совершаемые объектами по отношению друг к другу и по отношению к самим себе.

19. Диаграммы UML, их назначение. Диаграммы состояний. Диаграммы деятельностей

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

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

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

Диаграмма состояний (statechart diagram)

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

Но поговорим об обозначениях на диаграммах состояний.

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

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

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

Переходы имеют метки, которые состоят из трех необязательных частей, это - события, условия, действия

<событие> <[условие]> </действие>

На диаграммах также отображаются функции, которые выполняются объектом в определенном состоянии.

Синтаксис этой метки такой:

Выполнить /<деятельность>

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

Диаграмма деятельности используется для описания поведения системы. Основные элементы:

1) Овалы - изображение действия объекта,

2) Линейка синхронизации, указание начать или завершить некоторое действие,

3) Ромбы, отображающие принятие решения по поводу выбора одного из маршрутов,

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

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

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

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

20. Типовое проектирование

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

Ключевые особенности технологии типового проектирования

· Причины применения:

o Существенно снижаются затраты на проектирование, разработку и даже на модернизацию ИС;

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

· Сущность: Является одной из разновидностей индустриального проектирования. Заключается в создании информационной системы из готовых типовых элементов.

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

o Схожая структура и правила управления;

o Единые стандарты отчетности;

o Схожие комплексы используемых технических и программных средств;

o Единая цель существования: извлечение прибыли.

· Содержание: Процесс проектирования ИС состоит из следующих основных этапов:

o Разбиение проекта информационной системы на отдельные составляющие (компоненты).

o Выбор и приобретения имеющихся на рынке типовых проектных решений (тиражируемых продуктов) для каждого компонента ИС.

o Настройка и доработка приобретенных типовых проектных решений в соответствии с требованиями конкретной предметной области.

· Условия применения:

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

21. Типовые структурные модели на примере моделей репозитория и OSI.

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

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

Эта модель включает в себя семь уровней:

7)Определяет методы взаимодействия приложений в сети, включая СУБД, электронную почту и т.д.

6)Определяет методы описания, форматирования, преобразования и кодирования данных.

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

4)Определяет проколы для структурирования сообщений и обеспечивает проверку на наличие ошибок при передаче данных.

3)Определяет протоколы маршрутизации в сети.

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

1)определяет механизм взаимодействия со средой передачи данных и интерфейса с аппаратным обеспечением.

Дата добавления: 2015-04-24