Análise de Sistemas Orientada a Objetos

Aula 01 – Introdução à disciplina

O que veremos?

• Abordaremos conceitos aplicáveis sobre:• Aspectos introdutórios.

• Sistema de Informação X Software.

• Papeis de membros de uma equipe de projeto software.

• Engenharia de Requisitos• Requisitos: requisitos do usuário, requisitos do sistema, requisitos funcionais e requisitos

não-funcionais

• Técnicas para Coleta de Requisitos

• Documentação de Requisitos

• Gerenciamento de Requisitos

O que veremos?

• Abordaremos conceitos aplicáveis sobre:• Modelagem de Processos de Negócio.

• Conceitos introdutórios sobre processos de negócio.

• Diagrama de Atividades.

• O papel do Analista de Negócio.

• Modelagem de Casos de Uso.• Conceitos introdutórios sobre requisitos de software.

• Elicitação de Casos de Uso e Atores.

• Diagrama de Casos de Uso.

• Descrição de Casos de Uso.

• Estruturação do Diagrama de Casos de Uso.

• Requisitos não-funcionais .

O que veremos?

• Abordaremos conceitos aplicáveis sobre:• Modelagem de Processos de Negócio.

• Conceitos introdutórios sobre processos de negócio.

• Diagrama de Atividades.

• O papel do Analista de Negócio.

• Modelagem de Casos de Uso.• Conceitos introdutórios sobre requisitos de software.

• Elicitação de Casos de Uso e Atores.

• Diagrama de Casos de Uso.

• Descrição de Casos de Uso.

• Estruturação do Diagrama de Casos de Uso.

• Requisitos não-funcionais .

O que veremos?

• Abordaremos conceitos aplicáveis sobre:• Análise OO com UML.

• Classes de Análise.

• Diagrama de Classes.

• Realização de Casos de Uso.

• Colaborações.

• Diagrama de Sequência.

• Diagrama de Colaboração (Comunicação).

• Diagrama de Máquina de Estados.

• Estruturação de sistemas em subsistemas e camadas.

• Diagrama de Pacotes.

• Acoplamento X Coesão.

Bibliografia

• BOOCH, G.; JACOBSON, I.; RUMBAUGH, J. UML - guia do usuário. 2. ed. Rio de Janeiro, Campus, 2006.

• BEZERRA, E. Princípios de Análise e Projeto de Sistemas com UML: um guia prático para modelagem de sistemas orientados a objetos através da linguagem de modelagem unificada. Rio de Janeiro, Campus.

• LARMAN, C. Utilizando UML e Padrões: uma introdução à análise e ao projeto orientados a objetos e ao processo unificado. 2. Ed. Porto Alegre. Bookman. 2004.

Bibliografia Complementar

• PRESSMAN, R. S. Engenharia de software. 6. ed. São Paulo: McGraw-Hill, 2006.

• SOMMERVILLE, I. Engenharia de software. 8. ed. São Paulo: Pearson, 2007.

Frequência em sala de aula

• Cada noite de aula correspondem a 3 (três) presenças

• Exigência mínima de presença em sala de aula para aprovação: 75%

Avaliação

● Padrão UNIP: NP1 e NP2

● Avaliações com questões de múltipla escolha e

dissertativas, totalizando 10 questões por avaliação.

● Média Semestral (MS) deverá ser igual ou superior a 5,0 para aprovação

MS = ((NP1 x 4) + (PIM x 2) + (NP2 x 4)) / 10

Aspectos Introdutórios

• Sistema de Informação:• Conjunto de componentes inter-relacionados trabalhando juntos para coletar,

recuperar, processar, armazenar e distribuir informações com a finalidade de facilitar o planejamento, o controle, a coordenação, a análise e o processo decisório em empresas e outras organizações [Laudon].

• Gera informações utilizáveis para a coordenação de fluxo operacional de trabalho de uma empresa, bem como suporte à tomada de decisões. Um sistema de informação pode ser totalmente manual ou ser automatizado.

Aspectos Introdutórios

• Elementos de um Sistema de Informação:

• Organizações: Empresas são organizações formais. Subdivide-se em unidades organizacionais (UO) hierárquicas e estruturadas. Cada UO possui processos e regras de negócio que são executados por pessoas e/ou software.

