engenharia de software prof. joão paulo campolina lamas

ENGENHARIA DE SOFTWARE

Prof. João Paulo Campolina Lamas

João Paulo Campolina Lamas 2

Definições de Engenharia de Software O estabelecimento e uso de princípios de

engenharia para a produção economicamente viável de software de qualidade que funcione em máquinas reais.

A engenharia de software é a disciplina envolvida com a produção e manutenção sistemática de software que são desenvolvidos com custos e prazos estimados.

Disciplina que aborda a construção de software complexo:

com muitas partes interconectadas e diferentes versões por uma equipe de analistas,

projetistas,programadores, gerentes, "testadores", etc.


Qual a diferença entre engenharia desoftware e ciência da computação?

Ciência da computação aborda as teorias e fundamentos; engenharia de software está interessada nos aspectos práticos de desenvolver e entregar no prazo um software útil.

Todo engenheiro de software deve ter uma boa base em ciência da computação, tal como um engenheiro mecânico, civil ou elétrico deve ter conhecimentos em física.

Atualmente, a ciência da computação ainda não possui teorias suficientes a engenharia de software.


Software - Sistemas

Um conjunto de elementos que é organizado para executar certo método, procedimento ou um controle ao processar informações.

Sistemas de Informação: Um mecanismos composto de várias partes que agem de maneira coordenada para prestar serviços à uma área de negócio.


Desenvolvimento de Sistemas

É o trabalho de produzir os sistemas.

Envolve as atividades de requisitos, análise, projeto, implementação, teste, implantação e manutenção.


Problemas no Desenvolvimento Produtividade da Equipe; Correção da

Especificação; Confiabilidade; Manutenibilidade; Desempenho; Portabilidade; Segurança.


Método de Desenvolvimento

Definição – Seqüência de tarefas que determinam como um sistema é construído.

Objetivo – Os métodos de desenvolvimento de sistemas criam diferentes níveis de abstração.


Abstração


Abstração

É o exame seletivo de determinados aspectos de um problema;

Objetivo – É isolar os aspectos que sejam importantes para algum propósito e suprimir os que não o forem.


Modelos

Um modelo é uma descrição da realidade que ressalta alguns aspectos em detrimentos de outros.

Cada tipo de modelo utiliza uma notação precisa e uma conjunto de regras sintáticas e semânticas.


Modelos

Os modelos são úteis para: O entendimento de problemas; A difusão do conhecimento entre os

componentes da equipe do projeto; Testar hipóteses antes de realizá-

las; Construir sistemas complexos.


Processo de Desenvolvimento Um conjunto de tarefas necessárias para

transformar os requisitos dos usuários em sistemas. Nesta definição devem ser considerados as seguintes informações atividades a serem realizadas recursos utilizados, artefatos consumidos e gerados, procedimentos adotados, paradigma e tecnologia adotados, e o modelo de ciclo de vida utilizado.

Objetivos Determinar uma ordem; Guiar os desenvolvedores; Padronização das atividades; Servir de base para estimativas de recursos e

acompanhamento de projeto;


Modelo de Ciclo de Vida Um modelo de ciclo de vida de um

sistema é uma visão das atividades que ocorrem durante o desenvolvimento de um software, definindo, assim, os estágios ou fases que um produto de sistema atravessa ao ser desenvolvido.

Um modelo de ciclo de vida possibilita um melhor entendimento das atividades básicas e características do sistema em desenvolvimento.


Modelo de Ciclo de Vida

A classificação dos modelos de ciclo de vida são:

Clássico ou em cascata; Cascata revisto Prototipagem; Modelo Espiral; Interativo e Incremental.


Atividades Básicas de um Ciclo de Vida

Requisitos; Análise; Projeto; Implementação; Testes; Implantação; e Manutenção.


Atividade de Requisitos Identificar desejos, interações,

procedimentos atuais e dados relevantes; Esta etapa deve geras as informações

que vão permitir os projetistas modelar todo o sistema sem ambigüidades.

E especificação de requisitos, também, propicia ao desenvolvedor, e ao cliente os critérios para avaliar a qualidade do sistema.


Atividade de Análise O domínio de informação de um

problema deve ser representado e compreendido;

Os modelos devem descrevem as informações, funções e o comportamento do sistema;

