Aula-tema: Introdução Ao Levantamento E Análise De Requisitos Orientados A Objetos; Apresentação Da UML. Abordagem Resumida Dos Diagramas UML. Apresentação De Ferramenta Para Modelagem De Dados.

Resumo 1.1 - Análise e Projetos Orientado a Objetos

Primeiro passo para um projeto orientado são os levantamentos de requisitos nada mais é do que uma condição ou capacidade que deve ser alcançada. Simplificando, é algo que um sistema ou componente deve possuir para satisfazer um contrato, padrão ou especificação.

Pois requisitos são identificados a partir de um domínio de negócio. Domínio de negócio nada mais é do que a área específica que o software será desenvolvido, o contexto para a nossa solução.

Dentro dos requisitos devemos abordar os seguintes:

Requisitos Funcionais

Os requisitos funcionais abordam o que o sistema deve fazer.

O sistema deve permitir que cada professor realize o lançamento de notas das turmas nas quais lecionou. O sistema deve permitir que o aluno realize a sua matrícula nas disciplinas oferecidas em um semestre.

Requisitos Não-Funcionais

Esses requisitos declaram características de qualidade que o sistema deve possuir e que estão relacionadas às suas funcionalidades. Temos algumas divisões dentro desse tipo de requisitos.

Confiabilidade

Nada mais do que medidas quantitativas da confiabilidade do sistema, como por exemplo, o tempo médio entre falhas, recuperação de falhas, erros por milhares de linhas de código.

Portabilidade

Aqui tratamos da facilidade de migrar o sistema para outras plataformas. Que devemos dar uma atenção, para que o sistema rode em qualquer lugar.

Segurança

Aqui são descritas as particularidades sobre acessos ao sistema, segurança extra em login, restringir acesso de algumas pessoas, entre outros.

Usabilidade

Aqui são descritos os requisitos que se relacionam ou afetam a usabilidade do sistema. Coisas relacionadas à facilidade de uso, sobre a necessidade de treinamentos para os usuários.

Engenharia de requisito

O processo de engenharia de requisitos é composto por quatro atividades de alto nível.: Identificação, analise e negociação, especificação e documentação e validação

Este processo deve ser precedido de estudos de viabilidade que, a partir das restrições do projeto, determinam se este é ou não viável e se deve prosseguir para a identificação dos requisitos. Uma outra atividade que se pode considerar que faz também parte deste processo, se incluirmos a fase posterior à produção do documento (isto é, a sua "manutenção"), é a gestão dos requisitos.

 

Resumo 1.2 – Conceitos Gerais de Engenharia de Software

O conceito da Engenharia de Software foi proposto pela primeira vez em 1968 em uma conferência que discutia o que foi chamado de “Crise do Software”.

Tal crise foi resultante de um novo hardware de computador que era baseado em circuitos integrados, o seu poder era imenso há época, capaz de desenvolver softwares que antes eram inviáveis. Mostrando que o desenvolvimento informal de softwares era insuficiente.

O software não é um simples programa de computador, mas sim todos os dados de documentação e configuração associados, necessários para que o programa opere.

A Engenharia de Software é uma disciplina de engenharia relacionada com todos os aspectos da produção de software, desde os estágios iniciais de especificação do sistema até sua manutenção, depois que este entrar em operação.

Existem quatro atividades fundamentais de processo que são comuns a todos os processos de softwares:

Especificação de software: clientes e engenheiros definem o software a ser produzido e as restrições para a sua operação;

Desenvolvimento de software: o software é projetado e programado.

Validação de software: na qual o software é verificado para garantir que é o que o cliente deseja.

Evolução de software: o software é modificado para se adaptar às mudanças dos requisitos do cliente e do mercado.

O modelo em cascata e um dos modelos mais utilizados na hora de produzir um software que passa pelas seguintes etapas: especificação de requisitos, projeto de software, implementação e teste.

Um bom software deve conter tais atributos: facilidade de manutenção, confiança, eficiência e usabilidade.

Um grande desafio na produção do software e o da segurança, pois e essencial que possamos confiar no software. O desafio é desenvolver técnicas que demonstrem que o software pode ter a confiança dos seus usuários.

Apesar de existirem muitos processos de softwares, algumas atividades fundamentais são comuns a todos eles são elas: Especificação, projeto e implementação, validação e evolução do software.

A especificação de software ou engenharia de requisitos é o processo para compreender e definir quais serviços são necessários e identificar as restrições de operação e de desenvolvimento do sistema.

