ANÁLISE E PROJETO DE SISTEMA

Transcrição

1 ANÁLISE E PROJETO DE SISTEMA

2 Sistema Conjunto de regras ou princípios que regulam a execução de um fenômeno Partes coordenadas que regulam a execução de um fenômeno Combinação de partes que, coordenadas, concorrem para certo fim

3 Sistema de software Sistema baseado em software compondo um sistema computacional (combinação de hardware e software)

4 Projeto A intenção de fazer O que se tem a intenção de fazer Plano para a realização de uma ação Representação gráfica ou escrita Modelo

5 Análise Exame de cada parte de um todo Processo lógico que consiste na investigação das estruturas básicas de uma informação Processo de modelagem

6 Modelagem Atividade de construção de modelos

7 Modelo Gabarito Representação Representação ou interpretação simplificada da realidade

8 Modelar software Modelar software, a grosso modo, é planejar (a partir de modelos) como ele será. Isto é, o que ele fará especificamente (que problemas o seu algoritmo resolverá); e como usuário irá interagir com o aplicativo.

9 Objetivos da modelagem Especificar o algoritmo do software Criar a interface software-usuário Compreender o usuário (o que ele quer, o que precisa, o que gosta, etc) Compreender o ambiente do usuário (afinal o comportamento do usuário vai variar mediante o contexto de uso) Estabelecer casos de uso (ocorrências de comportamentos do usuário em determinados ambientes e contextos de uso).

10 Abstração Simplificação Processo de generalização por redução do conteúdo da informação de um conceito para reter apenas a informação que é relevante para um propósito particular Foco no essencial para entendimento do domínio do problema

11 Processo Conjunto sequencial e particular de ações com um objetivo específico

12 Arquitetura de software Visões desenvolvidas para atender requisitos de qualidade Visão de banco de dados Visão de camadas Visão de negócio Visão organizacional Visão funcional

13 Itens de qualidade Organização Desempenho Portabilidade Confiabilidade Disponibilidade

14 Projeto arquitetural O projeto arquitetural determina o sucesso do projeto de software

15 Engenharia É a ciência e a profissão de adquirir e de aplicar os conhecimentos matemáticos, técnicos e científicos na criação, aperfeiçoamento e implementação de utilidades (materiais, estruturas, máquinas, aparelhos, sistemas ou processos) que realizem uma determinada função ou objetivo

16 Engenharia de software É a aplicação de uma abordagem sistemática, disciplinada e quantificável no desenvolvimento, operações e manutenção de software Área da computação voltada à especificação, desenvolvimento e manutenção de sistema de software, com a aplicação de tecnologias e práticas de gerência de projetos e outras disciplinas, visando organização, produtividade e qualidade

17 Disciplinas de engenharia de Requisitos Projeto (análise e design) Implementação Teste Implantação Manutenção Gestão de projeto Gestão de configuração e mudança Processos Ferramentas e métodos

18 Engenharia da informação

19 Objetivos da engenharia de A engenharia de software surgiu com o objetivo de utilizar princípios de engenharia no desenvolvimento de software para aumentar a qualidade dos produtos oferecidos, diminuir custos e riscos relacionados e criar processos repetíveis e eficazes para serem utilizados nos ciclos de manutenção e desenvolvimento

20 Pressupostos da engenharia de Rigor no Processo (qualidade e eficiência) Medição do processo Repetibilidade Otimização de recursos Base científica

21 Princípios da engenharia de Formalidade Abstração Decomposição Generalização Flexibilização

22 Princípio da Formalidade Desenv.SW é uma atividade criativa e com tal tende a seguir a inspiração do momento. Um enfoque formal pode gerar SW mais confiável e exercer controle sobre seu custo. O nível de formalidade não deve restringir a criatividade e deve ser adequado à dificuldade conceitual de cada desenvolvimento. A formalidade estará contida no projeto (descrição formal), na programação (pgms. são componentes formais), nas rotinas de teste, nos procedimentos da instalação etc.

23 Princípio da Abstração Processo de identificar os aspectos importantes do produto/processo, ignorandose detalhes. Modelos são abstração da realidade. O sistema de informação é uma abstração do processo real. Linguagens de programação abstraem ao programador, detalhes da máquina e da solução (algoritmo em baixo nível) O encapsulamento é uma técnica de abstração para diminuir a complexidade e melhorar a reusabilidade dos objetos.