O processo de análise deve mover-se da informação essencial para os detalhes de implementação.


Atividade de Projeto Uma atividade de múltiplos passos que

deve se concentrar em quatro atributos distintos do sistema: Estrutura de Dados; Arquitetura de Sistemas; Detalhes Procedimentais; Caracterização das Interfaces.

Independe da tecnologia onde será implementado o sistema.


Atividade de Implementação

Essa atividade traduz a anterior em uma forma legível para o computador executar;

Se o projeto for executado detalhadamente, a implementação poderá ser executada mecanicamente.


Atividade de Testes Esta atividade deve começar assim que o

código tenha sido gerado; Essa atividade se concentra nos aspectos

lógicos internos ao sistema, garantido que todas as instruções tenham sido testadas, e concentra-se também nos aspectos funcionais externos, ou seja, os teste são para descobrir erros e garantir que a entrada definida produz os resultados esperados.


Atividade de Implantação

Atividade para por o sistema em operação: Treinamento de operadores; Conversão de dados; Disponibilização dos manuais; e Suporte à operação.


Atividade de Manutenção

Sempre, o sistema sofrerá mudanças depois que for entregue ao cliente;

Motivos: Erros encontrados; Adaptar para possíveis mudanças de

requisitos; e Acréscimo de funcionalidades.


Modelo Clássico ou em Cascata

Foi primeiro modelo a ser proposto; Defende a idéia que o

desenvolvimento ocorra através de uma seqüência de atividade encadeadas, em que uma atividade só é iniciada quando a atividade antecedente é terminada.


Modelo Clássico ou em Cascata


Modelo Cascata Revisto


Modelo de Prototipagem

Propõe a construção rápida de um protótipo como uma forma de validar e refinar os requisitos, permitindo ao desenvolvedor um melhor conhecimento do que necessita ser feito;

O protótipo deve ser descartado.


Modelo Espiral

Propõe a combinação das atividades de desenvolvimento com as de gerenciamento de risco, com o objetivo de minimizar e controlar os riscos envolvidos no projeto;

Quando os riscos são identificados, os gerentes do projeto devem decidir como minimizá-los ou eliminá-los.


Modelo Espiral


Modelo Interativo e Incremental

Muito utilizado atualmente, defende a idéia do desenvolvimento de versões do sistema;

Este modelo não pressupõe que todos os requisitos sejam conhecidos no início do projeto, e propõe que para cada versão sejam selecionados apenas os requisitos que estejam bem definidos.


Modelo Interativo e Incremental


Como Escolher o Modelo de Ciclo de vida? Não é uma atividade trivial; Devemos considerar as características do

projeto, da equipe de desenvolvimento e gerência, e dos próprios usuários;

Alguns critérios: Paradigma de desenvolvimento adotado; Necessidade do sistema ser colocado em uso

rapidamente com funcionalidade total ou parcial; Grau de definição do problema; Tamanho e complexidade da aplicação; Nível de formação, atualização e experiência da

equipe de desenvolvimento e de gerência.


Análise Estruturada Técnicas de análise de sistemas que

constrói modelos funcionais do sistema; Centrada em processos; Mais utilizada; Notação gráfica criada por DeMarco, em

1979; Adaptada por outros autores:

Chris Gane; Yourdon.


Elementos Utilizados

Diagrama de Fluxo de dados (DFD); Dicionário de Dados; Especificação dos processos; Modelo de Entidade e

Relacionamento; Projeto Estruturado; e Diagrama de Transição de Estados;


Diagrama de Fluxo de Dados Especificam as funções de um sistema; Representam o trânsito das

informações de um sistema e sua transformação pelos processos;


Diagrama de Fluxo de Dados Processos – Transforma/processa as

informações; Fluxo de dados – São as informações

em trânsito entre os processos; A seta indica a direção do fluxo de dados;

Entidade Externas – Elementos na fronteira do sistema. Produzem ou recebem as informações do sistema; e

Depósitos – Lugar aonde as informações são armazenadas.


Diagrama de Fluxo de Dados Inicialmente constrói-se um DFD

apresentando os limites do sistema. Este DFD é denominado de Diagrama

de Contexto: Apresenta o sistema como um único

