Унифицированный язык моделирования UML

Унифицированный язык моделирования UML

Назначение языка UML. Общая структура языка UML. Характеристики основных объектов.

Назначение языка UML

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

Общая структура языка UML

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

· является языком визуального моделирования, который обеспечивает разработку репрезентативных моделей для организации взаимодействия заказчика и разработчика ИС, различных групп разработчиков ИС;

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

Характеристики основных объектов

Классы — это базовые элементы любой объектно–ориентированной системы. Классы представляют собой описание совокупностей однородных объектов с присущими им свойствами — атрибутами, операциями, отношениями и семантикой.

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

Операция — реализация функции, которую можно запросить у любого объекта класса. Операция показывает, что можно сделать с объектом. Исполнение операции часто связано с обработкой и изменением значений атрибутов объекта, а также изменением состояния объекта.

 

Базовые принципы языка UML. Абстракция. Наследование. Полиморфизм. Инкапсуляция. Передача сообщений. Ассоциации. Агрегирование. Зависимость.

Базовые принципы языка UML

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

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

Абстракция

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

Пример: чтобы вычислить скорость движения необходимо путь поделить на время. Нет необходимости учитывать силу трения, температуру и потоки ветров.

Наследование

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

Полиморфизм

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

Пример: классы Man и Woman наследуют интерфейс Human и реализовывают в нем методы под свои нужды.

Инкапсуляция

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

· public – доступен везде

· protected – доступен, только если мы наследуем этот класс, либо ссылаемся на него

· internal – доступен в текущей сборке

· private – доступ ограничен

Пример: пилоты самолета видят все. Пассажиры самолета не видят ничего, кроме окон и сидений.

 

Передача сообщений

Взаимодействие между экземплярами актеров и объектами моделируется посредством передачи сообщений. Сообщение (англ. message) – это спецификация факта передачи информации между сущностями с ожиданием выполнения определенных действий со стороны принимающей сущности. Сущность, отправляющую сообщение, называют клиентом, а принимающую – сервером. Таким образом, сообщения не только передают некоторую информацию, но и требуют или предполагают выполнения сервером определенных действий или передачу (возврат) клиенту необходимой информации. Если принимающей сообщение сущностью является объект, то оно представляет собой операцию (метод) объекта-сервера. Прием сообщения обычно трактуется, как возникновение события на сервере. Сообщения изображаются стрелкой с обязательным указанием направления (остриё стрелки указывает на принимающую сторону) и спецификации.

Ассоциации

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

Агрегирование

При агрегации реализуется слабая связь, то есть в данном случае объекты Car и Engine будут равноправны. В конструктор Car передается ссылка на уже имеющийся объект Engine. И, как правило, определяется ссылка не на конкретный класс, а на абстрактный класс или интерфейс, что увеличивает гибкость программы.

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

Зависимость

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

Графически представляется штриховой стрелкой, идущей от зависимого элемента к тому, от которого он зависит.

Существует несколько именованных вариантов. Зависимость может быть между экземплярами, классами или экземпляром и классом.

 

 

Семантика и синтаксис UML

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

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

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

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

· public (общий) – любой внешний класс, который «видит» данный, может пользоваться его общими свойствами. Обозначаются знаком «+» перед именем атрибута или операции;

· protected (защищенный) – только любой потомок данного класса может пользоваться его защищенными свойствами. Обозначаются знаком «#»;

· private (закрытый) – только данный класс может пользоваться этими свойствами. Обозначаются символом «–».

Область действия свойства указывает, будет ли оно проявлять себя по-разному в каждом экземпляре класса, или одно и то же значение свойства будет совместно использоваться всеми экземплярами:

· instance (экземпляр) – у каждого экземпляра класса есть собственное значение данного свойства;

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

Возможное количество экземпляров класса называется его кратностью. В UML можно определять следующие разновидности классов:

· не содержащие ни одного экземпляра – тогда класс становится служебным (Abstract);

· содержащие ровно один экземпляр (Singleton);

