Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Análise e Desenho
Orientado a Objetos
Capacitação Engenharia de Software Análise e Desenho Orientado a Objetos com UML
Rildo F Santos
rildo.santos@etecnologia.com.br
rildo.santos@companyweb.com.br
Twitter: @rildosan
Blog: http://rildosan.blogspot.com/
Todos os direitos reservados e protegidos © 2006 e 2007
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Versão 27 |
Análise e Desenho Orientado a Objetos com UML
Conteúdo
Capacitação Engenharia de Software
Principais Conceitos da
Orientação a Objetos e UML
Objetivo desta parte:
É apresentar e discutir os principais conceitos da
Orientação a Objetos e fazer uma breve introdução a UML
Objetivo
Objetivo:
Apresentar os principais conceitos da orientação a objetos. Será demonstrado os seguintes
conceitos: Classes, Objetos, Atributos, Métodos, Abstração de Dados, Herança,
Polimorfismo, Encapsulamento, Associação e Interface.
Influência escolha da
Ferramentas
Ferramentas
Tecnologia OO
e
Artefatos
Atividades
Suporte as atividades
WorkFlows
Metodologia/Fases
Atributos
cor
Número chassi
Ano-fabricação
Identificador
Carro
Operações
acelerar
O que são operações ? parar
- Coisas que objeto deve
saber fazer
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 8
Análise e Desenho Orientado a Objetos com UML
Atributos
cor branco
Número chassi VW1003G345
Ano-fabricação 1966
Identificador
Carro
Operações
acelerar estado
parar
Atributos
cor branco
Substantivo
Número chassi VW1003G345
Ano-fabricação 1966
Identificador
Carro
Operações
acelerar
parar
verbos
Identificador Carro
Nome (identificador)
Representação na
Orientação a objetos
Carro
Atributos cor
número chassi
cor branco
ano-fabricação
Número chassi VW1003G345 Propriedades
acelerar (atributos)
Ano-fabricação 1966 parar
Operações
acelerar
parar Operações
Classe
Definição de Classe:
Uma classe descreve um conjunto de objetos que compartilham os
mesmos atributos, operações, métodos, relacionamentos e semântica
Classes
As classes são as partes mais importantes de qualquer sistema orientada a
Objetos objetos.
Atributos Usamos as classes para capturar o vocabulário do sistema que está em
desenvolvimento. Essas classes podem incluir abstrações que são parte do domínio do
Métodos problema, assim como as classes que fazem uma implementação. Podemos usar ainda
as classes para representar itens de software, de hardware e até itens que sejam
Abstração de Dados somente conceituais.
Herança Exemplo:
A classe Pessoa deverá ter atributos e métodos comuns
Polimorfismo
Encapsulamento Pessoa Nome da Classe
Interface nome Atributos
idade
getNome()
getIdade()
Nota: Dicionário Aurélio Métodos
Em programação ou modelagem orientada a objetos (v. orientação a objetos), categoria descritiva setNome()
geral, que abrange o conjunto de objetos que compartilham uma ou mais características quanto a
seus itens de dados e procedimentos associados. 22. Lóg. Agrupamento de objetos que têm uma ou
setIdade()
mais características em comum.
Classe
Exemplo de Classe:
3
1 Livro
Legenda:
Classes 1 – Objeto no mundo real
Objetos 2 – Classe Livro
3 – Objeto da classe Livro
Atributos
Métodos
Abstração de Dados
Herança
Polimorfismo
2 ISBN 0747551006
Encapsulamento
Titulo: Harry Potter and the
Interface Order of the Phoenix
Autor: J. K. Rowling
Classe e Objeto
Classe e Objeto. Exemplo:
ISBN 0747551006
Titulo: O Poder da inteligência
Classes Emocional
Autor: Daniel Goleman
Objetos
Atributos
ISBN 0747551006
Métodos
Titulo: Harry Potter and the
Abstração de Dados Order of the Phoenix
Autor: J. K. Rowling
Herança
Polimorfismo ISBN 8571643512
Encapsulamento Titulo: AS JANELAS DO
PARATII
Interface Autor: Amir Klink
Classe e Objeto
Classe e Objeto. Exemplo:
Identificador Carro
Classe e Objeto
Classe e Objeto. Exemplo:
Classe
Classes
Cliente
Objetos nome
cpf
Atributos idade
Métodos
Abstração de Dados
Herança
Objetos
Polimorfismo
Encapsulamento
Interface Cliente: clientemulher Cliente: clientehomem
nome = Marina nome = Felipe
cpf = 022.200.708-12 cpf = 039.217.908-22
idade = 16 idade = 42
Métodos
Abstração de Dados Nome da classe Cartão
Herança
Responsabilidades Colaborações
Polimorfismo
Encapsulamento
Interface Aluno
-- Deve conhecer os Matricula
dados dos aluno: Pessoa
Nome Curso
Número da Matricula
Curso
Atributo
Definindo Atributo:
Herança
Polimorfismo
Encapsulamento
Interface
Cliente: clientemulher
nome = Marina
atributos cpf = 022.200.708-12
idade = 16
Método
Escrevendo os métodos.
Interface
Método
Definição de Método:
Definição:
Método é a implementação de uma operação.
Classes Definição de Operação:
Objetos É a implementação de serviço que pode ser solicitado por qualquer
Atributos objeto da classe com a finalidade de afetar um comportamento.
Métodos Chamando os métodos
Para chamar um método de um objeto é necessário enviar uma mensagem para ele.
Abstração de Dados As mensagens identificam os métodos a serem executados no objeto receptor.
Herança Por definição todas as mensagens tem um tipo de retorno.
Polimorfismo
Encapsulamento ContaCorrente
Interface conta
saldo
setDeposito()
Métodos getSaldo()
setSaque()
Mensagem
Definição de Mensagem:
Definição:
Mensagem é uma chamada de uma operação sobre um objeto,
Classes compreendendo um nome de operação e uma lista de valores de
argumentos. (Rumbaugh)
Objetos
Atributos Um mensagem representa a requisição de um objeto remetente a um objeto receptor
para este último execute alguma operação definida para sua classe.
Métodos Essa mensagem deve conter informações suficiente para que a operações do objeto
receptor possa ser executada
Abstração de Dados
Herança
Polimorfismo
Encapsulamento
Interface
Resumo: Métodos
Resumindo:
Os métodos são a implementação das operações de objetos.
Os métodos são responsáveis pelo comportamento do objeto.
Classes A mudança de estado de um objeto deve ocorrer através dos
Objetos métodos.
Atributos
Desta forma podemos dizer que os métodos “encapsulam” os
Métodos atributos.
Abstração de Dados
Herança
Polimorfismo
Encapsulamento
Interface
Abstração de Dados
Exemplo:
Um a empresa de transporte possui uma frota de veículo, esta frota é composta por caminhões, peruas
e motos.
Estes veículos têm algumas características semelhantes como cor, peso, tamanho e capacidade de
carga. Entretanto cada veículo possui outras características diferentes como número de eixos sistema
de freio, tipo de motor e etc.
A abstração de dados é utilizada neste caso para identificar todas as propriedades comuns e reuni-las
em novo conjunto, isto lembra alguns princípios da matemática como fatoração.
Desta forma estaríamos fazendo um melhor aproveitamento de informações que se repetem e também
estamos fazendo que características diferente seja tratada de forma diferenciada.
O que é
abstração
de dados ?
Abstração de Dados
Definição de Abstração de Dados:
Definição de abstração:
“Habilidade mental que permite aos seres humanos visualizarem os problemas
Classes do mundo real com vários graus de detalhe, dependendo do contexto corrente do
Objetos problema. (Jim Rumbaugh).
Navio Avião
especialização
Abstração de Dados
Exemplo de Abstração de Dados:
Objetos Generalização
Atributos MeiodeComunicação
Métodos
Abstração de Dados
Herança Carta Telefone Jornal
Polimorfismo
Encapsulamento
Interface
Especialização
As classes Contribuinte e MeiodeComunuicação neste caso são abstratas e
ambas podem representam um domínio.
Abstração de Dados
Abstração de Dados:
Uma classe abstrata é uma classe que:
• Provê organização
Classes • Não possui “instances”, ou seja, não possui objetos.
• Possui uma ou mais operações (métodos) abstratas
Objetos
Atributos public abstract class ContaBancaria extends Object {
public ContaBancaria() { }
Métodos protected int numerocontacorrente;
Herança }
Polimorfismo
Encapsulamento
Interface
Abstração de Dados
Veja agora a classe Pessoa, que é public abstract class Pessoa {
abstrata, pois, possui um método //métodos
public abstract String getNome()
abstrato.
public void setNome(String nome){
this.nome = nome;
}
Um método abstrato não possui public abstract int calcIdade(Date
public abstract int getIdade()
implementação somente assinatura d1, Date d2);
(declaração) public void
public void setIdade(int
setIdade(int idade)
idade)
{ {
this.idade = idade;
this.idade = idade;
} }
Abstração de Dados
Herança
Definição de Herança:
Definição:
Mecanismo baseado em objetos que permite que as classes compartilhem atributos
Classes e operações baseados em um relacionamento, geralmente generalização.
(Rumbaugh)
Objetos
Atributos Uma classe derivada herda a estrutura de atributos e métodos de sua
classe “base”, mas pode seletivamente:
Métodos • adicionar novos métodos
• estender a estrutura de dados
Abstração de Dados • redefinir a implementação de métodos já existentes
Herança
Uma classe “pai” ou super classe proporciona a funcionalidade que é comum a todas as
Polimorfismo suas classes derivadas, filhas ou sub classe, enquanto que uma classe derivada
proporciona a funcionalidade adicional que especializa seu comportamento.
Encapsulamento
Interface Exemplo:
Animal
Herança
Exemplo de Herança:
Classes
Podemos dizer que Pós-
Objetos Hierarquia de Classes Graduação é tipo de Curso
Universitário, assim como
Atributos Super classes Curso Curso de Especialização ou
Métodos Universitário de Extensão.
Abstração de Dados
Sub classe
Herança Graduação Pós-Graduação
Polimorfismo extends
Encapsulamento
Interface Especialização Extensão
Polimorfismo
Definição de Polimorfismo:
Definição:
Interface
Telefone Fixo
Polimorfismo
Overloading de Método
Possibilidade de reúso do nome do método para diferentes implementações, em
tempo de execução, a aplicação, escolherá o método adequado para cada
Classes chamada, veja o exemplo.
Objetos
Atributos TesteSoma Soma
Métodos
somar(int a, int b)
Abstração de Dados somar(float a, float b)
Herança somar(char a, char b)
somar(long a, long b))
Polimorfismo
Encapsulamento
Interface
Para cada tipo de dados existe um método, o reúso do nome do método é permitido,
entretanto a lista de argumentos deve ser diferente, veja o exemplo acima: o método
somar é definido várias vezes, entretanto com a lista de argumentos diferente, desta
forma evitaremos problemas como ambigüidade.
Polimorfismo
Overridde de Método
Atributos getSaldo()
Métodos
Abstração de Dados
Herança Conta Corrente Conta Poupança Investimentos
Encapsulamento O método getSaldo é herdado da Superclasse (Conta Bancária), entretanto para cada tipo de
Interface Conta ele tem uma implementação diferente. Por exemplo:
- Para apurar o saldo da Conta Corrente saldo atual = (soma dos depósitos + saldo anterior) -
saques
Para a conta poupança seria saldo atual = (soma dos depósitos + saldo anterior + juros) -
saques
Para a conta de investimentos seria saldo atual = (soma dos aplicações + saldo anterior +
juros) - resgates - ir
Principais Conceitos
Encapsulamento
Definição de Encapsulamento:
Métodos
Abstração de Dados
Herança
Polimorfismo
Encapsulamento Private
Dados/Atributos/propriedades
Interface
Exemplo:
Quanto temos um arquivo protegido por senha de acesso, podemos dizer que ele está
protegido, pois, apenas podemos lê-lo sem fazermos alteração
Encapsulamento
Benefícios do Encapsulamento:
Benefícios
- Segurança:
Classes Protege os atributos dos objetos de terem seus valores corrompidos por
outros objetos.
Objetos - Independência:
Atributos “Escondendo” seus atributos, um objeto protege outros objetos de
complicações de dependência de sua estrutura interna
Métodos
Abstração de Dados
Herança Pessoa
Polimorfismo nome
idade setNome() nome getNome()
Encapsulamento
setNome()
Interface getNome()
setIdade() setIdade() idade getIdade()
getIdade()
encapsulamento
Interface
Definição de Interface:
O que é interface ?
Interface
Exemplo de Interface:
Representação:
Classes
<<interface>>
Objetos Codigo
realização
Atributos getcodigo()
setcodigo()
Métodos
Abstração de Dados
Herança Contrato
Introdução a aOrientação
Orientação Objetos. aPrincipais
Objetos Conceitos:
Capacitação Engenharia de Software
Interface
Principais Características
Características de uma interface:
Introdução
Por que fazer a modelagem?
Introdução
O Que é Modelagem Visual?
Modelagem visual significa modelar com a utilização de notações padrão.
Precisamos adotar uma ferramenta, uma notação e linguagem para tal empreitada.
UML (Linguagem de Modelagem Unificada) é a linguagem de modelagem é das
mais populares do momento.
Introdução
A UML (Linguagem de Modelagem Unificada) é uma linguagem-padrão para elaboração
da estrutura de projetos de software. A UML poderá ser usada para:
•Visualização
•Especificação
•Construção de modelos e diagramas
•Documentação.
A UML é apenas uma linguagem e, portanto, é somente uma parte de um método para
desenvolvimento de software. Ela é independente do processo, apesar de ser
perfeitamente utilizada em processo orientado a casos de usos, centrado na arquitetura,
iterativo e incremental.
Principais Digramas:
ESTÁTICOS
. Diagrama de Classes
. Diagrama de Objetos Modela a estrutura do sistema
. Diagrama de Componentes
. Diagrama de Distribuição
DINÂMICOS
Processo de Desenvolvimento:
Processo de Desenvolvimento
Análise Desenho
Necessidades dos Visão Modelo de dosRealização
Casos de Uso Classes Classes
Stakeholders Casos de Uso
Casos de Teste
Componentes
A Linguagem:
• Linguagem = Sintaxe + semântica
– syntax = rules by which language elements (e.g., words) are assembled
into expressions (e.g., phrases, clauses)
– semantics = rules by which syntactic expressions are assigned
meanings
• Notação = (UML Notation Guide) – define uma sintaxe gráfica UML
• Semântica = (UML Semantics) – define uma semântica UML
Elementos:
• Elementos estruturais:
– classe, interface, colaboração, caso de uso, classe ativa, componente,
nó
• Elementos comportamentais:
– interação, máquina de estados
• Elementos de agrupamento:
– pacote, subsistema
Visões:
Visão de Visão da
Projeto Implementação
Codificação
Funcionalidade Montagem
Vocabulário
Visão de
Caso de Uso
Visão do Visão da
Processo Implantação
Desempenho Topologia do Sistema
Escalabilidade Distribuição
Throughput Instalação
Conceitual Físico
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 53
Análise e Desenho Orientado a Objetos com UML
Visões:
Visão de Caso
de Uso
• A visão do caso de uso abrange os casos de usos que descrevem o comportamento do sistema
conforme é visto pelos seus usuários finais, analista e pessoal de teste. Essa visão não especifica
realmente a organização do sistema de software. Porém , ela existe para especificar as forças que
determinam a forma da arquitetura do Sistema. Com a UML, os aspectos estáticos dessa visão
são representados em diagramas de caso de uso, enquanto os aspectos dinâmicos são
representados em diagrama de interação., diagrama de gráfico de estados e diagrama de
atividades
Visão de Projeto
Visões:
Visão de Processo
Visão de Implementação
Visões:
Visão de Implantação
Cada uma dessas visões pode ser considerada isoladamente, permitindo que diferentes
participantes orientem seu foco para os aspectos da arquitetura do sistema que mais lhes
interessem. Essas cincos visões também interagem entre si, por exemplo:
Os nós na visão de implantação contêm componentes da visão de implementação que, por sua vez,
representa a realização física de classes, interfaces, colaborações e classes ativas provenientes das visões
de projeto e de processo.
Diagrama de Estado
Diagrama de Classes Diagrama de Atividades
Diagrama de Pacotes
Component view
Diagrama de Componentes
Deployment view
Diagrama de Deployment
Engenharia de Requisitos
4
Casos de Uso
Requisitos Não
Funcionais Arquitetura Inicial
Introdução. Artefatos:
Produtos dos Workflows de Requisitos e de Análise:
Documento de Visão
Documento de Requisitos
Requisitos
Especificação de Requisitos (Casos de Uso)
Receber Pedido
Entrega
Receber Pagamento
getDescricao( )
exibirCategoria( )
selecionarCategoria
getDescricao( ) getQuantidade( )
exibirProduto( )
Encerrar Pedido
selecionarProduto( )
Projeto
Principais Produtos (Artefatos):
Diagrama de Atividades
Diagrama de Estados
Diagrama de Classes
Receber Pedido
getDescricao( )
Entrega
exibirCategoria( )
exibirProduto( )
Encerrar Pedido
Diagrama de Componentes
Diagrama de Deployment
Arquitetura
Principais Produtos (Artefatos):
Diagrama de Componentes
Diagrama de Distribuição(Deployment)
Modelo de Arquitetura
Especificação de Requisitos
de Software
Objetivo desta parte:
É apresentar e discutir o Ciclo de Requisitos de Software:
– Elicitação, Análise, Especificação de Requisitos de
Software com Caso de Uso
desenvolvimento do software. Não importa quão bem projetado ou quão bem codificado
seja, um programa mal analisado e especificado frustrará o usuário.
Análise de requisitos é um processo de descoberta, refinamento, modelagem e
especificação.
O dilema com o qual se depara um analista pode ser mais bem entendido, repetindo-se a
declaração de um cliente anônimo:
“Sei que você acredita que entendeu o que acha que eu disse, mas não estou certo
que percebeu que aquilo que ouviu não é o que eu pretendia dizer...”
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 65
Análise e Desenho Orientado a Objetos com UML
Engenharia de Requisitos
4
Casos de Uso
Workflow Requisitos
Capacitação Engenharia de Software
Requisitos
Workflow Artefatos Papéis
Arquitetura Documento de Visão
Analista de Sistema
Analista de Requisitos
Documento de Requisitos
Especificação de Requisitos
(Casos de Uso)
Da perspectiva da engenharia de software, a “elicitação” de requisitos é talvez a mais parte mais critica
do processo de desenvolvimento de software.
Estudos indicam que os requisitos, só detectados depois do software implementado ou erros na análise
de requisitos, são até 20 vezes mais caros de se corrigir que qualquer outro tipo de erro.
Requisitos
Capacitação Engenharia de Software
2) Uma condição ou uma capacidade que deve ser alcançada ou possuída por um sistema
ou componente do sistema, para satisfazer um contrato, um padrão, uma especificação
ou outros documentos impostos formalmente.
Requisitos
Capacitação Engenharia de Software
Documento de Visão
Documento de
Especificação
de Requisitos
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 70
Análise e Desenho Orientado a Objetos com UML
Requisitos
Capacitação Engenharia de Software
Requisitos
Capacitação Engenharia de Software
Participantes:
Analistas e
documentos Objetivo:
Especialista reuniões
em Negócios Descrever
a visão inicial
Participantes: identificação/
do software
Usuário, elicitação de
Clientes, Requisitos
Fornecedores e Documento
Patrocinadores de visão
entrevistas
Requisitos
Capacitação Engenharia de Software
Identificar Fontes
Como deve ser feito ? Planejamento Técnicas
Documento de Visão
Requisitos
Capacitação Engenharia de Software
Análise de Requisitos
Capacitação Engenharia de Software
Requisitos
Requisitos Requisitos
Funcionais Não-Funcionais
Os requisitos funcionais descrevem o que o Os requisitos não funcionais dizem respeito as
sistema deve fazer, isto é, as funções características que descrevem qualidade do serviço
(funcionalidades) necessárias para atender os (QoS).
objetivos. O que sistema deve saber fazer. A omissão ou esquecimento desses requisitos constitui
Exemplos: Buscar cliente, Registrar pedido uma das principais razões de uma eventual
Calcular conta de consumo, Calcular tributos e insatisfação dos usuários com relação a um software.
etc. Os Requisitos Não Funcionais (RNF) também são
chamamos de “Requisito Suplementares.”
Exemplos: performance, disponibiliade, confiabilidade,
segurança, usabilidade e etc.
Requisitos
Capacitação Engenharia de Software
Requisitos
Capacitação Engenharia de Software
Requisitos
Capacitação Engenharia de Software
Documento de Visão
Documento de
Especificação
de Requisitos
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 78
Análise e Desenho Orientado a Objetos com UML
Requisitos
Capacitação Engenharia de Software
Não Ambígua: Cada requisito deve ter somente uma interpretação (definição);
Requisitos
Capacitação Engenharia de Software
Análise de Requisitos
Atividades da Análise de Requisitos
A análise de requisitos possibilita que o Analista de Sistemas especifique as funcionalidades,
classificando e detalhando os requisitos encontrados na coleta.
Os requisitos funcionais serão descritos em detalhes. E os requisitos não funcionais serão classificados.
Detalhar os
Requisitos Funcionais
Classificar os
Requisitos não Funcionais
Documento de Requisitos
Descrever os Usuários
e Entidades Externas
Requisitos
Capacitação Engenharia de Software
Requisitos
Capacitação Engenharia de Software
Requisitos Funcional
RN: RN01 Nome: Reserva Descrição: Serviço de Atendimento e Reserva de Apartamento
ID Nome Descrição
RFC01 Registrar Reserva Esta funcionalidade deverá permitir o usuário (funcionário) a fazer reserva de apartamentos,
de Apartamento as ações que estarão disponíveis são: criar, cancelar, alterar e consultar reservas.
Requisitos
Capacitação Engenharia de Software
Requisitos
Capacitação Engenharia de Software
Categoria: Performance
Requisitos
Capacitação Engenharia de Software
Categoria: Usabilidade
Autor: Revisão: Data Atualização:
RF /
Código Descrição
Aplicação
As cores, as fontes e logotipos devem seguir o Manual de
Aplicação RNFU1
Identidade Visual da empresa.
Requisitos
Capacitação Engenharia de Software
Lista de Stakeholders
Nome Descrição
Requisitos
Capacitação Engenharia de Software
Nome Descrição
Requisitos
Capacitação Engenharia de Software
Requisitos
Capacitação Engenharia de Software
Documento de Visão
Documento de
Especificação
de Requisitos
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 89
Análise e Desenho Orientado a Objetos com UML
Requisitos
Capacitação Engenharia de Software
Especificação de Requisitos:
O produto que devemos ter após Análise de Requisitos é a “A especificação de Requisitos” é feita
através de Casos de Uso, conforme definido pela UML. Um conjunto de casos de uso é importante
para se compreender o que o usuário quer. Um caso de uso descreve uma funcionalidade (“requisito”)
a ser oferecida pelo sistema, ou seja, um serviço.
Requisitos Não
Documento
Funcionais
Requisitos
Funcionais
de Visão
Documento de
Requisitos
Especificação de Requisitos
Modelo de
Comportamento externo Casos de Uso Arquitetura
do Software
Comportamento interno Seqüência Colaboração
Estrutura Classes
Implementação Distribuição
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 90
Análise e Desenho Orientado a Objetos com UML
Requisitos
Capacitação Engenharia de Software
Especificação de Requisitos
Análise de Casos de Uso:
•Casos de uso expressam o diálogo entre os usuários e o sistema
•Casos de uso expressam “o quê” o sistema deverá fazer. E não “como” fazer.
•Casos de uso formam a base para testes e documentação do sistema
•O modelo de casos de uso expressam todos os casos de uso do sistema e os seus
relacionamentos.
•As técnicas para criar e expressar casos de uso em uma aplicação Web são as
mesmas para construir outros sistemas de software.
Objetivos:
• Identificar os atores;
• Identificar os casos de uso;
• Desenhar os casos de uso e
• Escrever cenários.
Requisitos
Capacitação Engenharia de Software
Especificação de Requisitos
Transformar os Requisitos
Funcionais em Casos de Uso:
Calcular Total
Fazer Cadastro
Cliente
Funcionário
Fazer Pedido
Emitir NF
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 92
Análise e Desenho Orientado a Objetos com UML
Requisitos
Capacitação Engenharia de Software
Especificação de Requisitos
Atividades e Passos:
Fazer Diagrama de
Casos de Uso
Identificar Atores /
Casos de Uso
Escrever cenários
Rational Rose
Escrever Formulário
Fazer Diagrama de
Caso de Uso
Requisitos
Capacitação Engenharia de Software
Casos de Uso
Introdução:
Os diagramas de caso de uso são usados para capturar os requisitos funcionais do sistema. Ajuda o
entendimento do contexto dos requerimentos do sistema.
Os casos de uso podem ser agrupados em pacotes, desta forma temos uma organização funcional.
Definição:
Caso de Uso é uma descrição de um conjunto de seqüências de ações, inclusive variantes, que um
sistema pode produzir um resultado de valor observável por um ator. A representação gráfica é uma
elipse.
Requisitos
Capacitação Engenharia de Software
Casos de Uso
Casos de Uso e Cenários:
Os casos de uso exibem a funcionalidade na perspectiva do usuário. Entretanto, podemos ter vários
caminhos para completar esta função. Um cenários é como uma “instance” do Caso de uso, isto é, um
caminho lógico com início e fim.
Principais características:
- Cenários não contém declarações condicionais;
- Pode ter mesmo começo, mas, com final diferente;
- Um cenário é narrativa de uma situação e
- Os cenários devem descrever os bons caminhos e maus também.
Requisitos
Capacitação Engenharia de Software
Casos de Uso
Casos de Uso e Fluxo de Eventos:
Uso caso de uso descreve “o quê” um sistema (ou subsistema, classe, ou interface) faz,
ele não especifica “como” isso é feito. Ao fazer uma modelagem, importante manter clara a separação
de questões entre a visão interna e externa.
Podemos especificar o comportamento de um caso de uso pela descrição do fluxo de eventos no texto
de maneira suficientemente clara para que qualquer pessoa possa entende-lo facilmente. Ao
escrevermos o fluxo de eventos devemos incluir como e quando o caso de uso inicia e termina, como e
quando o caso de uso interage com os atores e o fluxo básico e fluxo alternativo do comportamento.
Tipos de fluxos:
• Fluxo de eventos principal e
• Fluxo alternativo de eventos.
Requisitos
Capacitação Engenharia de Software
Casos de Uso
Casos de Uso e Formulário:
Os formulários devem ter as seguinte informações:
- Ponto de ativação (momento que caso de uso começa)
- Nome do caso de uso
- Objetivo
- Atores que participam do caso de uso
- Pré-condição
- Fluxo Normal
- Fluxo Alternativo
- Pós-condição.
Requisitos
Capacitação Engenharia de Software
Casos de Uso
Exemplos de Casos de Uso:
Gerente
Gerar catalogo
Manter informação de
professor
Aluno
Selecionar curso
para ensinar
Requisitos
Capacitação Engenharia de Software
Casos de Uso
Casos de Uso e Formulário Nome: Fazer Busca Produto
Ponto de ativação: Este caso de uso começa quando entra na página
Exemplo: de Busca e seleciona um item da caixa de seleção
Ator: Visitante e Cliente
Objetivo: Fazer busca de produto por categoria
Pré-condição: Aplicação Disponível
Fluxo Normal:
1 - O visitante seleciona a página de busca
2 - O visitante seleciona a categoria para busca
3 - O visitante informar o produto
4 - O visitante pressiona o botão buscar
5 - O sistema processa a busca
6 - Retorna as informações sobre o produto
Fluxo Alternativo:
1 - O Visitante seleciona a página de busca
2 - O visitante seleciona a categoria para busca
3 - O visitante informar o produto
4 - O visitante pressiona o botão buscar
5 - O sistema processa a busca
6 - Retorna as uma mensagem “produto não encontrado”
Pós-condição: Busca realizada
Requisito Funcional: RF002 -Fazer Busca do Produto
Requisito Não Funcional: ---
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 99
Análise e Desenho Orientado a Objetos com UML
Requisitos
Capacitação Engenharia de Software
Casos de Uso
Elementos dos Caso de Uso:
Ator:
Um ator representa um conjunto coerente de papéis que os usuários de casos de
uso desempenham quanto interagem com esses casos de uso. Geralmente um
ator representa um papel, que pode ser de pessoa, de um sistema ou de um
dispositivo e etc...
Cenários:
É narrativa de determinado fato ou de uma situação.
“O caso de uso deve ser descrito através de cenários. Devem ser construídos tantos
cenários quantos forem necessários para se entender completamente todo o
sistema. Podem ser considerados como teste informais para validação dos requisitos do
sistema.”
Formulário:
É a representação estruturada de um ou mais cenários
Requisitos
Capacitação Engenharia de Software
Generalização:
Entre os casos de uso é parecida à generalização existente entre as classes.
No caso de uso a generalização significa que o caso de uso filho herda o
comportamento e o significado do caso de uso pai; o filho poderá acrescentar ou sobrescrever o
comportamento de seu pai; poderá ser substituído em qualquer local qual o pai apareça.
Include:
Quando você estiver se repetindo em dois ou mais caso de uso separados
devemos evitar a repetição
Extends:
Quando estivermos descrevendo uma variação em comportamento normal, entretanto, querendo
fazer uma descrição mais controlada, explicando os pontos de extensão no caso de uso.
Realizes:
Especifica a colaboração entre os casos de uso
Requisitos
Capacitação Engenharia de Software
Receber Pagamento
generalização
Funcionário
Gerente de
Recepcionista
Reservas
Requisitos
Capacitação Engenharia de Software
Usuário
<<extend>>
<<include>> <<extend>>
<<include>>
Requisitos
Capacitação Engenharia de Software
O caso de uso incluído nunca permanece isolado, mas é apenas uma “instance” como parte de alguma
base maior que o inclui. Você pode pensar na inclusão como o caso de uso base que o obtém o
comportamento a partir do fornecedor do caso de uso. Você utiliza um relacionamento de inclusão para
evitar descrever o mesmo fluxo de eventos várias vezes, incluindo o comportamento comum em um caso
de uso próprio. O relacionamento de inclusão é essencialmente um exemplo de delegação, você coleta
um conjunto de responsabilidades do sistema e o captura um único local (o caso de uso incluído); depois,
permite que outras partes do sistema (outros casos de uso) incluam a nova agregação de
responsabilidade sempre que precisamos utilizar essa funcionalidade.
Exemplos:
Fazer Pedido Fazer Check IN Fazer Check OUT
Gerenciar Receber
Acompanhar Pedido Pagamento
Reserva <<include>>
<<include>>
<<include>>
Requisitos
Capacitação Engenharia de Software
Casos de Uso
Casos de Uso - Identificação de Atores
Os atores não fazem parte do sistema - eles representam qualquer um e qualquer coisa
que faça interação com sistema. Podendo ser uma pessoa, software, hardware e etc.
Requisitos
Capacitação Engenharia de Software
Casos de Uso.Dicas
Um engano comum na identificação de casos de uso é representar como Caso de uso
passos individuais, operações ou transações.
Exemplo:
No domínio de ponto de venda, alguém pode definir um caso de uso chamado
“Imprimindo o Recibo”, quando de fato, a operação de impressão é meramente um passo
no processo muito mais abrangente do caso de uso Comprar Itens
Lembre-se:
Requisitos
Capacitação Engenharia de Software
1 Requisitos Funcionais
2
• Gerenciar Reserva
•...
Refinado pelo
Documento de
Visão
„
Documento
de Requisitos
Requisitos
Capacitação Engenharia de Software
3
Formulário
Cenários
Gerenciar Reserva
Usuário
Caso de Uso
Ator
Associação
Requisitos
Capacitação Engenharia de Software
Requisitos
Capacitação Engenharia de Software
Cenários Formulário
O Setor de Reserva do Hotel recebe um telefonema de cliente que solicita uma reserva
de apartamentos para data.
O cliente informa o período, ou seja, data de chegado e partida, e qual tipo de apartamento
Pré- condição ele precisa.
O funcionário do Setor de Reserva, verifica a disponibilidade do apartamento e confirma a
reserva.
Pós- condição
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 110
Análise e Desenho Orientado a Objetos com UML
Requisitos
Capacitação Engenharia de Software
Requisitos
Capacitação Engenharia de Software
Ator: Funcionário
Requisitos
Capacitação Engenharia de Software
3
Formulário
Cenários
Gerenciar Reserva
Funcionário
Caso de Uso
Ator
Associação
Requisitos
Capacitação Engenharia de Software
Mitos e Lendas
• Requisitos não são Casos de Uso;
Requisitos
Capacitação Engenharia de Software
Requisitos
Capacitação Engenharia de Software
Requisitos
Capacitação Engenharia de Software
Documento de Visão
Documento de
Especificação
de Requisitos
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 117
Análise e Desenho Orientado a Objetos com UML
Requisitos
Capacitação Engenharia de Software
Validação de Requisitos
Deve preocupa-se em mostrar que os requisitos definem o sistema que o cliente/usuário
deseja.
Validação é importante uma vez que o custo para remover um erro de requisitos é
grande.
Requisitos
Capacitação Engenharia de Software
Validação de Requisitos
Técnicas de validação de requisitos
Revisão de requisitos:
- Análise manual sistemática dos requisitos
Prototipação:
- Uso de um modelo executável do sistema para checar os requisitos.
Geração de casos de teste:
- Desenvolver testes para os requisitos a fim de verificar a “testabilidade”.
Análise automatizada da consistência:
- Uso de ferramenta para verificar a consistência do modelo.
Requisitos
Capacitação Engenharia de Software
Validação de Requisitos
Técnicas de validação de requisitos
Revisão de requisitos:
- Revisões regulares devem ocorrer durante a formulação da definição dos requisitos
- Tanto o cliente quanto a equipe contratada devem estar envolvidos nas revisões
- As revisões podem ser formais (com documentos completos) ou informais. Uma boa
comunicação entre os desenvolvedores, clientes e usuários pode resolver problemas em
estágios iniciais
Verificação de revisões:
- “Verificabilidade”. O requisito é realisticamente testável?
- Compreensibilidade. O requisito é propriamente entendido?
- Rastreabilidade. A origem do requisito é claramente estabelecida?
- Adaptabilidade. O requisito pode ser modificado sem grande impacto sobre outros
requisitos?
Requisitos
Capacitação Engenharia de Software
Estrutura do Documento:
1.0 Introdução
1.1 propósito do documento de requisitos
1.2 escopo do produto
1.3 definições, acrônimos e abreviações
1.4 referências
1.5 visão geral do restante do documento
2.0 Descrição geral
2.1 perspectiva do produto
2.2 funções do produto
2.3 características do usuário
2.4 restrições gerais
2.5 suposições e dependências
3. Requisitos (Específicos)
os requisitos podem documentar interfaces externas, descrever funcionalidade e desempenho do
sistema, especificar requisitos lógicos de banco de dados,restrições de projeto, características de
qualidade.
4. Apêndices
5. índice
Análise Conceitual
Engenharia de Requisitos
4
Casos de Uso
Requisitos Não
Funcionais Arquitetura Inicial
Workflow Analise
Capacitação Engenharia de Software
Analise
Workflow Artefatos Papéis
Arquitetura Modelo Conceitual ou Modelo
de Domínio
Analista de Sistema
Analista de Requisitos
Arquiteto de Software
Vocabulário do Sistema
Workflow de Análise
Capacitação Engenharia de Software
Introdução:
Modelo de Casos de Uso de software é elaborado para dar a Visão de Caso de Uso.
Esta visão fornece uma perspectiva do software a partir de um ponto de vista externo.
Os aspectos dinâmicos descrevem a troca de mensagens entre os objetos e a sua
reação a eventos que ocorrem no software. O aspecto dinâmico será apresentado na
terceira parte, no workflow de Projetos.
Visão da
Visão de
Implementação
Funcionalidade Projeto Codificação
Vocabulário Montagem
Visão de Caso de
Uso
Gerenciar Reserva Visão do Visão da Implantação
Funcionário Desempenho Processo Topologia do Sistema
Escalabilidade Distribuição
Throughput Instalação
O aspecto estrutural estático permite entender como uma software está estruturado
internamente para atender os requisitos (visão externa).
Esse aspecto é chamado de estático porque não apresenta informações sobre como os
objetos se comportam no ciclo de vida de software e também porque representa a estrutura
das classes de objetos e os relacionamentos entre elas.
Workflow de Análise
Capacitação Engenharia de Software
Objetivo:
Apresentar e discutir como elaborar o Modelo Conceitual (também chamado de modelo de
domínio) e o Vocabulário de Conceitos. Para isto apresentaremos um algumas técnicas
para identificação dos candidatos a classes.
Os objetivos desta etapa são:
1 - Apresentar técnicas para identificação dos candidatos a classes, atributos e
associações;
2 - Elaborar o Modelo Conceitual ou modelo de domínio e
3 - Elaborar o Vocabulário de Conceitos.
Workflow de Análise
Capacitação Engenharia de Software
Atividades.Road Map
Fazer Vocabulário
Documento de
Visão Vocabulário
Definir o modelo de
Arquitetura
Modelo de Arquitetura
Workflow de Análise
Capacitação Engenharia de Software
Atividades e Artefatos:
Para este workflow as principais atividades e artefatos são:
Workflow de Requisitos:
Atividade:
Coletar Requisitos
Fazer Análise de Requisitos.
Fazer Especificação de Requisitos;
Artefatos: Documento de Visão
Documento de Requisitos
Caso de Uso
Workflow de Análise
Atividade:
Fazer Análise Conceitual
Fazer Vocabulário de Conceitos
Workflow de Análise
Capacitação Engenharia de Software
Os objetivos são:
Workflow de Análise
Capacitação Engenharia de Software
Documento de
Visão
Workflow de Análise
Capacitação Engenharia de Software
Workflow de Análise
Capacitação Engenharia de Software
Pessoa
Pessoa
-nome
nome -idade
idade
<<refines>> +setNome()
+getNome()
+getIdade()
+getIdade()
Workflow de Análise
Capacitação Engenharia de Software
Identificar os candidatos
a classe
Fazer a Lista de
Candidatos
Desenhar o Modelo
Conceitual
Definir a Arquitetura
Inicial
Workflow de Análise
Capacitação Engenharia de Software
Workflow de Análise
Capacitação Engenharia de Software
UML. Introdução
A UML deve ser utilizada para criarmos o Modelo Conceitual. Os modelos visuais ajudam
a compreender melhor o sistema que estamos construindo.
As seguir será apresentado os nós, elementos e adornos usados para construir o modelo.
Workflow de Análise
Capacitação Engenharia de Software
Agora faremos apenas o Modelo Conceitual que podemos considerar como o primeiro
“esboço” do que mais tarde se tornará o Diagrama de Classes.
Workflow de Análise
Capacitação Engenharia de Software
UML. Elementos:
Elementos estruturais:
Classe, Interface, Colaboração, Caso de Uso, Classe Ativa, Nó e
Componente
Elementos de agrupamento:
Pacote e Subsistema
Workflow de Análise
Capacitação Engenharia de Software
UML. Elementos:
• Dependência
• Associação
– Associação
– Composição
– Agregação
• Generalização
Mecanismos de Extensibilidade:
• Estereótipo
• “Tagged value”
• Restrição (Constraint)
Workflow de Análise
Capacitação Engenharia de Software
Diagrama de Classes
Workflow de Análise
Capacitação Engenharia de Software
Associação
Definição de Associação:
Um relacionamento estrutural que descreve um conjunto de vínculos, em que o vínculo
é uma conexão entre objetos; relacionamento semântico entre dois ou mais
classificadores que envolve as conexões entre seus objetos.
Associação
classe classe
Usuario Senha
Workflow de Análise
Capacitação Engenharia de Software
Associação
Nome de Associação:
Uma associação pode ter um nome, que pode usado para descrever a natureza do
relacionamento. Podemos ainda acrescentar um triângulo para demonstrar a direção do
nome, ou seja, a direção que nome deve ser lido.
Nome da associação
Direção do nome
faz
Cliente Pedido
Observação:
Apesar da possibilidade de a associação ter um nome, não é necessário incluí-lo. Recomendamos o uso do
nome quando o modelo possui muitas associações e você tem a necessidade de fazer referência às
associações ou de destaca-las.
Workflow de Análise
Capacitação Engenharia de Software
Associação
Navegação:
Indica qual é a direção da associação. A direção da associação pode ser unidirecional (onde
somente uma das pontas da linha de associação tenha a seta) ou bidireciona (não existem
setas em nenhum dos lados)
Associação
Navegação
Cliente Pedido
Workflow de Análise
Capacitação Engenharia de Software
Role Name:
Definição de Role Name:
É um identificador (nome) do papel da associação, podendo cada ponta ter um nome
especifico.
Modificadores:
(+) public | (-) private | (#) protected
Workflow de Análise
Capacitação Engenharia de Software
Multiplicidade
Definição:
A especificação de uma faixa de números cardinais, que um conjunto pode assumir.
Eqüivale a muitos
Workflow de Análise
Capacitação Engenharia de Software
Multiplicidade
Para cada objeto (instance) da classe Pessoa a classe
Empresa poder ter uma ou muitos objetos.
Workflow de Análise
Capacitação Engenharia de Software
Inspeção Análise de
CRC
Gramatical Caso de Uso
Scott Ambler
Graig Larman
Peter Coad
Outras
Técnicas
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 146
Análise e Desenho Orientado a Objetos com UML
Workflow de Análise
Capacitação Engenharia de Software
É uma técnica útil, por causa da simplicidade, proposta por Abbot. Consiste em identificar
os substantivos no texto da Declaração de Problema e considerá-los como candidatos a
a classe ou conceitos.
Workflow de Análise
Capacitação Engenharia de Software
Declaração de
Visão 1º Lista Lista Final
Workflow de Análise
Capacitação Engenharia de Software
Modelo Conceitual
Lista de Candidatos
Vocabulário de Conceitos
Workflow de Análise
Capacitação Engenharia de Software
Nome da associação
Classe
Reserva Cliente
1..* feita por 1
numero id
data-entrada hospede nome
data-saida documento
Atributo 0..*
Multiplicidade
Apartamento
1..*
numero
tipo
situacao
Associação
Workflow de Análise
Capacitação Engenharia de Software
Workflow de Análise
Capacitação Engenharia de Software
Workflow de Análise
Capacitação Engenharia de Software
Preço Cliente
Workflow de Análise
Capacitação Engenharia de Software
Atributos:
Dados de contas, extrato, dinheiro e dados de transações
Conceito redundante:
Usuário
Conceito Irrelevante:
Preço
Conceito de implementação:
Registro de Transação, Acesso, Software e Linha de Comunicação
Eliminado às classes apontadas, ficamos com as seguintes conceitos válidos:
Conta, ATM, Banco, Computador do Banco, Cartão Magnético, Caixa Terminal do Caixa, Computador
Central, Consórcio, Cliente e Transação
Workflow de Análise
Capacitação Engenharia de Software
Identificando as Associações:
Qualquer dependência entre duas ou mais conceitos é uma associação. Uma referência
de uma classe a outra é uma associação.
As associações muitas vezes correspondem a verbos estáticos ou a locuções verbais.
Isso inclui localização física:
- junto a, parte de, contido em e etc
Ações indiretas:
- direciona, comunica-se (fala a), propriedade (tem, parte de), ou satisfação de alguma
condição (trabalha para, casado com, gerencia).
Tente identificar as associações, lembre-se que nem todas, estão explicitas, pode haver
muitas transações implícitas e algumas associação dependem do conhecimento do
mundo real, ou seja, do negócio.
Extraia todas as candidatas do enunciado do problema e as escreva em uma lista, e
depois refine-as.
Workflow de Análise
Capacitação Engenharia de Software
Workflow de Análise
Capacitação Engenharia de Software
Workflow de Análise
Capacitação Engenharia de Software
Workflow de Análise
Capacitação Engenharia de Software
Workflow de Análise
Capacitação Engenharia de Software
Workflow de Análise
Capacitação Engenharia de Software
Transacao Transacao
Datahora Datahora:Timestamp
+getTransacao()
+setDataHora()
+getDataHora()
Conceito de Classes
classes e atributos
Workflow de Análise
Capacitação Engenharia de Software
Workflow de Análise
Capacitação Engenharia de Software
CRC
Método dirigido a responsabilidades:
Neste método, a ênfase está na identificação das classes a partir de seus comportamentos
relevante ao sistema.
Técnica Cartão (CRC):
O CRC foi apresentado por Kent Beck e Ward Cunningham em artigo chamado:
"A Laboratory for Teaching Object-Oriented Thinking" no OOPLSA '89.
Conceito e Aplicação:
Observação:
O CRC não faz parte da UML. Mas é uma técnica recomendada, pela sua simplicidade,
principalmente para quem tem pouca experiência com orientação a objetos.
Workflow de Análise
Capacitação Engenharia de Software
Objeto
Colaborações:
Responsabilidades:
(o que objeto conhece e o que faz) + (outras classes que são associadas,
para a interação entre os objetos)
Workflow de Análise
Capacitação Engenharia de Software
CRC. Elementos:
O nome do cartão é o mesmo nome da classe, as responsabilidades são as coisas que a
classe dever saber fazer e coisas que ela deve conhecer.
As colaborações as informações que a classe precisa e que está alocada em outra classe,
desta forma temos que fazer o relacionamento entre classes, para que ela
cumpra com sua responsabilidade.
Modelo:
Nome da Classe
Responsabilidades: Colaborações:
Melhores Práticas:
Os candidatos a classe cujo a responsabilidade não foi encontrada, este candidato deve
ser descartado. Pois, não podemos ter classe sem nenhuma responsabilidade.
Workflow de Análise
Capacitação Engenharia de Software
CRC. Exemplos:
Classe: Reserva
Responsabilidades: Colaborações:
Conhecer o período da reserva
Apartamento
(datas)
Cliente
Saber o nome do cliente
Saber o número do apartamento
Classe: Cliente
Responsabilidades: Colaborações:
Workflow de Análise
Capacitação Engenharia de Software
Responsabilidades: Colaborações:
SaberClasse:
o nome do clienteReserva
Cliente
Saber a Reserva do Cliente
Responsabilidades: Colaborações:
Responsabilidades: Colaborações:
Workflow de Análise
Capacitação Engenharia de Software
Formulário
Cenários
Usuário
Gerenciar Reserva
Caso de Uso Listas de Candidatos
Ator Associação
Workflow de Análise
Capacitação Engenharia de Software
Engenharia de Requisitos
Cenários
Casos de Uso
Lista de Requisitos
Não Funcionais
Usuário Gerenciar Reservas
Ator Associação
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 169
Análise e Desenho Orientado a Objetos com UML
Workflow de Análise
Capacitação Engenharia de Software
Usuário
Gerenciar Reserva Reserva é provável candidato a classe
<<include>>
Funcionário <<include>>
Criar Reserva Cadastrar Cliente prováveis candidatos a classe
Remover Reserva
Workflow de Análise
Capacitação Engenharia de Software
O Setor de Reserva do Hotel recebe um telefonema de cliente que solicita uma reserva
de apartamentos para data.
O cliente informa o período, ou seja, data de chegado e partida, e qual tipo de apartamento
ele precisa.
O funcionário do Setor de Reserva, verifica a disponibilidade do apartamento e informa
Cenários que não tem disponibilidade de apartamento para o período informado pelo cliente e
oferece um outro tipo de apartamento.
O cliente não aceita a proposta do funcionário e a reserva não é confirmada.
Workflow de Análise
Capacitação Engenharia de Software
Workflow de Análise
Capacitação Engenharia de Software
Saber o nome
Classe: do cliente
Cliente Reserva
Saber a Reserva do Cliente
Responsabilidades: Colaborações:
Workflow de Análise
Capacitação Engenharia de Software
Workflow de Análise
Capacitação Engenharia de Software
Graig Larman
Larman sugere a que a identificação dos substantivos, que são os candidatos a classe ou
conceitos seja feito através dos Casos de Uso “expandidos”, pois, eles fornecem uma
excelente descrição a serem usadas como fontes para este tipo de análise.
Exemplo:
Entretanto esta técnica exige uma ou mais revisão nos conceitos encontrados, pois,
diferentes substantivos podem representar o mesmo conceito.
Workflow de Análise
Capacitação Engenharia de Software
Graig Larman
Larman também sugere usar uma abordagem de Categoria de Conceitos, que nada mais
é que uma lista de categorias. Após determinar lista use-a para identificar os conceitos.
Exemplo de lista:
Categoria Exemplos
Objeto físico ou tangível Terminal de ponto-de-venda
Avião
Lugares Loja
Aeroporto
Workflow de Análise
Capacitação Engenharia de Software
Graig Larman
Identificação dos Conceitos:
Abaixo um exemplo de identificação dos conceitos a partir dos Formulários dos Casos
de Uso:
Workflow de Análise
Capacitação Engenharia de Software
Peter Coad
A Proposta de Coad & Yourdon:
O método Análise Orientada a Objetos, proposto por Peter Coad e Yourdon e denominado
OOA (Object Oriented Analysis), consiste basicamente em cinco passos:
Workflow de Análise
Capacitação Engenharia de Software
Workflow de Análise
Capacitação Engenharia de Software
Vocabulário.Road Map:
Fazer Vocabulário
Documento de
Visão Vocabulário
Workflow de Análise
Capacitação Engenharia de Software
Vocabulário:
Fazer Vocabulário
Descrever os conceitos
Fazer Vocabulário:
Devemos fazer um Vocabulário de todas as classes presente no Modelo Conceitual.
O vocabulário consiste em simples descrição do conceito.
Transacao
Datahora
Transação – Uma única solicitação integral para operações nas
contas de um único cliente. Especificamente somente que as ATM
podem entregar dinheiro, mas não podemos eliminar a
possibilidade da impressão de cheques ou de receber dinheiro ou
cheques. Também queremos prover a flexibilidade de operar as
contas de diferente clientes, embora isso não seja exigido. As
diferentes operações devem fechar apropriadamente.
Workflow de Análise
Capacitação Engenharia de Software
Modelo Conceitual.
Workflow de Análise
Capacitação Engenharia de Software
Vocabulário. Exemplo:
Vocabulário:
ATM – Uma estação que permite os clientes introduzem suas próprias transações
utilizando cartões magnéticos como identificação. A ATM interage com o cliente para
obter informações sobre transações, envia as informações sobre transações para o
computador central para validação e processamento e entrega de dinheiro ao usuário.
Presumimos que uma ATM não necessita operar independente de rede.
Banco – Uma instituição financeira que mantém contas de cliente e emite cartões
magnéticos autorizando o acesso às contas através da ATM.
Workflow de Análise
Capacitação Engenharia de Software
Vocabulário. Exemplo:
Vocabulário:
Cliente – Possuidor de uma ou mais contas em um banco. Um cliente pode ser uma ou
mais pessoas ou corporações; a correspondência não é relevante para este problema. Se
uma pessoa possui conta em um diferente banco é considerada cliente diferente.
Workflow de Análise
Capacitação Engenharia de Software
Vocabulário. Exemplo:
Vocabulário:
Computador Central - Computador operado pelo consórcio que despacha transações entre as ATM e
os computadores dos bancos. O computador central valida códigos de bancos mas não processam
transações diretamente.
Consórcio – Organização de bancos que comissiona e opera a rede ATM. A rede só manipula
transações do consórcio.
Conta – Única conta no banco contra a qual as transações podem ser aplicadas. As contas podem ser
de vários tipos, no mínimo de cheques e de poupança. Um cliente pode manter mais de uma conta.
Terminal de caixa – Terminal no qual os caixas introduzem transações para os clientes. Os caixas
entregam a recebem dinheiro e cheques; a impressora do terminal imprime extratos. O terminal do
caixa comunica-se com o computador central do banco para validar e processar transações.
Transações – Uma única solicitação integral para operações nas contas de um único cliente.
Especificamente somente que as ATM podem entregar dinheiro, mas não podemos eliminar a
possibilidade da impressão de cheques ou de receber dinheiro ou cheques. Também queremos prover
a flexibilidade de operar as contas de diferente clientes, embora isso não seja exigido. As diferentes
operações devem fechar apropriadamente.
Workflow de Análise
Capacitação Engenharia de Software
Diagrama de Objetos
Introdução:
Bem o última coisa a fazer neste Workflow é fazer a validação do Diagrama de Classes.
Podemos fazer esta validação utilizando o Diagrama de Objetos e os Casos de Uso. Desta forma
estaremos garantindo que o Diagrama de Classes feito atende os requisitos.
:Nome do Objeto
Nome do Objeto
vínculo
Atributo: Valor do atributo
Workflow de Análise
Capacitação Engenharia de Software
Diagrama de Objetos
Recomendamos o uso do Diagrama de Objetos para validar o Diagrama de Classes.
Exemplo:
Matricula 201-23-02-01:Matricula
-Matricula: int Matricula: 201-23-02-01 vinculo
-Curso: String Curso: Adm Empresas
Workflow de Análise
Capacitação Engenharia de Software
Diagrama de Objetos
Conteúdo do Diagrama de Objetos:
Objetos e Vinculo
Diagrama de Objetos
objeto :Aluno
Nome: “Fulano de Tal”
Data: 23-02-2001
201-23-02-01:Matricula
Matricula: 201-23-02-01 vínculo
Curso: Adm Empresas
Um vínculo é uma
conexão semântica existente
entre os objetos.
Em geral, um vínculo é uma
“instance” de uma associação.
Desta forma um objeto pode
enviar uma mensagem para
outro.
Workflow de Análise
Capacitação Engenharia de Software
Diagrama de Objetos
Como fazer a modelagem de um estrutura de objetos:
Como posso
• Identifique o mecanismo cuja modelagem você deseja fazer. Um mecanismo
validar o
representa algum requisito ou comportamento da parte do sistema cuja a
diagrama de
modelagem você está fazendo e que é resultante da interação de um conjunto
classes?
de classes, interfaces e outros itens.
• Para cada mecanismo, identifique todos os itens (classes, interfaces e outros
elementos) que participam nessa colaboração e seus relacionamentos.
• Leve em consideração somente um cenário capaz de percorrer esse
mecanismo. Congele o cenário em determinado momento e represente cada
objeto que participa do mecanismo.
• Exponha o estado e os valores dos atributos de cada um desses objetos,
conforme seja necessário, para compreensão do cenário.
• De maneira semelhante, exponha os vínculos existentes entre esses objetos,
representando as “instance” de associação entre eles.
Workflow de Análise
Capacitação Engenharia de Software
Fazer Vocabulário
Documento de
Visão Vocabulário
Definir o modelo de
Arquitetura
Modelo de Arquitetura
Workflow de Análise
Capacitação Engenharia de Software
Podemos criar um Modelo de Arquitetura Inicial para aplicação. O objetivo deste modelo é apresentar
um visão macro da arquitetura.
Os modelos de Caso de Uso e Modelo Conceitual são utilizados para desenhar este o modelo.
Uma visão inicial da arquitetura pode ter muita formas, podemos utilizar a UML para representar este
modelo ou qualquer outra notação.
Este modelo será refinado no workflow de projeto na Atividade “Fazer o Modelo de Arquitetura”.
Camada de Camada
Camada Banco de
serviço regra de
apresentação Dados
4
(controle) negócio
Diagrama de Deployment
Apêndice
Capacitação Engenharia de Software
Diagrama de Pacotes
Como podemos definir o diagrama de pacotes?
A definição de Pacote é uma generalização, ou seja, um agrupamento, com o propósito de
organizar as Classes de Objetos em grupos. Esta abordagem facilita a análise a medida
que o número de Classes de Objetos cresce num do cenário. O tipo de relacionamento é
linha pontilhada com uma seta que indica dependência. Os diagramas de pacote podem
ser usados para fazer decomposição funcional.
A notação usada pela UML para representar pacotes é:
Nome do Nome do
Pacote Pacote
Nome do Pacote
Nome do
Pacote
Dependência
(import)
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 192
Análise e Desenho Orientado a Objetos com UML
Apêndice
Capacitação Engenharia de Software
Diagrama de Pacotes
Decomposição. “Dividir para conquistar...”
Algumas aplicações podem ser enormes ou ter um grau muito alto de complexidade ou
ambas as coisas. Para facilitar é necessário fazer uma decomposição.
A idéia da decomposição é simples. É fazer uma divisão para simplificar o entendimento, a
modelagem ou processo de desenvolvimento de um software.
Veja o exemplo abaixo:
Contas a Fluxo de
Pagar Caixa
Nome do Pacote
Subsistema
Contas a
Receber Dependência
(import)
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 193
Capacitação Engenharia de Software Análise e Desenho Orientado a Objetos com UML
Workflow de Projeto
Capacitação Engenharia de Software
Objetivo:
Apresentar e discutir o Workflow de Projeto, também conhecida como “Fase de
Especificação”, agora faremos uso da intenso da UML para fazer os modelos (diagramas)
e a documentação.
Workflow de Projeto
Capacitação Engenharia de Software
Visão de Visão da
Projeto Implementação
Codificação
Funcionalidade Montagem
Vocabulário
Visão de
Caso de Uso
Visão do Visão da
Processo Implantação
Desempenho Topologia do Sistema
Escalabilidade Distribuição
Throughput Instalação
Conceitual Físico
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 196
Análise e Desenho Orientado a Objetos com UML
Workflow de Projeto
Capacitação Engenharia de Software
Visão de Processo
Workflow de Projeto
Capacitação Engenharia de Software
Esse aspecto é chamado de estático porque não apresenta informações sobre como os
objetos se comportam no ciclo de vida de software e também porque representa a estrutura
das classes de objetos e os relacionamentos entre elas.
Workflow de Projeto
Capacitação Engenharia de Software
ESTÁTICOS DINÂMICOS
. Diagrama de Classes . Diagrama de Casos de Uso
. Diagrama de Objetos . Diagramas de Interação
. Diagrama de Componentes - Diagrama de Seqüência
. Diagrama de Distribuição - Diagrama de Colaboração
. Diagrama de Atividade
. Diagrama de Estados
Workflow de Projeto
Capacitação Engenharia de Software
Introdução
A Workflow de Projeto depende da Workflow de
Análise:
dependência
Workflow de Projeto
Capacitação Engenharia de Software
Introdução
A Workflow de Projeto refina a Workflow de
Análise:
Workflow de Análise Workflow de Projeto
modelo conceitual Diagrama de Classes
Atributos:
Cliente Cliente Tipo de dados
Workflow de Projeto
Capacitação Engenharia de Software
Receber Pedido
Entrega
Receber Pagamento
getDescricao( )
exibirCategoria( )
selecionarCategoria
getDescricao( ) getQuantidade( )
exibirProduto( )
Encerrar Pedido
selecionarProduto( )
Workflow de Projeto
Capacitação Engenharia de Software
Arquitetura
Workflow Artefatos Papéis
Arquitetura Diagrama de Seqüência /
Colaboração
Analista de Sistema
Projetista de Software
Diagrama de Atividades Arquiteto de Software
Diagrama de Estados
Diagrama de Classes
Workflow de Projeto
Capacitação Engenharia de Software
Atividades.Road Map
Workflow de Projeto
Capacitação Engenharia de Software
Identificar as classes de
Especificação
Fazer Diagrama de
Interação
Fazer a Diagrama de
Atividades / Estados*
Refinar o Modelo
de Classes
Modelo de
Especificação
Workflow de Projeto
Capacitação Engenharia de Software
“O quê” <<include>>
selecionar categoria
getDescricao( )
exibirCategoria( )
selecionarCategoria
getDescricao( ) getQuantidade( )
exibirProduto( )
selecionarProduto( )
Formulário
Workflow de Projeto
Capacitação Engenharia de Software
• Diagrama de Seqüência:
O foco deste diagrama é maneira que as mensagens são enviadas ao longo do tempo.
• Diagrama de Colaboração:
Aqui o foco é o relacionamentos estrutural entre os objetos de uma interação e então
considerar como as mensagens são passadas no contexto dessa estrutura.
Workflow de Projeto
Capacitação Engenharia de Software
Diagrama de Interação
O que é Diagramas de Seqüência?
É um diagrama que exibe a colaboração dinâmica entre objetos de um sistema. O
principal aspecto deste diagrama é que a partir dele percebe-se a seqüência de
mensagens enviadas entre os objetos. Ele mostra a interação entre os objetos e os
eventos que acontecem em um ponto específico da execução do sistema.
Notação:
Diagrama de Seqüência
:Objeto 1 :Objeto 2
Ator: 1: mensagem 1
2: mensagem 2
3: mensagem 3
Workflow de Projeto
Capacitação Engenharia de Software
Diagrama de Interação
Diagramas de Seqüência:
Workflow de Projeto
Capacitação Engenharia de Software
Diagrama de Interação
Diagramas de Seqüência:
Aluno:
entrar com o
semestre
obter cursos
Workflow de Projeto
Capacitação Engenharia de Software
Diagrama de Interação
Diagramas de Seqüência. Elementos:
Instance das classes
ator
getDadosCliente( )
[* se cliente cadastrado
verificar divida ]
getDivida( )
getDisponibilidade( )
setSaida( )
[* se veículo
disponível ]
Autodelegação
Workflow de Projeto
Capacitação Engenharia de Software
Diagrama de Interação
Diagramas de Seqüência. Numerando as seqüências das mensagens.
1: getDescricao( )
2: exibirCategoria( )
3: selecionarCategoria
4: getDescricao( ) 5: getQuantidade( )
6: exibirProduto( )
7: selecionarProduto( )
Workflow de Projeto
Capacitação Engenharia de Software
Diagrama de Interação
O que é Diagrama de Colaboração?
É um diagrama que mostra a colaboração dinâmica entre os objetos, semelhante ao
diagrama de seqüência.
No diagrama de colaboração, além de mostrar a troca de mensagens entre os objetos,
percebe-se também as colaborações dos objetos.
A interação de mensagens é mostrada em ambos os diagramas.
Diagrama de Colaboração tem a maioria de suas características semelhantes ao
Diagrama de Seqüência.
Workflow de Projeto
Capacitação Engenharia de Software
Diagrama de Interação
O que é Diagrama de Colaboração ?
O diagrama de colaboração é desenhado como um diagrama de objeto, onde os diversos
objetos são mostrados juntamente com seus relacionamentos. As setas de mensagens
são desenhadas entre os objetos para mostrar o fluxo de mensagens entre eles. As
mensagens são nomeadas, que entre outras coisas mostram a ordem em que as
mensagens são enviadas. Também podem mostrar condições, interações, valores de
resposta, e etc. O diagrama de colaboração também pode conter objetos ativos, que
executam paralelamente com outros.
Exemplo:
Diagrama de Colaboração 2: validar acesso
1:entrar com chave 3:entrar com o
de acesso semestre
formulários de registro
4:criar nova matrícula
Ator (José)
5:apresentar
em tela
Workflow de Projeto
Capacitação Engenharia de Software
Diagrama de Interação
Gerando Diagramas de Colaboração:
Na ferramenta “Rational Rose”, após criarmos o diagrama de seqüência. Selecionar:
~ Menu Browse e depois a opção F5 (Create colaboration Diagram)
:
Categori
3: selecionarCategoria
: visitante
7: selecionarProduto( )
4: getDescricao( )
1: getDescricao( )
5: getQuantidade( )
: : Catalogo
Produto
: Form
Busca
2: exibirCategoria( )
6: exibirProduto( )
Workflow de Projeto
Capacitação Engenharia de Software
Identificar as classes de
Especificação
Fazer Diagrama de
Interação
Fazer a Diagrama de
Atividades / Estados*
Refinar o Modelo
de Classes
Modelo de
Especificação
Workflow de Projeto
Capacitação Engenharia de Software
Diagrama de Estado
O que é Diagrama de Estado?
É um diagrama que tipicamente complementa a descrição das classes. Pois, este
diagrama exibe todos os estados possíveis que objetos de uma certa classe podem se
encontrar. Mostra também quais as variações de comportamento provocam tais
mudanças.
Não necessário escrever o diagrama de estado para todas as classes de um sistema,
mas, apenas para aquelas que possuem um número definido de estados conhecidos e
onde o comportamento das classes é afetado e modificado pelos diferentes estados.
Diagramas de estado capturam o ciclo de vida dos objetos, subsistemas e sistemas.
Aplicação:
Um diagrama de estado pode ser aplicado a diversos elementos da UML, tais como:
- Classes e Casos de Uso
Workflow de Projeto
Capacitação Engenharia de Software
Diagrama de Estado
Elementos:
Verificando
Estado Transição
Workflow de Projeto
Capacitação Engenharia de Software
Diagrama de Estado
Exemplo:
início
transição
fora do gancho
ocioso Ativo
no gancho
Estado
Workflow de Projeto
Capacitação Engenharia de Software
Diagrama de Estado
Exemplo 1:
on
Inicializa o
Objeto Lamp
On
Espera por
Evento on/print(”on”)
Trata
Evento
off
off
Lamp
Off
Finaliza
Objeto
stop
Workflow de Projeto
Capacitação Engenharia de Software
Diagrama de Estado
Exemplo 2: (Completo)
[Nem todos os itens verificados]/pegar
próximo item
início
[itens ecebidos
[Todos os itens [alguns itens não
verificados e estão disponíveis]
alguns itens não Item recebido
estão disponíveis] [os todos itens
disponíveis]
Aguardando cancelamento
cancelado
Cancelamento Entregue
final
Workflow de Projeto
Capacitação Engenharia de Software
Diagrama de Estado
Exemplo:
Caso de Uso
Cliente
Consultar
Verificando Status [Pedido não entregue] Mudando Status
Pedido
Gerenciar <<extends>>
Cancelando Pedido
Pedido
Cancelar
Pedido
<<include>>
UpdateStatus Logistica
Funcionário Confirmar Pedido
Pedido
Workflow de Projeto
Capacitação Engenharia de Software
Diagrama de Atividades
O que é Diagrama de Atividade?
É um diagrama que exibe o fluxo seqüencial das atividades, é geralmente utilizado para
demonstrar as atividades executadas por uma operação específica do sistema, como por
exemplo seleção de um item do menu principal.
Consistem em estados de ação, que contém a especificação de uma atividade a ser
desempenhada por uma operação do sistema. Decisões e condições, como execução
paralela, também podem ser representados no diagrama de atividade.
O diagrama também pode conter especificações de mensagens enviadas e recebidas
como partes de ações executadas.
Diagramas de atividade capturam ações e seus resultados. Eles focam o trabalho
executado na implementação de uma operação (método), e suas atividades numa
“instance” de um objeto. O diagrama de atividade é uma variação do diagrama de estado
e possui um propósito um pouco diferente do diagrama de estado, que é o de capturar
ações (trabalho e atividades que serão executados) e seus resultados em termos das
mudanças de estados dos objetos.
Workflow de Projeto
Capacitação Engenharia de Software
Diagrama de Atividades
Elementos e Exemplo com comentários:
responsabilidades
atividade
Fazer Pedido atividade
Enviar Pedido
decisão
Pagar Fatura
Barras de
sincronização Fechar Pedido
junção
Elementos
raias
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 224
Análise e Desenho Orientado a Objetos com UML
Workflow de Projeto
Capacitação Engenharia de Software
Diagrama de Atividades
Os estados no diagrama de atividade mudam para um próximo estágio quando uma ação é
executada (sem a necessidade de especificar nenhum evento).
Outra diferença entre o diagrama de atividade e o de estado é que podem ser colocadas como
swimlanes (raias). Uma swimlane agrupa atividades, com respeito a quem é responsável e onde
estas atividades residem na organização, e é representada por retângulos que englobam todos os
objetos que estão ligados a ela (swimlane).
Um
Um diagrama
diagramade deatividade
atividadeé pode
uma maneira alternativa
ser usado de se mostrar
com diferentes interações,
propósitos com a possibilidade
inclusive:
de expressar como as ações são executadas, o que elas fazem (mudanças dos estados dos objetos),
quando
Para capturar
elas sãoos trabalhos que
executadas serão executados
(seqüência das ações),quando
e ondeuma
elasoperação
acontecemé disparada (ações). Este
(swimlanes).
é o uso mais comum para o diagrama de atividade.
Para capturar o trabalho interno em um objeto.
• Para mostrar como um grupo de ações relacionadas podem ser executadas, e como elas vão afetar
os objetos em torno delas.
• Para mostrar como uma “instance” pode ser executada em termos de ações e objetos.
Para mostrar como um negócio funciona em termos de trabalhadores (atores), fluxos de trabalho,
organização, e objetos (fatores físicos e intelectuais usados no negócio).
Diagrama de Atividades não é orientado a objetos, na verdade ele é muito semelhante a um
fluxograma.
Workflow de Projeto
Capacitação Engenharia de Software
Diagrama de Atividades
Exemplo 2:
Receber Pedido
Entrega
[pedido urgente] [senão]
Receber Pagamento
Encerrar Pedido
Workflow de Projeto
Capacitação Engenharia de Software
Diagrama de Atividades
- Quando utilizar Diagrama de Atividade:
Workflow de Projeto
Capacitação Engenharia de Software
Diagrama de Atividades
Quando utilizar Diagramas de Atividades:
Workflow de Projeto
Capacitação Engenharia de Software
Esta atividade tem a seguinte divisão, a qual chamamos de refinamento, são quatro
passos. A cada passo faremos alguns refinamentos no modelo.
Também será definido alguns conceito durante estes passsos.
Workflow de Projeto
Capacitação Engenharia de Software
Workflow de Projeto
Capacitação Engenharia de Software
Workflow de Projeto
Capacitação Engenharia de Software
Pessoa
nome
Fase de Análise Fase de Projeto
modelo Diagrama de
Atributos:
conceitual Classes
Tipo de dados e
Cliente Cliente Visibilidade Pedido Cliente
Data Relacionamento
codigo -codigo: int cpf Herança
<<refine>> Status
nome -nome: String codigo
Numero
1
+getCodigo()
1..n item
+setCodigo()
+getNome() ItemPedito
+setNome()
Quantidade
métodos
Workflow de Projeto
Capacitação Engenharia de Software
Workflow de Projeto
Capacitação Engenharia de Software
Workflow de Projeto
Capacitação Engenharia de Software
cliente
PessoaFisica PessoaFisica
codigo codigo Role name
cpf
Workflow de Projeto
Capacitação Engenharia de Software
Workflow de Projeto
Capacitação Engenharia de Software
EspecialidadeMédica generalização
Tipo de Tipo de
especialização
Ortopedia Pediatria
ContaBancaria
Tipo de Tipo de
ContaCorrente ContaPoupança
Workflow de Projeto
Capacitação Engenharia de Software
Tipo de Tipo de
CartaoCredito CartaoDebito
Retangulo Circulo
Tipo de
Tipo de
Ponto
Workflow de Projeto
Capacitação Engenharia de Software
Sociio
CPF Cliente -codigo: int
-cpf Livro
-codigo: int * -idade: int
getCPF() -isbn *
setCPF() { idade > 18} -nome: String -titulo +getCodigo()
-idade: int +setCodigo()
getISBN()
+getCodigo() setISBN() +getIdade()
+setCodigo() setTitulo() +setIdade()
Emprestimo
+getNome() getTitulo()
+setNome() -data
+getIdade() -status
+setIdade() getData()
setDAta()
setStatus()
getStatus()
Workflow de Projeto
Capacitação Engenharia de Software
Workflow de Projeto
Capacitação Engenharia de Software
0..1
ItemPedido
Pedido Produto
Linha de item quantidade: int
Qualificador
Workflow de Projeto
Capacitação Engenharia de Software
papéis
Em uma associação o uso dos papéis é importante para evitar ambigüidade na
interpretação da associação. Uma associação reflexiva não indica que um objeto
se associa a si próprio (um empregado não é gerente dele mesmo; uma condição
não é pré-requisito dela mesma). Associação reflexiva indica que um objeto se
associa com outros objetos da mesma classe.
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 242
Análise e Desenho Orientado a Objetos com UML
Workflow de Projeto
Capacitação Engenharia de Software
Supervisor 1
Empregado
*
Supervisionado
Workflow de Projeto
Capacitação Engenharia de Software
Workflow de Projeto
Capacitação Engenharia de Software
{ ou }
0..1 0..1
Pessoafisica PessoaJuridica
atributos atributos
Workflow de Projeto
Capacitação Engenharia de Software
Workflow de Projeto
Capacitação Engenharia de Software
Associação de muitos:muitos
Produto * * Fornecedor
atributos atributos
atributos
Workflow de Projeto
Capacitação Engenharia de Software
<<interface>> Estereotipo e
nome da interface
Nome Interface
Métodos (assinatura)
Assinatura do
métodos
Workflow de Projeto
Capacitação Engenharia de Software
Fornecedor PrestadorServico
atributos atributos
Workflow de Projeto
Capacitação Engenharia de Software
FilmClip
play(c: Channel)
Channel
start()
stop()
pause()
dependência
Workflow de Projeto
Capacitação Engenharia de Software
Geralmente para cada atributo criamos um par de métodos getter e setter, estes
métodos garantem o encapsulamento dos dados. Entretanto, quando estamos em um
ambiente distribuído (de rede), fazer a manipulação de vários e métodos e atributos,
um a um, pode causar um péssimo desempenho, temos que considerar latência de
rede, largura de banda e etc.
Para evitar esta situação podemos criar um método chamado getCliente(), que
contempla todos os dados do cliente, desta forma estaríamos fazendo um única
requisição.
Workflow de Projeto
Capacitação Engenharia de Software
Cliente
-codigo: int
Granularidade Fina
-descricao: String
+getCodigo()
+setCodigo()
Granularidade Grossa +getDescricao()
+setDescricao()
+getCliente()
Workflow de Projeto
Capacitação Engenharia de Software
<<métodos>>
+ getCodigo(): int
+ getNome(): String
+ setCodigo(int codigo)
+ setNome(String nome)
+ getTipo(): Tipo
+ setTipo(tipo Tipo)
+ getCliente(): String
Workflow de Projeto
Capacitação Engenharia de Software
//Métodos
}
Workflow de Projeto
Capacitação Engenharia de Software
Posso ter construtores com mesmo nome, mas com a lista de argumentos diferente
(quantidade de argumentos, tipos de dados, ordem e etc)
Workflow de Projeto
Capacitação Engenharia de Software
- addOnly: No caso de atributos com multiplicidade maior do que um, valores adicionais
poderão ser incluídos, mas uma vez criado, o valor não poderá ser removido ou alterado.
- Frozen: O valor do atributo não pode poderá ser modificado depois que o objeto for
iniciado
TaxaJuro
- valor: double {frozen}
<<métodos>>
+ getValor(): double Propriedade
+ setValor(double valor)
Workflow de Projeto
Capacitação Engenharia de Software
- addOnly: No caso de atributos com multiplicidade maior do que um, valores adicionais
poderão ser incluídos, mas uma vez criado, o valor não poderá ser removido ou alterado.
- Frozen: O valor do atributo não pode poderá ser modificado depois que o objeto for
iniciado
TaxaJuro
- valor: double {frozen}
<<métodos>>
+ getValor(): double Propriedade
+ setValor(double valor)
Workflow de Projeto
Capacitação Engenharia de Software
Workflow de Projeto
Capacitação Engenharia de Software
TaxaJuro
- valor: double {frozen}
<<métodos>>
+ getValor(): double
+ setValor(double valor)
Workflow de Projeto
Capacitação Engenharia de Software
Workflow de Projeto
Capacitação Engenharia de Software
Classe
A descrição de conjunto de objetos que compartilham os mesmos atributos, operações,
relacionamento e semântica.
Temos a primeira sugestão do modelo, como classe Cliente fazendo uma associação a
Senha.
Cliente Senha
possui
codigo senha
nome
Workflow de Projeto
Capacitação Engenharia de Software
Cliente
codigo
nome Quais são as implicações
senha que o atributo “senha” pode
causar ao modelo ?
Workflow de Projeto
Capacitação Engenharia de Software
1 - Identificar todas classes que fazem uso ou que tem um determinado atributo,
neste caso, Cliente e Funcionário tem o atributo “senha”. Isto deve está explícito no
documento “Domínio do Problema”. Veja o exemplo:
Conceito diferente
Cliente Funcionario
codigo codigo-funcional
nome nome
senha senha
O mesmo conceito
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 263
Análise e Desenho Orientado a Objetos com UML
Workflow de Projeto
Capacitação Engenharia de Software
Workflow de Projeto
Capacitação Engenharia de Software
2 - Uma vez que senha é um atributo de cliente como podemos implementar regras de
negócio a senha, se implementarmos dentro da classe Cliente, teríamos um erro de
conceito (semântica). Veja o exemplo:
Cliente
codigo
nome
senha Este atributo somente é regra
qde_dias_expiracao_senha que se aplica somente a senha e
não a cliente.
Workflow de Projeto
Capacitação Engenharia de Software
Cliente
codigo
nome
senha
Workflow de Projeto
Capacitação Engenharia de Software
Mitos e Lendas
O que é dito:
- Modelo de entidade e relacionamento (MER), deve ser feito antes do diagrama de
classes.
Arquitetura de Software
Workflow Arquitetura
Capacitação Engenharia de Software
Objetivo:
Apresentar e discutir a Arquitetura de Software. Arquitetura é parte do Workflow de Projeto,
nesta fase criamos os componentes, modelos físicos e como serão distribuídos. Os
principais diagramas UML são:
- Diagrama de Deployment e
- Diagrama de Componentes.
Workflow Arquitetura
Capacitação Engenharia de Software
Receber Pedido
getDescricao( )
Entrega
exibirCategoria( )
exibirProduto( )
Encerrar Pedido
Diagrama de Componentes
Diagrama de Deployment
Workflow Arquitetura
Capacitação Engenharia de Software
Arquitetura
Workflow Artefatos Papéis
Arquitetura
Digrama de Componentes
Analista de Sistema
Projetista de Software
Diagrama de Deployment Arquiteto de Software
Modelo de Arquitetura
Workflow Arquitetura
Capacitação Engenharia de Software
Visão de Visão da
Projeto Implementação
Codificação
Funcionalidade Montagem
Vocabulário
Visão de
Caso de Uso
Visão do Visão da
Processo Implantação
Desempenho Topologia do Sistema
Escalabilidade Distribuição
Throughput Instalação
Conceitual Físico
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 272
Análise e Desenho Orientado a Objetos com UML
Workflow Arquitetura
Capacitação Engenharia de Software
Visão de Implantação
Workflow Arquitetura
Capacitação Engenharia de Software
Workflow Arquitetura
Capacitação Engenharia de Software
Workflow Arquitetura
Capacitação Engenharia de Software
Decomposição e Camadas
Decomposição:
As desvantagens:
As decomposições inadequadas ou excesso pode levar facilmente a uma grave
degradação do desempenho devido ao “overhead” de comunicação.
Workflow de Arquitetura
Capacitação Engenharia de Software
Nome do Nome do
Pacote Pacote
Nome do Pacote
Nome do
Pacote
Dependência
(import)
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 277
Análise e Desenho Orientado a Objetos com UML
Workflow de Arquitetura
Capacitação Engenharia de Software
Contas a Fluxo de
Pagar Caixa
Nome do Pacote
Subsistema
Contas a
Receber Dependência
(import)
Workflow Arquitetura
Capacitação Engenharia de Software
Separação em camadas
Camada:
Uma aplicação de grande escala pode ser complexo e difícil de desenvolver e gerenciar.
A camada é um padrão para a decomposição. A decomposição leva uma fragmentação
lógica do sistema em subsistemas e módulos, e as camadas agrupam e separam esses
subsistemas, assim limitando quem pode usar os subsistemas, componentes e módulos.
O Rational Unified Process (RUP) ou simplesmente UP identifica duas abordagens para a
camada:
- Camada baseada em responsabilidade e
- Camada baseada em reúso.
Camada baseada em responsabilidade:
Estas as camadas são bem definidas, significando que cumprem um papel específico no
esquema geral das coisas. Tais camadas também são conhecidas como níveis.
Níveis:
Os níveis podem ser mapeados para as camadas baseada em responsabilidades, neste
caso um nível torna-se sinônimo de cumprir um papel específico no sistema, como a
apresentação, a lógica de negócio, apresentação e etc.
Uma arquitetura baseada em níveis facilitam a manutenção, disponibilidade e separação
de funcionalidades e de papéis de uma aplicação
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 279
Análise e Desenho Orientado a Objetos com UML
Workflow Arquitetura
Capacitação Engenharia de Software
Separação em camadas
Níveis:
A forma de se conseguir a distribuição em arquitetura com n níveis é alinhar as camadas
específicas com cada nível, exemplo:
- O nível de cliente, lida com interação com usuário
- O nível de apresentação, lida com apresentação dos dados
- O nível de negócio, contém as regras de negócios e as entidades
- O nível de dados, fornece a interface para armazenamento de dados
Workflow Arquitetura
Capacitação Engenharia de Software
O padrão MVC originou da linguagem Smalltalk e foi usada para projetar interfaces com
usuário. Esta interface é divida em três partes: model, view e controller.
Onde:
Model: Representa o dado ou objeto. Ele é que manipula e objetos, exemplo: JavaBeans
e EJB.
View: É visão de como os dados serão apresentados, exemplo: páginas JSP e ASP
Controller: Recebe as requisições, faz validação e define o model que manipulará os
dados.
Algumas vantagens do MVC:
- Decomposição;
- Reúso;
- Possibilita o desenvolvimento em paralelo;
- Separação de responsabilidades e papéis;
- Isolamento e separação das camadas e
- Baixo acoplamento.
MVC podem ser implementado de duas maneiras o modelo 1 e modelo 2, como
veremos a seguir.
Workflow Arquitetura
Capacitação Engenharia de Software
Workflow Arquitetura
Capacitação Engenharia de Software
Controller
Web
Componentes (Model) Server
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 283
Análise e Desenho Orientado a Objetos com UML
Workflow Arquitetura
Capacitação Engenharia de Software
View:
Visão representa a apresentação (interface com usuário) de uma aplicação. O componentes
da View obtém os valores do estado do Model.
Controller:
O Controller fornece a ligação da arquitetura MVC. Ela é responsável por receber as
requisições e determinar qual o Model apropriado para atende-la. Ele também poder
tratar a resposta.
Workflow Arquitetura
Capacitação Engenharia de Software
Model:
O modelo representa as regras de negócios de uma aplicação. Encapsulando as regras
dentro de um componente facilita os testes, melhora a qualidade e promove o reúso de
componentes.
Estado do componentes (model):
O estado define um conjunto de valores do Model e inclui métodos para mudar estes
valores. Estes métodos são regras de negócios e outros métodos.
Workflow Arquitetura
Capacitação Engenharia de Software
Introdução:
O papel da Arquitetura:
Os softwares podem ter arquitetura e ambiente simples, ou seja, “rodar” um único servidor
e em diversas estações clientes em ambiente de rede local.
Atualmente, os softwares podem ter uma arquitetura mais complexa, ou seja, eles podem
ser distribuídos, ou seja, rodar em uma rede distribuída, com diversos servidores, quando
alocamos algum recurso remotamente (componentes, por exemplo), temos que garantir o
funcionamento (desempenho) deste software é missão mais difícil e até critica.
Workflow de Arquitetura
Capacitação Engenharia de Software
Princípios:
Existem diversos princípios que podemos aplicar a arquitetura de software, entretanto
existem dois que se destacam:
- Separação de Camadas e
- Princípio da Dependência Inversa.
Workflow Arquitetura
Capacitação Engenharia de Software
Arquitetura.Road Map
Modelo de Digrama de
Especificação Deployment
Documentos Fazer Diagramas
de Requisitos Digrama de
Componentes
Modelo de
Fazer Modelo de Arquitetura
Arquitetura Inicial Banco de
JSP/HTML Servlet EJB
Dados
Caso de Uso
Workflow Arquitetura
Capacitação Engenharia de Software
Refinar Modelo de
Arquitetura (RNFs)
Refinar o Modelo
de Especificação
Modelo de Arquitetura
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 289
Análise e Desenho Orientado a Objetos com UML
Workflow Arquitetura
Capacitação Engenharia de Software
Diagrama de Deployment
O que é Diagrama de Deployment?
Variações tradução:
• Diagrama de Deployment <=> Diagrama de Implantação
• Diagrama de Deployment <=> Diagrama de Distribuição
Workflow Arquitetura
Capacitação Engenharia de Software
Diagrama de Deployment
Elementos:
Servidor
processador
Dispositivo
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 291
Análise e Desenho Orientado a Objetos com UML
Workflow Arquitetura
Capacitação Engenharia de Software
Diagrama de Deployment
Elementos:
Connection (conexão): A conexão é o vinculo entre processadores e dispositivos.
Geralmente representam as conexões de rede físicas (rede local ou distribuída).
estereotipo
Servidor
Cliente <<TCP/IP>>
<<RS 232>>
Processador
Impressora (Nó)
conexão
Dispositivo
(Nó)
Workflow Arquitetura
Capacitação Engenharia de Software
Diagrama de Deployment
Elementos:
Os processadores e os dispositivos podem ser chamados de nó. Um nó é um elemento
físico que existe em tempo de execução e representa um recurso computacional.
<<WebServer>>
<<Cliente>> Apache
WebBrowser <<HTTP>>
<<RS 232>>
Impressora
Nós
<<Application Server>> <<Banco de Dados>>
JBoss Oracle
<<RMI>>
<<Client-Server>>
Cliente
Workflow Arquitetura
Capacitação Engenharia de Software
Diagrama de Deployment
O diagrama de Deployment pode ser substituído por outro diagrama que exibam com
maiores detalhes e/ou com ícones mais apropriados. Apesar de não ser uma boa
recomendação, pois, estaríamos deixando de lado a UML, mas em algumas vezes se
faça necessário.
Oracle
Application Server
JBoss
Workflow Arquitetura
Capacitação Engenharia de Software
Workflow Arquitetura
Capacitação Engenharia de Software
Dependência Componente
A
Componente
genérico
Componente Nome do
B componente
Workflow Arquitetura
Capacitação Engenharia de Software
Diagrama de Componentes
O que é um Diagrama de Componentes?
É um diagrama que exibe o sistema por um lado funcional, expondo as relações entre
seus componentes e a organização de seus módulos durante sua execução.
O diagrama de componente descreve os componentes de software e suas dependências
entre si, representando a estrutura do código gerado. Eles são tipicamente os arquivos
implementados no ambiente de desenvolvimento.
Diagrama de componente representa uma visão física, é um pedaço de software de
sistema e seus relacionamentos.
Quando um componente colabora com outro componente, está colaboração é ilustrada
com uma dependência entre o componente cliente e o componente de serviço.
ReservaService
ReservaUI
Dependência Reserva
Service_ Interface
stub
Room Component
Workflow Arquitetura
Capacitação Engenharia de Software
Interfaces:
Uma interface é coleção de operações utilizadas para especificar um serviço de uma classe
ou de um componente. O relacionamento entre componente e interface é muito importe.
As tecnologias mais populares usam interfaces na implementação de componentes, tais
como:
- Enterprise Java Beans;
- Corba (CCM) e
- Microsoft COM+.
Workflow Arquitetura
Capacitação Engenharia de Software
CatalogHome
CatalogHome
Catalog Catalog
Home EJB
Catalog.jsp Stub Home
Catalog
Business
Delegate
Catalog
CatalogRemote
CatalogRemote Bean
Catalog
Catalog
EJB
Remote
Object CatalogRemote
Stub
Workflow Arquitetura
Capacitação Engenharia de Software
Diagrama de Componentes
Tipos de Componentes:
Existem três tipos de componentes:
- Componentes de Implantação: São os componentes necessários para montar um
sistema executável, como as DLLs e os arquivos EXEs. A definição da UML para
componentes é abrangente, inclui componentes mais populares (COM+, CCM e EJB),
além de modelos alternativos como páginas web, tabelas de banco de dados e etc...
CheckIT.exe Video.dll
{versão 1.}
Disk.dll
Floppy.dll
Workflow Arquitetura
Capacitação Engenharia de Software
Diagrama de Componentes
Tipos de Componentes: (continuação)
- Componentes do Produto do Trabalho: Esses componentes são essencialmente o é
parte do processo de desenvolvimento, formados por arquivos de código fontes, arquivos
de dados, ícones. Esses componentes não fazem parte (diretamente) em sistema
executável, mas são os produtos de desenvolvimento, usados para criação do sistema
executável. Cliente.class
Conta.class Conta.jar
{versão 1}
Historico.class
Conta.java
Workflow Arquitetura
Capacitação Engenharia de Software
Workflow Arquitetura
Capacitação Engenharia de Software
Diagrama de Componentes
Tipos de Componentes:
- Componente: O ícone de componente representa um módulo (pedaço) de software
com uma interface bem definida. Na especificação de componente definimos o
estereótipo como: ActiveX, Applet, Application, DLL e EXE.
Componente
Nome do genérico
Componente
NewSubprogSpec NewSubprogBody
Workflow Arquitetura
Capacitação Engenharia de Software
Diagrama de Componentes
Tipos de Componentes:
- Programa Principal: Este ícone representam o programa principal. Um programa
principal que contém a raiz de um programa. Na linguagem Java seria o programa que
tem o método “main”. MainProgram
Programa princial
(método main)
Workflow Arquitetura
Capacitação Engenharia de Software
Diagrama de Componentes
Tipos de Componentes:
- Especificação e corpo da tarefa: Estes ícones representam os pacotes que possuem
linhas independentes de controle. Uma arquivo executável é geralmente representado
como uma especificação de tarefa com uma extensão .exe
NewTaskSpec NewTaskBody
Componente
genérico
Interface
Workflow Arquitetura
Capacitação Engenharia de Software
Boundary
Services
Entities
Workflow Arquitetura
Capacitação Engenharia de Software
Entities
As classes Entidades
Workflow Arquitetura
Capacitação Engenharia de Software
Services
ProdutoService
Workflow Arquitetura
Capacitação Engenharia de Software
CestaInterface
Boundary
As classes de Interfaces
Workflow Arquitetura
Capacitação Engenharia de Software
CestaService
ProdutoService
Cesta
Produto
Cesta Item
Workflow Arquitetura
Capacitação Engenharia de Software
Controller ReservaService
ClienteService
ApartamentoService
Workflow Arquitetura
Capacitação Engenharia de Software
Workflow Arquitetura
Capacitação Engenharia de Software
Workflow Arquitetura
Capacitação Engenharia de Software
Workflow Arquitetura
Capacitação Engenharia de Software
Workflow Arquitetura
Capacitação Engenharia de Software
Exemplo:
Workflow Arquitetura
Capacitação Engenharia de Software
Workflow Arquitetura
Capacitação Engenharia de Software
Workflow Arquitetura
Capacitação Engenharia de Software
Benefícios:
Workflow Arquitetura
Capacitação Engenharia de Software
Workflow Arquitetura
Capacitação Engenharia de Software
Funcional:
Benefícios:
•Coesão e
•Acoplamento • Não afeta por mudanças em outros componentes
• simples de entender
• conveniente para o reúso.
Workflow Arquitetura
Capacitação Engenharia de Software
Independência
Service Service Service Service
Funcional:
•Coesão e Sem acoplamento Forte acoplamento
•Acoplamento
Cliente Service Cliente Service
Com acoplamento
Cliente Service
Versão 27 tight
Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 322
Análise e Desenho Orientado a Objetos com UML
Exemplo:
Independência Moeda MaskMoeda
Funcional: - valor
•Coesão e +getValor
•Acoplamento +setValor
+maskFormat()
dependência
Workflow Arquitetura
Capacitação Engenharia de Software
Moeda MaskMoeda
- valor
+getValor
+maskMoeda()
+setValor
Independência
Funcional: dependência
Workflow Arquitetura
Capacitação Engenharia de Software
Funcional:
•Coesão e
Service Service Service Service
•Acoplamento
Solução para a classe Moeda:
Moeda MoedaMask
{abstract}
Real Dolar
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 325
Análise e Desenho Orientado a Objetos com UML
Workflow Arquitetura
Capacitação Engenharia de Software
Problema:
A classe Cliente realiza a interface iPessoa (isto quer dizes que todos os
métodos assinados na interface deve ser implementado na classe) Uma
vez que se declare uma nova assinatura de método na interface iPessoa
será necessário implementar este novo método na classe Cliente.
Independência
Funcional:
•Coesão e <<interface>>
Realização
•Acoplamento iPessoa
Cliente
Workflow Arquitetura
Capacitação Engenharia de Software
Solução:
Criação de nova classe PessoaAdapter esta classe se relacionará com a
interface iPessoa, desta forma todas as modificações ou novos
implementações serão feitas nesta classe.
Desta forma reduziremos o acoplamento entre a interface e a classe
Cliente
Independência
Funcional: <<interface>>
•Coesão e iPessoa
•Acoplamento Realização
PessoaAdapter
Cliente
Workflow Arquitetura
Capacitação Engenharia de Software
Diagrama de Componentes
Exemplo:
A partir do diagrama de classe, tentamos agrupar classes usando
técnicas de coesão e acoplamento.
Exemplo:
Acoplamento
Coesão
e Componentes
Workflow Arquitetura
Capacitação Engenharia de Software
Diagrama de Componentes
Exemplo:
Exemplo:
Acoplamento
Coesão
e Componentes
Workflow Arquitetura
Capacitação Engenharia de Software
Diagrama de Componentes
Exemplo 2:
Diagrama de Classes:
Workflow Arquitetura
Capacitação Engenharia de Software
Pedido
Cesta de Compra
Produto
FormaPagto
331
Todos os direitos reservados e protegidos © 2006 e 2007
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Análise e Desenho Orientado a Objetos com UML
Diagrama de Componentes
Exemplo 2:
Diagrama de Componentes
Produto
Pedido
Cesta de Compra
Cesta
Produto
FormaPagto
Pedido FormaPagto
Workflow Arquitetura
Capacitação Engenharia de Software
HTTP
TCP/IP
Oracle
HTML
Workflow Arquitetura
Capacitação Engenharia de Software
Funcionário
RMI
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Todos os direitos reservados e protegidos © 2006 e 2007 334
Análise e Desenho Orientado a Objetos com UML
Workflow Arquitetura
Capacitação Engenharia de Software
Browser
FormConsulta
Cliente
HTTP
ServletsController
<< Reserva>>
JSP
HotelSchema
Banco de
<< ConnDB>> Dados
JavaBeans
Workflow Arquitetura
Capacitação Engenharia de Software
Workflow Arquitetura
Capacitação Engenharia de Software
Browser
FormPagamento
Fazer Pedido
Cliente <<include>> Cliente
ServletsController
CartaoCredito
Pagamento
Envie um e-mail para com subject: “Quero entrar na comunidade” para rildo.santos@etecnologia.com.br que te
enviaremos um convite para participar da nossa comunidade
http://etecnologia.ning.com/
Todos os direitos reservados e protegidos © 2006 e 2007
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br) 338
Sobre o Análise
autor:eRildo F. Orientado
Desenho Santos a Objetos com UML
Coach e Consultor de Gestão de Negócios, Inovação e Tecnologia para a Gestão 2.0, a Gestão Ágil.
A Gestão Ágil ajuda as empresas a responder mais rápido as demandas de negócio e mudanças. A Gestão 2.0, abrange Planejamento
Estratégico, Gestão por Processos Ágeis, Gestão de Projetos Ágeis, Tecnologia da Informação (Métodos Ágeis), Inovação e Liderança.
Capacitação Engenharia de Software
Minha Experiência:
Tenho mais de 10.000 horas de experiência em Gestão de Negócios, Gestão de Inovação, Governança e Engenharia de Software. Formado
em Administração de Empresas, Pós-Graduado em Didática do Ensino Superior e Mestre em Engenharia de Software pela Universidade
Mackenzie.
Fui instrutor de Tecnologia de Orientação a Objetos, UML e Linguagem Java na Sun Microsystems e na IBM.
Conheço Métodos Ágeis (SCRUM, Lead, FDD e XP), Arquitetura de Software, SOA (Arquitetura Orientado a Serviço), RUP/UP -
Processo Unificado, Business Intelligence, Gestão de Risco de TI entre outras tecnologias.
Sou professor de curso de MBA da Fiap e fui professor de pós-graduação da Fasp e IBTA.
Possuo fortes conhecimentos de Gestão de Negócio (Inteligência de Negócio, Gestão por Processo, Inovação, Gestão de Projetos e GRC -
Governance, Risk and Compliance), SOX, Basel II e PCI;
E experiência na implementação de Governança de TI e Gerenciamento de Serviços de TI. Conhecimento dos principais frameworks e
padrões: ITIL, Cobit, ISO 27001 e ISO 15999;
Desempenhei diversos papéis como: Estrategista de Negócio, Gerente de Negócio, Gerente de Projeto, Arquiteto de Software, Projetista de
Software e Analista de Sistema em diversos segmentos: Financeiro, Telecomunicações, Seguro, Saúde, Comunicação, Segurança Pública,
Fazenda, Tecnologia, Varejo, Distribuição, Energia e Petróleo e Gás.
Possuo as certificações: CSM - Certified SCRUM Master, CSPO - Certified SCRUM Product Owner , SUN Java Certified Instrutor, ITIL
Foundation e sou Instrutor Oficial de Cobit Foundation e Cobit Games;
Onde estou:
Twitter: http://twitter.com/rildosan
Blog: http://rildosan.blogspot.com/
Todos os termos mencionados e reconhecidos como Marca Registrada e/ou comercial são de responsabilidade de
seus proprietários. O autor informa não estar associada a nenhum produto e/ou fornecedor apresentado neste
material. No decorrer deste, imagens, nomes de produtos e fabricantes podem ter sido utilizados, e desde já o
autor informa que o uso é apenas ilustrativo e/ou educativo, não visando ao lucro, favorecimento ou
desmerecimento do produto/fabricante.
Melhoria e Revisão:
Este material esta em processo constante de revisão e melhoria, se você encontrou algum problema ou erro envie
um e-mail nós.
Criticas e Sugestões:
Nós estamos abertos para receber criticas e sugestões que possam melhorar o material, por favor envie um e-
mail para nós.
Imagens:
Google, Flickr e Banco de Imagem.
Rildo F Santos
rildo.santos@etecnologia.com.br
rildo.santos@companyweb.com.br
Twitter: @rildosan
Blog: http://rildosan.blogspot.com/
Todos os direitos reservados e protegidos © 2006 e 2007
Versão 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Versão 27 |