processo; Determina os fluxo de entrada e saída do

sistema; Apresenta as entidades externas.


Diagrama de Fluxo de Dados

Em seguida, o diagrama de contexto é explodido: Constrói-se um DFD que detalha os

processos que compõe o sistema; Cada processo pode ser

posteriormente refinado em novos DFDs;

Processos não refinados são denominados processos primitivos.


Dicionário de Dados

Refinam as informações do sistema: Informações dos fluxos de dados; Informações dos repositórios.

Determinam: A estrutura e o significado das

informações; Os limites de valores para as

informações.


Dicionário de Dados (Estruturas de Dados) Para o Tom DeMarco:

= -> é equivalente à + -> e [] -> ou {} -> interações de () -> opcional @ -> Chave Primária & -> Chave estrangeira


Dicionário de Dados (Elemento de Dados) Descrição Sucinta; Tipo de Dado; Tamanho; Sinal; Tipo de Elemento (Discreto ou

contínuo): Se for discreto

Definir os valores Se for contínuo

Valor Mínimo Valor máximo


Especificação de Processos Especificar os passos nos processos

primitivos Cada processo primitivo possui uma

especificação; Especificações podem ser descritivas

através de: Português estruturado; Linguagens formais; Fluxogramas; e Qualquer outro recursos do tipo.


Modelo de Entidades e Relacionamentos Entidades:

É qualquer objeto de interesse do mundo real, do qual se deseja conhecer, controlar e/ou acompanhar suas características, cujo comportamento deve ser tratado por um sistema de informação. Podem ser pessoas, instituições, eventos, objetos materiais, etc.

CLIENTES PRODUTOS


Modelo de Entidades e Relacionamentos

Relacionamentos: É qualquer associação de interesse

entre as entidades de um determinado estudo. Representa basicamente as regras de gestão.

CLIENTES PRODUTOScompram


Cardinalidade É a representação da freqüência com que uma

determinada ocorrência em uma entidade se corresponde a outras ocorrências em outra entidade, através do relacionamento. São identificadas as cardinalidades mínimas e máximas do relacionamento. Quando a cardinalidade máxima for conhecida, esta deverá ser explicitamente informada.


Atributos É uma característica existente em uma entidade

ou em um relacionamento, que se deseja conhecer, controlar e/ou acompanhar em um determinado estudo. Representa informação (dados) a manipular.

CLIENTES PRODUTOScompram

CGC

RAZÃO SOCIAL

ENDEREÇO

TELEFONE

CÓDIGO

DESCRIÇÃO

PREÇO BÁSICO

PESO

DATA COMPRA

QUANTIDADE

(0,N) (1,N)


Tipos de Relacionamento 1-1: É quando as cardinalidades máximas do

relacionamento forem 1 e 1. FUNCIONÁRIOS possuem DADOS RESCISÃO PEDIDOS geram FATURAS

1-N: É quando as cardinalidades máximas do relacionamento forem 1 e N. PESSOAS possuem CARROS DEPARTAMENTOS alocam FUNCIONÁRIOS RESPONSÁVEIS possuem DEPENDENTES

N-N: É quando as cardinalidades máximas do relacionamento forem N e N. CLIENTES compram PRODUTOS ALUNOS matriculam em DISCIPLINAS


Diagrama de Transição de Estados Mostra uma máquina de estados, dando

ênfase ao fluxo de controle de um estado para o outro;

Uma máquina de estados é um comportamento que especifica as seqüências de estados pelos quais um objeto passa durante seu tempo de vida em resposta a eventos, juntamente com suas respostas a esses eventos;

São criados para objetos que tenham um comportamento dinâmico significativo;


Diagrama de Transição de Estados

CriaFatura nãopaga

pagapagar

Fatura DestruídaEstado

Inicial

Estado do Objeto

Estado

Final

Evento


Estado Estado

É uma condição ou situação na vida de um objeto durante a qual ele satisfaz a alguma condição, realiza alguma atividade ou aguarda algum evento;

Exemplo de estados:

A duplicata(objeto) foi paga (estado)

O carro (objeto) está parado (estado)

O motor (objeto) está funcionando (estado)

João (objeto) está solteiro (estado)


Evento

Evento É uma especificação de uma

