Leitura Prévia _ Tema 7

Prévia do material em texto

1 
 
Engenharia de Requisitos 
Tema 7 – Colaboração entre Objetos 
Regras e conceitos Básicos; Categorias e Tipos de Objetos: Objetos de Entidades, 
Objetos de Controle, Objetos de Fronteira; Visão dinâmica: Diagrama de 
Sequência; Notação da visão dinâmica no Diagrama de Sequência; Diagrama de 
Atividades. 
 
 
Objetos são “coisas” do mundo real que podem ser físicas( casa, espelho , limão, estrela, 
barco, loja, pessoas etc.), ou abstratas (soma, percentagem, senha, crédito, débito, total, 
troca, parcela, pedido, Kadiquê...) cada uma fará sentido lógico de acordo com a 
abstração na solução de um problema no contexto de produção de software. Para melhorar 
o entendimento os seres humanos agrupam essas “coisas” objeto em conjuntos com 
características comuns ou similares denominadas “Classes”. Classes são agrupamento de 
objetos com as mesmas características para atender a uma dada funcionalidade num 
sistema. A modelagem de Classes, como já vimos anteriormente, não é uma ação 
construída de uma só vez, trata-se de um processo de otimização sucessiva que vai 
evoluindo à medida em que o projeto do sistema vai sendo desenvolvido com as 
mudanças necessárias. Esse roteiro começou pela Introdução e avança aqui pelos 
Objetos - Responsabilidade e Colaboração; essa rota segue no mundo da tecnologia 
pelos caminhos à sua escolha: 
 
 
 
A realização das operações das classes que visa atender aos objetivos de um sistema é 
feita através da responsabilidade e colaboração entre objetos. Tudo em um sistema 
orientado a objetos é realizado por objetos. Objetos assumem a responsabilidade do 
controle, gerenciamento e movimentação de dados no sistema. Objetos trabalham juntos 
comunicando ou interagindo uns com os outros. Objetos - Tudo que existe no mundo 
2 
 
real e que pode ser utilizado numa abstração como elemento do contexto e do limite do 
projeto de sistema. 
 
 
Regras e conceitos Básicos 
 
O paradigma da Orientação a Objeto visualiza um Sistema de software como uma coleção 
de agentes interconectados, chamados objetos que se relacionam entre si. Cada objeto é 
responsável pela realização de tarefas específicas. É através da realização dessas tarefas 
em colaboração de objetos que uma funcionalidade de um sistema é executada. 
Responsabilidade é algo que o objeto conhece e executa individualmente ou requisita a 
colaboração de outro objeto para completa a execução. Nesse paradigma os objetos 
encapsulam tanto dados quanto comportamentos. Uma classe cumpre a sua 
responsabilidade através das informações que ela possui e daquelas que precisará do 
suporte de outras classes. Classes agrupam objetos afins, possuem atributos de Objetos 
que executam através de métodos, objetos que são instâncias das classes colaboram entre 
si para realização de tarefas do sistema para atender a necessidade do usuário: 
 
 
Esquematização Geral - Responsabilidade e Colaboração 
 
 
 
 
Categorias e Tipos de Objetos 
 
Os objetos são categorizados em geral em função de suas responsabilidades como: 
Entidades, Fronteira e Controle. 
 
Objetos de Entidades : Manipulam informações no domínio do negócio enfocam as 
funcionalidades do sistema. Por exemplo: Somar Valores do sistema; Calcular dados 
em colaboração; Criar e destruir dados na agregação etc. 
 
Objetos de Controle : Controlar a coordenação entre vários objetos em termos de 
execução e mudanças de status dessa execução para entre: Eventos e atores externos; 
Eventos e atores internos. Lógica da aplicação. 
 
3 
 
Objetos de Fronteira : Atender a troca de informações na interface com Usuários, 
outros Sistemas, Sensores, outros dispositivos, etc. Notificar informações geradas 
internamente no sistema aos atores externos (ex. comando de impressora). Notificar 
informações geradas internamente no sistema entre os objetos. 
 
 
Visão dinâmica: Diagrama de Sequência 
 
“Diagramas de Sequência: são um tipo de diagrama de interação cuja ênfase está na 
ordenação temporal das mensagens trocadas entre objetos” (FALBO, 2012, p.74). 
 
Um objeto de software é a abstração de uma representação de algo no mundo real para o 
domínio do sistema em estudo. A visão estática representa como os objetos estão 
definidos e dispostos em uma estrutura. Não diz como os objetos se comportam os 
colocados em interações e colaborações. Em contraste à visão dinâmica representa as 
interações dos objetos em um sistema. Os diagramas de Sequência compõem a visão 
dinâmica da Modelagem de Sistemas, pois revelam como os objetos interagem entre si 
em resposta às interações do ambiente. 
 
A visão dinâmica contém diagramas projetados especificamente para modelar objetos 
trabalham juntos. Representa como o sistema responde às ações dos usuários, como 
mantém a integridade interna, como os dados são movidos do armazenamento para a 
visualização do usuário, e como os objetos são criados e manipulados. 
 
Notação da visão dinâmica no Diagrama de Sequência 
 
Na visão Caso de Uso, modelamos, a partir das abstrações e cenários, as funcionalidades 
do sistema a ser desenvolvido. O Diagrama de Sequência descreve como o sistema deve 
se comportar quando essas funcionalidades interagem entre si. Um Cenário descreve 
como interagem as funcionalidades descritas no Caso de Uso e que fazem parte do 
domínio de um sistema projetado em estudo. Uma abstração desse Cenário inclui apenas 
dados e informações mais relevantes ao domínio do sistema em estudo. 
 
