Buscar

25227_23296_Projeto-UML

Prévia do material em texto

Projeto de Software - Motivação 
• Momento em que os requisitos são analisados 
para produzir uma descrição da estrutura interna 
do software 
• Estrutura servirá como base para a construção do 
software 
• Durante essa fase são construídos vários modelos 
Planta de uma casa 
Planta elétrica – abstração de outros 
elementos 
Projeto de Software 
O processo inicial de projeto de software que consiste em 
identificar subsistemas ou módulos é chamado de projeto de 
arquitetura. 
 
• A saída desse processo de projeto é uma descrição da 
arquitetura do software. 
 
 
 
 
Paradigmas de Análise 
•Análise Estruturada 
•DFD, MER 
•Análise Orientada a Objetos 
•Diagrama de UML 
•etc 
Análise Estruturada 
•Elementos 
oObjetos de Dados 
� É a representação de qualquer informação que pode ser 
processada 
oAtributos 
� Descrevem as características dos objetos de dados 
oRelações 
�Maneira de conexão entre os objetos de dados 
Análise Estruturada Centrada nos Dados 
(adaptação: Pressman, 5a. Ed) 
Dados 
Modelagem 
Funcional: 
 
IDEF0, Caso 
de Uso, DFD, 
... 
Modelagem de 
Dados: 
 
DER 
Modelagem 
Comportamental: 
 
Diagrama de Estado 
Representação Tabular de Objetos de 
Dados 
Fulano Azul Sedan Abc1234 Escort Fort 
Proprietário Cor Tipo Placa Modelo Marca 
Análise Orientada a Objetos 
•Conceitos: 
oencapsulamento, 
oherança, 
opolimorfismo, 
oagregação, 
oetc 
 
Projeto de Software 
• A arquitetura de software dá a direção dos passos que serão 
tomados e as tarefas envolvidas em cada área de 
especialidade e interesse do usuário. 
 
• O modelo de projeto fornece detalhes sobre estrutura de 
dados, arquitetura, interfaces e componentes do software 
necessários para implementar o software 
 
 
 
Conceitos de Projetos 
• Abstração 
• Refinamento 
• Modularidade 
• Refabricação 
• Coesão 
• Acoplamento 
Conceitos de Projeto 
• Abstração 
o Para uma solução modular muitos níveis de abstração 
podem ser levantados. Pode ser de alto nível ou baixo 
nível, além de procedural ou de dados 
 
o Abstração é indispensável no projeto de software, 
principalmente os de grande porte, sendo essencial 
para o particionamento dos problemas - divisão dos 
sistemas em componentes (módulos). 
 
Conceitos de Projeto 
• Modularidade 
o O software é dividido em componentes que são integrados para 
formar o sistema 
 
• A modularidade tenta atingir três metas: 
o capacidade de decompor um sistema complexo ou de grande porte; 
o capacidade de compor um sistema a partir de um conjunto de 
módulos; 
o facilitar a compreensão de sistemas complexos. 
 
ߛ arquitetura possui modularidade 
 
 
Conceitos de Projeto 
• Refinamento 
o O refinamento é a elaboração sucessiva de níveis de detalhes 
procedimentais 
• Refabricação 
o Os modelos de projeto (ou código) são refeitos, sem 
mudar o seu funcionamento, mas melhora a estrutura 
interna 
Custo de Modularidade x Integração 
• Se o custo de resolver dois problemas juntos for 
maior do que resolvê-los separadamente, implica 
em modularizar o código ao máximo 
� ߛ “dividir para conquistar” 
• Porém, existe um custo de integração. 
 
ߛ Assim, existe uma região de custo mínimo para o 
número de módulos de um software 
Independência Funcional 
• Coesão 
o Um módulo é coeso se realiza uma única tarefa 
• Acoplamento 
o É uma medida de interconexão entre módulos 
 
