ESAB – Pós-graduação em Engenharia de Sistemas Módulo: Metodologia de Análise de Sistemas
RESUMO UNIDADE 1: Introdução à Análise de Sistemas
Mostra um pouco do histórico desde a revolução industrial até a Era da Informação, com a necessidade das organizações de definir métricas e planejamento.
UNIDADE 2: Revisão Geral de Engenharia de Software Modelo Cascata: progressão em sequência das etapas:
• Levantamento de Requisitos; • Análise de Requisitos; • Projeto; • Implementação; • Testes; • Implantação.
Modelo Iterativo e Incremental: ciclos de desenvolvimento (iterativo), cada ciclo contempla as fases (análise, projeto, implementação e testes) adicionando as features novas (incremental). O
gerenciamento de riscos é facilitado nesta abordagem.
UNIDADE 3: Estrutura geral de um Desenvolvimento Incremental e Iterativo Gráfico das baleias, RUP.
Basicamente o processo tem fases (concepção, elaboração, construção e transição). Em cada fase, ocorrem iterações (em geral, divididas em atividades: levantamento de requisitos, análise de requisitos, projeto, implementação, testes e implantação).
Ao final de cada fase, temos marcos, úteis para o gerente do projeto estimar gastos e andamento do cronograma.
• Concepção: ideia geral, escopo do desenvolvimento (planejamento de alto nível);
• Elaboração: encerra o planejamento do projeto, analisa-se o domínio do negócio e organiza-se o conjunto de requisitos;
• Construção: maior ocorrência de atividades de análise e projeto;
• Transição: treinamento de usuários, instalação e configuração do sistema são tratadas aqui. UNIDADE 4: Levantamento de Requisitos
Dados do chaos report:
• Projetos que terminam dentro do prazo estimado: 10% • Projetos descontinuados antes do fim: 25%
• Projetos acima do custo esperado: 60% • Atraso médio de projetos: 1 ano
Requisito: condição ou capacidade que deve ser alcançada ou possuída por um sistema ou componente para satisfazer um contrato, padrão, especificação ou documentação formalmente imposta.
Levantamento de Requisitos: estudo exploratório das necessidades do usuário dentro do domínio do problema. Seu produto final é o DOCUMENTO DE REQUISITOS.
Tipos de Requisitos:
• Funcionais : definem as funcionalidades do sistema (normalmente são descritos em UML, nos Casos de Uso);
• Não-funcionais : características de qualidade ou desempenho que o sistema deve possuir, que estão relacionadas às suas funcionalidades, por exemplo:
• Confiabilidade : tempo médio entre falhas, recuperação de falhas, etc; • Desempenho : tempos de resposta;
• Portabilidade : restrições em plataformas de hardware e software; • Segurança : limitações quanto a acessos não-autorizados;
• Usabilidade : facilidade de uso e necessidade de treinamento de usuários.
Destaca a importância da análise de requisitos bem feita como fator-chave no desenvolvimento do projeto e o documento de requisitos como o contrato entre desenvolvedores e usuários.
“O sistema é avaliado pelo seu grau de conformidade aos requisitos e não em relação à tecnologia empregada ou elegância e complexidade da solução”.
UNIDADE 5: Análise de Requisitos
Etapa na qual os analistas fazem um estudo detalhado no Documento de Requisitos, construindo modelos para representar o sistema a ser construído.
A Análise de Requisitos não deve levar em conta o ambiente de desenvolvimento a ser utilizado. O modelo deve especificar “o que” precisa ser feito (“como será feito”, é em outra etapa).
Modelos devem ser analisados e validados com cuidado antes de começar a construção do sistema. A prototipagem é uma técnica que complementa a análise de requisitos. Após o processo de validação e refinamento do protótipo, ele pode ser descartado ou utilizado como versão inicial do sistema. O protótipo é mais adequado para validação do que os diagramas, permitindo a
participação direta do usuário.
*não use protótipos no lugar dos modelos. Construa os modelos do sistema. UNIDADE 6: Projeto, Implementação, Testes e Implantação
Na fase de Projeto, determina-se “como” o sistema irá funcionar para atender aos requisitos. Nesta fase, existe dependência da tecnologia, que pode acrescentar restrições aos modelos construídos na fase de análise. A fase de Projeto possui 2 atividades:
• Projeto de Arquitetura: de alto nível, distribuindo as classes de objetos do sistema em subsistemas e componentes. Normalmente faz uso da UML com Diagramas de Implementação;
• Projeto Detalhado: de baixo nível, modela as colaborações entre os objetos de cada módulo, interface com o usuário e base de dados. Normalmente faz uso da UML com Diagramas de Classes, Casos de Uso, Interação, Estados e Atividades.
Na fase de Implementação, o sistema é codificado de fato, utilizando a linguagem e tecnologia definida para o projeto.
Na fase de Testes, as características são verificadas e o sistema é integrado, utiliza-se o Relatório de Testes como saída.
Na fase de Implantação, o pacote de instalação é criado, juntamente com manuais, treinamentos e migração de sistemas legados.
UNIDADE 7: Metodologia e Análise de Sistemas no contexto de Engenharia de Software • Métodos: caminho (processo) sistemático pelo qual se atinge um objetivo;
• Metodologia: estudo dos métodos, avaliando-os e analisando-os, para direcionar as escolhas apropriadas dentro de um trabalho.
Benefícios da Metodologia bem implantada:
• Aumento de Qualidade dos Sistemas: pela existência de métodos bem definidos para levantamento de requisitos, e documentação com notação padronizada que facilita a comunicação;
• Independência dos Analistas: com uma boa documentação, é possível que quaisquer analistas possam fazer a manutenção do sistema, mesmo sem conhecimento prévio; • Facilidade de Manutenção: consequência do item anterior, as manutenções ficam mais
simples e rápidas;
• Aumento da Produtividade: sistemas bem construídos, apresentam facilidade de reutilização de algumas de suas partes;
Destaca-se a importância de Métricas de Software para poder conhecer melhor os problemas e atuar sobre eles.
Objetivos de uma Metodologia:
• Criação de ferramentas para possibilitar o desenvolvimento de projetos na empresa, de acordo com os princípios básicos de administração (planejamento, previsão, organização, decisão, comando, coordenação e controle);
• Promover cumprimento de prazos, eficiência e qualidade de serviço (padronizando atividades de desenvolvimento e racionalizando a documentação);
UNIDADE 8: Funções de um Analista de Sistema
Analista de Sistemas é o profissional que deve conhecer o domínio do negócio, para poder definir os requisitos.
Especialistas do Domínio são pessoas que tem familiaridade com o domínio do negócio mas não com desenvolvimento de software (normalmente serão usuários do sistema).
O Analista de Sistemas faz a “ponte” entre os especialistas do negócio e os desenvolvedores do sistema.
O texto descreve alguns aspectos do comportamento de um analista e da conduta que ele deve adotar durante o projeto.
A seguir descreve os aspectos históricos do desenvolvimento de software desde a década de 50 (de sistemas de baixa complexidade e sem planejamento até as metodologias modernas e estruturadas de desenvolvimento do final da década de 90).
Aborda as ferramentas CASE como automação da metodologia, com foco não só na implementação, mas também na produtividade.
UNIDADE 9: Principais metodologias aplicadas a desenvolvimento de sistemas Tipos de metodologias:
• Estruturada: sucessivos detalhamentos desde o nível macro até o detalhe de nível mais baixo (visão top-down). Normalmente utiliza DFD (Data Flow Diagram), DER (Diagrama
Entidade-Relacionamento) para estabelecer as visões de cada componente, criando um modelo lógico do negócio, uma visão abstrata do mundo real;
• Desenvolvimento Ágil: foco em ciclos rápidos de desenvolvimento, com microgerenciamento, sem toda a burocracia dos métodos mais “pesados”;
• Orientada a Objetos: utiliza modelagem orientada a objetos, das quais a UML é a principal linguagem.
UNIDADE 10: Metodologia Estruturada
Especificação Funcional do Sistema: documento gerado na Análise Clássica, descrevendo o sistema.
Em geral esses documentos possuem as características: • monolíticos;
• redundantes (repetição de informações); • difíceis de modificar e manter;
• mistura especificações físicas e lógicas, dificultando a discussão sobre a real necessidade do usuário.
A Metodologia Estruturada promove uma melhoria deste processo, com ferramentas gráficas para a documentação. As ferramentas são:
• Diagrama de Fluxo de Dados (DFD): representa a movimentação dos dados no sistema; • Dicionário de dados: contém as definições lógicas de todos os nomes de dados apresentados
no DFD;
• Especificação de Processo: documento estruturado detalhando os níveis representados no DFD;
• Diagrama Entidade-Relacionamento(DER): enfatiza os principais objetos ou entidades do sistema e seus relacionamentos.
Características da Análise Estruturada:
• Modular: quebra o conceito monolítico da Análise Clássica; • Gráfica: mais figuras que palavras;
• Top-Down: descrição do sistema em níveis progressivamente detalhados; • Lógica: modelo independente da implementação.
UNIDADE 11: Diagramas de Fluxo de Dados
O DFD representa o fluxo de dados num sistema de informação e as sucessivas transformações deles.
É a ferramenta mais usada para documentação na fase de análise (normalmente no método convencional de desenvolvimento).
Elementos básicos do DFD:
• Entidades Externas: são elementos (ou subsistemas) fora do sistema em análise que recebem/enviam dados de/para o sistema;
• Fluxo de dados: dados que fluem entre processos, arquivos e entidades externas, sem especificação temporal;
• Arquivo de Dados: armazenamento de dados;
• Processo: recebe dados de entrada e transforma os dados em fluxo de saída. Os objetos e processos precisam de nomes indicando o que fazem.
A abordagem é top-down, cada nível de detalhe é representado em diferentes níveis de DFDs. UNIDADE 12: Modelo e Diagrama de Entidade-Relacionamento
MER → modelo conceitual, representado por um gráfico (DER). As Entidades devem ser vistas sob o enfoque de dados (sem rotinas ou procedimentos).
Representações e características: • Entidades: retângulo horizontal; • Relacionamentos: losango;
• Pode haver um relacionamento entre mais de 2 Entidades; • Relacionamentos podem conter atributos;
• Pode haver mais de 1 relacionamento entre 2 Entidades. Terminologias:
• Entidade: componentes físicos e abstratos onde são armazenados dados; • Atributo: propriedade de uma Entidade, caracterizando-a;
• Ocorrência: conjunto de atributos de uma dada Entidade; • Relacionamento: correspondência entre 2 Entidades;
• Identificador ou Atributo Determinante: atributo ou conjunto de atributos que determina de modo único uma ocorrência de Entidade;
• Grau de Relacionamento: número de Entidades que participam da associação;
• Classe de Relacionamento (Cardinalidade): quantas ocorrências de cada Entidade estão envolvidas no relacionamento ( 1:1, 1:n ou m:n ).
A seguir descreve as etapas de criação de um DER (descrever as entidades, criar relacionamentos com nomes, identificar as cardinalidades, etc).
Depois enumera algumas recomendações para se elaborar um bom DER (conhecer o mundo real, modelar bem as entidades, identificar seus atributos, analisar bem os relacionamentos e as
agregações, etc).
UNIDADE 13: Metodologia Estruturada, evolução ao longo do tempo
Descreve o histórico da Metodologia Estruturada, com seu surgimento numa época em que o desenvolvimento de sistemas não possuía nenhum padrão. Com isso, houve uma melhora (DFDs, DERs e documentação).
Mas a comunicação entre desenvolvedores e usuários ainda não era fácil, e com isso as metodologias orientadas a objeto ganharam força.
UNIDADE 14: Modelagem Orientada a Objetos
Cita o exemplo da casa de cachorro do Guia de UML (que basicamente mostra a importância de um projeto estruturado, modelado e documentado – arquitetura, processos e ferramentas).
UNIDADE 15: Modelo – Definições práticas
Modelo é uma simplificação da realidade, podendo ser (estrutural ou comportamental). Objetivos da modelagem:
• visualizar a arquitetura de um sistema;
• especificar a estrutura e comportamento do sistema; • guia de construção para o sistema;
• documentar as decisões. Vantagens da modelagem:
• Analogia com outras engenharias (necessidade de modelos); • Gerenciamento da Complexidade;
• Facilidade de comunicação entre os envolvidos;
• Redução de custos de desenvolvimento (correções e alterações); • Análise de comportamentos futuros do sistema.
UNIDADE 16: Os 4 Princípios da Modelagem
• A escolha do modelo tem profunda influência sobre a maneira como um determinado problema é atacado e como uma solução é definida;
• Cada modelo poderá ser expresso em diferentes níveis de precisão; • Os melhores modelos estão relacionados à realidade;
por meio de um pequeno conjunto de modelos, quase independentes um do outro. UNIDADE 17: Definições e apresentação da UML
UML → Padrão para a planejamento de arquitetura de projetos de sistemas (processos de negócio, funções do sistema, classes, esquemas de banco de dados etc).
Surgiu como resultado da união dos 3 métodos principais (Booch, OMT e OOSE). É uma linguagem de modelagem (não é método nem metodologia).
Atividades que a UML auxilia: • Visualizar;
• Especificar; • Construir; • Documentar; Visões da UML:
• Visão de Casos de Uso → descreve o sistema do ponto de vista externo (interações entre o sistema e os agentes externos);
• Visão de Projeto → foco nas características de suporte estrutural e comportamental às funcionalidades do sistema;
• Visão de Implementação → gerenciamento de versões do sistema;
• Visão de Implantação → distribuição física do sistema, seus subsistemas e a conexão entre essas partes;
• Visão de Processo → foco nas características de concorrência (paralelismo), sincronização e desempenho do sistema.
As visões devem ser utilizadas em função da necessidade (complexidade do sistema). UNIDADE 18: Paradigma de Orientação a Objetos
Princípios:
• Qualquer coisa é um objeto;
• Objetos realizam tarefas requisitando serviços de outros objetos; • Cada objeto pertence a uma classe;
• Classe é um repositório de comportamentos de objetos; • Classes possuem hierarquias.
Orientação a Objetos (objetos e interações) x Análise Estruturada (dados e processos). Terminologias:
• Classes → ideias, abstrato;
• Objetos → uma instância concreta de uma classe; • Atributos → estado de um objeto;
• Mensagens → requisição de um método de um objeto.
UNIDADE 19: Conceitos Básicos do Paradigma de Orientação a Objetos
• Encapsulamento: restrições de acesso ao comportamento interno dos objetos, só a interface é visível;
• Polimorfismo: capacidade de abstrair diferentes implementações de uma mesma interface; • Herança: abstração para especializar e generalizar comportamentos de objetos.
UNIDADE 20: Principais Linguagens Orientadas a Objetos no mercado Primeira linguagem → Simula (1962).
SmallTalk → totalmente orientada a objetos.
Linguagem híbrida: p. ex. C++ (C estendido para contemplar OOP). Enumera mais algumas linguagens (java, object pascal).
UNIDADE 21: Casos de Uso – Conceitos Básicos
Maior dificuldade de modelagem de um sistema → Gerenciamento de Requisitos.
Modelo de Casos de Uso → trabalha os requisitos funcionais do sistema, composto por casos de uso, atores e relacionamentos entre eles.
Um caso de uso é a especificação de uma sequência de interações entre um sistema e os agentes externos. Deve definir o uso de uma funcionalidade sem revelar a estrutura e os comportamentos internos desse sistema.
UNIDADE 22: Casos de Uso (continuação) – Características principais
• Formato → narrativa descritiva usando texto livre (claro, usando um vocabulário comum e apropriado ao entendimento do negócio). Formato pode ser;
• Descrição numerada → passos descritivos;
• Descrição particionada → tabela particionada em colunas, uma para o ator e outra para o sistema;
• Detalhamento → pode ser sucinto ou não, dependendo do caso (sem necessariamente expandir as ações);
• Abstração → o caso de uso pode ser:
• Essencial → mais abstrato, sem menção à tecnologia utilizada;
• Real → as descrições das interações citam detalhes da tecnologia a ser usada na implementação.
*um bom caso de uso essencial seguiria a “regra dos 100 anos”. (mais ou menos, na verdade) UNIDADE 23: Casos de Uso (continuação) – Elementos constituintes
• Atores → qualquer elemento externo que interage com o sistema (pessoas, organizações, outros sistemas, equipamentos). A escolha do nome do ator é relevante;
• Relacionamentos:
• comunicação: interação Ator e Casos de Uso, por meio do envio e recebimento de mensagens;
• inclusão: interação entre Casos de Uso, quando existem cenários cujas ações atendem a mais de um caso de uso (um caso inclui o procedimento de outro); • extensão: interação entre Casos de Uso, indicando que um deles irá estender outro
(identificado como base), por exemplo: casos de exceção, caminhos opcionais; • generalização: interação entre Casos de Uso ou entre Atores, quando temos
elementos semelhantes mas com um deles realizando algo a mais. UNIDADE 24: Diagramas da UML
2 categorias:
• Estruturais (características estáticas) • Classes; • Estrutura Composta; • Componentes; • Implantação; • Objetos; • Pacotes;
• Atividades; • Casos de Uso; • Máquinas de Estado; • Sequência; • Comunicação; • Visão Geral; • Temporal.
UNIDADE 25: Exemplos de diagramas de UML
Mostra exemplos do Diagrama de Classes e de Estrutura (p.117-118). UNIDADE 26: Exemplos de diagramas de UML (continuação)
Mostra exemplos do Diagrama de Componentes e de Instalação (p.119-120). UNIDADE 27: Exemplos de diagramas de UML (continuação)
Mostra exemplos do Diagrama de Objetos e de Pacotes (p.122-123). UNIDADE 28: Exemplo UML (Hello World do Java)
Retirado do UML: Guia do Usuário. Mostra o começo do modelo (visão geral). UNIDADE 29: Exemplo UML (Hello World do Java)
Retirado do UML: Guia do Usuário. Mostra o modelo (diagrama de classes, hierarquias, interface e diagrama de pacotes).
UNIDADE 30: Exemplo UML (Hello World do Java)
Retirado do UML: Guia do Usuário. Mostra o modelo dinâmico (diagrama de sequência, diagrama de componentes). Explica detalhadamente o diagrama de sequência.