A engenharia de requisitos é um estágio crítico do processo de software, pois os erros conduzem inevitavelmente a problemas posteriores no projeto e na implementação do sistema.

As principais fases da engenharia de requisitos são: estudo de viabilidade, elicitação e analise, especificação e validação de requisitos.

Projeto de implementação do software é o processo de conversão de uma especificação de um sistema em um sistema executável.

 

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

A concepção é um passo inicial curto, para estabelecer uma visão comum e o escopo básico do projeto. Incluirá a análise de 10% dos casos de uso, análise dos requisitos não funcionais críticos, criação de um caso de negócios e preparação do ambiente de desenvolvimento, para que a programação possa começar na fase seguinte de elaboração.

A fase de concepção deve ser relativamente curta para a maioria dos projetos com uma ou poucas semanas de duração. De fato, em muitos projetos, se ela tiver mais de uma semana de duração, o sentido dela não foi compreendido: sua finalidade é decidir se o projeto merece uma investigação séria ( durante a elaboração ) e não executar tal investigação.

A elicitação de requisitos é também denominada de descoberta de requisitos, envolve pessoal objetivado em descobrir o domínio da aplicação, serviços que devem ser fornecidos bem como restrições e deve envolver usuários finais, gerentes, pessoal envolvido na manutenção, especialistas no domínio, etc.

Os tipos de requisitos são: requisitos funcionais, requisitos não funcionais e requisitos de domínio.

Um Requisito Funcional descreve as finalidades e serviços do sistema. Depende do tio de software, dos usuários esperados e do tipo do sistema onde o software e usado.

Ex de RF: Usuário pode pesquisar todo ou um subconjunto do banco de dados, Sistema deve oferecer visualizadores apropriados para o usuário ler documentos armazenados.

Um requisito não funcional define propriedades e restrições do sistema, o requisito não funcional pode ser mais critico que um requisito funcional. Devido a sua própria definição os requisitos não-funcionais são esperados mensuráveis.

Os requisitos não-funcionais são classificados de três formas requisitos do produto(o produto deve comportar-se de forma particular (velocidade de execução, confiabilidade, etc)), requisitos organizacionais (são a consequência de políticas e procedimentos organizacionais) e requisitos externos(são consequência de fatores externos ao sistema e ao processo de desenvolvimento).

Um requisito do domínio e derivado do domínio da aplicação e descreve características do sistema que qualidades que refletem o domínio, podem ser requisitos funcionais novos, restrições sobre requisitos existentes ou computações existentes.

Se os requisitos do domínio não forem satisfeitos, o sistema pode tornar-se não prático.

 

Resumo 1.4 – Engenharia de Requisitos

Engenharia de requisitos é o processo de descobrir, analisar, documentar e verificar as funções e restrições do sistema.

O uso do termo engenharia implica na adoção de métodos e técnicas sistemáticas, de tal forma que o processo seja passível de repetição e garanta a definição de requisitos não-redundantes, completos, corretos, de fácil entendimento etc.

Pesquisas têm comprovado que muitos projetos de implementação de software têm falhado por problemas de requisitos, ou seja, os requisitos obtidos muitas vezes são incompletos, mal entendidos e ambíguos. Requisitos incorretos acarretam em custo para o projeto.

De uma forma geral podemos definir um requisito como sendo uma declaração de um serviço ou restrição de um sistema a ser desenvolvido

Requisito também pode ser definido simplesmente como "algo que um cliente necessita"

Entretanto, do ponto de vista de um desenvolvedor, requisito pode também ser definido como "algo que necessita ser projetado".

Requisitos de sistema: Envolvem um contexto mais amplo e menos técnico que os requisitos de software.

Devem descrever o comportamento do sistema visto do “lado de fora”, ou seja, vindos da ótica do usuário do sistema.

A representação dos requisitos do sistema deve ser feita de tal forma que possa servir de veículo de comunicação entre os usuários e os desenvolvedores do software.

Requisitos de software:A maior parte dos requisitos do sistema apontados pelos usuários são funcionalidades e restrições que devem ser suportadas pelo software a ser implementado, e portanto passam a ser vistos também como requisitos do software

Além dos requisitos funcionais incorporados, os requisitos do software também envolvem restrições e exigências quanto a performance, segurança de acesso, interface com o usuário, portabilidade, modularidade, manutenibilidade, confiabilidade etc.

Além de incorporar boa parte dos requisitos do sistema, também abrangem os aspectos computacionais necessários a atender as exigências e restrições citadas acima.

Os Requisitos Funcionais determinam “o que” o software deve fazer e identificados a partir do ponto de vista do usuário.

