ANÁLISE ORIENTADA A OBJETOS

Prévia do material em texto

ANÁLISE ORIENTADA A OBJETOS
FERRAMENTO: Visual Paradigm Community
- UML
	- UML (Aceita pela ISO como padrão):
	
		- Definição: Linguagem Padronizada de Modelagem de Sistemas (Orgão Padronizador: OMG - Object Management Group)
		- Importância: Facilitar a visualização, Especificação, Construção e Documentação de Componentes de um sistema
		- Características: Combina com Orientação a Objetos, Compatível em todo ciclo de vida de um sistema, compatível com diversos escopos
		- Evolução: 
		
			- Primeira versão (1997): a primeira versão enviada ao OMG em janeiro de 1997 não estava completa e precisou de reformulações. A versão 1.1, lançada em novembro de 1997, foi a primeira funcional.
			- Versão 1.3: após feedbacks, modificações na semântica, notações e metamodelos resultaram na versão 1.3.
			- Versões 1.4 e 1.5: a versão 1.4 acrescentou opções de visibilidade, artefatos e estereótipos, seguida pela versão 1.5 com procedimentos e mecanismos de data flow. Em janeiro de 2003, entre essas versões, a UML foi aceita pela ISO como padrão.
			- UML 2.0 (2005): introduziu interações em diagramas como object, package e timing. Diagramas de colaboração foram renomeados para diagramas de comunicação, entre outras modificações significativas.
			- Versões 2.1 a 2.3: focaram em correções de erros e pequenas modificações.
			- Versão 2.4.1 (2011): incorporou mudanças em classes, pacotes e estereótipos.
			- UML 2.5: revisão da versão anterior, com melhorias na simplicidade da linguagem e geração mais rápida de modelos eficientes, eliminando características obsoletas.
			- Última Versão 2.5.1 (2017): incluiu correções de erros reportados pelos usuários, embora alguns problemas ainda permaneçam não resolvidos, conforme o site da OMG.
		
		- Níveis de abstração do modelo: Alto (Para o Cliente - Requisitos), Médio (Desenvolvimento) e Baixo (Desenvolvimento)
		- Vantagens (beneficios): Independente da Implementação, Simples, Padrão para desenvolvimento
		- Desvantagens: Treinamento, Curva de Aprendizado, Resistência a mudança
		
			DESVAGENS DO MEU PONTO DE VISTA:
			- CAROS 
			- DEMANDAM TEMPO
			- COMPLEXOS
			- EXTENSOS
			- EXTREMAMENTE DIFICIL A MANUTENÇÃO
			- RIGIDA DEMAIS PARA AMBIENTES DINÂMICOS E AGEIS
			- REQUER FERRAMENTAS (PAGAS)
			- A INCONSISTÊNCIA COM O TEMPO POR FALTA DE MANUTENÇÃO PODE LEVAR A ESCOLHAS ERRONÊAS
	
	- Classificação de diagramas UML:
	
		- Estruturais: 
		
			- Definição: Capacidade de mostrar a estrutura do sistema (Arquitetura e Montagem do Sistema)
			- Diagramas: Classes, Objetos, Pacotes, Estrutura Composta, Componente, Implantação e Perfil
			
		- Comportamentais (Diagrama de Interação): 
		
			- Definição: Valida o Fluxo e o Comportamento do Sistemas
			- Diagramas: Casos de Uso, Atividade (Cada caso de uso gera um) e Máquina de Estados (muito útil)
			- Diagramas de Interação: Sequência, Comunicação, Tempo, Tempo e Visão Geral de Interação
	
	- Processo Unificado do UML:
	
		- Importância: Processo unificado é um processo de desenvolvimento focado em UML
		- processo unificado (PU / UP) / RUP (Rational Unified Process - Proceso Unificado Racional): quem faz? o que faz? como faz? quando faz? 
		- processo:
		
			- Interativo e incremental
			- Dirigido por uma lista de casos de uso
			- Focado na Arquitetura do Sistema
			- Orientado a Riscos (Maior risco primeiro)
			
		- Fases: Concepção, Elaboração, Construção, Transição (Tipo Testes)
		
			- Comunicação (Concepção)
			- Planejamento (Elaboração / Análise)
			- Modelagem (Elaboração / Análise)
			- Construção (Desenvolvimento / Transição)
			- Entrega (Desenvolvimento / Transição)
			- Gera uma nova versão do Sistema (Incremento / Produção)
			
		- Disciplina (Por incremento)
		
		Concepção	| Elaboração	| Construção		| Transição 
		-------------------------------------------------------------
		I1			| E1	E2		| C1	C2	C3	C4	| T1	T2
		Alto		| Alto		 | Alto 			| Baixo 
		Alto 		| Alto | Alto 			| Baixo
		Médio		| Médio | Alto 			| Médio
		Médio		| Médio | Alto 			| Médio
		Baixo		| Baixo | Alto 			| Alto
		Baixo	 | Baixo | Alto 			| Alto
		
		- Diagramas por Fase:
		
			- Concepção e Elaboração: Casos de Uso, Sequência, Colaboração, Atividades, Máquina de Estados
			- Construção: Classes, Sequência, Colaboração, Atividade, Máquina de Estado, Implantação
			- Transição: Transição, Sequência, Colaboração, Componentes
		
		- consistência dos diagramas: 
		
			- Nº de Objetos deve ser igual entre os diagramas de classes e sequência
			- A manutenção no Diagrama de classes deve ser repetida no diagrama de sequência
			- Cada caso de uso deve gerar uma operação no diagrama de classes
			- Para cada caso de uso deve existir um diagrama de sequência
			- Deve haver consistência entre os atores do caso de uso e do diagrama de sequência
	
	- Fundamentos de Orientação a Objetos:
	
		- Paradigmas: Padrões de desenvolvimento de uma linguagem de programação
		- Exemploes de paradigmas: Imperativo, Declarativo (Funcional ou Lógico), Baseado à Eventos, Orientado a Objetos
		- Fundamentos: Representação dos Objetos do mundo real, suas caracteristicas (Atributos) e comportamentos (Métodos)
		- Componentes:
		
			Classes: É a abstração de um objeto do mundo real (Definição de um objeto do mundo real), definindo o através de atributos e métodos
			Objetos: É uma instância da classe (Representação de um objeto do mundo real)
		
		- PILARES DA ORIENTAÇÃO A OBJETO:
		
			- Abstração: Seleção de aspectos do domínio do problema a modelar
			- Herança (RELACIONAMENTO): Compartilhamento de métodos e atributos entre classes
			- Polimorfismo (RELACIONAMENTO): Métodos com a mesma assinatura mas comportamentos diferentes
			- Encapsulamento: Privar o acesso direto ao estado (atributo) do nosso objeto