ocorrência significativa que tem uma localização no tempo e no espaço;

No contexto de uma máquina de estado, um evento é uma ocorrência de um estímulo capaz de ativar uma transição de estado;


Transição

Transição É um relacionamento entre dois

estados, indicando que um objeto no primeiro estado realizará certas ações e entrará no segundo estado quando um evento especificado ocorrer e as condições especificadas estiverem satisfeitas;


Condição de Guarda

É uma expressão booleana colocada na transição de estados, que deve ser verdadeira, para que ocorrência do evento a transição ocorra.


Ação

É uma atividade ou operação que deve ser feita ao chegar, permanecer ou sair de um estado; Ações executadas ao entrar no estado

(entry); Ações executadas dentro do estado

(do); Ações executadas ao sair do estado

(exit).


Aplicabilidade Permite o controle do comportamento

de um objeto ao longo de um período, possuindo as seguintes aplicações:

Representação do diálogo homem X máquina, identificando a necessidade de intervenção humana (do usuário) em um dado algoritmo (função implementacional).

Representação das transições de um objeto controlado entre situações relevantes a um contexto estudado. Este objeto poderá estar representado em um Modelo de Entidade e Relacionamentos (MER) ou Diagrama de Classes.


Banco Investir

Arquitetura e Projeto de Software


Arquitetura e Projeto de Software A arquitetura de software estuda um conjunto

de aspectos estruturais que envolve: a forma de organizar um sistema como um conjunto

de componentes interconectados; as estruturas de controles responsáveis pela forma

de seqüenciamento do programa; os protocolos para comunicação, sincronismo de

acesso a dados entre estes componentes; a alocação de funcionalidade a cada um dos

componentes; a distribuição física dos componentes; estudo de desempenho; formas de evolução.


Arquitetura e Projeto de Software Definição:

Fornecer um nível de abstração no qual os projetistas podem argumentar sobre o comportamento de um sistema: funcionalidade, desempenho, confiabilidade, etc.

Fornecer uma “consciência” para a evolução do sistema, indicando quais aspectos do sistema podem ser facilmente alterados sem comprometer a integridade do sistema.


Arquitetura e Projeto de Software A criação da arquitetura de um sistema

apresenta um conjunto de questões arquiteturais que devem ser respondidas antes de um projeto ser desenvolvido: Como organizar o controle do sistema? Qual a forma de armazenamento de dados? Qual a política de tratamento das exceções?


Organização e Controle do Sistema

A primeira pergunta é respondida através dos modelos de casos de uso, no qual descreve as funcionalidades de um sistema. Cada caso de uso segue um roteiro ordenado que indica quais passos devem ser seguidos para que o passo possa ser executado com sucesso.


Armazenamento e Persistência Na grande maioria dos SGBDs comerciais

modernos, todas as informações são arranjadas em relações de itens chamadas de tabelas. As linhas da tabela são chamadas de ocorrências e as colunas de atributos. A associação de uma ocorrência de uma tabela a uma ou mais ocorrência de outra tabela é feita pelos identificadores referenciais

Persistência é o nome dado a um problema de armazenamento dos objetos de um sistema em uma memória permanente.


Tratamento de Exceções A confiabilidade da arquitetura de um

software está ligada ao cumprimento dos requisitos não funcionais de correção, confiabilidade e robustez. Cada uma dessas propriedades não funcionais é de grande importância arquitetônica, pois influenciam bastante no desenvolvimento, manutenção e extensão do software.

Engenharia de Software Orientada a Objetos


Paradigma Orientado à Objetos

Conjunto de conceitos e regras que determinam como desenvolver software utilizando a tecnologia de orientação à objetos.


Objetos

Representam elementos do mundo real

Possuem: Atributos (estado); Serviços (comportamento);


Atributos e Serviços

Atributo É um dado (informação de estado)

para o qual cada objeto em uma classe tem seu próprio valor.

Serviço É um comportamento específico que

um objeto deve exibir.


Atributos e Serviços Serviços só têm acesso aos atributos da

classe para a qual foram definidos. Atributos de uma classe só podem ser

manipulados por serviços desta classe.


Classe Uma descrição de um ou mais

objetos com os mesmos atributos e serviços.

Uma classe pode ser vista como uma “fábrica de objetos”.

