1 Вопрос. Функциональная схема программного продукта
Функциональная схема -- вид графической модели изделия. Их использование и построение позволяет наглядно отразить устройство функциональных (рабочих) изменений, описание которых оперирует любыми (в том числе и несущественными) микросхемами, БИС и СБИС. Поскольку функциональные схемы не имеют собственной системы условных обозначений, их построение допускает сочетание кинематических, электрических и алгоритмических обозначений (для таких схем более подходящим термином оказывается комбинированные схемы).
2 вопрос Пошаговая детализация при составлении ПП.
Пошаговая детализация представляет собой простой процесс, предполагающий первоначальное выражение логики модуля в терминах гипотетического (условного) языка очень высокого уровня с последующей детализацией каждого предложения в терминах языка более низкого уровня, до тех пор, пока, наконец, не будет достигнут уровень используемого языка программирования. Здесь уместно напомнить: чем меньше язык содержит деталей, тем более он высокого уровня. Можно считать языком самого высокого уровня обычную человеческую речь, а языком низкого уровня — машинный язык.
На протяжении всего процесса пошаговой детализации логика процесса выражается основными конструкциями структурного программирования.
Достоинство пошаговой детализации состоит в том, что она позволяет проектировщику упорядочить свои рассуждения. На каждом шаге мы имеем дело с элементарной задачей.
Нисходящее проектирование программы, когда первоначально программа рассматривается, как совокупность действий, каждое из которых затем детализируется и представляется как последовательность более простых и конкретных действий и т.д. Вплоть до отдельных операторов языка; такой подход позволяет реализовать наличие двух видов подпрограмм в языке – процедур и функций.
Первоначально продумывается общая структура алгоритма без детальной проработки отдельных его частей. Блоки требующие дальнейшей детализации, обозначаются пунктирной линией. Далее прорабатываются отдельные блоки, не детализированные на предыдущем шаге.
Таким образом, на каждом шаге разработки уточняется реализация фрагмента алгоритма (или программы), т.е. решается более простая задача. Полностью закончив детализацию всех блоков, получаем решение задачи в целом.
Если на каждом шаге детализации использовать принципы структурного программирования, то получается хорошая структурированная программа в целом.
При разработке алгоритмов обычно используют метод пошаговой детализации (поэтапно):
1. На первом этапе описываются решения поставленной перед программой задачи, выделяются подзадачи.
2. В последующих этапах описывается решение каждой подзадачи, выделяя при этом новые подзадачи. Так происходит до тех пор, пока решение подзадач не будет очевидным. Рекомендовано решение каждой задачи описывать при помощи 1 - 2 конструкций не более, чтобы более четко представлять структуру программы.
3. Вопрос. Цели и история создания унифицированного языка uml
Официально создание UML началось в октябре 1994 года. Первоначальной целью было объединение методов Буча и ОМТ/
Первая пробная версия 0.8 Унифицированного Метода (Unified Method), как его тогда называли, появилась в октябре 1995 года. Приблизительно в это же время в компанию Rational перешел Джекобсон, и проект UML был расширен с целью включить в него язык OOSE. В результате совместных усилий в июне 1996 года вышла версия 0.9 языка UML. Версия 1.0 языка появилась в результате совместных усилий компаний Digital Equipment Corporation, Hewlett Packard. Между январем и июнем 1997 года консорциум UML расширился, в него вошли практически все компании, откликнувшиеся на призыв OMG. Дальнейшая работа по развитию UML проводилась Группой по усовершенствованию (Revision Task Force, RTF) OMG под руководством Криса Кобрина. В июне 1998 года вышла версия UML 1.2, а осенью 1998 – UML 1.3.
4 Вопрос. Средства языка uml
Создатели UML представляют его как язык для определения, представления, проектирования и документирования программных систем, организационно-экономических систем, технических систем и других систем различной природы. UML содержит стандартный набор диаграмм и нотаций самых разнообразных видов. Стандарт UML версии 1.1, принятый OMG в 1997 г., предлагает следующий набор диаграмм для моделирования:
диаграммы вариантов использования (use case diagrams) – для моделирования бизнес-процессов организации и требований к создаваемой системе);
– диаграммы классов (class diagrams) – для моделирования статической структуры классов системы и связей между ними;
– диаграммы поведения системы (behavior diagrams):
· диаграммы взаимодействия (interaction diagrams):
¨ диаграммы последовательности (sequence diagrams) и
¨ кооперативные диаграммы (collaboration diagrams) – для моделирования процесса обмена сообщениями между объектами;
· диаграммы состояний (statechart diagrams)– для моделирования поведения объектов системы при переходе из одного состояния в другое;
· диаграммы деятельностей (activity diagrams) – для моделирования поведения системы в рамках различных вариантов использования, или моделирования деятельностей;
– диаграммы реализации (implementation diagrams):
· диаграммы компонентов (component diagrams) – для моделирования иерархии компонентов (подсистем) системы;
· диаграммы размещения (deployment diagrams) – для моделирования физической архитектуры системы.
5 Вопрос. Структура языка uml
Язык UML имеет сложную иерархическую структуру, показанную на Рис.3.2.
6 Вопрос. Краткий обзор диаграмм uml
Диаграмма классов UML представляет собой статическую структурную диаграмму, предназначенную для описания структуры системы, а также демонстрации атрибутов, методов и зависимостей между несколькими различными классами.
Диаграмма компонентов UML представляет собой полностью статическую структурную диаграмму. Предназначается она для того, чтобы продемонстрировать разбиение определенной программной системы на разнообразные структурные компоненты, а также связи между ними. Диаграмма компонентов UML в качестве таковых может использовать всевозможные модели, библиотеки, файлы, пакеты, исполняемые файлы и еще множество других элементов
Диаграмма деятельности UML отображает разложение определенной деятельности на несколько составных частей. В данном случае понятием «деятельность» называется спецификация определенного исполняемого поведения в виде параллельного, а также координированного последовательного выполнения различных подчиненных элементов – вложенных типов деятельности и различных действий, объединенных потоками, идущими от выходов определенного узла к входам другого.
Диаграмма последовательности UML демонстрирует взаимодействия между несколькими объектами, которые упорядочиваются в соответствии с временем их проявления. На такой диаграмме отображается упорядоченное во времени взаимодействие между несколькими объектами