• Independência Funcional 
o É conseguida através de 
 ↑ alta coesão e 
 ↓ baixo acoplamento 
 
deve conduzir a uma definição em módulos com alto grau de 
independência, como forma de facilitar as tarefas de manutenção ao 
longo da vida do software; 
 
Modelos e Diagramas 
 Modelo é uma representação, em pequena escala, do sistema sob 
uma determinada perspectiva (abstração). 
 
 
 Os Diagramas expressam as visões de um Modelo. 
 
– Diagramas estruturais 
– Diagramas comportamentais 
– Diagramas de interação 
UML 
Unificada Linguagem de Modelagem Unificada 
UML 
Unificada Linguagem de Modelagem Unificada 
• Linguagem visual para especificação 
Linguagem(modelagem) de sistemas orientados a objetos 
• Fornece representação gráfica para os elementos essenciais 
do paradigma de orientação a objetos 
• Classes, atributos, objetos, troca de mensagens, ... 
UML 
Unificada Linguagem de Modelagem Unificada 
• Padrão OMG – Object Management Group 
• Toda a documentação disponível em http://www.omg.org 
• Privilegia a descrição de um sistema segundo três perspectivas: 
– Dados (estrutural) 
• Diagrama de Classes 
– Operações (funcional) 
• Diagrama de Caso de Uso 
– Eventos (temporal) 
• Diagramas de Seqüência, Atividades, de Transição de Estados 
Objetivo da UML 
• O objetivo da UML é fornecer múltiplas visões 
do sistema que se deseja modelar 
 
• Estas várias visões são representadas pelos 
Diagramas UML 
 
• Cada diagrama modela o sistemas sob um 
determinado aspecto, sendo possível ter enfoques 
mais gerais (visão externa) do sistema ou mais 
específicos (visão interna) 
UML 
• UML não é uma linguagem de programação e 
também não é uma metodologia de 
desenvolvimento 
 
• É uma linguagem de modelagem utilizada para 
representar o sistema de software principalmente 
nas etapas de Análise e Projeto 
 
UML 
• Auxilia na definição de características do 
sistema: 
 
• Requisitos 
• Estrutura lógica 
• Comportamento 
• Dinâmica de processos 
• Comunicação/Interface com os usuários 
• Etc. 
• A escolha de quais diagramas utilizar depende do 
tamanho, tipo de aplicação e complexidade dos 
projetos a serem desenvolvidos. 
A aplicação da UML 
Síntese Geral dos Diagramas UML 
Diagrama de 
Comunicação 
Diagrama de 
Tempo 
Diagrama 
Diagrama Estrutural Diagrama Comportamental 
Diagrama de 
Classes 
Diagrama de 
Objetos 
Diagrama de 
Implantação 
Diagrama de 
Caso de Uso 
Diagrama de 
Atividades 
Diagrama de 
Máquina de Estados 
Diagrama de 
Estrutura Composta 
Diagrama de 
Componentes 
Diagrama de 
Pacotes 
Diagrama de Interação 
Diagrama de 
Seqüência 
Diagrama Geral 
de Interação 
UML - Unified Modeling Language 
• Diagramas Estruturais 
 Ilustram as características estáticas de um modelo, incluindo classes, 
associações, objetos, links e colaborações. 
 
 Mostram as partes que compõem o modelo e como elas se relacionam, sem 
mostrar, porém, o como elas se comportam. 
 
 Provêem os itens sobre os quais os elementos dinâmicos do modelo irão 
atuar. 
 
Exemplos: diagrama de classes, pacotes, implantação, componentes 
UML - Unified Modeling Language 
• Diagramas Comportamentais 
 Descrevem os comportamentos dos itens modelados nos diagramas estruturais, 
em termos de estados, atividades e funcionalidades que eles devem prover. 
Exemplos: Diagrama de casos de uso, atividades, estados 
 
• Diagramas de Interação 
 Descrevem como os itens modelados nos diagramas estruturais se interagem 
