anliseorientadaaobjetos 100207191356 phpapp01

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

Análise Orientada a Objetos
Prof. Eliseu Castelo Branco Jr.,PMP,MSc.
ecastelob@gmail.com
1
Conceitos de Orientação a Objetos
Visão Geral da UML
Diagrama de Caso de Uso
Diagrama de Classes
Diagrama de Objetos
Diagramas de Interação
Diagrama de Estado
Diagrama de Atividades
Diagramas de Implementação
Ementa da Disciplina
2
Cronograma de Aulas
FEVEREIRO
MARÇO
ABRIL
MAIO
JUNHO
2
2
6
4
1
9
9
AV1-13
11
8
 
23
16
20
18
AV2-15
 
 
23
27
25
22
 
 
30
 
 
AV3 - 29
 
3
5
4
4
5
TOTAL
21
FREQ MIN
17
3
Provas sobre conteúdo teórico da disciplina (Av1, Av2, Av3)
Trabalhos de pesquisa publicados na Internet
Documentos de Análise e Projeto de software entregues
Exercícios realizados em sala de aula
OBS: mínimo de 75% de presença em sala de aula necessário para aprovação na disciplina.
Avaliações
4
Sistemas de software são complexos.
O uso de modelos auxilia na compreensão de conceitos complexos.
Introdução
5
O desenvolvimento de um sistema envolve grande quantidade de atividades e pessoas
Erros são inevitáveis e se identificados nos modelos sua correção é mais fácil e barata.
Introdução
6
O uso de modelos reduz o custo do desenvolvimento de sistemas.
O modelo permite prever o comportamento do sistema no futuro.
Introdução
7
A modelagem de sistemas de software consiste na utilização de notações gráficas e textuais com o objetivo de construir modelos que representam as partes essenciais de um sistema, considerando-se diversas perspectivas diferentes e complementares.
O que é modelagem de software?
8
“Paradigma é a forma de abordar um problema”
Princípios:
Qualquer coisa é um objeto
Objetos realizam tarefas através da requisição de serviços a outros objetos
Cada objeto pertence a uma classe
A classe é um repositório para comportamento associado ao objeto
Classes são organizadas em hierarquias
Paradigma da Orientação a Objetos
9
O paradigma da orientação a objetos visualiza um sistema de software como uma coleção de agentes interconectados chamados OBJETOS. Cada objeto realiza tarefas específicas. É através da interação entre objetos que uma tarefa computacional é realizada.
Paradigma da Orientação a Objetos
10
Tipos de Sistemas
11
O Sistema contem subsistemas
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
Subsistemas de um Sistema de Informação
28
Módulos do Sistema (subsistemas)
29
Classe Movimentação Financeira
Classe Bancos
Classe Rendas Diversas 
Classe Contas a Pagar
Classe Receitas Diversas
Subsistema Contas a Pagar
30
Classe Banco
Atributos
Métodos
31
O que é Análise e Projeto?
Análise — “o quê”
Investigação do problema e dos requisitos
Requisitos
Casos de uso
Restrições
Vocabulário
Projeto — “como”
Descrição de uma solução lógica
Objetos
Arquitetura
Instalação & Operação
Interface do usuário
32
Representação de um Conceito na APOO
Ex.: O conceito “Livro” em um sistema de biblioteca
Conceito
de domínio
public class Livro
{
public void imprimir();
private String titulo;
}
Representação
no código
Livro
título
 Representação
na análise
Livro
título
 Representação
