ANÁLISE E PROJETO DE SISTEMA

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

Sistema de software• Sistema baseado em software compondo um

sistema computacional (combinação de hardware e software)

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

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

Modelagem• Atividade de construção de modelos

Modelo• Gabarito• Representação• Representação ou interpretação simplificada da

realidade

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.

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).

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

Processo• Conjunto sequencial e particular de ações com um

objetivo específico

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

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

Projeto arquitetural• O projeto arquitetural determina o sucesso do

projeto de software

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

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

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

Engenharia da informação

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

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

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

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.

Princípio da Abstração• Processo de identificar os aspectos

importantes do produto/processo, ignorando-se 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.

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

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.

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

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

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

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

Antes de 1960:• Nenhuma metodologia.• Programar computador é uma arte (5% de

inspiração e 95% de transpiração).

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

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

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

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).

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).

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

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.

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.

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).

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

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).

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.

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).

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

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

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

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)

Metodologia• Conjunto de métodos (técnicas) e processos.• Por exemplo: Metodologia Estruturada,

Metodologia Orientada a Objeto etc.

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.

Processo• Maneira pela qual se realiza uma operação, segundo

determinado método ou norma.

Técnica• Aplicação prática do processo;• Por exemplo: Conhecer o processo alvo do sistema e

levantar as transformações da informação

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.

Ferramentas• Proporcionam apoio automatizado ou semi-

automatizado à aplicação dos métodos.• Quando integradas, chamadas de ferramenta CASE▫Engenharia de software auxiliada por computador

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.