para prover uma determinada funcionalidade. 
Exemplo: diagrama de sequencia 
Síntese Geral dos Diagramas UML 
Diagrama de 
Comunicação 
Diagrama de 
Tempo 
Diagrama 
Diagrama Estrutural Diagrama Comportamental 
Diagrama de 
Classes 
Diagrama de 
Objetos 
Diagrama de 
Implantação 
Diagrama de 
Caso de Uso 
Diagrama de 
Atividades 
Diagrama de 
Máquina de Estados 
Diagrama de 
Estrutura Composta 
Diagrama de 
Componentes 
Diagrama de 
Pacotes 
Diagrama de Interação 
Diagrama de 
Seqüência 
Diagrama Geral 
de Interação 
Diagramas Estruturais• Diagrama de Classes: Classes 
 São os elementos base do diagrama de classes. 
 
 Incluem informações que descrevem as características de uma entidade e como 
elas podem ser utilizadas. 
 
 Descrevem o TIPO de um objeto, com seus atributos e métodos. 
Diagramas Estruturais 
• Diagrama de Classes: Classes 
 Possuem três compartimentos por padrão: 
– Nome 
– Atributos 
– Operações 
 
 
 
 
Atributos da classe 
Operações da classe 
Nome da classe 
Diagramas Estruturais 
• Diagrama de Classes: Relacionamento - Multiplicidade 
 Uma associação pode definir o número de elementos que podem fazer parte do 
relacionamento. 
 
 
 
 
 Quando não especificada, a MULTIPLICIDADE do relacionamento equivale a 
1. 
* indefinida 
n..m intervalos 
n exata 
Representação Multiplicidade 
UML - Unified Modeling Language 
• Para que serve? 
 Modelar visualmente um sistema ANTES da sua implementação. 
 
 Permite representar sistemas de software sob diversas perspectivas de 
visualização por meio de seus diagramas. 
 
 Suporta todo o ciclo de vida do software: 
– Modelagem do negócio (processos, objetos) 
– Modelagem de requisitos alocados 
– Modelagem da solução 
 
 
 
Diagramas Estruturais 
• Diagrama de Objetos: Objeto 
 São instâncias de classes. 
 
 Demonstram o estado (valores dos atributos) de uma instância em um 
determinado instante de tempo. 
Nome do objeto Classe do objeto 
Nome e valor 
dos atributos 
Diagramas Estruturais 
• Diagrama de Pacotes 
 Descrevem os pacotes ou pedaços do sistema divididos em agrupamentos lógicos, 
mostrando as suas dependências. 
 
 
 Podem ser utilizados para: 
– Modelar a estrutura lógica do sistema 
– Descrever as divisões de responsabilidades dos componentes do sistema 
Diagramas Estruturais • Pode agrupar: 
– Classes; 
– Componentes; 
– Casos de uso; 
– Nós. 
 
• Representa um agrupamento lógico entre os 
elementos pertencentes à este pacote 
 
Diagramas Estruturais 
• Diagrama de Pacotes: Pacote 
 Mecanismo de propósito geral para 
organizar elementos semanticamente 
relacionados em grupos. 
 
 Representam um grupo de classes 
(ou outros elementos) e as suas 
dependências, que se relacionam 
de uma forma lógica. 
Diagramas Estruturais 
• Diagrama de Pacotes: Pacote 
 
 Formam um espaço de nome. (package, namespace, …) 
 
 
 
 
 
 
 
 
 
Cada elemento do modelo pode pertencer a um único pacote, e o seu nome dentro do 
pacote deve ser único. 
Subsistemas da 
estação 
meteorológica 
Diagramas Estruturais 
Diagramas Estruturais 
• Diagrama de Componentes: Componentes 
 É uma parte física e substituível de um sistema, que proporciona a realização 
(implementação) de um conjunto de interfaces. 
 
 São a implementação na arquitetura física dos conceitos e funcionalidades 