• Pessoal: Colaboradores da empresa que executam processos de negócio e operam computadores. São consumidores e geradores de informações.

• Procedimentos: É um conjunto de tarefas que podem ser manuais ou automatizadas por algum software, ou ainda que poderão ser automatizadas por um software a ser desenvolvida em uma ocasião futura.

Aspectos Introdutórios

• Elementos de um Sistema de Informação:• Software: Artefato de código que tem por objetivo a execução de um conjunto de

instruções que automatizam um processo ou um trecho de um processo de negócio.

• Hardware: Dispositivos eletrônicos que fornecem capacidade computacional, dispositivos de interconectividade, dispositivos eletromecânicos. O hardware é um meio eletrônico que permite a execução de um artefato de software.

• Base de dados: Como o próprio nome sugere, é um conjunto de dados que são atualizados pelo software. Essas atualizações são feitas através de procedimentos de inclusão, alteração, exclusão e consulta de entidades de negócio.

• Documentação: Informação descritiva que mostra o uso e/ou operação do sistema. Podem ser normas, padrões, regras, políticas, descritivos de procedimentos, sistemáticas e processos relativos ao negócio foco do sistema de informação em questão.

Cenário atual do desenvolvimento de software

Cenário atual do desenvolvimento de software

Causas de falhas em projetos de software

Requisitos e análise de sistemas

Requisitos - Definição

Segundo o Rational Unified Process (RUP):É uma condição ou uma capacidade que deve ser atendida pelo sistema.

Definição do IEEE (Institute of Electrical and Electronics Engineers):

É uma condição ou capacidade que deve ser atendida pelo software, necessária a um usuário para solucionar um problema ou atender a um objetivo.O conjunto de todos os requisitos formam a base para posterior desenvolvimento do sistema ou componente do sistema.

SWEBOK (Software Engineer Body Of Knowledge)

Expressa necessidades e restrições ao produto de software que contribui para a solução de problemas no domínio do negócio.

Engenharia de Requisitos

É um processo que engloba todas as atividades que contribuem para a produção de um documento de requisitos e sua manutenção ao longo do tempo.

O processo de engenharia de requisitos é composto por quatro atividades de alto nível :

• identificação;

• análise e negociação;

• especificação e documentação;

• validação.

Engenharia de Requisitos

Engenharia de Requisitos

Engenharia de Requisitos

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.

Engenharia de Requisitos

• Uma forma de avaliar a viabilidade de um projeto é obter, através da interação com "as partes interessadas" (ou stakeholder em inglês) do projeto (em reuniões ou entrevistas, por exemplo), a resposta às seguintes questões:

• Será que o sistema contribui para os objetivos da organização?

• Dadas as restrições tecnológicas, organizacionais e temporais associadas ao projeto, será que o sistema pode ser implementado?

• Caso haja necessidade de integração entre diferentes sistemas, será que esta é possível?

Engenharia de Requisitos - identificação

• Algumas das atividades envolvidas nesta fase incluem:• Compreensão do domínio: é muito importante para o analista compreender o

domínio no qual a organização e o projeto se inserem; quanto maior for o conhecimento acerca do domínio, mais eficaz será a comunicação entre o analista e as partes interessadas.

• Identificação das partes interessadas: estes já deverão ter sido identificados nos estudos de viabilidade, porém para efeitos de identificação de requisitos convém concentrar as atenções nos usuários do sistema.

• Captura: consiste na obtenção com o cliente dos requisitos (funcionais e não-funcionais) pretendidos para o sistema.

• Identificação e análise de problemas: os problemas devem ser identificados (e a sua definição deve ser consensual) e devem ser propostas soluções em conjunto com as partes interessadas.

Engenharia de Requisitos - identificação

Algumas dificuldades típicas estão associadas:

• O cliente pode não saber exatamente o que deseja para o sistema, ou sabê-lo mas não conseguir articulá-lo (o que é bastante comum).

• Os requisitos identificados podem não ser realistas (do ponto de vista econômico ou tecnológico, por exemplo).

• Cada parte interessada pode expressar os mesmos requisitos de formas diferentes, sendo necessário - através de um bom conhecimento do domínio - identificar estas situações.

Engenharia de Requisitos - identificaçãoTécnicas para levantamento de requisitos: Entrevistas e Questionários

