11. Функциональная спецификация программных систем.

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

Функциональная спецификация состоит из трех частей:

• описания внешней информационной среды, к которой должны применяться программы разрабатываемой ПС;

• определение функций ПС, определенных на множестве состояний этой информационной среды (такие функции называют внешними функциями ПС);

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

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

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

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

12. Архитектура программных систем

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

Основные задачи разработки архитектуры ПС:

• выделение программных подсистем и отображение на них внешних функций (заданных во внешнем описании) ПС;

• определение способов взаимодействия между выделенными программными подсистемами.

С учетом принимаемых на этом этапе решений производится дальнейшая конкретизация функциональных спецификаций.

Архитектура программной системы - есть совокупность решений относительно:

• организации программной системы;

• выбора структурных элементов, составляющих систему, и их интерфейсов;

• поведения этих элементов, специфицированного в кооперациях с другими элементами;

• составления из этих структурных и поведенческих элементов все более и более крупных подсистем;

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

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

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

• конечные пользователи,

• системные аналитики,

• руководители проекта,

• разработчики,

• тестеры,

• технические писатели,

• менеджеры

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

Итеративный (iterative) процесс предполагает управление потоком исполняемых версий системы.

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