- Modelando essencial
	- Diagrama de Caso de Uso:
	
		- Conceitos: Esboçar os casos abrangidos por um sistema e pelas pessoas associadas
		- Características: Diagrama de Alto Nível, usado como requisitos e é fácil de usar
		- Componentes: Caso de Uso (Verbo + Substantivo), Ator, Ligações (Associação, Generalização (com seta), Include (Obrigatório) ou Extend (Opcional)), Multiplicidade
		- Elaboração: Para generalização sai dos dependentes para o principal, para include ou extend sai de quem chama para quem será chamado
		- Multiplicidade: jogador (2..4) - (0..1) jogar => (Mínimo, máximo)
	
	- Diagrama de Classes:
	
		- Conceitos: Descrever as classes, objetos, interfaces e seus relacionamentos para o desenvolvimento de um sistema
		- Componentes: 
		
			- Classes: Nome, Atributos e Métodos
			- Modificadores de acesso: + Public, - Private, # Protected -> somente sub classe
			- Classes Abstratas: Contratos estabelecidos por herança
			- Interfaces: Contratos
			
			- Ligações (Relacionamentos): 
			
				- Implementação (Tracejado com seta)
				- Herança (com seta)
				- Composição (seta com losango preenchido): Não necessita do outro
				- Agregação (seta com losango não preenchido): Necessita do outro
			
			- Multiplicidade: 
			
				- 0..1 → Um ou nenhum (Opcional)
				- 1 → Exatamente um (Obrigatório)
				- 0..*`` (ou *`) → Zero ou mais (Coleção)
				- 1..* → Um ou mais (Obrigatório, mas pode ter vários)
				- n..m → De n a m elementos (Faixa específica)
	
	- Diagrama de Atividades:
	
		- Conceitos: É a descrição individual das atividades de cada caso de uso
		- Componentes: Inicio, Fim, Terminal, Condicional, Atividade, Transição
		- Barra de Sincronização: 
		- Fork: Divisão do fluxos
		- Join: União dos Fluxos
		- Partição de Atividades (Swimlanes): Raias que setorizam (exemplo: fiscal, logistica, etc) o problema
	
	- Diagrama de Máquina de Estado:
	
		- Conceitos: Análisa como um objeto se comporta e como ele muda o seu comportamento
		- Elementos: Inicio, Fim, Estado, Transição, Condicional, Fork, Join
		- Ações executadas por Estado:Do: Atividades durante um estado
			Entry (Transacional): Atividades executadas na entrada de um estado
			Exit (Transacional): Atividades executadas na saída de um estado
			
		- Elaboração: Indentificar os estados relevantes, identificar eventos relacionados, identificar influências, definir estado inicial e final (finais)
- Modelagem complementar
	- Diagrama de Sequência:
	
		- Conceitos: Entender a interação entre os objetos, sendo uma derivação do caso de uso e do de classe
		- Componentes: 
		
			- LifeLine (Ligação com um elemento qualquer que existe (instanciado))
			- Ator 
			- Object: Class (Ligação de um Objeto/Classe)
			- Mensagem Sincrona (Seta simples): Emissor aguarda uma resposta
			- Mensagem Assincrona (Seta preenchida): Emissor não aguarda uma resposta
			- Mensagem de Retorno (Seta simples tracejada)
			- Frame: Tipos de Elementos, consequências ou SubProcessos
			- Esteriótipos: > (Visualização da Aplicação), > (Controle da Aplicação) e > (Dominio da Aplicação)
			- Fragmentos: ref (sequencial), alt (decisão manual), opt (condicional), loop (interação) - é usado em um frame
			
		- Elaboração: Analisar o diagrama de casos de uso (identificar atores), analisar diag. classes (comunicação entre objetos), identificar mensagens e a consistência
	
	- Diagrama de Componente:
	
		- Conceito: Descreve um componente seus agrupamentos, relações e modo de comunicação
		- Elementos: Componente, Classes (soomente o nome), Necessita (Linha com um circulo no meio), Portas (Comunicam componentes internos com o externo)
	
	- Diagrama de Objeto:
	
		- Conceito: Como está meu programa em um determinado momento baseado nas classes (Só aborda atributos)
		- Componentes: objeto, associação (reta), classe, instanciação (tracejada com seta simples >), Multiplicidade, 
		- MINHA OBSERVAÇÃO: Importante para testes unitários
	
	- Diagrama de Pacotes e Diagrama de Comunicação:
	
		- Diagrama de Pacotes (tipo um nugget): 
		
			- Conceitos: Hierarquia de pacotes dentro de um sistema e mostrar a dependência entre eles
			- Componentes: Pacotes, Classes, Dependências dos pacotes
			
		- Diagrama de Comunicação (Basicamente meus esboços de comunicação quando passo algo para alguém): 
		
			- Conceitos: Representa as interações entre diferentes objetos
			- Componentes: Ator, Multi-Object, LifeLine, Vinculo, Message e annotations
			- Diagrama de Sequencia X Diagrama de Comunicação : Prático, mais complicado de entender
- Modelagem de caso (ESTUDO DE CASO)
	-> CRISE DO SOFTWARE
	-> MODELAR É IMPORTANTE PARA SISTEMAS COMPLEXOS POIS RESTRINGE OS ASPECTOS
	-> ABAIXO ORDEM DA MODELAGEM REALIZADA DE EXEMPLO NA UNIDADE:
	- Modelagem Complementar:
	
		- Diagrama de Estruturas Compostas: 
		- Diagrama de Máquina de Estados: 
		- Outros detalhes de Modelagem COmplementar: 
	
	- Transição de Análise para Projeto:
	
		- Modelagem de Projeto: 
		- Classes: 
		- Refinamento dos Aspectos Comportamentais: 
	
	- Aspectos de Qualidade no Desenvolcimento: 
	
		- Persistência de Objetos para o Modelo Relacional: 
	
	- Fases de um Projeto:
	
		- Inicio: 
		
			- Casos de Uso: 
			- Atividades: 
		
		- Elaboração: 
		
			- Classe: 
			- Objeto: 
			- Sequência: 
			- Colaboração: 
			- Componentes: 
		
		- Construção: 
		
			- Máquina de Estado: 
			- Implantação: 
		
		- Transição: 
		
			- Implantação: 
			- Componentes: 
			- Pacotes: