Analise e Desenho Orientado A Objetos Com UML

Anlise e Desenho Orientado a Objetos com UML
Capacitao Engenharia de Software
Rildo F Santos
rildo.santos@etecnologia.com.br rildo.santos@companyweb.com.br
Verso 27 Verso 27 |
Rildo F Santos (rildo.santos@Companyweb.com.br)
Twitter: @rildosan Blog: http://rildosan.blogspot.com/ Todos os direitos reservados e protegidos 2006 e 2007
Contedo
Parte 1 - Principais Conceitos da Orientao a Objetos e introduo UML Parte 2 Especificao de Requisitos de Software Parte 3 Analise Conceitual Parte 4 Desenho (design) do Modelo de Especificao de Software Parte 5 Arquitetura de Software
Verso 27
Todos os direitos reservados e protegidos 2006 e 2007
Principais Conceitos da Orientao a Objetos e UML

Objetivo desta parte: apresentar e discutir os principais conceitos da Orientao a Objetos e fazer uma breve introduo a UML
Verso 27 Rildo F Santos (rildo.santos@Companyweb.com.br)
Orientao a Objetos. Principais Conceitos:

Objetivo
Objetivo: Apresentar os principais conceitos da orientao a objetos. Ser demonstrado os seguintes conceitos: Classes, Objetos, Atributos, Mtodos, Abstrao de Dados, Herana,
Polimorfismo, Encapsulamento, Associao e Interface.

Orientao a Objetos. Principais Conceitos: Introduo. Desenvolvimento de Software Orientada a Objetos

Influncia escolha da Ferramentas
Ferramentas e Artefatos
Tecnologia OO
Atividades
Suporte as atividades
WorkFlows
Metodologia/Fases
Verso 27 Jacobson pyramid rational enterprise philosophy Rildo F Santos (rildo.santos@Companyweb.com.br)

Objetos do Mundo Real
Bem, podemos encontrar vrias definies para o termo objeto, neste momento podemos entender que:
Objeto pode ser qualquer coisa na natureza que possua caractersticas e comportamentos Veja alguns exemplos de objetos:
Pessoa
Co
Partida de Futebol
Barco
Os objetos podem ser fsico (aqueles que podemos pegar, exemplos: uma pessoa, um animal, um barco, um livro, um carro, uma casa e etc) e os conceituais (aqueles que no podemos pegar, tais como: cobrana de IOF, uma ligao telefnica, uma conta corrente e etc...)

Objetos O termo orientao a objetos significa organizar o mundo real como uma coleo de objetos que incorporam estrutura de dados (propriedades ou caractersticas) e um conjunto de operaes que manipulam estes dados.
Classes Objetos Atributos Mtodos Abstrao de Dados Herana Polimorfismo Encapsulamento Interface
Objeto: Pessoa
Propriedades
Nome Data de Nascimento Massa (peso) Altura
Operaes
Andar Correr Trabalhar Chorar Danar
Objeto: Pssaro
Propriedades
Espcie Cor das penas Tamanho Peso
Operaes
Andar Correr Voar Pousar
Verso 27

Os objetos tem um identificador nico (que podemos chamar de nome do objeto), tem conjunto de propriedades (que podemos chamar de caractersticas e/ou atributos) e comportamentos (que podemos chamar de operaes).
Atributos
cor Nmero chassi Ano-fabricao
Identificador
Carro
Operaes
acelerar O que so operaes ? - Coisas que objeto deve saber fazer
Verso 27
parar

Quando atribumos valores aos objetos, ou seja, as propriedades (atributos), podemos dizer que ele tem um estado
Atributos
cor branco
Nmero chassi
VW1003G345
Ano-fabricao 1966
Identificador
Carro
Operaes
acelerar parar estado
Verso 27

Os nomes dos objetos geralmente so substantivo no singular, tais como, cliente, conta-corrente, pessoa e etc. Os atributos tambm so substantivos, exemplo: cor, tamanho, peso, idade, nmero e etc. J as operaes usualmente so verbos, como: acelerar, validar, verificar, calcular e etc
Atributos
Substantivo cor branco
Nmero chassi
VW1003G345
Ano-fabricao 1966
Identificador
Carro
Operaes
acelerar verbos
Verso 27
parar
10

Modelagem de objeto:
Identificador
Carro
Representao na Orientao a objetos
Nome (identificador)
Carro
Atributos
cor Nmero chassi branco VW1003G345
cor nmero chassi ano-fabricao
Ano-fabricao 1966
acelerar parar
Propriedades (atributos)
Operaes
acelerar
parar
Operaes
11

Modelagem de objeto:
Carro cor nmero chassi ano-fabricao acelerar parar

Representao na Orientao a objetos
Para representar os objetos do mundo real criamos classes, E a partir destas classes podemos criar os objetos. Podemos dizer que um objeto uma instance (espcie) da classe. As classes so blueprint (projeto) para os objetos. So frmas de objetos.
O que uma classe ?
Verso 27
12
Classe
Definio de Classe: Uma classe descreve um conjunto de objetos que compartilham os mesmos atributos, operaes, mtodos, relacionamentos e semntica
As classes so as partes mais importantes de qualquer sistema orientada a objetos. Usamos as classes para capturar o vocabulrio do sistema que est em desenvolvimento. Essas classes podem incluir abstraes que so parte do domnio do problema, assim como as classes que fazem uma implementao. Podemos usar ainda as classes para representar itens de software, de hardware e at itens que sejam somente conceituais. Exemplo: A classe Pessoa dever ter atributos e mtodos comuns
Pessoa nome idade getNome() getIdade() setNome() setIdade()
Nome da Classe Atributos
Nota: Dicionrio Aurlio Em programao ou modelagem orientada a objetos (v. orientao a objetos), categoria descritiva geral, que abrange o conjunto de objetos que compartilham uma ou mais caractersticas quanto a seus itens de dados e procedimentos associados. 22. Lg. Agrupamento de objetos que tm uma ou mais caractersticas em comum.
Mtodos
Verso 27
13
Classe
Exemplo de Classe:
3 Livro 1
Legenda: 1 Objeto no mundo real 2 Classe Livro 3 Objeto da classe Livro
ISBN 0747551006 Titulo: Harry Potter and the Order of the Phoenix Autor: J. K. Rowling
Verso 27
14
Classe e Objeto
Classe e Objeto. Exemplo:
ISBN 0747551006 Titulo: O Poder da inteligncia Emocional Autor: Daniel Goleman
Uma coleo de livros pode ser representada por uma classe chamada Livro.
ISBN 0747551006 Titulo: Harry Potter and the Order of the Phoenix Autor: J. K. Rowling
ISBN 8571643512 Titulo: AS JANELAS DO PARATII Autor: Amir Klink
Cada livro desta coleo instance (objeto) da classe livro.

15
Classe e Objeto
Identificador
Carro
Classe (Modelo)
Objeto (instance)
Carro
fusca:Carro
cor=branco nmero chassi=VW1003G345 ano-fabricao=1966
Atributos
cor Nmero chassi
branco VW1003G345
cor nmero chassi ano-fabricao Acelerar() parar()
Ano-fabricao 1966
Operaes
acelerar
parar
16
Classe e Objeto
Classe
Cliente nome cpf idade
Objetos
Cliente: clientemulher nome = Marina cpf = 022.200.708-12 idade = 16
Cliente: clientehomem nome = Felipe cpf = 039.217.908-22 idade = 42
Verso 27
17
Classe, Responsabilidade e Colaborao

Responsabilidades Definio de Responsabilidades: Um contrato ou obrigao em tipo ou de uma classe
Ao criar uma classe voc estar criando uma declarao de que todos os objetos dessa classe tm o mesmo tipo de estado e o mesmo tipo de comportamento. Em nvel mais abstrato, esses atributos e operaes so apenas as caractersticas com quais as responsabilidades das classes executadas. Uma classe chamada de Transao de Pagamento tem a responsabilidade pelo conhecimento das informaes inerente a operao, tais como nmero da transao, situao, valor, data, tipo de pagamento e etc. TransacaoPagamento numero valor data situao TipoPagamento Responsabilidade: -- Saber o nmero da transao, data, valor -- Conhecer o tipo de pagamento...
Responsabilidades
Verso 27
18

Colaborao: Definio de Colaborao: s vezes uma classe precisa colaborar com outra classe para cumprir suas responsabilidades
A classe Transao de Pagamento tem a responsabilidade pelo conhecimento das seguintes informaes: nmero da transao, situao, valor, data, tipo de pagamento e etc. As informaes sobre tipo de pagamentos esto outras classes que tem dados especifica para cada tipo de pagamento. Exemplo: CartaoCredito e BoletoBancario. Desta forma precisamos ter uma colaborao entre as classes para atender as responsabilidades. TransacaoPagamento numero valor data situao TipoPagamento Responsabilidade: -- Saber o nmero da transao, data, valor -- Conhecer o tipo de pagamento... CartaoCredito
Colaborao
BoletoBancario
Verso 27
19

Classes, Responsabilidades e Colaborao:
As responsabilidades so apenas texto em formato livre. Na prtica uma nica responsabilidade pode ser escrita como expresso, ou uma orao ou breve pargrafo. O CRC (Carto de Responsabilidade e Colaborao) tcnica para capturar e representar as classes suas responsabilidade e colaboraes. Outra tcnica que pode ser usada a Anlise baseada em Caso de Uso podem ser usada.
Nome da classe Responsabilidades Colaboraes
Carto
Aluno
-- Deve conhecer os dados dos aluno: Nome Nmero da Matricula Curso Matricula Pessoa Curso
Verso 27
20
Resumo: Classe e Objeto

Resumindo:
Um objeto possui: um estado (definido pelo conjunto de valores dos seus atributos em determinado instante) um comportamento (definido pelo conjunto de mtodos definido na sua interface) uma identidade nica Uma classe possui: Atributos Mtodos Responsabilidades (o que ela sabe fazer) Colaborao (interao com outras classes)
Verso 27
21
Atributo
Definindo Atributo:
uma caractersticas (propriedade) presente no objeto. Valor de todos os atributos igual Estado do Objeto.
Somente atributos que so de interesse do sistema devem ser descritos na classe.
Cliente nome cpf idade
atributos
Cliente: clientemulher nome = Marina cpf = 022.200.708-12 idade = 16

Verso 27
22
Mtodo
Escrevendo os mtodos.
Para cada atributo recomendado escrever um par de mtodos, os nomes destes mtodos devem comear com setXXXX( ) e getXXX( )
Cliente
codigo nome getCodigo() setCodigo() getNome() setNome()
Mtodos
setCodigo(): Para trocar o valor do atributo getCodigo(): Para recuperar o valor do atributo Exemplo: Valor do atributo: nome = null setNome(Duke). Agora valor do atributo nome = Duke getNome(), retornar Duke
Verso 27
23
Mtodo
Definio de Mtodo: Definio: Mtodo a implementao de uma operao. Definio de Operao: a implementao de servio que pode ser solicitado por qualquer objeto da classe com a finalidade de afetar um comportamento.
Chamando os mtodos Para chamar um mtodo de um objeto necessrio enviar uma mensagem para ele. As mensagens identificam os mtodos a serem executados no objeto receptor. Por definio todas as mensagens tem um tipo de retorno.
ContaCorrente conta saldo
Mtodos
setDeposito() getSaldo() setSaque()
Verso 27
24
Mensagem
Definio de Mensagem:
Definio:
Mensagem uma chamada de uma operao sobre um objeto, compreendendo um nome de operao e uma lista de valores de argumentos. (Rumbaugh)
Um mensagem representa a requisio de um objeto remetente a um objeto receptor para este ltimo execute alguma operao definida para sua classe. Essa mensagem deve conter informaes suficiente para que a operaes do objeto receptor possa ser executada
Verso 27
25
Resumo: Mtodos
Resumindo:
Os mtodos so a implementao das operaes de objetos. Os mtodos so responsveis pelo comportamento do objeto. A mudana de estado de um objeto deve ocorrer atravs dos mtodos. Desta forma podemos dizer que os mtodos encapsulam os atributos.
Verso 27
26
Classe Concreta e Abstrata

Temos dois tipos de classes: Concreto e Abstrato Classe concreta: So aquelas classes que podem sofrer instance (criar objetos) e tem seus mtodos implementados por completo.
E a Classe abstrata ? Bem, veremos a seguir o que uma classe abstrata...
public class Pessoa {
//Atributos private String nome; private int idade; //mtodos public String getNome(){ return nome; }
public void setNome(String nome){ this.nome = nome; }

public int getIdade(){ return idade; }
public void setIdade(int idade){ this.idade = idade; }

}
27
Orientao a Objetos. Principais Conceitos: Abstrao de Dados

Exemplo: Um a empresa de transporte possui uma frota de veculo, esta frota composta por caminhes, peruas e motos. Estes veculos tm algumas caractersticas semelhantes como cor, peso, tamanho e capacidade de carga. Entretanto cada veculo possui outras caractersticas diferentes como nmero de eixos sistema de freio, tipo de motor e etc. A abstrao de dados utilizada neste caso para identificar todas as propriedades comuns e reuni-las em novo conjunto, isto lembra alguns princpios da matemtica como fatorao. Desta forma estaramos fazendo um melhor aproveitamento de informaes que se repetem e tambm estamos fazendo que caractersticas diferente seja tratada de forma diferenciada.
O que abstrao de dados ?
Verso 27
28

Definio de Abstrao de Dados:
Definio de abstrao: Habilidade mental que permite aos seres humanos visualizarem os problemas do mundo real com vrios graus de detalhe, dependendo do contexto corrente do problema. (Jim Rumbaugh).
Qual a funo da abstrao ? A funo da abstrao capturar as propriedades e os comportamentos essenciais, como se fosse uma fatorao, desta forma determina-se o que importante e o que no . Exemplo
Veculo
Abstrao
Navio
especializao
Avio
29

Exemplo de Abstrao de Dados:
Abstrao: nos ajuda a lidar com a complexidade.
Exemplo Generalizao
MeiodeComunicao
Carta
Telefone
Jornal
Especializao As classes Contribuinte e MeiodeComunuicao neste caso so abstratas e ambas podem representam um domnio.
30

Abstrao de Dados:
Uma classe abstrata uma classe que: Prov organizao No possui instances, ou seja, no possui objetos. Possui uma ou mais operaes (mtodos) abstratas
public abstract class ContaBancaria extends Object { public ContaBancaria() { } protected int numerocontacorrente; public abstract int getNumeroContaCorrente(); public abstract void setNumeroContaCorrente(int numerocontacorrente); }
Verso 27
31

Veja agora a classe Pessoa, que abstrata, pois, possui um mtodo abstrato.
public abstract class Pessoa { //mtodos public abstract String getNome() public void setNome(String nome){ this.nome = nome; }
Um mtodo abstrato no possui implementao somente assinatura (declarao)
public abstract int calcIdade(Date public abstract int getIdade() d1, Date d2);
public void setIdade(int idade) public void setIdade(int idade) { { this.idade = idade; this.idade = idade; } } }
Um mtodo concreto possui implementao assinatura e implementao.

32
Resumo: Abstrao de Dados

Resumindo:
Uma classe abstrata deve ter pelo menos um mtodo abstrato. Mas, poder ter outros mtodos que no so abstrato, so os mtodos concreto. Uma classe abstrata no possui instance
Como eu fao para usar uma classe abstrata ?
Verso 27
33

Comparao entre Classe Abstrata e Classe Concreta Classe Abstrata Classe Concreta Os mtodos podem ser assinados e implementados Poder sofrer instance Todos os tipos de relacionamentos
Os mtodos devem ser somente assinados

No pode sofrer instance Relacionamento somente atravs de HERANA
Verso 27
34
Herana
Definio de Herana:
Definio:
Mecanismo baseado em objetos que permite que as classes compartilhem atributos e operaes baseados em um relacionamento, geralmente generalizao. (Rumbaugh)
Uma classe derivada herda a estrutura de atributos e mtodos de sua classe base, mas pode seletivamente: adicionar novos mtodos estender a estrutura de dados redefinir a implementao de mtodos j existentes Uma classe pai ou super classe proporciona a funcionalidade que comum a todas as suas classes derivadas, filhas ou sub classe, enquanto que uma classe derivada proporciona a funcionalidade adicional que especializa seu comportamento. Exemplo:
Animal
Animal Domstico Animal Selvagem
Verso 27
35
Herana
Exemplo de Herana:
Hierarquia de Classes
Super classes
Curso Universitrio
Podemos dizer que PsGraduao tipo de Curso Universitrio, assim como Curso de Especializao ou de Extenso.
Sub classe Graduao Ps-Graduao extends Especializao Extenso
Verso 27
36
Polimorfismo
Definio de Polimorfismo:
Definio: Polimorfismo uma operao que pode assumir mltiplas formas, a propriedade segundo o qual uma operao pode comportar-se diferentemente em classes diferentes (Rumbaugh) O polimorfismo o responsvel pela extensibilidade em programao orientada a objetos. Promove o reso. Exemplo:
Billhetagem calcularConta(telefone)
Telefone Mvel
Telefone Fixo
Verso 27
37
Polimorfismo
Overloading de Mtodo
Possibilidade de reso do nome do mtodo para diferentes implementaes, em tempo de execuo, a aplicao, escolher o mtodo adequado para cada chamada, veja o exemplo.
TesteSoma
Soma somar(int a, int b) somar(float a, float b) somar(char a, char b) somar(long a, long b))
Para cada tipo de dados existe um mtodo, o reso do nome do mtodo permitido, entretanto a lista de argumentos deve ser diferente, veja o exemplo acima: o mtodo somar definido vrias vezes, entretanto com a lista de argumentos diferente, desta forma evitaremos problemas como ambigidade.
Verso 27
38
Polimorfismo
Overridde de Mtodo Uma subclasse pode mudar o comportamento herdado da Superclasse, ou seja, um mtodo herdado poder ser modificado. Veja o exemplo abaixo:
Conta Bancria getSaldo()
Conta Corrente getSaldo()
Conta Poupana getSaldo()
Investimentos getSaldo()
O mtodo getSaldo herdado da Superclasse (Conta Bancria), entretanto para cada tipo de Conta ele tem uma implementao diferente. Por exemplo: - Para apurar o saldo da Conta Corrente saldo atual = (soma dos depsitos + saldo anterior) saques Para a conta poupana seria saldo atual = (soma dos depsitos + saldo anterior + juros) saques Para a conta de investimentos seria saldo atual = (soma dos aplicaes + saldo anterior + juros) - resgates - ir
Verso 27
39
Encapsulamento Principais Conceitos

Definio de Encapsulamento:
uma proteo adicional dos dados do objeto de possveis modificaes imprprias, forando o acesso a um nvel mais baixo para tratamento do dados.
Public Operaes/mtodos/interface
Private Dados/Atributos/propriedades
Exemplo: Quanto temos um arquivo protegido por senha de acesso, podemos dizer que ele est protegido, pois, apenas podemos l-lo sem fazermos alterao
40
Encapsulamento
Benefcios do Encapsulamento:
Benefcios - Segurana: Protege os atributos dos objetos de terem seus valores corrompidos por outros objetos. - Independncia: Escondendo seus atributos, um objeto protege outros objetos de complicaes de dependncia de sua estrutura interna
Pessoa
nome idade setNome() getNome() setIdade() getIdade()
setNome() setIdade()
nome idade
encapsulamento
getNome() getIdade()
Verso 27
41
Interface
Definio de Interface: O que interface ?
Interface um contrato entre o cliente (classe) e uma interface. Este contrato garantia que o mtodos assinados na interface sero implementados na classe cliente. As interfaces so consideradas a forma mais pura de abstrao de dados, pois, somente podemos assinar (declarar) os mtodos. Podemos usa-las tambm para prover: - Organizao e padronizao de assinatura de mtodos; - Simular herana mltipla e - Fazer relacionamentos de classes com responsabilidade distintas.
Verso 27
42
Interface
Exemplo de Interface: Representao:
<<interface>> Codigo getcodigo() setcodigo()
realizao
Contrato
Produto getcodigo() setcodigo() cpf Fornecedor getcodigo() setcodigo() cnpj
Verso 27
43
Orientao Orientao Principais Introduo a a Objetos. a Objetos Conceitos:
Interface
Principais Caractersticas
Caractersticas de uma interface:
No possui implementao prpria. Ela define operaes, mas no os mtodos. Uma interface especifica, usualmente, uma parte limitada do comportamento de uma classe ou componente. Uma classe pode realizar vrias interfaces. Porque utilizar interfaces: Reduz o acoplamento (dependncia) entre classes, aumentando a sua reusabilidade. Permite que componentes possam ter diferentes interfaces de acordo com as necessidades dos seus usurios. Ajuda a esconder a complexidade da arquitetura de componentes. Oferece uma forma simplificada de implementar herana mltipla.
Verso 27
44
UML. Linguagem de Modelagem Unificada
A verso da UML abordada verso 1.5

45
UML. Linguagem de Modelagem Unificada Introduo

Por que fazer a modelagem? Construmos modelos para compreender melhor o sistema que estamos desenvolvendo. Com a modelagem, alcanamos alguns objetivos: 1 - Os modelos ajudam a visualizar o sistema como ele ou como desejamos que seja; 2 - Os modelos permitem especificar a estrutura ou o comportamento de um sistema; 3 - Os modelos proporcionam um guia para a construo do sistema; 4 - Os modelos documenta o sistema.
O Que Modelagem Visual?
A Modelagem captura as partes essenciais do sistema. (Rumbaugh)

46

O Que Modelagem Visual? Modelagem visual significa modelar com a utilizao de notaes padro. Precisamos adotar uma ferramenta, uma notao e linguagem para tal empreitada. UML (Linguagem de Modelagem Unificada) a linguagem de modelagem das mais populares do momento. A UML (Linguagem de Modelagem Unificado) padro mantido pelo OMG (www.omg.org/uml).
Verso 27
47

A UML (Linguagem de Modelagem Unificada) uma linguagem-padro para elaborao da estrutura de projetos de software. A UML poder ser usada para: Visualizao Especificao Construo de modelos e diagramas Documentao.
A UML adequada para a modelagem de sistemas, cuja a abrangncia poder incluir sistemas de informao corporativos a serem distribudos a aplicao baseadas em Web e at sistemas complexos embutidos de tempo real. A UML apenas uma linguagem e, portanto, somente uma parte de um mtodo 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.
48
UML. Linguagem de Modelagem Unificada Principais Digramas:

ESTTICOS . Diagrama de Classes . Diagrama de Objetos . Diagrama de Componentes . Diagrama de Distribuio DINMICOS . Diagrama de Casos de Uso . Diagramas de Interao - Diagrama de Seqncia - Diagrama de Colaborao . Diagrama de Atividade . Diagrama de Estados
Verso 27
Modela a estrutura do sistema
Modela o comportamento do sistema
49
UML. Linguagem de Modelagem Unificada Processo de Desenvolvimento:
Processo de Desenvolvimento
Modelo Objetos de Negcio
Modelo Casos Uso de Negcio
Modelo de Classes
Necessidades dos Viso Stakeholders
Anlise Realizao Modelo de dos Casos de Uso Classes Casos de Uso
Desenho Classes
Casos de Teste Defeitos

Verso 27
Componentes Script de Testes

50
UML. Linguagem de Modelagem Unificada A Linguagem:

Linguagem = Sintaxe + semntica 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 Notao = (UML Notation Guide) define uma sintaxe grfica UML Semntica = (UML Semantics) define uma semntica UML
Verso 27
51
UML. Linguagem de Modelagem Unificada Elementos:

Elementos estruturais: classe, interface, colaborao, caso de uso, classe ativa, componente, n Elementos comportamentais: interao, mquina de estados Elementos de agrupamento: pacote, subsistema
Verso 27
52
UML. Linguagem de Modelagem Unificada Vises:
Viso de Projeto
Funcionalidade Vocabulrio
Viso da Implementao
Codificao Montagem
Viso de Caso de Uso Viso do Viso da Processo Implantao

Desempenho Escalabilidade Throughput Topologia do Sistema Distribuio Instalao
Conceitual
Fsico
53

Viso de Caso de Uso A viso do caso de uso abrange os casos de usos que descrevem o comportamento do sistema conforme visto pelos seus usurios finais, analista e pessoal de teste. Essa viso no especifica realmente a organizao do sistema de software. Porm , ela existe para especificar as foras que determinam a forma da arquitetura do Sistema. Com a UML, os aspectos estticos dessa viso so representados em diagramas de caso de uso, enquanto os aspectos dinmicos so
representados em diagrama de interao., diagrama de grfico de estados e diagrama de

atividades Viso de Projeto
A viso de projeto de um sistema abrange as classes e colaboraes que formam o vocabulrio do

problema e de sua soluo. Essa perspectiva proporciona principalmente um suporte para os requisitos funcionais do sistema, ou seja, os servios que o sistema dever fornecer a seus usurios finais. Com a UML, os aspectos estticos dessa viso so captados em diagramas de classes e de objetos; os aspectos dinmicos so captados em diagramas de interaes, de estados e de
atividades.
54

Viso de Processo
A viso do processo abrange os threads e os processos que formam os mecanismos de

concorrncia e de sincronizao do sistema. Essa viso tem com objetivo principal tratar questes de desempenho, crescimento escalar e ao throughput do sistema. Com a UML, os aspectos estticos e dinmicos dessa viso so capturados nos mesmos tipos de diagrama da viso do projeto, mas o foco voltado para as classes ativas que representam esses threads e processos.
Threads = Linhas de execuo em paralelos, tambm conhecido como processo, estas linhas podem ser
programas ou parte.
Viso de Implementao A viso de implementao de um sistema abrange os componentes e os arquivos utilizados para a montagem e fornecimento do sistema fsico. Essa viso envolve principalmente o gerenciamento da configurao das verses do sistema, compostas por componentes e
arquivos de alguma maneira independentes, que podem ser reunidos de diferentes formas para
a produo de um sistema executvel.
55

Viso de Implantao
A viso de implantao de um sistema abrange os ns que formam a topologia de hardware em que o sistema executado. Essa viso direciona principalmente a distribuio, o fornecimento e a instalao das partes que constituem o sistema fsico. Com a UML, os aspectos estticos dessa
viso so representados em diagramas de implantao; os aspectos dinmicos so capturados em

diagramas de interaes, de grfico de estados e diagramas de atividades. Cada uma dessas vises pode ser considerada isoladamente, permitindo que diferentes participantes orientem seu foco para os aspectos da arquitetura do sistema que mais lhes interessem. Essas cincos vises tambm interagem entre si, por exemplo:
Os ns na viso de implantao contm componentes da viso de implementao que, por sua vez, representa a realizao fsica de classes, interfaces, colaboraes e classes ativas provenientes das vises de projeto e de processo.
Verso 27
56
UML. Linguagem de Modelagem Unificada Exemplo: de Projeto Software Orientado a Objetos:

Use case view unidades
Casos de Uso
Formulrios Diagrama de Seqncia e/ou Diagrama de Colaborao Diagrama de Estado Diagrama de Atividades Diagrama de Pacotes Diagrama de Estado Diagrama de Atividades Diagrama de Pacotes
Logical view
Diagrama de Classes
Component view
Diagrama de Componentes
Deployment view
Diagrama de Deployment
57
UML. Linguagem de Modelagem Unificada Big Picture. Requisitos e Anlise

Business Case Coleta de Requisitos
Documento de Viso
Anlise Conceitual
Modelo Conceitual
Engenharia de Requisitos
4
Anlise de Requisitos Requisitos Funcionais
Especificao de Requisitos (Viso de Caso de Uso) Glossrio de conceitos
Casos de Uso
Requisitos No Funcionais
Arquitetura Inicial
58
UML. Linguagem de Modelagem Unificada Introduo. Artefatos: Produtos dos Workflows de Requisitos e de Anlise:
Documento de Viso Documento de Requisitos
Requisitos
Especificao de Requisitos (Casos de Uso)
Modelo Conceitual ou Modelo de Domnio
Anlise
Vocabulrio do Sistema Modelo de Arquitetura Inicial

Verso 27
59
UML. Linguagem de Modelagem Unificada Big Picture. Anlise & Projeto

Anlise
Modelo Conceitual
Projeto (Viso Lgica)

Diagrama de Classes
Receber Pedido
Preencher Pedido
Enviar Fatura
Entrega [pedido urgente] [seno] Receber Pagamento
Especificao de Requisitos (Viso de Caso de Uso)
Entrega durante a noite
Entrega Regular
: visitante
: FormBusca
: Categoria
: Produto
: Catalogo
getDescricao( ) exibirCategoria( ) selecionarCategoria
getDescricao( )
getQuantidade( )
exibirProduto( )
Encerrar Pedido
selecionarProduto( )
Verso 27
60
Projeto
Principais Produtos (Artefatos): Diagrama de Sequncia / Colaborao
Diagrama de Atividades
Diagrama de Estados Diagrama de Classes
Verso 27
61
UML. Linguagem de Modelagem Unificada Big Picture. Projeto &Arquitetura

Diagramas
Arquitetura
Projeto (Viso de Componentes e Viso de Deployment)
Receber Pedido
: visitante
: FormBusca
: Categoria
: Produto
: Catalogo
Preencher Pedido
Enviar Fatura
Entrega [pedido urgente]

getQuantidade( )
getDescricao( )
[seno] Receber Pagamento
exibirProduto( )
Entrega Regular
Encerrar Pedido
Diagrama de Componentes Diagrama de Deployment

Verso 27
62
Arquitetura
Principais Produtos (Artefatos): Diagrama de Componentes Diagrama de Distribuio(Deployment) Modelo de Arquitetura
Verso 27
63
Especificao de Requisitos de Software

Objetivo desta parte: apresentar e discutir o Ciclo de Requisitos de Software: Elicitao, Anlise, Especificao de Requisitos de Software com Caso de Uso
64
Introduo
Anlise de Requisitos: Introduo

Um entendimento completo dos requisitos de software essencial para um o sucesso do desenvolvimento do software. No importa quo bem projetado ou quo bem codificado seja, um programa mal analisado e especificado frustrar o usurio. Anlise de requisitos um processo de descoberta, refinamento, modelagem e especificao. O escopo do software, inicialmente estabelecido pelo Analista de Sistemas e refinado durante o planejamento do projeto de software, aperfeioado em detalhes. Modelos, diagramas, fluxos so criados para melhor compreenso do problema. O analista e o usurio desempenham um papel ativo na anlise e especificao de requisitos. O cliente (usurio) tenta reformular um conceito de funo e desempenho de software, s vezes nebuloso, sem detalhes concretos. O analista age como indagador, consultor e solucionador de problemas. Entretanto, a anlise e especificao de requisitos pode parecer uma tarefa relativamente simples, mas as aparncias enganam. O grau comunicao elevado. Da, surgem as oportunidades de interpretaes errneas e informaes falsas. A ambigidade provvel. O dilema com o qual se depara um analista pode ser mais bem entendido, repetindo-se a declarao de um cliente annimo: Sei que voc acredita que entendeu o que acha que eu disse, mas no estou certo que percebeu que aquilo que ouviu no o que eu pretendia dizer...
65
Ferramenta de Desenvolvimento de Software Big Picture. Requisitos

Business Case Coleta de Requisitos
Documento de Viso
Anlise Conceitual
Modelo Conceitual
4
Casos de Uso
Restries
Arquitetura Inicial
66
Workflow Requisitos
Requisitos
Workflow Artefatos
Documento de Viso
Papis
Arquitetura
Documento de Requisitos
Analista de Sistema Analista de Requisitos
Especificao de Requisitos (Casos de Uso)
Verso 27
67

Da perspectiva da engenharia de software, a elicitao 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 anlise de requisitos, so at 20 vezes mais caros de se corrigir que qualquer outro tipo de erro.
68
Requisitos
Definies de requisito (segundo IEEE)

1) Uma condio ou uma capacidade de que o usurio necessita para solucionar um problema ou alcanar um objetivo. 2) Uma condio ou uma capacidade que deve ser alcanada ou possuda por um sistema ou componente do sistema, para satisfazer um contrato, um padro, uma especificao ou outros documentos impostos formalmente. 3) Uma representao documentada de uma condio ou capacidade, conforme os itens (1) e (2).
Verso 27
69
Requisitos
Requisitos. Road Map

Fazer identificao e elicitao de requisitos
Documento de Viso
Regras de negcio
Fazer Anlise de Requisitos

Usurios e Clientes
Fazer Especificao de Requisitos
Documentos
Fazer Validao de Requisitos

Documento de Especificao de Requisitos
70
Requisitos
Identificao e elicitao de Requisitos:

Por que o elicitao importante: O sucesso no desenvolvimento de um projeto de software depende basicamente da elicitao de requisitos, pois, a base que permitir ao Analista tirar concluses sobre as situaes, problemas ou fenmenos e, assim, sugerir propostas que possam contribuir para a soluo do problema. Entretanto, esta atividade, nem sempre est presente no processo de desenvolvimento, raramente ela elaborada de forma metodolgica, geralmente tem uma abordagem intuitiva. Principais caractersticas de uma boa elicitao de requisitos: Definir as tcnicas de coleta de requisitos baseadas em fatores operacionais, tticos e financeiros; Criar um planejamento com objetivo de alcanar as metas estabelecidas, tais como: Prazos, Custos e Qualidade; Promover a integrao e o comprometimento de todos os envolvidos no processo, por exemplo: Clientes, Fornecedores, Usurios e o Patrocinador. Identificar os documentos e procedimentos que definem as polticas de negcios da empresa. Uma Simples Comparao:
Elicitao Boa Bom Diagnstico Solues eficientes Satisfao dos usurios Melhoria dos processos e reduo de custo
Verso 27
Elicitao Ruim Diagnstico ineficiente Solues medocres Insatisfao dos usurios Problemas operacionais e financeiros
71
Requisitos

Documento (Artefato) desta etapa: Documento de Viso
Participantes: Analistas e Especialista em Negcios Participantes: Usurio, Clientes, Fornecedores e Patrocinadores
reunies
documentos
identificao/ elicitao de Requisitos entrevistas Documento de viso
Objetivo: Descrever a viso inicial do software
Verso 27
72
Requisitos

As fases da Identificao/Elicitao de Requisitos:
Um projeto de elicitao de requisitos tm as seguintes fases:
Como deve ser feito ?
Planejamento
Identificar Fontes Tcnicas
O que devo coletar ?
Elicitao de Requisitos
Identificar Funcionalidades Identificar Restries e Riscos
Como devo documentar ?
Documentao
Documento de Viso
73
Requisitos

As informaes podem ser identificadas ou encontradas em diversas fontes: - Usurios; - Documentos; - Especificaes; - Clientes; - Patrocinadores; - Analista de Negcios (Domain Experts - Especialista em uma ou mais rea de negcio) Quais so as tcnicas ? Existem vrias tcnicas, todas elas possuem seus prprios conceitos, vantagens e desvantagens, que podem ser usada nesta atividade entre elas esto: - Reunies; - Entrevistas; - Questionrios; - Workshop; - Brainstorming; - JAD (Join Application Development) - Fast; - Documentos; - Sistemas Legados.
74
Anlise de Requisitos

Identificao dos Requisitos: Tipos de Requisitos
Os Requisitos de Software podem ser divididos em duas categorias:
Requisitos
Requisitos Funcionais
Os requisitos funcionais descrevem o que o sistema deve fazer, isto , as funes (funcionalidades) necessrias para atender os objetivos. O que sistema deve saber fazer. Exemplos: Buscar cliente, Registrar pedido Calcular conta de consumo, Calcular tributos e etc.
Requisitos No-Funcionais
Os requisitos no funcionais dizem respeito as caractersticas que descrevem qualidade do servio (QoS). A omisso ou esquecimento desses requisitos constitui uma das principais razes de uma eventual insatisfao dos usurios com relao a um software. Os Requisitos No Funcionais (RNF) tambm so chamamos de Requisito Suplementares. Exemplos: performance, disponibiliade, confiabilidade, segurana, usabilidade e etc.
Verso 27
75
Requisitos

Identificao dos Requisitos:
Os requisitos de software podem ser identificados no texto da declarao do problema (geralmente so verbos que identificam algumas aes).
Este documento possibilita a identificao, extrao e classificao dos requisitos - Requisitos funcionais e - Requisitos no funcionais.
Texto da Declarao do Problema
Verso 27
76
Requisitos

Documento de Viso: Objetivo: Fazer uma descrio da viso da soluo Este documento tem as seguintes sees: -Entendimento do Problema; - Lista dos Stakeholders - Lista dos Requisitos - Lista dos Riscos - Lista das Restries
Exemplo: Documento de Viso:

Data: ________ | Autor: ________ | Reviso: ____ ndice: 1.0 - Introduo 1.1 Objetivo do documento 1.2 Escopo 1.3 Abreviaturas, Siglas e etc. 2.0 Entendimento do Problema (Contexto) 2.1 Declarao do Problema 2.2 Diagrama de Contexto 3.0 Lista de Stakeholders 3.0 Usurios 3.1 Entidades 4.0 Lista dos Requisitos 4.1 Requisitos funcionais 4.2 Requisitos no funcionais 5.0 Lista dos Riscos 6.0 Lista das Restries 6.1 Software 6.2 Hardware 6.3 Ambiente e Tecnologia
Verso 27
77
Requisitos

Documento de Viso
Regras de negcio

Usurios e Clientes
Documentos

78
Requisitos
Anlise de Requisitos: Introduo

A anlise de requisitos procura sistematizar o processo de definio de requisitos. Essa sistematizao necessria porque a complexidade dos sistemas exige que se preste mais ateno ao correto entendimento do problema antes do comprometimento de uma soluo. Uma definio para requisitos apresentada a seguir.
O Documento de Viso um artefato importante na Anlise de Requisitos, destacamos algumas razes: - Da perspectiva da engenharia de software, a elicitao de requisitos talvez a mais parte mais critica do processo de desenvolvimento de software. A Anlise de Requisitos deve ser: Correta: Quando cada requisito expresso nela for encontrado no software; No Ambgua: Cada requisito deve ter somente uma interpretao (definio); Completa: Quando incluir todos os requisitos significativos relacionados as funcionalidades e requisitos relacionados a qualidade do servio (tambm conhecidos como requisitos no funcionais) Consistente: Quando no existir conflito entre os requisitos;
Verificvel: Quando for possvel verificar/validar cada requisito;

Modificvel: Quando os requisitos podem ser facilmente alterados.
79
Requisitos
Anlise de Requisitos
Atividades da Anlise de Requisitos A anlise de requisitos possibilita que o Analista de Sistemas especifique as funcionalidades, classificando e detalhando os requisitos encontrados na coleta. Os requisitos funcionais sero descritos em detalhes. E os requisitos no funcionais sero classificados.
Detalhar os Requisitos Funcionais
Classificar os Requisitos no Funcionais

Descrever os Usurios e Entidades Externas
Fazer Plano de Reduo de Risco

80
Requisitos
Anlise de Requisitos. Detalhar

Requisitos Funcionais:
Os requisitos funcionais devem ser detalhados. Devemos usar um formato padro para esta atividade. Veja o exemplo:
Lista de Requisitos funcionais
Autor: Reviso: Data Atualizao:
Nome
Cdigo
Descrio
Fazer Reserva RF01E Esta funcionalidade dever permitir o usurio (funcionrio) a fazer reserva de apartamentos, as aes que estaro disponveis so: criar, remover, alterar e consultar reservas. Cada reserva dever ter um cliente e um apartamento e respectiva perodo)
Verso 27
81
Requisitos

Descrio das Regras de Negcio
Nome do Projeto Objetivo
Servio de Atendimento e Reserva de Apartamento

Descrever todas as regras de negcio para para o servio de atendimento e reserva de apartamentos.
id
Nome da Regra
Descrio da Regra de Negcio A confirmao do registro de reserva de apartamento deve ocorrer aps o pagamento de 25% do valor da estadia. Os clientes AA (pessoas que hospedaram no hotel mais de 10 dias por ano) tem preferncia de data e tipo de apartamento. No perodo de baixa a estao (de mar a jun e ago a nov) o valor da diria tem um desconto de 40%. Para que agilizar o atendimento manter a satisfao do cliente as consultas de reserva devem ser feitas em no mximo 30 segundos.
Data Nome / Equipe RFS Verso 2.1 Status Vigente
RN01
Registrar Reserva de Apartamento
Os cdigo permitem a rastreabilidade
01/01/08
Requisitos Funcional
RN: RN01 ID RFC01 Nome: Reserva Nome Registrar Reserva de Apartamento Descrio: Servio de Atendimento e Reserva de Apartamento Descrio Esta funcionalidade dever permitir o usurio (funcionrio) a fazer reserva de apartamentos, as aes que estaro disponveis so: criar, cancelar, alterar e consultar reservas.
Verso 27
82
Requisitos
Anlise de Requisitos. Classificar

Requisitos No Funcionais:
Agora vamos descrever os Requisitos No Funcionais. Entretanto, precisamos categorizar estes requisitos, as mais frequente so:
- Performance: Tempo de resposta - Segurana: Uso de senhas, certificados digitais e etc.. - Usabilidade: Identidade Visual e Interfaces amigveis - Disponibilidade: O software deve estar disponvel para usurio 24x7. Exemplo: Tolerncia a falha - Flexibilidade: Capacidade de adaptao quando um requisito muda - Portabilidade: Capacidade de se adaptar a outros ambientes (sistemas operacionais) - Escalabilidade: Capacidade de responder aumento de carga (novos usurios) Outras categorias como Integrao, Processamento, Manutenvel e etc.
83
Requisitos
Anlise de Requisitos. Classificar e Detalhar

Bem vamos descrever os requisitos no funcionais. Como na descrio dos Requisitos funcionais, precisamos ter um padro
Lista de Requisitos No funcionais
Categoria: Performance Autor: Req. Funcional Cdigo RNFP1 Descrio Reviso: Data Atualizao:
Fazer Consulta
As consultas que sero realizadas pelo cliente no podero exceder ao tempo de resposta de 15 segundos
Por que preciso de um cdigo ? Este cdigo tem como objetivo facilitar a rastreabilidade. Ele pode ser usado no Formulrio de Caso de Uso, por exemplo, desta forma conseguiremos identificar qual o caso de uso que realiza este RNF, no caso de mudanas.
Verso 27
84
Requisitos
Anlise de Requisitos. Classificar e Detalhar

Continuao:
Lista de Requisitos No funcionais
Categoria: Usabilidade Autor: RF / Aplicao Cdigo RNFU1 Descrio Reviso: Data Atualizao:
Aplicao Aplicao
As cores, as fontes e logotipos devem seguir o Manual de Identidade Visual da empresa. As interfaces com usurio devem seguir padro de interfaces estabelecido pelo Manual de Sistema
RNFU2
Verso 27
85
Requisitos

Lista de Stakeholders:
Precisamos descrever todos as pessoas e/ou organizao que influenciam a tomada de deciso ou participam direta ou indiretamente do processo de construo do software. Mais uma vez criaremos um formato padro. Veja o exemplo:
Lista de Stakeholders
Autor: Nome Descrio Reviso: Data Atualizao:
Cliente Colaborador
So todas as pessoas fsicas ou jurdicas que fazem reservas qualquer pessoa que presta algum tipo servio para empresa
Verso 27
86
Requisitos

Lista de Stakeholders:
Continuao:
Lista de Entidades Externas
Autor: Nome Descrio Reviso: Data Atualizao:
Administradora de Carto de Crdito
Entidade que faz validao de um carto de crdito presente em transao de pagamento.
Plano de Reduo de Riscos:
Precisamos elaborar um Plano de Reduo de Risco, para os risco que j foram identificados. Este plano deve detalhar como mitigar os riscos identificados.
Verso 27
87
Requisitos
Anlise de Requisitos. Artefato

Documento de Requisitos: Objetivo: Classificar, descrever os requisitos de software, usurios e entidade externas e elaborao do plano de reduo de risco. Este documento tem as seguintes sees: - Requisitos Funcionais - Requisitos No Funcionais - Lista dos Stakeholders - Plano de Reduo de Risco Exemplo:Documento de Requisitos:
Data: ________ | Autor: ________ | Reviso: ____

ndice: 1.0 - Introduo 1.1 Objetivo do documento 1.2 Escopo 2.0 Requisitos Funcionais 3.0 Requisitos No Funcionais 4.0 Lista Stakeholders 4.1 Usurios 4.2 Entidades 5.0 Plano de Reduo de Riscos
Verso 27
88
Requisitos

Documento de Viso
Regras de negcio

Usurios e Clientes
Fazer Especificao de Requisitos (Casos de Uso)
Documentos

89
Requisitos
Especificao de Requisitos:
O produto que devemos ter aps Anlise de Requisitos a A especificao de Requisitos feita atravs de Casos de Uso, conforme definido pela UML. Um conjunto de casos de uso importante para se compreender o que o usurio quer. Um caso de uso descreve uma funcionalidade (requisito) a ser oferecida pelo sistema, ou seja, um servio. Documento de Viso
Documento de Requisitos Especificao de Requisitos Comportamento externo Comportamento interno Estrutura Implementao
Verso 27
Requisitos Funcionais
Casos de Uso Seqncia Classes Colaborao
Modelo de Arquitetura do Software
Distribuio
90
Requisitos
Especificao de Requisitos
Anlise de Casos de Uso:
Casos de uso expressam o dilogo entre os usurios e o sistema Casos de uso expressam o qu o sistema dever fazer. E no como fazer. Casos de uso formam a base para testes e documentao do sistema O modelo de casos de uso expressam todos os casos de uso do sistema e os seus relacionamentos. As tcnicas para criar e expressar casos de uso em uma aplicao Web so as mesmas para construir outros sistemas de software.
Objetivos: Identificar os atores; Identificar os casos de uso; Desenhar os casos de uso e Escrever cenrios.
Verso 27
91
Requisitos
Transformar os Requisitos Funcionais em Casos de Uso:
Calcular Total
Cliente
Fazer Cadastro Funcionrio Fazer Pedido
Emitir NF
92
Requisitos
Atividades e Passos: Fazer Diagrama de Casos de Uso Identificar Atores / Casos de Uso Escrever cenrios Escrever Formulrio Fazer Diagrama de Caso de Uso
Rational Rose
Verso 27
93
Requisitos
Casos de Uso
Introduo: Caso de Uso uma representao grfica e semntica da interao do usurio e o sistema.
Os diagramas de caso de uso so 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 organizao funcional. O que so Caso de Uso? So diagramas de que permitem visualizar, especificar e documentar o comportamento de um elemento. Esses diagramas fazem com que sistema, subsistemas e classes fiquem acessveis e compreensveis, por apresentarem uma viso externa sobre como esses elementos interagem com sistema. Definio: Caso de Uso uma descrio de um conjunto de seqncias de aes, inclusive variantes, que um sistema pode produzir um resultado de valor observvel por um ator. A representao grfica uma elipse.
Caso de Uso
Gerenciar Reserva
Os nomes de casos de uso so breves expresses verbais ativas.
Ator
Verso 27
Usurio Nome
94
Requisitos
Casos de Uso
Casos de Uso e Cenrios: Os casos de uso exibem a funcionalidade na perspectiva do usurio. Entretanto, podemos ter vrios caminhos para completar esta funo. Um cenrios como uma instance do Caso de uso, isto , um caminho lgico com incio e fim. Principais caractersticas: - Cenrios no contm declaraes condicionais; - Pode ter mesmo comeo, mas, com final diferente; - Um cenrio narrativa de uma situao e - Os cenrios devem descrever os bons caminhos e maus tambm. Exemplo: Autorizao de acesso. O usurio executa a aplicao, o sistema exibe a janela de identificao que pede a identificao do usurio, ou seja, seu nome e sua senha, O usurio informa seu nome e sua senha, o sistema valida as informaes e d a autorizao de acesso ao Sistema. Se senha for invalida ou nome neste caso teremos um novo cenrio.
Verso 27
95
Requisitos
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 no especifica como isso feito. Ao fazer uma modelagem, importante manter clara a separao de questes entre a viso interna e externa. Podemos especificar o comportamento de um caso de uso pela descrio 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 bsico e fluxo alternativo do comportamento. Tipos de fluxos: Fluxo de eventos principal e Fluxo alternativo de eventos. Tipicamente descrevemos um fluxo de eventos para um caso de uso. Os fluxos de eventos ajudam a compreenso dos requisitos do sistema, entretanto, voc desejar utilizar os diagramas de interao para especificar esses fluxos graficamente. Alm disso, voc tambm utilizar um diagrama de seqncia para especificar o fluxo principal de um caso de uso e variao deste diagrama para especificar os fluxos excepcionais.
96
Requisitos
Casos de Uso
Casos de Uso e Formulrio: Os formulrios devem ter as seguinte informaes: - Ponto de ativao (momento que caso de uso comea) - Nome do caso de uso - Objetivo - Atores que participam do caso de uso - Pr-condio - Fluxo Normal - Fluxo Alternativo - Ps-condio. Opcionalmente podemos acrescentar outros itens ao Formulrio de Caso Uso. Exemplos: - Nome ou cdigo dos Requisitos (RN e RNF) que esto associados a este caso de uso
Verso 27
97
Requisitos
Casos de Uso
Exemplos de Casos de Uso:
Manter informao de aluno
Manter informaes dos cursos
Gerente Manter informao de professor Gerar catalogo
Pedir lista dos matriculados Sistema de cobrana Matrcula nos Cursos Professor
Aluno Selecionar curso para ensinar Verso 27 Rildo F Santos (rildo.santos@Companyweb.com.br)

98
Requisitos
Casos de Uso
Casos de Uso e Formulrio Exemplo:
Nome: Fazer Busca Produto Ponto de ativao: Este caso de uso comea quando entra na pgina de Busca e seleciona um item da caixa de seleo Ator: Visitante e Cliente Objetivo: Fazer busca de produto por categoria Pr-condio: Aplicao Disponvel Fluxo Normal: 1 - O visitante seleciona a pgina de busca 2 - O visitante seleciona a categoria para busca 3 - O visitante informar o produto 4 - O visitante pressiona o boto buscar 5 - O sistema processa a busca 6 - Retorna as informaes sobre o produto Fluxo Alternativo: 1 - O Visitante seleciona a pgina de busca 2 - O visitante seleciona a categoria para busca 3 - O visitante informar o produto 4 - O visitante pressiona o boto buscar 5 - O sistema processa a busca 6 - Retorna as uma mensagem produto no encontrado Ps-condio: Busca realizada Requisito Funcional: RF002 -Fazer Busca do Produto Requisito No Funcional: --Todos os direitos reservados e protegidos 2006 e 2007
Verso 27
99
Requisitos
Casos de Uso
Elementos dos Caso de Uso: Ator: Um ator representa um conjunto coerente de papis que os usurios 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... Cenrios: narrativa de determinado fato ou de uma situao. O caso de uso deve ser descrito atravs de cenrios. Devem ser construdos tantos cenrios quantos forem necessrios para se entender completamente todo o sistema. Podem ser considerados como teste informais para validao dos requisitos do sistema. Formulrio: a representao estruturada de um ou mais cenrios
Verso 27
100
Requisitos
Casos de Uso. Relacionamentos

Organizao dos Casos de Uso: Os casos de uso tambm podem ser organizados pela especificao de relacionamento de generalizao, incluso e extenso, existentes entre eles. Esses podem ser aplicados com a finalidade de fatorar o comportamento comum (obtendo esse comportamento a partir de outros casos de uso que ele inclui) e fatorar variantes (obtendo esse comportamento em outros casos de uso que o estendem) Generalizao: Entre os casos de uso parecida generalizao existente entre as classes. No caso de uso a generalizao 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 substitudo em qualquer local qual o pai aparea. Include: Quando voc estiver se repetindo em dois ou mais caso de uso separados devemos evitar a repetio Extends: Quando estivermos descrevendo uma variao em comportamento normal, entretanto, querendo fazer uma descrio mais controlada, explicando os pontos de extenso no caso de uso. Realizes: Especifica a colaborao entre os casos de uso * Use (obsoleto): Especifica que a semntica do elemento de origem depende da semntica da parte pblica do destino. Substitudo pelo include.
101
Requisitos

Generalizao: Podemos usar a generalizao entre casos de uso, pelo mesmo motivo que utilizamos nas classes, para compartilhar comportamento: A generalizao tambm pode ser aplicado aos atores e seus respectivos papis. Veja o exemplo:
Receber Pagamento generalizao
Funcionrio
Pagto Carto de Crdito
Pagto Carto de Dbito
Recepcionista
Gerente de Reservas
102
Verso 27
Requisitos

Extends: Podemos usa-lo para Demonstrar Variao de Comportamento: Cada uma das extenses descreve as diferentes maneiras com que um passo do caso de uso pode ser executado. Variao de Comportamento. Exemplo:
Locadora de Automveis
Devolver Veculo
Sala de Conferncia
Fazer Ligao
Usurio
<<include>> <<include>> <<extend>> <<extend>>
Alterar status do carro
Consulta Cliente
Calcular Multa
Fazer Ligao (Conference call)
Verso 27
103
Requisitos

Explicando o estereotipo include Um relacionamento de incluso entre casos de uso significa que o caso de uso base incorpora explicitamente o comportamento de outro caso de uso em uma localizao especificada na base. O caso de uso includo nunca permanece isolado, mas apenas uma instance como parte de alguma base maior que o inclui. Voc pode pensar na incluso como o caso de uso base que o obtm o comportamento a partir do fornecedor do caso de uso. Voc utiliza um relacionamento de incluso para evitar descrever o mesmo fluxo de eventos vrias vezes, incluindo o comportamento comum em um caso de uso prprio. O relacionamento de incluso essencialmente um exemplo de delegao, voc coleta um conjunto de responsabilidades do sistema e o captura um nico local (o caso de uso includo); depois, permite que outras partes do sistema (outros casos de uso) incluam a nova agregao de responsabilidade sempre que precisamos utilizar essa funcionalidade. Exemplos:
Fazer Pedido <<include>> Validar Usurio Acompanhar Pedido <<include>> <<include>> Gerenciar Reserva Receber Pagamento Fazer Check IN Fazer Check OUT
<<include>>
Verso 27
104
Requisitos
Casos de Uso
Casos de Uso - Identificao de Atores
Os atores no fazem parte do sistema - eles representam qualquer um e qualquer coisa que faa interao com sistema. Podendo ser uma pessoa, software, hardware e etc. Uma ator pode: - Apenas fornecer informaes ao sistema - Apenas receber informaes do sistema - Fornecer e receber informaes ao sistema Tipicamente os atores so identificados nas Declaraes de Problemas (Documento de Viso) ou atravs de entrevistas com os usurios e outros envolvidos no processo, como, Gerente, Especialista em Negcio, Analista de Sistema e Analista de Negcio, por exemplo. As seguintes questes podem ser usadas para identificar o atores: - Onde o sistema ser usado ? - Quais reas sero usurias do sistema ? - O sistema usar recurso externo ? - Quem ser o responsvel pelo sistema ? - Quem sero os usurios do sistema ?
105
Requisitos
Casos de Uso.Dicas
Um engano comum na identificao de casos de uso representar como Caso de uso passos individuais, operaes ou transaes. Exemplo: No domnio de ponto de venda, algum pode definir um caso de uso chamado Imprimindo o Recibo, quando de fato, a operao de impresso meramente um passo no processo muito mais abrangente do caso de uso Comprar Itens Lembre-se: Um caso de uso uma descrio completa de processo, que inclui outros passos ou transaes.
Verso 27
106
Requisitos
Especificao de Requisitos. Exemplo:

O hotel contm um nmero de apartamentos disponveis para ser alugado aos hospedes. Cada apartamento tem as seguintes propriedades: - Nmero, preos base, capacidade de pessoas - Tipo (Single, double, triplo ou suite) O preo de cada apartamento est relacionado com seu tipo e sazonalidades (perodos especiais, tais como: frias, natal, carnaval...) Um hospede pode fazer reserva de mais de um apartamentos atravs do telefone, Internet ou pessoalmente no balco de reserva do Hotel .
Requisitos Funcionais Gerenciar Reserva ...
Refinado pelo
Documento de Viso
107
Requisitos

3
Formulrio
Cenrios
Usurio Ator Associao
Gerenciar Reserva Caso de Uso
Caso de Uso: Gerenciar Reserva

108
Requisitos

Escrevendo os Cenrios:
Cenrio 1: Gerenciamento de Reserva: O Setor de Reserva do Hotel recebe um telefonema de cliente que solicita uma reserva de apartamentos para data. O cliente informa o perodo, ou seja, data de chegado e partida, e qual tipo de apartamento ele precisa. O funcionrio do Setor de Reserva, verifica a disponibilidade do apartamento e confirma a reserva.
Cenrios
Cenrio 2: Gerenciamento de Reserva: O Setor de Reserva do Hotel recebe um telefonema de cliente que solicita uma reserva de apartamentos para data. O cliente informa o perodo, ou seja, data de chegado e partida, e qual tipo de apartamento ele precisa. O funcionrio do Setor de Reserva, verifica a disponibilidade do apartamento e informa que no tem disponibilidade de apartamento para o perodo informado pelo cliente e oferece um outro tipo de apartamento. O cliente aceita o apartamento e ento o funcionrio confirma a reserva. Cenrio 2: Gerenciamento de Reserva: O Setor de Reserva do Hotel recebe um telefonema de cliente que solicita uma reserva de apartamentos para data. O cliente informa o perodo, ou seja, data de chegado e partida, e qual tipo de apartamento ele precisa. O funcionrio do Setor de Reserva, verifica a disponibilidade do apartamento e informa que no tem disponibilidade de apartamento para o perodo informado pelo cliente e oferece um outro tipo de apartamento. O cliente no aceita a proposta do funcionrio e a reserva no confirmada.
109
Requisitos

Escrevendo o Formulrio: Compilar os Cenrios em Formulrio:
Cenrios
Formulrio
Identificando a pr-condio e ps-condio: Cenrio

Gerenciamento de Reserva: O Setor de Reserva do Hotel recebe um telefonema de cliente que solicita uma reserva de apartamentos para data. O cliente informa o perodo, ou seja, data de chegado e partida, e qual tipo de apartamento ele precisa. O funcionrio do Setor de Reserva, verifica a disponibilidade do apartamento e confirma a reserva. Ps- condio
Pr- condio
110
Requisitos

Escrevendo o Formulrio: Compilar os Cenrios em Formulrio:
Primeiras linhas do cenrio
Gerenciar Reserva caminho feliz
Nome: Gerenciar Reserva Ponto de ativao: Este caso de uso comea quando o funcionrio do setor de reserva recebe uma solicitao de reserva Ator: Funcionrio Objetivo: Fazer reservar de apartamentos Pr-condio: Solicitao de reserva Fluxo Normal:
Gerenciar Reserva caminho alternativo
Fluxo Alternativo:
Ps-condio: Reserva confirmada
ltima linha do cenrio

111
Requisitos

Escrevendo o Formulrio de Descrio de Caso de Uso:
Nome: Gerenciar Reserva Ponto de ativao: Este caso de uso comea quando o funcionrio do setor de reserva recebe uma solicitao de reserva Ator: Funcionrio Objetivo: Fazer reservar de apartamentos Pr-condio: Solicitao de reserva Fluxo Normal: O cliente informa o tipo de apartamento O cliente o perodo (data de chegada e partida) O funcionrio do Hotel verifica a disponibilidade do apartamento O funcionrio confirma a reserva Fluxo Alternativo: ... O funcionrio do Hotel verifica a disponibilidade do apartamento O funcionrio faz proposta de outro apartamento para cliente O cliente aceita e ento o funcionrio confirma a reserva Ps-condio: Reserva confirmada
112
Requisitos

3
Formulrio
Cenrios
Funcionrio Ator Associao
Gerenciar Reserva Caso de Uso
Caso de Uso: Gerenciar Reserva

113
Requisitos
Mitos e Lendas
Requisitos no so Casos de Uso;
Um Caso de Uso pode relacionar mais de um requisito, veja o exemplo: Caso de Uso Fazer Busca, est associado a dois requisitos: (RF) Fazer Buscar (RNF) O tempo de resposta para transao deve ser 10 segundos (Desempenho)
Verso 27
114
Requisitos
Especificao de Requisitos. Exerccio:

Especificao de Requisitos, como fazer:
1 - Identifique quais os REQUISITOS e relacione com os CASOS DE USO; 2 - Identifique tambm os ATORES e seus respectivos PAPIS; 3 - D um nome para o CASO DE USO, lembre-se que este nome deve ser nico no modelo; 4 - Escreva os CENRIOS para o CASO DE USO; 5 - Compile os CENRIOS em nico FORMULRIO e 6 - Faa o Diagrama de Caso de Uso.
Verso 27
115
Requisitos
Especificao de Requisitos. Template:

Template do Formulrio:
Data: ______ | Autor: ________ | Reviso: ____
Nome: <nome do caso de uso> Ponto de ativao: <informar o ponto de ativao> Ator: <informar os atores> Objetivo: <descrever o objetivo> Pr-condio: <descrever a pr-condio> Fluxo Normal: <descrever o fluxo normal> Fluxo Alternativo: <descrever o fluxo alternativo> Ps-condio: <descrever a ps-condio> RF: <informar os cdigo ou nomes dos RFs> RNF: <informar os cdigo ou nomes dos RNFs>
Rastreabilidade
116
Requisitos

Documento de Viso
Regras de negcio

Usurios e Clientes
Documentos

117
Requisitos
Validao de Requisitos
Deve preocupa-se em mostrar que os requisitos definem o sistema que o cliente/usurio deseja. Validao importante uma vez que o custo para remover um erro de requisitos grande.
Pequeno Check List de Requisitos: Validade. O sistema fornece as funes que melhor atende as necessidades do usurio? Consistncia. Existem conflitos de requisitos? Completeza. Todas as funes necessrias para o cliente esto includas? Realismo. Os requisitos podem ser implementados com a tecnologia e oramento disponveis?
Facilidade de verificao. Os requisitos podem ser checados?

118
Requisitos
Tcnicas de validao de requisitos Reviso de requisitos: - Anlise manual sistemtica dos requisitos Prototipao: - Uso de um modelo executvel do sistema para checar os requisitos. Gerao de casos de teste: - Desenvolver testes para os requisitos a fim de verificar a testabilidade. Anlise automatizada da consistncia: - Uso de ferramenta para verificar a consistncia do modelo.
Verso 27
119
Requisitos
Tcnicas de validao de requisitos Reviso de requisitos: - Revises regulares devem ocorrer durante a formulao da definio dos requisitos - Tanto o cliente quanto a equipe contratada devem estar envolvidos nas revises - As revises podem ser formais (com documentos completos) ou informais. Uma boa comunicao entre os desenvolvedores, clientes e usurios pode resolver problemas em estgios iniciais Verificao de revises: - Verificabilidade. O requisito realisticamente testvel? - Compreensibilidade. O requisito propriamente entendido? - Rastreabilidade. A origem do requisito claramente estabelecida? - Adaptabilidade. O requisito pode ser modificado sem grande impacto sobre outros requisitos?
Verso 27
120
Requisitos
Formato do documento de especificao de requisitos sugerido pela IEEE/ANSI 830-1993: Estrutura do Documento: 1.0 Introduo 1.1 propsito do documento de requisitos 1.2 escopo do produto 1.3 definies, acrnimos e abreviaes 1.4 referncias 1.5 viso geral do restante do documento 2.0 Descrio geral 2.1 perspectiva do produto 2.2 funes do produto 2.3 caractersticas do usurio 2.4 restries gerais 2.5 suposies e dependncias 3. Requisitos (Especficos) os requisitos podem documentar interfaces externas, descrever funcionalidade e desempenho do sistema, especificar requisitos lgicos de banco de dados,restries de projeto, caractersticas de qualidade. 4. Apndices 5. ndice
Verso 27
121
Anlise Conceitual
Objetivo desta parte: apresentar e discutir a Anlise Conceitual suas tcnicas, conceitos e modelos.
Verso 27
122
Big Picture. Business Case
Requisitos e Anlise
Coleta de Requisitos
Documento de Viso
Anlise Conceitual
Modelo Conceitual
4
Casos de Uso
Arquitetura Inicial
123
Workflow Analise
Analise
Workflow Artefatos Modelo Conceitual ou Modelo de Domnio Papis
Arquitetura
Vocabulrio do Sistema
Analista de Sistema Analista de Requisitos Arquiteto de Software
Modelo de Arquitetura Inicial
Verso 27
124
Workflow de Anlise Introduo:

