Resumo da disciplina de Analise Orientada a Objetos I.docx

Prévia do material em texto

Resumo da disciplina de Analise Orientada a Objetos I
ADS – 2017 – 3º Semestre
Introdução
	Este resumo foi realizado com o intuito de ajudar a estudar para a disciplina de Analise Orientada a Objetos I. Contendo o resumo de cada tele aula realizada, com ajuda do meu entendimento sobre a disciplina, referencias do livro disponibilizado para o estudo e com os slides das tele aulas. E espero que ajude outras pessoas a entender essa disciplina que é essencial para o curso de analise e desenvolvimento de sistemas.
Primeira Tele Aula
Papel do Analista de Sistemas: Deve ser especialista nas tecnologias e recursos tecnológicos; Deve possuir visão diferente em relação a equipe; Mesmo assim, deve saber trabalhar em grupo; Deve ter habilidades de comunicação; Deve ter criatividade; Deve procurar ter dinamismo, ser autodidata;
Ciclo de Vida Básico do Processo de Desenvolvimento de Software: Conjunto de fases que o projeto possui. Estas, por sua vez, determinam as características do projeto e tornam possível ver a “maturidade” em que o projeto se encontra.
Analise de Requisitos
Análise (o que precisa ser feito/ Modelagem)
Projeto (Como será desenvolvido/ fala das tecnologias usadas)
Implementação e testes (onde cria os códigos e testa)
Implementação (Entrega para o cliente o software desejado)
Manutenção (Se caso o cliente solicitar) 
Analise de Requisitos: Preocupa-se com “o que deve ser feito”; compreende o problema apresentado considerando a FRONTEIRA (Objetivo que quero alcançar) e o DOMÍNIO (meios que utilizo para alcançar a fronteira). 
Paradigma Orientado a Objetos 
Orientação a Objetos: Maneira de entender e refletir sobre o mundo usando modelos organizados. 
Objetos: Qualquer coisa concreta ou abstrata com existência no mundo real (documentos ou objetos físicos), sendo possível identifica-lo como único.
Atributos: Características que uma determinada classe ou objeto possui. Eles também são chamados de variáveis de classe e podem se classificados em atributos de instância e atributos de classe (ou constantes). O primeiro é responsável por determinar o ESTADO de um objeto. E o segundo é responsável por CONTROLAR informações de uma classe, chama-se de constante, pois a informação da classe pode mudar conforme suas atualizações.
Classe: Grupo de objetos do mundo real que possui tipos de características e de comportamentos em comum. 
Métodos: Proporciona os detalhes de como fazer para construir o software. O código, linguagens de programação e ferramentas CASE.
Operações: Toda ação que o objeto executa ou sabe executar. Por exemplo: uma Ferrari é um objeto da classe carro, portanto, tem habilidade para ligar o motor, implementada através do método ligarMotor().
Evento e Estado: Evento são os acontecimentos que fazem os objetos mudarem de estado; E estado representa a forma de apresentação dos objetos de uma classe em um determinado instante. Por exemplo: Uma porta, o objeto porta1 se encontra no estado de fechada e assumiu o estado de aberto – Tudo isso toma um exemplo de estado da porta.
Encapsulamento: Ato de reunir em uma estrutura chamada classe, as características e o comportamento dos objetos, sendo uma forma de organiza-los, permitindo que um objeto proteja a integridade de suas partes. Por exemplo: Uma calculadora tem uma função definida, posso reutilizar essa função mas não posso interferir na sua integridade.
Generalização: Representa a propriedade pelas quais uma classe pode herdar características e comportamentos de outra.
Polimorfismo: Representa uma mesma operação se comportando de diferentes formas, em diferentes classes. 
Segunda Tele Aula
UML (Unified Modeling Language): Linguagem de Modelagem Unificada. Ela é uma fusão de métodos de Grady Booch, Ivar Jacobson, James Rumbaugh e tem a proposta de 13 técnicas de modelagem e 1 técnica narrativa. Sendo criada em 1997. Também é uma linguagem visual utilizada para modelar sistemas computacionais complexos ou não por meio do paradigma de orientação a objetos. Ela privilegia a descrição de um sistema segundo três perspectivas: 
Dados: Diagrama de Classe (Estrutural)
Operações: Diagrama de casos de uso (Funcional)
Eventos: Diagrama de sequencia, atividades de estado (temporal)
Operações e Eventos são a parte dinâmica do sistema e dados é a parte estática.
Na imagem esta mostrando as técnicas de modelagem que a UML utiliza, e a com o asterisco vermelho (*) seria a técnica narrativa. Os diagramas tratados na disciplina de A.O.Obj I foram o diagrama de classe, o diagrama de casos de uso e a documentação de casos de uso.
Processo Unificado: É um dos modelos de engenharia de software criado para apoiar o desenvolvimento orientado a objetos com a UML. Antes era chamado de Rational Objectory Process (ROP). É interativo e incremental. Um subconjunto do Processo Unificado se chama RUP (Rational Unified Process).
O P.U adaptado por Booch possui quatro fases e quatro atividades. Cada fase possui um resultado que deve ser alcançado para que a mesma seja concluída. A cada uma dessas fases tem a realização das atividades.
Fases: Concepção (Fase inicial do processo, é onde determina o escopo do sistema e, por meio dele, fornece um orçamento ao cliente), Elaboração (Preparação do projeto, finalização da arquitetura do projeto, assim como o domínio do problema, decidindo quais frameworks e linguagem de programação que serão usados), Construção (fase de desenvolvimento do projeto não especificadamente, é como um protótipo de como ele vai ficar), Transição (Fase final do processo, em que após ter requisitos e protótipos validados pelo cliente, o mesmo recebe o produto final e disponibiliza para usuários usarem)
Atividades: Requisitos (Aqui se defini o que o projeto precisa, define-se a quantidade de iterações que o mesmo irá possuir analisando e descrevendo o custo e o tempo de desenvolvimento do sistema, o analista deve mostrar ao desenvolvedor uma compreensão melhor dos requisitos. Esta contida nas três primeiras fases do P.U), Analise e Projeto (É responsável por analisar os requisitos a fim de gerar o projeto, estabelecendo uma boa arquitetura e buscando maior desempenho do sistema. Esta contido nas três primeiras fases), Implementação (É responsável por implementar o sistema, integrando todas as partes do sistema que foram desenvolvidas pela equipe com a responsabilidade de organização e padronização dos códigos. Esta contido na segunda e terceira fase), Testes (Realiza testes no sistema, com atividades como localizar e documentar os erros que o item avaliado possui e indicar se o projeto realmente atende as necessidades do cliente).
2.1 Diagrama de casos de Uso: Todo diagrama tem notação (elementos que compõem o diagrama) e existe regras (de nomenclatura e de desenho).
Requisitos Funcionais e Não-Funcionais: 
Funcionais: Todas as funcionalidades (casos de uso) que o sistema deve prover para os usuários. Ex: Controles, cadastros, consultas. 
Não-Funcionais: É o que não é uma funcionalidade, mas que precisa ser realizado para que o software atenda seu proposito.
Ator: É representado por um “boneco”, precedido do seu nome. Pode ser definido como um dos envolvidos no projeto, que interage com o sistema. Ele pode ser uma pessoa, um usuário do sistema, um hardware ou um sistema computacional. O ator primário fornece os dados, o secundário às vezes dependendo do caso.
Caso de Uso: Representado por uma elipse nomeada, pode ser definido como uma ação ou necessidade que o sistema deve atender na visão do desenvolvedor de sistemas. Outra definição é que pode ser um conjunto de métodos com um objetivo em comum.
Associação: Representa a conversa entre ator e caso de uso. Existem dois tipos de associação: Unidirecional (o ator somente solicita uma ação sem esperar resposta, ou vice-versa), Bidirecional (Envia e recebe mensagens entre ator e caso de uso).Representação de casos de uso:
Básico: Que existem poucas associações.
Generalização: Tanto o ator como caso de uso podem ter uma generalização.
Extend e o Include: Existem relacionamentos entre casos de uso e existe o caso de uso base que é aquele que tem o ator do lado. Os dois tipos de relacionamento são o extend (extensão) e o include (inclusão). 
Extensão: Vou usar em relacionamentos não obrigatórios (opcional) e é do caso de uso executado para o próximo passo que ele pode ou não precisar. 
Inclusão: Vai existir a partir de outro caso de uso sendo uma regra, então ela é representado obrigatoriamente. É do caso de uso base para o que vai acontecer. Ações obrigatórias que podem ser utilizadas por mais de um caso de uso.
3. Terceira Tele Aula
Documentação do caso de uso: Descreve, com linguagem simples, o que o caso de uso esta fazendo, de maneira detalhada, ou não, descreve as ações de cada ator e a ação do sistema, descreve também as restrições e validações do caso de uso; Embora esteja incluído no diagrama da UML 2.0 ele não é uma técnica! Ele é um complemento do caso de uso; Uma dica que me foi passada é que a documentação é bem feita logo após o diagrama de caso de uso, diagrama de classes e a prototipação, então ele seria a ultima tarefa a se fazer ao elaborar um projeto.
Formas de documentação: 
Contínuo: consiste no nome do caso de uso, uma breve descrição do que se trata, descreve o que é necessário, atores envolvidos (Cenário Principal e Alternativo), requisitos especiais e especifica os atributos.
Tabular: consiste em nome, caso de uso geral, atores secundários, pré-condições e pós-condições, ações do ator e do sistema, e restrições/Validações.
Numerado: Descrição narrativa dos eventos que são usados no caso de uso, especificando em cenário principal e alternativo, descrita por passos numerados. Obrigatoriamente terá um cenário principal em cada documentação e poderá ter vários cenários alternativos, pois ele é uma condição dos cenários principais. 
3.1 Diagrama de classes: Representa a modelagem da parte estática do sistema, representando um conjunto de classes com seus atributos, operações e relacionamentos.
Modelo de Classes: Conjunto de Diagramas. É quando não consigo mostrar um diagrama em uma única tabela assim acaba se tornando um modelo de classe.
Técnicas especificas do diagrama de classes: 
Elaboração do Diagrama de casos de uso.
Analisando os casos de uso, podemos identificar as classes e seus atributos.
Elaboração do Diagrama de classes único ou por visão.
Refinamento do diagrama de classes
Notação de classe: Nome da classe (substantivo no singular), atributos (nomeDoAtributo) e operações (verbo no infinitivo + substantivo). Segue, nessa mesma ordem, a imagem a baixo.
		