24 Princípio da Decomposição A decomposição é uma técnica utilizada para permitir lidar com a complexidade. Decomposição do processo Atividades de controle da qualidade, atividades de gerenciamento do cronograma, atividades de gerenciamento de fornecedores externos, atividades de teste, atividades de documentação Decomposição do produto Programas, Módulos ou rotinas, Componentes

25 Princípio da Generalização A abstração, buscando-se as características comuns e esquecendo-se as características específicas dos itens a serem generalizados. Uma solução mais genérica tem maior potencialidade de ser reutilizada (reusabilidade e generalização dos componentes). A generalização é o processo inverso da decomposição (generalização e especialização em OO). Custo do desenvolvimento voltado à generalização versus benefício da reutilização.

26 Princípio da Flexibilização A flexibilização irá conferir ao produto de software a facilidade de adaptação a novos ambientes, a mudanças ocorridas no ambiente, a casos de uso não implementados e às manutenções que se fizerem necessárias. Flexibilização do produto de software: Customização das saídas do sistema; Parametrização do processo e inclusão de variações do algoritmo original; Facilidade em agregar novos módulos/funções Facilidade em portá-lo para outras plataformas

27 Princípio da Flexibilização Flexibilização do processo de software: Procedimentos e técnicas alternativas no processo de software visando: Corrigir erros Corrigir atrasos Adaptar técnicas de outros paradigmas Atender às constantes mudanças de requisitos

28 Crise de software Relacionado às dificuldades enfrentadas no desenvolvimento de software, inerentes ao aumento das demandas e da complexidade delas, aliado à inexistência de técnicas apropriadas para resolver esses desafios

29 Sintomas Software de baixa qualidade Projetos com prazos e custos maiores que os planejados Software não atendendo aos requisitos dos interessados Custos e dificuldades no processo de manutenção

30 Antes de 1960: Nenhuma metodologia. Programar computador é uma arte (5% de inspiração e 95% de transpiração).

31 Década de 60: Sob a influência do DoD nasce a discussão Como construir sistemas com método (eficiência). Aparece então o conceito de estruturação Programação Estruturada Projeto Estruturado Análise Estruturada

32 Década de 60 Característica da Análise Estruturada: Grande quantidade de dados sobre a lógica dos processos e pequena quantidade de dados relativos aos processos. Chris Gane e Trish Sarson Michael Jacson Edward Yourdon

33 60/70 Aparecem os SGBD s 1976 Peter Shen cria o Modelo Entidade- Relacionamento (MER ou DER), inicialmente para se obter uma visão abstrata dos dados. Posteriormente foi usado para modelagem conceitual de BD s. DER -> CASE -> Geração automática das tabelas

34 Anos 80 Disputa entre as Metodologias Focadas no Processo Versus Metodologias Focadas nos Dados Técnicas de Normalização de dados (3FN) Usar modelo conceitual de dados normalizados para comunicar-se com os usuários (modelo de dados normalizados como modelo do problema).

35 1981 Engenharia da Informação. Formulada por James Martin e Clive Finkelstein. Conjunto de técnicas e ferramentas capazes de ter o rigor das Engenharias Convencionais, aplicadas a Dados, Atividades, Tecnologia e Pessoas, para permitir Planejar, Analisar, Projetar, Construir e Manter sistemas de informação (PD). Foco excessivo na modelagem de dados (MDC- Modelo de dados corporativo).

36 1984 Análise Essencial Criada por McMennamin e Palmer, corrige o foco excessivo nos dados em detrimento da funcionalidade Usuário precisa da funcionalidade que por sua vez precisa de dados 1o Modelar eventos de negócios (funções) 2o Modelar dados necessários aos eventos

37 Análise essencial Essa tendência de prevalência da funcionalidade sobre os dados, deu origem a: Análise de Pontos por Função Técnicas de Orientação a Objetos (OO) (Coad e Yourdon: detectar objetos primeiro) Em 1995, Ivar Jacobson adaptou o conceito de Evento da Análise Essencial para a OO criando o conceito de Caso de Uso.

38 Anos 90: técnicas OO 88/91 Sally Shlaer e Steve Mellor escrevem 2 livros sobre Análise e Projeto OO e criam o Método Shlaer/Mellor Orientado a Objetos. Método baseado em notação tradicional (inclusive DF como técnica para visualizar o modelo de comportamento do objeto. Utilizam ainda DER e Diagrama de transição de estado.

39 Anos 90: técnicas OO Comunidade Smalltalk de Oregon criam o enfoque de projeto dirigido a responsabilidade e propõem os cartões de colaboração e responsabilidade de classe CRC-Class Responsability-Collaboration).

