Atps Fundamentos De Análise Orientada A Objetos

Relatório 1 –

Análise dos Requisitos

Resumo 1.1 - Análise e Projetos Orientado a Objetos;

Existe uma diferença no conceito de Análise e Projeto Orientado a Objetos. Enquanto a análise trata de identificação e resolução de uma determinada situação, uma investigação pra entender o domínio do problema e o que deve ser feito, o projeto trata da solução, como pode ou deve ser feito essa resolução utilizando uma modelagem. Resumidamente: análise = entendimento do problema e projeto=modelagem da solução;

Na fase de análise, são realizadas todas as atividades para entendimento do problema, uma conversa com o cliente a fim de saber quais as suas necessidades, quais as interações que esse sistema deve realizar e identificar quais os objetos importantes para esse sistema.

Utilizam-se então o conceito de “objeto” para coisas, conceitos, entidades, onde tudo é visto como “algo”. Objeto pode ter seus atributos que seriam quase como qualidades, algo que ele possui, e as responsabilidades, que seriam o que ele deve fazer, como vai agir nesse sistema.Na fase do projeto esse emprego de objeto, atributo e responsabilidades, participam da solução do devido problema.

Dá pra perceber que a análise e o projeto andam juntos, pois ao mesmo tempo que são verificados os possíveis problemas já se vai identificando os protagonistas para a resolução dos mesmos. Na fase de projeto, deve se solucionar o problema e mostrar, visualizar como o sistema funcionara, quais os objetos responsáveis por determinadas ações, utilizando alguns dos vários diagramas existentes na UML.

A UML é um padrão de linguagem modelada, ou seja, uma linguagem a ser seguida para a representação desse sistema de forma visual.

Com alguns dos vários diagramas existentes, é possível mostrar como o sistema ira funcionar, quais as ações empregadas por determinado objeto, o que ele pode e não pode fazer. Alguns nos permitem mostrar o sistema interagindo com o usuário, ou com outro sistema, etc...

As possibilidades são muitas, e tudo é abstraído na fase de analise que é a mais importante, pois é onde você deve saber onde esta o problema para aplicar o seu sistema solução.

Resumo 1.2 – Conceitos Gerais de Engenharia de Software;

Engenharia de software diz respeito a todo o processo de produção do software. Geralmente esse processo é dividido em 4 tarefas, sendo:

-Especificação de Software: onde são definidas as restrições e funcionalidades. -Desenvolvimento: o software é projetado e programado.

-Validação: verificação onde se garante que o software desenvolvido atende ao pedido do cliente.

-Evolução: modificação, mudanças, para atender a novos requisitos do cliente ou mercado.

Métodos:

Um método é uma forma estruturada de desenvolver um software com facilidade, agilidade, de qualidade e custos adequados.

O método orientado a funções foi complementado pelo orientado a objetos, sendo integrado a UML.

Um bom software precisa ser manutenível, podendo se adequar a novas mudanças se preciso, ser confiável,eficiente em termos de tempo de resposta, utilização de memória,e ser usável pelo tipo de usuário ao qual ele foi projetado.

Processo de Software: São todas as atividades realizadas para a produção do produto de software como definir suas funcionalidades e restrições, a implementação e validação, pra confirmar o funcionamento e se é realmente aquilo que o cliente pediu.

Modelos de Processo de Software: Existem vários modelos que vai de acordo com sua preferência e necessidade de uso, diz respeito a forma como você vai desenvolver seu projeto e desenvolvê-lo, como exemplo podemos citar o modelo em cascata, que considera especificação, desenvolvimento, validação e evolução e representa cada uma destas etapas como fases separadas. Existem outros modelos como prototipagem e incremental onde de inicio se pode ir desenvolvendo o software e ir “adicionando” funções ao longo do projeto com o objetivo de obter a satisfação do cliente, ou seja, ao tempo que você vai obtendo os requisitos, definindo funções e restrições você também já vai desenvolvendo o software, e conforme mais funções e requisitos você for obtendo, vai incrementando isso ao software já desenvolvido até a conclusão.

Essa técnica de prototipagem e incremental é indicada em casos de softwares simples, pois o cliente não tem de esperar até a entrega do sistema inteiro pra utilizar dele, pois podem já ir utilizando as “partes” que vão sendo desenvolvidas e ao longo do processo terão acrescentadas as demais “partes” até que ele esteja completo.

Resumo 1.3 – Concepção, Elicitação e Tipos de Requisitos;

Concepção: é uma avaliação sobre o desenvolvimento do projeto, uma estimativa de quanto tempo, qual o custo, viabilidade, riscos, pra concluir se vale à pena investir mais a fundo na elaboração do projeto. Esse passo é quase como um estudo de viabilidade, só que superficial, e só após essa visão superficial, chegamos a uma conclusão, e então nos aprofundando no assunto pra obter respostas mais precisas.

Nessa fase geralmente se faz uso de alguns artefatos, como a descrição dos requisitos funcionais, lista de riscos, criação de protótipos para prova de conceito, e outros. São apenas completados parcialmente, e subquentemente sendo refinados, e lembrando que todos estes artefatos são opcionais, você pode optar pelo que te agregar maior valor para a elaboração do projeto, a fase de Concepção é um planejamento.

Nessa parte não é preciso detalhar muito os requisitos e funcionalidades, isso se faz na elaboração do projeto.

Elicitação de requisitos: é uma das tarefas mais importantes na engenharia de software, pois se trata da fase de extração, obtenção das necessidades do usuário, e entendimento dos fatos que apresentam problemas a serem resolvidos. Na fase de elicitação, é necessário o envolvimento do usuário, descrição clara dos requisitos, planejamentos adequados, e expectativas realísticas. Tem-se toda uma preparação para se extrair essas informações do usuário, podendo ser desde um questionário a um workshop, durante as entrevistas, focar no que o cliente quer e não tirar conclusões precipitadas, ter boa postura, não falar termos técnicos, e em caso de duvidas sempre