Modelo de Casos de Uso de software elaborado para dar a Viso de Caso de Uso. Esta viso fornece uma perspectiva do software a partir de um ponto de vista externo. Os aspectos dinmicos descrevem a troca de mensagens entre os objetos e a sua reao a eventos que ocorrem no software. O aspecto dinmico ser apresentado na terceira parte, no workflow de Projetos.
Viso de Projeto Viso da Implementao
Codificao Montagem
Funcionrio
Gerenciar Reserva
Viso do Desempenho Processo Escalabilidade Throughput
Viso de Caso de Uso Viso da Implantao Topologia do Sistema Distribuio Instalao
O aspecto estrutural esttico permite entender como uma software est estruturado internamente para atender os requisitos (viso externa). Esse aspecto chamado de esttico porque no apresenta informaes sobre como os objetos se comportam no ciclo de vida de software e tambm porque representa a estrutura das classes de objetos e os relacionamentos entre elas.
Verso 27
125
Workflow de Anlise
Objetivo:
Apresentar e discutir como elaborar o Modelo Conceitual (tambm chamado de modelo de domnio) e o Vocabulrio de Conceitos. Para isto apresentaremos um algumas tcnicas para identificao dos candidatos a classes. Os objetivos desta etapa so: 1 - Apresentar tcnicas para identificao dos candidatos a classes, atributos e associaes; 2 - Elaborar o Modelo Conceitual ou modelo de domnio e 3 - Elaborar o Vocabulrio de Conceitos.
Verso 27
126
Workflow de Anlise Atividades.Road Map
Fazer Anlise Conceitual

Caso de Uso Modelo Conceitual
Fazer Vocabulrio
Documento de Viso Vocabulrio
Definir o modelo de Arquitetura

Modelo de Arquitetura
Verso 27
127
Workflow de Anlise Atividades e Artefatos:

Para este workflow as principais atividades e artefatos so:
Workflow de Requisitos: Atividade: Coletar Requisitos Fazer Anlise de Requisitos. Fazer Especificao de Requisitos; Artefatos: Documento de Viso Documento de Requisitos Caso de Uso Workflow de Anlise Atividade: Fazer Anlise Conceitual Fazer Vocabulrio de Conceitos Artefatos: Modelo Conceitual e Vocabulrio do Sistema.
Verso 27
128
Workflow de Anlise Anlise Conceitual. Introduo:

Modelo Conceitual. o artefato mais importante da Anlise Orientada a Objetos O modelo representa conceitos relevantes (do ponto de vista do modelador) do domnio do negcio. Este conceitos tambm so chamados de Chaves da Abstrao. A chave da abstrao uma classe ou objeto que fazem parte do vocabulrio do domnio do problema (Booch). Na UML, esta fase ilustrada com os diagramas de estruturas estticas: - Caso de Uso - Digrama de Classes (na verdade o Modelo Conceitual). Os objetivos so: 1 - Apresentar tcnicas para identificao dos candidatos a classe classes, atributos e associaes e 2 - Elaborar o Modelo Conceitual ou Modelo de Domnio.
Verso 27
129
Workflow de Anlise
Atividade: Fazer Anlise Conceitual

Documento de Viso
Verso 27
130
Workflow de Anlise Anlise Conceitual. Modelos:

O modelo de classe tm pelo trs nveis de abstrao: - Modelo Conceitual de Classes: Representa as classes no domnio do desenvolvimento do software, este modelo pertence a Workflow de Anlise. Por definio, um modelo de classes de domnio no leva em considerao restries referente tecnologia a ser utilizada na soluo do problema. Este modelo tambm conhecido como Modelo de Classes de Domnio. - Modelo de Classes de Especificao: derivado do Modelo Conceitual. Com acrscimos de detalhes, tais como, tipo de dado, operaes (mtodos), implementao de associaes, generalizao, agregao e composio e incremento de novas classes para que se fazem necessria para dar uma soluo ao problema. Exemplo: Classes associativas. Este modelo desenvolvido no Workflow de Projeto.
Verso 27
131
Workflow de Anlise Anlise Conceitual. Modelos

- Modelo de Classes de Implementao: derivado do modelo de especificao e corresponde a implementao das classes em alguma linguagem de programao, como Java, C#, C++ por exemplo. O modelo de implementao construdo na Fase Construo.
Workflow de Anlise
Workflow de Projeto
Pessoa
Pessoa
nome idade <<refines>>
-nome -idade +setNome() +getNome() +getIdade() +getIdade()
Modelo Conceitual ou Modelo de Domnio

Verso 27
Modelo de Especificao
132
Workflow de Anlise Anlise Conceitual. Atividades e Passos:

Identificar os candidatos a classe Selecionar uma tcnica Fazer a Lista de Candidatos
Desenhar o Modelo Conceitual

4
Definir a Arquitetura Inicial

133
Workflow de Anlise Anlise Conceitual. Identificao das Classes:

Um software orientado a objetos composto de uma coleo de objetos que colaboram para realizar seus requisitos. Entretanto, sabemos que os objetos so instances das classes. Para identificar as classes, podemos usar um mtodo simples. O primeiro passo fazer uma lista de todas classes que encontramos, esta lista pode ser chamada de Lista de Classes Candidatas. E depois usando algum critrio, eliminamos as classes irrelevantes e a teremos uma lista definitiva. Existem dois mtodos principais para realizar a identificao das classes de domnio de um software: - Mtodo dirigido a dados: Neste mtodo, a nfase est na identificao da estrutura dos conceitos relevantes para o domnio do negcio, resultando em Modelo Conceitual. - Mtodo dirigido a responsabilidades: Neste mtodo, a nfase est na identificao de classes a partir de seus comportamentos relevante ao sistema. Este mtodo tambm resulta em Modelo Conceitual.
Verso 27
134
Workflow de Anlise
UML. Introduo
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 ns, elementos e adornos usados para construir o modelo.
Verso 27
135
Workflow de Anlise
Diagrama de Classes. Introduo

O Diagrama de Classes nasce no Workflow de Anlise com Modelo Conceitual (modelo de domnio), mais tarde no Workflow de Projeto este o modelo ser refinado ganhando adornos, novos tipos de relacionamentos, operaes (mtodos) e at novas classes. Agora faremos apenas o Modelo Conceitual que podemos considerar como o primeiro esboo do que mais tarde se tornar o Diagrama de Classes.
Verso 27
136
Workflow de Anlise UML. Elementos:

Elementos estruturais: Classe, Interface, Colaborao, Caso de Uso, Classe Ativa, N e Componente Elementos de agrupamento: Pacote e Subsistema
Verso 27
137
Workflow de Anlise UML. Elementos:

Dependncia Associao
Associao Composio Agregao
Generalizao Esteretipo Tagged value Restrio (Constraint)
Mecanismos de Extensibilidade:
Verso 27
138
Workflow de Anlise Diagrama de Classes
O diagrama de classes deve capturar o Vocabulrio* do sistema
Verso 27
139
Workflow de Anlise Associao

Definio de Associao: Um relacionamento estrutural que descreve um conjunto de vnculos, em que o vnculo uma conexo entre objetos; relacionamento semntico entre dois ou mais classificadores que envolve as conexes entre seus objetos.
Associao classe classe
Usuario
Senha
Verso 27
140

Nome de Associao: Uma associao pode ter um nome, que pode usado para descrever a natureza do relacionamento. Podemos ainda acrescentar um tringulo para demonstrar a direo do nome, ou seja, a direo que nome deve ser lido.
Nome da associao Direo do nome
Cliente
faz
Pedido
Observao: Apesar da possibilidade de a associao ter um nome, no necessrio inclu-lo. Recomendamos o uso do nome quando o modelo possui muitas associaes e voc tem a necessidade de fazer referncia s associaes ou de destaca-las.
141

Navegao: Indica qual a direo da associao. A direo da associao pode ser unidirecional (onde somente uma das pontas da linha de associao tenha a seta) ou bidireciona (no existem setas em nenhum dos lados)
Associao Navegao
Cliente
Pedido
Verso 27
142
Workflow de Anlise Role Name:

