Paradigmas De Análise e Desenvolvimentos (CCT0305/2F2614653) - Resumo aulas 1-10

Prévia do material em texto

AULA 1 - PARADIGMAS DE LPS E PROGRAMAÇÃO 
As linguagens de programação permitem a escrita dos programas, que serão integrados 
para compor o software. 
 
1 - Tornar mais produtivo o trabalho dos programadores; 
2 - Padrões de qualidade pré-estabelecidos, confiabilidade, manutenibilidade e eficiência; 
3 - Atender as expectativas e requisitos de seus usuários. 
 
● Concepção do Sistema - Expostas as idéias; 
● Análise de requisitos - Ambiente, requisitos e funcionalidades; 
● Projeto de Software - Arquitetura do sistema; 
● Implementação - Escrita dos programas na linguagem selecionada; 
● Testes - Se atende às exigências das especificações; 
● Manutenção - Oferecem recursos de modularização; 
● Conclusão - Linguagens de programação influenciam e sofrem influência das fases. 
 
Ambiente de linguagem de programação <- Motiva -> Técnicas de programação <- 
Demandam -> Técnicas de Análise e Projeto de Sistemas; 
 
Paradigma ​- Conjunto de características que servem para categorizar um grupo de 
linguagens com características semelhantes e que apoiem o desenvolvimento de sistemas 
com determinadas características. 
● Imperativo/Procedural 
● Orientado a Objetos 
● Concorrente 
● Funciona 
● Lógico 
 
LISP - Paradigma Funcional 
Paradigma Lógico - Capacidade humana de raciocinar 
 
AULA 2 - PARADIGMAS DE ANÁLISE E PROJETO DE SOFTWARE 
Processo de desenvolvimento 
● Análise 
● Projeto 
● Implementação 
 
Análise de sistemas: Estudo do sistema e do contexto. São as soluções para o problema 
em estudo. 
● Identificar os requisitos do sistema, levantamento de dados: Entrevistas, brainstorm, 
análise de campo (in locco). 
○ Especificar o que o sistema deve fazer. 
 
Análise ​Tradicional ​- Programação Linear e Modular - Imperativo e Funcional (LPs). 
Análise ​Estruturada ​- Programação Estruturada Lógica de predicados - Imperativo Lógico. 
Análise ​Essencial ​- Programação Estruturada - Imperativo. 
Análise ​Orientada a Objet​o - Programação Orientada a Objeto - Orientado a Objeto. 
 
A análise estruturada - Requisitos e funcionamento. 
● Por onde começar 
○ Análise Essencial de Sistemas, identificação de eventos; 
● Separação entre aspectos lógicos e físicos, ao modelar o sistema 
○ Análise Estruturada Moderna, sistema deve satisfazer os requisitos dos 
usuários. 
● A identificação das principais funções do sistema 
○ Análise Essencial, tentou minimizar; 
● O DFD dava pouca ênfase a análise de dados 
○ DFD particionado, elaborando-se o Modelo de Entidade e Relacionamento; 
● Um DFD desenvolvido com a técnica de análise estruturada sempre é diferente se 
feito por profissionais diferentes. 
 
A Análise ​Essencial ​- Satisfazer os requisitos dos usuários. 
 
Paradigma da análise orientada a objeto (OO): "conjunto de objetos relacionados". 
● Mudança do paradigma Essencial para o Paradigma Orientado a objetos 
 
AULA 3 - ANÁLISE ESTRUTURADA 
Auxiliar no processo de desenvolvimento de sistemas, especificamente na fase de análise e 
definição de sistemas. 
 
Baseada na construção de modelos utilizando técnicas gráficas, como diagramas. 
Objetivos - Auxiliar no estudo de partes ou toda a empresa. 
1. Cria modelos 
2. Retrata, nos diagramas, os fluxos de dados 
3. Usa a técnica de refinamentos sucessivos ou top down. 
 
DFD:​ Modelo funcional, que apresenta a rede dos processos do sistema em 
desenvolvimento, interligados por fluxos de dados. 
 
- ​Processo:​ Representa as ações que o sistema executa. 
- ​Fluxo de dados:​ Informações que trafegam pelo sistema. 
- ​Depósito de dados: ​Armazenam (temporariamente) os dados que fluem no 
sistema. 
- ​Entidade Externa:​ Não fazem parte do sistema, mas interagem com ele. 
 
