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