O Diagrama de Sequência detalha os objetos referidos de modo agrupados nas classes. 
portanto, Criar o diagrama de sequência é mais factível se já tiver concluído pelo menos 
um primeiro rascunho do modelo de caso de uso e o do diagrama de classes. Destes dois 
artefatos, é possível fazer conjuntos de interações (cenários) e de objetos candidatos 
para assumir a responsabilidade pelas execuções. Um objeto de software é uma abstração, 
ou uma representação de algo que faz sentido para o domínio do sistema no mundo real. 
Por exemplo, para atender um requisito de funcionalidade “Cadastrar Cliente”, no sistema 
de Entrega de Pizza, não há necessidade de saber a sua altura, peso, idade e as preferências 
musicais do cliente! É necessário obter os seus atributos que possuem as propriedades 
que descrevem o status de um objeto, tais como: como nome, número de telefone, 
endereço, e-mail, número de cartão de crédito, etc. Ou seja, todas os atributos necessários 
para atender aos requisitos da funcionalidade para cadastrá-lo. Finalmente, todos os 
diagramas de Sequência são modelados no nível do objeto, e NÃO no nível da classe. O 
diagrama de sequência usa três elementos fundamentais de notação: Objetos, mensagens 
/ estímulos e linha de vida do objeto. 
 
4 
 
Os objetos participantes são alinhados na parte superior do diagrama. Uma mensagem ou 
estímulo é geralmente é uma chamada representada por uma flecha. A linha sólida 
representa uma mensagem que requer uma resposta. As setas tracejadas são as respostas 
do objeto invocado, conforme cenário descrito no domínio do sistema. As mensagens 
trocadas são colocadas horizontalmente para as linhas do tempo em posição vertical 
relativa na ordem em que elas acontecem. 
 
 
 
Ao modelar as interações, busca-se encontrar as interfaces / operações que o objeto 
requer. As interações nos mostram como os objetos inter-relacionam entre si. Cada vez 
que um objeto interage com outro invoca uma interface e uma operação que representam 
as ações que o método da classe deve executar. 
 
Diagrama de Sequência – Cenário: Exemplo Compra eletrônica 
 
5 
 
 
 
Diagrama de Atividades 
Um diagrama de atividades é como um fluxograma, no sentido que focaliza o fluxo de 
controle de uma atividade para outra. Entretanto, ao contrário de um fluxograma tradicional, 
um diagrama de atividades mostra, além de fluxos sequenciais e ramificações de controle, 
fluxos concorrentes (BOOCH; RUMBAUGH; JACOBSON, 2006; BLAHA; 
RUMBAUGH, 2006). O propósito de um diagrama de atividades é mostraras etapas de um 
processo complexo e a sequência entre elas (BLAHA; RUMBAUGH, 2006). Diagramas de 
atividades são usados para representar processos, sendo utilizados tanto para modelar 
processos de negócio quanto para representar a realização de um caso de uso. Eles foram 
adicionados à UML relativamente tarde, adquirindo status de um tipo de diagramas. 
Um diagrama de atividades deve mostrar as atividades no contexto de um fluxo de eventos 
descrito em uma descrição de casos de uso. Cursos alternativos (de exceção ou variantes) 
devem ser mostrados no mesmo diagrama de atividades. A sequência de atividades em um 
diagrama de atividades deve estar consistente com a sequência de passos da descrição do 
caso de uso correspondente. 
Exemplo: Diagrama de Atividades 
 
No contexto da Engenharia de Requisitos, além dos diagramas anteriormente citados aqui 
e nos temas anteriores, merecem atenção também os diagramas de pacotes (FALBO, 
2012, p. . Na UML que não é objeto desse curso. O pacote é um mecanismo de propósito 
geral usado para organizar elementos de modelagem em grupos. Assim, um diagrama de 
pacotes mostra a decomposição de um modelo em unidades menores e suas dependências 
(BOOCH; RUMBAUGH; JACOBSON, 2006). 
 
 
 
 
 
 
6 
 
 
Referências Bibliográficas: 
 
 
BEZERRA, Eduardo. Princípios de Análise e Projeto de Sistemas com UML – 
Elsevier. 2006. 
 
BOOCH, G., RUMBAUGH, J., JACOBSON, I., UML Guia do Usuário, 2a edição, 
Elsevier. Editora, 2006. 
 
DENNIS, Alan, WIXOM, Barbara Haley; TEGARDEN, David. 4 th ed. System analysis 
Design & UML. An object-oriented approach. John Willey& Sons. 2012 
 
FALBO, Ricardo de Almeida. Engenharia de Requisitos. Notas de Aula. UFES - 
Universidade Federal do Espírito Santo. 2012. 
Disponível em: 
< http://www.inf.ufes.br/~falbo/files/ER/Notas_Aula_Engenharia_Requisitos.pdf > 
Acesso em 14-10-2019 
 
SOMMERVILLE, Ian. Engenharia de Software, 9th Edition. Pearson Brazil, 11/2015. 
VitalBook file. 
 
POHL, Klaus; RUPP Chris. Fundamentos da Engenharia de Requisitos - Um guia 
para o exame CPRE-FL em conformidade com o padrão IREB. 
• [4] IEEE Std 830 Prática Recomendada Para Especificações de Exigências de Software: 
Standard Internacional; por André Gonçalves, Fernando Martins, Paulo Carreira, Pedro 
Lopes, e Sérgio Nunes. Publicado Abril, 2004. Norma IEEE Std 830-1998 
Disponível em: 
<http://professor.pucgoias.edu.br/SiteDocente/admin/arquivosUpload/17785/material/E
ngenharia%20de%20Requisitos.pdf> Acesso 14-10-2019