· содержащие заданное число экземпляров;

· содержащие произвольное число экземпляров.

Нотация UML

Unified Modeling Language (UML) - Унифицированный язык моделирования, предназначен для моделирования различных классов систем и их программного обеспечения. Нотация использует объектно-ориентированные методы. Моделирование в данной нотации позволяет последовательно пройти концептуальный, логический и физический уровни моделирования систем.

Основные объекты нотации:

· Сущности

· Структурные сущности

· Поведенческие сущности

· Группирующие сущности

· Аннотационные сущности

Отношения

· Зависимость

· Ассоциация

· Обобщение

· Реализация

Типы диаграмм UML

· Диаграмма классов (Class diagram) Представляет логическую модель системы

· Диаграмма объектов (Object diagram) Показывает часть объектов системы и связи между ними

· Диаграмма прецедентов (Use case diagram) Описывает функциональное назначение системы, является её концептуальной моделью, отражает объекты и задачи, ими выполняемые

· Диаграмма последовательностей (Sequence diagram) Отражает последовательность передачи сообщений между объектами, акцентируя последовательности приема/передачи сообщений

· Диаграмма кооперации (Collaboration diagram) Позволяет отследить все взаимосвязи объектов

· Диаграмма состояний (Statechart diagram) Отображает состояния объектов системы

· Диаграмма деятельности (Activity diagram) Отражает бизнес-процессы объекта. Этот тип диаграмм позволяет показать не только последовательность процессов, но ветвление и их синхронизацию. Данные диаграммы позволяют проектировать алгоритмы поведения объектов любой сложности, в том числе может использоваться для составления блок-схем

· Диаграмма компонентов (Component diagram) Диаграммы этого вида используются редко

· Диаграмма развертывания (Deployment diagram) Показывает декомпозицию системы на физические устройства различных видов

 

 

Особенности изображения диаграмм языка UML. Диаграмма Вариантов использования (Use Case Diagram). Диаграмма Классов (Class Diagram). Диаграмма Состояний (Statechart diagram). Диаграмма Последовательности (sequence diagram).

Диаграммы

Диаграмма использования

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

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

Диаграмма классов. Диаграмма классов, Class diagram — статическая структурная диаграмма, описывающая структуру системы, она демонстрирует классы системы, их атрибуты, методы и зависимости между классами.

 

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

Диаграмма автомата.(диаг. Состояний) Диаграмма автомата, State Machine diagram (диаграмма конечного автомата, диаграмма состояний) — диаграмма, на которой представлен конечный автомат с простыми состояниями, переходами и композитными состояниями.

 

Диаграмма последовательности

Диаграмма последовательности, Sequence diagram — диаграмма, на которой изображено упорядоченное во времени взаимодействие объектов. В частности, на ней изображаются участвующие во взаимодействии объекты и последовательность сообщений, которыми они обмениваются.

Диаграмма кооперации

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

· показать набор взаимодействующих объектов в реальном окружении "с высоты птичьего полета";

· распределить функциональность между классами, основываясь на результатах изучения динамических аспектов системы;

· описать логику выполнения сложных операций, особенно в тех случаях, когда один объект взаимодействует еще с несколькими объектами;

· изучить роли, выполняемые объектами внутри системы, а также отношения между объектами, в которые они вовлекаются, выполняя эти роли.

Говоря о диаграммах кооперации, часто упоминают два "уровня" таких диаграмм:

· уровень экземпляров (примеров, Instance-Level): отображает взаимодействия между объектами (экземплярами классов); такая диаграмма обычно создается, чтобы исследовать внутреннее устройство объектно-ориентированной системы.

· уровень спецификации (Specification-Level): используется для изучения ролей, исполняемых в системе основными классами.

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

 

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

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

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

Основной тип сущностей на диаграмме компонентов ‒ это сами компоненты 1, а также интерфейсы 2, посредством которых указывается взаимосвязь между компонентами. На диаграмме компонентов применяются следующие отношения:

· реализации между компонентами и интерфейсами (компонент реализует интерфейс);