definidos na arquitetura lógica (classes, objetos e seus relacionamentos). 
 
 Representa um empacotamento físico de elementos relacionados logicamente 
(normalmente classes). 
 
 São tipicamente os arquivos implementados no ambiente de desenvolvimento. 
Diagramas Estruturais 
• Diagrama de Componentes 
Diagramas Estruturais 
• Diagrama de Implantação ou Distribuição (deployment) 
 Descrevem a arquitetura física do hardware do sistema sobre o qual serão 
executados os componentes de software. 
 
 Mostram os computadores e periféricos, juntamente com as conexões que 
estabelecem entre si, bem como os componentes de software que são executados 
neles. 
 
 Podem ser utilizados para: 
– Especificar a distribuição de componentes 
– Descrever fisicamente a topologia do sistema 
 
Diagramas Estruturais 
• Diagrama de 
Implantação ou 
Distribuição: 
Elementos 
 
– Nós (nodes): representam 
um elemento físico capaz de 
oferecer recursos 
computacionais 
 
– Conexões: especificam a 
forma de comunicação entre 
os nós 
 
– Componentes: são os 
“pedaços” de software que 
são executados para 
disponibilizar as 
funcionalidades providas 
pelo nó. 
Node 
Conexão 
(protocolo: opcional) 
Componente 
Diagramas Comportamentais 
• Diagrama de Casos de Uso: Elementos (já vimos na fase de 
Requisitos) 
– Atores 
– Casos de Uso 
– Relacionamentos 
Diagramas Comportamentais 
• Diagrama de Casos de Uso: Relacionamentos 
 O relacionamento de inclusão indica que um caso de uso incorpora 
explicitamente o comportamento de outro caso de uso em um ponto específico, 
sendo executado como parte do caso de uso que o inclui. 
 
 Pode ser utilizado quando existe um serviço, situação ou rotina comum a mais de 
um caso de uso. 
 
 Representado pelo estereótipo <<include>> e pela seta tracejada que vai até 
o caso de uso incluído. 
Diagramas Comportamentais 
• Diagrama de Casos de Uso: Relacionamentos 
 O relacionamento de extensão indica que um caso de uso pode incorporar 
implicitamente o comportamento de outro caso de uso em um ponto específico, 
sendo executado nos casos em que determinadas condições forem satisfeitas. 
 
 Pode ser utilizado para modelar a parte do caso de uso que o usuário considera 
como sendo um comportamento condicional do sistema. 
 
 Representado pelo estereótipo <<extend>> e pela seta tracejada que sai do 
caso de uso estendido. 
Diagramas Comportamentais 
• Diagrama de Atividades 
 
• Descrevem as atividades que afetam o estado do sistema e os fluxos e ações que 
levam de uma atividade a outra. 
 
 Mostram o fluxo sequencial das atividades executadas por uma operação 
específica do sistema, seus pontos de decisão e as mensagens enviadas e 
recebidas como parte das ações executadas. 
 
 Podem ser utilizados para: 
– Modelar fluxos de trabalho (workflows) e processos de negócio 
– Descrever casos de uso 
– Descrever a implementação de métodos/funções complexas 
Diagramas Comportamentais 
• Diagrama de Atividades: Elementos 
– Atividade 
– Pontos de Decisão (decision) 
– Pontos de Junção (join) 
– Nós de Início e Fim 
– Raias (Swimlanes) 
Diagramas Comportamentais 
• Diagrama de Atividades: Raias 
 São regiões, dentro do diagrama, associadas à objetos do modelo que indicam quais as 
atividades relativas a cada um dos objetos envolvidos. 
Diagramas de Interação 
• Diagrama de Seqüência 
 Descrevem a interação dinâmica entre vários objetos do sistema em um 
determinado contexto (caso de uso, operação, etc). 
 
 Modelam a troca de mensagens entre os objetos e a seqüência em que elas 
