Техническое проектирование [preliminary design ] – Стадия работ по проектированию АС, которая включает:

· Разработку проектных решений по системе и её частям;

· Разработку документации на АС и её части;

· Разработку и оформление документации на поставку изделий для комплектования АС и/или технических требований (технических заданий) на их разработку;

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

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

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

Структура диаграммы Деятельности похожа на диаграмму Состояний (см. ниже). Рассмотрим пример диаграммы Деятельности (см. рис. 1.10), где деятельности показаны скругленными прямоугольниками. Это шаги, пред­принимаемые в рамках определенных рабочих потоков. Квадратами отмече­ны объекты, влияющие на исполнение рабочего потока. Указаны исходное (начальное) и конечное состояния рабочего потока. Ромбами отмечены точ­ки, в которых принимаются решения.

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

транзакции, введя условия для начала/отсутствия транзакции, а также ука­зать действия, предпринимаемые в рамках определенной транзакции.

Диаграммы Деятельности могут разделяться вертикальными линиями — "плавательными дорожками" (swimline). В пределах каждой такой дорожки действует определенная роль рабочего потока. Анализируя активности в пре­делах одной дорожки, можно определить ответственность роли. Отслежива­ние транзакций между активностями на разных дорожках позволит определить коммуникации между ролями. Все это крайне важно для понима­ния и моделирования бизнес-процессов.

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

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

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

На рис. изображена одна из диаграмм Компонентов для системы ATM.

Рис.6 Диаграмма Компонентов для клиента ATM

На этой диаграмме показаны компоненты клиента системы ATM. В данном случае команда разработчиков решила строить систему с помощью языка C++. У каждого класса имеется свой собственный заголовочный файл и файл с расширением . СРР, так что каждый класс преобразуется в свои собствен­ные компоненты на диаграмме. Например, класс ATM Screen преобразуется в два компонента ATM Screen диаграммы. Вместе эти компоненты представляют тело и заголовок класса ATM Screen. Выделенный темным компонент называется спецификацией пакета (package specification) и соответствует файлу тела класса ATM Screen на языке C++ (файл с расширением .СРР). Невыделенный компонент также называется спецификацией пакета, но соответствует заголовочному файлу класса языка C++ (файл с расширением . Н). Компонент АТМ.ехе является спецификацией задачи и представляет поток обработки информации (thread of processing). В данном случае поток обработки — это исполняемая программа.

Компоненты соединены штриховой линией, отображающей зависимости между ними. Например, класс Card Reader зависит от класса ATM Screen. Следовательно, для того чтобы класс Card Reader мог быть скомпилирован, класс ATM Screen должен уже существовать. После компиляции всех клас­сов может быть создан исполняемый файл ATMClient.exe.

Пример ATM содержит два потока обработки, и таким образом получаются два исполняемых файла. Один из них — это клиент ATM, он содержит компоненты Cash Dispenser, Card Reader и ATM Screen. Второй файл — сервер ATM, включающий в себя компонент Account. Диаграмма Компонен­тов для сервера ATM показана на рис.

Рис.7 Диаграмма Компонентов для сервера ATM

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

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

57. Объектно - ориентированное проектирование на стадии реализации программного обеспечения (кодирование и использование диаграмм размещения).

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

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

Диаграммы Размещения