2.Организация проектирования по

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

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

Различают след осн классы архитектур ПС:

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

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

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

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

Различают однопользовательскую архитектуру , и многопольз-ую архитектуру.

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

-проектирование

-оформление проектн. документ-и

-пользовательского интерфейса

Структурный и объектный подходы к разработке программ.

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

Общие принципы:

1.базовые

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

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

2.второстепенные

-абстрогирование. Выделение существенных аспектов системы и отличие от несущест-х.

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

-непротиворечивость. Обоснован-ть и согласов. элемента .

-структурирование данных. Данные должны быть структурирован. и иерархически организованны.

Метод проектирования архитектуры:

1.Нисходящего проектирования. Представл-т собой подход функцион-ой декомпозиции на основе 2-х стратегий:

-пошагового уточнения, при кот на каждом след этапе разбиения опред-т модули более низкого уровня.

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

2.Метод восходящего проектир-я. Это подход при кот в первую очередь опред-т вспомогательные модули требующиеся для проектир. программы.

3.Метод расширения ядра. Это подход при кот осн внешние направления на выявления мн-ва вспомогательн-х модулей, а не на опред-е функций всех программ в целом.

Объектный подход.

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

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

Недостатки:1.снижение производ-ти функционирован. программ и высокие начальные затраты.2.подход не дает немедленной отдачи. метод структурного анализа и проектирования SADT (IDEF0)

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

Средством для создания модели являются диаграммы:

1.SADT – модели и соответствующие функциональные модели

2.DFD – диаграммы потоков данных

3.ERD – диаграммы сущность-связь

Перечисленные модели в совокупности дают полное описание информационной модели.

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

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

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

3.Каждая из этих под функций может быть также декомпозирована

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

Для построения DFD традиционно используют 2 различные нотации. Соответствующие методам Иордона – де Марко и Гейна – Сэрсона. 1.Внешняя сущность - это материальный объект или физическое лицо, выступающее в качестве источника или приемника информации. Например, заказчики, клиенты, банк. 2.Процесс – преобразование входных потоков данных в выходные, в соответствии с определенным алгоритмом. Каждый процесс имеет свой номер и связан с исполнителем, которые осуществляет данные преобразования.

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

Методы объектно-ориентированного анализа и проектирования. Язык UML.

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

Её основные принципы: абстрагирование. Инкапсуляция. Модульность. Иерархия.

и понятия ( объект, класс, атрибут, операция, интерфейс ) наиболее чётко сформулированы Гради Бучом.

Большинство современных методов анализа и проектирования основываются на использовании языка UML.

UML- язык для определения представления, проектирования и документирования ПС. UML содержит стандартный набор диаграмм и нотаций. Создание UML началось в конце 1994 года Гради Бучом и Джейсом Рамбом.

Главными в разработке UML были следующие цели:

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

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

3.обеспечить независимость от конкретных языков программирования.

4.язык должен быть точным и доступным для понимания, лишен формализма.

5.стимулировать рост рынка объектно-ориентированных инструментальных средств.

6.интегрировать лучший практический опыт.

Стандарт UML версия 1.1., принятый организацией OMG в 1997 году. Содержит следующий набор диаграмм:

1.структурные модели:

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

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

В) диаграммы размещения для моделирования физической архитектуры системы (отражает физические взаимосвязи между программными и аппаратными компонентами системы).

2.модели поведения:

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

Б)диаграммы взаимодействия(описывают поведения, взаимодействия групп объектов).

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

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

Д)диаграммы деятельности для моделирования поведения(используются при описании поведения системы).

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

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

UML допускает произвольную интерпретацию семантики (смысл значения команды) элементов модели.

UML является слабо типизированным языком. К механизмам расширения языка UML относят стереотипы, именованные значения и ограничения.

Стереотип – новый тип элемента модели, который определяется на основе уже существующего элемента.

Стереотипы классов - это механизм, позволяющий разделять классы на категории. ПРИМЕР!

Именованное значение – пара строк : тег = значение или имя = содержимое , в которых хранится дополнительная инфо о элементе системы.