no projeto
imprimir()
33
Uma Analogia — Organizando os Negócios de uma Empresa 
Documentos
Associados
APOO
Analogia
Casos de uso
Análise de requisitos
Quais são os processos de negócio?
Modelo conceitual
Análise do domínio
Quais são os papeis dos empregados?
Diagramas de classes de projeto, diagramas de colaboração
Atribuição de responsabilidades, projeto das interações
Quem é responsável por o quê? Como eles interagem?
34
Um Exemplo — Jogo de Dados
Objetivo: ganha o jogo o jogador que rolar dois dados e tirar sete
Modelagem na APOO
Casos de uso
Descrições narrativas de processos do domínio no formato de prosa estruturada
Ex.: 
Caso de uso:
Atores:
Descrição:
Jogar
Jogador
Este caso de uso começa quando
o jogador rola os dados. Se o total
dos dados for sete, o jogador ganha;
do contrário, ele perde.
35
Um Exemplo — Jogo de Dados
Modelagem na APOO (cont.)
Modelo conceitual
Conceitos, atributos, e associações que são considerados importantes no domínio da aplicação
Ex.:
Um modelo conceitual descreve conceitos do mundo real, não componentes de software!
Jogador
nome
JogoDeDados
Dado
valor
Rola
Joga
Inclui
2
2
1
1
1
1
36
Um Exemplo — Jogo de Dados
Modelagem na APOO (cont.) 
Diagramas de colaboração
Alocação de responsabilidades para objetos ilustrando como eles interagem via mensagens
Mostram o fluxo de mensagens entre instâncias e a invocação de métodos
Ex.:
:Jogador
d1 : Dado
d2 : Dado
joga()
1: r1 := rola()
2: r2 := rola()
37
Um Exemplo — Jogo de Dados
Modelagem na APOO (cont.) 
Diagramas de classes de projeto
Como os objetos (de software) se conectam? 
Quais são os métodos de uma classe?
Ex.:
Rola
Joga
Inclui
2
2
Jogador
nome
joga()
Dado
valor
rola()
JogoDeDados
inicializa()
1
1
1
1
38
APOO X APE
Metodologias mais antigas, como Análise e Projeto Estruturados, baseiam-se em outras dimensões de decomposição
Sistema de
Biblioteca
Sistema
A&P Orientados a Objeto
Decomposição por objetos ou conceitos
A&P Estruturados
Decomposição por funções ou processos
Registra
Empréstimos
Adiciona
Recursos
Reporta
Multas
Catálogo
Livro
Bibliotecário
Biblioteca
39
A Linguagem de Modelagem Unificada — UML
A UML é a linguagem padrão de diagramação para visualizar os resultados da análise e projeto
A notação (a própria UML) é relativamente trivial
Muito mais importante: habilidade para modelar com objetos
Só aprender a notação UML não ajuda
A UML não é
um processo ou metodologia
APOO
regras de projeto 
40
Origem e Evolução da UML
Unified Method 0.8
Unificação I
(Out’95)
Booch’93
OMT-2
Outros 
métodos
Booch’91
OMT-1
OOSE
Fragmentação
UML 1.0
Parceiros
da UML
Padronização
(Jan’97)
UML 1.1
Industrialização
(Set’97)
UML 0.9 & 0.91
Unificação II
(Out’96)
41
42
Processo de Desenvolvimento
Organização das atividades relacionadas à produção e manutenção de sistemas de software
Útil, mas um fator de segunda ordem
O principal: equipe qualificada
Boa equipe + bom processo = menor risco
O processo racional unificado (RUP), baseado no modelo iterativo, é o processo padrão na indústria
43
Sol, Mar e UML
44
Visões da UML
45
Uma série de pesquisas (www.embeddded-forecast.com) tem mostrado que muitos projetos de software embarcados são entregues com atraso ou cancelados. 
Em média, observou-se que mais de 50% dos projetos têm seus cronogramas atrasados em pelo menos quatro meses e cerca de 11% são cancelados.
46
O custo dos atrasos pode ser significativo. Por exemplo, no setor de aviônicos o custo dos atrasos é estimado de 50.000 a 300.000 dólares por mês.
Outro problema apontado é o nível de conformidade do produto final com as especificações. 
Identificou-se que pelo menos 30% dos projetos não alcançavam 50% das especificações propostas de performance ou funcionalidade. 
47
À medida que os sistemas embarcados aumentam em complexidade, esta situação tende a piorar. 
A pesquisa mostrou também que adoção de UML (Unified Modeling Language) ainda não é uma prática comum.
48
Ações (*) : unidade básica de especificação de comportamento. Ações estão contidas em atividades
Artefatos (*) : Pedaço físico da informação usado ou produzido durante o desenvolvimento do sistema
Atividades
Casos de Uso
Classes
Classes ativas
Colaboração
Componente
Estado
Interação
Interface
Elementos básicos do modelo UML
49
No
Nota
Pacote
Partes (*)
Portas (*)
Estereótipos (*)
Valores de etiqueta (*)
Restrições (*)
Elementos básicos do modelo UML
50