A análise estrutural propõe a elaboração do DFD em níveis. 
Nível 1 - Diagrama de Contexto: Sistema como um único processo, com entidades 
externas e fluxos de entrada/saída. 
Nível 2 - Diagrama Zero: Macro-funções. 
Nível 3 - Detalhes dos principais processos. 
Nível 4 - Especificação da lógica dos processos. 
 
Balanceamento do DFD 
 
REGRA GERAL: Ao particionar (explodir) um processo, qualquer fluxo, depósito ou 
entidade que esteja em 1 nível, deve aparecer no nível imediatamente anterior. 
Só devem ser especificados os processos primitivos do DFD 
 
Dicionário de Dados (DD) - Explicando melhor seus elementos: entidades, fluxos de dados 
e depósito de dados. 
- Especificações dos processos 
- Considerações da especificação 
- Características da especificação: "o que o processo deve fazer" 
 
- Identificar Entidades 
- Identificar Entradas/Saídas 
- Desenhar diagrama de contexto 
- Identificar consultas e pedidos de informação 
- Identificar processos 
- Desenhar diagrama (nível 0) 
 
MER - É um modelo de dados, de alto nível de abstração que mostra o relacionamento dos 
dados que são armazenados em um sistema. 
- Entidade 
- Relacionamento 
- Atributo das entidades 
 
AULA 4 - ANÁLISE ESSENCIAL 
 Elaborar, inicialmente o modelo ideal, descrevendo os requisitos que o sistema 
precisa ter, sem qualquer preocupação de como será a implementação. 
 
Tecnologia Perfeita, que é caracterizada por: 
- Capacidade ilimitada de processamento 
- Capacidade ilimitada de armazenamento 
- Não custa nada (zero) 
- Infalível 
 
O Conceito de Evento 
 
Eventos --> Estímulos --> Sistema (Funções) --> Respostas --> 
 
Eventos: Causa! 
Estímulos: Função predeterminada, produz resposta esperada. 
Respostas: Resultado de um evento. 
 
Atividade Fundamental (memória entra) - Produz informação que é parte do 
propósito do Sistema. 
Atividade de Custódia (memória sai) - Cria e mantém a memória essência para 
executar atividades. 
Atividade Composta (memória entra/sai) - Executa tarefas dos dois tipos. 
 
Nos DFD a memória essencial é representada pelos depósitos de dados. 
DER (Diagrama de Entidade e Relacionamento) mostra o relacionamento entre a 
memória essencial. 
 
Resumo dos Conceitos da Análise Essencial 
Requisito Verdadeiro 
Requisito Falso - Não necessário ao usuário. 
Essência do Sistema - Conjunto de requisitos verdadeiros. 
Atividades Essenciais - Armazenam dados necessários para execução das atividade 
essências. 
Memória Essencial Evento 
Estímulo 
Resposta 
 
Eventos Orientados por Fluxo de Dados - Nem todo fluxo de dados que chega ao 
sistema serve de estímulo. 
Eventos Orientados por Controle - Pode Haver fluxos de dados complementares. 
Eventos Orientados por Tempo (temporal) 
 
Os componentes do modelo ambiental são: 
 Declaração dos Objetivos do Sistema. 
 Diagrama de Contexto do Sistema. 
 Lista de Eventos que afetam o Sistema. 
 
AULA 5 - ANÁLISE ESSENCIAL II 
As atividades do Modelo Comportamental compreendem: 
1. DFD particionado por Evento. 
2. Diagrama de Entidade e Relacionamento (DER). 
3. DFD por níveis 
a. DFD Preliminar. 
b. DFD Nível Zero. 
c. DFD de nível, dentro da necessidade de detalhamento do sistema. 
4. Dicionário de Dados (DD). 
5. Mini especificação dos processos primitivos (não são explodidos em outro nível) do 
DFD de nível. 
6. 6. Diagrama de Transição de Estados (DTE). 
 
Diagrama de Entidade e Relacionamento (DER) 
DFD Preliminar, que é obtido integrando-se todos os DFD’s dos eventos em um único DFD. 
 
A Análise Essencial utiliza a abordagem middle-out. Parte de uma situação intermediária (o 
DFD preliminar), para os níveis mais baixos (abordagem top-down) e para o Diagrama de 
Nível Zero (abordagem bottom-up). 
 
Derivar DFD Preliminar 
1º Analise os processos 
2º Desenho os depósitos de dados e repita os desenhos, caso necessário. 
3º Desenho as entidades externas e repita os desenhos, caso necessário. 
4º Desenhe os fluxos de dados de/para os depósitos de dados 
5º Desenhe os fluxos de dados de/para as entidades externas 
 