ocorrem, destacando a ordem de atuação e o papel de cada objeto dentro do 
fluxo de execução de uma determinada funcionalidade. 
 
 Podem ser utilizados para: 
– Descrever uma seqüência particular de funcionamento de uma determinada 
funcionalidade 
– Enfatizar a comunicação e a passagem de controle entre os objetos ao longo 
do tempo 
– Extrair e refinar as operações dos objetos 
Diagramas de Interação 
• Diagrama de Seqüência 
Objeto 
[nome : tipo] 
Mensagem de 
criação 
Mensagem de 
destruição 
Mensagem 
auto-referência 
Fragmento Mensagem de retorno 
Linha de vida 
Mensagem 
(síncrona) 
Exemplo e Diagrama de Sequência – 
 Solicitação de Serviço 
Primeiro Cenário 
Tela 
Chamada 
Solicitação 
De 
Chamada 
Cliente CEP 
Tipo 
De 
Serviço 
Chamado 
Ordem 
De 
Serviço 
CPF 
Solicitação 
serviço Valida Cliente 
OK 
CPF OK 
Envia CEP 
Valida CEP 
OK 
CEP OK 
Descrição 
Seleciona Tipos de Serviço 
Retorna os tipos de serviço Mostra T.S 
Escolheserviço Grava chamado 
Grava ordem de Serviço 
Mostra 
N. protocolo 
Diagramas Comportamentais 
• Diagrama de Máquina de Estados 
 Especificam máquinas de estados enfatizando o comportamento interno de um 
objeto de acordo com os eventos externos recebidos. 
 
 Modelam as ações que disparam as transições de estado bem como as atividades 
realizadas em resposta a tais eventos, além de demonstrar todos os estados 
possíveis que um objeto pode ter. 
 
 Podem ser utilizados para: 
– Modelar o ciclo de vida de objetos e sistemas 
– Extrair operações do objeto 
Diagramas de estado 
• Modelam o comportamento do sistema em resposta aos 
eventos externos e internos. 
 
• Mostram as respostas do sistema aos estímulos e, assim, 
são freqüentemente usados para modelagem de sistemas 
de tempo real. 
 
• Quando um evento ocorre, o sistema muda de um estado 
para um outro. 
 
Diagramas Comportamentais 
Diagramas Comportamentais 
• Diagrama de Máquina de Estados 
Estado 
Evento interno 
Atividade 
Evento externo 
Arquitetura de Software 
• A arquitetura de software serve como uma 
estrutura que permite o entendimento de 
componentes de um sistema e seus inter-
relacionamentos.. 
 
• Diferentes modelos de arquitetura podem ser 
produzidos durante o processo de projeto. 
 
• Cada modelo representa diferentes perspectivas 
na arquitetura 
Rastreabilidade entre os modelos 
� Os diagramas da UML são inter-relacionados porque descrevem o 
mesmo sistema 
� cada diagrama se refere a uma visão parcial do sistema 
� se integram para apresentar uma visão completa do sistema 
 
� A relação entre os diagramas deve ser garantida pelo Arquiteto 
 
• Pressman, Roger S. Engenharia de Software. 6.ed. - Rio de 
Janeiro: McGraw-Hill, 2006. 
• Sommerville, I. Engenharia de Software. 8.ed. – São Paulo : 
Addison-Wesley, 2007. 
• Kruchten, Philippe, Introdução ao RUP – Rational Unified 
Process – Rio de Janeiro: Editora Ciência Moderna, 2003 
• Booch, G.; Rumbaugh, J.E.; Jacobson, I. UML, guia do usuário. 
Rio de Janeiro: Campus, 2000 
• A. M. Silva Filho, Arquitetura de Software, Editora Campus, 
2002 
 
 
 
Bibliografia

Outros materiais

Materiais relacionados

Perguntas relacionadas

Perguntas Recentes