Objetos pertencentes à classe são ditos INSTÂNCIAS da classe.

Instanciação: ato de criar (instanciar) objetos de uma classe.


Classe


Tipos de Classes

Classe Concreta Pode instanciar objetos.

Classe Abstrata Não pode instanciar objetos.


Classe e Objetos


Classificação


Dificuldade da Classificação


Abstração

Princípio de ignorar os aspectos de um assunto não relevantes para o propósito em questão, tornando possível uma concentração maior nos assuntos principais.

A abstração consiste então na seleção de alguns aspectos, ignorando outros.


Encapsulamento(Ocultamento de Informações)

O encapsulamento proíbe a visualização interna de um objeto.

Atributos são associados à serviços e só podem ser acessados por estes.

A interface para cada módulo é definida de forma a revelar o menos possível sobre seu funcionamento interno.


Encapsulamento


Herança

Mecanismo para expressar a similaridade entre classes, simplificando a definição de classes iguais a outras que já foram definidas.

Representa a estrutura Generalização e Especialização (Gen-Espec), tornando explícitos os atributos e serviços comuns em uma hierarquia de classes.


Herança


Herança Superclasses representam abstrações

generalizadas. Subclasses representam abstrações

onde variáveis de instância e métodos são adicionados, modificados ou removidos.

Superclasses podem possuir serviços abstratos (virtuais), que devem ser implementados nas subclasses


Herança Com o mecanismo de herança, ao

se criar uma classe a partir de outra classe, a nova classe (subclasse da classe original) herda todas as suas características (atributos e serviços).

Dois tipos: Simples Múltipla


Herança Simples Subclasse herda de apenas uma

superclasse


Herança Múltipla Subclasse herda de mais de uma

superclasse Principal problema: conflito de nomes


Polimorfismo

Possibilidade de enviar um mesmo seletor de mensagem para diferentes objetos, mesmo que estes sejam instâncias de classes diferentes.

Significa que a mesma operação pode atuar de modos diferentes em classes diferentes.


Associação

Um modelo de mapeamento de domínio que um objeto precisa ter com outros, para cumprir suas responsabilidades.


Composição (Agregação)

Utilizado quando objetos de determinadas classes são utilizados em conjunto e um faz parte do outro.

Representa a estrutura Todo-Parte.


Tecnologias Orientadas à Objetosx Baseadas em Objetos

As orientadas à objetos suportam todos os conceitos como encapsulamento, heranças nas classes e polimorfismo nas operações.

As baseadas em objetos apenas aderem parcialmente a estes conceitos.

Nem todas as ferramentas visuais são orientadas à objetos.


Reutilização O reuso é inerente ao processo de

solução de problemas utilizado pelos seres humanos.

Na medida em que soluções são encontradas, estas são utilizadas em problemas similares.

A capacidade de abstração é o que garante a adaptação necessária ao novo contexto.


Reutilização Definições:

É a utilização de produtos de software desenvolvidos ao longo do ciclo de vida em uma situação diferente daquela para a qual foram originalmente produzidos

É o processo de utilização de software pré-existente (programas, procedimentos, documentação e dados associados) durante o desenvolvimento de um novo sistema ou componente


Reutilização Motivação:

Melhores índices de produtividade; produtos de melhor qualidade, mais

confiáveis, consistentes e padronizados; redução dos custos e tempo envolvidos

no desenvolvimento de software; maior flexibilidade na estrutura do

software produzido, facilitando sua manutenção e evolução.

Projeto Orientado a Objetos


O que é o RUP? O nome é uma abreviação de Rational

Unified Process; É um processo de engenharia de

software desenvolvido por três dos principais gurus da indústria de software: Ivar Jacobson, James Rumbaugh e Grady Booch, sendo o resultado de mais de 30 anos de experiência acumulada;

É o primeiro processo de desenvolvimento a explorar integralmente as capacidades do padrão UML.


RUP é um Processo

dirigido por casos de uso; centrado na arquitetura; iterativo e incremental.


Processo Dirigido por Casos de Uso caso de uso é um modelo que define o

que o sistema deve fazer da perspectiva dos usuários, subsistemas ou periféricos;

ator é algo que interaja com o sistema a ser desenvolvido;

