ENGENHARIA DE SOFTWARE
Prof. João Paulo Campolina Lamas
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.
João Paulo Campolina Lamas
2
Qual a diferença entre engenharia de
software 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.
João Paulo Campolina Lamas
3
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.
João Paulo Campolina Lamas
4
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.
João Paulo Campolina Lamas
5
Problemas no
Desenvolvimento







Produtividade da Equipe;
Correção da Especificação;
Confiabilidade;
Manutenibilidade;
Desempenho;
Portabilidade;
Segurança.
João Paulo Campolina Lamas
6
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.
João Paulo Campolina Lamas
7
Abstração
João Paulo Campolina Lamas
8
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.
João Paulo Campolina Lamas
9
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.
João Paulo Campolina Lamas
10
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.
João Paulo Campolina Lamas
11
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;
João Paulo Campolina Lamas
12
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.
João Paulo Campolina Lamas
13
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.
João Paulo Campolina Lamas
14
Atividades Básicas de um Ciclo
de Vida







Requisitos;
Análise;
Projeto;
Implementação;
Testes;
Implantação; e
Manutenção.
João Paulo Campolina Lamas
15
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.
João Paulo Campolina Lamas
16
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.
João Paulo Campolina Lamas
17
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.
João Paulo Campolina Lamas
18
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.
João Paulo Campolina Lamas
19
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.
João Paulo Campolina Lamas
20
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.
João Paulo Campolina Lamas
21
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.
João Paulo Campolina Lamas
22
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.
João Paulo Campolina Lamas
23
Modelo Clássico ou em
Cascata
João Paulo Campolina Lamas
24
Modelo Cascata Revisto
João Paulo Campolina Lamas
25
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.
João Paulo Campolina Lamas
26
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.
João Paulo Campolina Lamas
27
Modelo Espiral
João Paulo Campolina Lamas
28
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.
João Paulo Campolina Lamas
29
Modelo Interativo e
Incremental
João Paulo Campolina Lamas
30
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.
João Paulo Campolina Lamas
31
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.
João Paulo Campolina Lamas
32
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;
João Paulo Campolina Lamas
33
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;
João Paulo Campolina Lamas
34
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.
João Paulo Campolina Lamas
35
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.
João Paulo Campolina Lamas
36
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.
João Paulo Campolina Lamas
37
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.
João Paulo Campolina Lamas
38
Dicionário de Dados
(Estruturas de Dados)

Para o Tom DeMarco:







= -> é equivalente à
+ -> e
[] -> ou
{} -> interações de
() -> opcional
@ -> Chave Primária
& -> Chave estrangeira
João Paulo Campolina Lamas
39
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
João Paulo Campolina Lamas
40
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.
João Paulo Campolina Lamas
41
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
João Paulo Campolina Lamas
42
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
compram
João Paulo Campolina Lamas
PRODUTOS
43
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.
João Paulo Campolina Lamas
44
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.
(0,N)
CLIENTES
CGC
RAZÃO SOCIAL
(1,N)
compram
DATA COMPRA
QUANTIDADE
ENDEREÇO
TELEFONE
PRODUTOS
CÓDIGO
DESCRIÇÃO
PREÇO BÁSICO
João Paulo Campolina Lamas
PESO
45
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
João Paulo Campolina Lamas
46
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;
João Paulo Campolina Lamas
47
Diagrama de Transição de
Estados
Estado do
Objeto
Evento
CriaFatura
Estado
Inicial
não
paga
pagar
paga
Fatura
Destruída
Estado
Final
João Paulo Campolina Lamas
48
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)
João Paulo Campolina Lamas
49
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;
João Paulo Campolina Lamas
50
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;
João Paulo Campolina Lamas
51
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.
João Paulo Campolina Lamas
52
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).
João Paulo Campolina Lamas
53
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.
João Paulo Campolina Lamas
54
Banco Investir
João Paulo Campolina Lamas
55
Banco Investir
João Paulo Campolina Lamas
56
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.
João Paulo Campolina Lamas
58
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.
João Paulo Campolina Lamas
59
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?
João Paulo Campolina Lamas
60
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.
João Paulo Campolina Lamas
61
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.
João Paulo Campolina Lamas
62
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.
João Paulo Campolina Lamas
63
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.
João Paulo Campolina Lamas
65
Objetos


Representam elementos do mundo real
Possuem:


Atributos (estado);
Serviços (comportamento);
João Paulo Campolina Lamas
66
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.
João Paulo Campolina Lamas
67
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.
João Paulo Campolina Lamas
68
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.
João Paulo Campolina Lamas
69
Classe
João Paulo Campolina Lamas
70
Tipos de Classes

