Análise Orientada a Objeto

Prévia do material em texto

Análise Orientada a Objeto
Enfatiza a descoberta e a descrição dos objetos de um domínio de aplicação
O paradigma da orientação a objetos visualiza um sistema de software como uma coleção de agentes interconectados chamados objetos.
Um paradigma é uma forma de abordar um problema.
No contexto da modelagem de um sistema de software, um paradigma tem a ver com a forma pela qual esse sistema é entendido e construído.
Cada objeto é responsável por realizar tarefas específicas. É através de interação entre objetos que uma tarefa computacional é realizada.
Um sistema de software orientado a objetos consiste de objetos em colaboração com o objetivo de realizar as funcionalidades deste sistema. Cada objeto é responsável por tarefas específicas. É através da cooperação entre objetos que a computação do sistema se desenvolve.
Fundamentos da orientação a Objetos
Qualquer coisa é um objeto.
Objetos realizam tarefas através da requisição de serviços a outros objetos.
Cada objeto pertence a uma determinada classe. Uma classe agrupa objetos similares.
A classe é um repositório para comportamento associado ao objeto.
Classes são organizadas em hierarquias.
UML (Unified Modeling Language)
Não é uma linguagem de programação
Não é uma técnica de modelagem. 
Uma linguagem visual
É independente de linguagem de programação.
É independente de processo de desenvolvimento.
Tem como objetivo auxiliar os engenheiros de software a definirem as características do sistema, como seus requisitos, seu comportamento, sua estrutura lógica, a dinâmica de seus processos e até mesmo suas necessidades físicas em relação ao equipamento sobre o qual o sistema deverá ser implantado
Aplicada em todas as etapas do ciclo de vida do software
Especifica, visualiza, constrói e documenta artefatos de software
Adequada à construção de modelos gráficos
A UML predefine diversos estereótipos.
UML -> PARA VISUALIZAÇÃO E ESPECIFICAÇÃO
Facilita a construção de modelos visuais de sistemas, descrevendo detalhadamente a estrutura e o comportamento
Fornece os símbolos gráficos para a representação de artefatos de software
Emprega símbolos com sintaxe e semântica bem definidos
Favorece a construção de modelos precisos, completos e sem ambiguidades
UML -> PARA CONSTRUIR
Os modelos UML podem ser diretamente “traduzidos” para várias linguagens de programação
Esse mapeamento permite a realização de uma engenharia de produção (geração de código) a partir de modelos UML
Permite reconstruir alguns models a partir do código fonte escrito em alguma linguagem de programação. Este processo inverso é chamado de engenharia reversa
UML -> PARA DOCUMENTAR
Os requisitos do sistema
A arquitetura e todos os seus detalhes
As atividades de planejamento do projeto 
As atividades de realização de testes
O gerenciamento de versões
Vantagens da UML
Padrão aberto e não proprietário (OMG)
Independente de processo de desenvolvimento
Aplicável em todas as fases do ciclo de desenvolvimento
Aplicável em todas as fases do ciclo de desenvolvimento
Independente de linguagem de programação
Interação das melhores práticas de modelagem
É uma linguagem extensível
OCL
Linguagem formal definida pela UML que pode ser utilizada para especificar restrições sobre diversos elementos de um modelo.
Pode ser utilizada para definir expressões de navegação entre objetos expressões lógicas, consulta, etc.
A maioria das declarações em OCL consiste dos seguintes elementos estruturais: contexto, propriedade e operação.
A OCL pode ser utilizada em qualquer diagrama da UML.
O que é Arquitetura?
É o conjunto de decisões significativas sobre:
A organização de um sistema de software
A seleção dos elementos estruturais que irão compor um sistema
O comportamento de um sistema, conforme especificado nas colaborações entre esses elementos
A decomposição desses elementos estruturais e comportamentais em subsistemas progressivamente maiores
O estilo arquitetural que orienta a organização desses elementos (aspectos estáticos, dinâmicos, suas interfaces, colaborações e composições)
Visão de caso de uso
Descreve um sistema do ponto de vista externo, através das interações entre esse sistema e os agentes externos a ele.
Requisitos funcionais
Processos de negócios 
Recursos: Descrição textual, diagrama de caso de uso, diagrama de estado, diagramas de interações, diagrama de atividades
Visão de projeto
Enfatiza as características de um sistema que são suporte, tanto estrutural quanto comportamental, às funcionalidades externamente visíveis desse sistema
Vocabulário
Funcionalidades
Recursos: Diagrama de classes, diagrama de interações, diagrama de estados
Visão de processos
Mostra o fluxo de controle entre as várias partes, incluindo mecanismos de concorrência e sincronização.
Essa visão cuida principalmente das questões referentes ao desempenho, à escalabilidade e ao throughput de um sistema
Recursos: Utiliza os mesmos diagramas que a visão de projeto, mas com foco voltado para as classes ativas (processos e threads) que controlam um sistema e as mensagens que passam por essas classes.
Visão de implementação
Abrange o gerenciamento de versões de um sistema e dos componentes e artefatos utilizados para a montagem e distribuição do mesmo. Diz a respeito também ao mapeamento dos componentes lógicos para os artefatos físicos
Recursos: Diagrama de componentes, diagramas de interações, diagrama de estados, diagrama de atividades
Visão de implantação
Abrange os nós que formam a topologia do hardware em que um sistema será executado
Essa visão trata principalmente da distribuição, do fornecimento e da instalação dos componentes físicos de um sistema
Recursos: Diagramas de implantação, diagramas de interações, diagramas de estados, diagrama de atividades
Por que modelar?
Por mais simples que seja, todo e qualquer sistema deve ser modelado antes de se iniciar sua implementação, entre outras coisas, porque os sistemas de informação frequentemente costumam ter propriedades de “crescer”, isto é, aumentar em tamanho, complexidade e abrangência.
Um sistema de informação precisa ter uma documentação extremamente detalhada, precisa e atualizada para que possa ser mantido com facilidade, rapidez e correção, sem produzir novos erros ao corrigir os antigos.
A atividade de modelar propicia:
O gerenciamento da complexidade inerente ao desenvolvimento de software
A comunicação entre as pessoas envolvidas
A redução dos custos no desenvolvimento 
A predição do comportamento futuro do sistema 
O fato complexidade é o condicionante dessas vantagens 
Diagramas e documentação
Diagramas permitem a construção de uma representação concisa de um sistema a ser construído. 
“uma figura vale por mil palavras”
Modelos também são compostos de informações textuais.
Dado um modelo de uma das perspectivas de um sistema, diz-se que o seu diagrama, juntamente com a informação textual associada, formam a documentação deste modelo.
Modelo de iterativo e incremental
Divide o desenvolvimento de um produto de software em ciclos.
Em cada ciclo de desenvolvimento, podem ser identificadas as fases de análise, projeto, implementação e testes.
Cada ciclo considera um subconjunto de requisitos. 
Esta característica contrasta com a abordagem clássica, na qual as fases são realizadas uma única vez.
Iterativo: o sistema de software é desenvolvido em vários passos similares.
Incremental: Em cada passo, o sistema é estendido com mais funcionalidades.
Vantagens
Incentiva a participação do usuário.
Riscos do desenvolvimento podem ser mais bem gerenciados.
Um risco de projeto é a possibilidade de ocorrência de algum evento que cause prejuízo ao processo de desenvolvimento, juntamente com as consequências desse prejuízo.
Influências: custos do projeto, cronograma, qualidade do produto, satisfação do cliente, etc.
Desvantagens
Mais difícil de gerenciar
Engenharia de requisitos
O que é?
Conjunto de tarefas que levam a um entendimentode qual será o impacto do software sobre o negócio, o que o cliente quer e como os usuários finais irão interagir com o software.
Quem realiza?
Engenheiros de softwares (também conhecidos como engenheiros de sistemas ou “analistas”) e outros interessados no processo (gerentes, clientes, usuários finais).
Por que é importante?
É importante entender o que o cliente quer antes de começar a projetar e construir um sistema baseado em computador.
Quais são as etapas envolvidas?
Concepção, Levantamento, Elaboração, Negociação, Especificação, Validação, Gestão.
Concepção: tarefa que define o escopo e a natureza do problema a ser resolvido.
Levantamento: tarefa que ajuda os interessados a definir o que é necessário.
Elaboração: onde os requisitos básicos são refinados e modificados. À Medida que os interessados definem o problema, ocorre a negociação - quais são as prioridades, o que é essencial, quando é necessário.
Qual é o artefato?
O objetivo da engenharia de requisitos é fornecer a todas as partes um entendimento escrito do problema. Isso pode ser alcançado por meio de uma série de artefatos: cenários de uso, listas de funções e características, modelos de análise ou uma especificação.
Como garantir que o trabalho foi realizado corretamente?
Os artefatos da engenharia de requisitos são revisados com os interessados para garantir que aquilo que você entendeu é realmente aquilo que eles queriam dizer.
Mesmo depois de todas as partes terem entrado em acordo, as coisas tendem a mudar e continuarão mudando ao longo de todo o projeto.
Engenharia de requisitos é uma ação de engenharia de software importante que se inicia durante a atividade de comunicação e continua na de modelagem. Ela deve ser adaptada às necessidades do processo, do projeto, do produto e das pessoas que estão realizando o trabalho.
A engenharia de requisitos constrói uma ponte para o projeto e para a construção.
A engenharia de requisitos fornece o mecanismo apropriado para entender aquilo que o cliente deseja, analisando as necessidades, avaliando a viabilidade, negociando uma solução razoável, especificando a solução sem ambiguidades, validando a especificação e gerenciando as necessidades à medida que são transformadas em um sistema.
Como um projeto de software é iniciado?
Na concepção do projeto, estabelecemos um entendimento básico do problema, as pessoas que querem uma solução, a natureza da solução desejada e a eficácia da comunicação e colaboração preliminares entre os demais interessados e a equipe de software.
Levantamento 
Certamente parece bastante simples – pergunte ao cliente, aos usuários e aos demais interessados quais são os objetivos para que o sistema ou produto, o que dever ser alcançado, como o sistema ou produto atende às necessidades da empresa e, por fim, como o sistema ou produto deve ser utilizado no dia a dia. Mas isso não é simples – na verdade, é muito difícil.
 