· зависимости между компонентами и интерфейсами (компонент использует интерфейс) 3.

 

Диаграмма развертывания

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

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

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

· определить распределение компонентов системы по ее физическим узлам;

· показать физические связи между всеми узлами реализации системы на этапе ее исполнения;

· выявить узкие места системы и реконфигурировать ее топологию для достижения требуемой производительности.

 

Анализ и проектирование

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

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

Аналитики собирают и фиксируют информацию в двух взаимосвязанных формах:

• функции — информация о событиях и процессах, которые происходят в бизнесе;

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

Ранее двумя классическими результатами анализа были: иерархия функций, которая разбивает процесс обработки на компоненты («что делается и из чего это состоит»), и модель «сущность–связь» (Entry Relationship model, ER–модель), которая описывает сущности, их атрибуты и связи (отношения) между ними. Эти результаты являются необходимыми, но не достаточными. К достаточным результатам следует отнести диаграммы потоков данных и диаграммы жизненных циклов сущностей, которые описывают динамику системы. В настоящее время существует способ формализации проекта — Unified Modelling Language (UML), позволяющий формально описать различные стороны жизнедеятельности разрабатываемого проекта. Существует достаточно большое количество ПО, реализующего UML, например Rational Rose, Microsoft Visio. О UML мы расскажем в отдельной части данной статьи.

На этапе проектирования формируется модель данных. Проектировщики получают входные данные анализа. Конечным продуктом этапа проектирования являются схема базы данных (если таковая существует в проекте) или схема хранилища данных (ER–модель) и набор спецификаций модулей системы (модель функций).

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

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

Задачами проектирования являются:

• рассмотрение результатов анализа и проверка их полноты;

• семинары с заказчиком;

• определение критических участков проекта и оценка ограничений проекта;

• определение архитектуры системы;

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

• проектирование хранилища данных: модель базы данных, бета–версия базы данных;

• проектирование процессов и кода: окончательный выбор средств разработки, определение интерфейсов программ, отображение функций системы на ее модули и определение спецификаций модулей;

• определение требований к процессу тестирования;

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

Классификация АСУ. Особенности комплексной автоматизации. Требования к системам комплексной автоматизации. Программные продукты и их основные характеристики. Основные понятия программного обеспечения.

Классификация АСУ

АСУ - это, как правило, система «человек-машина», призванная обеспечивать автоматизированный сбор и обработку информации, необходимый для оптимизации процесса управления. В отличие от автоматических систем, где человек полностью исключён из контура управления, АСУ предполагает активное участие человека в контуре управления, который обеспечивает необходимую гибкость и адаптивность АСУ.

В зависимости от роли человека в процессе управления, форм связи и функционирования звена «человек-машина», оператором и ЭВМ, между ЭВМ и средствами контроля и управления все системы можно разделить на два класса:

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

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

 

Информационные системы

Цель таких систем - получение оператором информации с высокой достоверностью для эффективного принятия решений. Характерной особенностью для информационных систем является работа ЭВМ в разомкнутой схеме управления. Причём возможны информационные системы различного уровня.

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

В информационно справочных системах ЭВМ необходима только для сбора и обработки информации об управляемом объекте. На основе информации, переработанной в ЭВМ и предоставленной в удобной для восприятия форме, оператор принимает решения относительно способа управления объектом.

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

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

· определение рационального технологического режима функционирования по отдельным технологическим параметрам процесса;

· определение управляющих воздействий по всем или отдельным параметрам процесса;

· определение значений (величин) установок локальных регуляторов.

 

Управляющие системы

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

Супервизорные системы управления. АСУ, функционирующая в режиме супервизорного управления, предназначена для организации многопрограммного режима работы ЭВМ и представляет собой двухуровневую иерархическую систему, обладающую широкими возможностями и повышенной надёжностью. Управляющая программа определяет очевидность выполнения программ и подпрограмм и руководит загрузкой устройств ЭВМ.