todos os casos de uso de um sistema compõe a especificação funcional do sistema (modelo de casos de uso), ou seja, definem os requisitos do sistema;


Processo Dirigido por Casos de Uso

Dirigem várias atividades de desenvolvimento: Criação e validação da arquitetura do

sistema; Criação de casos de teste; Planejamento das iterações; Criação de documentação do usuário; Implantação do sistema;


Processo Centrado na Arquitetura Fornece uma base sólida para a

construção do software; Melhor compreensão do sistema e

organização do desenvolvimento; Descrição da arquitetura envolve

elementos mais importantes, como a coleção de visões dos modelos do sistema;

A arquitetura representa a forma, enquanto que os casos de uso representam as funcionalidades;


Processo Iterativo e Incremental Identificação de riscos é adiantada; Preparação do Sistema para requisitos

que mudam; Integração contínua (facilita testes) e

aprendizado facilitado; Desenvolvimento em mini-projetos

(iterações) que incrementam o desenvolvimento;

Modelos evoluem nas iterações.


O RUP é iterativo e incremental O desenvolvimento iterativo controlado

é superior a tradicional abordagem cascata por muitas razões: suporta mudanças de requisitos; permite integração contínua; atenua os riscos; permite mudanças táticas; facilita a reutilização; resulta em uma arquitetura mais robusta; facilita o entendimento; refina os processos;


O RUP é iterativo e incremental

Concepção (define o escopo do projeto) Elaboração (detalha os requisitos e a

arquitetura) Construção (desenvolve o sistema) Transição (implanta o sistema)


O RUP é iterativo e incremental Cada iteração:

é planejada; realiza uma seqüência de atividades

(de elicitação de requisitos, análise e projeto, implementação, etc.) distintas geralmente resulta em uma versão executável do sistema;

é avaliada segundo critérios de sucesso previamente definidos;


RUP – Fluxos de Trabalho Modelagem de Negócio

Definição dos Processos e Regras de negócio. Requisitos

Casos de Uso + Protótipo Interface com Usuário + Glossário + Modelo de domínio.

Análise e Projeto Desenvolvimento baseado em componentes. Mecanismos de colaboração entre componentes de forma

a realizar os cenários dos casos de uso. • Implementação

Produção de código e testes de unidade. Testes

Testes do sistema, baseados nos casos de uso e demais requisitos.


Fases x Iterações O conjunto das 4 fases (Concepção,

Elaboração, Construção e Transição) formam um ciclo de desenvolvimento;

Cada ciclo produz a geração de um produto (com infra-estrutura de manutenção e suporte). Ciclos de evolução podem ser originados de: sugestões de usuários modificações no contexto do negócio mudanças tecnológicas reação à competição


Fases x Iterações Cada fase (concepção, elaboração,

construção, transição) é composta por 1 ou mais iterações;

Cada iteração gera um release interno ou externo;

O que é um release? Uma versão estável, completa em si e

executável do sistema bem como qualquer outros elementos necessários para sua utilização.


Fases x Iterações


Concepção Responder às seguintes perguntas:

Quais serão as principais funcionalidades do sistema? Em linhas gerais, como será a arquitetura do

sistema? Qual é a estimativa inicial de tempo e custo para o

projeto? Quais são os principais riscos?

Entendimento geral do problema e da tecnologia envolvida;

Estabelecer o escopo do projeto; Garantir o financiamento do projeto; Verificar a viabilidade do projeto;


Elaboração Detalhamento dos requisitos do sistema; Protótipo Descartável - Interface com Usuário; Garantir uma arquitetura estável e testada

para a construção (evitar surpresas técnicas durante a construção);

Minimizar os riscos relacionados à fase de construção;

Plano de desenvolvimento para as próximas fases;

Estimativa realista de custo e prazo para a construção;


Construção Construção do produto em uma

seqüência de iterações; Ênfase em Projeto Detalhado,

Implementação e testes; Gerar o software propriamente dito; Manuais / Documentação do usuário; Produto ao final da Construção ainda

pode conter erros, que serão descobertos e removidos na fase de transição;


Transição Fazer a transição do produto para a comunidade de

usuários; Foco na correção de problemas e não em adição de