Definio de Role Name: um identificador (nome) do papel da associao, podendo cada ponta ter um nome especifico.
Modificadores: (+) public | (-) private | (#) protected
Verso 27
143
Workflow de Anlise Multiplicidade

Definio: A especificao de uma faixa de nmeros cardinais, que um conjunto pode assumir.
Eqivale a muitos
Multiplicidade Faixa Vlida: 0....1 | 0..* | * | 1 | 1..*
O que uma multiplicidade ? Uma associao representa um relacionamento entre dois objetos. Em algumas situaes de modelagem, importante especificar a quantidade de objetos que podem ser conectados pela instance de uma associao. Essa quantidade chamada de multiplicidade do papel de uma associao e escrita como uma expresso equivalente a um intervalo de valores ou de uma valor explcito.
144
Workflow de Anlise Role Name e Multiplicidade

Exemplo:
Multiplicidade
Para cada objeto (instance) da classe Pessoa a classe Empresa poder ter uma ou muitos objetos.
Verso 27
145
Workflow de Anlise
Anlise Conceitual. Tcnicas:
Abbot
Kent Beck
UML
Inspeo Gramatical
CRC
Scott Ambler
Graig Larman Peter Coad
Anlise de Caso de Uso
Outras Tcnicas
146
Workflow de Anlise Modelo Conceitual. Tcnica: Inspeo Gramatical

Introduo: A primeira etapa na construo do Modelo Conceitual identificar os conceitos (idias ou coisas). Podemos achar os candidatos a classe com a identificao de substantivos (Inspeo Gramatical). uma tcnica til, por causa da simplicidade, proposta por Abbot. Consiste em identificar os substantivos no texto da Declarao de Problema e consider-los como candidatos a a classe ou conceitos.
Verso 27
147

Lista de Candidatos:
Conhecimento do Negcio
Declarao de Viso 1 Lista
Interaes Lista Final
Identificao dos candidatos a classe, associaes e atributos

Verso 27
Fazer reviso da lista: Eliminar conceitos os repetidos, ambguo, irrelevantes e etc..

148

Artefatos:
Modelo Conceitual Lista de Candidatos
Vocabulrio de Conceitos
Verso 27
149
Nome da associao
Classe
1..*
Reserva
feita por
Cliente
numero data-entrada data-saida

Atributo
0..*
id
hospede nome
documento
Multiplicidade
Apartamento
1..*
numero tipo situacao
Associao
Verso 27
150
Workflow de Anlise Modelo Conceitual. Tcnica: Inspeo Gramatical - Exemplo

Declarao do Problema: O cliente solicitou o desenvolvimento de software para apoiar uma rede bancria computadorizada incluindo caixas humanos e mquinas de auto atendimento (ATM) a ser compartilhada por um consrcio de bancos. Cada banco prov seu prprio computador para manter suas contas e processar transaes sobre elas. Os caixa automticos so propriedade dos bancos e se comunicam diretamente com os computadores de seus bancos proprietrios. Os caixas humanos introduzem dados sobre as contas e transaes. Os caixas eletrnicos comunicam-se com um computador central que liquida as transaes com os bancos adequados. Um caixa automtico receber carto magnticos, interage com o usurio, comunica-se com o sistema central para executar transaes, entrega de dinheiro e impresso de extratos. O sistema exige um adequado arquivamento de registros e reservas de segurana. O sistema deve manipular corretamente acessos concorrente mesma conta. Os bancos devem prover seu prprio software para seus prprios computadores; devemos projetar o software para as ATM e para a rede. O custo do sistema compartilhado deve ser distribudo pelos bancos de acordo com nmero transaes realizadas.
Verso 27
151

Identificando do Domnio: (Tcnica usada: extrao dos substantivos do enunciado do problema)
Fazer transaes eletrnica atravs de caixa de Auto atendimento e caixas
Verso 27
152

Identificando os conceitos: (Tcnica usada: extrao dos substantivos do enunciado do problema)
Software ATM Computador do Banco Terminal do caixa Computador Central Dinheiro Manuteno do arquivo de Registro Preo Rede Bancria Consrcio Conta Dados de contas Carto Magntico Extrato Reserva de segurana Caixa Banco Transao Dados de transaes Usurio Sistema Acesso
Cliente
Classes da ATM originadas do conhecimento do domnio do problema

Linha de Comunicao
Verso 27
Registro de transao
153

Identificando os conceitos: (Tcnica usada: extrao dos substantivos do enunciado do problema)
Aps a reviso identificamos o seguinte: Conceitos vagos: Sistema, Reserva de Segurana, Manuteno do arquivo de Registro e Rede Bancria Atributos: Dados de contas, extrato, dinheiro e dados de transaes Conceito redundante: Usurio Conceito Irrelevante: Preo Conceito de implementao: Registro de Transao, Acesso, Software e Linha de Comunicao
Eliminado s classes apontadas, ficamos com as seguintes conceitos vlidos: Conta, ATM, Banco, Computador do Banco, Carto Magntico, Caixa Terminal do Caixa, Computador Central, Consrcio, Cliente e Transao
154

Identificando as Associaes:
Qualquer dependncia entre duas ou mais conceitos uma associao. Uma referncia de uma classe a outra uma associao. As associaes muitas vezes correspondem a verbos estticos ou a locues verbais. Isso inclui localizao fsica: - junto a, parte de, contido em e etc Aes indiretas: - direciona, comunica-se (fala a), propriedade (tem, parte de), ou satisfao de alguma condio (trabalha para, casado com, gerencia). Tente identificar as associaes, lembre-se que nem todas, esto explicitas, pode haver muitas transaes implcitas e algumas associao dependem do conhecimento do mundo real, ou seja, do negcio. Extraia todas as candidatas do enunciado do problema e as escreva em uma lista, e depois refine-as.
Verso 27
155

Identificando as Associaes: Lista (Frases verbais): Rede de bancria inclui caixas e ATM Consrcio compartilha ATM Banco prov computador do banco Computador do banco mantm contas Computador do banco processa transaes contra a conta Banco possui terminal de caixa Terminal de caixa comunica-se com o computador do banco Caixa introduz transao para a conta ATM comunica-se com computador central sobre transao Computador central liquida transao com banco ATM aceita carto magntico ATM interage com usurio
Verso 27
156

Identificando as Associaes: Lista (Frases verbais): ATM entrega o dinheiro ATM imprime extrato Sistema manipula acesso concorrente Bancos fornecem software Custo repartido pelos bancos Frases Verbais implcitas: Consrcio compem-se de bancos Banco mantm conta Consrcio possui computador central Sistema prov arquivamento de registros Sistema prov segurana Clientes possuem cartes magnticos Conhecimento do domnio do problema: Carto magntico permite acesso a contas Banco emprega caixas
157

Identificao dos conceitos dos atributos:
Os atributos so propriedades de objetos individuais, como nome, peso, altura, velocidade, cor e etc. Os atributos no devem ser objetos; utilize uma associao para demonstrar qualquer relacionamento entre dois objetos. Os atributos geralmente correspondem a substantivos seguidos por frases possessivas, por exemplo: a cor do carro ou o nmero da conta. Os adjetivos muitas vezes representam valores de atributos especficos e enumerados, como vermelho sobre ou expirado. Diretamente das classes e associaes, os atributos tm menos probabilidade de serem integralmente descritos no enunciado do problema. Devemos valer-se de nosso conhecimento do domnio da aplicao e do mundo real para encontr-los. Lembre-se que os atributos raramente afetam a estrutura bsica do problema.
Verso 27
158

Identificao dos conceitos dos atributos:
Os atributos derivados devem ser omitidos ou claramente rotulados, como: idade derivado de data de nascimento e data atual (que uma propriedade do ambiente). Os atributos derivados como os objetos e associao derivadas podem ser teis na abstrao de propriedade significativas de uma aplicao, mas devem ser distinguidos nitidamente dos atributos bsicos, que definem o estado do objeto. Os atributos derivados no devem ser expressos como operaes, como obter-idade, embora possam eventualmente ser implementados como tais. Os atributos de ligao tambm devem ser identificados. Um atributo de ligao uma propriedade da ligao entre dois objetos e no a propriedade de um objeto isoladamente. Por exemplo: a associao muitos-para-muitos entre Acionistas e Empresa tem o atributo de ligao nmero de aes. Os atributos de ligao s vezes so tomadas erradamente por atributos de objetos.
Verso 27
159

Identificao dos conceitos dos atributos: Os atributos derivados devem ser omitidos ou claramente rotulados, como: idade derivado de data de nascimento e data atual (que uma propriedade do ambiente). Os atributos derivados como os objetos e associao derivadas podem ser teis na abstrao de propriedade significativas de uma aplicao, mas devem ser distinguidos nitidamente dos atributos bsicos, que definem o estado do objeto. Os atributos derivados no devem ser expressos como operaes, como obter-idade, embora possam eventualmente ser implementados como tais. Os atributos de ligao tambm devem ser identificados. Um atributo de ligao uma propriedade da ligao entre dois objetos e no a propriedade de um objeto isoladamente. Por exemplo: a associao muitos-para-muitos entre Acionistas e Empresa tem o atributo de ligao nmero de aes. Os atributos de ligao s vezes so tomadas erradamente por atributos de objetos.
Verso 27
160

Modelo Conceitual vs Modelo de Especificao
Workflow de Anlise
Transacao Datahora
Workflow de Projeto Transacao Datahora:Timestamp +getTransacao() +setDataHora() +getDataHora()
Conceito de classes e atributos

Verso 27
Classes
161

Modelo Conceitual:
Verso 27
162
Workflow de Anlise CRC

Mtodo dirigido a responsabilidades: Neste mtodo, a nfase est na identificao das classes a partir de seus comportamentos relevante ao sistema.
Tcnica Carto (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 Aplicao: CRC (Carto Responsabilidade e Colaborao) um carto ndice que usado para representar as responsabilidades das classes e suas interaes com outras classes. O carto CRC uma abordagem informal da modelo de orientao a objetos. Os cartes so criados atravs de cenrios, baseado nos Requisitos, que modela o comportamento do sistema. Observao: O CRC no faz parte da UML. Mas uma tcnica recomendada, pela sua simplicidade, principalmente para quem tem pouca experincia com orientao a objetos.
163
Workflow de Anlise CRC. Responsabilidades e Colaboraes:

Em sistema orientado a objetos, os objetos encapsulam os dados e os comportamentos. O comportamento de um objeto definido de tal forma que ela possa cumprir com as responsabilidades. Uma responsabilidade uma obrigao que um objeto tem para como sistema no qual ele estar inserido. Atravs das responsabilidades, um objeto colabora com outros objetos para que os objetos sejam alcanados. Podemos considerar que uma responsabilidade alguma coisa que objeto deve conhecer ou que ele deve saber fazer. Em alguns casos, um objeto tem uma responsabilidade com qual ele no pode cumprir sozinho. Nesses casos, o objeto deve requisitar colaborao de outros objetos do software para cumprir com sua responsabilidade.
Objeto
Colaboraes: (outras classes que so associadas, para a interao entre os objetos)
Responsabilidades: (o que objeto conhece e o que faz)
Verso 27
164
Workflow de Anlise CRC. Elementos:

O nome do carto o mesmo nome da classe, as responsabilidades so as coisas que a classe dever saber fazer e coisas que ela deve conhecer. As colaboraes as informaes 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:

Lista das responsabilidades
Colaboraes:
Lista de colaboraes
Melhores Prticas: Os candidatos a classe cujo a responsabilidade no foi encontrada, este candidato deve ser descartado. Pois, no podemos ter classe sem nenhuma responsabilidade.
165
Workflow de Anlise CRC. Exemplos:

Classe: Reserva
Responsabilidades:
Conhecer o perodo da reserva (datas) Saber o nome do cliente Saber o nmero do apartamento
Colaboraes:
Apartamento Cliente
Classe: Cliente Responsabilidades:

Saber o nome do cliente Saber a Reserva do Cliente
Colaboraes:
Reserva
Verso 27
166
Workflow de Anlise Modelo Conceitual. Tcnica: Inspeo Gramatical & CRC
Inspeo Gramatical
Lista de Candidatos
CRC
Classe: Cliente
UML
Colaboraes:
Responsabilidades:
Saber o nome do cliente Reserva Classe: Cliente Saber a Reserva do Cliente Responsabilidades: Colaboraes: Saber o nome do cliente Reserva Saber a Reserva do Cliente Classe: Cliente
Responsabilidades:
Colaboraes:
Saber o nome do cliente Reserva Saber a Reserva do Cliente
Identificao dos candidatos

Verso 27
Identificao das Responsabilidade

Modelo Conceitual
167
Workflow de Anlise Anlise de Caso de Uso:

Anlise comea com verificao do Modelo de Caso de Uso, Diagrama, Cenrios e Formulrios e a Lista de Requisitos Funcionais. Nesta anlise identificado os candidatos a classe.
Formulrio
Cenrios
Usurio Ator
Verso 27
Gerenciar Reserva Caso de Uso Associao

Listas de Candidatos
168
Workflow de Anlise Anlise de Caso de Uso. Big Picture

Documento de Viso 4
Lista de Candidatos
Anlise de Requisitos Lista de Requisitos Funcionais

Formulrio
Cenrios
Casos de Uso Lista de Requisitos No Funcionais Ator
Verso 27
Usurio
Gerenciar Reservas Associao

169
Workflow de Anlise Anlise de Caso de Uso: Identificando os candidatos a classe

Como fazer. Diagrama:
1 - Verifique os nome dos Casos de Uso, eles geralmente contm bons candidatos.
Usurio
Gerenciar Reserva
Reserva provvel candidato a classe
<<include>>
Atualizar Reserva
Buscar Apartamento
Funcionrio
Criar Reserva
<<include>>
Cadastrar Cliente
provveis candidatos a classe
Remover Reserva
170
Workflow de Anlise Anlise de Caso de Uso: Identificando os candidatos a classe

Como fazer. Cenrios:
2 - Os cenrios devem usados para identificao dos candidatos. Ache os substantivos, exemplo: Cenrios:
Gerenciar de Reserva: O Setor de Reserva do Hotel recebe um telefonema de cliente que solicita uma reserva de apartamentos para data. O cliente informa o perodo, ou seja, data de chegado e partida, e qual tipo de apartamento ele precisa. O funcionrio do Setor de Reserva, verifica a disponibilidade do apartamento e informa que no tem disponibilidade de apartamento para o perodo informado pelo cliente e oferece um outro tipo de apartamento. O cliente no aceita a proposta do funcionrio e a reserva no confirmada.
Cenrios
Provveis candidatos a classe
Verso 27
171
Workflow de Anlise Anlise de Caso de Uso: Atividades

Como fazer. Formulrio:
3 - Os Formulrios tambm devem usados para identificao dos candidatos. Ache os substantivos, exemplo:
Nome: Gerenciar Reserva Ponto de ativao: Este caso de uso comea quando o funcionrio do setor de reserva recebe uma solicitao de reserva Ator: Funcionrio Objetivo: Fazer reservar de apartamentos Pr-condio: Solicitao de reserva Fluxo Normal: O cliente informa o tipo de apartamento O cliente o perodo (data de chegada e partida) O funcionrio do Hotel verifica a disponibilidade do apartamento O funcionrio confirma a reserva Fluxo Alternativo: ... O funcionrio do Hotel verifica a disponibilidade do apartamento O funcionrio faz proposta de outro apartamento para cliente O cliente aceita e ento o funcionrio confirma a reserva Ps-condio: Reserva confirmada
Formulrios
Provveis candidatos a classe

172
Workflow de Anlise Modelo Conceitual. Tcnica: Inspeo Gramatical & CRC
Anlise de Caso de Uso

Lista de Candidatos
CRC
Classe: Cliente
UML
Responsabilidades: Colaboraes:
Saber o nome do cliente Classe: Cliente Reserva Saber a Reserva do Cliente Responsabilidades: Colaboraes: Saber o nome do cliente Reserva Classe: Cliente Saber a Reserva do Cliente
Responsabilidades: Colaboraes:
Saber o nome do cliente Reserva Saber a Reserva do Cliente
Identificao dos candidatos

Verso 27
Identificao das Responsabilidade

Modelo Conceitual
173
Workflow de Anlise Dicas: Scott Ambler

Para encontrar as classes, vejamos algumas dicas: 1 - Considere que as classes so lugares, eventos, conceitos, pessoas e etc. 2 - Atores so classes em potencial; 3 - Identifique os clientes; 4 - Siga o dinheiro, podemos identificar produtos, servios, eventos como venda, compra e etc; 5 - Conceitos so classes em potencial; 6 - Eventos so classes em potencial e 7 - Entende o negcio. Use a tcnica CRC para atribuir ou descobrir as responsabilidades e colaboraes das classes encontradas
Verso 27
174
Workflow de Anlise Graig Larman

Larman sugere a que a identificao dos substantivos, que so os candidatos a classe ou conceitos seja feito atravs dos Casos de Uso expandidos, pois, eles fornecem uma excelente descrio a serem usadas como fontes para este tipo de anlise. Exemplo:
Exemplo de Caso de Uso expandido: Seqncia tpica de eventos: 1 - Este caso de uso comea quando um Cliente chega a um ponto de venda e deseja comprar alguns itens. 2 - O Caixa registra o cdigo do produto de cada item ... Entretanto esta tcnica exige uma ou mais reviso nos conceitos encontrados, pois, diferentes substantivos podem representar o mesmo conceito.
Verso 27
175

Larman tambm sugere usar uma abordagem de Categoria de Conceitos, que nada mais que uma lista de categorias. Aps determinar lista use-a para identificar os conceitos. Exemplo de lista: Categoria
Objeto fsico ou tangvel Especificao, projeto, ou descrio de coisas Lugares Transaes Itens de transao Papis de pessoas
Exemplos
Terminal de ponto-de-venda Avio Especificao de produto Descrio de vo Loja Aeroporto Venda, Pagamento Reserva Itens de venda Parcelas de pagamento Operador Piloto
Verso 27
176

Identificao dos Conceitos: Abaixo um exemplo de identificao dos conceitos a partir dos Formulrios dos Casos de Uso:
Ao do Ator
1. Este caso de uso comea quando um Cliente chega no caixa com itens para comprar. 2. O Operador registra o identi-ficador de cada item. Se h mais de um do mesmo item, o Operador tambm pode informar a quantidade.
Resposta do Sistema
3. Determina o preo do item e adiciona informao sobre o item transao de venda em anda-mento. Mostra a descrio e o preo do item corrente.
Verso 27
177
Workflow de Anlise Peter Coad

A Proposta de Coad & Yourdon: O mtodo Anlise Orientada a Objetos, proposto por Peter Coad e Yourdon e denominado OOA (Object Oriented Analysis), consiste basicamente em cinco passos:
1 - Localizao de classes-&-objetos: entende-se por objetos como a abstrao de alguma coisa, em um domnio de problema, cujas informaes devam ser manipuladas pelo sistema. Uma classe corresponde ao conjunto de objetos semelhantes. 2 - Identificao de estruturas: que podem ser classificadas em: Generalizao-especializao: quando uma classe \ um tipo de uma outra classe. Exemplo: a classe carro uma especializao da classe veculos; Todo-parte: quando uma classe formada por outras classes. Exemplo: as classes motor e chassis fazem parte da classe carro.
3 - Definio de assuntos: onde cada qual se relaciona a diferentes partes do modelo, permitindo minimizar a complexidade de projetos extensos.
Verso 27
178
Workflow de Anlise Dicas: Peter Coad

A Proposta de Coad & Yourdon
4 - Definio de atributos: um atributo definido como uma propriedade, uma qualidade ou uma caracterstica de um determinado objeto. Um atributo consiste em alguns dados (informaes de estado) atravs dos quais cada objeto em uma classe tem seu prprio valor. Atributos comuns a todas as subclasses (especializaes) de uma classe so apenas listados na classe e, automaticamente, estendidos para as suas subclasses. Uma conexo de ocorrncia representa relacionamentos entre objetos. 5 - Definio de Servios: um servio um comportamento especfico que um objeto deve exibir. Um servio altera o estado de um objeto. Servios pertencentes a todas subclasses so definidos apenas na classe. Os servios implcitos, tais como incluir, remover, alterar e selecionar instncias, no so apresentados no diagrama. Uma conexo de mensagem representa a comunicao entre objetos, onde um emissor' envia uma mensagem para um `receptor'', para a realizao de algum processamento.
Verso 27
179
Workflow de Anlise
Vocabulrio.Road Map:

Fazer Vocabulrio
Verso 27
180
Workflow de Anlise Vocabulrio:

Fazer Vocabulrio
Descrever os conceitos
Fazer Vocabulrio: Devemos fazer um Vocabulrio de todas as classes presente no Modelo Conceitual. O vocabulrio consiste em simples descrio do conceito.
Transacao Datahora
Transao Uma nica solicitao integral para operaes nas contas de um nico cliente. Especificamente somente que as ATM podem entregar dinheiro, mas no podemos eliminar a possibilidade da impresso de cheques ou de receber dinheiro ou cheques. Tambm queremos prover a flexibilidade de operar as contas de diferente clientes, embora isso no seja exigido. As diferentes operaes devem fechar apropriadamente.
181
Workflow de Anlise Modelo Conceitual.
Verso 27
182
Workflow de Anlise Vocabulrio. Exemplo:

Vocabulrio: ATM Uma estao que permite os clientes introduzem suas prprias transaes utilizando cartes magnticos como identificao. A ATM interage com o cliente para obter informaes sobre transaes, envia as informaes sobre transaes para o computador central para validao e processamento e entrega de dinheiro ao usurio. Presumimos que uma ATM no necessita operar independente de rede. Banco Uma instituio financeira que mantm contas de cliente e emite cartes magnticos autorizando o acesso s contas atravs da ATM. Caixa Um empregado do banco autorizado a introduzir transaes nos terminais de caixa e a receber e entregar dinheiro e cheques aos clientes. As transaes, o dinheiro e os cheques manipulados por cada caixa devem ser registrados e devidamente contabilizados.
Verso 27
183

Vocabulrio: Carto Magntico Carto vinculado a um cliente do banco que autoriza o acesso s contas utilizando uma mquina ATM. Cada carto contm um cdigo de banco e um nmero de carto, codificados de acordo com os padres definidos pelo Bacen (Banco Central) sobre cartes de crditos e cartes magnticos. O cdigo do banco identifica inequivocamente o banco dentro do consrcio. O nmero do carto determina as contas a que carto pode ter acesso. Um carto no necessariamente d acesso a todas as contas do cliente. Cada carto pertence a um usurio cliente, mas podem existir mltiplas cpias dele, de modo que a utilizao simultnea do mesmo carto em diferentes mquinas deve ser considerada. Cliente Possuidor de uma ou mais contas em um banco. Um cliente pode ser uma ou mais pessoas ou corporaes; a correspondncia no relevante para este problema. Se uma pessoa possui conta em um diferente banco considerada cliente diferente.
Verso 27
184

Vocabulrio: Computador Central - Computador operado pelo consrcio que despacha transaes entre as ATM e os computadores dos bancos. O computador central valida cdigos de bancos mas no processam transaes diretamente. Consrcio Organizao de bancos que comissiona e opera a rede ATM. A rede s manipula transaes do consrcio. Conta nica conta no banco contra a qual as transaes podem ser aplicadas. As contas podem ser de vrios tipos, no mnimo de cheques e de poupana. Um cliente pode manter mais de uma conta. Terminal de caixa Terminal no qual os caixas introduzem transaes 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 transaes. Transaes Uma nica solicitao integral para operaes nas contas de um nico cliente. Especificamente somente que as ATM podem entregar dinheiro, mas no podemos eliminar a possibilidade da impresso de cheques ou de receber dinheiro ou cheques. Tambm queremos prover a flexibilidade de operar as contas de diferente clientes, embora isso no seja exigido. As diferentes operaes devem fechar apropriadamente.
Verso 27
185
Workflow de Anlise Diagrama de Objetos

Introduo: Bem o ltima coisa a fazer neste Workflow fazer a validao do Diagrama de Classes. Podemos fazer esta validao utilizando o Diagrama de Objetos e os Casos de Uso. Desta forma estaremos garantindo que o Diagrama de Classes feito atende os requisitos. Diagrama de Objetos, diagrama estrutural, que demonstra um conjunto de objetos e seus relacionamentos em determinado ponto no tempo. Sua principal aplicao ilustrar as estruturas de dados, registro estticos das instances dos itens encontrados no diagrama de classe. O diagrama de objetos direcionam a viso esttica do projeto ou de processo de um sistema. O Diagrama de Objetos tambm podem conter pacotes ou subsistemas, notas e restries. Exemplo da notao:
:Nome do Objeto Atributo: Valor do atributo objeto
Nome do Objeto Atributo: Valor do atributo vnculo
Verso 27
186

Recomendamos o uso do Diagrama de Objetos para validar o Diagrama de Classes. Exemplo:
Diagrama de Classe
Nome da associao Aluno -Nome: String -Data: Date Instance Matricula -Matricula: int -Curso: String Atributo
Diagrama de Objetos
:Aluno Nome: Fulano de Tal Data: 23-02-2001 objeto 201-23-02-01:Matricula Matricula: 201-23-02-01 Curso: Adm Empresas Valor do atributo
Nome do objeto
vinculo
Verso 27
187

Contedo 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 Curso: Adm Empresas
vnculo
Um vnculo uma conexo semntica existente entre os objetos. Em geral, um vnculo uma instance de uma associao. Desta forma um objeto pode enviar uma mensagem para outro.
Verso 27
188

Como fazer a modelagem de um estrutura de objetos: Como posso validar o diagrama de classes? Identifique o mecanismo cuja modelagem voc deseja fazer. Um mecanismo representa algum requisito ou comportamento da parte do sistema cuja a modelagem voc est fazendo e que resultante da interao de um conjunto de classes, interfaces e outros itens. Para cada mecanismo, identifique todos os itens (classes, interfaces e outros elementos) que participam nessa colaborao e seus relacionamentos. Leve em considerao somente um cenrio capaz de percorrer esse mecanismo. Congele o cenrio 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 necessrio, para compreenso do cenrio. De maneira semelhante, exponha os vnculos existentes entre esses objetos, representando as instance de associao entre eles.
Verso 27
189
Workflow de Anlise Arquitetura Inicial.Road Map

Fazer Vocabulrio
Definir o modelo de Arquitetura

190
Workflow de Anlise Modelo de Inicial de Arquitetura

Definir o Modelo de Arquitetura Definir o Modelo de Arquitetura Inicial
Podemos criar um Modelo de Arquitetura Inicial para aplicao. O objetivo deste modelo apresentar um viso macro da arquitetura. Os modelos de Caso de Uso e Modelo Conceitual so utilizados para desenhar este o modelo. Uma viso inicial da arquitetura pode ter muita formas, podemos utilizar a UML para representar este modelo ou qualquer outra notao. Este modelo ser refinado no workflow de projeto na Atividade Fazer o Modelo de Arquitetura.
Camada apresentao
4
Camada de servio (controle)
Camada regra de negcio
Banco de Dados
191
Apndice Diagrama de Pacotes

Como podemos definir o diagrama de pacotes? A definio de Pacote uma generalizao, ou seja, um agrupamento, com o propsito de organizar as Classes de Objetos em grupos. Esta abordagem facilita a anlise a medida que o nmero de Classes de Objetos cresce num do cenrio. O tipo de relacionamento linha pontilhada com uma seta que indica dependncia. Os diagramas de pacote podem ser usados para fazer decomposio funcional. A notao usada pela UML para representar pacotes :
Nome do Pacote
Nome do Pacote
Nome do Pacote
Nome do Pacote
Dependncia (import)
192
Apndice Diagrama de Pacotes

Decomposio. Dividir para conquistar... Algumas aplicaes podem ser enormes ou ter um grau muito alto de complexidade ou ambas as coisas. Para facilitar necessrio fazer uma decomposio. A idia da decomposio simples. fazer uma diviso para simplificar o entendimento, a modelagem ou processo de desenvolvimento de um software. Veja o exemplo abaixo:
Contas a Pagar
Fluxo de Caixa
Subsistema Contas a Receber

Nome do Pacote
Dependncia (import)
193
Desenho (design) do Modelo de Especificao de Software

Objetivo desta parte: apresentar e discutir o desenho (modelo de especificao) seus conceitos, tcnicas e modelo.
194
Workflow de Projeto Objetivo:

Apresentar e discutir o Workflow de Projeto, tambm conhecida como Fase de Especificao, agora faremos uso da intenso da UML para fazer os modelos (diagramas) e a documentao. As principais atividades so: - Construo do Modelo de Especificao (Projeto) - Construo do Modelo de Arquitetura - Fazer validao do modelo.
Verso 27
195
Workflow de Projeto Introduo. UML, Vises:
Viso de Projeto
Viso da Implementao
Codificao Montagem

Conceitual
Verso 27
Fsico
196
Workflow de Projeto Introduo. UML, Vises:

Viso de Projeto
A viso de projeto de um sistema abrange as classes e colaboraes que formam o vocabulrio do problema e de sua soluo. Essa perspectiva proporciona principalmente um suporte para os requisitos funcionais do sistema, ou seja, os servios que o sistema dever fornecer a seus usurios finais. Com a UML, os aspectos estticos dessa viso so captados em diagramas de classes e de
objetos; os aspectos dinmicos so captados em diagramas de interaes, de estados e de

atividades. Viso de Processo A viso do processo abrange os threads e os processos que formam os mecanismos de
concorrncia e de sincronizao do sistema. Essa viso tem com objetivo principal tratar questes
de desempenho, crescimento escalar e ao throughput do sistema. Com a UML, os aspectos estticos e dinmicos dessa viso so capturados nos mesmos tipos de diagrama da viso do projeto, mas o foco voltado para as classes ativas que representam esses threads e processos.
Threads = Linhas de execuo em paralelos, tambm conhecido como processo, estas linhas podem ser programas ou parte.
197
Workflow de Projeto Introduo. Aspecto esttico e dinmico:

O Workflow de Anlise determinado pelo aspecto estrutural esttico, que permite entender como uma software est estruturado internamente para atender os requisitos.
Esse aspecto chamado de esttico porque no apresenta informaes sobre como os objetos se comportam no ciclo de vida de software e tambm porque representa a estrutura das classes de objetos e os relacionamentos entre elas.
No Workflow de Projeto, faremos a modelagem dos aspectos dinmicos do sistema, estes aspectos so capturados em digramas (diagrama de interao, diagrama de estados e diagrama de atividades). E assim podemos representar os comportamentos internos e desta forma teremos novas vises do software e a conseguiremos compreender melhor o software.
Verso 27
198
Workflow de Projeto Introduo. Aspecto esttico e dinmico: UML. Principais Diagramas:

Modela a estrutura do sistema Modela o comportamento do sistema
ESTTICOS . Diagrama de Classes . Diagrama de Objetos . Diagrama de Componentes . Diagrama de Distribuio
DINMICOS . Diagrama de Casos de Uso . Diagramas de Interao - Diagrama de Seqncia - Diagrama de Colaborao . Diagrama de Atividade . Diagrama de Estados
Workflow de Projeto
Workflow de Anlise
Verso 27
199
Workflow de Projeto Introduo A Workflow de Projeto depende da Workflow de Anlise:
Workflow de Anlise
Anlise
dependncia
Workflow de Projeto
Projeto
Verso 27
200
Workflow de Projeto Introduo A Workflow de Projeto refina a Workflow de Anlise:

Workflow de Anlise modelo conceitual Workflow de Projeto
Diagrama de Classes
Cliente
codigo nome
<<refine>>
Cliente
-codigo: int -nome: String
Atributos: Tipo de dados
Atributos: Visibilidade
+getCodigo() +setCodigo() +getNome() +setNome()

mtodos
Verso 27
201
Workflow de Projeto Big Picture. Projeto

Anlise
Modelo Conceitual

Diagrama de Classes
Receber Pedido
Preencher Pedido
Enviar Fatura
Entrega [pedido urgente] [seno] Receber Pagamento
Entrega Regular
: visitante
: FormBusca
: Categoria
: Produto
: Catalogo
getDescricao( )
getQuantidade( )
exibirProduto( )
Encerrar Pedido
Verso 27
202
Workflow de Projeto
Arquitetura
Workflow Artefatos Diagrama de Seqncia / Colaborao
Analista de Sistema Projetista de Software
Papis
Arquitetura
Diagrama de Atividades
Arquiteto de Software
Diagrama de Estados
Diagrama de Classes
Verso 27
203
Workflow de Projeto Atividades.Road Map
Fazer Modelo de Especificao

Caso de Uso Modelo de Especificao
Fazer Modelo de Arquitetura

Modelo conceitual Modelo de Arquietura
Verso 27
204
Workflow de Projeto Projeto. Atividades e Passos:
Fazer Modelo Especificao

Identificar as classes de Especificao Fazer Diagrama de Interao Fazer a Diagrama de Atividades / Estados* Refinar o Modelo de Classes
Verso 27
205
Workflow de Projeto
Casos de Uso. Reviso

Uso caso de uso descreve o qu um sistema faz, ele no especifica como isso feito. Ao fazer uma modelagem, importante manter clara a separao de questes entre a viso interna e externa. O como modelado pelo Diagrama de Interao.
O qu
<<include>> selecionar categoria buscar produtos
visitante Diagrama de Estado
Diagrama de Sequncia
O como
: Produto : Catalogo
: visitante
: FormBusca
: Categoria
getDescricao( )
getQuantidade( )
exibirProduto( )
Formulrio
Verso 27
206
Workflow de Projeto
Diagrama de Interao. Introduo

Diagrama de Interao so modelos que descrevem como grupos de objetos colaboram para atender comportamento. Tipicamente, um diagrama de interao captura o comportamento de um nico caso de uso. O diagrama deve mostrar os vrios objetos e as mensagens que so passadas entre estes objetos. Existem dois tipos de diagramas: Diagrama de Seqncia: O foco deste diagrama maneira que as mensagens so enviadas ao longo do tempo. Diagrama de Colaborao: Aqui o foco o relacionamentos estrutural entre os objetos de uma interao e ento considerar como as mensagens so passadas no contexto dessa estrutura.
Verso 27
207
Workflow de Projeto Diagrama de Interao

O que Diagramas de Seqncia?
um diagrama que exibe a colaborao dinmica entre objetos de um sistema. O principal aspecto deste diagrama que a partir dele percebe-se a seqncia de mensagens enviadas entre os objetos. Ele mostra a interao entre os objetos e os eventos que acontecem em um ponto especfico da execuo do sistema.
Notao: Diagrama de Seqncia

:Objeto 1
Ator:
:Objeto 2
1: mensagem 1
2: mensagem 2
3: mensagem 3
Verso 27
208

Diagramas de Seqncia:
Verso 27
209

Diagramas de Seqncia:
formulrios de registro
entrar com senha de acesso validar acesso
formulrio de matrcula
cursos disponveis
Aluno:
entrar com o semestre
criar nova matrcula apresentar em tela obter cursos
Verso 27
210

Diagramas de Seqncia. Elementos: Instance das classes ator
: Atendente
: Cliente
: Veiculo
: Locacao
getDadosCliente( )
[* se cliente cadastrado verificar divida ]

getDivida( )
getDisponibilidade( )
setSaida( ) [* se veculo disponvel ]
Autodelegao
As interaes entre os objetos Restrio ou condio
Linha do tempo
Verso 27
211

Diagramas de Seqncia. Numerando as seqncias das mensagens.
: visitante
: FormBusca
: Categoria
: Produto
: Catalogo
1: getDescricao( ) 2: exibirCategoria( ) 3: selecionarCategoria
4: getDescricao( ) 5: getQuantidade( )
6: exibirProduto( )
7: selecionarProduto( )
Este diagrama descreve em ordem cronolgica as mensagens entre os objetos.

212

O que Diagrama de Colaborao? um diagrama que mostra a colaborao dinmica entre os objetos, semelhante ao diagrama de seqncia. No diagrama de colaborao, alm de mostrar a troca de mensagens entre os objetos, percebe-se tambm as colaboraes dos objetos. A interao de mensagens mostrada em ambos os diagramas. Diagrama de Colaborao tem a maioria de suas caractersticas semelhantes ao Diagrama de Seqncia. Quando usar o diagrama de Colaborao ? Se a nfase do diagrama for o decorrer do tempo, melhor escolher o diagrama de seqncia, mas se a nfase for relacionamentos estrutural entre os objetos de uma interao, melhor dar prioridade ao diagrama de colaborao. Podemos tambm escolher ambos. Diagrama de Seqncia mais usual.
Verso 27
213

O que Diagrama de Colaborao ? O diagrama de colaborao desenhado como um diagrama de objeto, onde os diversos objetos so mostrados juntamente com seus relacionamentos. As setas de mensagens so desenhadas entre os objetos para mostrar o fluxo de mensagens entre eles. As mensagens so nomeadas, que entre outras coisas mostram a ordem em que as mensagens so enviadas. Tambm podem mostrar condies, interaes, valores de resposta, e etc. O diagrama de colaborao tambm pode conter objetos ativos, que executam paralelamente com outros.
Exemplo: Diagrama de Colaborao
1:entrar com chave de acesso 3:entrar com o semestre formulrios de registro 4:criar nova matrcula Ator (Jos) 5:apresentar em tela 2: validar acesso
cursos disponveis 6:obter cursos
formulrio de matrcula
Verso 27
214

Gerando Diagramas de Colaborao:
Na ferramenta Rational Rose, aps criarmos o diagrama de seqncia. Selecionar: ~ Menu Browse e depois a opo F5 (Create colaboration Diagram)
: Categori 3: selecionarCategoria : visitante 7: selecionarProduto( )
4: getDescricao( ) 1: getDescricao( ) 5: getQuantidade( ) : Produto : Form Busca 2: exibirCategoria( ) 6: exibirProduto( ) : Catalogo
Verso 27
215
Workflow de Projeto Projeto. Atividades e Passos:
Fazer Modelo Especificao

Identificar as classes de Especificao Fazer Diagrama de Interao Fazer a Diagrama de Atividades / Estados* Refinar o Modelo de Classes
Verso 27
216
Workflow de Projeto Diagrama de Estado

O que Diagrama de Estado? um diagrama que tipicamente complementa a descrio das classes. Pois, este diagrama exibe todos os estados possveis que objetos de uma certa classe podem se encontrar. Mostra tambm quais as variaes de comportamento provocam tais mudanas. No necessrio escrever o diagrama de estado para todas as classes de um sistema, mas, apenas para aquelas que possuem um nmero 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. Aplicao: Um diagrama de estado pode ser aplicado a diversos elementos da UML, tais como: - Classes e Casos de Uso
Verso 27
217

Elementos: Os diagramas de estados so compostos de transies e estados. As transies so associadas com aes e so consideradas como processo de curta durao e no podem ser interrompidos. Os estados so associados com as atividades e podem levar mais tempo. Uma atividade pode ser interrompida por algum evento.
Verificando
Estado
Transio
Incio do fluxo
Final do fluxo
Verso 27
218

Exemplo:
incio
transio fora do gancho ocioso no gancho Estado Ativo
Verso 27
219

Exemplo 1:
Inicializa o Objeto Espera por Evento Trata Evento
on Lamp On on/print(on) off Lamp Off off
Finaliza Objeto
stop
Verso 27
220

Exemplo 2: (Completo)
[Nem todos os itens verificados]/pegar prximo item
[Todos os itens verificados e os todos itens disponveis]
incio
Verificando
Expedindo
[Todos os itens verificados e alguns itens no esto disponveis]
[itens ecebidos [alguns itens no esto disponveis]
Item recebido [os todos itens disponveis] cancelamento
Aguardando cancelado
Cancelamento
Entregue
final
Verso 27
221

Exemplo:
Caso de Uso
Cliente
Autenticar Senha
Diagrama de Estado
Consultar Pedido
Verificando Status
[Pedido no entregue]
Mudando Status
Gerenciar Pedido
<<extends>>
Cancelando Pedido
Cancelar Pedido <<include>>
Funcionrio
Confirmar Pedido
UpdateStatus Pedido
Logistica
Verso 27
222
Workflow de Projeto Diagrama de Atividades

O que Diagrama de Atividade?
um diagrama que exibe o fluxo seqencial das atividades, geralmente utilizado para demonstrar as atividades executadas por uma operao especfica do sistema, como por exemplo seleo de um item do menu principal. Consistem em estados de ao, que contm a especificao de uma atividade a ser desempenhada por uma operao do sistema. Decises e condies, como execuo paralela, tambm podem ser representados no diagrama de atividade. O diagrama tambm pode conter especificaes de mensagens enviadas e recebidas como partes de aes executadas. Diagramas de atividade capturam aes e seus resultados. Eles focam o trabalho executado na implementao de uma operao (mtodo), e suas atividades numa instance de um objeto. O diagrama de atividade uma variao do diagrama de estado e possui um propsito um pouco diferente do diagrama de estado, que o de capturar aes (trabalho e atividades que sero executados) e seus resultados em termos das mudanas de estados dos objetos.
223

Elementos e Exemplo com comentrios:
responsabilidades
Atividade atividade Fazer Pedido Cliente Vendas Estoque
atividade
transio
Processar Pedido
separao
Separar Produtos Enviar Pedido
deciso Receber Pedido Pagar Fatura Barras de sincronizao Fechar Pedido Cobrar Cliente
Elementos raias
juno
224

Os estados no diagrama de atividade mudam para um prximo estgio quando uma ao executada (sem a necessidade de especificar nenhum evento). Outra diferena entre o diagrama de atividade e o de estado que podem ser colocadas como swimlanes (raias). Uma swimlane agrupa atividades, com respeito a quem responsvel e onde estas atividades residem na organizao, e representada por retngulos que englobam todos os objetos que esto ligados a ela (swimlane). Um diagrama de atividade podemaneira alternativa de se mostrar interaes, com a possibilidade Um diagrama de atividade uma ser usado com diferentes propsitos inclusive: de expressar como as aes so executadas, o que elas fazem (mudanas dos estados dos objetos), Para capturar os trabalhos (seqncia das aes), e onde elas acontecem (swimlanes). quando elas so executadas que sero executados quando uma operao disparada (aes). Este o uso mais comum para o diagrama de atividade. Para capturar o trabalho interno em um objeto. Para mostrar como um grupo de aes relacionadas podem ser executadas, e como elas vo afetar os objetos em torno delas.
Para mostrar como uma instance pode ser executada em termos de aes e objetos.
Para mostrar como um negcio funciona em termos de trabalhadores (atores), fluxos de trabalho, organizao, e objetos (fatores fsicos e intelectuais usados no negcio). Diagrama de Atividades no orientado a objetos, na verdade ele muito semelhante a um fluxograma.
225

Exemplo 2:
Receber Pedido
Preencher Pedido Entrega

[pedido urgente] [seno]
Enviar Fatura
Receber Pagamento
Entrega durante a noite Entrega Regular
Encerrar Pedido
Verso 27
226

- Quando utilizar Diagrama de Atividade: Como a maioria das tcnicas de modelagem comportamental, os diagramas de atividades tm qualidades e deficincias, a melhor forma de us-lo a combinado com outras tcnicas. A maior qualidade dos diagramas de atividades est no fato que eles suportam e encorajam comportamento paralelo. Isso faz que ele possa ser utilizado como uma ferramenta para modelagem de workflow, e, em princpio, para programao concorrente. A desvantagem destes diagramas que eles no deixam muito claro as ligaes entre as aes e objetos. Voc pode definir uma ligao para um projeto rotulando uma atividade com um nome de objeto ou usando raias que dividem uma diagrama de atividades em base em responsabilidades, mas, isso no tem a clareza simples de diagramas de interao.
Verso 27
227

Quando utilizar Diagramas de Atividades:
Podemos utilizar diagrama de atividade nas seguintes situaes: - Analisando um caso de uso: Neste estgio, no estamos interessados em alocar aes aos objetos; precisamos simplesmente compreender que aes precisam acontecer e quais so as dependncias comportamentais. - Compreendo workflow: Os diagramas de atividades so muito teis para compreenso de um processo de negcio. - Descrevendo um algoritmo sequencial complicado: Neste caso, um diagrama de atividades simples flowcharts em notao UML. - Modelando processamento paralelo: Podemos usar o diagrama de atividades para modelar aplicaes de processamento paralelo. Quando no indicado: - Tentando ver como os objetos colaboram: O diagrama de interao mais indicado. - Tentando ver o comportamento de objeto durante se ciclo de vida: Neste caso o diagrama de estado o mais indicado.
228
Workflow de Projeto
Diagrama de Classes. Introduo

Apresentaremos e discutiremos o Diagrama de Classes, ele considerado o artefato mais importante e que tambm exige mais esforo para ser construdo. O Diagrama de Classes derivado do Modelo Conceitual (Workflow de Anlise) Agora no Workflow de Projeto o modelo refinado ganhando adornos, novos tipos de relacionamentos, mtodos e at novas classes.
Esta atividade tem a seguinte diviso, a qual chamamos de refinamento, so quatro passos. A cada passo faremos alguns refinamentos no modelo. Tambm ser definido alguns conceito durante estes passsos.
Verso 27
229
Workflow de Projeto Diagrama de Classe. Reviso:

O diagrama de classe um elemento estrutural
Verso 27
230
Workflow de Projeto Diagrama de Classe. Exemplo:
Verso 27
231
Workflow de Projeto Diagrama de Classe. Reviso:

Refinamentos:
1 - Refinamento: Atributos: Acrescentar tipos de dados e visibilidade exemplo: codigo 2 - Refinamento: Acrescentar: outros tipos de relacionamento entre as classes exemplo: agregao, composio, herana Acrescentar outros elementos como: Seta de navegao, Role Name (papis) e multiplicidade
Pessoa Fase de Anlise modelo conceitual Cliente codigo nome <<refine>> Fase de Projeto Diagrama de Classes Cliente -codigo: int -nome: String +getCodigo() +setCodigo() +getNome() +setNome() mtodos nome Atributos: Tipo de dados e Visibilidade
-codigo: int (private int codigo)
Pedido Data Status Numero 1 1..n item ItemPedito Quantidade
Cliente cpf codigo Relacionamento Herana
Verso 27
232
Workflow de Projeto Diagrama de Classes. Refinamento 1 - Refinamento: Exemplo: Atributos e Mtodos:

Fase de Anlise modelo conceitual Fase de Projeto Diagrama de Classes
Cliente
codigo nome
<<refine>>
Cliente
-codigo: int -nome: String +getCodigo() +setCodigo() +getNome() +setNome() +getCliente()
Atributos: Tipo de dados e Visibilidade
mtodos
Verso 27
233
Workflow de Projeto Diagrama de Classes. Refinamento 1 - Refinamento: Atributos: Acrescentar tipos de dados e visibilidade e mtodos. exemplo: codigo -codigo: int (private int codigo) Mtodo: Definir os Mtodos
Fase de Anlise modelo conceitual Fase de Projeto Diagrama de Classes
Cliente
Cliente
codigo nome
<<refine>>
-codigo: int -nome: String +getCodigo() +setCodigo() +getNome()

mtodos
Atributos: Tipo de dados e Visibilidade
Verso 27
234
Workflow de Projeto Diagrama de Classes. Refinamento 2 - Refinamento: Acrescentar: outros tipos de relacionamento entre as classes exemplo: agregao, composio, herana Acrescentar: Navegao, Role Name (papis) e Multiplicidade
Fase de Anlise modelo conceitual
Fase de Projeto Diagrama de Classes
Pessoa
nome
<<refine>>
Pessoa
cpf nome
cliente
Relacionamento Herana
PessoaFisica
codigo cpf
Verso 27
PessoaFisica
codigo
Role name
235
Workflow de Projeto Diagrama de Classes. Refinamento Herana, Agregao, Composio, Associao

Herana: mecanismo baseado em objetos que permite que as classes compartilhem atributos e operaes baseados em um relacionamento, geralmente generalizao Uma classe derivada herda a estrutura de atributos e mtodos de sua classe base, mas pode seletivamente: adicionar novos mtodos estender a estrutura de dados redefinir a implementao de mtodos j existentes
Herana Curso Universitrio
extends
Graduao
Podemos dizer que PsGraduao tipo de Curso Universitrio, assim como Curso de Especializao ou de Extenso.
Ps-Graduao
extends
Especializao Extenso
Uma classe pai proporciona a funcionalidade que comum a todas as suas classes derivadas, filhas, enquanto que uma classe derivada proporciona a funcionalidade adicional que especializa seu comportamento.
Verso 27
236
EspecialidadeMdica
generalizao
Tipo de Ortopedia
Tipo de Pediatria
especializao
ContaBancaria
Tipo de ContaCorrente
Tipo de ContaPoupana
237
Verso 27

Herana: Quais associaes so invlidas:
Figura
Cartao
TipoPagamento
Tipo de Retangulo Circulo CartaoCredito Tipo de
Tipo de CartaoDebito
Tipo de Ponto
Verso 27
238
Workflow de Projeto Diagrama de Classes Avanado. Refinamento

Refinamentos:
3 - Refinamento: Acrescentar: Associao Qualificada (qualificador), associaes reflexivas e Constraint (restries)
CPF -cpf getCPF() setCPF() { idade > 18} Sociio CPF -cpf getCPF() setCPF() Cliente -codigo: int -nome: String -idade: int +getCodigo() +setCodigo() +getNome() +setNome() +getIdade() +setIdade() Livro -isbn -titulo getISBN() setISBN() setTitulo() getTitulo() <Interface> Pessoa -nome: String +getNome() +setNome()
4 - Refinamento: Acrescentar: Classes Associativas, Interfaces e Dependncia
{ idade > 18}
Emprestimo -data -status getData() setDAta() setStatus() getStatus()
-codigo: int -idade: int +getCodigo() +setCodigo() +getIdade() +setIdade()
Verso 27
239
Workflow de Projeto Diagrama de Classes. Refinamento

Associao Qualificada um equivalente da UML de um conceito de programao conhecido como vetores, rvores binrias, maps ou dicionrios. Qualificador um atributo da associao cujo os valores particionam o conjunto de objetos relacionados a um objeto da associao. Aplicao: Reduo de semntica da associao. Tambm pode ser usado como ndice para hash ou vetor, isto quando, precisamos ter recurso de pesquisa em uma das extremidades da associao.
Classe
atributos
Verso 27
Nome da associao
qualificador
papel
0..1
papel
Classe
atributos
240

Associao Qualificada Pedido Produto
Qualificador
0..1
Linha de item
ItemPedido
quantidade: int
O exemplo, demonstra uma associao qualificada, entre as classe Produto, ItemPedido. O qualificador diz que em associao com Pedido poder haver um item de pedido cada ocorrncia de produto. Conceitualmente, esse exemplo indica que no possvel existir dois itens de pedido com pedido para o mesmo produto. Para fazer acesso a um item de pedido em especifico, necessrio identificar o produto como argumento.
241
Workflow de Projeto Diagrama de Classes. Refinamento 3 - Refinamento: Acrescentar: Associao Qualificada (qualificador), Associaes Reflexivas e Constraint (restries)
Associao Reflexiva Uma associao reflexiva (tambm conhecida como auto-associao) liga objetos da mesma classe. Cada objeto tem um papel distinto nesta associao.
papel 1 * papis Nome da associao
Classe
Em uma associao o uso dos papis importante para evitar ambigidade na interpretao da associao. Uma associao reflexiva no indica que um objeto se associa a si prprio (um empregado no gerente dele mesmo; uma condio no pr-requisito dela mesma). Associao reflexiva indica que um objeto se associa com outros objetos da mesma classe.
242
3 - Refinamento: Acrescentar: Associao Qualificada (qualificador), Associaes Reflexivas e Constraint (restries)

Associao Reflexiva: Exemplo
Superviso
Supervisor 1 *
Empregado
Supervisionado
Neste exemplo existe uma associao reflexiva objetos de Empregado. Nesta associao, h objetos que assumem o papel de supervisor e outros objetos que assumem o papel de supervisionado. O nome da associao pode ser omitido, uma vez que os papis foram definidos.
243
Workflow de Projeto Diagrama de Classes. Refinamento 3 - Refinamento: Acrescentar: Associao Qualificada (qualificador), Associaes Reflexivas e Constraint (restries)
Constraint (restries): Uma restrio um relacionamento semntica entre elementos de modelo que especifica condies que devem ser satisfeitas.
Classe
atributos
papel
{ restrio }
0..1
papel
Classe
atributos
Duas opes para representar restries em UML: Informal, a UML permite usar qualquer notao para representar as restries, entretanto , as estas devem ser especificadas dentro de chaves { }, podemos usar a linguagem formal, por exemplo. Formal, UML fornece linguagem formal de restries de objetos. (OCL - Object Constraint Language). Veja mais: http://www.omg.org/technology/documents/formal/ocl.htm
244
3 - Refinamento: Acrescentar: Associao Qualificada (qualificador), Associaes Reflexivas e Constraint (restries)

Constraint (restries): Por ser um mecanismo de extenso da UML, certos tipos de restries j esto definidos, tais como: complete, destroyd, disjoint, implicit, incomplete, new, or overlapping e transient.
Veja o exemplo: da restrio ou.
Contrato
atributos
{ ou }
0..1
0..1
Pessoafisica
atributos
PessoaJuridica
atributos
245
Workflow de Projeto Diagrama de Classes. Refinamento 4 - Refinamento: Acrescentar: Classes Associativas, Interfaces e Dependncia
Classe Associativa Em associao entre duas classes, a prpria associao poder ter propriedades. Essas propriedades so originadas a partir da associao de classes com a multiplicidade de: muitos:muitos, para expor a representao destas propriedades implementado uma nova classe que resultante da associao, assim como seus atributos e mtodos.
Classe
atributos
Classe
atributos
Nome da Associao
atributos
Verso 27
Classe de Associao
246
Classe Associativa Exemplo
Associao de muitos:muitos
Produto
atributos
Fornecedor
atributos
ProdutoFornecido
atributos
Classe de associao
Verso 27
247
Interface: O que interface ? (Representa a forma mais pura de abstrao de dados - Linguagem Java) Interface um contrato entre o cliente, onde o cliente pode ser classe concreta ou abstrata. Este contrato garantia que o mtodos assinados na interface sero implementados na classe cliente. O relacionamento entre uma interface e uma classe chamada de realizao.
<<interface>>
Estereotipo e nome da interface
Nome Interface
Mtodos (assinatura)
Assinatura do mtodos
Nota: Na interface tambm podemos declarar constantes (public static final).

248
Interface: Exemplo Interface, realizao e classes
<<interface>>
PessoaJuridica
getCNPJ() setCNPJ() setContrato() getContrato()
Realizao
Fornecedor atributos
PrestadorServico atributos
Verso 27
249
Dependncia: Uma dependncia um relacionamento de utilizao, determinando as modificaes na especificao de um item, mas no necessariamente o inverso. Utilizamos o relacionamento de dependncia no contexto das classes para mostrar que uma classe usa outra como argumento na assinatura de uma operao.
FilmClip
play(c: Channel) start() stop() pause()
dependncia
Channel
Verso 27
250
Workflow de Projeto Diagrama de Classes. Outros conceitos: Granularidade

Granularidade: Geralmente para cada atributo criamos um par de mtodos getter e setter, estes mtodos garantem o encapsulamento dos dados. Entretanto, quando estamos em um ambiente distribudo (de rede), fazer a manipulao de vrios e mtodos e atributos, um a um, pode causar um pssimo desempenho, temos que considerar latncia de rede, largura de banda e etc. Para evitar esta situao podemos criar um mtodo chamado getCliente(), que contempla todos os dados do cliente, desta forma estaramos fazendo um nica requisio. Desta forma temos a seguinte estrutura granular: Granularidade Grossa: Manipulao atravs de nico mtodo que encapsula todos os atributos da classe.
Granularidade Fina: Cada atributo tem seu par de mtodo.
Verso 27
251
Workflow de Projeto Diagrama de Classes. Granularidade

Granularidade: Exemplo
Cliente
-codigo: int -descricao: String +getCodigo() +setCodigo() +getDescricao() +setDescricao() +getCliente() Granularidade Fina
Granularidade Grossa
Verso 27
252
Workflow de Projeto Diagrama de Classes. Construtores:

O que so construtores? Construtores so um tipo especial de mtodo usado para inicializar uma instance da classe. Toda a classe deve ter um Construtor. Quando no declaramos o Construtor default, que inicializado automaticamente pelo Java. Mas existem casos que se faz necessrio a declarao explcita dos construtores.
Cliente
- codigo: int - nome: String - tipo: Tipo <<construtores>> +Cliente(codigo: int, nome: String) +Cliente(codigo: int, nome: String, tipo: Tipo)
<<mtodos>> + getCodigo(): int + getNome(): String + setCodigo(int codigo) + setNome(String nome) + getTipo(): Tipo + setTipo(tipo Tipo) + getCliente(): String
Tipo
-descricao: String +getDescricao(): String +setDescricao(d: String)
dependncia
253

Restrio: O Construtor no pode ser herdado. Para cham-lo a partir de uma subclasse usamos a referncia super. Para escrever um construtor, devemos seguir algumas regras: 1 O nome do construtor precisa ser igual ao nome da classe; 2 No deve ter tipo de retorno; 3 Podemos escrever vrios construtores para mesma classe.
public class Mamifero { private int idade;
public Mamifero(int idade) { this.idade = idade; }

//Mtodos
construtor
Verso 27
254

Quantos construtores pode ter uma classe ? Uma classe pode ter vrios construtores, entretanto, eles devem seguir a regra de overloading; Posso ter construtores com mesmo nome, mas com a lista de argumentos diferente (quantidade de argumentos, tipos de dados, ordem e etc)
public class Mamifero { private int idade; public Mamifero(int idade) { this.idade = idade; } public Mamifero() { } //Mtodos }
construtores
255
Workflow de Projeto Diagrama de Classes. Propriedades: Propriedades dos Atributos:

Existem trs propriedades definidas que podero ser utilizada como os atributos: - Changeable: No h restries para se modificar o valor do atributo. - addOnly: No caso de atributos com multiplicidade maior do que um, valores adicionais podero ser includos, mas uma vez criado, o valor no poder ser removido ou alterado. - Frozen: O valor do atributo no pode poder ser modificado depois que o objeto for iniciado
TaxaJuro
- valor: double {frozen} <<mtodos>> + getValor(): double + setValor(double valor)
Verso 27
Propriedade
256

Existem trs propriedades definidas que podero ser utilizada como os atributos: - Changeable: No h restries para se modificar o valor do atributo. - addOnly: No caso de atributos com multiplicidade maior do que um, valores adicionais podero ser includos, mas uma vez criado, o valor no poder ser removido ou alterado. - Frozen: O valor do atributo no pode poder ser modificado depois que o objeto for iniciado
TaxaJuro
Verso 27
Propriedade
257

Implementando a propriedade Frozen em Java: TaxaJuro
Modificador Final (constantes)

Para declarar uma varivel, um ou uma classe como constante usamos o modificador final. Entretanto, o uso deste modificador deve obedecer a certas restries como: Uma classe constante no pode ter subclasses; Um mtodo constante no pode ser sobrescrito; O valor para varivel constante deve ser definido no momento da declarao ou atravs de um construtor, para variveis membro, uma vez atribudo o valor, este no mudar mais. public class TaxaJuro { private final double VALOR; public TaxaJuro(double valor) { VALOR = valor; } public static void main(String args[]) { TaxaJuro taxa = new TaxaJuro(21.30); System.out.println(taxa.VALOR); } }
Verso 27
258

Exerccio: Implementando a propriedade Frozen em Java, implemente tambm os mtodos set e get e tente mudar o valor da atributo.
TaxaJuro
Verso 27
259
Workflow de Projeto Diagrama de Classes. Delegao:

Definio de Delegao: A habilidade de um objeto enviar uma mensagem a outro objeto como resposta a uma mensagem. O reso de propriedades de uma classe pode ser realizado no s atravs do mecanismo generalizao entre as classes, mas tambm atravs do mecanismo de delegao. O reso por generalizao se baseia na estrutura de superclasse e subclasse, onde a subclasse herda todos os mtodos e atributos da classe pai (superclasse). Recomendamos usar o mecanismo de delegao em algumas situaes: Para no violar regra de encapsulamento; Para no sobrecarregar de responsabilidade uma classe; Para atender a semntica da classe e Favorecer o mecanismo de reso. A seguir veremos um exemplo completo, onde a aplicao do mecanismo de delegao melhor soluo para obedecermos as regras da orientao a objetos.
Verso 27
260

No Modelo Conceitual devemos identificar os candidatos a classe e seus respectivos conceitos. Entretanto, devemos antes lembrar da definio da classe.
Classe A descrio de conjunto de objetos que compartilham os mesmos atributos, operaes, relacionamento e semntica.
Temos a primeira sugesto do modelo, como classe Cliente fazendo uma associao a Senha.
Cliente
codigo nome
possui
Senha
senha
Verso 27
261

Em segunda sugesto de modelo, como classe Cliente tem como atributo senha, desta forma a classe Senha no seria necessrio.
Cliente
codigo nome senha Quais so as implicaes que o atributo senha pode causar ao modelo ?
Verso 27
262

Ao modelarmos devemos ter os seguintes cuidados: 1 - Identificar todas classes que fazem uso ou que tem um determinado atributo, neste caso, Cliente e Funcionrio tem o atributo senha. Isto deve est explcito no documento Domnio do Problema. Veja o exemplo:
Conceito diferente
Cliente
codigo nome senha
Funcionario
codigo-funcional nome senha
O mesmo conceito
263

Ao modelarmos devemos ter os seguintes cuidados: (continuao) - Uma sugesto para soluo do problema:
Pedido
Cliente
codigo nome
Funcionario
codigo-funcional nome
HistoricoCliente
possui
Senha
senha
possui
Verso 27
264

Ao modelarmos devemos ter os seguintes cuidados: (continuao) 2 - Uma vez que senha um atributo de cliente como podemos implementar regras de negcio a senha, se implementarmos dentro da classe Cliente, teramos um erro de conceito (semntica). Veja o exemplo:
Cliente
codigo nome senha qde_dias_expiracao_senha
Este atributo somente regra que se aplica somente a senha e no a cliente.
Verso 27
265

Ao modelarmos devemos ter os seguintes cuidados: (continuao) 3 - Reso: - O atributo senha poder ser utilizado por outra aplicao, que nem sempre dever ver os outros atributos de cliente.
Cliente
codigo nome senha
Podemos concluir, que no exemplo apresentado duas regras da orientao a objetos foram violadas: - Semntica e - Baixo reso
266
Workflow de Projeto
Mitos e Lendas
O que dito: - Modelo de entidade e relacionamento (MER), deve ser feito antes do diagrama de classes.
Entretanto, a realidade outra... Quando estamos a metodologia de orientao a objetos os dados so encapsulados. Assim o MER deve ser derivado do modelo de classes.
Verso 27
267
Arquitetura de Software
Objetivo desta parte: apresentar e discutir Arquitetura de Software, conceitos modelos e tcnicas
268
Workflow Arquitetura Objetivo:

Apresentar e discutir a Arquitetura de Software. Arquitetura parte do Workflow de Projeto, nesta fase criamos os componentes, modelos fsicos e como sero distribudos. Os principais diagramas UML so: - Diagrama de Deployment e - Diagrama de Componentes. Tambm nesta fase refinamos o Modelo de Arquitetura. Objetivo primrio da arquitetura atender os requisitos no funcionais. O artefato deste passo : - Modelo de Arquitetura.
Verso 27
269
Workflow Arquitetura Big Picture. Arquitetura

Diagramas
Arquitetura
Projeto (Viso de Componentes e Viso de Deployment)
Receber Pedido
: visitante
: FormBusca
: Categoria
: Produto
: Catalogo
Preencher Pedido
Enviar Fatura
Entrega [pedido urgente]

getQuantidade( )
getDescricao( )
[seno] Receber Pagamento
exibirProduto( )
Entrega Regular
Encerrar Pedido
Diagrama de Componentes Diagrama de Deployment

Verso 27
270
Workflow Arquitetura
Arquitetura
Workflow Artefatos
Digrama de Componentes
Analista de Sistema Projetista de Software
Papis
Arquitetura
Arquiteto de Software
Verso 27
271
Workflow Arquitetura Introduo. UML, Vises:
Viso de Projeto
Viso da Implementao
Codificao Montagem

Conceitual
Verso 27
Fsico
272

Viso de Implementao A viso de implementao de um sistema abrange os componentes e os arquivos utilizados para a montagem e fornecimento do sistema fsico. Essa viso envolve principalmente o gerenciamento da configurao das verses do sistema, compostas por componentes e arquivos de alguma maneira independentes, que podem ser reunidos de diferentes formas para a produo de um sistema executvel.
Viso de Implantao A viso de implantao de um sistema abrange os ns que formam a topologia de hardware em que o sistema executado. Essa viso direciona principalmente a distribuio, o fornecimento e a instalao das partes que constituem o sistema fsico. Com a UML, os aspectos estticos dessa viso so representados em diagramas de implantao; os aspectos dinmicos so capturados em diagramas de interaes, de grfico de estados e diagramas de atividades.
Verso 27
273

Cada uma dessas vises pode ser considerada isoladamente, permitindo que diferentes participantes orientem seu foco para os aspectos da arquitetura do sistema que mais lhes interessem. Essas cincos vises tambm interagem entre si, por exemplo: Os ns na viso de implantao contm componentes da viso de implementao que, por sua vez,
representa a realizao fsica de classes, interfaces, colaboraes e classes ativas provenientes das
vises de projeto e de processo.
Verso 27
274
Workflow Arquitetura Modelo de Inicial de Arquitetura

Na Anlise fizemos um o Modelo de Arquitetura Inicial para aplicao. O objetivo deste modelo apresentar um viso macro da arquitetura. Os modelos de Caso de Uso e Modelo Conceitual so utilizados para desenhar este o Modelo de Arquitetura. Uma viso inicial da arquitetura pode ter muita formas, podemos utilizar a UML para representar este modelo ou qualquer outra notao. Este modelo ser refinado no workflow de arquitetura na Atividade Refinar o Modelo de Arquitetura.
Passos:
1 - Selecionar o Modelo de Arquitetura 2 Refinar o Modelo de Arquitetura Inicial.
Verso 27
275
Workflow Arquitetura Decomposio e Camadas

Decomposio: A decomposio refere-se fragmentao de uma aplicao ou sistema em partes menores e lgicas facilitando gerenciar a complexidade. Os mdulos, os subsistemas e componentes so bom exemplo de decomposio. A decomposio ajuda a definir e a esclarecer as interfaces entre as diferentes partes de um sistema. Tambm pode ser til nas situaes em que voc tem de integrar com o legado e ou aplicaes de terceiros. A decomposio pode tambm auxiliar na distribuio do software em diversos processadores. A decomposio ajuda na distribuio de responsabilidades e papis na equipe de desenvolvimento. As desvantagens: As decomposies inadequadas ou excesso pode levar facilmente a uma grave degradao do desempenho devido ao overhead de comunicao. Na UML a decomposio pode ser representada atravs do diagrama de pacotes e subsitemas.
276
Workflow de Arquitetura UML. Diagrama de Pacotes

Como podemos definir o diagrama de pacotes? A definio de Pacote uma generalizao, ou seja, um agrupamento, com o propsito de organizar as Classes de Objetos em grupos. Esta abordagem facilita a anlise a medida que o nmero de Classes de Objetos cresce num do cenrio. O tipo de relacionamento linha pontilhada com uma seta que indica dependncia. Os diagramas de pacote podem ser usados para fazer decomposio funcional. A notao usada pela UML para representar pacotes :
Nome do Pacote
Nome do Pacote
Nome do Pacote
Nome do Pacote
Dependncia (import)
277
Workflow de Arquitetura UML. Diagrama de Pacotes

Decomposio. Dividir para conquistar...
Algumas aplicaes podem ser enormes ou ter um grau muito alto de complexidade ou ambas as coisas. Para facilitar necessrio fazer uma decomposio. A idia da decomposio simples. fazer uma diviso para simplificar o entendimento, a modelagem ou processo de desenvolvimento de um software. Veja o exemplo abaixo:
Contas a Pagar
Fluxo de Caixa
Subsistema Contas a Receber
Nome do Pacote
Dependncia (import)
Verso 27
278
Workflow Arquitetura Separao em camadas

Camada: Uma aplicao de grande escala pode ser complexo e difcil de desenvolver e gerenciar. A camada um padro para a decomposio. A decomposio leva uma fragmentao lgica do sistema em subsistemas e mdulos, e as camadas agrupam e separam esses subsistemas, assim limitando quem pode usar os subsistemas, componentes e mdulos. O Rational Unified Process (RUP) ou simplesmente UP identifica duas abordagens para a camada: - Camada baseada em responsabilidade e - Camada baseada em reso. Camada baseada em responsabilidade: Estas as camadas so bem definidas, significando que cumprem um papel especfico no esquema geral das coisas. Tais camadas tambm so conhecidas como nveis.
Nveis: Os nveis podem ser mapeados para as camadas baseada em responsabilidades, neste caso um nvel torna-se sinnimo de cumprir um papel especfico no sistema, como a apresentao, a lgica de negcio, apresentao e etc.
Uma arquitetura baseada em nveis facilitam a manuteno, disponibilidade e separao de funcionalidades e de papis de uma aplicao
279
Workflow Arquitetura Separao em camadas

Nveis: A forma de se conseguir a distribuio em arquitetura com n nveis alinhar as camadas especficas com cada nvel, exemplo: - O nvel de cliente, lida com interao com usurio
- O nvel de apresentao, lida com apresentao dos dados

- O nvel de negcio, contm as regras de negcios e as entidades - O nvel de dados, fornece a interface para armazenamento de dados
<<tier>> Cliente
Verso 27
<<tier>> Apresentao
<<tier>> Negcios
<<tier>> Dados
280
Workflow Arquitetura Pattern. Model View Controller

Aplicao do MVC (Model, View e Controller) O padro MVC originou da linguagem Smalltalk e foi usada para projetar interfaces com usurio. Esta interface divida em trs partes: model, view e controller. Onde: Model: Representa o dado ou objeto. Ele que manipula e objetos, exemplo: JavaBeans e EJB. View: viso de como os dados sero apresentados, exemplo: pginas JSP e ASP Controller: Recebe as requisies, faz validao e define o model que manipular os dados. Algumas vantagens do MVC: - Decomposio; - Reso; - Possibilita o desenvolvimento em paralelo; - Separao de responsabilidades e papis; - Isolamento e separao das camadas e - Baixo acoplamento. MVC podem ser implementado de duas maneiras o modelo 1 e modelo 2, como veremos a seguir.
281
Workflow Arquitetura Model View Controller. Model 1

Model 1: O cliente faz uma requisio para uma pgina dinmica (JSP ou ASP) que pode chamar um model (componente) ou outra pgina dinmica que faz algum processamento e devolve para cliente a resposta
View
View
View Model
Web Server
Verso 27
282
Workflow Arquitetura Model View Controller. Model 2

Model 2: O cliente faz uma requisio para a camada controller que redireciona para camada model que executa algum processamento e retorna para controller que gera uma pgina dinmica (JSP ou ASP) que devolvida como a resposta ao cliente
View
View
View
Controller Componentes (Model)

Web Server
283
Workflow Arquitetura Model View Controller

Aplicao do MVC em ambiente de trs camadas (Web)
View: Viso representa a apresentao (interface com usurio) de uma aplicao. O componentes da View obtm os valores do estado do Model.
Separao do View e do Model habilita a construo independente interfaces com diferentes Look and Feel (aparncias - skins). Diferentes Views podem interagir com mesmo model. JSP escolha natural para implementao do View Controller: O Controller fornece a ligao da arquitetura MVC. Ela responsvel por receber as requisies e determinar qual o Model apropriado para atende-la. Ele tambm poder tratar a resposta.
Verso 27
284
Workflow Arquitetura Model View Controller

Aplicao do MVC (Model, View e Controller)
Model: O modelo representa as regras de negcios de uma aplicao. Encapsulando as regras dentro de um componente facilita os testes, melhora a qualidade e promove o reso de componentes. Estado do componentes (model): O estado define um conjunto de valores do Model e inclui mtodos para mudar estes valores. Estes mtodos so regras de negcios e outros mtodos.
O estado de componente so geralmente um protocolo independente. Na tecnologia Java os JavaBeans e os EJBs so uma boa escolha para implementar estes componentes. Na tecnologia .Net (Microsoft) podemos usar os componentes COM+
Verso 27
285
Workflow Arquitetura Introduo: O papel da Arquitetura:

Os softwares podem ter arquitetura e ambiente simples, ou seja, rodar um nico servidor e em diversas estaes clientes em ambiente de rede local. Atualmente, os softwares podem ter uma arquitetura mais complexa, ou seja, eles podem ser distribudos, ou seja, rodar em uma rede distribuda, com diversos servidores, quando alocamos algum recurso remotamente (componentes, por exemplo), temos que garantir o funcionamento (desempenho) deste software misso mais difcil e at critica. O papel do Arquiteto de Software garantir o funcionamento do software e atendimento pleno dos Requisitos No Funcionais (Desempenho, Escalabilidade, Confiabilidade, Segurana e etc) e das Restries, como uso de determinada tecnologia (protocolos, linguagens de programao, banco de dados e etc) As responsabilidades do Arquiteto de Software: - Selecionar uma tecnologia adequada e projetar um modelo robusto, flexvel e eficiente. - Propor um plano de reduo de risco.Um ambiente complexo tem um risco maior, cabe ao Arquiteto desenvolver um plano para reduo de risco. - O Arquiteto tambm deve sugerir o uso de Patterns de Arquitetura que so as boas prticas para a construo do Modelo.
286
Workflow de Arquitetura Princpios:

Existem diversos princpios que podemos aplicar a arquitetura de software, entretanto existem dois que se destacam: - Separao de Camadas e - Princpio da Dependncia Inversa.
Verso 27
287
Workflow Arquitetura Arquitetura.Road Map
Modelo de Especificao Documentos de Requisitos
Fazer Diagramas
Digrama de Deployment
Fazer Modelo de Arquitetura
View
Controller
Model
Resources
JSP/HTML
Servlet
EJB
Banco de Dados
Caso de Uso
Verso 27
288
Workflow Arquitetura Arquitetura. Atividades e Passos:

Fazer Modelo Arquitetura
Selecionar uma Arquitetura Fazer Diagrama de Deployment Fazer Diagrama de Componentes
Digrama de Deployment
Refinar Modelo de Arquitetura (RNFs) Refinar o Modelo de Especificao

289
Workflow Arquitetura Diagrama de Deployment

O que Diagrama de Deployment?
Variaes traduo: Diagrama de Deployment <=> Diagrama de Implantao Diagrama de Deployment <=> Diagrama de Distribuio
um diagrama que exibe a arquitetura fsica do hardware e do software no sistema. Pode apresentar os computadores e perifricos, juntamente com as conexes que eles estabelecem entre si. Podemos mostrar tambm os tipos de conexes entre esses computadores. Especifica-se os componentes executveis e objetos que so alocados para exibir quais unidades de software so executados e quais computadores. O diagrama de deployment demonstra a arquitetura runtime de processadores, dispositivos fsicos e de software que executam no ambiente onde o sistema desenvolvido ser utilizado. o ltimo diagrama da topologia do sistema, descrevendo a estrutura de hardware e software que executam em cada unidade.
290

Elementos: Processor (Processador): qualquer mquina que possua a capacidade de processamento. Os servidores, estaes de trabalho por exemplo.
Servidor
processador
Device (Dispositivo): qualquer mquina com finalidade ou finalidade limita. Os dispositivos so os itens como impressoras, roteadores, raids, storages, scanners, leitoras de cdigo de barra e etc.
Impressora
Dispositivo
291

Elementos: Connection (conexo): A conexo o vinculo entre processadores e dispositivos. Geralmente representam as conexes de rede fsicas (rede local ou distribuda).
estereotipo
Cliente
<<TCP/IP>>
Servidor
<<RS 232>> Impressora
conexo
Processador (N)
Dispositivo (N)
292

Elementos: Os processadores e os dispositivos podem ser chamados de n. Um n um elemento fsico que existe em tempo de execuo e representa um recurso computacional.
<<Cliente>> WebBrowser <<WebServer>> Apache <<HTTP>>
<<RS 232>> Impressora
Ns
<<Application Server>> JBoss <<Banco de Dados>> Oracle
<<RMI>>
<<Client-Server>> Cliente
Verso 27
293

O diagrama de Deployment pode ser substitudo por outro diagrama que exibam com maiores detalhes e/ou com cones mais apropriados. Apesar de no ser uma boa recomendao, pois, estaramos deixando de lado a UML, mas em algumas vezes se faa necessrio.
WebServer Apache
Banco de Dados
Oracle
Application Server JBoss
Verso 27
294
Workflow Arquitetura Diagrama de Deployment & Diagrama de Componentes

Adicionando ao Diagrama de Deployment o Diagrama de Componentes, podemos ter uma viso mais clara da arquitetura baseada na UML
Verso 27
295
Workflow Arquitetura Diagrama de Componentes. Introduo:

Os componentes so utilizados para a modelagem de coisas fsicas que podem residir em n, como executveis, bibliotecas, tabelas, arquivos e documentos. Um componente tipicamente representa o pacote fsico de elementos lgicos, como classes, interfaces, colaboraes. Bons componentes definem abstraes com interfaces bem-definidas, desta forma possvel atualizao de componentes, ou seja, trocar os componentes mais velhos por outros componentes mais novos ou por novas verses.
Dependncia
Componente A Componente genrico Componente B Nome do componente
Verso 27
296
Workflow Arquitetura Diagrama de Componentes

O que um Diagrama de Componentes?
um diagrama que exibe o sistema por um lado funcional, expondo as relaes entre seus componentes e a organizao de seus mdulos durante sua execuo. O diagrama de componente descreve os componentes de software e suas dependncias entre si, representando a estrutura do cdigo gerado. Eles so tipicamente os arquivos implementados no ambiente de desenvolvimento. Diagrama de componente representa uma viso fsica, um pedao de software de sistema e seus relacionamentos. Quando um componente colabora com outro componente, est colaborao ilustrada com uma dependncia entre o componente cliente e o componente de servio.
ReservaService ReservaUI
Dependncia
Reserva Service_ stub Component
Interface
Room
Verso 27
297
Workflow Arquitetura Diagrama de Componentes. Definies:

Componente:
Um componente a parte fsica e substituvel de um sistema ao qual se adapta e fornece a realizao de um conjunto de interfaces.
Interfaces: Uma interface coleo de operaes utilizadas para especificar um servio de uma classe ou de um componente. O relacionamento entre componente e interface muito importe. As tecnologias mais populares usam interfaces na implementao de componentes, tais como: - Enterprise Java Beans; - Corba (CCM) e - Microsoft COM+.
Verso 27
298
Workflow Arquitetura Diagrama de Componentes. Exemplo:

CatalogHome
CatalogHome
Catalog.jsp Catalog Business Delegate
Catalog Home Stub
Catalog EJB Home
CatalogRemote
CatalogRemote
Catalog Bean
Catalog Remote Stub
Catalog EJB Object
CatalogRemote
Verso 27
299

Tipos de Componentes:
Existem trs tipos de componentes:
- Componentes de Implantao: So os componentes necessrios para montar um sistema executvel, como as DLLs e os arquivos EXEs. A definio da UML para componentes abrangente, inclui componentes mais populares (COM+, CCM e EJB), alm de modelos alternativos como pginas web, tabelas de banco de dados e etc...
CheckIT.exe {verso 1.}
Video.dll
Disk.dll Floppy.dll
Verso 27
300

Tipos de Componentes: (continuao)
- Componentes do Produto do Trabalho: Esses componentes so essencialmente o parte do processo de desenvolvimento, formados por arquivos de cdigo fontes, arquivos de dados, cones. Esses componentes no fazem parte (diretamente) em sistema executvel, mas so os produtos de desenvolvimento, usados para criao do sistema executvel. Cliente.class
Conta.class Conta.jar {verso 1} Historico.class
Conta.java
- Componentes de Execuo: Esses componentes so criados como uma conseqncia de um sistema em execuo, como um componente COM+, que sofre instance a partir de uma DLL.
301
Workflow Arquitetura Diagrama de Componentes. Elementos:

Elementos:
A UML define cinco esteretipos-padro que se aplica aos componentes: 1 - Executvel: Especifica um componente que poder ser executado em um n 2 - Biblioteca: Especifica uma biblioteca de objetos esttica ou dinmica 3 - Tabela: Especifica um componente que representa uma tabela de banco de dados 5 - Arquivo: Especifica um componente que representa um documento contendo cdigo-fonte ou dados 6 - Documento: Especifica um componente que representa um documento.
Verso 27
302

- Componente: O cone de componente representa um mdulo (pedao) de software com uma interface bem definida. Na especificao de componente definimos o esteretipo como: ActiveX, Applet, Application, DLL e EXE.
Nome do Componente
Componente genrico
- Especificao e corpo do subprograma: Estes cones representam a especificao visvel de um subprograma e o seu corpo de implementao. Um subprograma costuma ser uma coleo de sub-rotinas. Os subprogramas no contm definies de classe.
NewSubprogSpec NewSubprogBody
Verso 27
303

- Programa Principal: Este cone representam o programa principal. Um programa principal que contm a raiz de um programa. Na linguagem Java seria o programa que tem o mtodo main. MainProgram
Programa princial (mtodo main)
- Especificao e corpo do pacote: Um pacote a implementao de uma classe. Uma especificao de pacote constitui-se em um arquivo de cabealho, o qual contm as informaes referentes ao prottipo de funo para a classe.
Package Specification Package Body
Na linguagem C++, as especificaes de pacote so os arquivos .h (header). Em Java usamos o cone de especificao de pacote para representar os arquivos .java
Verso 27
Um corpo de pacote pode apresentar o cdigo para as operaes da classe. Em C++, os corpos de pacotes so os arquivos .cpp
304

- Especificao e corpo da tarefa: Estes cones representam os pacotes que possuem linhas independentes de controle. Uma arquivo executvel geralmente representado como uma especificao de tarefa com uma extenso .exe
NewTaskSpec NewTaskBody
Alm de modelar o componente propriamente dito, podemos modelar o relacionamento entre o componente e sua interface. Veja o exemplo abaixo:
Componente genrico
Interface
Verso 27
305
Workflow Arquitetura Arquitetura.Diagrama de Componentes. Exemplo:

Neste exemplo criaremos um diagrama de componentes para a funcionalidade cesta de compra. Neste momento identificaremos as classes que so necessrias para realizar o caso de uso adicionar item na cesta de compra. Como alguns casos de usos so embutidos, novos componentes sero adicionados ao diagrama. A tecnologia deste exemplo Java.
Component view
Boundary
Services
Entities
Viso principal do Diagrama de Componentes

306

Todos os componentes do pacote Entities. Esses so os componentes que contero as classes de entidades.
Component view
Cesta
Entities
Cesta Item
Produto
As classes Entidades
Verso 27
307

Todos os componentes do pacote Services. Esses so os componentes que contero as classes de servios ou de controle.
Component view
CestaService
Services
ProdutoService
As classes de Servios ou Controle
Verso 27
308

Todos os componentes do pacote Boundaries. Esses so os componentes que contero as classes de Boundaries (ou de interface com usurio).
Component view
CestaInterface
Boundary
As classes de Interfaces
Verso 27
309

Uma viso dos componentes e relacionamentos
MainProgram CestaInterface
CestaService ProdutoService
Cesta
Cesta Item
Produto
Verso 27
310

Um novo exemplo, o cenrio fazer Reserva de apartamento.
View
Menu Principal
ReservaUI
Controller
ClienteService
ReservaService ApartamentoService
Model
Cliente
Reserva
Apartamento
Verso 27
311
Workflow Arquitetura Diagrama de Componentes. Identificao de Componentes:

Componentes: Componentes so grupos de classes que representam uma funcionalidade dentro de sistema.
Como fao o diagrama de componentes ?
Componentes so identificados usando coeso e acoplamento. Grupos de classes que exigem alta coeso e baixo acoplamento formam um componente. Como identificar os componentes ? Na fase de Projeto os componentes so desenhados da seguinte forma: O Diagrama de Classe so revisados e grupos de classes so identificados usando coeso e acoplamento. Este grupos representaram os componentes.
Componentes
Verso 27
312
Workflow Arquitetura Conceitos: Acoplamento e Coeso

Independncia Funcional
Independncia Funcional: Coeso e Acoplamento
Conceito que est diretamente relacionado a modularidade, abstrao e encapsulamento de informao. Principais caractersticas: funo de propsito nico. Interfaces simples quando visto de outras partes da estrutura do programa. medida usando-se dois critrios qualitativos: coeso e acoplamento.
Coeso e Acoplamento ajudaram na diviso de classe dentro de componente.
Verso 27
313

Coeso (High Cohesion) uma medida de fora funcional relativa de um mdulo. Uma classe coesiva executa uma nica tarefa, exigindo pouca interao com outras classes ou objetos. Alta coeso o desejvel. Como manter a alta coeso ?
- Soluo: Atribuir uma responsabilidade de forma que a coeso permanea alta. Como manter a complexidade sob controle ? Em termos de projeto orientado a objetos, a coeso (ou mais especificamente, coeso funcional) uma medida de quo fortemente relacionadas e focalizadas so as responsabilidades de uma classe. Uma classe com responsabilidade altamente relacionadas e que no executa um formidvel volume de trabalho tem coeso alta.
Verso 27
314

Coeso: (continuao) Uma classe com coeso baixa faz muitas coisas no-relacionadas, ou executa demasiado trabalho. Tais classes so indesejveis, elas sofrem dos seguintes problemas: - So difceis de compreender; - So difceis de reusar; - So difceis de manter; - So muito sensveis a mudana; Classes de coeso baixa representam, geralmente, uma abstrao de grande granularidade ou atriburam responsabilidades que deveriam ter sido delgadas a outras classes ou objetos
Verso 27
315

Coeso: (continuao) Exemplo: Neste exemplo demonstrado a baixa coeso, uma vez que a classe Nota Fiscal assume a responsabilidade de fazer o clculo dos imposto Tributo
- codigo - nome
NotaFiscal
- nmero - data emisso - tipo +calcularImposto() +getNumero +setNumero ....
Cliente
- codigo - nome +getCodigo() +setCodigo() +getNome()
NotaFiscalItem
- item[ ] - quantidade +getQuantidade() +setQuantidade() ...
Produto
- codigo - descrio +setCodigo() +getCodigo()
Verso 27
316

Tributo Coeso: (continuao) Exemplo: Soluo delegar a responsabilidade de clculo de imposto para uma classe especializada neste assunto (usamos aqui o mecanismo de delegao). Desta forma teremos uma alta coeso. Produto
- codigo - descrio +setCodigo() +getCodigo() +gerProduto - codigo - nome
NotaFiscal
- nmero - data emisso - tipo +getNumero +setNumero ....
CalculoImposto
+calcularImposto()
NotaFiscalItem
- quantidade +getQuantidade() +setQuantidade() ...
Cliente
- codigo - nome +getCodigo() +setCodigo() +getNome() +get/cliente()
Verso 27
317

Coeso: (continuao) Tipos de coeso funcional: Coeso Muito Baixa:
Uma classe a nica responsvel por muitas coisas em reas funcionais muito diferentes Uma classe a nica com a responsabilidade de uma tarefa complexa em rea funcional Uma classe tem a responsabilidade moderadas em uma rea funcional e colabora com outras classes para levar a termo as tarefas Uma classe tem peso leve e responsabilidade exclusivas em umas poucas reas diferentes que esto logicamente relacionadas ao conceito da classe, mas no entre si.
Coeso Baixa:
Coeso Alta:
Coeso Moderada:
Verso 27
318

Coeso: (continuao) Benefcios: Clareza e a facilidade de compreenso do projeto aumentam; A manuteno e as melhorias so simplificadas; Freqentemente, o baixo acoplamento favorecido; A granularidade fina de funcionalidades altamente relacionadas suporta o aumento do potencial de reso, porque uma classe altamente coesiva pode ser usada para finalidade muito especfica..
Verso 27
319

Acoplamento (Low Coupling)
uma medida da interdependncia relativa entre as classes. Depende da complexidade de interface entre as classes. Baixo acoplamento o desejvel
Como manter o baixo acoplamento ?
- Soluo: Atribuir uma responsabilidade de forma que o acoplamento permanea fraco Como suportar uma dependncia baixa e aumentar o reso? O acoplamento uma medida de quo fortemente uma classe est ligada a uma ou mais classes, tem conhecimento das mesmas ou depende delas. Uma classe com acoplamento baixo (fraco) no dependente de muitas classes.
Verso 27
320

Acoplamento (continuao) Uma classe com acoplamento alto (forte) depende de muitas outras classes. Tais classes so indesejveis; elas sofrem dos seguinte problemas: Mudana em classes relacionadas foram mudanas locais Mais difcil de compreender isoladamente Mais difcil de reusar porque o seu uso requer a presena adicional das classes que ela depende. Benefcios:
No afeta por mudanas em outros componentes simples de entender conveniente para o reso.
Verso 27
321

Acoplamento. Tipos:
Abaixo os possveis tipos de acoplamento:

Acoplamento Abstrata:
<<Interface>>
Cliente
Service
{abstract}
Cliente
Service
Service Sem acoplamento
Service
Service Forte acoplamento Cliente
Service
Cliente
Service
Service
Com acoplamento Cliente Service
Verso 27
tight Rildo F Santos (rildo.santos@Companyweb.com.br)
322
Workflow de Projeto, Arquitetura Conceitos: Acoplamento e Coeso

Acoplamento
Princpio da Dependncia Inversa: Abstrao no deve depender classe concreta. Uma classe concreta deve depender de uma abstrao
Exemplo:
Moeda
- valor +getValor +setValor
MaskMoeda
+maskFormat()
dependncia
Este modelo tem alguns problemas: 1 - Herana. Todos que herdarem a classe Moeda so obrigados a herdar tambm a classe MaskMoeda e as vezes somente precisamos da classe Moeda.
323

Acoplamento
Princpio da Dependncia Inversa (continuao):

Moeda - valor
+getValor +setValor +maskMoeda()
MaskMoeda
dependncia
2 - O relacionamento de dependncia inibe a extensibilidade da classe Moeda. Vamos analisar o seguinte cenrio: Em uma aplicao financeira que lida com mercado internacional, precisamos ter uma classe Moeda com as seguintes responsabilidades de saber o valor, formatao de acordo padro monetrio e exibir o respectivo smbolo da moeda (cifro).
Verso 27
324

Acoplamento
Princpio da Dependncia Inversa (continuao): Aplicando a DIP, podemos resolver a situao, veja os modelos abaixo:
DIP com Classe Abstrata: Cliente Service
{abstract}
DIP com Interface:

<<Interface>>
Cliente
Service
Service
Service
Service
Service
Soluo para a classe Moeda: Moeda MoedaMask

{abstract}
Real
Dolar
325

Acoplamento Relacionamento de Realizao Problema: A classe Cliente realiza a interface iPessoa (isto quer dizes que todos os mtodos assinados na interface deve ser implementado na classe) Uma vez que se declare uma nova assinatura de mtodo na interface iPessoa ser necessrio implementar este novo mtodo na classe Cliente.
<<interface>> Realizao iPessoa
Cliente
Verso 27
326

Acoplamento Relacionamento de Realizao Soluo: Criao de nova classe PessoaAdapter esta classe se relacionar com a interface iPessoa, desta forma todas as modificaes ou novos implementaes sero feitas nesta classe. Desta forma reduziremos o acoplamento entre a interface e a classe Cliente
<<interface>> iPessoa Realizao PessoaAdapter
Cliente
Verso 27
327

Exemplo: A partir do diagrama de classe, tentamos agrupar classes usando tcnicas de coeso e acoplamento.
Exemplo: Acoplamento Coeso e Componentes
Verso 27
328

Exemplo: Temos o seguinte resultado:
Exemplo: Acoplamento Coeso e Componentes
Verso 27
329

Exemplo 2: Diagrama de Classes:
Verso 27
330
Workflow Arquitetura UML. Diagrama de Componentes

Exemplo 2: A partir do diagrama de classe, agrupar classes usando os conceitos de coeso e acoplamento.
Pedido
Cesta de Compra
Produto FormaPagto
Verso 27
331
Workflow de Projeto, Arquitetura Diagrama de Componentes

Exemplo 2: Diagrama de Componentes
Produto
Pedido
Cesta de Compra
Cesta
Produto FormaPagto
Pedido FormaPagto
Verso 27
332
Workflow Arquitetura Projetando um Modelo de Arquitetura:

Sugesto para modelo de Arquitetura para aplicaes Web de trs camadas: Servidor de Aplicao JBoss
HTTP TCP/IP
Cliente
Servidor de Banco de Dados
Oracle
HTML
Windows
Linux Suse
Linux Suse
Verso 27
333
Workflow Arquitetura Projetando um Modelo de Arquitetura para Camada Cliente:

Cliente Servidor. Fazendo acesso utilizando o RMI (Remoto Method Invocation)
DeskTop
ReservaUI
Servidor de Aplicao
Reserva
<<JRMP>>
Funcionrio
<< Stub>>
<<Skeleton>>
RMI
334

Web
Browser FormConsulta
Cliente
HTTP
WebServer
ServletsController
Servlet
Tabelas de Reserva
<< Reserva>>
JSP HotelSchema JavaBeans

<< ConnDB>>
Banco de Dados
Verso 27
335

Web
Cliente
Browser FormConsulta
Apresentao
ServletsController
Negcio
<< Reserva>>
Integrao
JDBC 2.0
Recursos
HTTP
<< ConnDB>>
Cliente
Banco de Dados
HTML
Servlet/JSP
JavaBeans
SQL
Verso 27
336
Workflow Arquitetura Implementando os Requisitos No Funcionais:

Neste momento devemos construir modelo de arquitetura para atender todos os RNF e os casos de uso mais relevante ao negcio. A seguir demonstraremos um exemplo de como criar uma arquitetura para RNF. Considerando o cenrio de Loja Virtual, numa transao de pagamento.
Browser FormPagamento
Cliente Fazer Pedido <<include>> Cliente
HTTPs (HTTP + SSL)

<<include>> Fazer Pagamento Fechar Pedido
WebServer
ServletsController
CartaoCredito
Pagamento
Requisito No Funcional: Segurana: Todas as transaes de pagamento deve ser realizado em ambiente seguro
337
Quer Mais Capacitao Engenharia de Software

Gostou quer mais, gostaria de receber outros materiais sobre o mesmo tema e novas verses deste material... 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/
338
Sobre o Anlise eRildo F. Orientado a Objetos com UML autor: Desenho Santos
Coach e Consultor de Gesto de Negcios, Inovao e Tecnologia para a Gesto 2.0, a Gesto gil. A Gesto gil ajuda as empresas a responder mais rpido as demandas de negcio e mudanas. A Gesto 2.0, abrange Planejamento Estratgico, Gesto por Processos geis, Gesto de Projetos geis, Tecnologia da Informao (Mtodos geis), Inovao e Liderana. Minha Experincia: Tenho mais de 10.000 horas de experincia em Gesto de Negcios, Gesto de Inovao, Governana e Engenharia de Software. Formado em Administrao de Empresas, Ps-Graduado em Didtica do Ensino Superior e Mestre em Engenharia de Software pela Universidade Mackenzie. Fui instrutor de Tecnologia de Orientao a Objetos, UML e Linguagem Java na Sun Microsystems e na IBM. Conheo Mtodos geis (SCRUM, Lead, FDD e XP), Arquitetura de Software, SOA (Arquitetura Orientado a Servio), RUP/UP Processo Unificado, Business Intelligence, Gesto de Risco de TI entre outras tecnologias. Sou professor de curso de MBA da Fiap e fui professor de ps-graduao da Fasp e IBTA. Possuo fortes conhecimentos de Gesto de Negcio (Inteligncia de Negcio, Gesto por Processo, Inovao, Gesto de Projetos e GRC Governance, Risk and Compliance), SOX, Basel II e PCI; E experincia na implementao de Governana de TI e Gerenciamento de Servios de TI. Conhecimento dos principais frameworks e padres: ITIL, Cobit, ISO 27001 e ISO 15999; Desempenhei diversos papis como: Estrategista de Negcio, Gerente de Negcio, Gerente de Projeto, Arquiteto de Software, Projetista de Software e Analista de Sistema em diversos segmentos: Financeiro, Telecomunicaes, Seguro, Sade, Comunicao, Segurana Pblica, Fazenda, Tecnologia, Varejo, Distribuio, Energia e Petrleo e Gs. Possuo as certificaes: 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; Sou membro do IIBA-International Institute of Business Analysis (Canada) Onde estou: Twitter: http://twitter.com/rildosan Blog: http://rildosan.blogspot.com/
Verso 27
339

Marcas Registradas:
Todos os termos mencionados e reconhecidos como Marca Registrada e/ou comercial so de responsabilidade de seus proprietrios. O autor informa no 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, no visando ao lucro, favorecimento ou desmerecimento do produto/fabricante.
Melhoria e Reviso:
Este material esta em processo constante de reviso e melhoria, se voc encontrou algum problema ou erro envie um e-mail ns. Criticas e Sugestes: Ns estamos abertos para receber criticas e sugestes que possam melhorar o material, por favor envie um email para ns.
Imagens: Google, Flickr e Banco de Imagem.
Rildo F dos Santos (rildo.santos@etecnologia.com.br)

340
Licena: Capacitao Engenharia de Software
Verso 27
341
Rildo F Santos
rildo.santos@etecnologia.com.br rildo.santos@companyweb.com.br
Verso 27 Verso 27 |
Twitter: @rildosan Blog: http://rildosan.blogspot.com/ Todos os direitos reservados e protegidos 2006 e 2007

Analise e Desenho Orientado A Objetos Com UML

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Analise e Desenho Orientado A Objetos Com UML

Enviado por

Direitos autorais:

Formatos disponíveis

Anlise e Desenho Orientado a Objetos com UML

Capacitao Engenharia de Software

Rildo F Santos (rildo.santos@Companyweb.com.br)

Anlise e Desenho Orientado a Objetos com UML

Anlise e Desenho Orientado a Objetos com UML

Capacitao Engenharia de Software

Rildo F Santos (rildo.santos@Companyweb.com.br)

Todos os direitos reservados e protegidos 2006 e 2007

Anlise e Desenho Orientado a Objetos com UML

Capacitao Engenharia de Software

Principais Conceitos da Orientao a Objetos e UML

Anlise e Desenho Orientado a Objetos com UML

Capacitao Engenharia de Software

Orientao a Objetos. Principais Conceitos:

Polimorfismo, Encapsulamento, Associao e Interface.

Anlise e Desenho Orientado a Objetos com UML

Capacitao Engenharia de Software

Orientao a Objetos. Principais Conceitos: Introduo. Desenvolvimento de Software Orientada a Objetos

Anlise e Desenho Orientado a Objetos com UML

Capacitao Engenharia de Software

Orientao a Objetos. Principais Conceitos:

Anlise e Desenho Orientado a Objetos com UML

Capacitao Engenharia de Software

Orientao a Objetos. Principais Conceitos:

Rildo F Santos (rildo.santos@Companyweb.com.br)

Todos os direitos reservados e protegidos 2006 e 2007

Anlise e Desenho Orientado a Objetos com UML

Capacitao Engenharia de Software

Orientao a Objetos. Principais Conceitos:

Rildo F Santos (rildo.santos@Companyweb.com.br)

Todos os direitos reservados e protegidos 2006 e 2007

Anlise e Desenho Orientado a Objetos com UML

Capacitao Engenharia de Software

Orientao a Objetos. Principais Conceitos:

Rildo F Santos (rildo.santos@Companyweb.com.br)

Todos os direitos reservados e protegidos 2006 e 2007

Anlise e Desenho Orientado a Objetos com UML

Capacitao Engenharia de Software

Orientao a Objetos. Principais Conceitos:

Rildo F Santos (rildo.santos@Companyweb.com.br)

Anlise e Desenho Orientado a Objetos com UML

Capacitao Engenharia de Software

Orientao a Objetos. Principais Conceitos:

cor nmero chassi ano-fabricao

Anlise e Desenho Orientado a Objetos com UML

Capacitao Engenharia de Software

Orientao a Objetos. Principais Conceitos:

Carro cor nmero chassi ano-fabricao acelerar parar

O que uma classe ?

Rildo F Santos (rildo.santos@Companyweb.com.br)

Todos os direitos reservados e protegidos 2006 e 2007

Anlise e Desenho Orientado a Objetos com UML

Capacitao Engenharia de Software

Orientao a Objetos. Principais Conceitos:

Pessoa nome idade getNome() getIdade() setNome() setIdade()

Nome da Classe Atributos

Rildo F Santos (rildo.santos@Companyweb.com.br)

Todos os direitos reservados e protegidos 2006 e 2007

Anlise e Desenho Orientado a Objetos com UML

Capacitao Engenharia de Software

Orientao a Objetos. Principais Conceitos:

Legenda: 1 Objeto no mundo real 2 Classe Livro 3 Objeto da classe Livro

Rildo F Santos (rildo.santos@Companyweb.com.br)