17. Оценка размеров программных средств на начальных стадиях проектирования. Метрики количества строк исходного кода и функциональных точек. Метод функциональных точек

Метод функциональных точек. Этот метод явл. основн. технологией для оценки функц. размера как уже готовых, так и находящихся на стадии проек-ния ПС. Функц. точки явл. мерой функциональности, т.е. полезности ПС с позиции пользователя. Функциональность = Функц-сть Данных + Функц-сть Транзакций.

Измер. функц-сти необходимо нач. с опред. границ ПС. При анализе по методу функц. точек рассматр. два вида групп данных: внутр. логич. файл (ILF) – логически связ. группа данных, опред. пользователем и находящаяся внутри границ ПС; и внешн. интерфейсный файл (EIF) – логически связ. группа данных, обеспеч. ПС информацией, но лежащая за его пределами и поддерж. другим ПС.

Транзакции – это элементарные процессы, т.е. наименьшие единицы активности, имеющие смысл для пользователя, кот. происходят внутри ПС и кот. порождаются входной и выходной инф. Выделяют три вида транзакций: Внешн. ввод (EI) – процесс ввода данных и управляющей информ. в ПС. Процессы вида EI исп. для добавления, изменения или удаления инф.(поля ввода данных, сообщ. об ошибках, вычисл. знач., радио-кнопки, флажки и т.д) Внешн. вывод (EO) – процесс, генерирующий данные или упр-ую информ., кот. поступают на выход ПС. Обычно процесс вида EO представляет собой формирование различных экранов, отчетов, сообщений.(Поля данных в отчетах, заголовки полей данных отчетов) Внешн. запрос (EQ) – диалоговый ввод, кот. приводит к немедленному ответу ПС в форме диалогового вывода. Каждой из выявленных характеристик функц-сти ПС (EI, EO, EQ, ILF, или EIF) ставится в соответствие низкий, средний или высокий уровень сложности. Для внешн. и внутр. файлов (ILF и EIF) сложность опр-ся и ранжируется при помощи кол-ва типов элементов записей (RET) и кол-ва типов элементов данных (DET), входящих в соответствующие логические группы данных. При этом под кол-вом RET понимается кол-во различных форматов записей, используемых в данном файле, а под кол-вом DET – кол-во различных полей в записях. Уровни сложности для внутр. и внешн. файлов (ILF и EIF) в завис. от кол-ва RET и DET. Для транзакционных функций (EI, EO и EQ) сложность опр-ся и ранжируется при помощи кол-ва типов использ. файлов (FTR), т.е. количества ILF и EIF участв. в транзакционном процессе, а также кол-ва типов элементов данных DET (отличных друг от друга полей записей), добавляемых, модифицируемых, стираемых или создаваемых в выходных данных.Уровни сложн. для внешн. входов (EI) и выходов (EO) в завис. от числа FTR и DET.

В завис. от весовых коэфф. уровней сложности подсчитывается ненормированный кол-ва функц. точек (UFPC). Для получ. окончат. рез-та анализа, т.е. нормированного кол-ва функц. точек (AFPC), необходимо ненормир. кол-о функц. точек умнож. на нормирующий фактор (VAF), кот. опред. путем анализа 14 основн. хар-к сист. В дальнейшем нормир. кол-во функц. точек может быть исп. для получ. оценки кол-ва строк исх. кода (SLOC) в ПС при помощи бэкфайер-метода, кот. основан на испол. «языкового множителя». Изм. размера ПС явл. ключ. фактором для точной оценки трудоемкости его разработки и планир. работ по его реализ. Основн. метрики размера ПС – это кол-во строк исходного кода (SLOC) и количество функц-ных точек (FPC).

18. История появления UML. Назначение и структура языка. Типы диаграмм UML: диаграммы прецедентов использования, диаграммы классов, диаграммы компонент, диаграммы размещения, диаграммы следования, диаграммы кооперации, диаграммы состояний, диаграммы активности

Методол ООП появ в конце 70х гг –начале 80х гг. К началу 90х гг исп неск методол ООМ – OOSE(object oriented software engineering), OMT-2 (object modeling technique), Booch-93.

У кажд методол имелись + и -. Поэтому появилось предложение создать единый универскальный язык моделир ООС. Разраб UML началась в 1994. В конце 1996 вышел первый рабочий вариант UML 0.90. После его обсужедения. была создана OMG(object modeling group), к-рая занималась дальнейшей разраб UML. В 97 появ официальная версия UML 1.0, а в 2002 – UML 2.0.

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

Назначение UML

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

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

Перечислим осн типы диагр исп в UML, сгруппируя их в соотв с их предназначением:

• диаграммы наивысшего уровня абстрагирования

  1. диагр прецендентов использования

  2. диагр классов

• диагр, опис поведенческие аспекты разраб С

  1. диагр состояний

  2. диагр активности

• диагр, отвечающие за опис взаимод объектов

  1. диагр следования

  2. диагр кооперации

• диагр, связанные с физич реализацией С

  1. диагр компонент

  2. диагр размешения

Диагр прецедентов использования

Суть диагр сост в след: прое-е С предст в виде наборов т.н. акторов(Actor), взаимодействующих с С с помощью прецедентов использования (Use Case)

А ктором м/б любая сущность, взаимод с С из вне: ч-к, оборудование, др С, т.е. все, что взаимод с рассмотренной С.

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

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

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

Явл одними из самых главных в UML, поскольку именно эти диагр исп при ООПр. Диагр классов показывают статическую стр-ру С. Составляющими данного типа лиаг явл: классы, объекты и отношения между ними.

Нотация диагр классов достаточно проста. Класс на диагр предс прямоугольником с тремя разделами:

Схожая нотации примен для объектов (объект –конкретный экземпляр класса). Отличие закл в том, что к имени класса добавл имя объекта и вся надпись подчеркивается.

Диагр классов –очень мощная методология.

Отношения между классами быв следующими:

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

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

• «обобщение». Изображ в виде треугольника со связующими линиями. Отнош обобщения позволяет представить иерархию наследования от суперкласса к подклассам

Диагр состояния

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

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

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

Диагр активности

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

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

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

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

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

Диагр взаимод быв 2 типов: диагр следования и диагр кооперации.

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

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

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

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

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

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

• Визуализации общей структуры исходного кода программной системы.

• Спецификации исполнимого варианта программной системы.

• Обеспечения многократного использования отдельных фрагментов программного кода.

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

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