Модели качества процесса конструирования. Архитектура программных средств.
Стандарт ISO 9126:1991 - Оценка программного продукта. Характеристики качества и руководство по их применению является основой формального регламентирования характеристик качества ПС.Развитие этого стандарта проводится в направлении уточнения, детализации и расширения, описаний характеристик качества комплексов программ. Для замены редакции 1991 года завершается разработка и формализован проект стандарта, состоящего из четырех частей ISO 9126:1-4. Стандарт ISO 9126:1991 предполагается заменить на две взаимосвязанные серии стандартов: ISO 9126:1-4 (проект) - "Качество программных средств", а также на утвержденный стандарт ISO 14598:1-6:1998-2000
Модели качества процессов конструирования
В условиях жесткой конкуренции очень важно гарантировать высокое качество процесса конструирования ПО. Такую гарантию дает сертификат качества процесса, подтверждающий его
соответствие принятым международным стандартам. Каждый такой стандарт фиксирует свою модель обеспечения качества. Наиболее авторитетны модели стандартов ISO 9001:2000, ISO /
IЕС 15504 и модель зрелости процесса конструирования ПО (Capability Maturity Model - СММ)Института программной инженерии при американском университете Карнеги-Меллон. Модель стандарта ISO 9001:2000 ориентирована на процессы разработки из любых областей человеческой деятельности.
Стандарт ISO / IЕС 15504 специализируется на процессах программной разработки и отличается более высоким уровнем детализации. Достаточно сказать, что объем этого стандарта (документа) превышает 500 страниц. Значительная часть идей ISO/IЕС 15504 взята из модели СММ. Базовым понятием модели СММсчитается зрелость компании.
|
|
|
Архитектуройпрограммных средств (программного обеспечения) называют совокупность решений относительно: организации программной системы; выбора структурных элементов, составляющих систему, и их интерфейсов; поведения этих элементов, специфицированного в кооперациях с другими элементами; составления из этих структурных и поведенческих элементов
все более и более крупных подсистем;архитектурного стиля, направляющего и определяющего всю
организацию системы (статические и динамические элементы, их интерфейсы, кооперации и способы их объединения).
· вид с точки зрения прецедентов (use case view) охватывает прецеденты, которые описывают поведение системы, наблюдаемое конечными пользователями, аналитиками и тестерами. Этот вид специфицирует не истинную организацию программной системы, а те движущие силы, от которых зависит формирование системной архитектуры;
· вид с точки зрения проектирования (design view) охватывает классы, интерфейсы и кооперации, формирующие словарь задачи и ее решения. Этот вид подчеркивает прежде всего функциональные требования, предъявляемые к системе, то есть те услуги, которые она должна предоставлять конечным пользователям;
|
|
|
· вид с точки зрения процессов (process view) охватывает нити и процессы, формирующие механизмы параллелизма и синхронизации в системе. Этот вид описывает главным образом производительность, масштабируемость и пропускную способность системы.
вид с точки зрения реализации (implementation view) охватывает компоненты и файлы, используемые для сборки и выпуска конечного программного продукта. Этот вид предназначен в первую очередь для управления конфигурацией версий системы, составляемых из независимых (до некоторой степени) компонентов и файлов, которые могут по-разному объединяться между собой;
· вид с точки зрения развертывания (deployment view) охватывает узлы, формирующие топологию аппаратных средств системы, на которой она выполняется. В первую очередь он связан с распределением, поставкой и установкой частей, составляющий физическую систему.
17. Базис языка UML Лекция 11
UML (англ. Unified Modeling Language — унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения. UML является языком широкого профиля, это открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML-моделью. UML был создан для определения, визуализации, проектирования и документирования в основном программных систем. UML не является языком программирования, но в средствах выполнения UML-моделей как интерпретируемого кода возможна кодогенерация. UML представляет собой объектно-ориентированный язык моделирования, обладающий следующими основными характеристиками:
|
|
|
• является языком визуального моделирования, который обеспечивает разработку репрезентативных моделей для организации взаимодействия заказчика и разработчика ИС различных групп разработчиков ИС;
• содержит механизмы расширения и специализации базовых концепций языка.
Класс –описание множества объектов, которые разделяют одинаковые свойства, операции, отношения и семантику (смысл). Класс реализует один или несколько интерфейсов.
Интерфейс– набор операций, которые определяют услуги класса или компонента. Интерфейс описывает поведение элемента, видимое извне
|
|
|
Кооперация(сотрудничество) – определяет взаимодействие и является совокупностью ролей и других элементов, которые работают вместе для обеспечения коллективного поведения более сложного, чем простая сумма всех элементов.
Актер – набор согласованных ролей, которые могут играть пользователи при взаимодействии с системой (ее элементами Use Case).
Элемент Use Case(Прецедент) – описание последовательности действий, выполняемых системой в интересах отдельного актера и производящих видимый для актера результат.
 |
Активный класс – класс, чьи объекты имеют один или несколько процессов и поэтому могут инициировать управляющую деятельность. Активный класс похож на обычный класс за исключением того, что его объекты действуют одновременно с объектами других классов.
Компонент – физическая и заменяемая часть системы, которая соответствует набору интерфейсов и обеспечивает реализацию этого набора интерфейсов. Обычно компонент – это физическая упаковка различных логических элементов (классов, интерфейсов и сотрудничеств).
Узел – физический элемент, который существует в период работы системы и представляет ресурс, обычно имеющий память и возможности обработки. В узле размещается набор компонентов, который может перемещаться от узла к узлу.
Артефакт – это любой созданный искусственно элемент программной системы.
К элементам программной системы, а, следовательно, и к артефактам, могут относиться исполняемые файлы, исходные тексты, веб страницы, справочные файлы, сопроводительные документы, файлы с данными, модели и многое другое, являющееся физическим носителем информации. Другими словами, артефактами являются те информационные элементы, которые тем или иным способом используются при работе программной системы и входят в ее состав.
В UML имеются четыре разновидности предметов:
· структурные предметы;
· предметы поведения;
· группирующие предметы;
· поясняющие предметы.
Эти предметы являются базовыми объектно-ориентированными строительными блоками. Они используются для написания моделей.
Предметы поведения — динамические части UML-моделей. Они являются глаголами моделей, представлением поведения во времени и пространстве. Существует две основные разновидности предметов поведения.
Взаимодействие – поведение, заключающее в себе набор сообщений, которыми обменивается набор объектов в конкретном контексте для достижения определенной цели. Элементами взаимодействия являются сообщения, последовательность действий (поведение, вызываемое сообщением) и связи (соединения между объектами). 
Конечный автомат – поведение, которое определяет последовательность состояний объекта или взаимодействия, выполняемые в ходе его существования в ответ на события (и с учетом обязанностей по этим событиям). Элементами конечного автомата являются состояния, переходы (от состояния к состоянию), события (предметы, вызывающие переходы) и действия (реакции на переход). 
Группирующие предметы
Пакет – общий механизм для распределения элементов по группам. Пакет существует только в период разработки.
Последовательное представление отношений сущностей очень полезно. Самая главная часть диаграммы классов —это отношения
Отношения UML
Зависимость – семантическое отношение между двумя предметами, в котором изменение в одном предмете (независимом предмете) может влиять на семантику другого предмета (зависимого предмета)
Ассоциация – структурное отношение, которое описывает набор связей, являющихся соединением между объектами. Агрегация – это специальная разновидность ассоциации, представляющая структурное отношение между целым и его частями.
Обобщение – отношение специализации/обобщения, в котором объекты специализированного элемента (потомка) могут заменять объекты обобщенного элемента (предка).
Реализация – семантическое отношение между классификаторами, где один классификатор определяет контракт, который другой классификатор обязуется выполнять (к классификаторам относят классы, интерфейсы, компоненты, элементы Use Case, кооперации). Отношения реализации применяют в двух случаях: между интерфейсами и классами (или компонентами), реализующими их; между элементами Use Case и кооперациями, которые реализуют их.
В UML имеются четыре разновидности отношений:
1. Зависимость — семантическое отношение между двумя предметами, в котором изменение в одном предмете (независимом предмете) может влиять на семантику другого предмета (зависимого предмета).
2. Ассоциация — структурное отношение, которое описывает набор связей, являющихся соединением между объектами. Агрегация — это специальная разновидность ассоциации, представляющая структурное отношение между целым и его частями.
3. Обобщение — отношение специализации/обобщения, в котором объекты специализированного элемента (потомка, ребенка) могут заменять объекты обобщенного элемента (предка, родителя). Иначе говоря, потомок разделяет структуру и поведение родителя.
4. Реализация — семантическое отношение между классификаторами, где один классификатор определяет контракт, который другой классификатор обязуется выполнять (к классификаторам относят классы, интерфейсы, компоненты, элементы Use Case, кооперации). Отношения реализации применяют в двух случаях: между интерфейсами и классами (или компонентами), реализующими их; между элементами Use Case и кооперациями, которые реализуют их.
Дата добавления: 2018-02-15; просмотров: 1072; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!