novas funcionalidades; Sugestões são avaliadas, podendo ser incorporadas

ainda neste release; Modificações em função de feedback dos usuários; Otimização; Treinamento dos usuários; Montagem da estrutura de suporte; Definição do processo de manufatura; Teste beta - Aceitação final.


Modelagem de Negócio


Requisitos


Análise e Projeto


Implementação


Testes


Implantação


Mecanismos Fundamentais

Abstração de Dados; Herança; Poliformismo; Tratamento de Exceções; Persistência;


Objetos em Software Idéias Básicas:

O modelo representa em software objetos que encontramos no mundo real;

Tipos de objetos: Entidades Físicas; Entidades Abstratas;

A características mais importante (e diferente) desta abordagem para a tradicional é a unificação de dados e funções;


Modelagem Conceitual E dois aspectos fundamentais:

Abstração – relacionada com os nossos pensamentos na observação do domínio do problema e na definição dos objetos, propriedades e ações relevantes para a solução;

Representação – está relacionada com a notação adotada para expressar o modelo concreto (ou realidade física)


Abstração O mecanismo através do qual observa-se

o domínio de um problema e foca-se nos objetos, ações e propriedades, que são relevantes para uma aplicação específica;

Noções diferentes podem ser abstraídas: Categoria ou classes; Ações; e Propriedades.


Herança

É um mecanismo para derivar novas classes a partir de classes existentes através de um processo de refinamento. Uma classe derivada herda a representação de dados e operações, estende a representação de dados ou redefini a implementação de operações já existentes.


Problemas com a Herança

Conjuntos Equivocados; Hierarquia Invertida; Confundir Classe com Instância; e Utilização Inadequada.


Conjuntos Equivocados


Hierarquia Invertida


Confundir Classe com Instância


Utilização Inadequada


Polimorfismo Palavra é derivada do grego e significa

“muitas formas” ou “tendo muitas formas”;

No contexto da orientação a objetos, significa que varáveis podem referenciar mais do que um tipo;

É a habilidade pela qual uma única operação ou nome de atributo pode ser definido em mais de uma classe e assumir implementações diferentes em cada uma dessas classes.


Polimorfismo


Tolerância a Falhas A partir do momento que os

computadores se tornaram uma ferramenta indispensável na sociedade moderna, um princípio fundamental surgiu: os benefícios trazidos pelos sistemas computacionais são tantos quantos os prejuízos que estes nos proporcionam quando deixam de funcionar ou quando funcionam incorretamente.


Tolerância a Falhas É a melhor forma de manter a

confiabilidade e disponibilidade; Sistemas confiáveis - são sistemas que não

irão desviar das intenções de seus projetistas diante de falhas de projeto, físicas ou interação com os usuários, ou ainda permitir que vírus ou ataques maliciosos afetem seus serviços essenciais;

Sistemas disponíveis - são sistemas que se mantém disponíveis mesmo diante de falhas de projeto, físicas ou humanas.


Tolerância a Falhas Uma falha num componente do sistema

pode causar um erro no estado interno, o que pode levar a um defeito no sistema em algum momento, que pode implicar as sua parada total;

Técnicas conhecidas para eliminar os erros dos estados de um sistema: Recuperação de erros por avanço; e Recuperação de erros por retrocesso.


Recuperação de Erros por Avanço Tenta retornar o sistema para um estado

livre de erros aplicando correções ao estado danificado do sistema;

Esta técnica requer um certo conhecimento dos erros possíveis de ocorrer;

Exceções e tratamento de exceções consistem num mecanismo comumente aplicado para a provisão de recuperação de erros por avanço.


Recuperação de Erros por Retrocesso Tenta recuperar o sistema para um

estado prévia livre de erros, não requerendo nenhum conhecimento prévio dos erros do sistema;

Desde que falhas de software e os erros causados por elas são de natureza imprevisível, recuperação de erros por retrocesso é geralmente aplicada para tolerar falhas de software.


Persistência A maioria das aplicações requer o

armazenamento e a recuperação de informações em um mecanismo de armazenamento persistentes, tal como um banco de dados relacional;

Os gerenciadores de banco de dados, mais utilizados pelo mercado atualmente, seguem o modelo relacional.

engenharia de software prof. joão paulo campolina lamas

Documents