Os Requisitos Não-Funcionais Determinam características desejáveis do software quanto ao: desempenho, confiabilidade, segurança e pertabilidade.

A engenharia de requisitos ocorre de forma intensiva nas primeiras etapas do ciclo de vida, abrangendo a engenharia de sistemas, análise e projeto.

Pode se estender para as demais etapas dependendo do paradigma de engenharia de software adotado

A importância da engenharia de requisitos no contexto de desenvolvimento de software advém do fato de que a correta identificação e documentação dos requisitos são fundamentais para o sucesso do software.

 

Aula-tema: Diagramas de Casos de Uso. Documentação dos Casos de Uso. Atores, Associações (Inclusão, Extensão); Diagramas de Classes e Objetos da UML.

Passo 2.1 Casos de uso

Um caso de uso representa uma discreta da interação entre um usuário e o sistema. Um caso de uso é uma unidade de um trabalho significante. Casos de uso são narrativas em texto, descrevendo a unidade funcional, e são amplamente utilizados para descobrir e registrar requisitos de sistemas. Os diagramas de Casos de Uso são representações dos Casos de Uso e podem ser representados por uma elipse contendo, internamente, o nome do caso de uso.

Casos de uso são tipicamente relacionados a "atores". Um ator é um humano ou entidade máquina que interage com o sistema para executar um significante trabalho. Cada ator corresponde a um papel específico: uma mesma pessoa que desempenha diferentes papéis nas interações com o sistema é representada por diferentes atores; por outro lado, diversas pessoas que desempenham o mesmo papel correspondem a um único ator.

Muitas pessoas introduziram os casos de uso via UML, que define uma notação gráfica para representar os casos de uso. O UML não define padrões para o formato escrito objetivando descrever casos de uso, e assim muitas pessoas compreendem erroneamente que a notação gráfica define a natureza do caso de uso; contudo a notação gráfica pode dar a visão geral mais simples de um caso de uso ou de um conjunto destes casos.

O Diagrama de Casos de Uso é um resumo do sistema. Você pode utilizá-lo para fazer um levantamento inicial dos OBJETIVOS e ATORES, e depois escrever os textos das narrativas. Ou você pode escrever as narrativas e depois fazer o diagrama. De qualquer forma, para a técnica de Casos de Uso, o texto (a narrativa) é muito mais importante que o diagrama. O diagrama também destaca integrações com sistemas externos, e em quais Casos de Uso ocorre essa integração.

A engenharia de requisitos consiste num processo onde são identificados todos os diferentes requisitos que um sistema de software deverá satisfazer quando se encontrar funcional. Este processo recorre a diferentes técnicas, algumas delas complementares entre si. O objetivo final é obter todos os requisitos idealizados para o sistema, possivelmente classificados por ordem de importância, descritos o mais claramente possível e devidamente validados pelos interessados ou stakeholders do sistema.

A clareza com que os requisitos são descritos e a sua abrangência que é idealizada pelos stakeholders é a máxima prioridade do processo tendo em vista não só a necessidade de transição do conhecimento dos requisitos do sistema tanto para os programadores que o irão implementar quanto para os utilizadores que dele farão uso, mas também para garantir que todo o conteúdo pretendido esteja identificado antes do processo de implementação começar, de modo a facilitar a arquitetura e planejamento de implementação da solução, evitando retrabalho.

2.2 Diagramas de casos de uso

Esse diagrama documenta o que o sistema faz do ponto de vista do usuário. Em outras palavras, ele descreve as principais funcionalidades do sistema e a interação dessas funcionalidades com os usuários do mesmo sistema. Nesse diagrama não nos aprofundamos em detalhes técnicos que dizem como o sistema faz.

Este artefato é comumente derivado da especificação de requisitos, que por sua vez não faz parte da UML. Pode ser utilizado também para criar o documento de requisitos.

Diagramas de Casos de Uso são compostos basicamente por quatro partes:

• Cenário: Sequência de eventos que acontecem quando um usuário interage com o sistema.

• Ator: Usuário do sistema, ou melhor, um tipo de usuário.

• Use Case: É uma tarefa ou uma funcionalidade realizada pelo ator (usuário)

• Comunicação: è o que liga um ator com um caso de uso.

• Include: seria a relação de um caso de uso que para ter sua funcionalidade executada precisa chamar outro caso de uso.

• Extend: Esta relação significa que o caso de uso extendido vai funcionar exatamente como o caso de uso base só que alguns passos novos inseridos no caso de uso extendido.