Diagrama de Transiçãode Estados (DTE) - Representa o comportamento dos objetos dos 
sistema em função da passagem do tempo. 
● Estado - Situação. 
● Transição - Passagem de um estado para outro. 
● Ação - Transição de Estado 
● Condição - Causa da transição 
 
1. Construir ou usar a lista de eventos do sistema 
2. Ordenar os eventos cronologicamente 
3. Para cada evento, identificar a respectiva transição do estado 
4. Para cada transição de Estado 
a. Identificar o estado de partida e de chegada. 
b. Identificar a condição que provoca a transição de estado. 
c. Identificar a ação ativada pela ocorrência da condição. 
5. Para cada estado: 
a. Verificar qual a transição para a qual ele é o estado de chegada. 
b. Verificar se há transição de saída dele (condições normais e anormais) 
 
Lista de eventos 
● Número de Eventos 
● Nome do Evento 
● Tipo do Evento: Fluxo, Controle ou Tempo. 
● Estímulos 
● Ações: Resposta aos estímulos 
● Respostas: Fluxo de dados de saída ou Fluxo de dados para Manutenção de 
depósito 
 
Declaração dos objetivos do Sistema 
Qual a finalidade do sistema? 
Que requisitos devem ser atendidos? 
Vai substituir algum sistema? 
O que o sistema não vai controlar? 
Que problemas o sistema deve resolver? 
 
 
AULA 6 - ANÁLISE ORIENTADA A OBJETO (PARTE 1) 
UML - Unified Modeling Language 
- Não é metodologia nem processo de desenvolvimento 
- Linguagem que permite a construção de vários diagramas 
- Auxiliar a modelagem de um sistema 
- Pode ser usado em qualquer processo de desenvolvimento de software 
- A UML não especifica por qual diagrama começar 
 
Diagramas Estruturais 
- Aspecto estrutural de um sistema de software o que abrange a existência e a 
colocação: ​Classes, interfaces, colaborações e componentes. 
- Diagrama de Classes:​ Mostra as classes do domínio do problema. 
- Diagrama de Pacotes: 
- Diagramas de Componentes 
- Diagramas de Objetos 
- Diagramas de Estruturas Composta 
- Diagrama de Utilização 
 
Diagramas Comportamentais 
- Como o sistema responde 
- Diagramas de Casos de Uso:​ Especificam o comportamento do sistema (ou 
parte dele), descrevendo as funcionalidades deste. 
- Diagrama de Estado 
- Diagrama de Atividades 
- Diagramas de Interação 
- Diagrama de sequência: ​Interação entres os objetos (classes) de um 
determinado cenário 
- Diagrama de Visão Geral de Interação 
- Diagrama de comunicação 
- Diagrama de Temporização 
 
O Tripé da Análise 
A fase de análise requer a especificação dos requisito (Modelo de Requisitos). 
 
Diagrama de Casos de Uso: 
1. As funcionalidades (caso de uso) do sistema, do ponto de vista do usuário. 
2. Os atores (interface) que interage com o sistema 
3. Eventuais relacionamentos entre os casos de uso e entre os atores. 
 
Com ​pacotes ​é possível criar um primeiro diagrama principal contendo todos os pacotes 
maiores do sistema e, a seguir, explodir cada pacote em um novo diagrama 
 
Diagrama de Classes: 
1. Mostram as classes que constituem o sistema, respectivos relacionamentos entre 
elas. Inicialmente o diagrama apresenta as classes do negócio (entidades). 
2. Diagrama de Classes de Projeto. Mostram como será a arquitetura do sistema, 
classes de controle, classes de interface (fronteira) e classes auxiliares. 
a. Classe de fronteira (Boundary) ou interface: Responsável pela interação com 
os atores. 
b. Classes de controle: Coordenação da interação entre os objetos 
3. Durante a implementação (codificação) novas classes podem surgir. 
 
● Passo 1: Identificação das Classes nos casos de uso 
● Passo 2: Identificação dos atributos e métodos no mini mundo 
● Passo 3: Identificação dos relacionamentos 
● Passo 4 : Cardinalidade dos relacionamento 
 
Diagrama de sequência: 
1. Demonstrar a interação entre os objetos envolvidos na realização de uma cenário. 
a. Um cenário é um conjunto de passos contidos em um caso de uso. 
b. Identificar novos métodos para as classes. 
2. O Diagrama de Sequência deve ser elaborado para cada cenário de uso. 
 
