Análise Orientada a Objetos

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

Clique para editar o estilo do título mestre
Clique para editar o estilo do subtítulo mestre
*
*
*
Análise Orientada a Objetos
Conceitos Básicos de OO
*
*
*
Por que OO?
Tecnologia para modelar domínios usando sua própria linguagem
Dificuldades dos paradigmas anteriores:
Separação entre dados e processos
Descontinuidade da Análise para o Projeto
*
*
*
Revolução X Evolução
	Fáceis de construir, expandir, modificar e validar
Conveniente para as linguagens atuais (OO)
Aceita e comprovadamente eficaz
*
*
*
Objeto
Abstração
Forma de captar conceitos
Algo que existe no mundo real (concreto ou não)
Necessitamos modelar para o sistema que será construído
*
*
*
Classe
Conjunto de objetos com as mesmas características
Todos os objetos de uma mesma classe possuem os mesmos atributos, operações e relacionamentos
Um molde para criação de objetos
*
*
*
Atributos
Propriedade de uma classe
Descreve uma faixa de valores
Uma classe pode ter qualquer número de atributos, inclusive zero
*
*
*
Operações (Métodos)
Serviços que uma classe possui
Provêem comportamento ao objeto
Uma classe pode ter várias ou nenhuma operação
*
*
*
Encapsulamento
Separa a interface da implementação
Incentiva o baixo acoplamento
Reduz o esforço para a modificação
Permite a modificação confiável de programas
MODULARIDADE
*
*
*
Herança
Classe recebe atributos e comportamentos de outra
Super-classe
Sub-classe
Normalmente a sub classe modifica ou expande a classe. É raro utilizar a redução
Classe Concreta X Abstrata
*
*
*
Polimorfismo
Teoria de Tipos / Classe / Tipo
A propriedade que permite que um nome possa significar instâncias de muitas classes, desde que essas sejam relacionadas por uma super-classe. 
“Qualquer objeto representado por tal nome é capaz de responder a um conjunto de operações de forma distinta. “ – Booch –
*
*
*
Persistência
A existência de um objeto pode persistir ao tempo
Na prática, isso significa que o objeto terá que ser armazenado de alguma forma
*
*
*
Associação
Conexão física ou lógica entre objetos
Equivale ao conceito de relacionamento
*
*
*
Agregação
É um tipo específico de associação
Relacionamento PARTE/TODO
Cria uma restrição de integridade na associação
Esconde as partes dentro do todo
Aumenta o acoplamento
*
*
*
Composição
Também é uma associação
É uma agregação
Impõe uma restrição de integridade ainda mais severa a associação/agregação
Introduz o conceito de vidas coincidentes!!!
*
*
*
Agregação, composição e associação
Composição: um trem é formado por locomotiva e vagões
Agregação: uma locomotiva tem um farol (mas não vai deixar de ser uma locomotiva se não o tiver)
Associação: um trem usa uma estrada de ferro (não faz parte do trem, mas ele depende dela)
*
*
*
Análise Orientada a Objetos 
Metodologias
*
*
*
Metodologias OO
Booch
OMT
OOSE
Fusion
Coad/Yourdon
*
*
*
Booch
Várias versões
Sistema analisado por visões
Vários diagramas por visão
Notação extensa e complicada
Macro e Micro visões do sistema
*
*
*
OMT 
General Eletric – James Rumbaugh
Processo e notação simples
Metodologia mais utilizada para SI
Dicas de projeto, como modelagem de concorrência em sistemas e arquitetura 
*
*
*
OOSE/Objectory
Ivar Jacobson
Baseadas em Use Cases (Casos de Uso)
Use-Cases acompanham todo o ciclo de desenvolvimento
Também usado para Reengenharia de Processos de Negócio
*
*
*
Fusion
Hewlett-Packard
Considerando um método da segunda geração
Melhorou várias idéias das metodologias da primeira Geração
Utiliza um grande número de modelos
*
*
*
Coad/Yourdon – OOA/OOD
Pioneiro
Simples e fácil de aprender
Bom para a introdução da OO
Muito limitado, só suportando o desenvolvimento de sistemas simples e pequenos
*
*
*
Análise Orientada a Objetos
UML
*
*
*
A Linguagem de Modelagem Unificada 
– UML – 
Booch, Rambaugh e Jacobson
Linguagem, não método
Baseada principalmente na OMT, Booch e OOSE
Inclui conceitos de diversas metodologisas, inclusive Padrões de Projeto (Design Patterns)
Padrão OMG (Nov. 1997)
*
*
*
UML – Objetivos
Modelagem de sistemas utilizando conceitos de OO (não software também)
Estabelecer uma associação explícita entre o conceitual e a implementação
Permitir a escalabilidade inerente a sistemas complexos e críticos para a missão
Ser utilizável por homem e máquina
*
*
*
UML – Propósitos 
Prover uma linguagem de modelagem visual potente e significativa, que represente os conceitos básicos de modelagem aceitos por vários métodos e ferramentas
Prover mecanismos de extensão e especialização que permitam a ampliação de conceitos básicos
Ser independente de linguagem de programação e de processo de desenvolvimento
Prover uma base formal para entendimento da linguagem de modelagem
Incentivar mercado de ferramentas OO
Suportar conceitos de desenvolvimento de alto nível, bem como conceitos como colaboração, framework, padrões e componentes.
Incorporar as melhores práticas
*
*
*
UML – Aplicação
Sistemas de Informação
Sistemas Técnicos
Sistemas de Tempo Real
Sistemas Distribuídos
Softwares Básicos
Sistemas de Negócio (Estratégicos)
Reengenharia de Processos (BPR)
*
*
*
UML – Conceitos Básicos
Visões
Diagramas
Elementos de Modelagem
Recursos Genéricos
*
*
*
UML – Visões
Diferentes aspectos do sistema a ser modelado
Modelo completo só através de várias visões
Também servem para associar a linguagem de modelagem ao processo escolhido
Metodologias diferentes usam os diagramas para compor diferentes visões
*
*
*
UML – Diagramas
Gráficos que descrevem o conteúdo de uma visão
9 tipos de diagramas
Uma visão pode ser composta por vários diagramas
*
*
*
Visões e Diagramas
*
*
*
UML – Visões (Exemplos)
Uma visão representa um aspecto específico do sistema
Estruturais
Estática
Casos de Uso
Implementação
Implantação
Dinâmicas
Máquinas de Estado
Atividade
Interação
Gerencial
Modelo Gerencial
Uma visão representa um aspecto específico do sistema
*
*
*
Visões Estruturais 
Visão: Estática
Diagrama: 
Classes
Principais Conceitos:
Classe, 
Associação, 
Generalização, 
Dependência, 
Interface
*
*
*
Visões Estruturais
Visão: Casos de Uso
Diagrama: Casos de Uso
Principais Conceitos: 
Caso de Uso, 
Ator, 
Associação, 
“Extend”, 
“Include”,
Generalização de Casos de Uso
*
*
*
Visões Estruturais
Visão Implementação
Diagrama: 
Componentes
Principais Conceitos: 
Componente,
Interface, Dependência
*
*
*
Visões Estruturais
Visão: Implantação
Diagrama:
Implantação
Principais Conceitos: 
Nó, 
Componente, 
Dependência,
Local
*
*
*
UML 
Diagrama de Classes
*
*
*
Introdução
Descreve relações estáticas, basicamente:
Classes e sub-classes
Associações
Atemporal
Diagrama mais importante
Objeto = qualquer coisa que faz sentido no contexto da aplicação
Classe = conjunto de objetos com atributos, comportamentos e semântica comnus
*
*
*
Perpectivas (Niveis de Abstracao)
Conceitual 
Especificação Logica 
(Tipos e Interfaces) 
Implementação (Fisica)
IMAGEM
DOMÍNIO
*
*
*
Modelo Conceitual
No Modelo Conceitual representamos conceitos relativos ao domínio de um problema. Devemos nos concentrar no negocio e não em detalhes da implementação.
*
*
*
Modelo Conceitual – O quê?
Representamos no modelo conceitual:
Conceitos
Atributos relacionados aos conceitos
Associação entre conceitos
*
*
*
Modelo conceitual – Para que?
Não existe um modelo conceitual totalmente correto ou incorreto. Existem modelos úteis e inúteis. [Larman 97]
Se modelarmos um conceito de uma determinada maneira, devemos nos questionar quanto a sua utilidade e se a forma que modelamos
é a que mais no facilitará.
*
*
*
Queremos:
Representar abstrações
Independência de Implementações
Facilidade de comunicação
*
*
*
Modelo Conceitual – Como?
Conceito é uma idéia ou um algo tangível, uma coisa 
Construímos o modelo:
Usando nomes comuns ao negócio
Omitindo coisas ou detalhes irrelevantes
Sem acrescentar coisas que não estejam o negócio
*
*
*
Notação (Elementos)
Classes
Atributos
Operações
Associações
Papéis
Cardinalidade
Navegabilidade (Uni-direcional x Bi-direcional)
Generalização
Restrições
Agregação e Composição
*
*
*
Classes 
*
*
*
Atributos 
visibilidade nome : expressão-tipo = valor inicial {propriedades} 
Visibilidade
Privado –
Público +
Protegido #
Expressão – tipo
Tipo do atributo. Depende da linguagem utilizada.
Propriedades
Escopo
*
*
*
Associações 
Generalização
Agregação
Composição
Papéis (Necessário para ligação de uma classe com ela mesma)
Multiplicidade
Navegabilidade (Uni-direcional x Bi-direcional)
Restrições 
*
*
*
Generalização 
*
*
*
Agregação 
*
*
*
Composição 
*
*
*
Papel (Role) 
*
*
*
Associações – Exemplos 
*
*
*
Operações 
visibilidade nome (lista-parametros) : expressão-tipo-retorno {propriedades}
lista-parâmetros
gênero nome : expressão-tipo = valor-default
gênero -> in ,out , inout
expressão-tipo -> dependente da linguagem
valor-default -> opcional
propriedades
características da operação
Ex.: seqüencial ou concorrente
Especificação da operação
Descrita por uma nota (recurso genérico) ligada a operação
*
*
*
Conceitos Avançados
Classes de Associação
Restrição
Esteriótipos
Atributos Derivados
Classes Abstratas e Interfaces
Refinamento
Templates
Visibilidade
*
*
*
Atributos Derivados
*
*
*
Templates 
*
*
*
UML 
Diagrama de Seqüência
*
*
*
Introdução 
Diagramas de Seqüência apresentam a interação entre um grupo de objetos (ou classes) de um sistema, através de mensagens ou controles, em um determinado Cenário.
Servem para modelar o “funcionamento” do sistema, inclusive da concorrência entre objetos.
Úteis para compreensão da dinâmica, principalmente para iniciantes na OO.
Melhores que o Diagrama de Colaboração para apresentar as responsabilidades de cada objeto, especialmente quando o aspecto temporal é relevante.
*
*
*
Aplicação 
Diagramas de Seqüência são primariamente utilizados para atribuição de responsabilidades a cada um dos objetos no sistema – operações 
Além de servir para descoberta das operações, serve para a modelagem da interação entre os objetos 
Completam o tripé da análise:
Casos de Uso – comportamento externo (funcional)
Diagramas de Classes – visão estática
Diagramas de Seqüência – visão dinâmica
*
*
*
Concepção 
Cada Caso de Uso provê vários cenários 
Um cenário é uma instância de um caso de uso 
Diagrama de Classes mostra os objetos do domínio da aplicação 
Fazemos um Diagrama de Seqüência mostrando a interação dos objetos em um determinado cenário, ou seja, para cada cenário de um Caso de Uso teremos um diagrama
*
*
*
Concepção (cont.)
*
*
*
Diagrama de Seqüência 
Visão: Interação
Diagrama: 
Seqüência
Principais Conceitos:
Interação, 
Objeto,
Mensagem
*
*
*
Notação 
Dimensão Vertical = seqüência 
Dimensão Horizontal = objetos (ordem sem significado) 
Linha da Vida 
Mensagens 
Informações e Controle
*
*
*
Linha da Vida 
Objetos no topo
Vida do Objeto durante a interação representada
Pode apresentar a ativação e a desativação de objetos (foco de controle)
Pode representar criação de objetos
e a sua destruição de objetos
*
*
*
Mensagem 
Pelo menos o nome da mensagem deve aparecer 
Podemos também incluir argumentos e informações de controle 
Seta inclinada significa que a mensagem não é instantânea 
Return só é mandatório em sistemas concorrentes
*
*
*
Informações de Controle
Auto-delegação
Condição
Iteração
Return
*
*
*
Exemplo