Шпаргалка по "Программированию и компьютерам"

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

 

                                                                                                         

 
 
 

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

 Компонентами  модели являются

 -диаграммы

 -словари  данных

 -спецификации  процессов

 Для изображения DFD традиционно используются две  различные нотации: Йодана (Yourdon) и Гейна-Сарсона (Gane-Sarson).

 

                                             Йодана                      Гейна-Сарсона

 

 поток                                  имя                                 номер

 данных                          

 

    процесс                            имя                                 имя             

                                           номер                                

 
 

 внешняя сущность     

                                              имя                                 имя            

 

                           

   хранилище                        имя                                         имя

 
 

 Основные  символы        

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

 

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

 Процесс. Назначение процесса состоит в продуцировании выходных потоков из входных в соответствии с действием, задаваемым именем процесса. Это имя должно содержать глагол в неопределенной форме с последующим дополнением (например, ВЫЧИСЛИТЬ,ПРОВЕРИТЬ, СОЗДАТЬ, ПОЛУЧИТЬ). Использование таких глаголов как ОТРАБОТАТЬ, МОДЕРНИЗИРОВАТЬ и др. означает, как правило, недостаточно глубокое понимание процесса и требует дальнейшего анализа.  Кроме того, каждый процесс должен иметь уникальный номер для ссылок на него внутри диаграммы. Этот номер может использоваться совместно с номером диаграммы для получения уникального индекса процесса во всей модели.

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

     Хранилище (накопитель) данных позволяет на определенных участках определять данные, которые будут сохраняться в памяти между процессами. Фактически хранилище представляет "срезы" потоков данных во времени. Информация, которую оно содержит, может использоваться в любое время после ее определения, при этом данные могут выбираться в любом порядке. Имя хранилища должно идентифицировать его содержимое и быть существительным. В случае, когда поток данных входит или выходит в/из хранилища, и его структура соответствует структуре хранилища, он должен иметь то же самое имя, которое нет необходимости отражать на диаграмме.

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

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

 4. ОБъектно-ориентированный  подход к проектированию. Состав описания  архитектуры системы  на языке UML.

 

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

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

 Блоки UML:

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

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

 Интерфейс (Interface) - это совокупность операций, которые определяют сервис (набор  услуг), предоставляемый классом  или компонентом. Таким образом, интерфейс описывает видимое  извне поведение элемента. Графически интерфейс изображается в виде круга, под которым пишется его имя.

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

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

 Зависимость (Dependency) - это семантическое отношение  между двумя сущностями, при котором  изменение одной из них, независимой, может повлиять на семантику другой, зависимой. Графически зависимость изображается в виде прямой пунктирной линии, часто со стрелкой, которая может содержать метку.

 Ассоциация (Association) - структурное отношение, описывающее  совокупность связей; связь - это соединение между объектами. Разновидностью ассоциации является агрегирование (Aggregation) - так называют структурное отношение между целым и его частями. Графически ассоциация изображается в виде прямой линии (иногда завершающейся стрелкой или содержащей метку), рядом с которой могут присутствовать дополнительные обозначения, например кратность и имена ролей.

 Обобщение (Generalization) - это отношение "специализация/обобщение", при котором объект специализированного  элемента (потомок) может быть подставлен вместо объекта обобщенного элемента (родителя или предка). Таким образом, потомок (Child) наследует структуру и поведение своего родителя (Parent). Графически отношение обобщения изображается в виде линии с незакрашенной стрелкой, указывающей на родителя.

 Диаграммы UML:

 1) Use case diagram (диаграммы прецедентов)

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

 Каждая  такая диаграмма или, как ее обычно называют, каждый Use case – это описание сценария поведения, которому следуют  действующие лица (Actors).

 

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

 2) Deployment diagram (диаграммы топологии)

 Этот вид  диаграмм предназначен для анализа аппаратной части системы, то есть «железа», а не программ. В прямом переводе с английского Deployment означает «развертывание», но термин «топология» точнее отражает сущность этого типа диаграмм.

 Для каждой модели создается только одна такая  диаграмма, отображающая процессоры (Processor), устройства (Device) и их соединения.

 

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

 3) State Maсhine diagram (диаграммы состояний)

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

 

 Диаграмма состояний (Statechart) предназначена для  отображения состояний объектов системы, имеющих сложную модель поведения. Это одна из двух диаграмм State Machine, доступ к которой осуществляется из одного пункта меню.

 4) Activity diagram (диаграммы активности)

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

 

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

 5) Sequence diagram (диаграммы последовательностей  действий)

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

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

 

 Этот тип диаграммы не акцентирует внимание на конкретном взаимодействии, главный акцент уделяется последовательности приема/передачи сообщений. Для того чтобы окинуть взглядом все взаимосвязи объектов, служит Collaboration diagram.

 6) Class diagram (диаграммы классов)

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

 Значки  диаграммы позволяют отображать сложную иерархию систем, взаимосвязи  классов (Classes) и интерфейсов (Interfaces). Данный тип диаграмм противоположен по содержанию диаграмме Collaboration, на которомотображаются объекты системы. Rational Rose позволяет создавать классы при помощи данного типа диаграмм в различных нотациях. В нотации, предложенной Г. Бучем, которая так и называется Booch, классы изображаются в виде чего-то нечеткого, похожего на облако. Таким образом Г.Буч пытается показать, что класс – это лишь шаблон, по которому в дальнейшем будет создан конкретный объект.