Relacionamentos: Na UML existem 4 tipos de relacionamentos: associação, generalização, dependências e realizações.
Associação: Relacionamentos estruturais entre instâncias. Tipos: Unária (auto-associação ou reflexiva), binária, classe associativa e agregação.
Unária: Objetos de uma classe se associando com os objetos da mesma.
Binária: Relacionamento entre objetos de duas classes.
Classe Associativa: É representada por uma seta tracejada partindo do meio da associação e atingindo uma classe.
Agregação (Agregação por Referência): As informações de um objeto (chamado objeto-todo) precisam ser complementadas pelas informações contidas em um ou mais objetos de outra classe( chamados objetos-parte). Ambas as classes poder “viver” de forma independentes, ou seja, não dependem uma da outra. Por exemplo: 
Quando eu tenho a classe aula mais a classe exercício quer dizer que toda aula pode ter nenhum ou muitos exercícios (0..*) mas cada exercício é especifico de uma aula (1). E toda aula pode ter nenhum ou vários materiais (0..*) e é especifico de uma aula. AULA = OBJETO-TODO/ EXERCICIOS e MATERIAIS = OBJETO-PARTE. Utiliza um losango vazio para indicar a composição.
Composição (ou Agregação por Valor): variação da agregação, onde é apresentado um vinculo mais forte entre objetos-todo e os objetos-parte, procurando demonstrar que os objetos-parte tem de estar associados a um único objeto-todo. Utiliza um losango preenchido para indicar a composição. Ambas dependem uma da outra. Por exemplo:
No momento que eu cadastrar uma prova, eu já faço o cadastro das perguntas e das alternativas. Não existe o objeto prova sem cadastrar as perguntas e não existe pergunta sem alternativas/respostas.
Generalização e Especialização: Classe-mãe, chamadas gerais e classes-filhas, chamadas especializadas, demonstrando a ocorrência de herança e de métodos. A herança é a possibilidade de uma classe utilizar atributos e métodos de uma outra como se fossem seus. 
Espero ter ajudado quem baixar esse resumo, tentei ao máximo diminuir o assunto ;) e bons estudos daqui pra frente :D