• É a técnica mais simples de utilizar. Está condicionada a alguns fatores:• Influência do entrevistador nas respostas do cliente: convém que o entrevistador dê

margem ao entrevistado para expor as suas ideias sem as enviesar logo à partida.

• Relação pessoal entre os intervenientes na entrevista.

• Predisposição do entrevistado: caso, por exemplo, o papel do entrevistado venha a ser afetado pela introdução de um sistema na organização, este pode propositadamente dificultar o acesso à informação.

• Capacidade de seguir um "plano" para a entrevista: na ausência destes planos é natural que haja tendência para que os intervenientes se dispersem um pouco, levando a que a entrevista demore mais tempo do que seria suposto. Caso a entrevista se torne demasiado longa, as pessoas podem cair na tentação de "querer despachar" sendo os últimos pontos da entrevista abordados de forma superficial (ou podem nem chegar a ser abordados).

Engenharia de Requisitos - identificaçãoTécnicas para levantamento de requisitos: Workshops de requisitos

• Consiste numa técnica usada através de uma reunião estruturada, da qual devem fazer parte um grupo de analistas e um grupo representando o cliente , para então obter um conjunto de requisitos bem definidos.

• Ao contrário das reuniões, promove-se a interação entre todos os elementos presentes no workshop fomentando momentos de descontração como forma de dinamizar o trabalho em equipe, existindo um facilitador neutro cujo papel é conduzir o workshop e promover a discussão entre os vários intervenientes.

• As tomadas de decisão devem seguir processos bem definidos e devem resultar de um processo de negociação, mediado pelo facilitador. Uma técnica que é também útil em workshops é o uso de brainstorming como forma de gerar um elevado número de ideias numa pequena quantidade de tempo.

• Como resultado dos workshops deve ser produzida documentação que reflita os requisitos e decisões tomadas sobre o sistema a implementar.

Engenharia de Requisitos - identificaçãoTécnicas para levantamento de requisitos: Cenários

• Uma forma de levar as pessoas a imaginarem o comportamento de um sistema. Através de exemplos práticos descritivos do comportamento de um sistema, os seus usuários podem comentar acerca do seu comportamento e da interação que esperam ter com ele. Trata-se de uma abordagem informal, prática e aplicável a qualquer tipo de sistema. De um modo geral, os cenários devem incluir os seguintes elementos:• estado do sistema no início do cenário;• sequência de eventos esperada (na ausência de erros) no cenário;• listagem de erros que podem ocorrer no decorrer dos eventos do cenário e de

como estes erros serão tratados;• outras atividades que podem ser executadas ao mesmo tempo que as deste

cenário;• estado do sistema depois de o cenário terminar.

Engenharia de Requisitos - identificaçãoTécnicas para levantamento de requisitos: Prototipagem

• Versão inicial do sistema, baseada em requisitos ainda pouco definidos, mas que pode ajudar a encontrar desde cedo falhas que através da comunicação verbal não são tão facilmente identificáveis.

• São desenvolvidas apenas algumas funcionalidades sendo normalmente desenvolvidas primeiro aquelas que são mais fáceis de compreender por parte do utilizador e que lhe podem trazer maior valor acrescentado.

• O uso de protótipos deve ser considerado apenas mediante uma análise custo-benefício, já que os custos de desenvolvimento de um protótipo podem facilmente crescer, sendo particularmente úteis em situações em que a interface com os usuários é, para eles, um aspecto crítico.

Engenharia de Requisitos - identificaçãoTécnicas para levantamento de requisitos: Estudo etnográfico

• Análise de componente social das tarefas desempenhadas numa dada organização.

• Quando um dado conjunto de tarefas se torna rotineiro para uma pessoa, é de se esperar que esta sinta dificuldade em articular todos os passos que segue ou todas as pessoas com as quais interage para as levar a cabo.

• Através de uma observação direta das atividades realizadas durante um período de trabalho de um funcionário é possível encontrar requisitos que não seriam observáveis usando técnicas convencionais.

• Esta observação pode ser acompanhada de registros áudio/vídeo, porém não convém usá-los em demasia visto que o tempo necessário para os processar pode ser demasiado. Nesta técnica assume-se que o representante do cliente observado desempenha as suas funções "corretamente", pelo que convém ter algum cuidado na escolha do mesmo.