AULA 8 - PRÁTICA DE ANÁLISE ESSENCIAL 
Atividades que antecedem a modelagem do sistema. 
 
Fase de concepção:​ Todos os dados abaixos são agrupados em um documento chamado 
de Documento de Viabilidade, Relatório de Concepção, Mini Mundo, além de outros nomes. 
● Viabilidade técnica e econômica. 
● Identificados e documentados os envolvidos, objetivos, abrangência e requisitos. 
 
Fase de análise: ​Recebe os documentos da fase de concepção desenvolvido pelo(s) 
mesmo(s) analista(s) de sistema(s) que será(ão) responsável(is) pela fase de análise. 
1. Levantamento de dados 
2. Elaboração do documento de requisitos de análise 
3. Validação dos requisitos com o usuário 
4. Modelagem de sistema, segundo a técnica da Análise Essencial que compreende: 
a. Modelo Ambiental: Lista de objetos e eventos e Diagrama de contexto. 
b. Modelagem Comportamental: 
i. DFD (Diagrama de fluxo de Dados) particionada por evento, Modelo 
de dados (integração DBA) e Modelo de controle. 
ii. DFD por níveis. 
iii. Dicionário de dados. 
iv. Especificação de processos. 
5. Validação dos requisitos e modelagem (Prototipação) 
 
Levantamento de Dados: ​Entender e detalhar o funcionamento da empresa e definir os 
requisitos dos usuários​.​ Entrevista, reuniões, questionários e brainstorm. 
1. Contextualizar a empresa:​ Identificação das áreas se necessário o uso de 
organograma. 
2. Identificar o objetivo geral do sistema: ​Clareza sobre o desenvolvimento do 
sistema. 
3. Confirmar ou definir o escopo do sistema: ​Já deve existir no documento inicial 
caso não exista deve ser definido nesse momento. 
4. Identificar os eventos que afetam o sistema: ​Base para a modelagem. 
 
Elaboração do Documento de Requisitos de Análise: ​Complemento do documento 
inicial. Contendo retificações, definição não constante e complemento de informações. 
 
Validação dos Requisitos com Usuário: ​Revisão dos requisitos, junto aos usuários. Cada 
uma das necessidades que serão traduzidas em funcionalidades no sistema. 
 
Lista de Objetivos do Sistema 
Lista de Eventos do Sistema: ​Estímulos, Função e Resposta. 
 
MER (Modelo Entidade Relacionamento): ​Obtido por particionamento por evento. 
Analisando ​as entidades envolvidas e acrescentando as entidades, atributos e 
relacionamentos ao diagrama. Ou ​Analisando ​os depósitos de dados e identificando o 
relacionamento entre eles. 
 
DTE (Diagrama de Transição de Estado): ​Deve ser feito para cada entidade que tenha 
mais de um estado. 
1. Identificar os estado possíveis 
2. Transições 
3. Estado inicial e final 
 
Dicionário de Dados: ​Definir cada elemento constante do conjunto de DFD. 
 
Especificação de Processos: ​ Desenvolvimento do DFD em níveis e especificar a lógica 
dos processos que não foram explodidos no DFD, chamados de Processos Primitivos. 
 
Validação dos Requisitos e Modelagem: ​Usuário não tinha segurança de validar pelos 
modelos e sim por textos ou algo que relacionasse as funcionalidades do sistema. 
 
AULA 9 - PRÁTICA DE ANÁLISE ORIENTADA A OBJETO - PARTE I 
A visão de ator é de quem interage com o sistema e não quem troca informações, 
como no caso de Entidade Externa. 
Outro tipo de Refinamento possível acontece com os casos de extensões (extends). 
 
1. Identificação das Classes e Alguns métodos: Para desenhar o diagrama de Classes 
CONCEITUAL, devemos olhar cada caso de uso, pois: Alguns casos de uso 
derivam. 
2. 1º Versão do Diagrama de Classe Conceitual 
3. Identificação dos atributos das Classes 
 
AULA 10 - PRÁTICA DE ANÁLISE ORIENTADA A OBJETO - PARTE II 
O ​Diagrama de Sequência​ vai mostrar a interação entre os objetos para realizar um 
cenário de uso. 
O ​Diagrama de Estados​ temos que analisar o estudo realizado e identificar que objetos 
terão, pelo menos, dois ou mais estadosao longo de seu ciclo de vida. 
O ​Diagrama de Atividade ​analisar se existe algum caso de uso ou método de uma classe 
cuja especificação seja complexa demais para ser descrita é um diagrama para facilitar o 
entendimento.