40 Anos 90: técnicas de modelagem Grady Booch desenvolve o Método de Booch-OOD (95) que inicialmente compreende técnicas de projeto orientado a objeto, depois entendido para atender a análise orientada a objeto. Primeiro definem-se os objetos, estes passam a servir de base para os módulos do sistema Segundo Booch, Projeto Estruturado e Projeto Orientado a Objetos são visões ortogonais do mesmo fato: PE separa o sistema em módulos e o POO estuda o problema baseado nos objetos existentes no domínio do problema

41 Anos 90: técnicas de modelagem Peter Coad e Eduard Yourdon criam em 1990 a OOA e OOD- Análise Baseada em Objetos e Projeto Baseado em Objetos. Dividem a Análise em classes e objetos além de quatro elementos adicionais para descrever um sistema: estrutura (domínio do problema), sujeito (papéis), atributo (tipos de dados) e serviço (o que o objeto pode fazer).

42 Anos 90: técnicas de modelagem Jim Rumbaugh e equipe da GE criam a OMT- Object Modeling Technique (96). A OMT cobre as diversas fases do projeto. Baseado na modelagem semântica de dados, tem notação parecida com a dos métodos estruturados porém falta notação para a passagem de mensagem entre objetos.

43 Anos 90: técnicas de modelagem Derek Coleman et all (equipe HP) lança em 92 o Método Fusion, que é a fusão de OMT (Rumbaugh), OOD (Booch), Objectory (Jacobson) e CRC (Comunidade SmallTalk). A proposta era usar métodos não derivados da metodologia estruturada, buscando o melhor de cada método (fusão).

44 Anos 90: técnicas de modelagem James Martin e Jim Odell criaram a Análise e Projeto Baseados em Objetos (96), com enfoque orientada a objetos mas baseado nos conceitos da Engenharia da Informação e notação semelhante à de Coad/Yourdon. Possui forte ênfase na modelagem de dados

45 Anos 90: técnicas de modelagem Ivar Jacobson (Ericson) introduz o conceito de Caso de Uso através da OOSE-Object-Oriented Software Engineering (95) e o Método Objectory. O método tem foco nos Casos de Uso, na categorização de papéis, no modelo de domínio de problema e uma descrição da interface do sistema. O Método Objectory tem sido adaptado para a engenharia de negócios e modelagem de processos

46 Anos 90: técnicas de modelagem Os métodos de Booch e Rumbaugh estavam crescendo em aceitação pela comunidade usuária, seus autores se juntam na Rational Corporation e em 1995 lançaram o Método Unificado (V.0.8). No outono de 95 Jacobson se juntou à equipe fundindo o Método OOSE ao Método Unificado. Método de Booch (95) OMT (Rumbaugh-96) OOSE (Jacobson-95) Nascimento da UML

47 Anos 90: técnicas de modelagem Em 96 é criada a UML-Linguagem Unificada de Modelagem. Em 1997 é padronizada a versão 1.0 da UML após ser apresentada ao OMG Object Management Group que a adota como padrão de linguagem de modelagem. Rational (Jacobson) lança o RUP-Rational Unified Process, como processo de desenvolvimento unificado de software (OO, UML, RUP)

48 Metodologia Conjunto de métodos (técnicas) e processos. Por exemplo: Metodologia Estruturada, Metodologia Orientada a Objeto etc.

49 Método Caminho para se atingir um objetivo (modo de proceder). Por exemplo: Método de Análise Estruturada, Método de Projeto Estruturado, etc.

50 Processo Maneira pela qual se realiza uma operação, segundo determinado método ou norma.

51 Técnica Aplicação prática do processo; Por exemplo: Conhecer o processo alvo do sistema e levantar as transformações da informação

52 Métodos Detalhamento de como fazer, utilizando-se os princípios de engenharia. Métodos envolvem amplo conjunto de tarefas: Planejamento, Codificação, Estimativa de Projeto, Testes, Análise de Requisitos, Manutenção Métodos geralmente introduzem uma notação gráfica, uma terminologia especial e um conjunto de critério para sua aplicação.

53 Ferramentas Proporcionam apoio automatizado ou semiautomatizado à aplicação dos métodos. Quando integradas, chamadas de ferramenta CASE Engenharia de software auxiliada por computador

54 Procedimentos Constituem o elo de ligação entre Métodos e Ferramentas, permitindo o desenvolvimento racional de software. Definem a seqüência em que os métodos serão aplicados, os produtos que devem ser gerados, os controles a serem estabelecidos e os marcos de referência (milestones) que permitem a avaliação do processo.