Problemas durante o levantamento
• Problemas de Escopo
Os limites do sistema são definidos de forma precária ou os clientes/ usuários especificam detalhes desnecessários que podem confundir, em vez de esclarecer, os objetivos globais do sistema
• Problemas de Entendimento
Os clientes/ usuários não estão completamente certos do que é preciso, têm um entendimento inadequado das capacidades e limitações de seus ambientes computacionais, não possuem um entendimento completo do domínio do problema, têm problemas para transmitir suas necessidades ao engenheiro de sistemas, omitem informações que acreditam ser “óbvias”, especificam requisitos que são ambíguos ou impossíveis de serem testados.
 
• Problemas de Votalitidade
Os requisitos mudam com o tempo. Para ajudar a superar esses problemas, devemos abordar o levantamento de requisitos de forma organizada.
Elaboração
As informações obtidas do cliente durante as fases de concepção e levantamento são expandidas e refinadas durante a elaboração. Essa tarefa concentra-se no desenvolvimento de um modelo de requisitos refinado que identifique os diversos aspectos da função, do comportamento e das informações do software. Para ajudar a superar esses problemas, devemos abordar o levantamento de requisitos de forma organizada.
As informações obtidas do cliente durante as fases de concepção e levantamento são expandidas e refinadas durante a elaboração. Essa tarefa concentra-se no desenvolvimento de um modelo de requisitos refinado que identifique os diversos aspectos da função, do comportamento e das informações do software. Para ajudar a superar esses problemas, devemos abordar o levantamento de requisitos de forma organizada.
Negociação
Não é comum clientes e usuários pedirem mais do que pode ser alcançado, dados os recursos limitados do negócio. Também é relativamente comum diferentes clientes ou usuários proporem necessidades conflitantes, argumentando que sua versão é "essencial para nossas necessidades especiais".
Especificação
Especificação pode ser um documento por escrito, um conjunto de modelos gráficos, um modelo matemático formal, um conjunto de cenários de uso, um protótipo ou qualquer combinação dos fatores citados.
A formalidade e o formato de uma especificação variam com o tamanho e a complexidade do software a ser construído.
Validação
Os artefatos produzidos como consequência da engenharia de requisitos são avaliados quanto À qualidade durante a etapa de validação. A validação de requisitos examina a especificação para garantir que todos os requisitos de software tenham sido declarados de forma não ambígua; que as inconsistências, omissões e erros tenham sido detectados e corrigidos e que os artefatos estejam de acordo com os padrões estabelecidos para o processo, projeto e produto.
O principal mecanismo de validação de requisitos é a Revisão Técnica.
A equipe de revisão que valida os requisitos é formada por engenheiros de software, clientes, usuários e outros interessados que examinam a especificação em busca de erros no conteúdo ou na interpretação, áreas em que talvez sejam necessários esclarecimentos, de informações faltantes, de inconsistências, de requisitos conflitantes ou de requisitos irreais (intangíveis).
Gestão de Requisitos
Gestão de requisitos é um conjunto de atividades que ajuda a equipe de projeto a identificar, controlar e acompanhar as necessidades e suas mudanças a qualquer momento enquanto o projeto prossegue.
Requisitos de sistemas de software
Requisitos funcionais: 
São declarações de funções que o sistema deve fornecer, ou são descrições de como alguns cálculos dever ser realizados.
Descrevem a funcionalidade ou os serviços que se espera que o sistema forneça.
Eles dependem do tipo de software que está sendo desenvolvido, dos usuários de software que se espera verificar e do tipo de sistema que está sendo desenvolvido.
Podem ser expressos de diversas maneiras.
Descrevem a função do sistema detalhadamente, suas entras e saídas, exceções, ...
A especificação de requisitos funcionais de um sistema dever ser completa e consistente.
A completeza significa que todas as funções requeridas pelo usuário devem estar definidas.
A consistência significa que os requisitos não devem ter definições contraditórias.
Requisitos não funcionais: 
São restrições sobre os serviços ou as funções oferecidas pelo sistema. Entre eles destacam-se restrições de tempo, restrições sobre o processo de desenvolvimento, padrões, entre outros.
São aqueles que não dizem respeito diretamente às funções específicas fornecidas pelo sistema.
Eles podem estar relacionados a propriedades de sistema emergentes, como confiabilidade, tempo de resposta e espaço em disco.
Como alternativa, eles podem definir restrições para o sistema, como a capacidade dos dispositivos de E/ S e as representações de dados utilizadas nas interfaces de sistema.
Muitos requisitos não funcionais dizem respeito ao sistema como um todo, e não a características individuais do sistema.
Exemplo:
Se um sistema de aviação não atender a seus requisitosde confiabilidade, ele não será atestado como seguro para operação.
Se um sistema de controle em tempo real falhar em cumprir com seus requisitos de desempenho, as funções de controle não operarão corretamente.
Os requisitos não funcionais nem sempre dizem respeito ao sistema de software a ser desenvolvido. Alguns requisitos não funcionais podem restringir o processo que pode ser utilizado para o desenvolver o sistema.
Os requisitos não funcionais surgem conforme a necessidade dos usuários, em razão de restrições de orçamento, de políticas organizacionais, pela necessidade de interoperabilidade com outros sistemas de software ou hardware ou devido a fatores externos (ex: regulamentos de segurança e legislação sobre privacidade).
Tipos de requisitos não funcionais:
Requisitos de Produtos: São os requisitos que especificam o comportamento do produto. Entre os exemplos estão os requisitos de desempenho sobre com que rapidez o sistema deve operar e quanta a memória ele requer
Requisitos Organizacionais: São procedentes de políticas e procedimentos nas organizações do cliente e do desenvolvedor. Entre os exemplos estão os padrões de processos que devem ser utilizados, os requisitos de implementação, como a linguagem de programação ou o método de projeto utilizado
Requisitos Externos: Abrange todos os requisitos procedentes de fatores externos ao sistema e a seu processo de desenvolvimento. Dentre eles destacam-se os requisitos de interoperabilidade, que definem como os sistemas interage com sistemas em outras organizações, os requisitos legais
Requisitos de domínio: 
São requisitos que se originam do domínio de aplicação do sistema e que refletem características desse domínio. Podem ser requisitos funcionais ou não funcionais.
Requisitos de Usuário:
Requisitos de usuário, eles são normalmente descritos de um modo bastante geral.
Os requisitos de usuários para um sistema devem descrever os requisitos funcionais e não funcionais de como compreensível pelos usuários do sistema que não tem conhecimentos técnicos detalhados.
Eles devem especificar somente o comportamento externo do sistema, evitando tanto quanto possível as características do projeto do sistema.
Não devem ser definidos utilizando-se um modelo de implementação. Eles podem ser escritos com o uso de linguagem natural, formulários e diagramas intuitivos simples.
Problemas que podem surgir quando os requisitos são escritos em linguagem natural:
Falta de clareza: Às vezes, é difícil utilizar a linguagem de maneira precisa e sem ambiguidade, sem produzir um documento de difícil leitura.
Confusão de requisitos: Os requisitos funcionais e os não funcionais, os objetivos do sistema e as informações sobre o projeto podem não estar claramente definidos.
Fusão de requisitos: Vários requisitos diferentes podem ser expressos juntos como um único requisito.
Requisitos de Sistema:
Requisitos de sistemas são descrições mais detalhadas dos requisitos do usuário.
Eles podem servir como base para um contrato destinado à implementação do sistema e, por tanto, devem ser uma especificação completa e consistente de todo o sistema.
Eles são utilizados pelos engenheiros de software como ponto de partida para o projeto de sistema
Modelo de caso de uso
É uma representação das funcionalidades externamente observáveis do sistema e dos elementos externos ao sistema que interagem com o mesmo.
Representa os requisitos funcionais do sistema.
Força os desenvolvedores a moldar o sistema de acordo com as necessidades do usuário
O modelo de casos de uso de um sistema é composto de duas partes, uma textual, e outra gráfica.
O diagrama da UML utilizado na modelagem de gráfica é o diagrama de casos de uso.
Este diagrama permite dar uma visão global e de alto nível do sistema.
É também chamado de diagrama de contexto.
Casos de uso:
Um caso de uso é a especificação de uma sequência de interações entre um sistema e os agentes externos.
Define parte da funcionalidade de um sistema, sem revelar a estrutura e o comportamento internos deste sistema.
Um modelo de casos de uso típico é formado de vários casos de uso.
Cada caso de uso é definido através da descrição textual das interações que ocorrem entre o(s) elemento(s) externo(s) e o sistema.
Há várias “dimensões de estilo” para descrição de casos de uso: Grau de abstração; Formato; Grau de detalhamento.
Utilidades dos casos de uso:
Equipe de clientes (validação)
aprovam o que o sistema deverá fazer
entendem o que o sistema deverá fazer 
Equipe de desenvolvedores 
Ponto de partida para refinar requisitos de software.
Podem seguir um desenvolvimento dirigido a casos de uso.
Designer (projetista): encontrar classes 
Testadores: usam como base para casos de teste
Diagrama de caso de uso
Representa graficamente os atores, casos de uso e relacionamentos entre os elementos.
Tem o objetivo de ilustrar em um nível alto de abstração quais elementos externos interagem com que funcionalidades do sistema.
Uma espécie de “diagrama de contexto”.
Apresenta os elementos externos de um sistema e as maneiras segundo as quais eles as utilizam.
Um MCU possui diversos elementos, e cada um deles pode ser representado graficamente. Os elementos mais comuns em um MCU são:
Ator
Caso de uso
Além disso, a UML define diversos de relacionamentos entre esses elementos para serem usados no modelo de casos de uso:
Comunicação
Inclusão
Extensão
Generalização
Diagrama de classe
Lembra o “der”, porém ele não possui métodos
Diagrama de classe -> associação
Diagrama Entidade Relacionamento -> relacionamento
Classe não tem chave primária, nem chave estrangeira, isso são conceitos de banco de dados relacional
Um objeto é qualquer coisa
Associação é representada por verbo
Nem todo verbo é uma associação
Associação: pode ser definida por mínimo e máximo
Conceito de herança = generalização e especificação 
Agregação, composição e herança:
Se algo depender de outro para existir é Composição (losango vazio)
Se não depende, apenas agrega é Agregação (losango cheio)
Se algo fosse feito do outro, fosse sua matéria prima, é Herança