Автор работы: Пользователь скрыл имя, 17 Декабря 2014 в 02:02, курс лекций
Введение в идеологию. В эпоху НТП объемы производства и использование средств вычислительной технологии во многом определял Н.Т.П. Резкое снижение средств вычислительной техники создало предпосылки для массового внедрения вычислительной техники в бытовом производстве. Это позволило провести широкую автоматизацию производственных процессов на базе встроенных микропроцессов вплоть до применения их в бытовой технике.
Детальное проектир-е…. поддерж. базой
Наиболее слабым местом при разработки ПО, является методы разработки архитектуры программ, где до сих пор отсутствуют формальные подходы проектирования архитектуры. Однако, существуют 2 подхода, которые в какой - то степени обеспечивают проектирование ПО.:
Лекция 7
Метод абстракций – это метод часто применяется при построении архитектуры системы ПО, которая конструируется из подсистем, и называемая уровнями абстракций, взаимодействие которой определяется совокупностью правил. Уровни абстракций иерархически упорядочены. Каждый уровень абстракций использует ресурсы только тех уровней, которые находятся ниже по иерархии. Каждый из уровней абстракций подчиняется следующим правилам:
1) На каждом уровне абстракций абсолютно ничего не известно о уровнях абстракций более высокой иерархии.
2) На каждом уровне абстракций ничего не известно о других уровнях абстракций и также ничего ни известно о внутреннем устройстве других уровней абстракций.
3 ) Каждый уровней абстракций (группа модулей), часть их может являться внутренней, т.е. приватными, а остальная часть может быть доступна другим уровня абстракции.
4) Каждый уровень абстракций обладает определенными ресурсами, которые он может скрывать или показывать для других уровней абстракций, т.е. имеет возможность предоставлять. избирательно для других. уровней свои ресурсы.
5) Каждый уровень абстракций может обеспечивать абстракцию данных в системе, т. е. формировать определенные структуры данных для других уровней абстракций.
6) Связи между уровнями абстракции ограничены аргументами, передаваемыми программами с уровня все уровни.
7) Каждая из представляемых уровням абстракций функция обладает одним входом и одним выходом, а все аргументы этих функции должны носить простой характер (не быть структурами). Данную концепцию использовал Дейкстра для разработки архитектуры ОС .
Метод портов
Также используется для разработки ОС. В данном методе предполагается, что система состоит из асинхронно функционирующих подсистем обменивающихся информацией путем посылки сообщений от системы к подсистеме через порты. Каждая из подсистем может иметь 1 или несколько входных портов (очередей, необходимых выполнить в данном порте). Входы портов могут использоваться другими подсистемами для посылки своих сообщений данной подсистеме. При этом каждая из подсистем слабо связана между собой, более того она может не знать о подсистемах, которые хранятся в памяти рядом. Однако оно должно быть известно лишь специальным программам, обеспечивающим механизмы передачи сообщений. Есть технологические комплексы, где 2 подхода реализуются в совокупности, где передача сообщений обеспечивается методом портов, а подсистемы организованны методом концепций уровней абстракций.
После завершения построения архитектуры системы ПО каждая подсистема разбивается на модули – минимальная программа или минимальная программная единица.
Для того, чтобы уменьшить сложность описываемой системы применяется метод декомпозиции. На более мелкие составные части, однако данный формальный подход потерпел неудачу по следующим причинам:
1) Модули выполняют слишком много функций что приводит к запутанным и сложным программам.
2) Многие общие функции для системы не конкретизированы, рассредоточены и по-разному реализованы в различных модулях.
3)Не учтены все
В принципе любую программу можно рассматривать как совокупность операторов, связанных между собой некоторыми отношениями. Разбиение такой программы на модули, означает выбор такой структуры при которой связь между операторами внутри модуля была бы сильнее между любыми операторами в различных модулях, это приводит нас к пониманию следующих вещей: к пониманию прочностей и сцеплении модулей.
Прочность модуля - мера его внутренних связей.
Подразделяют 7 видов прочностей, которые образуют иерархию, которая позволяет градуировать, систематизировать данные оценки модулей.
1) Прочность модуля по
2) Логическая прочность- прочность при каждом вызове выполняет одну из связных с ним функций. Основным недостатком является то, что характерными для данного вида модулей является сложное сопряжение необходимое для выполнения данных функций, а также высокая вероятность внесения ошибки при изменении данных функций модуля.
3) Прочность по классу - это модуль, последовательно выполняющий связанные с ним функции. У данного класса модулей существует сильная, часто неявная связь, связанных с функциям других модулей, а также такая связь приводит к высокой чувствительности, к внесению изменений.
4)Процедурная прочность модуля – это прочный по классу модуль, выполняемые функции которого непосредственно относятся к процедурному выполнению или процедуре решения задачи. Основным недостатком данного класса модулей является сильная взаимозависимость внутренних фрагментов от различных функций решаемых задач этим модулем.
5) Коммуникационная прочность – это процедурно прочный модуль, у которого все функции связаны по данным, что увеличивает связанность выполняемых функций.
6) Информационная прочность – это коммуникационно прочный модуль, каждая функция которого предоставляется одним входом или определяется одним собственным входом.
7) Функциональная прочность – это информационно прочный модуль выполняющий одну функцию.
Определение. Сцепления модуля – это мера взаимозависимости модулей по данным, обусловленная как организацией этих данных, так и их передачей.
Выделяют 6 видов сцепления модулей, которые также образуют иерархию по степени сцепления:
1) Сцепление по содержимому, когда модуль А ссылается на данные модуля В использую абсолютное смещение. Любые изменения одного из модулей практически приводят программу в неработающее состояние.
2) Сцепление по общей области, когда модуль А и модуль В ссылаются на одну и ту же глобальную структуру данных. Создание глобальных данных создает практически непреодолимые трудности при необходимости управления доступа к этим данным различных модулей. Кроме того глобальные данные ухудшают понимание программы, а также делают увеличение вероятность постороннего доступа к ним.
3) Сцепление модулей по внешним данным, когда модуль А и модуль В ссылаются на один и то же глобальный элемент данных. Здесь проявляется практически все недостатки свойственные сцеплению по общей области за исключением проблем, связанных с физическим упорядочиванием элементов общей структуры данных.
4) Сцепление по управлению, когда
модуль А явно управляет
5) Сцепление по формату, когда модуль А и В ссылаются на одну и туже глобальную структуру данных. При этом модули А и В чувствительны к изменению структуры формата. Если при этом структура данных избыточна, то вероятность внесения ошибок возрастает.
6) Сцепление по данным когда модуль А вызывает модуль В и все входные и выходные данные или параметры, вызываемого модуля являются простыми элементами данных ( не структурированы).
Виды прочности модулей приведены в порядке их возрастания, чем прочнее модуль, тем четче определена его функция, тем он проще для понимания, тем вероятнее использовать его в модуле различных контекстов.
Типы сцепления модулей описаны в порядке уменьшения, чем слабее сцепление модулей, тем более они независимые, тем меньше вероятность, что изменение одного модуля повлечет изменения другого модуля, тем проще поручить разработку данного модуля отдельной команде или одному специалисту.
Степень прочности модулей некоторого проекта системы ПО и степень взаимного их сцепления могут использоваться для оценки качества проекта.
Структурный подход
Структурная организация модулей.
Основными объектами структуризации обычно выступает поток передач управления в программе. Именно это определяет структуру.
Что касается потока управления, то сложность программирования возникает в программе, тогда когда используется оператор goto который нарушает структуризацию любой программы. Такие языки как Фортран, Бэйсик используют данный оператор, что говорит о его главной структурированности.
Лекция 8
Технология прогр.
Для обеспечения структуризации программирования, программы снабжены следующими типами операторами.
1) Последовательный оператор.
2) Условный оператор.
3) Оператор цикла это позволило обеспечить понимаемость и читаемость программ. Каждый из этих операторов имеет отдельный вход и отдельный выход, а программирование, использующее эти типы операторов, называются структурным программированием. Методы, в которых используют данные виды программирования – методы Джексона и R – технологий (методы от данных). В направлении развития структурного программирования с появлением абстрактных типов данных следует выделить следующие положения. 1) Когда описание данных разделено на 2 части: в том числе на описание действий, которые можно выполнить некоторой структурой данных, и реализация этих описаний, такое описание позволило повысить независимость работы программ со сложными структурами, от самих данных и от способов реализации этих данных (обычная инкапсуляция).
Средства представления проектной информации и структуризация ее в процессе разработки ПО
В процессе разработки ПО на каждом этапе создается некоторое описание проектируемой системы, где на каждом этапе определяется определенный перечень документов, отвечающих данному этапу разработки. По форме проектная информация представляется обычно в графическом, символьном и в виде шаблонов форме, описанных определенными структурами, а в ряде случаев и комбинированной форме представления информации (таблично-графической). Одним из возможных методов, способов классификации представления проектной информации на каждом этапе – это определение цели, методами описания( на кого ориентирована данная информация и технологические способы представления данной информации), т.е. главное вся проектная информация делится на этапы.
Недостаток: на каждом этапе собирается информация, которая дублируется. В ней не всегда удается сообщить информацию по методам, т.е. методы обработки. на каждом этапе могут быть разные.
Основные признаки которые. обычно используют для анализа проектной информации состоят :
1) Какие объекты требуют описания.
2) Какие математические методы и модели надо использовать при описании.
3) Кто будет воспринимать данное описание.
4) Какова технологическая роль представления.
Ответы на данные вопросы позволят оценить рамки применения данной проектной информации на каждом этапе, а также средства представления проектной информации, в процессе разработки проектной информации.
Глушковым было предложено описания следующих типов: функциональное, морфологическое и информационное описание в процессе разработки на каждом этапе. Функциональное описание объектов включает в себя:
1) Описание характеристик и параметров внешней среды как некоторой системы обработки данных, в рамках которой и должно функционировать данное ПО.
2) Параметры самого ПО.
3) Процессы взаимодействия внешней среды и ПО.
4) Функции ПО. определяемые данными процессами или поддерживающие данные процессы.
5) Критериев и показателей эффективности выполнения той или иной функции при разработке ПО.
Морфологическое описание объекта должно дать представление о строении ПО как некоторой системы.
1) Описание состава функций компонент ПО.
2) Структуры и связи ПО, т.е. отношение данных. Информационное описание должно отражать:
1) Законы изменения параметров внешней среды ПО.
2)Диапазоны изменения этих пар-ров.
3) Способы
представления их в
Математические методы и модели, используемые в описании в процессе разработки проектной информации.
Различные
способы представления
Пользователи проектной информации. – т.е. кто будет воспринимать эту информацию на каждом этапе:
1) если оно будет анализироваться заказчиком, не являющимся профессиональным программистом, то информация должна быть представлена на таком уровне и в тех. терминах как на котором заказчик сможет оценить предлагаемую работу.
2) Описание ориентированное на разработчика ПО (программиста) должно быть представлено на уровне, понимаемом программистами и в терминах реализующих данной ПО.
3) Для тех, кто непосредственно
интерпретирует данное ПО(