Classe Concreta


Pode instanciar objetos.
Classe Abstrata

Não pode instanciar objetos.
João Paulo Campolina Lamas
71
Classe e Objetos
João Paulo Campolina Lamas
72
Classificação
João Paulo Campolina Lamas
73
Dificuldade da Classificação
João Paulo Campolina Lamas
74
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.
João Paulo Campolina Lamas
75
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.
João Paulo Campolina Lamas
76
Encapsulamento
João Paulo Campolina Lamas
77
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.
João Paulo Campolina Lamas
78
Herança
João Paulo Campolina Lamas
79
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
João Paulo Campolina Lamas
80
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
João Paulo Campolina Lamas
81
Herança Simples

Subclasse herda de apenas uma
superclasse
João Paulo Campolina Lamas
82
Herança Múltipla

Subclasse herda de mais de uma
superclasse

Principal problema: conflito de nomes
João Paulo Campolina Lamas
83
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.
João Paulo Campolina Lamas
84
Associação

Um modelo de mapeamento de domínio
que um objeto precisa ter com outros,
para cumprir suas responsabilidades.
João Paulo Campolina Lamas
85
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.
João Paulo Campolina Lamas
86
Tecnologias Orientadas à Objetos
x 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.
João Paulo Campolina Lamas
87
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.
João Paulo Campolina Lamas
88
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
João Paulo Campolina Lamas
89
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.
João Paulo Campolina Lamas
90
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.
João Paulo Campolina Lamas
92
RUP é um Processo



dirigido por casos de uso;
centrado na arquitetura;
iterativo e incremental.
João Paulo Campolina Lamas
93
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;
João Paulo Campolina Lamas
94
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;
João Paulo Campolina Lamas
95
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;
João Paulo Campolina Lamas
96
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.
João Paulo Campolina Lamas
97
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;
João Paulo Campolina Lamas
98
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)
João Paulo Campolina Lamas
99
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;
João Paulo Campolina Lamas
100
RUP – Fluxos de Trabalho

Modelagem de Negócio


Requisitos



Desenvolvimento baseado em componentes.
Mecanismos de colaboração entre componentes de forma a realizar
os cenários dos casos de uso.
• Implementação


Casos de Uso + Protótipo Interface com Usuário + Glossário +
Modelo de domínio.
Análise e Projeto


Definição dos Processos e Regras de negócio.
Produção de código e testes de unidade.
Testes

Testes do sistema, baseados nos casos de uso e demais requisitos.
João Paulo Campolina Lamas
101
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
João Paulo Campolina Lamas
102
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.
João Paulo Campolina Lamas
103
Fases x Iterações
João Paulo Campolina Lamas
104
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;
João Paulo Campolina Lamas
105
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;
João Paulo Campolina Lamas
106
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;
João Paulo Campolina Lamas
107
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.
João Paulo Campolina Lamas
108
Modelagem de Negócio
João Paulo Campolina Lamas
109
Requisitos
João Paulo Campolina Lamas
110
Análise e Projeto
João Paulo Campolina Lamas
111
Implementação
João Paulo Campolina Lamas
112
Testes
João Paulo Campolina Lamas
113
Implantação
João Paulo Campolina Lamas
114
Mecanismos Fundamentais





Abstração de Dados;
Herança;
Poliformismo;
Tratamento de Exceções;
Persistência;
João Paulo Campolina Lamas
115
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;
João Paulo Campolina Lamas
116
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)
João Paulo Campolina Lamas
117
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.
João Paulo Campolina Lamas
118
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.
João Paulo Campolina Lamas
119
Problemas com a Herança




Conjuntos Equivocados;
Hierarquia Invertida;
Confundir Classe com Instância; e
Utilização Inadequada.
João Paulo Campolina Lamas
120
Conjuntos Equivocados
João Paulo Campolina Lamas
121
Hierarquia Invertida
João Paulo Campolina Lamas
122
Confundir Classe com
Instância
João Paulo Campolina Lamas
123
Confundir Classe com
Instância
João Paulo Campolina Lamas
124
Confundir Classe com
Instância
João Paulo Campolina Lamas
125
Utilização Inadequada
João Paulo Campolina Lamas
126
Utilização Inadequada
João Paulo Campolina Lamas
127
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.
João Paulo Campolina Lamas
128
Polimorfismo
João Paulo Campolina Lamas
129
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.
João Paulo Campolina Lamas
130
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.
João Paulo Campolina Lamas
131
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.
João Paulo Campolina Lamas
132
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.
João Paulo Campolina Lamas
133
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.
João Paulo Campolina Lamas
134
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.
João Paulo Campolina Lamas
135