Системы прямого цифрового управления. ЭВМ непосредственно вырабатывает оптимальные управляющие воздействия и с помощью соответствующих преобразователей передаёт команды управления на исполнительные механизмы. Режим прямого цифрового управления позволяет применять более эффективные принципы регулирования и управления и выбирать их оптимальный вариант; реализовать оптимизирующие функции и адаптацию к изменению внешней среды и переменным параметрам объекта управления; снизить расходы на техническое обслуживание и унифицировать средства контроля и управления.

 

 

Программный продукт

1) согласно ГОСТ 7.83–2001 СИБИД «Электронные издания. Основные виды и выходные сведения», – самостоятельное, отчуждаемое произведение, представляющее собой публикацию текста программы или программ на языке программирования или в виде исполняемого кода;

 

2) согласно ГОСТ 28806–90 «Качество программных средств. Термины и определения», – программное средство, предназначенное для поставки, передачи, продажи пользователю.

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

 

Программные продукты могут создаваться как:

– индивидуальная разработка под заказ;

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

 

Классификация ПО

По степени тиражируемости всё программное обеспечение делится на три категории:

· программное обеспечение, разрабатываемое на заказ;

· программное обеспечение для крупных корпораций и организаций;

· программное обеспечение для массового потребителя.

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

Моделирование данных

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

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

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

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

Связь (Relationship) – поименованная ассоциация между двумя сущностями, значимая для рассматриваемой предметной области. Связь – это ассоциация между сущностями, при которой, как правило, каждый экземпляр одной сущности, называемой родительской сущностью, ассоциирован с произвольным (в том числе нулевым) количеством экземпляров второй сущности, называемой сущностью–потомком, а каждый экземпляр сущности–потомка ассоциирован в точности с одним экземпляром сущности–родителя. Таким образом, экземпляр сущности–потомка может существовать только при существовании сущности родителя.

Степень связи и обязательность графически изображаются следующим образом.

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

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

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

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

Модель данных по методологии SADT:

Методология IDEF1X

В настоящее время на основе совершенствования методологии IDEF1 создана ее новая версия – методология IDEF1X. IDEF1X разработана с учетом таких требований, как простота изучения и возможность автоматизации. IDEF1X–диаграммы используются рядом распространенных CASE–средств (в частности, ERwin, Design/IDEF).

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

Каждой сущности присваивается уникальное имя и номер, разделяемые косой чертой "/" и помещаемые над блоком.

Связь может дополнительно определяться с помощью указания степени или мощности (количества экземпляров сущности–потомка, которое может существовать для каждого экземпляра сущности–родителя). В IDEF1X могут быть выражены следующие мощности связей:

Идентифицирующая связь между сущностью–родителем и сущностью–потомком изображается сплошной линией.

Пунктирная линия изображает неидентифицируемую связь.

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

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

Документирование ПО

Когда программист-разработчик получает в той или иной форме задание на программирование, перед ним, перед руководителем проекта и перед всей проектной группой встают вопросы:

· что должно быть сделано, кроме собственно программы?

· что и как должно быть оформлено в виде документации?

· что передавать пользователям, а что службе сопровождения?

· как управлять всем этим процессом?

· что должно входить в само задание на программирование?

Кроме упомянутых вопросов есть и другие.

На эти и массу других вопросов когда-то отвечали государственные стандарты на программную документацию комплекс стандартов 19-й серии ГОСТ ЕСПД. Но уже тогда у программистов была масса претензий к этим стандартам. Что-то требовалось дублировать в документации много раз (как, казалось — неоправданно), а многое не было предусмотрено, как, например, отражение специфики документирования программ, работающих с интегрированной базой данных.

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

 

ГОСТ (СТ СЭВ) 19.101-77 (1626-79). ЕСПД. Виды программ и программных документов.

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

· Виды программ

· Виды программных документов

· Виды эксплуатационных документов

· Виды программных документов, разрабатываемых на разных стадиях, и их коды

3) ГОСТ 19.102-77. ЕСПД. Стадии разработки.

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

· Те