UML - Unified Modeling Language

Prévia do material em texto

UMLUML
Rodrigo Leite Durães.
rodrigo_l_d@yahoo.com.br
O que é Análise de Software?
 UML:
 – É o estágio de um sistema que captura 
os requisitos e o domínio do problema, 
focalizando no que deve ser feito, não 
como faze-lo.
Objetivos da Análise de 
Software
 Análise de Software tem por objetivo analisar os requisitos 
previamente levantados, realizando refinamento e estruturação 
dos mesmos
_ Análise: decompor para obter entendimento
O que se deseja?
– Entendimento mais preciso dos requisitos
– Descrição dos requisitos fácil de manter e que ajuda a estruturar 
todo o sistema
_ incluindo arquitetura
Análise Orientada por Objetos
 Elementos básicos
– Objetos
 Entidades do domínio
 Outros itens importantes
– Classes
 Agrupamentos de objetos similares
 Atributos
 Métodos
Análise Orientada por Objetos 
–
Identificação das classesExemplo (Engenharia de Software, Fundamentos, Métodos e Padrões, 2a. Edição)
 1. O caixeiro faz a abertura da venda
 2. O caixeiro registra os itens vendidos, informando a identificação e 
quantidade do item
 3. O sistema totaliza a venda para o cliente da da mercearia
 4. O caixeiro encerra a venda
 5. O sistema emite o ticket de caixa para o cliente da mercearia
 6. O caixeiro registra a forma de pagamento
 7. O sistema faz a baixa no estoque das mercadorias vendidas
Análise Orientada por Objetos 
–
Identificação das classes Especificação das classes encontradas
– Definição clara e concisa
– Lista de responsabilidades (o que ela deve 
fazer)
– Lista de colaborações (com que outras 
classes ela interage)
– Regras ou restrições aplicáveis
– Possíveis exemplos.
Análise Orientada por Objetos 
–
Identificação das classes Item de Venda, exemplo:– Descrição
 Informação relativa a um item de venda
– Responsabilidades
 Comandar baixa no estoque
 Calcular impostos
 Imprimir linha de ticket na nota fiscal
– Colaborações
 Venda, Mercadoria
– Regras e restrições
 Cada item de venda corresponde a uma linha do ticket de caixa e na nota fiscal
 Todo item de venda deve corresponder a uma mercadoria no estoque
– Exemplos
 Seis cervejas Rottenbeer em lata
 Duas caixas de pregos número 2
Análise Orientada por Objetos 
–
Revisão da Análise Consiste em validar o modelo de análise. 
Consiste em:
– Percorrer os casos de uso, verificando se 
existem caminhos para realizar todas as 
operações necessárias.
– Verificar, para cada campo de saída requerido 
nas interfaces, se existe uma maneira de obter 
esse campo através de alguma colaboração 
entre as classes.
Análise de Software –
Sumário
 Modelagem de análise:
– Produz especificação mais precisa dos requisitos.
– Descrita utilizando a linguagem dos desenvolvedores, 
mais formalismo funcionamento interno do sistema.
 Estrutura os requisitos
– Facilita entendimento e manutenção.
 Primeiro esboço da modelagem de desenho
– Embora seja uma modelagem por si só
UML
– Estágio de um sistema que descreve 
como ele será implementado, em nível 
lógico superior ao do código.
O que é Desenho de 
Software?
 Atenção a nomenclatura
– Tradução de Software design
– Alguns autores traduzem como projeto 
de software
 Mas projeto é também a tradução de 
software project
Objetivos do Desenho de 
Software
 Adquirir um profundo entendimento das questões 
relacionadas aos requisitos não-funcionais
– linguagens de programação, reuso de componentes, 
sistemas operacionais, distribuição e concorrência, 
bancos de dados, interface do usuário, transações, etc.
 Ponto de partida apropriado para a implementação
– subsistemas, interfaces e classes.
 Decompor o trabalho de implementação em diversas 
partes gerenciáveis
– Nem sempre possível nos requisitos ou análise
Desenho de Software
 Capturar as principais interfaces entre subsistemas
– Útil para arquitetura e sincronismo do trabalho de 
diferentes equipes.
 Estar apto a visualizar e elaborar sobre desenho 
utilizando uma notação comum
 Criar abstração correta da implementação do sistema,
– implementação torna-se refinamento direto do desenho.
_ Resultado: modelagem de desenho
Desenho Orientado por 
Objetos –
Detalhamento dos casos de 
uso
 Resolver detalhes dos fluxos dos 
casos de uso de desenho, 
considerando os componentes reais 
das interfaces.
 Todos os fluxos alternativos devem ser 
detalhados, inclusive os de erro ou 
exceção.
Desenho Orientado por 
Objetos –
Desenho das Entidades Transformar as classes de entidade da modelagem de análise nas correspondentes da modelagem de desenho.
 Inclui-se também:
– Consideração de reutilização dessas classes
– Consideração de transformação dessas classes em 
componentes
– Decidir como serão representados os relacionamentos em 
caso de multiplicidades um para muitos
– Todos os detalhes que eram irrelevantes na análise,
 Ex: visibilidade das classes, navegabilidade dos 
relacionamentos.
Desenho Orientado por 
Objetos –
Desenho da Persistência Definição de estruturas externas de armazenamento persistente
 Problemas a resolver:
– Definição física das estruturas persistentes externas
 Esquema de um banco de dados.
 Realização de ponte entre o modelo de desenho orientado a 
objetos e paradigmas das estruturas de armazenamento 
(relacionais, por exemplo).
– Ponte feita pela camada de persistência,
 Pode ser reaproveitada em outros sistemas se bem desenhada.
 Pode ser reaproveitada de outros sistemas com camadas bem 
desenhadas.
Desenho Orientado por 
Objetos –
Realização dos casos de uso Determina como os objetos das classes de 
desenho colaborarão para realizar os casos de uso:
– As classes da camada de controle conterão o código que 
amarra essas colaborações
– Diagramas de interação são usados para descrever as 
colaborações.
– Classes utilitárias ajudam a abstrair aspectos comuns.
_ Diferente da realização da análise - serve para validar 
muitas das decisões tomadas nas atividades anteriores.
Desenho Orientado por 
Objetos –
Desenho das Liberações Determina como a construção do 
produto será dividida em liberações 
executáveis (releases). Divisão procura:
– Mitigar os maiores riscos
– Obter realimentação dos usuários a 
intervalos razoáveis
– Dividir as unidades de implementação 
entre as equipes de trabalho.
	Slide 1
	Slide 2
	Slide 3
	Slide 4
	Slide 5
	Slide 6
	Slide 7
	Slide 8
	Slide 9
	Slide 10
	Slide 11
	Slide 12
	Slide 13
	Slide 14
	Slide 15
	Slide 16
	Slide 17
	Slide 18