Analise e Desenho Orientado a Objetos Com UML

Análise e Desenho Orientado a Objetos com UML e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C

o s L o h t M n e j e U s b e O D a m o e c o e s d i a l t á n n e A i r O

Rild Ri ldo o F Sant Santos os [email protected] [email protected]

Twitter: @rildosan Blog: http://rildosan.blogspot.com/


Conteúdo Parte 1 - Principais Conceitos Conceitos da Orientação Orientação a Objetos Objetos e introdução introdução UML Parte 2 – Especificação de Requisitos de Software Parte 3 – Analise Conceitual (design ) do Modelo de Especificação de Software Parte 4 – Desenho (design Parte 5 – Arquitetura de Software


Principais Conceitos da Orientação a Objetos e UML Objetivo desta parte: É apresentar e discutir os principais conceitos da Orientação a Objetos e fazer uma breve introdução a UML


Orientação a Objetos. Principais Conceitos: Objetivo

Objetivo: Apresentar os principais conceitos da orientação a objetos. Será demonstrado os seguintes conceitos: Classes, Objetos, Atributos, Métodos, Abstração de Dados, Herança,

Polimorfismo, Encapsulamento, Associação e Interface.


Orientação a Objetos. Principais Conceitos: Introdução. Desenvolvimento de Software Orientada a Objetos Influência escolha da Ferramentas

Ferramentas e Artefatos

Tecnologia OO

Atividades Suporte as atividades

WorkFlows

Metodologia/Fases Jacobson pyramid “rational enterprise philosophy”


Orientação a Objetos. Principais Conceitos: Objetos do Mundo Real Bem, podemos encontrar várias definições para o termo “objeto”, neste momento podemos entender que: “Objeto pode ser qualquer coisa na natureza que possua características e comportamentos” comportamentos”

Veja alguns exemplos de objetos:

Pessoa

Cão

Partida de Futebol

Barco

Os objetos podem ser físico (aqueles que podemos pegar, exemplos: uma pessoa, um animal, um barco, um livro, um carro, uma casa e etc ) e os conceituais (aqueles que não podemos pegar, tais como: cobrança de IOF, IOF , uma ligação telefônica, telefônica, uma conta corrente e etc...)


Orientação a Objetos. Principais Conceitos: Objetos do Mundo Real Objetos O termo orientação a objetos significa organizar o mundo real como uma coleção de objetos que incorporam estrutura de

Classes Objetos Atributos Métodos Abstração de Dados Herança Polimorfismo Encapsulamento Interface

dados (propriedades ou características) e um conjunto de operações que manipulam estes dados.

Objeto: Pessoa

Objeto: Pássaro

Propriedades

Operações

Nome Data de Nascimento Massa (peso) Altura

Andar Correr Trabalhar Chorar Dançar

Propriedades

Operações

Espécie Cor das penas Tamanho Peso

Andar Correr Voar Pousar


Orientação a Objetos. Principais Conceitos: Objetos do Mundo Real Os objetos tem um identificador único (que podemos chamar de nome do objeto), tem conjunto de propriedades (que podemos chamar de características e/ou atributos) e comportamentos (que podemos chamar de operações).

Atributos cor Número chassi

Identificador

Carro

Ano-fabricação

Operações acelerar O que são operações ? - Cois Coisas as que objet objetoo deve saber fazer

parar


Orientação a Objetos. Principais Conceitos: Objetos do Mundo Real Quando atribuímos valores aos objetos, ou seja, as propriedades (atributos), podemos dizer que ele tem um estado

Atributos cor

branco

Número chassi VW1003G345 Ano-fabricação 1966

Identificador

Carro

Operações acelerar parar

estado


Orientação a Objetos. Principais Conceitos: Objetos do Mundo Real Os nomes dos objetos geralmente são substantivo no singular, tais como, cliente, conta-corrente, pessoa e etc. Os atributos também são substantivos, exemplo: cor, tamanho, peso, idade, número e etc. Já as operações usualmente são verbos, como: acelerar, validar, validar, verificar, verificar, calcular e etc

Atributos cor

Substantivo

branco


Identificador

Carro

Operações acelerar verbos

parar


Orientação a Objetos. Principais Conceitos: Objetos do Mundo Real Modelagem de objeto:

Identificador

Carro

Nome (identificador) Representação na Orientação a objetos

Carro

Atributos cor

branco


cor número chassi ano-fabricação acelerar parar

Propriedades (atributos)


Operações


Orientação a Objetos. Principais Conceitos: Objetos do Mundo Real Modelagem de objeto:

Carro cor número chassi ano-fabricação acelerar parar Representação na Orientação 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 ” (espécie) da classe. As classes são “blueprint ” (projeto) para os objetos. São fôrmas de objetos.

O que é uma classe ?


Orientação a Objetos. Principais Conceitos:

Classe Classes Objetos Atributos Métodos Abstração de Dados Herança Polimorfismo Encapsulamento Interface

Definição de Classe: Uma classe descreve descreve um conjunto de objetos que compartilham compartilham os mesmos atributos, operações, métodos, relacionamentos e semântica As classes são as partes mais importantes de qualquer sistema orientada a objetos. Usamos as classes para capturar o vocabulário do sistema que está em desenvolvimento. Essas Essas classes podem incluir abstrações que são parte do domínio do domínio do problema, assim como as classes que fazem uma implementação. Podemos usar ainda as classes para representar itens de software, de hardware hardware e até itens que sejam somente conceituais. Exemplo: A classe classe Pessoa deverá ter atributos e métodos comuns comuns

Nota: Dicionário Aurélio Em programação ou modelagem orientada a ob jetos (v. orientação a objetos), categoria descritiva geral, que abrange o conjunto de objetos que compartilham uma ou mais características quanto a seus itens de dados e procedimentos associados. 22. Lóg. Agrupamento de objetos que têm uma ou mais características em comum.

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

Nome da Classe Atributos Métodos



Classe Exemplo de Classe: 3


1

Livro

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

2

ISBN 0747551006 Titulo: Harry Potter and the Order of the Phoenix Autor: J. K. Rowling



Classe e Objeto Classe e Objeto. Exemplo: ISBN 0747551006 Titulo: O Poder da inteligência Emocional Autor: Daniel Goleman


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

Uma coleção de livros pode ser representada por uma classe chamada Livro.

Cada livro desta coleção é “instance” (objeto) da classe livro.



Classe e Objeto Classe e Objeto. Exemplo:

Identificador

Carro

Atributos cor

branco

Classe (Modelo)

Objeto (“instance”)

Carro

fusca:Carro

cor número chassi ano-fabricação

cor=“branco” número chassi=“VW1003G345



Acelerar() parar()

ano-fabricação=1966



Classe e Objeto Classe e Objeto. Exemplo:

Classe Classes Objetos Atributos Métodos Abstração de Dados Herança Polimorfismo Encapsulamento Interface

Cliente nome cpf idade

Objetos Cliente: clientemulher nome = Marina cpf = 022.200.708-12 idade = 16

Cliente: clientehomem clientehomem nome = Felipe cpf = 039.217.908-22 idade = 42



Classe, Responsabilidade e Colaboração Responsabilidades Definição de Responsabilidades: Responsabilidades: Um contrato ou obrigação em tipo ou de uma classe


Ao criar uma classe você estará criando uma declaração de que todos os objetos dessa classe têm o mesmo tipo de estado e o mesmo tipo de comportamento. Em nível mais abstrato, esses atributos e operações são apenas as características com quais as responsabilidades das classes executadas. Uma classe chamada de Transação de Pagamento tem a responsabilidade pelo conhecimento das informações inerente a operação, tais como número da transação, situação, valor, valor, data, tipo de pagamento e etc.

Responsabilidades

TransacaoPagamento numero valor data situação TipoPagamento Responsabilidade: -- Saber o número número da transação, data, valor -- Conhecer Conhecer o tipo tipo de pagamento...



Classe, Responsabilidade e Colaboração Colaboração:


Definição de Colaboração: Ás vezes uma classe precisa colaborar com outra classe para cumprir suas responsabilidades responsabilidades A classe classe Transação de Pagamento tem a responsabilidade responsabilidade pelo conhecimento das seguintes informações: número da transação, situação, valor, valor, data, tipo de pagamento e etc. As informações sobre tipo de pagamentos estão outras classes que tem dados especifica para cada tipo tipo de pagamento. Exemplo: CartaoCredito CartaoCredito e BoletoBancario. Desta forma precisamos ter uma colaboração entre as classes para atender as responsabilidades. TransacaoPagamento numero valor data situação TipoPagamento Responsabilidade: -- Saber o número número da transação, data, valor -- Conhecer Conhecer o tipo tipo de pagamento...

CartaoCredito

Colaboração

BoletoBancario



Classe, Responsabilidade e Colaboração Classes, Responsabilidades e Colaboração:


As responsabilidades são apenas texto em formato livre. Na prática uma única responsabilidade pode ser escrita como expressão, ou uma oração ou breve parágrafo. O CRC (Cartão de Responsabilidade e Colaboração) é técnica para capturar e representar as classes suas responsabilidade e colaborações. Outra técnica que pode ser usada é a Análise baseada em Caso de Uso podem ser usada.

Nome da classe Responsabilidades

Colaborações

Aluno -- Deve conhecer conhecer os dados dos aluno: Nome Número da Matricula Curso

Matricula Pessoa Curso

Cartão



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 métodos definido na sua interface) • uma identidade única

Classes Objetos Atributos Métodos Abstração de Dados Uma classe possui: • Atributos Herança • Métodos Polimorfismo • Responsabilidades (o que ela sabe fazer) Encapsulamento • Colaboração (interação com outras classes) Interface



Atributo Definindo Atributo: • É uma características (propriedade) presente no objeto. • Valor Valor de todos os atributos at ributos é igual Estado do Objeto. Objeto .

Classes • Somente atributos que são de interesse do sistema sist ema devem ser Objetos descritos na classe. Atributos Cliente nome Métodos cpf idade Abstração de Dados Herança Polimorfismo Encapsulamento Interface

atributos

Cliente: clientemulher nome = Marina cpf = 022.200.708-12 idade = 16



Método Escrevendo os métodos. Para cada atributo é recomendado escrever um par de métodos, os nomes destes métodos devem começar com setXXXX( ) e getXXX( )


Cliente codigo nome

Métodos

getCodigo() setCodigo() getNome() setNome()

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”



Método Definição de Método:


Definição: Método é a implementação de uma operação. Definição de Operação: É a implementação de serviço que pode ser solicitado por qualquer objeto da classe com a finalidade de afetar um comportamento. Chamando os métodos Para chamar um método de um u m objeto é necessário enviar uma mensagem para ele. As mensagens identificam os métodos a serem executados no objeto receptor. Por definição todas as mensagens tem um tipo de retorno . ContaCorrente conta saldo

Métodos

setDeposito() getSaldo() setSaque()



Mensagem Definição de Mensagem: Definição:


Mensagem é uma chamada de uma operação sobre um objeto, compreendendo um nome de operação e uma lista de valores de argumentos. (Rumbaugh) Um mensagem representa a requisição de um objeto remetente a um objeto receptor para este último execute alguma operação definida para sua classe. Essa mensagem deve conter informações suficiente para que a operações do objeto receptor possa ser executada



Resumo: Métodos Resumindo:

Os métodos são a implementação das operações de objetos. Os métodos são responsáveis pelo comportamento do objeto. A mudança de estado de um objeto deve ocorrer através dos métodos.

Classes Objetos Atributos Desta forma podemos dizer que os métodos “encapsulam” os Métodos atributos. Abstração de Dados Herança Polimorfismo Encapsulamento Interface



Classe Concreta e Abstrata Abstrata Temos dois tipos de classes: Concreto e Abstrato Classe concreta: São aquelas classes que podem sofrer “instance ” (criar objetos) e tem seus métodos implementados por completo.

public class Pessoa { //Atributos private String nome; private int idade; //métodos public public String String getNome(){ getNome(){ return return nome; nome; }

E a Classe abstrata ? Bem, veremos a seguir o que é uma classe abstrata...

public public void void setNome(String setNome(String nome){ this.nome = nome; } publ public ic int int getIdade(){ getIdade(){ return return idade; idade; } public public void void setIdade(int setIdade(int idade){ this.idade = idade; } }


Orientação a Objetos. Principais Conceitos: Abstração de Dados Exemplo: Um a empresa de transporte possui uma frota de veículo, esta frota é composta por caminhões, peruas e motos. Estes veículos têm algumas características c aracterísticas semelhantes semelhantes como cor, peso, tamanho e capacidade c apacidade de carga. Entretanto cada veículo possui outras características característ icas diferentes como número de eixos sistema de freio, tipo de motor e etc. A abstração de dados é utilizada neste caso para identificar todas as propriedades comuns e reuni-las em novo conjunto, isto lembra alguns princípios da matemática como fatoração. Desta forma estaríamos fazendo um melhor aproveitamento de informações que se repetem e também t ambém estamos fazendo que características diferente seja tratada de forma diferenciada.

O que é abstração de dados ?


Orientação a Objetos. Principais Conceitos: Abstração de Dados Definição de Abstração de Dados: Definição de abstração: “Habilidade mental que permite aos seres humanos visualizarem os problemas

Classes do mundo real com vários graus de detalhe, dependendo do contexto corrente do problema. (Jim Rumbaugh). Objetos Qual é a função da abstração ? Atributos A função da abstração é capturar as propriedades e os comportamentos essenciais, Métodos como se fosse uma fatoração, desta forma determina-se o que é importante e o que não é. Abstração de Dados Exemplo Herança Polimorfismo Veículo Encapsulamento Abstração Interface Navio especialização

Avião


Orientação a Objetos. Principais Conceitos: Abstração de Dados Exemplo de Abstração de Dados:

Abstração: nos ajuda a lidar com a complexidade. Classes Objetos Atributos Métodos Abstração de Dados Herança Polimorfismo Encapsulamento Interface

Exemplo Generalização

MeiodeComunicação

Carta

Telefone

Jornal

Especialização As classes Contribuinte e MeiodeComunuicação neste MeiodeComunuicação neste caso são abstratas e ambas podem representam um domínio.


Orientação a Objetos. Principais Conceitos: Abstração de Dados Abstração de Dados:


Uma classe abstrata é uma classe que: • Provê organização • Não possui “instances”, “instances”, ou seja, não possui objetos. • Possui uma ou mais operações operações (métodos) abstratas public abstract class ContaBancaria extends Object { public public ContaB ContaBanca ancaria ria() () { } protected int numerocontacorrente; public abstract int getNumeroContaCorrente(); public abstract void setNumeroContaCorrente(int numerocontacorrente); }


Orientação a Objetos. Principais Conceitos: Abstração de Dados Veja agora a classe Pessoa, que é abstrata, pois, possui um método abstrato.

public abstract class Pessoa { //métodos public abstract String getNome() getNome() public void setNome(String setNome(String nome){ this.nome = nome; }

Um método abstrato não possui implementação somente assinatura (declaração)

public int calcIdade(Date calcIdade()(Date publicabstract abstract int getIdade() getIdade d1, Date d2); public void void setIdade(int setIdade(int setIdade(int (int idade) idade) public setIdade { { this.idade = idade; this.idade = idade; } } }

Um método concreto possui implementação assinatura e implementação.



Resumo: Abstração de Dados Resumindo:


Uma classe abstrata deve ter pelo menos um método m étodo abstrato. Mas, poder ter outros métodos que não são abstrato, são os métodos concreto. Uma classe abstrata não possui “instance”

Como eu faço para usar uma classe abstrata ?

Análise e Desenho Orientado a Objetos com UML

Orientação a Objetos. Principais Conceitos: Abstração de Dados

e r a w t f o S Comparação entre Classe Abstrata e Classe Concreta e d Classe Abstrata Classe Concreta a i r a Os métodos podem ser assinados e h Os métodos devem ser somente assinados n implementados e g n Poder sofrer “instance” E Não pode sofrer “instance” o ã ç Relacionamento somente através de a Todos os tipos de relacionamentos t HERANÇA i c a p a C



Herança Definição de Herança: Definição:


Mecanismo baseado em objetos que permite que as classes compartilhem atributos e operações baseados em um relacionamento, geralmente generalização. (Rumbaugh) Uma classe derivada herda a estrutura de atributos e métodos de sua classe “base”, mas pode seletivamente: • adicionar novos métodos • estender a estrutura de dados • redefinir a implementação de métodos já existentes Uma classe “pai” ou super classe proporciona 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 Doméstico

Animal Selvagem



Herança Exemplo de Herança:


Podemos dizer que Pós- Graduação é tipo de Curso Universitário, assim como Curso de Especialização ou de Extensão.

Hierarquia de Classes Super classes

Curso Universitário

Graduação

Pós-Graduação

Sub classe

extends

Especialização

Extensão



Polimorfismo Definição de Polimorfismo: Definição:


“Polimorfismo” é uma operação que pode assumir múltiplas formas,

a propriedade segundo o qual uma operação pode comportar-se diferentemente em classes diferentes” (Rumbaugh)

O polimorfismo é o responsável pela extensibilidade em programação orientada a objetos. Promove o reúso. Exemplo:

Billhetagem

Telefone Móvel

calcularConta(telefone)

Telefone Fixo



Polimorfismo Overloading de Método


Possibilidade de reúso do nome do método para diferentes implementações, em tempo de execução, a aplicação, escolherá o método adequado para cada 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 método, o reúso do nome do método é permitido, entretanto a lista de argumentos deve ser diferente, veja o exemplo acima: o método somar é definido várias vezes, entretanto com a lista de argumentos diferente, desta forma evitaremos problemas como ambigüidade .



Polimorfismo Overridde de Método


Uma subclasse pode mudar o comportamento herdado da Superclasse, ou seja, um método herdado poderá ser modificado. Veja Veja o exemplo abaixo: Conta Bancária getSaldo()

Conta Corrente getSaldo()

Conta Poupança getSaldo()

Investimentos getSaldo()

O método getSaldo é herdado da Superclasse (Conta Bancária), Bancária), entretanto para cada tipo de Conta ele tem uma implementação diferente. Por exemplo: - Para apurar o saldo da Conta Conta Corrente saldo atual = (soma dos depósitos + saldo anterior) saques

Para a conta poupança seria saldo atual = (soma dos depósitos + saldo anterior + juros) saques

Para a conta de investimentos seria saldo atual = (soma dos aplicações + saldo anterior + juros) juros) - resgate resgatess - ir



Principais Encapsulamento Conceitos Definição de Encapsulamento: É uma proteção adicional dos dados do objeto de possíveis modificações impróprias, forçando o acesso a um nível mais baixo para tratamento do dados.


Public Operações/métodos/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 alteração



Encapsulamento Benefícios do Encapsulamento:


Benefícios - Seguran Segurança: ça: Protege os atributos dos objetos de terem seus valores corrompidos por outros objetos. - Independênc Independência: ia: “Escondendo” seus atributos, um objeto protege outros objetos de complicações de dependência de sua estrutura interna

Pessoa nome idade

setNome()

nome

getNome()

setNome() getNome() setIdade() getIdade()

setIdade()

idade

getIdade()

encapsulamento



Interface Definição de Interface: O que é interface ?


Interface é um contrato entre o cliente (classe) e uma interface. Este contrato é garantia que o métodos assinados na interface serão implementados na classe cliente. As interfaces são consideradas a forma mais pura de abstração de dados, pois, somente podemos assinar (declarar) os métodos. Podemos usa-las usa -las também para prover: - Organização Organização e padroniz padronização ação de assinatura assinatura de métodos; métodos; - Simular Simular heranç herançaa múlti múltipla pla e - Fazer Fazer relacionamento relacionamentoss de classes com com responsabilida responsabilidade de distintas. distintas.



Interface Exemplo de Interface: Representação:


<> Codigo getcodigo() setcodigo()

realização

Contrato Produto getcodigo() setcodigo()

cpf

Fornecedor getcodigo() setcodigo()

cnpj


Introdução a aOrientação Orientação Objetos. aPrincipais Objetos Conceitos:

Interface Principais Características Características de uma interface:


•Não possui implementação própria. •Ela define operações, mas não os métodos. •Uma interface especifica, usualmente, uma parte limitada do comportamento de uma classe ou componente. •Uma classe pode realizar várias interfaces.

Porque utilizar interfaces: • Reduz o acoplamento (dependência) entre classes, aumentando a sua reusabilidade. • Permite que componentes possam ter diferentes interfaces de acordo com as necessidades dos seus usuários. • Ajuda a esconder a complexidade da arquitetura de componentes. • Oferece uma forma simplificada de implementar herança múltipla.


UML. Linguagem de Modelagem Unificada

A versão da UML abordada é versão 1.5


UML. Linguagem de Modelagem Unificada Introdução Por que fazer a modelagem? Construímos modelos para compreender melhor o sistema que estamos desenvolvendo. Com a modelagem, alcançamos 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 comportamento de um sistema; 3 - Os modelos proporcionam proporcionam um guia para a construção construção do sistema; 4 - Os modelos modelos documenta documenta o sistema sistema.. O Que Que é Modela Modelagem gem Visua Visual? l?

“A Modelagem captura as partes essenciais do sistema.” (Rumbaugh)


UML. Linguagem de Modelagem Unificada Introdução O Que é Modelagem Visual? Modelagem visual significa modelar com a utilização de notações padrão. Precisamos adotar uma ferramenta, uma notação e linguagem para tal empreitada. UML (Linguagem de Modelagem Unificada) é a linguagem de modelagem é das mais populares do momento. A UML (Linguagem (Linguagem de Modelagem Unificado) é padrão mantido pelo OMG (www (www.omg.org/uml). .omg.org/uml).


UML. Linguagem de Modelagem Unificada Introdução A UML (Linguagem de Modelagem Unificada) é uma linguagem-padrão para elaboração da estrutura de projetos de software. A UML poderá ser usada para: •Visualização •Especificação •Construção de modelos e diagramas •Documentação. A UML é adequada para a modelagem de sistemas, cuja a abrangência poderá incluir i ncluir sistemas de informação corporativos a serem distribuídos a aplicação baseadas em Web e até sistemas complexos embutidos de tempo real. A UML é apenas uma linguagem e, portanto, é somente uma parte de um método para desenvolvimento de software. Ela é independente i ndependente do processo, apesar de ser perfeitamente utilizada em processo orientado a casos de usos, centrado na arquitetura, iterativo e incremental.


UML. Linguagem de Modelagem Unificada Principais Digramas: ESTÁTICOS . Diagrama de Classes . Diagrama de Objetos . Diagrama de Componentes . Diagrama de Distribuição

Modela a estrutura do sistema

DINÂMICOS . Diagrama de Casos de Uso . Diagramas de Interação - Diagram Diagramaa de Seqüênci Seqüênciaa - Diagram Diagramaa de Colaboraç Colaboração ão . Diagrama de Atividade . Diagrama de Estados

Modela o comportamento do sistema


UML. Linguagem de Modelagem Unificada Processo de Desenvolvimento:

Processo de Desenvolvimento Modelo Casos Uso de Negócio

Modelo Objetos de Negócio

Necessidades dos Visão Stakeholders

Modelo de Casos de Uso

Modelo de Classes

Análise Realização dos Casos de Uso Classes

Casos de Teste Defeitos

Desenho Classes

Componentes Script de Testes


UML. Linguagem de Modelagem Unificada A Linguagem: Linguagem = Sintaxe + semântica – syntax = rules by which language elements (e.g., words) are assembled into expressions (e.g., phrases, clauses) – semantics = rules by which syntactic expressions are assigned meanings • Notação = (UML Notation Guide) – define uma sintaxe gráfica UML • Semântica = (UML Semantics) – define uma semântica UML •


UML. Linguagem de Modelagem Unificada Elementos: Elementos estruturais: – classe, interface, colaboração, caso de uso, classe ativa, componente, nó • Elementos comportamentais: – interação, máquina de estados • Elementos de agrupamento: – pacote, subsistema •


UML. Linguagem de Modelagem Unificada Visões:

Vis Visão ão de Projeto

Visão da Implementação Codificação Montagem

Funcionalidade Vocabulário

Visão de Caso de Uso Visão do Visão da Processo Implantação Desempenho Escalabilidade Throughput Conceitual

Topologia do Sistema Distribuição Instalação Físico

Análise e Desenho Orientado a Objetos com UML e r a w t f o S e • d a i r a h n e g n E o ã ç a t i c a • p a C

UML. Linguagem de Modelagem Unificada Visões: Visão de Caso de Uso

A visão do caso de uso abrange os casos de usos que descrevem o comportamento do sistema conforme é visto pelos seus usuários finais, analista e pessoal de teste. Essa visão não especifica realmente a organização do sistema de software. Porém , ela existe para especificar as forças que determinam a forma da arquitetura do Sistema. Com a UML, os aspectos estáticos dessa visão são representados em diagramas de caso de uso, enquanto os aspectos dinâmicos são representados em diagrama de interação., interação., diagrama de gráfico de estados e diagrama de atividades Visão Visão de Projeto Projeto

A visão de projeto de um sistema abrange as classes e colaborações que formam o vocabulário do problema e de sua solução. Essa perspectiva proporciona principalmente um suporte para os requisitos funcionais do sistema, ou seja, os serviços que o sistema deverá fornecer a seus usuários finais. Com a UML, os aspectos estáticos dessa visão são captados em diagramas de classes e de objetos; os aspectos dinâmicos são captados em diagramas de interações, de estados e de atividades.



e r a w t f o Visão de Processo S e • A visão do processo abrange os “threads” e os processos que formam formam os mecanismos de d concorrência e de sincronização do sistema. Essa visão tem com objetivo principal tratar questões a i r de desempenho, à crescimento escalar e ao “ throughput” do sistema. Com a UML, os aspectos aspect os a h estáticos e dinâmicos dessa visão são capturados nos mesmos tipos de diagrama da visão do n e projeto, mas o foco voltado para as classes ativas que representam esses threads e threads e processos. g n Threads = Linhas de execução em paralelos, também conhecido como processo, estas linhas podem ser E programas ou parte. o ã ç a t i Visão de Implementação c a A visão de implementação de um sistema abrange os componentes e os arquivos utilizados p • a para a montagem e fornecimento do sistema físico. Essa visão envolve principalmente o C

gerenciamento da configuração das versões do sistema, compostas por componentes e arquivos de alguma maneira independentes, que podem ser reunidos de diferentes formas para a produção de um sistema executável.



e r a w t f o Visão de Implantação S e A visão de implantação de um sistema abrange os nós que formam a topologia topologia de hardware em d • a que o sistema é executado. Essa visão direciona principalmente a distribuição, o fornecimento e a i r a instalação das partes que constituem o sistema físico. Com a UML, os aspectos estáticos dessa h n visão são representados em diagramas de implantação; os aspectos dinâmicos são capturados em e g diagramas de interações, de gráfico de estados e diagramas de atividades. n E o Cada uma dessas visões pode ser considerada isoladamente, permitindo que diferentes ã ç participantes orientem seu foco para os aspectos da arquitetura do sistema que mais lhes a t i c interessem. Essas cincos visões também interagem entre si, por exemplo: a p Os nós na visão de implantação contêm componentes da visão de implementação que, por sua vez, a C representa a realização física de classes, interfaces, colaborações e classes ativas provenientes das visões de projeto e de processo.


UML. Linguagem de Modelagem Unificada Exemplo: de Projeto Software Orientado a Objetos:

e r a w t f o S e d a i r a unidades h n e g n E o ã ç a t i c a p a C

Use case view

Formulários

Casos de Uso

Diagrama de Seqüência e/ou Diagrama de Colaboração Diagrama de Estado Diagrama de Atividades Diagrama de Pacotes

Logical view

Diagrama de Classes

Component view

Diagrama de Componentes

Depl Deploym oymen entt view view

Diagrama de Deployment

Diagrama de Estado Diagrama de Atividades Diagrama de Pacotes


UML. Linguagem de Modelagem Unificada Big Picture. Requisitos e Análise Business Case

Coleta de Requisitos

Análise Conceitual Modelo Conceitual

Documento de Visão

Engenharia de Requisitos 4

Análise de Requisitos

Especificação de Requisitos (Visão de Caso de Uso)

Requisitos Funcionais

Glossário de conceitos

Casos de Uso

Requisitos Não Funcionais

Arquitetura Inicial


UML. Linguagem de Modelagem Unificada Introdução. Artefatos: Produtos dos Workflows Workflows de Requisitos e de Análise: Análise: Documento de d e Visão Documento de Requisitos

Requisitos Especificação de Requisitos (Casos de Uso)

Modelo Conceitual ou Modelo de Domínio

Análise

Vocabulário do Sistema Sist ema Modelo de Arquitetura Inicial


UML. Linguagem de Modelagem Unificada Big Picture. Análise & Projeto Projeto (Visão Lógica)

Análise Modelo Conceitual

Diagrama de Classes

4

ReceberPedido

4

PreencherPedido

EnviarFatura

Entrega [pedido urgent e]

[s enão] ReceberPagamento


Entregadurante a noite

: visitante

: FormBusca

: Ca Ca et go ir a

: Po r du ot

EntregaRegular

: Ca a t ol go

getDescricao() exibirCategoria() selecionarCategoria

exibirProduto()

selecionarProduto()

getDescricao()

getQuantidade()

EncerrarPedido



Projeto Principais Produtos (Artefatos): Diagrama Diagr ama de de Sequênci Sequência a / Colaboraç Colaboração ão Diagrama de Atividades Diagrama de Estados

Diagrama de Classes


UML. Linguagem de Modelagem Unificada Big Picture. Projeto &Arquitetura Projeto (Visão Lógica)

Arquitetura Projeto (Visão de Componentes e Visão de Deployment)

Diagramas

4

ReceberPedido

: visitante

: FormBusca

: Ca Ca et go ir a

: Pr Pr od ut o

PreencherPedido

: Ca a t ol go

EnviarFatura

getDescricao()

Entrega

exibirCategoria() selecionarCategoria

getDescricao()

[ pedi do urgente]

[ senão]

getQuantidade()

ReceberPagamento

exibirProduto()

selecionarProduto()


EntregaRegular

EncerrarPedido

Diagrama de Componentes Diagrama de Deployment



Arquitetura Principais Produtos (Artefatos): Diagrama de Componentes Diagrama de Distribuição(Deployment) Distribuição(Deployment) Modelo de Arquitetura


Especificação Especificação de Requisitos de Software Objetivo desta parte: É apresentar e discutir o Ciclo de Requisitos de Software: – Elicitação, Análise, Análise, Especificação de Requisitos de Software com Caso de Uso

Introdução


Análise de Requisitos: Introdução e Um entendimento completo dos requisitos de software é essencial para um o sucesso do r desenvolvimento do software. Não importa quão bem projetado ou quão bem codificado a w seja, um programa mal analisado e especificado frustrará o usuário. t f Análise de requisitos é um processo de descoberta, refinamento, modelagem e o S especificação. e d O escopo do software, inicialmente i nicialmente estabelecido pelo Analista de Sistemas e refinado a i durante o planejamento do projeto de software, é aperfeiçoado em detalhes. r a Modelos, diagramas, fluxos são criados para melhor compreensão do problema. h n O analista e o usuário desempenham um papel ativo na análise e especificação de e requisitos. g n E O cliente (usuário) tenta reformular um conceito de função e desempenho de software, às o ã vezes nebuloso, sem detalhes concretos. O analista age como indagador, consultor e ç solucionador de problemas. a t i Entretanto, a análise e especificação de requisitos pode parecer uma tarefa relativamente c a simples, mas as aparências enganam. O grau comunicação é elevado. Daí, surgem as p oportunidades de interpretações errôneas e informações falsas. A ambigüidade é provável. a C

O dilema com o qual se depara um analista pode ser mais m ais bem entendido, repetindo-se a declaração de um cliente anônimo:

“Sei que você acredita que entendeu o que acha que eu disse, mas não estou certo que percebeu que aquilo que ouviu não é o que eu pretendia dizer...”


Ferramenta de Desenvolvimento de Software Big Picture. Requisitos Business Case



Documento de Visão






Casos de Uso

Restrições


Arquitetura Inicial


Workflow Requisitos

Requisitos Workflow

Arquitetura

Artefatos

Papéis

Documento de Visão

Documento de Requisitos

Especificação de Requisitos (Casos de Uso)

Analista de Sistema Analista de Requisitos


Da perspectiva da engenharia de software, a “ elicitação” de requisitos é talvez a mais parte mais critica do processo de desenvolvimento de software. Estudos indicam que os requisitos, só detectados depois do software implementado ou erros na análise de requisitos, são até 20 vezes mais caros de se corrigir que qualquer outro tipo de erro.


Requisitos e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C

Definições de requisito (segundo IEEE) 1) Uma condição ou uma capacidade de que o usuário necessita para solucionar um problema ou alcançar um objetivo. 2) Uma condição ou uma capacidade que deve ser alcançada ou possuída por um sistema ou componente do sistema, para satisfazer um contrato, um padrão, uma uma especificação ou outros documentos impostos formalmente. 3) Uma representação documentada de uma condição ou capacidade, conforme os itens (1) e (2).


Requisitos

Requisitos. Road Map

e r a w t f o S e d Regras de negócio a i r a h n e g n E Usuários e Clientes o ã ç a t i c a p a C Documentos

Fazer identificação e elicitação de requisitos Documento de Visão

Fazer Análise de Requisitos

Fazer Especificação de Requisitos


Fazer Validação de Requisitos Documento de Especificação de Requisitos


Requisitos

Identificação e elicitação de Requisitos: Por que o “elicitação” é importante:

O sucesso no desenvolvimento de um projeto de software depende basicamente basicamente da elicitação de requisitos, pois, é a base que permitirá ao Analista tirar conclusões sobre as situações, problemas ou fenômenos e, assim, sugerir propostas que possam contribuir para a solução do problema. Entretanto, esta atividade, nem sempre está presente no processo de desenvolvimento, raramente ela é elaborada de forma metodológica, geralmente tem uma abordagem intuitiva. Principais características de uma “boa elicitação de requisitos”:

• Definir as técnicas de coleta de requisitos baseadas em fatores operacionais, táticos e financeiros; • Criar um planejamento com objetivo de alcançar as metas estabelecidas, tais como: Prazos, Custos e Qualidade; • Promover a integração e o comprometimento de todos os envolvidos no processo, por exemplo: Clientes, Fornecedores, Usuários e o Patrocinador. Patrocinador. • Identificar os documentos e procedimentos que definem as políticas de negócios da empresa.

Uma Simples Comparação: Elicitação Boa

Elicitação Ruim

Bom Diagnóstico

Diagnóstico ineficiente

Soluções eficientes

Soluções medíocres

Satisfação dos usuários Melhoria dos processos e redução de custo

Insatisfação dos usuários Problemas operacionais e financeiros


Requisitos

Identificação e elicitação de Requisitos: Documento (Artefato) desta etapa: “ Documento de Visão”

Participantes: Analistas e Especialista em Negócios Participantes: Usuário, Clientes, Fornecedores e Patrocinadores

reuniões

documentos

identificação/ elicitação de Requisitos entrevistas

Objetivo: Descrever a visão inicial do software Documento de visão


Requisitos

e r a w t f o As fases da Identificação/Elicitação de Requisitos: S e d Um projeto de elicitação de requisitos têm as seguintes fases: a i r a h n Como deve ser feito ? Planejamento e g n E o Elicitação de ã O que devo coletar ? ç Requisitos a t i c a p a Documentação C Como devo documentar ?

Identificação e elicitação de Requisitos:

Identificar Fontes Técnicas Identificar Funcionalidades Identificar Restrições e Riscos

Documento de Visão


Requisitos

Identificação e elicitação de Requisitos: As informações podem ser identificadas ou encontradas em diversas fontes: - Usuári Usuários; os; - Docume Documento ntos; s; - Especificaç Especificações; ões; - Client Clientes; es; - Patrocinado Patrocinadores; res; - Analista de Negócios (“Domain Domain Expert Expertss” - Especialis Especialista ta em em uma ou ou mais mais área de negócio) negócio) Quais são as técnicas ? Existem várias técnicas, todas elas possuem seus próprios conceitos, vantagens e desvantagens, que podem ser usada nesta atividade entre elas estão: - Reuniõ Reuniões; es; - Entrev Entrevist istas; as; - Questi Questioná onário rios; s; - Work Worksh shop op;; - Brains Brainstor tormin ming; g; - JAD (Join Applica Application tion Developm Development ent)) - Fast Fast; ; - Docume Documento ntos; s; - Sistemas Sistemas Legados. Legados.



e r a w t f o Identificação dos Requisitos: Tipos de Requisitos S Os Requisitos de Software podem ser divididos em duas categorias: e d a Requisitos i r a h n e g Requisitos Requisitos n E Funcionais Não-Funcionais o ã Os requisitos não funcionais dizem respeito as ç Os requisitos funcionais descrevem o que o a sistema deve fazer, isto é, as funções características que descrevem qualidade do serviço t i (QoS). QoS). c (funcionalidades) necessárias para atender os a objetivos. O que sistema deve saber fazer. A omissão ou esquecimento desses requisitos constitui p uma das principais razões de uma eventual a Exemplos: Buscar cliente, Registrar pedido insatisfação dos usuários com relação a um software. C Calcular conta de consumo, Calcular tributos e

Identificação e elicitação de Requisitos:

etc.

Os Requisitos Não Funcionais (RNF) também são chamamos de “Requisito Suplementares.” Exemplos: performance, disponibiliade, confiabilidade, segurança, usabilidade e etc.


Requisitos

Identificação e elicitação de Requisitos: Identificação dos Requisitos: Os requisitos de software podem ser identificados no texto da “ declaração declaração do problema ” (geralmente são verbos que identificam algumas ações).

Este documento possibilita a identificação, extração e classificação dos requisitos - Requisitos Requisitos funcionais funcionais e - Requisitos Requisitos não não funcionais funcionais..

Texto da Declaração do Problema


Requisitos

Identificação e elicitação de Requisitos: Documento de Visão: Objetivo: Fazer uma descrição da visão da solução Este documento tem as seguintes seções: -Entendimento do Problema; - Lista dos Stakehol Stakeholders ders - Lista dos Requisi Requisitos tos - Lista Lista dos Risc Riscos os - Lista das Restriç Restrições ões

Exemplo: Documento de Visão: Data: ________ | Autor: ________ | Revisão: Revisão: ____ Índice: 1.0 - Introd Introduçã ução o 1.1 Objetivo do documento 1.2 Escopo 1.3 Abreviaturas, Abreviaturas, Siglas e etc. 2.0 Entendimento do Problema (Contexto) 2.1 Declaração do Problema 2.2 Diagrama de Contexto 3.0 Lista de Stakeholders 3.0 Usuários 3.1 Entidades 4.0 Lista dos Requisitos 4.1 Requisitos funcionais 4.2 Requisitos não funcionais 5.0 Lista dos Riscos 6.0 Lista das Restrições 6.1 Software 6.2 Hardware 6.3 Ambiente e Tecnologia


Requisitos e r a w t f o S e d Regras de negócio a i r a h n e g n E Usuários e Clientes o ã ç a t i c a p a C Documentos

Requisitos. Road Map Fazer identificação e elicitação de requisitos Documento de Visão






Requisitos

e r a w t f A análise de requisitos procura sistematizar o processo de definição de requisitos. o c omplexidade dos sistemas exige que se preste mais S Essa sistematização é necessária porque a complexidade e atenção ao correto entendimento do problema antes do comprometimento de uma solução. Uma d definição para requisitos é apresentada a seguir. a O Documento de Visão é um artefato importante na Análise i Análise de Requisitos, destacamos algumas r a razões: h - Da perspectiva da engenharia de software, a elicitação de requisitos é talvez a mais parte mais mais critica n e do processo de desenvolvimento de software. g n A Análise de Requisitos deve ser: E Correta: Quando cada requisito expresso nela for encontrado no software; o Correta: ã ç Ambígua: Cada requisito deve ter somente uma interpretação (definição); a Não Ambígua: t i c Completa: Quando incluir todos os requisitos significativos relacionados as funcionalidades e requisitos a Completa: p relacionados a qualidade do serviço (também conhecidos como requisitos não funcionais) a C

Análise de Requisitos: Introdução

Consistente: Consistente: Quando não existir conflito entre os requisitos;

Verificável: Verificável : Quando for possível verificar/validar cada requisito; Modificável: Modificável: Quando os requisitos podem ser facilmente alterados.


Requisitos

Análise de Requisitos Atividades da Análise de Requisitos

A análise de requisitos possibilita que o Analista de Sistemas especifique as funcionalidades, classificando e detalhando os requisitos encontrados na coleta. Os requisitos funcionais serão descritos em detalhes. E os requisitos não funcionais serão classificados.

Detalhar os Requisitos Funcionais Classificar os Requisitos não Funcionais Descrever os Usuários e Entidades Externas Fazer Plano de Redução de Risco



Requisitos

Análise de Requisitos. Detalhar Requisitos Funcionais: Os requisitos funcionais devem ser detalhados. Devemos usar um formato padrão para esta atividade. Veja o exemplo: Lista de Requisitos funcionais Autor:

Nome

Revisão:

Código

Data Atualização:

Descrição

Fazer Reserva RF01E Esta funcionalidade deverá permitir o usuário (funcionário) a fazer reserva de apartamentos, as ações que estarão disponíveis são: criar, remover, alterar e consultar reservas. Cada reserva deverá ter um cliente e um apartamento e respectiva período)


Requisitos

Análise de Requisitos. Detalhar Descrição das Regras de Negócio Nome do Projeto Objetivo

id RN01

Serviço de Atendimento e Reserva de Apartamento Descrever todas as regras de negócio para para o serviço de atendimento e reserva de apartamentos.

Nome da Regra Registrar Reserva de Apartamento

Descrição da Regra de Negócio A confirmação do registro de reserva de apartamento deve ocorrer após o pagamento de 25% do valor da estadia. Os clientes AA (pessoas que hospedaram no hotel mais de 10 dias por ano) tem preferência de data e tipo de apartamento. No período de baixa a estação (de mar a jun e ago a nov) o valor da diária tem um desconto de 40%. Para que agilizar o atendimento manter a satisfação do cliente as consultas de reserva devem ser feitas em no máximo 30 segundos. Data

Os código permitem a rastreabilidade

01/01/08

Nome / Equipe RFS

Versão

Status

2.1

Vigente

Requisitos Funcional RN: RN01 Nome: Reserva

Descrição: Serviço de Atendimento e Reserva de Apartamento

ID

Nome

Descrição

RFC01

Registrar Reserva de Apartamento

Esta funcionalidade funcionalidade deverá permitir o usuário (funcionário) a fazer reserva de apartamentos, as ações que estarão disponíveis são: criar, cancelar, alterar e consultar reservas.


Requisitos

Análise de Requisitos. Classificar Requisitos Não Funcionais: Agora vamos descrever os Requisitos Não Funcionais. Entretanto, precisamos categorizar estes requisitos, as mais frequente são: - Performance: Tempo de resposta - Segurança: Uso de senhas, certificados digitais e etc.. - Usabilidade: Identidade Visual e Interfaces amigáveis - Disponibilidade: O software deve estar disponível para usuário 24x7. Exemplo: Tolerância a falha - Flexib Flexibilid ilidade ade:: Capacidade de adaptação quando um requisito muda - Portabilidade: Capacidade de se adaptar a outros ambientes (sistemas operacionais) - Escalabilidade: Capacidade de responder aumento de carga (novos usuários) Outras categorias como Integração, Processamento, Manutenível e etc.


Requisitos

Análise de Requisitos. Classificar e Detalhar Requisitos Não Funcionais: Bem vamos descrever os requisitos não funcionais. Como na descrição dos Requisitos funcionais, precisamos ter um padrão Lista de Requisitos Não funcionais Categoria: Performance Autor: Req. Funcional

Fazer Consulta

Revisão:

Data Atualização:

Código

Descrição

RNFP1

As consultas que serão realizadas pelo cliente não poderão exceder ao tempo de resposta de 15 segundos Por que preciso de um código ? Este código tem como objetivo facilitar a “rastreabilidade”.

Ele pode ser usado no Formulário de Caso de Uso, por exemplo, desta forma conseguiremos identificar qual é o caso de uso que realiza este RNF, RNF, no caso de mudanças.


Requisitos

Análise de Requisitos. Classificar e Detalhar Requisitos Não Funcionais: Continuação: Lista de Requisitos Não funcionais Categoria: Usabilidade Autor:

Revisão:

Data Atualização:

RF / Aplicação

Código

Descrição

Aplicação

RNFU1

As cores, as fontes e logotipos devem seguir o Manual de Identidade Visual da empresa.

Aplicação

RNFU2

As interfaces com usuário devem seguir padrão de interfaces estabelecido pelo Manual de Sistema


Requisitos

Análise de Requisitos. Detalhar Lista de Stakeholders: Precisamos descrever todos as pessoas e/ou organização que influenciam a tomada de decisão decisão ou participam participam direta direta ou indiretament indiretamentee do processo processo de de construçã construçãoo do softwar software. e. Mais uma vez criaremos um formato padrão. Veja o exemplo: Lista de Stakeholders Autor:

Revisão:

Data Atualização:

Nome

Descrição

Cliente

São todas as pessoas físicas ou jurídicas que fazem reservas

Colaborador

É qualquer pessoa que presta algum tipo serviço para empresa


Requisitos

Análise de Requisitos. Detalhar Lista de Stakeholders: Continuação: Lista de Entidades Externas Autor:

Revisão:

Data Atualização:

Nome

Descrição

Administradora de Cartão de Crédito

Entidade que faz validação de um cartão de crédito presente em transação de pagamento.

Plano de Redução de Riscos: Precisamos elaborar um Plano de Redução de Risco, para os risco que já foram identificados. Este plano deve detalhar como mitigar os riscos identificados.


Requisitos

Análise de Requisitos. Artefato Documento de Requisitos: Objetivo: Classificar, Classificar, descrever os requisitos de software, usuários e entidade externas e elaboração do plano de redução de risco. Este documento tem as seguintes seções: - Requisitos Requisitos Funcio Funcionais nais - Requisito Requisitoss Não Funcionais Funcionais - Lista dos Stakehol Stakeholders ders - Plano de Redução Redução de de Risco

Exemplo:Documento Exemplo:Documento de Requisitos:

Data: ________ | Autor: ________ | Revisão: ____ Índice: 1.0 - Introd Introduçã ução o 1.1 Objetivo do documento 1.2 Escopo 2.0 Requisitos Funcionais 3.0 Requisitos Não Funcionais 4.0 Lista Stakeholders 4.1 Usuários 4.2 Entidades 5.0 Plano de Redução de Riscos





Fazer Fazer Especificação de Requisitos (Casos de Uso)




Requisitos

Especificação de Requisitos: O produto que devemos ter após Análise de Requisitos é a “ A especificação de Requisitos” é feita através de Casos de Uso, Uso, conforme definido pela UML. Um conjunto de casos de uso é importante para se compreender o que o usuário quer. quer. Um caso de uso descreve uma funcionalidade (“requisito”) a ser oferecida pelo sistema, ou seja, um serviço.

Documento de Visão

o ã s N i s a n o o t i i c s n i u u q e F R

s s o i a t i n s o i i u c q e n u R F

Documento de Requisitos Especificação de Requisitos Comportamento externo

Casos de Uso

Comportamento interno

Seqüência

Estrutura Implementação

Classes Distribuição

Modelo de Arquitetura do Software Colaboração


Requisitos

Especificação de Requisitos Análise de Casos de Uso: •Casos de uso expressam o diálogo entre os usuários e o sistema •Casos de uso expressam “o quê” o sistema deverá fazer. E não “ como” fazer. •Casos de uso formam a base para testes e documentação do sistema •O modelo de casos de uso expressam todos os casos de uso do sistema s istema e os seus relacionamentos. •As técnicas para criar e expressar casos de uso em uma aplicação Web são as mesmas para construir outros sistemas de software.

Objetivos: • • • •

Identificar os atores; Identificar os casos de uso; Desenhar os casos de uso e Escrever cenários.


Requisitos

Especificação de Requisitos Transformar os Requisitos Funcionais em Casos de Uso:

Calcular Total

Cliente

Fazer Cadastro Funcionário Fazer Pedido Emitir NF


Requisitos

Especificação de Requisitos Atividades e Passos: Fazer Diagrama de Casos de Uso Identificar Atores Atores / Casos de Uso Escrever cenários Escrever Formulário Fazer Diagrama de Caso de Uso

Rational Rose


Requisitos

Casos de Uso Introdução: Caso de Uso é uma representação gráfica e semântica da interação do usuário e o sistema. sist ema. Os diagramas de caso de uso são usados para capturar os requisitos funcionais do sistema. Ajuda o entendimento do contexto dos requerimentos do sistema. Os casos de uso podem ser agrupados em pacotes, desta forma temos uma organização funcional. O que são Caso de Uso? São diagramas de que permitem visualizar, visualizar, especificar especificar e documentar o comportamento de um elemento. Esses diagramas fazem fazem com que sistema, subsistemas e classes fiquem acessíveis e compreensíveis, por apresentarem uma visão externa sobre como esses elementos interagem com sistema. Definição: Caso de Uso é uma descrição de um conjunto de seqüências de ações, inclusive variantes, que um sistema pode produzir um resultado de valor observável por um ator. A representação gráfica é uma elipse. Caso de Uso

Gerenciar Reserva

Ator

Usuário

Nome

Os nomes de casos de uso são breves expressões verbais ativas.


Requisitos

Casos de Uso Casos de Uso e Cenários: Os casos de uso exibem a funcionalidade na perspectiva do usuário. Entretanto, podemos ter vários caminhos para completar esta função. Um cenários é como uma “ instance instance ” do Caso de uso, isto é, um caminho lógico com início e fim. Principais características:

- Cenários Cenários não contém declarações declarações condicionais; condicionais; - Pode ter mesmo mesmo começo, começo, mas, com final diferente; diferente; - Um cenário é narrativa de uma situação situação e - Os cenários cenários devem descrever os bons caminhos e maus também. Exemplo: Autorização de acesso. O usuário executa a aplicação, o sistema exibe a janela de identificação que pede a identificação do usuário, ou seja, seu nome e sua senha, O usuário informa seu nome e sua senha, o sistema valida as informações e dá a autorização de acesso ao Sistema.

Se senha for invalida ou nome neste caso teremos um novo cenário.


Requisitos

Casos de Uso Casos de Uso e Fluxo de Eventos: Uso caso de uso descreve “ o quê” um sistema (ou subsistema, subsist ema, classe, ou interface) faz, ele não especifica “ como” como” isso é feito . Ao fazer uma modelagem, importante manter clara a separação de questões entre a visão interna e externa. Podemos especificar o comportamento de um caso de uso pela descrição do fluxo de eventos no texto de maneira suficientemente clara para que qualquer pessoa possa poss a entende-lo facilmente. Ao escrevermos o fluxo de eventos devemos incluir como e quando o caso de uso inicia e termina, como e quando o caso de uso interage com os atores e o fluxo básico e fluxo alternativo do comportamento. Tipos de fluxos: • Fluxo de eventos principal e • Fluxo alternativo de eventos. Tipicamente descrevemos descrevemos um fluxo de eventos para um caso cas o de uso. Os fluxos de eventos ajudam a compreensão dos requisitos do sistema, entretanto, você desejará utilizar os diagramas de interação para especificar esses fluxos graficamente. Além Além disso, você também utilizará um diagrama de seqüência para especificar o fluxo principal de um caso de uso e variação deste diagrama para especificar os fluxos excepcionais.


Requisitos

Casos de Uso Casos de Uso e Formulário: Os formulários devem ter as seguinte informações: - Ponto de ativação (momento que caso de uso começa) - Nome Nome do caso caso de uso uso - Obje Objetitivo vo - Atores Atores que participam participam do caso caso de uso - Pré-co Pré-condi ndição ção - Fluxo Fluxo Normal Normal - Fluxo Fluxo Altern Alternati ativo vo - Pós-co Pós-condi ndição ção.. Opcionalmente podemos acrescentar outros itens ao Formulário de Caso Uso . Exemplos: - Nome ou código código dos dos Requisitos Requisitos ( RN ) que estão associados a este caso de uso RN e RNF


Requisitos

Casos de Uso Exemplos de Casos de Uso:

Manter informações dos cursos

Manter informação de aluno

Gerente Manter informação de professor

Gerar catalogo

Pedir lista dos matriculados Sistema de cobrança

Matrícula nos Cursos Professor

Aluno Selecionar curso para ensinar


Requisitos

Casos de Uso Casos de Uso e Formulário Exemplo:

Produto Nome: Fazer Busca Produto Ponto de ativação: Este caso de uso começa quando entra na página de Busca e seleciona um item da caixa de seleção Ator: Visitante e Cliente Objetivo: Fazer busca de produto por categoria Pré-condição: Aplicação Disponível Fluxo Normal: 1 - O visitante visitante seleciona seleciona a página página de busca 2 - O visitante visitante seleciona seleciona a categoria para busca busca 3 - O visitante visitante informar informar o produto produto 4 - O visitante visitante pressiona pressiona o botão buscar buscar 5 - O sistema sistema processa processa a busca busca 6 - Retorna Retorna as informações informações sobre o produto produto Fluxo Alternativo: 1 - O Visita Visitante nte seleciona seleciona a página de busca 2 - O visitante visitante seleciona seleciona a categoria para busca busca 3 - O visitante visitante informar informar o produto produto 4 - O visitante visitante pressiona pressiona o botão buscar buscar 5 - O sistema sistema processa processa a busca busca 6 - Retorna as uma mensagem “produto não encontrado” Pós-condição: Busca realizada Requisito Funcional: RF002 -Fazer Busca do Produto Requisito Não Funcional: ---


Requisitos

Casos de Uso Elementos dos Caso de Uso: Ator: Um ator representa um conjunto coerente de papéis que os usuários de casos de uso desempenham desempenham quanto interagem interagem com esses casos de uso. Geralmente um ator representa um papel, que pode ser de pessoa, de um sistema ou de um dispositivo e etc... Cenários: É narrativa de determinado determinado fato ou de uma situação. “O caso de uso deve ser descrito através de cenários. Devem ser construídos tantos

cenários quantos quantos forem necessários para se entender completamente todo o sistema. Podem ser considerados como teste informais para validação dos requisitos do sistema.”

Formulário: É a representação estruturada de um ou mais cenários


Requisitos

Casos de Uso. Relacionamentos Organização dos Casos de Uso: Os casos de uso também podem ser organizados pela especificação de relacionamento de generalização, inclusão e extensão, existentes entre eles. Esses podem ser aplicados com a finalidade de fatorar o comportamento comum (obtendo esse comportamento comportamento a partir de outros casos de uso que ele inclui) e fatorar variantes (obtendo esse esse comportamento em outros casos de uso que o estendem) Generalização: Entre os casos de uso é parecida à generalização existente entre as classes. No caso de uso a generalização significa que o caso de uso filho herda o comportamento e o significado do caso de uso pai; o filho poderá acrescentar ou sobrescrever o comportamento de seu pai; poderá ser substituído em qualquer local qual o pai apareça. Include: Quando você estiver se repetindo em dois ou mais caso de uso separados devemos evitar a repetição Extends: Quando estivermos descrevendo uma variação em comportamento normal, entretanto, querendo fazer uma descrição mais controlada, explicando os pontos de extensão no caso de uso. Realizes: Especifica a colaboração entre os casos de uso * Use (obsoleto): Especifica que a semântica do elemento de origem depende da

semântica da parte pública do destino. Substituído pelo include.


Requisitos

e r a w t f o Generalização: S Podemos usar a generalização entre casos de A generalização também pode ser aplicado aos e uso, pelo mesmo motivo que utilizamos atores e seus respectivos papéis. Veja o exemplo: d a nas classes, para compartilhar comportamento: i r a h n Receber Pagamento e g n generalização Funcionário E o ã ç a t i c a p a Pagto Cartão de Crédito Pagto Cartão de Débito C

Casos de Uso. Relacionamentos

Recepcionista

Gerente de Reservas


Requisitos

Casos de Uso. Relacionamentos Extends: Podemos usa-lo para “Demonstrar Variação Variação de Comportamento”: Cada uma das extensões descreve as diferentes maneiras com que um passo do caso de uso pode ser executado. Variação Variação de Comportamento. Comportamento. Exemplo: Sala de Conferência

Locadora de Automóveis

Fazer Ligação

Devolver Veículo

<>

<>

<>

Alte lterar rar stat status us do carro rro

Cons Consul ultta Clie liente nte

Calcular Multa

Usuário <>

Fazer Ligação (Conference call)


Requisitos

Casos de Uso. Relacionamentos Explicando o estereotipo “include”

Um relacionamento de inclusão entre casos de uso significa que o caso de uso base incorpora explicitamente o comportamento de outro caso de uso em uma localização especificada na base. O caso de uso incluído nunca permanece isolado, mas é apenas uma “ instance” como parte de alguma base maior que o inclui. V Você ocê pode pensar na inclusão como o caso de uso base que o obtém o comportamento a partir do fornecedor fornecedor do caso de uso. Você utiliza utiliza um relacionamento de inclusão para evitar descrever o mesmo fluxo de eventos várias vezes, vezes, incluindo o comportamento comum em um caso de uso próprio. O relacionamento de inclusão é essencialmente um exemplo de delegação, você coleta um conjunto de responsabilidades do sistema e o captura um único local (o caso de uso incluído); depois, permite que outras partes do sistema (outros casos de uso) incluam a nova agregação de responsabilidade sempre que precisamos utilizar essa funcionalidade. Exemplos: Fazer Pedido

Fazer Fazer Check Check OUT

Fazer Fazer Check Check IN <>Validar Usuário

Acompanhar Pedido <> <>

Gerenciar Reserva

<>

Receber Pagamento


Requisitos

Casos de Uso Casos de Uso - Identificação de Atores

Os atores não fazem fazem parte do sistema - eles representam qualquer um um e qualquer coisa que faça interação com sistema. Podendo ser uma pessoa, software, hardware e etc. Uma ator pode:

- Apenas Apenas fornecer fornecer informações informações ao sistema - Apenas Apenas receber informaç informações ões do sistema - Fornecer Fornecer e receber receber informações informações ao sistema sistema

Tipicamente os atores são identificados nas Declarações de Problemas (Documento de Visão) ou através de entrevistas com os usuários e outros envolvidos no processo, como, Gerente, Especialista em Negócio, Analista de Sistema e Analista de Negócio, por exemplo. As seguintes questões podem ser usadas para identificar o atores: - Onde o sistema sistema será usado usado ? - Quais áreas áreas serão usuárias usuárias do sistema sistema ? - O sistema sistema usará recurso recurso externo externo ? - Quem será o responsá responsável vel pelo sistema sistema ? - Quem serão serão os usuários usuários do sistema sistema ?


Requisitos

e r a w t f o S Um engano comum na identificação de casos de uso é representar como Caso de uso e passos individuais, operações ou transações. d a i r Exemplo: a ponto de venda, alguém alguém pode definir um caso de uso chamado h No domínio de ponto n “Imprimindo o Recibo”, quando de fato, a operação de impressão é meramente um passo e g no processo muito mais abrangente do caso de uso Comprar Itens n E o Lembre-se: ã ç a Um caso de uso é uma descrição completa de processo, t i c que inclui outros passos ou transações. a p a C

Casos de Uso.Dicas


Requisitos

Especificação de Requisitos. Exemplo: O hotel contém um número de apartamentos disponíveis para ser alugado aos hospedes. Cada apartamento tem as seguintes propriedades: - Número, preços preços base, capacidade capacidade de pessoas - Tipo (Single, (Single, double, triplo ou suite) O preço de cada apartamento está relacionado com seu tipo e sazonalidades sazonalidades (períodos especiais, tais como: férias, natal, carnaval...) Um hospede pode fazer reserva de mais de um apartamentos através do telefone, Internet ou pessoalmente no balcão de reserva do Hotel .

1

2 Refinado pelo

   

Requisitos Funcionais • Gerenciar Reserva •...

Documento de Visão „



Requisitos

Especificação de Requisitos. Exemplo: Especificação de Requisitos: 3 Formulário

Cenários

Gerenciar Reserva

Usuário Ator

Caso de Uso Associação

Caso de Uso: Gerenciar Reserva


Requisitos

Especificação de Requisitos. Exemplo: Escrevendo os Cenários: Cenário 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 período, ou seja, data de chegado e partida, e qual tipo de apartamento ele precisa. O funcionário do Setor de Reserva, Reserva, verifica a disponibilidade do apartamento apartamento e confirma a reserva.

Cenários

Cenário 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 período, ou seja, data de chegado e partida, e qual tipo de apartamento ele precisa. O funcionário do Setor de Reserva, verifica a disponibilidade do apartamento e informa que não tem disponibilidade de apartamento apartamento para o período informado pelo cliente e oferece um outro tipo de apartamento. O cliente aceita o apartamento e então o funcionário confirma a reserva. Cenário 2: Gerenciamento de Reserva: O Setor de Reserva do Hotel recebe um telefonema de cliente que s olicita uma reserva de apartamentos para data. O cliente informa o período, ou seja, data de chegado e partida, e qual tipo de apartamento ele precisa. O funcionário do Setor de Reserva, verifica a disponibilidade do apartamento e informa que não tem disponibilidade de apartamento apartamento para o período informado pelo cliente e oferece um outro tipo de apartamento. O cliente não aceita a proposta do funcionário e a reserva não é confirmada.


Requisitos

Especificação de Requisitos. Exemplo: Escrevendo o Formulário: Compilar os Cenários em Formulário:

Cenários

Formulário

Identificando a pré-condição e pós-condição: Cenário 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 período, ou seja, data de chegado e partida, e qual tipo de apartamento Pré Pré- condiç condição ão ele precisa. O funcionário do Setor de Reserva, verifica a disponibilidade do apartamento e confirma a reserva. Pós Pós- condiç condição ão


Requisitos

Especificação de Requisitos. Exemplo: Escrevendo o Formulário: Compilar os Cenários em Formulário: Primeiras linhas do cenário

“caminho feliz”

Nome: Gerenciar Reserva Ponto de ativação: Este caso de uso começa quando o funcionário do setor de reserva recebe uma solicitação de reserva Ator: Funcionário Objetivo: Fazer reservar de apartamentos Pré-condição: Solicitação de reserva Fluxo Normal:

Gerenciar Reserva

Fluxo Alternativo:

Gerenciar Reserva

“caminho alternativo”

Pós-condição: Reserva confirmada

Última linha do cenário


Requisitos

Especificação de Requisitos. Exemplo: Escrevendo o Formulário de Descrição de Caso de Uso: Nome: Gerenciar Reserva Ponto de ativação: Este caso de uso começa quando o funcionário do setor de reserva recebe uma solicitação de reserva Ator: Funcionário Objetivo: Fazer reservar de apartamentos Pré-condição: Solicitação de reserva Fluxo Normal: O cliente informa o tipo de apartamento O cliente o período (data de chegada e partida) O funcionário do Hotel verifica a disponibilidade do apartamento O funcionário confirma a reserva

Fluxo Alternativo: ... O funcionário do Hotel verifica a disponibilidade do apartamento O funcionário faz proposta de outro apartamento para cliente O cliente aceita e então o funcionário confirma a reserva



Requisitos

Especificação de Requisitos. Exemplo: Especificação de Requisitos: 3 Formulário

Cenários

Funcionário Ator

Gerenciar Reserva

Associação

Caso de Uso: Gerenciar Reserva

Caso de Uso


Requisitos

Mitos e Lendas • Requisitos não são 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 transação deve ser 10 segundos (Desempenho)


Requisitos

Especificação de Requisitos. Exercício: Especificação de Requisitos, como fazer:

1 - Identifique quais os REQUISITOS e relacione com os CASOS DE USO; 2 - Identifique também os ATORES e seus respectivos PAPÉIS; PAPÉIS; 3 - Dê um nome para o CASO DE USO, lembre-se que este nome deve ser único no modelo; 4 - Escreva Escreva os CENÁRIOS CENÁRIOS para o CASO CASO DE USO; 5 - Compile Compile os CENÁRIOS CENÁRIOS em único FORMULÁR FORMULÁRIO IO e 6 - Faça o Diagrama Diagrama de Caso de de Uso.


Requisitos

Especificação de Requisitos. Template: Template do “Formulário”: Data: ______ | Autor: ________ | Revisão: ____ Nome: Ponto de ativação: Ator: Objetivo: Pré-condição: Fluxo Normal:

Fluxo Alternativo:

Pós-condição: RF: RNF:

Rastreabilidade









Requisitos

Validação de Requisito Requisitoss Deve preocupa-se em mostrar que os requisitos definem o sistema que o cliente/usuário deseja. Validação é importante uma vez que o custo para remover um erro de requisitos é grande.

Pequeno Check List de Requisitos: Validade. Validade. O sistema fornece as funções que melhor atende as necessidades necessi dades do usuário? Consistência. Consistência. Existem conflitos de requisitos? Todas as funções necessárias para o cliente estão incluídas? Completeza. Completeza. Todas Realismo. Realismo. Os requisitos podem ser implementados i mplementados com a tecnologia e orçamento disponíveis? Facilidade de verificação. verificação . Os requisitos podem ser checados?


Requisitos

Validação de Requisito Requisitoss Técnicas de validação de requisitos Revisão de requisitos: - Análise manual manual sistemática sistemática dos requisitos requisitos Prototipação: - Uso de um modelo executável do sistema para checar os requisitos. Geração de casos de teste: - Desenvolver testes para os requisitos a fim de verificar a “testabilidade”. Análise automatizada da consistência: - Uso de ferramenta para verificar a consistência consistência do modelo.


Requisitos

Validação de Requisito Requisitoss Técnicas de validação de requisitos Revisão de requisitos: - Revisões regulares devem ocorrer durante a formulação da definição dos requisitos - Tanto o cliente quanto a equipe contratada devem estar envolvidos nas revisões - As revisões podem podem ser formais (com documentos documentos completos) ou informais. Uma boa comunicação entre os desenvolvedores, clientes e usuários pode resolver problemas em estágios iniciais Verificação de revisões: - “Verificabilidade”. “Verificabilidade”. O requisito é realisticamente testável? - Compreensibilidade. O requisito é propriamente propriamente entendido? entendido? - Rastreabilidade. A origem do requisito é claramente estabelecida? - Adaptabilid Adaptabilidade. ade. O requisito requisito pode pode ser modificado modificado sem grande grande impacto sobre sobre outros requisitos?


Requisitos Formato do documento de especificação especificação de requisitos sugerido pela IEEE/ANSI IEEE/ANSI 830-1993: Estrutura do Documento: 1.0 Introdução 1.1 propósito do documento de requisitos 1.2 escopo do produto 1.3 definições, acrônimos e abreviações 1.4 referências 1.5 visão geral do restante do documento 2.0 Descrição geral 2.1 perspectiva do produto 2.2 funções do produto 2.3 características do usuário 2.4 restrições gerais 2.5 suposições e dependências 3. Requisitos (Específicos) os requisitos podem documentar interfaces externas, descrever funcionalidade e desempenho do sistema, especificar requisitos lógicos de banco de dados,restrições dados,restrições de projeto, características de qualidade. 4. Apêndices 5. índice


Análise Conceitual Objetivo desta parte: É apresentar e discutir a Análise Conceitual suas técnicas, conceitos e modelos.


Big Picture.

Requisitos e Análise

Business Case



Documento de Visão






Casos de Uso


Arquitetura Inicial


Workflow orkflow Analise Analis e

Analise Workflow

Arquitetura

Artefatos

Papéis


Vocabulário do Sistema Sistem a

Modelo de Arquitetura Inicial

Analista de Sistema Analista de Requisitos Arquiteto de Software


Workflow orkflo w de de Análise Introdução: Modelo de Casos de Uso de software é elaborado para dar a Visão de Caso de Uso. Esta visão fornece uma perspectiva do software a partir de um ponto de vista externo. Os aspectos dinâmicos descrevem a troca de mensagens entre os objetos e a sua reação a eventos que ocorrem no software. O aspecto dinâmico será apresentado na terceira parte, no workflow de Projetos. Visão de Funcionalidade Projeto

Visão da Implementação

Vocabulário

Funcionário

Gerenciar Reserva

Visão do

Desempenho Processo Escalabilidade Throughput

Codificação Montagem

Visão de Caso de Uso Visão da Implantação

Topologia do Sistema Distribuição Instalação

O aspecto estrutural estático permite entender como uma software está estruturado internamente para atender os requisitos (visão externa). Esse aspecto é chamado de estático porque não apresenta informações sobre como os objetos se comportam no ciclo de vida de software e também porque representa a estrutura das classes de objetos e os relacionamentos entre elas.


Workflow orkflo w de de Análise

Objetivo: Apresentar e discutir como elaborar o Modelo Conceitual Conceitual (também chamado de modelo de domínio) e o Vocabulário de Conceitos. Para isto apresentaremos um algumas técnicas para identificação dos candidatos a classes. Os objetivos desta etapa são: 1 - Apresentar técnicas para identificação dos candidatos a classes, atributos e associações; 2 - Elaborar Elaborar o Modelo Conceitua Conceituall ou modelo de domínio domínio e 3 - Elaborar Elaborar o Vocabulá Vocabulário rio de Conceitos. Conceitos.


Workflow orkflo w de de Análise Atividades.Road Map

e r a w t f o S e d a i r a h Caso de Uso n e g n E o ã ç Documento de a t Visão i c a p a C

Fazer Análise Conceitual Modelo Conceitual

Fazer Vocabulário Vocabulário

Definir o modelo de Arquitetura Modelo de Arquitetura


Workflow orkflo w de de Análise Atividades e Artefatos: Para este este workflow workflow as principais principais atividad atividades es e artefatos artefatos são: Workflow de Requisitos: Atividade: Coletar Requisitos Fazer Análise de Requisitos. Fazer Especificação de Requisitos; Artefatos: Documento de Visão Documento de Requisitos Caso de Uso Workflow de Análise Atividade: Fazer Análise Conceitual Fazer Vocabulário de Conceitos Artefatos: Modelo Conceitual e Vocabulário do Sistema.


Workflow orkflo w de de Análise Análise Conceitual. Introdução: “Modelo Conceitual. É o artefato mais importante da Análise Orientada a Objetos”

O modelo representa conceitos relevantes (do ponto de vista do modelador) do domínio do negócio. Este conceitos também são s ão chamados de Chaves da Abstração. “A chave da abstração é uma classe ou objeto que fazem parte do vocabulário do domínio do problema” (Booch). Na UML, esta fase é ilustrada com os diagramas de estruturas estáticas: - Caso Caso de Uso Uso - Digrama Digrama de Classes Classes (na verdade verdade o Modelo Modelo Conceitual). Conceitual). Os objetivos são: 1 - Apresentar Apresentar técnicas técnicas para identificaçã identificaçãoo dos candidatos candidatos a classe classes, classes, atributos atributos e associações e 2 - Elaborar Elaborar o Modelo Conceitua Conceituall ou Modelo de Domínio. Domínio.



e r a w t f o S e d a i r a h n e Caso de Uso g n E o ã ç a t i de c Documento a Visão p a C

Atividade: Fazer Análise Conceitual



Workflow orkflo w de de Análise Análise Conceitual. Modelos: O modelo de classe têm pelo três níveis de abstração: - Modelo Conceitual de Classes: Representa Representa as classes no domínio do do desenvolvimento do software, este modelo m odelo pertence a Workflow de Análise. Por definição, um modelo de classes de domínio não leva em consideração restrições referente à tecnologia a ser utilizada na solução do problema. Este modelo também conhecido como “Modelo de Classes de Domínio”. - Modelo de Classes de de Especificação: É derivado do Modelo Conceitual. Com Com acréscimos de detalhes, tais como, tipo de dado, operações (métodos), implementação de associações, generalização, agregação e composição e incremento de novas classes para que se fazem necessária para dar uma solução ao problema. Exemplo: Classes associativas. Este modelo é desenvolvido no Workflow de Projeto.


Workflow orkflo w de de Análise Análise Conceitual. Modelos - Modelo de Classes de de Implementação: É derivado do do modelo de especificação e corresponde a implementação das classes em alguma linguagem de programação, como Java, C#, C++ por exemplo. O modelo de implementação é construído na Fase Construção. Workflow de Análise

Workflow de Projeto

Pessoa

Pessoa nome idade


-nome -idade

<>

+setNome() +getNome() +getIdade() +getIdade()

Modelo de Especificação


Workflow orkflo w de de Análise Análise Conceitual. Atividades e Passos: Fazer Análise Conceitual Identificar os candidatos a classe Selecionar uma técnica Fazer a Lista de Candidatos Desenhar o Modelo Conceitual Definir a Arquitetura Inicial

4


Workflow orkflo w de de Análise Análise Conceitual. Identificação das Classes:

e r a w t f o S Um software orientado a objetos é composto de uma coleção de objetos que colaboram e para realizar seus requisitos. Entretanto, sabemos que os objetos são “instances” das d classes. a i r Para identificar as classes, podemos usar um método simples. O primeiro passo é fazer a uma lista de todas todas classes que encontramos, encontramos, esta lista pode ser chamada de “Lista de h n Classes Candidatas”. e E depois usando algum critério, eliminamos as classes irrelevantes e aí teremos uma lista g n definitiva. Existem dois métodos principais para realizar a identificação das classes de E domínio de um software: o ã - Método Método dirigido dirigido a dados: dados: ç a Neste método, a ênfase está na identificação da estrutura dos conceitos t i relevantes para o domínio do negócio, resultando em Modelo Conceitual. c a p a - Método Método dirigido a responsab responsabilidade ilidades: s: C Neste método, a ênfase está na identificação de classes a partir de seus

comportamentos relevante ao sistema. Este método também resulta em Modelo Conceitual.



UML. Introdução A UML deve ser utilizada para criarmos o Modelo Conceitual. Os modelos visuais ajudam a compreender melhor o sistema que estamos construindo. As seguir será apresentado os nós, elementos e adornos usados para construir o modelo.



e r a w t f o O Diagrama de Classes Cl asses nasce no Workflow de Análise com Modelo Conceitual (modelo de S e domínio), mais tarde no Workflow de Projeto este o modelo será refinado ganhando d adornos, novos tipos de relacionamentos, operações (métodos) e até novas classes. a i r a h Agora faremos apenas apenas o Modelo Conceitual que podemos considerar como o primeiro n e “esboço ” do que mais tarde se tornará o Diagrama de Classes. g n E o ã ç a t i c a p a C

Diagrama de Classes. Introdução


Workflow orkflo w de de Análise UML. Elementos: Elementos estruturais: Classe, Interface, Colaboração, Caso de Uso, Classe Ativa, Nó e Componente Elementos de agrupamento: Pacote e Subsistema


Workflow orkflo w de de Análise UML. Elementos: • •

Dependência Associação – Associação – Composição – Agregação

•

Generalização

Mecanismos de Extensibilidade:

• • •

Estereótipo “Tagged va value” Restrição (Constraint)


Workflow orkflo w de de Análise Diagrama de Classes

O diagrama de classes deve capturar capturar o Vocabu Vocabulário* lário* do sistema


Workflow orkflo w de de Análise Associação Definição de Associação: Um relacionamento estrutural que descreve um conjunto de vínculos, em que o vínculo é uma conexão entre objetos; relacionamento semântico entre dois ou mais classificadores que envolve as conexões entre seus objetos.

Associação classe

classe

Usuario

Senha


Workflow orkflo w de de Análise Associação Nome de Associação: Uma associação pode ter um nome, que pode usado para descrever a natureza do relacionamento. Podemos ainda acrescentar um triângulo para demonstrar a direção do nome, ou seja, a direção que nome deve ser lido. Nome da associação Direção do nome

Cliente

faz

Pedido

Observação: Apesar da possibilidade de a associação ter um nome, não é necessário incluí-lo. Recomendamos o uso do nome quando o modelo possui muitas associações e você tem a necessidade de fazer referência às associações ou de destaca-las.


Workflow orkflo w de de Análise Associação Navegação: Indica qual é a direção da associação. A direção da associação pode ser unidirecional unidireci onal (onde somente uma das pontas da linha de associação tenha a seta) ou bidireciona (não existem setas em nenhum dos lados)

Associação Navegação

Cliente

Pedido


Workflow orkflo w de de Análise Role Name: Definição de Role Name: É um identificador (nome) do papel da associação, podendo cada ponta ter um nome especifico.

Modificadores: (+) public | (-) private | (#) protected


Workflow orkflo w de de Análise Multiplicidade Definição: A especificação de uma faixa de números cardinais, que um conjunto pode assumir.

Eqüivale a muitos Multiplicidade

Faixa Válida: 0....1 | 0..* | * | 1 | 1..*

O que é uma multiplicidade ? Uma associação representa um relacionamento entre dois objetos. Em algumas situações de modelagem, é importante especificar a quantidade de objetos que podem ser conectados pela “instance” de uma associação. Essa “quantidade” é chamada de multiplicidade do papel de uma associação e é escrita escr ita como uma expressão equivalente a um intervalo de valores ou de uma valor explícito.


Workflow orkflo w de de Análise Role Name e Multiplicidade Exemplo:

Multiplicidade Para cada objeto (instance) da classe Pessoa a classe Empresa poder ter uma ou muitos objetos.



Análise Conceitual. Técnicas:

Abbot

UML

Kent Beck

Inspeção Gramatical

CRC Scott Ambler Graig Larman Peter Coad

Outras Técnicas

Análise de Caso de Uso


Workflow orkflo w de de Análise Modelo Conceitual. Técnica: Inspeção Gramatical Introdução: A primeira etapa na construção do Modelo Conceitual é identificar os conceitos os conceitos (idéias ou coisas). Podemos achar os candidatos a classe com a identificação de substantivos (Inspeção Gramatical). É uma técnica útil, por causa da simplicidade, simplici dade, proposta por Abbot . Consiste em identificar os substantivos no texto da Declaração de Problema e considerá-los como candidatos a a classe ou conceitos.


Workflow orkflo w de de Análise Modelo Conceitual. Técnica: Inspeção Gramatical Lista de Candidatos:

Conhecimento do Negócio Declaração de Visão

Identificação dos candidatos a classe, associações e atributos

1º Lista

Interações

Lista Final

Fazer revisão da lista: Eliminar conceitos os repetidos, ambíguo, irrelevantes e etc..


Workflow orkflo w de de Análise Modelo Conceitual. Técnica: Inspeção Gramatical Artefatos:

Modelo Conceitual

Lista de Candidatos

4

Vocabulário de Conceitos Co nceitos


Workflow orkflo w de de Análise Modelo Conceitual. Técnica: Inspeção Gramatical

Nome da associação Reserva

1..*

numero data-entrada data-saida Atributo

Classe feita por

1

Cliente

id hospede nome documento

0..*

Multiplicidade Apartamento 1..*

numero tipo situacao

Associação


Workflow orkflo w de de Análise Modelo Conceitual. Conceitual. Técnica: Técnica: Inspeção Inspeção Gramatical Gramatical - Exemplo Exemplo Declaração do Problema: O cliente solicitou o desenvolvimento de software para apoiar uma rede bancária computadorizada incluindo computadorizada incluindo caixas humanos e máquinas de auto atendimento (ATM) (ATM) a ser compartilhada por um consórcio de bancos. Cada banco provê seu próprio computador para manter suas contas e processar transações sobre elas. Os caixa automáticos são propriedade dos bancos e se comunicam diretamente com os computadores c omputadores de seus bancos proprietários. Os caixas humanos humanos introduzem dados sobre as contas e transações. Os caixas eletrônicos comunicam-se com um computador central que liquida as transações com os bancos adequados. Um caixa automático receber cartão magnéticos, interage com o usuário, comunica-se comunica-se com o sistema central central para executar executar transações, entrega entrega de dinheiro e impressão de extratos. O sistema exige um adequado arquivamento de registros e reservas de segurança. O sistema deve manipular corretamente acessos concorrente à mesma conta. Os bancos devem prover seu próprio software para seus próprios computadores; devemos projetar o software para as ATM ATM e para a rede. O custo do sistema compartilhado deve ser distribuído pelos bancos de acordo com número transações realizadas.


Workflow orkflo w de de Análise Modelo Conceitual. Técnica: Inspeção Gramatical Identificando do Domínio: (Técnica usada: extração dos substantivos do enunciado do problema)

Fazer transações eletrônica através de caixa de Auto atendimento e caixas


Workflow orkflo w de de Análise Modelo Conceitual. Técnica: Inspeção Gramatical Identificando os conceitos: (Técnica usada: extração dos substantivos do enunciado do problema) Software

Rede Bancária

Caixa

ATM

Consórcio

Banco

Computador do Banco

Conta

Transação

Terminal do do ca c aixa

Dados de de co c ontas

Dados de de tr t ransações

Computador Ce Central

Cartão Ma M agnético

Usuário

Dinheiro

Extrato

Sistema

Manutenção do Reserva de segurança arquiv arquivoo de Regist Registro ro Preço

Acesso

Cliente

Classes da ATM originadas do conhecimento do do domínio do problema Linha de Comunicação

Registro de transa nsação


Workflow orkflo w de de Análise Modelo Conceitual. Técnica: Inspeção Gramatical Identificando os conceitos: (Técnica usada: extração dos substantivos do enunciado do problema) Após a revisão identificamos o seguinte: Conceitos vagos: Sistema, Reserva de Segurança, Manutenção do arquivo de Registro e Rede Bancária Atributos: Dados de contas, extrato, dinheiro e dados de transações Conceito redundante: Usuário Conceito Irrelevante: Preço Conceito de implementação: Registro de Transação, Acesso, Software e Linha de Comunicação Eliminado às classes apontadas, ficamos com as seguintes conceitos válidos: Conta, ATM, ATM, Banco, Computador do Banco, Cartão Magnético, Caixa Terminal do Caixa, Computador Central, Consórcio, Cliente e Transação


Workflow orkflo w de de Análise Modelo Conceitual. Técnica: Inspeção Gramatical Identificando as Associações: Qualquer dependência entre duas ou mais conceitos é uma associação. Uma referência de uma classe a outra é uma associação. As associações muitas vezes correspondem a verbos estáticos ou a locuções verbais. Isso inclui localização física: - junto a, a, parte de, de, contido contido em e etc Ações indiretas: - direciona, comunica-se (fala a), propriedade (tem, parte de), ou satisfação de alguma condição (trabalha para, casado com, gerencia). Tente identificar as associações, lembre-se que nem todas, estão explicitas, pode haver muitas transações implícitas e algumas associação dependem do conhecimento do mundo real, real, ou seja, do negócio. negócio. Extraia todas as candidatas do enunciado do problema e as escreva em uma lista, e depois refine-as.


Workflow orkflo w de de Análise Modelo Conceitual. Técnica: Inspeção Gramatical Identificando as Associações: Lista (Frases (Frases verbais): verbais): Rede de bancária inclui caixas e ATM ATM Consórcio compartilha ATM Banco provê computador do banco Computador do banco mantém contas Computador do banco processa transações contra a conta Banco possui terminal de caixa Terminal de caixa comunica-se comunica-s e com o computador c omputador do banco Caixa introduz transação para a conta ATM comunica-se com computador central sobre transação Computador central liquida transação com banco ATM aceita cartão magnético ATM interage com usuário


Workflow orkflo w de de Análise Modelo Conceitual. Técnica: Inspeção Gramatical Identificando as Associações:

Lista (Frases (Frases verbais): verbais): ATM entrega o dinheiro ATM imprime extrato Sistema manipula acesso concorrente Bancos fornecem software Custo repartido pelos bancos Frases Verbais implícitas: Consórcio compõem-se de bancos Banco mantém conta Consórcio possui computador central Sistema provê arquivamento de registros Sistema provê segurança Clientes possuem cartões magnéticos Conhecimento do domínio do problema: Cartão magnético permite acesso a contas Banco emprega caixas


Workflow orkflo w de de Análise Modelo Conceitual. Técnica: Inspeção Gramatical Identificação dos conceitos dos atributos: Os atributos são propriedades de objetos individuais, como nome, peso, altura, velocidade, cor e etc. Os atributos não devem ser objetos; utilize uma associação para demonstrar qualquer relacionamento entre dois objetos. Os atributos geralmente geralmente correspondem a substantivos seguidos por frases possessivas, por exemplo: “a cor do carro” ou “o número da conta”. Os adjetivos muitas vezes representam valores de atributos específicos e enumerados, como vermelho sobre ou expirado. Diretamente das classes e associações, os atributos têm menos probabilidade de serem integralmente descritos no enunciado do problema. Devemos valer-se de nosso conhecimento do domínio da aplicação e do mundo real para encontrá-los. Lembre-se que os atributos raramente afetam a estrutura básica do problema.


Workflow orkflo w de de Análise Modelo Conceitual. Técnica: Inspeção Gramatical Identificação 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 associação derivadas podem ser úteis na abstração de propriedade significativas de uma aplicação, mas devem ser distinguidos nitidamente dos atributos básicos, que definem o estado do objeto. Os atributos derivados não devem ser expressos como operações, como obter-idade , embora possam eventualmente ser implementados como tais. Os atributos de ligação também devem ser identificados. Um atributo de ligação é uma propriedade da ligação entre dois objetos e não a propriedade de um objeto isoladamente. Por exemplo: a associação muitos-para-muitos entre muitos-para-muitos entre Acionistas e Empresa tem o atributo de ligação número de ações. Os atributos de ligação às vezes são tomadas erradamente por atributos de objetos.


Workflow orkflo w de de Análise Modelo Conceitual. Técnica: Inspeção Gramatical Identificação 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 associação derivadas podem ser úteis na abstração de propriedade significativas de uma aplicação, mas devem ser distinguidos nitidamente dos atributos básicos, que definem o estado do objeto. Os atributos derivados não devem ser expressos como operações, como obter-idade , embora possam eventualmente ser implementados como tais. Os atributos de ligação também devem ser identificados. Um atributo de ligação é uma propriedade da ligação entre dois objetos e não a propriedade de um objeto isoladamente. Por exemplo: a associação muitos-para-muitos entre muitos-para-muitos entre Acionistas e Empresa tem o atributo de ligação número de ações. Os atributos de ligação às vezes são tomadas erradamente por atributos de objetos.


Workflow orkflo w de de Análise Modelo Conceitual. Técnica: Inspeção Gramatical Modelo Conceitual vs Modelo de Especificação

Workflow de Análise

Transacao Datahora

Workflow de d e Projeto

Transacao Datahora:Timestamp +getTransacao() +setDataHora() +getDataHora()

Conceito de classes e atributos

Classes


Workflow orkflo w de de Análise Modelo Conceitual. Técnica: Inspeção Gramatical Modelo Conceitual:


Workflow orkflo w de de Análise CRC Método dirigido a responsabilidades: Neste método, a ênfase está na identificação das classes a partir de seus comportamentos relevante ao sistema. Técnica Cartão (CRC): O CRC foi apresentado por Kent Beck e Ward Cunningham em artigo chamado: "A Laboratory for Teaching Object-Oriented Thinking" no OOPLSA '89. Conceito e Aplicação: CRC (Cartão Responsabilidade e Colaboração) é um cartão índice que é usado para representar as responsabilidades das classes e suas interações com outras classes. O cartão CRC é uma abordagem informal da modelo de orientação a objetos. Os cartões são criados através de cenários, baseado nos Requisitos, Requisitos , que modela o comportamento do sistema. Observação: O CRC não faz parte da UML. Mas é uma técnica recomendada, pela sua simplicidade, principalmente para quem tem pouca experiência com orientação a objetos.


Workflow orkflo w de de Análise CRC. Responsabilidades e Colaborações: 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 obrigação que um objeto tem para como sistema no qual ele estará inserido. Através das responsabilidades, um objeto colabora com outros objetos para que os objetos sejam alcançados. 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 não pode cumprir sozinho. Nesses casos, o objeto deve requisitar colaboração de colaboração de outros objetos do software para cumprir com sua responsabilidade.

Objeto Responsabilidades: (o que objeto conhece e o que faz)

+

Colaborações: (outras classes que são associadas, para a interação entre os objetos)


Workflow orkflo w de de Análise CRC. Elementos: O nome do cartão é o mesmo nome da classe, as responsabilidades são as coisas que que a classe dever saber fazer e coisas que ela deve conhecer. conhecer. As colaborações as informações que a classe precisa e que está alocada em outra outra classe, desta forma temos que fazer o relacionamento entre classes, para que ela cumpra com sua responsabilidade. Modelo:

Nome da Classe Responsabilidades:

Colaborações:

Lista das responsabilidades responsabilidades

Lista de colaborações

Melhores Práticas: Os candidatos a classe cujo c ujo a responsabilidade não foi encontrada, este candidato c andidato deve ser descartado. Pois, não podemos ter classe sem nenhuma responsabilidade.


Workflow orkflo w de de Análise CRC. Exemplos: Classe: Reserva Responsabilidades: Conhecer o período da reserva (datas) Saber o nome do cliente Saber o número do apartamento

Colaborações: Apartamento Cliente

Classe: Cliente Responsabilidades:

Colaborações:

Saber o nome do cliente Saber a Reserva do Cliente

Reserva


Workflow orkflo w de de Análise Modelo Conceitual. Técnica: Inspeção Gramatical & CRC Inspeção Gramatical Lista de Candidatos

CRC

UML

Classe: Cliente Responsabilidades:

Colaborações:

SaberClasse: o nomeCliente do clienteReserva Saber a Reserva do Cliente Responsabilidades: Colaborações: Saber o nome do clienteReserva Saber a Reserva Classe: Clientedo Cliente Responsabilidades:

Colaborações:

Saber o nome do clienteReserva Saber a Reserva do Cliente

Identificação dos candidatos

Identificação das Responsabilidade

Modelo Conceitual


Workflow orkflo w de de Análise Análise de Caso de Uso: Análise começa com verificação do Modelo de Caso de Uso, Diagrama, Cenários e Formulários e a Lista de de Requisitos Funcionais. Nesta análise é identificado identificado os candidatos a classe.

Formulário

Cenários

Gerenciar Reserva

Usuário Ator

Caso de Uso Associação

Listas de Candidatos


Workflow orkflo w de de Análise Análise de Caso de Uso. Big Picture Documento de Visão

4

Lista de Candidatos

1

Engenharia de Requisitos Análise de Requisitos Lista de Requisitos Funcionais

Especificação Especificação de Requisitos (Visão de Caso de Uso)

3

Formulário

2

Cenários Casos de Uso Lista de Requisitos Não Funcionais Ator

Usuário

Gerenciar Reservas Associação


Workflow orkflo w de de Análise Análise de Caso de Uso: Identificando os candidatos a classe Como fazer. Diagrama: 1 - Verifique os nome dos Casos de Uso, eles geralmente contêm bons candidatos.

Usuário

Gerenciar Reserva

Reserva é provável candidato a classe

<>

Buscar Apartamento

Atualizar Atualizar Reserva Reserva

<>

Funcionário Criar Criar Reserva Reserva

Remover Remover Reserva Reserva

Cadastrar Cadastrar Cliente Cliente

prováveis candidatos a classe


Workflow orkflo w de de Análise Análise de Caso de Uso: Identificando os candidatos a classe Como fazer. Cenários: 2 - Os cenários devem usados para identificação dos candidatos. Ache os substantivos, substantivos, exemplo: Cenários: Gerenciar de Reserva:

Cenários

O Setor de Reserva do Hotel recebe um telefonema de cliente que solicita uma reserva de apartament apartamentos os para data. data. O cliente informa o período, ou seja, data de chegado e partida, e qual tipo de apartamento ele precisa. O funcionário funcionário do Setor de Reserva, Reserva, verifica verifica a disponibilid disponibilidade ade do apartamento apartamento e informa que não tem disponibilida disponibilidade de de apartamento apartamento para o período informado informado pelo cliente e oferece um outro tipo de apartamento. O cliente não aceita a proposta do funcionário e a reserva não é confirmada. confirmada.

Prováveis candidatos a classe


Workflow orkflo w de de Análise Análise de Caso de Uso: Atividades Como fazer. Formulário: 3 - Os Formulários também devem usados para para identificação dos candidatos. candidatos. Ache os substantivos, exemplo:

Formulários

Nome: Gerenciar Reserva Ponto de ativação: Este caso de uso começa quando o funcionário do setor de reserva recebe uma solicitação de reserva Ator: Funcionário Objetivo: Fazer reservar de apartamentos Pré-condição: Solicitação de reserva Fluxo Normal: O cliente informa o tipo de apartamento O cliente o período (data de chegada e partida) O funcionário do Hotel verifica a disponibilidade disponibilidade do apartamento O funcionário confirma a reserva

Fluxo Alternativo: ... O funcionário do Hotel verifica a disponibilidade disponibilidade do apartamento O funcionário faz proposta de outro apartamento para cliente O cliente aceita e então o funcionário confirma a reserva


Prováveis candidatos a classe


Workflow orkflo w de de Análise Modelo Conceitual. Técnica: Inspeção Gramatical & CRC Análise de Caso de Uso Lista de Candidatos

CRC

UML

Classe: Cliente Responsabilidades:Colaborações: Saber o nome do cliente Reserva Classe: Cliente Saber a Reserva do Cliente Responsabilidades:Colaborações: Saber o nome do cliente Reserva Classe: Clientedo Cliente Saber a Reserva Responsabilidades:Colaborações: Saber o nome do cliente Reserva Saber a Reserva do Cliente

Identificação dos candidatos

Identificação das Responsabilidade

Modelo Conceitual


Workflow orkflo w de de Análise Dicas: Scott Ambler Para encontrar as classes, vejamos algumas dicas: 1 - Considere que as classes são lugares, eventos, conceitos, pessoas e etc. etc. 2 - Atores Atores são classes classes em potencial; potencial; 3 - Identifique Identifique os clientes; clientes; 4 - Siga o dinheiro, dinheiro, podemos identificar identificar produtos, serviços, eventos como venda, venda, compra e etc; 5 - Conceitos Conceitos são classes classes em potencia potencial; l; 6 - Eventos Eventos são classes classes em potencia potenciall e 7 - Entende Entende o negócio. negócio. Use a técnica técnica CRC para atribuir ou descobrir as responsabilidades responsabilidades e colaborações das classes encontradas


Workflow orkflo w de de Análise Graig Larman Larman sugere a que a identificação dos substantivos, que são os candidatos a classe ou conceitos seja feito através dos C asos de Uso “expandidos”, pois, eles fornecem uma excelente descrição a serem usadas como fontes para este tipo de análise. Exemplo:

Exemplo de Caso de Uso expandido: Seqüência típica de eventos: 1 - Este caso caso de de uso começa quando quando um Cliente Cliente chega a um ponto ponto de venda venda e deseja deseja comprar alguns itens. 2 - O Caixa Caixa registr registraa o códig códigoo do produt produtoo de cada cada item item ... Entretanto esta técnica exige uma ou mais revisão nos conceitos encontrados, pois, diferentes substantivos podem representar o mesmo conceito.


Workflow orkflo w de de Análise Graig Larman Larman também sugere usar uma abordagem de Categoria de Conceitos, que nada mais é que uma lista de categorias. Após determinar lista use-a para identificar os conceitos. Exemplo de lista: Categoria

Exemplos

Objeto físico ou tangível

Terminal de ponto-de-venda Avião

Espe Es peci cififica caçã ção, o, pr proj ojet eto, o, ou ou descr descriç ição ão de de cois coisas as

Especi Espe cififica caçã çãoo de pro produ duto to Descrição de vôo

L u g a re s

L o ja Aeroporto

Transações

Venda, Pagamento Reserva

Itens de transação

Itens de venda Parcelas de pagamento

Papéis de pessoas

Operador Piloto


Workflow orkflo w de de Análise Graig Larman Identificação dos Conceitos: Abaixo um exemplo de identificação dos conceitos a partir dos Formulários dos Casos de Uso:

Ação do Ator 1. Este caso de uso começa quando um Cliente chega no caixa com itens para comprar c omprar.. 2. O Operador registra Operador registra o identi-ficador de cada item. item. Se há mais de um do mesmo item, item, o Operador tam também bém pod podee inf inform ormar ar a quantidade. quantidade.

Resposta do Sistema

3. De Dete term rmin inaa o preç preçoo do item item e adiciona informação sobre o item à transação de venda em anda-mento. Mostra a descrição e o preço do item corrente.


Workflow orkflo w de de Análise Peter Coad A Proposta de Coad & Yourdon: O método Análise Orientada a Objetos, proposto por Peter Coad e Yourdon Yourdon e denominado OOA (Object Oriented Analysis ), ), consiste basicamente em cinco passos: 1 - Localização Localização de de classes-&-objet classes-&-objetos: os: entende-se entende-se por por objetos como a abstração abstração de alguma alguma coisa, em um domínio de problema, cujas informações devam ser s er manipuladas pelo sistema. Uma classe corresponde ao conjunto de objetos semelhantes. 2 - Identificaçã Identificaçãoo de estrutur estruturas: as: que podem podem ser classificad classificadas as em: Generalização-especialização : quando uma classe é\ um tipo tipo de uma de uma outra classe. Exemplo: a classe carro é carro é uma especialização da classe veículos ; 

Todo-parte : quando uma classe é formada por outras por outras classes. Exemplo: as classes motor e motor e chassis fazem parte da classe carro . 

3 - Definição Definição de assuntos assuntos:: onde cada cada qual se relaciona relaciona a diferentes diferentes partes partes do modelo, permitindo minimizar a complexidade de projetos extensos.


Workflow orkflo w de de Análise Dicas: Peter Coad A Proposta de Coad & Yourdon 4 - Definição Definição de atributos: atributos: um atributo atributo é definido como como uma propriedade, propriedade, uma qualidade qualidade ou uma característica de um determinado objeto. Um atributo consiste em alguns dados (informações de estado) através dos quais cada objeto em uma classe class e tem seu próprio valor. Atributos comuns a todas as subclasses (especializações) de uma classe são apenas listados na classe e, automaticamente, estendidos para as suas subclasses. Uma conexão de ocorrência representa ocorrência representa relacionamentos entre objetos. 5 - Definição Definição de Serviços: Serviços: um serviço é um comportame comportamento nto específico específico que que um objeto deve exibir. exibir. Um serviço altera o estado de um objeto. Serviços pertencentes a todas subclasses são definidos apenas na classe. Os serviços implícitos, tais como incluir, i ncluir, remover, alterar e selecionar instâncias, não são apresentados no diagrama. Uma conexão de mensagem representa a comunicação entre objetos, onde um “emissor”' envia uma mensagem para um “`receptor'', para a realização de algum processamento.




Vocabulário.Road ocabulário.Road Map:


Fazer Vocabulário ocabul ário Vocabulário


Workflow orkflo w de de Análise Vocabulário:

e r a w t f o S Fazer Vocabulário e d a i r Descrever os conceitos a h n Fazer Vocabulário: e g Devemos fazer um Vocabulário de todas as classes presente pres ente no Modelo Conceitual. n O vocabulário consiste em simples descrição do conceito. E o Transacao ã ç a t i Datahora c a Transação – Uma única solicitação integral para operações nas p a contas de um único cliente. Especificamente somente que as ATM C podem entregar dinheiro, mas não podemos eliminar a

possibilidade da impressão de cheques ou de receber dinheiro ou cheques. Também Também queremos prover a flexibilidade de operar as contas de diferente clientes, embora isso não seja exigido. As As diferentes operações devem fechar apropriadamente.


Workflow orkflo w de de Análise Modelo Conceitual.


Workflow orkflo w de de Análise Vocabulário. ocabulário. Exemplo: Exemplo : Vocabulário: ATM – Uma estação que permite os clientes introduzem suas próprias transações utilizando cartões magnéticos como identificação. A ATM interage com o cliente para obter informações sobre transações, envia as informações sobre transações para o computador central para validação e processamento e entrega de dinheiro ao usuário. Presumimos que uma ATM ATM não necessita operar independente de rede. Banco – Uma instituição financeira que mantém contas de cliente e emite cartões magnéticos autorizando o acesso às contas através da ATM. ATM. Caixa – Um empregado do banco autorizado a introduzir transações nos terminais de caixa e a receber e entregar dinheiro e cheques aos clientes. As transações, o dinheiro e os cheques manipulados por cada caixa devem ser registrados e devidamente contabilizados.


Workflow orkflo w de de Análise Vocabulário. ocabulário. Exemplo: Exemplo : Vocabulário: Cartão Magnético – Cartão vinculado a um cliente do banco que autoriza o acesso às contas utilizando uma máquina ATM. ATM. Cada cartão contém um código de banco e um número de cartão, codificados de acordo com os padrões padrões definidos pelo pelo Bacen (Banco Central) sobre cartões de créditos e cartões magnéticos. O código do banco identifica inequivocamente i nequivocamente o banco dentro do consórcio. O número do cartão determina as contas a que cartão pode ter acesso. Um cartão não necessariamente dá acesso a todas as contas do cliente. Cada cartão pertence a um usuário cliente, mas podem existir múltiplas cópias dele, de modo que a utilização simultânea do mesmo cartão em diferentes máquinas deve ser considerada. Cliente – Possuidor de uma ou mais contas em um banco. Um cliente pode ser uma ou mais pessoas ou corporações; a correspondência não é relevante para este problema. Se uma pessoa possui conta em um diferente banco é considerada cliente diferente.


Workflow orkflo w de de Análise Vocabulário. ocabulário. Exemplo: Exemplo : Vocabulário: Computador operado operado pelo consórcio consórcio que despacha despacha transações transações entre entre as ATM ATM e Computador Central - Computador os computadores dos bancos. O computador central valida códigos de bancos mas não processam transações diretamente. ATM. A rede só manipula Consórcio – Organização de bancos que comissiona e opera a rede ATM. transações do consórcio. Conta – Única conta no banco contra a qual as transações transaç ões podem ser aplicadas. As contas podem ser de vários tipos, no mínimo de cheques e de poupança. Um cliente pode manter mais de uma conta. Terminal de caixa – Terminal no qual os caixas introduzem transações para os clientes. Os caixas entregam a recebem dinheiro e cheques; a impressora do terminal imprime extratos. O terminal do caixa comunica-se com o computador central do banco para validar e processar transações. Transações – Uma única solicitação integral para operações nas contas de um único cliente. Especificamente somente que as ATM ATM podem entregar dinheiro, mas não podemos eliminar a possibilidade da impressão de cheques ou de receber dinheiro ou cheques. Também Também queremos prover a flexibilidade de operar as contas de diferente clientes, embora isso não seja exigido. As diferentes operações devem fechar apropriadamente.


Workflow orkflo w de de Análise Diagrama de Objetos Introdução: Bem o última coisa a fazer neste Workflow é fazer a validação do Diagrama de Classes. Podemos fazer esta validação utilizando o Diagrama de Objetos e os Casos de Uso. Desta forma estaremos garantindo que o Diagrama de Classes feito atende os requisitos. Diagrama de Objetos, é diagrama estrutural, que demonstra um conjunto de objetos e seus relacionamentos em determinado ponto no tempo. Sua principal aplicação é ilustrar as estruturas de dados, registro estáticos estát icos das “instances” dos itens encontrados no diagrama de classe. O diagrama de objetos direcionam a visão estática do projeto ou de processo de um sistema. O Diagrama de Objetos também podem conter pacotes ou subsistemas, notas e restrições. Exemplo da notação: :Nome do Objeto Atributo: Valor do atributo objeto

Nome do Objeto Atributo: Valor do atributo

vínculo


Workflow orkflo w de de Análise Diagrama de Objetos

e r a w t f Recomendamos o uso do Diagrama de Objetos para validar o Diagrama de Classes. o S Exemplo: e d a i r Diagrama de Classe Diagrama de Objetos a h Aluno :Aluno n e Nome: “Fulano de Tal” -Nome: String Nome da g -Data: Date Data: 23-02-2001 associação n Nome do E objeto “Instance” objeto o ã Matricula 201-23-02-01:Matricula ç a -Matricula: int Matricula: 201-23-02-01 t vinculo i -Curso: String Curso: Adm Empresas c a Atributo Valor do atributo p a C


Workflow orkflo w de de Análise Diagrama de Objetos Conteúdo do Diagrama de Objetos: Objetos e Vinculo Diagrama de Objetos objeto

:Aluno Nome: “Fulano de Tal” Data: 23-02-2001

201-23-02-01:Matricula Matricula: 201-23-02-01 Curso: Adm Empresas

vínculo Um vínculo é uma conexão semântica existente entre os objetos. Em geral, um vínculo é uma “instance” de uma associação.

Desta forma um objeto pode enviar uma mensagem para outro.


Workflow orkflo w de de Análise Diagrama de Objetos Como fazer a modelagem de um estrutura de objetos: Como posso validar o diagrama de classes?

Um mecanismo • Identifique o mecanismo cuja modelagem você deseja fazer. Um representa algum requisito ou comportamento da parte do sistema cuja a modelagem você está fazendo e que é resultante da interação de um conjunto de classes, interfaces e outros itens. • Para cada mecanismo, identifique todos os itens (classes, interfaces e outros elementos) que participam nessa colaboração e seus relacionamentos. • Leve em consideração somente um cenário capaz de percorrer esse mecanismo. Congele o cenário em determinado momento e represente cada objeto que participa do mecanismo. • Exponha o estado e os valores dos atributos de cada c ada um desses objetos, conforme seja necessário, para compreensão do cenário. • De maneira semelhante, exponha os vínculos existentes entre esses objetos, representando as “instance” de associação entre eles.


Workflow orkflo w de de Análise Arquitetura Inicial.Road Map



Fazer Vocabulário Vocabulário

Definir o modelo de Arquitetura Modelo de Arquitetura


Workflow orkflo w de Análise Anális e Modelo de Inicial de Arquitetura Definir o Modelo de Arquitetura Definir o Modelo de Arquitetura Inicial

Podemos criar um Modelo de Arquitetura Inicial para aplicação. O objetivo deste modelo é apresentar um visão macro da arquitetura. Os modelos de Caso de Uso e Modelo Conceitual são utilizados para desenhar este o modelo. Uma visão inicial da arquitetura pode ter muita formas, podemos utilizar a UML para representar este modelo ou qualquer outra notação. Este modelo será refinado no workflow de projeto na Atividade “Fazer o Modelo de Arquitetura”.

Camada apresentação 4

Camada de serviço (controle)

Camada regra de negócio


Banco de Dados


Apêndice Diagrama de Pacotes Como podemos definir o diagrama de pacotes? A definição de Pacote é uma generalização, ou seja, um agrupamento, com o propósito de organizar as Classes de Objetos em grupos. Esta abordagem facilita a análise a medida que o número de Classes de Objetos cresce num do cenário. O tipo de relacionamento é linha pontilhada com uma seta que indica dependência. Os diagramas de pacote podem ser usados para fazer decomposição funcional. A nota notaçã çãoo usad usadaa pela ela UML UML para ara rep represe resenntar tar paco pacote tess é:

Nome do Pacote

Nome do Pacote

Nome do Pacote Nome do Pacote

Dependência (import)


Apêndice Diagrama de Pacotes Decomposição. “Dividir para conquistar...” conquistar...”

Algumas aplicações podem ser enormes ou ter um grau muito mui to alto de complexidade ou ambas as coisas. Para facilitar é necessário fazer uma decomposição. A idéia da decomposição é simples. É fazer uma divisão para simplificar si mplificar o entendimento, a modelagem ou processo de desenvolvimento de um software. Veja o exemplo abaixo:

Contas a Pagar

Fluxo de Caixa Nome do Pacote

Subsistema

Contas a Receber



Desenho (design (design ) do Modelo de Especificação de Software Objetivo desta parte: É apresentar e discutir o desenho (modelo de especificação) seus conceitos, técnicas e modelo.


Workflow de Projeto Objetivo:

e r a w t f o Apresentar e discutir o Workflow de Projeto, também conhecida como “Fase de S Especificação”, agora faremos faremos uso da intenso da UML para fazer os modelos (diagramas) e e a documentação. d a i r As principais atividades são: a Construção do Modelo de Especificaçã Especificaçãoo (Projeto) (Projeto) h - Construção n - Construção Construção do Modelo de Arquitetura Arquitetura e g - Fazer validaç validação ão do modelo. modelo. n E o ã ç a t i c a p a C


Workflow de Projeto Introdução. UML, Visões:

Visão de Projeto






Workflow de Projeto Introdução. UML, Visões:

e r a w t f o Visão de Projeto S e • A visão de projeto de um sistema abrange as classes e colaborações que formam o vocabulário do d a problema e de sua solução. Essa perspectiva proporciona principalmente um suporte para os i r a requisitos funcionais do sistema, ou seja, os serviços que o sistema deverá fornecer a seus usuários h n finais. Com a UML, os aspectos estáticos dessa visão são captados em diagramas de classes e de e g objetos; os aspectos dinâmicos são captados em diagramas de interações, de estados e de n atividades. E o ã Visão de Processo ç a t i • A visão do processo abrange os “threads” e os processos que formam os mecanismos mecanismos de c a concorrência e de sincronização do sistema. Essa visão tem com objetivo principal tratar questões p a de desempenho, à crescimento escalar e ao “throughput” do sistema. Com a UML, os aspectos C

estáticos e dinâmicos dessa visão são capturados nos mesmos tipos de diagrama da visão do projeto, mas o foco voltado para as classes ativas que representam esses threads e threads e processos.

Threads = Linhas de execução em paralelos, também conhecido como processo, estas linhas podem ser programas ou parte.


Workflow de Projeto Introdução. Aspecto Aspecto estático e dinâmico:

e r a w t f o O Workflow de Análise é determinado pelo “aspecto estrutural estático ”, ”, que permite S entender como uma software está estruturado internamente para atender os requisitos. e d a Esse aspecto é chamado de estático porque não apresenta informações sobre como os i r objetos se comportam no ciclo de vida de software e também porque representa a estrutura a h das classes de objetos e os relacionamentos entre elas. n e g No Workflow de Projeto, Projeto, faremos a modelagem dos aspectos dinâmicos do sistema , estes n aspectos são capturados em digramas (diagrama de interação, diagrama de estados e E o diagrama de atividades). ã E assim podemos representar os comportamentos internos e desta forma teremos novas ç a visões do software e aí conseguiremos compreender melhor o software. t i c a p a C


Workflow de Projeto Introdução. Aspecto Aspecto estático e dinâmico: UML. Principais Diagramas: Modela a estrutura do sistema

ESTÁTICOS . Diagrama de Classes . Diagrama de Objetos . Diagrama de Componentes . Diagrama de Distribuição


Modela o comportamento do sistema

DINÂMICOS . Diagrama de Casos de Uso . Diagramas de Interação - Diagram Diagramaa de Seqüênci Seqüênciaa - Diagram Diagramaa de Colaboraçã Colaboraçãoo . Diagrama de Atividade . Diagrama de Estados Workflow de Projeto


Workflow de Projeto Introdução A Workflow de Projeto depende da Workflow de Análise:


Análise dependência

Workflow de Projeto

Projeto


Workflow de Projeto Introdução A Workflow de Projeto refina a Workflow de Análise: Workflow de Análise

Workflow de Projeto

modelo conceitual

Diagrama de Classes

Cliente codigo nome

Cliente <>

Atributos: Visibilidade

Atributos: Tipo de dados

-codigo: int -nome: String +getCodigo() +setCodigo() +getNome() +setNome() métodos


Workflow de Projeto Big Picture. Projeto Projeto (Visão Lógica)

Análise Modelo Conceitual

Diagrama de Classes

4

ReceberPedido

4

PreencherPedido

EnviarFatura

Entrega [pedido urgent e]

[s enão] ReceberPagamento



: visitante

: FormBusca

: Ca et go ri a

: Pr Pr od ut o

EntregaRegular

: Ca Ca at ol go

getDescricao() exibirCategoria() selecionarCategoria

exibirProduto()

selecionarProduto()

getDescricao()

getQuantidade()

EncerrarPedido


Workflow de Projeto

Arquitetura Workflow

Arquitetura

Artefatos

Papéis

Diagrama de Seqüência / Colaboração Analista de Sistema Projetista de Software

Diagrama de Atividades

Diagrama de Estados

Diagrama de Classes

Arquiteto de Software


Workflow de Projeto Atividades.Road Map

e r a w t f o S e d a i r a h n e Caso de Uso g n E o ã ç a t i Modelo c conceitual a p a C

Fazer Modelo de Especificação Modelo de Especificação

Fazer Modelo de Arquitetura Modelo de Arquietura


Workflow de Projeto Projeto. Atividades e Passos: Fazer Modelo Especificação Identificar as classes de Especificação Fazer Diagrama de Interação Fazer a Diagrama de Atividades / Estados* Refinar o Modelo de Classes Modelo de Especificação


Workflow de Projeto

e r a w t f o Uso caso de uso descreve “o quê” um sistema faz, ele não especifica “ como” isso é feito. S Ao fazer uma modelagem, importante manter clara cl ara a separação de questões entre a visão e d interna e externa. “O como” é modelado pelo Diagrama de Interação. a i r a h n <> “O quê” e g selecionar categoria n E “O como” buscar produtos o Diagrama de Sequência visitante ã ç a Diagrama de Estado t i c a p a C

Casos de Uso. Revisão

: visitante

: FormBusca

: Cat egori a

: P rodut o

: Catalogo

getDescricao( )

exibirCategoria( )

selecionarCategoria

exibirProduto( exibirProduto( )

Formulário

selecionarProduto( selecionarProduto( )

getDescricao( )

getQuantidade( )


Workflow de Projeto

e r a w t f o Diagrama de Interação são modelos que descrevem como grupos de objetos objetos colaboram S e para atender comportamento. d Tipicamente, um diagrama de interação captura o comportamento de um único caso de a i r uso. O diagrama deve mostrar os vários v ários objetos e as mensagens que são passadas entre a h estes objetos. n e g n Existem dois tipos de diagramas: E o ã • Diagrama de Seqüência: ç a O foco deste diagrama é maneira que as mensagens m ensagens são enviadas ao longo do tempo. t i c • Diagrama de Colaboração: a p Aqui o foco é o relacionamentos estrutural entre os objetos de uma interação e então a considerar como as mensagens são passadas no contexto dessa estrutura. C

Diagrama de Interação. Introdução


Workflow de Projeto Diagrama de Interação O que é Diagramas de Seqüência? É um diagrama que exibe a colaboração dinâmica entre objetos de um sistema. O principal aspecto deste diagrama é que a partir dele percebe-se a seqüência de mensagens enviadas entre os objetos. Ele mostra a interação entre os objetos e os eventos que acontecem em um ponto específico da execução do sistema. Notação: Diagrama de Seqüência :Objeto 1 Ator:

1: mensagem 1 2: mensagem 2

3: mensagem 3

:Objeto 2


Workflow de Projeto Diagrama de Interação Diagramas de Seqüência:


Workflow de Projeto Diagrama de Interação Diagramas de Seqüência: formulários de registro

formulário de matrícula

entrar com senha de acesso validar acesso Aluno: entrar com o semestre

criar nova matrícula apresentar em tela obter cursos

cursos disponíveis


Workflow de Projeto Diagrama de Interação Diagramas de Seqüência. Elementos: Instance das classes ator

: Atendente

: Client e

: Veic ulo

: Loc ac ao

getDadosCliente( )

[* se cliente cadastrado verificar divida ] getDivida( )

getDisponibilidade( )

setSaida( ) [* se veículo disponível ]

Autodelegação

Linha do tempo

As interações entre os objetos

Restrição ou condição


Workflow de Projeto Diagrama de Interação Diagramas de Seqüência. Numerando as seqüências das mensagens.

: visitante

: FormBusca

: Categoria

: P roduto

: Catalogo

1: getDescricao( ) 2: exibirCategoria( ) 3: s elecionarCategoria elecionarCategoria

4: getDescricao( ) 5: getQuantidade( )

6: exibirProduto( )

7: selecionarProduto( )

Este diagrama descreve em ordem cronológica as mensagens entre os objetos.


Workflow de Projeto Diagrama de Interação O que é Diagrama de Colaboração? É um diagrama que mostra a colaboração dinâmica entre os objetos, semelhante semel hante ao diagrama de seqüência. No diagrama de colaboração, além de mostrar a troca de mensagens entre os objetos, percebe-se também as colaborações dos objetos. A interação de mensagens é mostrada em ambos os diagramas. Diagrama de Colaboração tem a maioria de suas características semelhantes ao Diagrama de Seqüência. Quando usar o diagrama de Colaboração ? Se a ênfase do diagrama for o decorrer do tempo, é melhor escolher o diagrama de seqüência, seqüência, mas se a ênfase for relacionamentos estrutural entre os objetos de uma interação, é melhor dar prioridade ao diagrama de colaboração. colaboração. Podemos também escolher ambos. Diagrama de Seqüência é mais usual.


Workflow de Projeto Diagrama de Interação O que é Diagrama de Colaboração ? O diagrama de colaboração é desenhado como um diagrama de objeto, onde os diversos objetos são mostrados juntamente com seus relacionamentos. As setas de mensagens são desenhadas entre os objetos para mostrar m ostrar o fluxo de mensagens entre eles. As mensagens são nomeadas, que entre outras coisas mostram a ordem em que as mensagens são enviadas. Também Também podem mostrar condições, interações, i nterações, valores de resposta, e etc. O diagrama de colaboração também pode conter objetos ativos, que executam paralelamente com outros. Exemplo: Diagrama de Colaboração

2: validar acesso 1:entrar com chave de acesso

3:entrar com o semestre

4:criar nova matrícula

formulários de registro

Ator (José) 5:apresentar em tela cursos disponíveis

formulário de matrícula 6:obter cursos


Workflow de Projeto Diagrama de Interação

e r a w t f o Gerando Diagramas de Colaboração: S e Na ferramenta “Rational Rose”, após criarmos o diagrama de seqüência. Selecionar: d c olaboration Diagram) a ~ Menu Browse e depois a opção F5 (Create colaboration i r a h n e g n E o : ã Categori ç 3: selecionarCategoria : visitante 7: selecionarProduto( ) a t i c 4: getDescricao( ) a 1: getDescricao( ) p a 5: getQuantidade( ) C : : Catalogo Produto

: Form Busca 2: exibirCategoria( ) 6: exibirProduto( )


Workflow de Projeto Projeto. Atividades e Passos: Fazer Modelo Especificação Identificar as classes de Especificação Fazer Diagrama de Interação Fazer a Diagrama de Atividades / Estados* Refinar o Modelo de Classes Modelo de Especificação


Workflow de Projeto Diagrama de Estado O que é Diagrama de Estado? É um diagrama que tipicamente complementa a descrição das classes. Pois, este diagrama exibe todos os estados possíveis que objetos de uma certa classe podem se encontrar. encontrar. Mostra também quais as variações de comportamento provocam tais mudanças. Não necessário escrever o diagrama de estado para todas as classes de um sistema, mas, apenas para aquelas que possuem um número definido de estados conhecidos e onde o comportamento das classes é afetado e modificado pelos diferentes estados. Diagramas de estado capturam o ciclo de vida dos objetos, subsistemas e sistemas. s istemas. Aplicação: Um diagrama de estado pode ser aplicado a diversos elementos da UML, tais como: - Classes Classes e Casos Casos de Uso Uso


Workflow de Projeto Diagrama de Estado Elementos: Os diagramas de estados são compostos de transições e estados. As transições são associadas com ações e são consideradas como processo de curta duração e não podem ser interrompidos. Os estados são associados com as atividades e podem levar mais tempo. Uma atividade pode ser interrompida por algum evento.

Verificando

Estado

Início do fluxo

Transição

Final do fluxo


Workflow de Projeto Diagrama de Estado Exemplo:

início

transição fora do gancho Ativo

ocioso no gancho Estado


Workflow de Projeto Diagrama de Estado Exemplo 1: Inicializa o Objeto

Lamp On

Espera por Evento Trata Evento

on

on/print(”on”)

off

off

Lamp Off Finaliza Objeto

stop


Workflow de Projeto Diagrama de Estado Exemplo 2: (Completo) início

[Nem todos os itens verificados]/pegar verificados]/pegar próximo item [Todos os itens verificados e os todos itens disponíveis]

Verificando

[Todos os itens verificados e alguns itens não estão disponíveis] disponíveis]

[itens ecebidos [alguns itens não estão disponíveis] disponíveis]

Expedindo

Item recebido [os todos itens disponíveis]

Aguardando

cancelamento cancelado Cancelamento

Entregue

final


Workflow de Projeto Diagrama de Estado Exemplo: Caso de Uso

Cliente

Diagrama de Estado

Autenticar Senha

Consultar Pedido Gerenciar Pedido

Funcionário

Confirmar Pedido

Verificando Verificando S tatus

[Pedido não entregue]

Mudando Status

<> Cancelando Pedido

Cancelar Pedido <>

UpdateStatus Pedido

Logistica


Workflow de Projeto Diagrama de Atividades O que é Diagrama D iagrama de Atividade? É um diagrama que exibe o fluxo seqüencial das atividades, é geralmente utilizado para demonstrar as atividades executadas por uma operação específica do sistema, como por exemplo seleção de um item do menu principal. Consistem em estados de ação, que contém a especificação de uma atividade a ser desempenhada por uma operação do sistema. Decisões e condições, como execução paralela, também podem ser representados no diagrama de atividade. O diagrama também pode conter especificações de mensagens enviadas e recebidas como partes de ações executadas. Diagramas de atividade capturam ações e seus resultados. Eles focam o trabalho executado na implementação de uma operação (método), e suas atividades numa “instance” de um objeto. O diagrama de atividade é uma variação do diagrama de estado e possui um propósito um pouco diferente do diagrama de estado, que é o de capturar ações (trabalho e atividades que serão executados) e seus resultados em termos das mudanças de estados dos objetos.


Workflow de Projeto Diagrama de Atividades Elementos e Exemplo com comentários: responsabilidades Cliente

Atividade atividade

Vendas

Fazer Pedido

transição

Estoque

atividade Processar Pedido Separar Produtos

separação

Enviar Pedido decisão Receber Pedido

Barras de sincronização

Elementos

Cobrar Cliente

Pagar Fatura Fechar Pedido

junção raias


Workflow de Projeto Diagrama de Atividades Os estados no diagrama de atividade mudam para um próximo estágio quando uma ação é executada (sem a necessidade de especificar nenhum evento). Outra diferença entre o diagrama de atividade e o de estado é que podem ser colocadas como swimlanes (raias). swimlanes (raias). Uma swimlane agrupa swimlane agrupa atividades, com respeito a quem é responsável e onde estas atividades residem na organização, e é representada por retângulos que englobam todos os objetos que estão ligados a ela ( swimlane ). ). Um uma maneira alternativa de se mostrar interações, com a possibilidade Um diagrama diagramade deatividade atividadeé pode ser usado com diferentes propósitos inclusive: de expressar como as ações são executadas, o que elas fazem (mudanças dos estados dos objetos), Para capturar trabalhos que serão executados é disparada (ações). Este quando elas sãoosexecutadas (seqüência das ações),quando e ondeuma elasoperação acontecem ( swimlanes ). ). é o uso mais comum c omum para o diagrama de atividade. 



Para capturar o trabalho interno em um objeto.

• Para mostrar como um grupo de ações relacionadas podem ser executadas, e como elas vão afetar os objetos em torno delas.

• Para mostra mostrarr como como uma “instance” pode ser executada em termos de ações e objetos.

Para mostrar como um negócio funciona em termos de trabalhadores (atores), fluxos de trabalho, organização, e objetos (fatores físicos e intelectuais usados no negócio).



Diagrama de Atividades Atividades não é orientado a objetos, na verdade ele é muito semelhante a um fluxograma.


Workflow de Projeto Diagrama de Atividades Exemplo 2: Receber Pedido

Preencher Pedido

Enviar Fatura

Entrega [pedido urgente]

[senão]

Receber Pagamento Entrega durante a noite

Entrega Regular

Encerrar Pedido


Workflow de Projeto Diagrama de Atividades - Quando Quando utilizar Diagrama Diagrama de Atividad Atividade: e: Como a maioria das técnicas de modelagem comportamental, os diagramas de atividades têm qualidades qualidades e deficiências, a melhor forma de usá-lo é a combinado com outras técnicas. 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 princípio, para programação concorrente. A desvantagem desvantagem destes diagramas é que eles não deixam muito claro c laro as ligações entre as ações e objetos. Você pode definir uma ligação para um projeto rotulando rotulando uma atividade com um nome nome de objeto ou usando raias que dividem uma diagrama de atividades em base em responsabilidades, mas, isso não tem a clareza simples de diagramas de interação.


Workflow de Projeto Diagrama de Atividades Quando utilizar Diagramas de Atividades: Podemos utilizar diagrama de atividade nas seguintes situações: - An Analisand alisando o um caso de uso: uso: Neste estágio, não estamos interessados em alocar ações aos objetos; precisamos simplesmente compreender que ações precisam acontecer e quais são as dependências comportamentais. - Compreend Compreendo o workflow: workflow: Os diagramas de atividades são muito úteis para compreensão de um processo de negócio. - Descrevendo um algoritmo sequencial complicado: complicado: Neste caso, um diagrama de atividades é simples “flowcharts” em notação UML. - Modelando processamento paralelo: Podemos usar o diagrama de atividades para modelar aplicações de processamento paralelo. Quando não é indicado: - Tentando ver como os objetos colaboram: O diagrama de interação é mais indicado. - Tentando ver o comportamento de objeto durante se ciclo de vida: vida: Neste caso o diagrama de estado é o mais indicado.


Workflow de Projeto

Diagrama de Classes. Introdução Apresentaremos e discutiremos o Diagrama de Classes, ele é considerado o artefato mais importante e é que também exige mais esforço para ser construído. O Diagrama de Classes Cl asses é derivado do Modelo Conceitual C onceitual (Workflow de Análise) Agora no Workflow de Projeto o modelo é refinado ganhando adornos, novos tipos de relacionamentos, métodos e até novas classes. Esta atividade tem a seguinte divisão, a qual chamamos de refinamento, são quatro passos. A cada passo faremos alguns refinamentos no modelo. Também será definido alguns conceito durante estes passsos.


Workflow de Projeto Diagrama de Classe. Revisão: •

O diagrama de classe é um elemento estrutural


Workflow de Projeto Diagrama de Classe. Exemplo:


Workflow de Projeto Diagrama de Classe. Revisão: Refinamentos: 1 - Refinamento Refinamento:: Atributos: Acrescentar Acrescentar tipos de dados e visibilidade exemplo: codigo -codigo: int (private int codigo)

Fase de Análise modelo conceitual

2 - Refinamento: Refinamento: Acrescentar: outros tipos de relacionamento entre as classes exemplo: agregação, composição, herança Acrescentar outros elementos como: Seta de navegação, Role Name (papéis) e multiplicidade Pessoa nome

Fase de Projeto Diagrama de Classes

Atributos: Tipo de dados e Visibilidade

Cliente

Cliente

codigo nome

-codigo: int -nome: String

Pedido Data Status Numero 1

+getCodigo() +setCodigo() +getNome() +setNome()

1..n item ItemPedito

<>

Quantidade métodos

Cliente cpf codigo

Relacionamento Herança


Workflow de Projeto Diagrama de Classes. Refinamento 1 - Refi Refina name mento nto:: Exemplo: Atributos e Métodos: Fase de Análise

Fase de Projeto

modelo conceitual

Diagrama de Classes

Cliente codigo nome

Cliente <>


-codigo: int -nome: String +getCodigo() +setCodigo() +getNome() +setNome() +getCliente()

métodos


Workflow de Projeto Diagrama de Classes. Refinamento 1 - Refi Refina name mento nto:: Atributos: Acrescentar tipos de dados e visibilidade e métodos. exemplo: codigo -codigo: int (private int codigo) Método: Definir os Métodos Fase de Análise

Fase de Projeto

modelo conceitual

Diagrama de Classes

Cliente Cliente codigo nome

<>


-codigo: int -nome: String +getCodigo() +setCodigo() +getNome() métodos


Workflow de Projeto Diagrama de Classes. Refinamento 2 - Refi Refina name mento nto:: Acrescentar: outros tipos de relacionamento entre as classes exemplo: agregação, composição, herança Acrescentar: Navegação, Role Name (papéis) e Multiplicidade Fase de Análise

Fase de Projeto

modelo conceitual

Diagrama de Classes

Pessoa nome

PessoaFisica codigo cpf

Pessoa <>

Relacionamento Herança

cpf nome cliente

PessoaFisica codigo

Role name


Workflow de Projeto Diagrama de Classes. Refinamento Herança, Agregação, Composição, Associação Herança: É mecanismo baseado em objetos que permite que as classes compartilhem atributos e operações baseados em um relacionamento, geralmente generalização Uma classe derivada herda a estrutura de atributos e métodos de sua classe “base”, mas pode seletivamente: • adicionar novos métodos • estender a estrutura de dados • redefinir a implementação de métodos já existentes 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. c omportamento.

Herança Curso Universitário extends

Graduação

Podemos dizer que PósGraduação é tipo de Curso Universitário, assim como Curso de Especialização ou de Extensão.

Pós-Graduação

extends

Especialização

Extensão


Workflow de Projeto Diagrama de Classes. Refinamento Herança, Agregação, Composição, Associação EspecialidadeMédica

Tipo de

generalização

Tipo de

Ortopedia

Pediatria

ContaBancaria

Tipo de ContaCorrente

Tipo de ContaPoupança

especialização


Workflow de Projeto Diagrama de Classes. Refinamento Herança, Agregação, Composição, Associação Herança: Quais associações são inválidas:

Cartao

Figura

TipoPagamento

Tipo de

Tipo de Retangulo

Circulo Tipo de Ponto

CartaoCredito Tipo de

CartaoDebito


Workflow de Projeto Diagrama de Classes Avançado Avançado. Refinamento Refinamentos: 3 - Refinamento Refinamento:: Acrescentar: Associação Qualificada (qualificador), associações reflexivas e Constraint (restrições)

4 - Refinamento: Refinamento: Acrescentar: Classes Associativas, Interfaces e Dependência CPF -cpf getCPF() setCPF()

Pessoa -nome: String +getNome() +setNome() { idade > 18}

CPF -cpf getCPF() setCPF()

{ idade > 18}

Cliente -codigo: int -nome: String -idade: int +getCodigo() +setCodigo() +getNome() +setNome() +getIdade() +setIdade()

Livro -isbn -titulo getISBN() setISBN() setTitulo() getTitulo()

*

*

Emprestimo -data -status getData() setDAta() setStatus() getStatus()

Sociio -codigo: int -idade: int +getCodigo() +setCodigo() +getIdade() +setIdade()


Workflow de Projeto Diagrama de Classes. Refinamento 3 - Refi Refina name ment nto: o: Acrescentar: Associação Qualificada (qualificador), associações reflexivas e Constraint (restrições) Associação Qualificada É um equivalente da UML de um conceito de programação conhecido como vetores, árvores binárias, maps ou dicionários. Qualificador é um atributo da associação cujo os valores particionam o conjunto de objetos relacionados a um objeto da associação. Aplicação: Redução de semântica da associação. Também pode ser usado como índice para hash ou vetor, vetor, isto quando, quand o, precisamos ter recurso de pesquisa em uma das extremidades da associação. Nome da associação

Classe atributos

qualificador

papel

0..1 papel

Classe atributos


Workflow de Projeto Diagrama de Classes. Refinamento 3 - Refi Refina name ment nto: o: Acrescentar: Associação Qualificada (qualificador), associações reflexivas e Constraint (restrições) Associação Qualificada Pedido

Produto

0..1

ItemPedido

Linha de item quantidade: int

Qualificador

O exemplo, demonstra uma associação qualificada, entre as classe Produto, ItemPedido. O qualificador diz que em associação com Pedido poder haver um item de pedido cada ocorrência de produto. Conceitualmente, esse exemplo indica que não é possível existir dois itens de pedido com pedido para o mesmo produto. produto. Para fazer acesso a um item de pedido em especifico, é necessário identificar o produto como argumento.


Workflow de Projeto Diagrama de Classes. Refinamento 3 - Refi Refina name mento nto:: Acrescentar: Associação Associação Qualificada (qualificador), Associações Reflexivas e Constraint (restrições)

Associação Reflexiva Uma associação reflexiva (também conhecida como auto-associação) liga objetos da mesma classe. Cada objeto tem um papel distinto nesta associação. papel

Classe

Nome da associação

1 *

papéis

Em uma associação o uso dos papéis é importante para evitar ambigüidade na interpretação da associação. Uma associação reflexiva não indica que um objeto se associa a si próprio (um empregado não é gerente dele mesmo; uma condição não é pré-requisito dela mesma). Associação reflexiva indica que um objeto se associa com outros objetos da mesma classe .


Workflow de Projeto Diagrama de Classes. Refinamento 3 - Refi Refina name ment nto: o: Acrescentar: Associação Associação Qualificada (qualificador), Associações Reflexivas e Constraint (restrições) Associação Reflexiva: Exemplo Supervisão Supervisor

1

Empregado

* Supervisionado

Neste exemplo existe uma associação reflexiva reflexiva objetos de Empregado. Empregado. Nesta associação, há objetos que assumem o papel de supervisor e outros objetos que assumem o papel de supervisionado. O nome da associação pode ser omitido, uma vez que os papéis foram definidos.


Workflow de Projeto Diagrama de Classes. Refinamento 3 - Refi Refina name mento nto:: Acrescentar: Associação Associação Qualificada (qualificador), Associações Reflexivas e Constraint (restrições) Constraint (restrições): Uma restrição é um relacionamento semântica entre elementos de modelo que especifica condições que devem ser satisfeitas. Classe atributos

{ restrição } 0..1 papel

papel

Classe atributos

Duas opções para representar restrições em UML: • Informal, a UML permite usar qualquer notação para representar as restrições, entretanto entretanto , as estas devem ser especificadas dentro dentro de chaves “{ }”, podemos usar a linguagem formal, por exemplo. fornece linguagem formal de restrições restrições de objetos. objetos. (OCL - Object • Formal, UML fornece Constrai Constraint nt Language Language). ). Veja mais: http://www.omg.org/technology/documents/formal/ocl.htm


Workflow de Projeto Diagrama de Classes. Refinamento 3 - Refi Refina name ment nto: o: Acrescentar: Associação Associação Qualificada (qualificador), Associações Reflexivas e Constraint (restrições) Constraint (restrições): Por ser um mecanismo de extensão da UML, certos tipos de restrições já estão definidos, tais como: complete, destroyd, disjoint, implicit, incomplete, new, new, or overlapping e transient. Veja o exemplo: da restrição

Contrato

“ou”.

atributos { ou }

0..1

0..1

Pessoafisica

PessoaJuridica

atributos

atributos


Workflow de Projeto Diagrama de Classes. Refinamento 4 - Refi Refina name mento nto:: Acrescentar: Classes Associativas, Interfaces e Dependência Classe Associativa Em associação entre duas classes, a própria associação poderá ter propriedades. Essas propriedades são originadas a partir da associação de classes com a multiplicidade de: muitos:muitos, para expor a representação destas propriedades é implementado uma nova classe que é resultante da associação, assim como seus atributos e métodos. Classe Classe * * atributos

atributos

Nome da Associação

atributos

Classe de Associação


Workflow de Projeto Diagrama de Classes. Refinamento 4 - Refi Refina name mento nto:: Acrescentar: Classes Associativas, Interfaces e Dependência Classe Associativa Exemplo Associação de muitos:muitos

Produto

*

*

atributos

Fornecedor atributos

ProdutoFornecido

atributos

Classe de associação


Workflow de Projeto Diagrama de Classes. Refinamento 4 - Refi Refina name mento nto:: Acrescentar: Classes Associativas, Interfaces e Dependência Interface: O que é interface ? (Representa (Representa a forma mais pura pura de abstração de dados - Linguagem Linguagem Java)

Interface é um contrato entre o cliente, onde o cliente pode ser classe concreta ou abstrata. Este contrato é garantia que o métodos assinados na interface serão implementados na classe cliente. O relacionamento entre uma interface e uma classe é chamada de realização. <>

Nome Interface

Estereotipo e nome da interface

Métodos (assinatura) Assinatura do métodos

public ic stat static ic fina final l ). Nota: Na interface também podemos declarar constantes ( publ ).


Workflow de Projeto Diagrama de Classes. Refinamento 4 - Refi Refina name mento nto:: Acrescentar: Classes Associativas, Interfaces e Dependência Interface: Exemplo Interface, realização e classes <>

PessoaJuridica getCNPJ() setCNPJ() setContrato() getContrato()

Realização

Fornecedor

PrestadorServico

atributos

atributos


Workflow de Projeto Diagrama de Classes. Refinamento 4 - Refi Refina name mento nto:: Acrescentar: Classes Associativas, Interfaces e Dependência Dependência: Uma dependência é um relacionamento de utilização, determinando as modificações na especificação de um item, mas não necessariamente o inverso. Utilizamos o relacionamento de dependência no contexto das classes para mostrar que uma classe usa outra como argumento na assinatura de uma operação.

FilmClip play(c: Channel) start() stop() pause() dependência

Channel


Workflow de Projeto Diagrama de Classes. Outros conceitos : Granularidade Granularidade: Geralmente para cada atributo criamos um par de métodos getter e getter e setter , estes métodos garantem o encapsulamento dos dados. Entretanto, Entretanto, quando estamos em um ambiente distribuído (de rede), fazer a manipulação de de vários e métodos e atributos, um a um, pode causar um péssimo péssi mo desempenho, temos que considerar latência de rede, largura de banda e etc. Para evitar esta situação podemos criar um método chamado c hamado getCliente(), que contempla todos os dados do cliente, desta forma estaríamos fazendo um única requisição. Desta forma temos a seguinte estrutura granular: Granularidade Grossa: Manipulação através de único método que encapsula todos os atributos da classe. Granularidade Fina: Fina: Cada atributo tem seu par de método. m étodo.


Workflow de Projeto Diagrama de Classes. Granularidade Granularidade: Exemplo

Cliente -codigo: int -descricao: String

Granularidade Grossa

+getCodigo() +setCodigo() +getDescricao() +setDescricao()

+getCliente()

Granularidade Fina


Workflow de Projeto Diagrama de Classes. Construtores: O que são construtores? Construtores são um tipo especial de método usado para inicializar uma “ instance” da classe. Toda a classe deve ter um Construtor. Quando não declaramos o “Construtor default”, que é inicializado automaticamente automaticamente pelo Java. Mas existem casos que se faz necessário a declaração explícita dos construtores.

Cliente

Tipo

- codigo codigo:: int int - nom nome: e: String String - tipo: tipo: Tipo Tipo <> +Cliente(codigo: int, nome: String) +Cliente(codigo: int, nome: String, tipo: Tipo)

-descricao: String

<> + getCodigo(): int + getNome(): String + setCodigo(int codigo) + setNome(String nome) + getTipo(): Tipo + setTipo(tipo Tipo) + getCliente(): String

+getDescricao(): String +setDescricao(d: String)

dependência


Workflow de Projeto Diagrama de Classes. Construtores: Restrição: O Construtor não pode ser herdado. Para chamá-lo a partir de uma subclasse usamos a referência super.

Para escrever um construtor, construtor, devemos seguir algumas regras: 1ª O nome do construtor precisa ser igual ao nome da classe; 2ª Não deve ter tipo de retorno; 3ª Podemos escrever vários construtores para mesma classe.

public class Mamifero { private int idade; public Mamifero(int idade) { this.idade = idade; }

//Métodos }

construtor


Workflow de Projeto Diagrama de Classes. Construtores: Quantos construtores pode ter uma classe ? Uma classe pode ter vários construtores, entretanto, eles devem seguir s eguir a regra de overloading; 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() { }

//Métodos }

construtores


Workflow de Projeto Diagrama de Classes. Propriedades: Propriedades dos Atributos: Existem três propriedades definidas que poderão ser utilizada como os atributos:

- Change Changeabl able: e: Não há restrições para se modificar o valor do atributo. - addOnly: No caso de atributos com multiplicidade maior do que um, valores adicionais poderão ser incluídos, mas uma vez criado, o valor não poderá ser removido ou alterado.

- Froz Frozen en:: O valor do atributo não pode poderá ser modificado depois que o objeto for iniciado TaxaJuro - valor: valor: doub double le {frozen} <> + getValor(): double + setValor(double setValor(double valor)

Propriedade


Workflow de Projeto Diagrama de Classes. Propriedades: Propriedades dos Atributos: Existem três propriedades definidas que poderão ser utilizada como os atributos:

- Change Changeabl able: e: Não há restrições para se modificar o valor do atributo. - addOnly: No caso de atributos com multiplicidade maior do que um, valores adicionais poderão ser incluídos, mas uma vez criado, o valor não poderá ser removido ou alterado.

- Froz Frozen en:: O valor do atributo não pode poderá ser modificado depois que o objeto for iniciado TaxaJuro - valor: valor: doub double le {frozen} <> + getValor(): double + setValor(double setValor(double valor)

Propriedade


Workflow de Projeto Diagrama de Classes. Propriedades: Propriedades dos Atributos: Implementando a propriedade Frozen em Java: TaxaJuro - valor: valor: doub double le {frozen} <> + getValor(): double + setValor(double setValor(double valor)

Modificador Final (constantes) Para declarar uma variável, um ou uma classe como constante usamos constante usamos o modificador final. Entretanto, o uso deste modificador deve obedecer a certas restrições como: • Uma classe constante não pode ter subclasses; • Um método constante não pode ser sobrescrito; • O valor para variável constante deve ser definido no momento da declaração ou através de um construtor, para variáveis membro, uma vez atribuído o valor, este não mudará mais. public public class class TaxaJur axaJuroo { private final double double VALOR; public TaxaJuro( axaJuro(double double valor) valor) { VALOR = valor; } public public static static void void main( main(Str String ing args[] args[])) { TaxaJuro taxa = new TaxaJuro(21.30); axaJuro(21.30); System.out.println(taxa.VALOR); } }


Workflow de Projeto Diagrama de Classes. Propriedades: Propriedades dos Atributos: Exercício: Implementando a propriedade Frozen em Java, implemente também os métodos set e get e tente mudar o valor da atributo. TaxaJuro - valor: valor: doub double le {frozen} <> + getValor(): double + setValor(double setValor(double valor)


Workflow de Projeto Diagrama de Classes. Delegação: Definição de Delegação: A habilidade de um objeto enviar uma mensagem a outro objeto como resposta a uma mensagem. O reúso de propriedades de uma classe pode ser realizado não só através do mecanismo generalização entre as classes, mas também através do mecanismo de delegação. O reúso por generalização se baseia na estrutura de superclasse e subclasse, onde a subclasse herda todos os métodos e atributos da classe “pai” (superclasse).

Recomendamos usar o mecanismo de delegação em algumas situações: • Para não violar regra de encapsulamento; • Para não sobrecarregar de responsabilidade uma classe; • Para atender a semântica da classe e • Favorecer o mecanismo de reúso. A seguir veremos um exemplo completo, onde a aplicação do mecanismo de delegação é melhor solução para obedecermos as regras da orientação a objetos.


Workflow de Projeto Diagrama de Classes. Delegação: No Modelo Conceitual devemos identificar os candidatos a classe e seus respectivos conceitos. Entretanto, devemos antes lembrar da definição da classe. Classe A descrição de conjunto de objetos que compartilham os mesmos atributos, operações, relacionamento e semântica.

Temos a primeira sugestão do modelo, como classe Cliente fazendo uma associação a Senha.

Cliente codigo nome

possui

Senha senha


Workflow de Projeto Diagrama de Classes. Delegação: Em segunda sugestão de modelo, como classe Cliente tem como atributo senha, desta forma a classe Senha não seria necessário.

Cliente codigo nome senha

Quais são as implicações que o atributo “senha” pode causar ao modelo ?


Workflow de Projeto Diagrama de Classes. Delegação: Ao modelarmos devemos ter os seguintes cuidados: 1 - Identificar Identificar todas classes classes que fazem uso ou que tem um determinado determinado atributo, atributo, neste caso, Cliente e Funcionário tem o atributo “senha”. Isto deve está explícito no documento “Domínio do Problema”. Veja o exemplo:

Conceito diferente

Cliente

Funcionario

codigo nome

codigo-funcional nome

senha

senha

O mesmo conceito


Workflow de Projeto Diagrama de Classes. Delegação: Ao modelarmos devemos ter os seguintes cuidados: (continuação) - Uma sugestão sugestão para solução solução do problema: problema:

Pedido

HistoricoCliente

Cliente

Funcionario

codigo nome

codigo-funcional nome

possui

Senha senha

possui


Workflow de Projeto Diagrama de Classes. Delegação: Ao modelarmos devemos ter os seguintes cuidados: (continuação) 2 - Uma vez que senha é um atributo de de cliente como podemos podemos implementar implementar regras de negócio a senha, se implementarmos dentro da classe Cliente, teríamos um erro de conceito (semântica). (semântica ). Veja Veja o exemplo:

Cliente codigo nome senha qde_dias_expiracao_senha

Este atributo somente é regra que se aplica somente a senha e não a cliente.


Workflow de Projeto Diagrama de Classes. Delegação: Ao modelarmos devemos ter os seguintes cuidados: (continuação) 3 - Reús Reúso: o: - O atributo senha poderá poderá ser utilizado por outra outra aplicação, que que nem sempre deverá deverá ver os outros atributos de cliente.

Cliente codigo nome senha

Podemos concluir, que no exemplo apresentado duas regras da orientação a objetos foram violadas: - Semâ Semânti ntica ca e - Baixo Baixo reúso reúso


Workflow de Projeto Mitos e Lendas

e r a w t f o S e O que é dito: d - Modelo de entidade e relacioname relacionamento nto (MER), deve deve ser feito antes do diagrama diagrama de a classes. i r a h n Entretanto, a realidade é outra... e g n E Quando estamos a metodologia de orientação a objetos os dados são o Assim o “MER” deve ser derivado do modelo de ã encapsulados. Assim ç classes. a t i c a p a C


Arquitetura de Software Objetivo desta parte: É apresentar e discutir Arquitetura Arquitetura de Software, conceitos modelos e técnicas


Workflow orkflow Arquitetura Arquitetur a Objetivo: Apresentar e discutir a Arquitetura de Software. Arquitetura é parte do Workflow de Projeto, nesta fase criamos os componentes, modelos físicos e como serão distribuídos. Os principais diagramas UML são: - Di Diag agra rama ma de Dep Deplo loym ymen entt e - Diagrama Diagrama de Componente Componentes. s. Também nesta fase refinamos o Modelo de Arquitetura. Arquitetura. Objetivo primário da arquitetura é atender os requisitos não funcionais. O artefato deste passo é: - Modelo de Arquitetura Arquitetura..


Workflow orkflow Arquitetura Arquitetur a Big Picture. Arquitetura Projeto (Visão Lógica)

Arquitetura

Diagramas

Projeto (Visão de Componentes e Visão de Deployment)

4

ReceberPedido

: visitante

: FormBusca

: Ca et go ir a

: Po r du ot

PreencherPedido

: Ca at ol go

EnviarFatura

getDescricao()

Entrega

exibirCategoria() selecionarCategoria

getDescricao()

[pedido urgente]

[ senão]

getQuantidade()

ReceberPagamento

exibirProduto()

selecionarProduto()


EntregaRegular

EncerrarPedido

Diagrama de Componentes Diagrama de Deployment


Workflow orkflow Arquitetura Arquitetur a

Arquitetura Workflow

Arquitetura

Artefatos

Papéis

Digrama de Componentes Analista de Sistema Projetista de Software


Modelo de Arquitetura

Arquiteto de Software


Workflow orkflow Arquitetura Arquitetur a Introdução. UML, Visões:

Visão de Projeto






Workflow orkflow Arquitetura Arquitetur a Introdução. UML, Visões:

e r a w t f o Visão de Implementação S e • A visão de implementação de um sistema abrange os componentes e os arquivos utilizados d para a montagem e fornecimento do sistema físico. Essa visão envolve principalmente o a i r gerenciamento da configuração das versões do sistema, compostas por componentes e a h arquivos de alguma maneira independentes, que podem ser reunidos de diferentes formas para n e a produção de um sistema executável. g n E o Visão de Implantação ã ç a • A visão de implantação de um sistema abrange os nós que formam a topologia topologia de hardware em t i c que o sistema é executado. Essa visão direciona principalmente a distribuição, o fornecimento e a a p instalação das partes que constituem o sistema físico. Com a UML, os aspectos estáticos dessa a C visão são representados em diagramas de implantação; os aspectos dinâmicos são capturados em

diagramas de interações, de gráfico de estados e diagramas de atividades.


Workflow orkflow Arquitetura Arquitetur a Introdução. UML, Visões: Cada uma dessas visões pode ser considerada c onsiderada isoladamente, permitindo que diferentes participantes orientem seu foco para os aspectos da arquitetura do sistema que mais lhes interessem. Essas cincos visões também interagem entre si, por exemplo: Os nós na visão de implantação contêm componentes da visão de implementação implement ação que, por sua vez,

representa a realização física de classes, interfaces, colaborações e classes ativas provenientes das visões de projeto e de processo.


Workflow orkflow Arquitetura Arquitetur a Modelo de Inicial de Arquitetura Na Análise fizemos um o Modelo de Arquitetura Inicial para aplicação. O objetivo deste modelo é apresentar um visão macro da arquitetura. Os modelos de Caso de Uso e Modelo Conceitual são utilizados para desenhar este o Modelo de Arquitetura. Uma visão inicial da arquitetura pode ter muita formas, podemos utilizar a UML para representar este modelo ou qualquer outra notação. Este modelo será refinado no workflow de arquitetura na Atividade “Refinar o Modelo de Arquitetura”. Arquitetura”.

Passos: 1 - Selecionar Selecionar o Modelo Modelo de Arquitet Arquitetura ura 2 – Refinar o Modelo de Arquitetura Inicial.


Workflow orkflow Arquitetura Arquitetur a Decomposição e Camadas Decomposição: A decomposição refere-se à fragmentação de uma aplicação ou sistema em partes menores e lógicas facilitando gerenciar a complexidade. Os módulos, os subsistemas e componentes são bom exemplo de decomposição. A decomposição decomposição ajuda a definir e a esclarecer as interfaces entre as diferentes partes de um sistema. Também Também pode ser útil nas situações em que você tem de integrar com o legado e ou aplicações de terceiros. A decomposição pode pode também auxiliar auxili ar na distribuição do software em diversos processadores. A decomposição ajuda na distribuição de responsabilidades e papéis na equipe de desenvolvimento. As desvantagens: As decomposições inadequadas ou excesso pode levar facilmente facilm ente a uma grave degradação do desempenho devido ao “overhead” de comunicação. Na UML a decomposição pode ser representada através do diagrama de pacotes e subsitemas.


Workflow de Arquitetura UML. Diagrama de Pacotes Como podemos definir o diagrama de pacotes? A definição de Pacote é uma generalização, ou seja, um agrupamento, com o propósito de organizar as Classes de Objetos em grupos. Esta abordagem facilita a análise a medida que o número de Classes de Objetos cresce num do cenário. O tipo de relacionamento é linha pontilhada com uma seta que indica dependência. dependência. Os diagramas de pacote podem ser usados para fazer decomposição funcional. A nota notaçã çãoo usad usadaa pela ela UML UML para ara rep represe resenntar tar paco pacote tess é:

Nome do Pacote

Nome do Pacote

Nome do Pacote Nome do Pacote



Workflow de Arquitetura UML. Diagrama de Pacotes Decomposição. “Dividir para conquistar...”

Algumas aplicações podem ser enormes ou ter um grau muito mui to alto de complexidade ou ambas as coisas. Para facilitar é necessário fazer uma decomposição. A idéia da decomposição é simples. É fazer uma divisão para simplificar si mplificar o entendimento, a modelagem ou processo de desenvolvimento de um software. Veja o exemplo abaixo:

Contas a Pagar

Fluxo de Caixa Nome do Pacote

Subsistema

Contas a Receber



Workflow orkflow Arquitetura Arquitetur a Separação em camadas Camada: Uma aplicação de grande escala pode ser complexo e difícil de desenvolver e gerenciar. A camada é um padrão para a decomposição. A decomposição leva uma fragmentação lógica do sistema em subsistemas e módulos, e as camadas agrupam e separam esses subsistemas, assim limitando quem pode usar os subsistemas, componentes e módulos. O Rational Rational Unified Unified Process Process (RUP) ou simplesmente simplesmente UP identif identifica ica duas duas abordage abordagens ns para para a camada: - Camada Camada baseada em responsab responsabilidade ilidade e - Camada Camada baseada baseada em reúso. reúso. Camada baseada em responsabilidade: Estas as camadas são bem definidas, significando que cumprem um papel específico no esquema geral das coisas. Tais Tais camadas também são conhecidas como níveis. Níveis: Os níveis podem ser mapeados para as camadas baseada em responsabilidades, neste caso um nível torna-se sinônimo de cumprir um papel específico no sistema, como a apresentação, a lógica de negócio, apresentação e etc. Uma arquitetura baseada em níveis facilitam a manutenção, disponibilidade dis ponibilidade e separação de funcionalidades e de papéis de uma aplicação


Workflow orkflow Arquitetura Arquitetur a Separação em camadas Níveis: A forma forma de se conseguir a distribuição em arquitetura com n níveis é alinhar as camadas específicas com cada nível, exemplo: - O nível de cliente, cliente, lida com interação interação com usuário usuário - O nível de apresentação, lida com apresentação dos dos dados - O nível de negócio, contém as regras de negócios negócios e as entidades entidades - O nível de dados, fornece a interface para para armazenamento de dados

<> Cliente

<> Apresentação

<> Negócios

<> Dados


Workflow orkflow Arquitetura Arquitetur a Pattern. Mode Modell View iew Cont Contrrolle ollerr Aplicação do MVC (Model, View e Controller) O padrão MVC originou da linguagem Smalltalk e foi usada para projetar interfaces com usuário. Esta interface é divida em três partes: model, model, view e controller. controller. Onde: Model: Model: Representa o dado ou objeto. Ele é que manipula e objetos, exemplo: JavaBeans e EJB. View: View : É visão de como os dados serão apresentados, exemplo: páginas JSP e ASP Controller: Controller: Recebe as requisições, faz validação e define o model que manipulará os dados. Algumas vantagens do MVC: - Decomp Decomposi osição ção;; - Reús Reúsoo; - Possibilita Possibilita o desenvolvime desenvolvimento nto em paralelo; paralelo; - Separação Separação de responsabilid responsabilidades ades e papéis; papéis; - Isolamento Isolamento e separação separação das das camadas camadas e - Baixo Baixo acoplame acoplamento nto.. MVC podem ser implementado de duas maneiras o modelo 1 e modelo 2, 2, como veremos a seguir s eguir..


Workflow orkflow Arquitetura Arquitetur a Model View Controller. Model 1 cl iente faz uma requisição para uma página dinâmica (JSP ou ASP) que pode Model 1: 1: O cliente chamar um model (componente) (componente) ou outra página dinâmica que faz algum processamento e devolve para cliente a resposta

View

View

Web Server

View Model


Workflow orkflow Arquitetura Arquitetur a Model View Controller. Model 2 c amada controller que redireciona para Model 2: 2: O cliente faz uma requisição para a camada camada model que executa algum processamento e retorna para controller que gera uma página dinâmica (JSP ou ASP) que é devolvida como a resposta ao cliente

View

View

Controller Componentes (Model)

View

Web Server


Workflow orkflow Arquitetura Arquitetur a Model View View Controller Aplicação do MVC em ambiente de três camadas (Web) View: Visão representa a apresentação (interface com usuário) de uma aplicação. O componentes da View obtém os valores do estado do Model. Separação do View e do Model habilita a construção independente interfaces com skins). Diferentes Diferentes Views podem podem interagir interagir diferentes “Look and Feel” (aparências - skins). com mesmo model. JSP é escolha natural para implementação do View Controller: O Controller fornece a ligação da arquitetura MVC. Ela é responsável por receber receber as requisições e determinar qual o Model apropriado para atende-la. Ele também poder tratar a resposta.


Workflow orkflow Arquitetura Arquitetur a Model View Controller Aplicação do MVC (Model, View e Controller) Model: O modelo representa as regras de negócios de uma aplicação. Encapsulando as regras dentro de um componente facilita os testes, melhora a qualidade e promove o reúso de componentes. Estado do componentes (model): O estado define um conjunto de valores do Model e inclui métodos para mudar estes valores. Estes métodos são regras de negócios e outros métodos. O “estado” de componente são geralmente um protocolo independente. Na

tecnologia Java os JavaBeans e os EJBs são uma boa escolha para implementar estes componentes. Na tecnologia .Net (Microsoft) podemos usar os componentes COM+


Workflow orkflow Arquitetura Arquitetur a Introdução: O papel da d a Arquitetura: Arquitetura:

e r a w t f o S e Os softwares podem ter arquitetura e ambiente simples, ou seja, “rodar” um único servidor servi dor d a e em diversas estações clientes em ambiente de rede local. i r Atualmente, os softwares podem ter uma arquitetura mais complexa, ou seja, eles podem a r ede distribuída, com diversos servidores, quando h ser distribuídos, ou seja, rodar em uma rede n alocamos algum recurso remotamente (componentes, por exemplo), temos que garantir o e criti ca. g funcionamento (desempenho) deste software é missão mais difícil e até critica. n E o O papel do “Arquiteto de Software” é garantir o funcionamento do software e atendimento ã pleno dos Requisitos Não Funcionais (Desempenho, “Escalabilidade”, Confiabilidade, ç a Segurança e etc) e das Restrições, Restrições, como uso de determinada tecnologia (protocolos, t i c linguagens de programação, banco de dados e etc) a As responsabilidades do Arquiteto Arquiteto de Software: p a - Selecionar uma tecnologia adequada e projetar um modelo robusto, flexível flexível e eficiente. C - Propor um plano de redução de risco.Um ambiente complexo tem um risco maior, maior, cabe ao

Arquiteto desenvolver um plano para redução de risco. - O Arquitet Arquitetoo também deve deve sugerir sugerir o uso de Patterns de Arquitetura que são as boas práticas para a construção do Modelo.


Workflow de Arquitetura Princípios: Existem diversos princípios que podemos aplicar a arquitetura de software, entretanto existem dois que se destacam: - Separação de Camadas e - Princípio da Dependência Inversa.


Workflow orkflow Arquitetura Arquitetur a Arquitetura.Road Arquitetura.Road Map

Modelo de Especificação Documentos de Requisitos

Modelo de Arquitetura Inicial

Caso de Uso

Digrama de Deployment

Fazer Diagramas

Digrama de Componentes

Fazer Modelo de Arquitetura

View

Controller

Model

Resources

JSP/HTML

Servlet

EJB

Banco de Dados


Workflow orkflow Arquitetura Arquitetur a Arquitetura. Atividades e Passos: Fazer Modelo Arquitetura Arquitetura Selecionar uma Arquitetura Modelo de Arquitetura Inicial

Fazer Diagrama de Deployment

Digrama de Deployment

Fazer Diagrama de Componentes

Digrama de Componentes

Refinar Modelo de Arquitetura (RNFs) Refinar o Modelo de Especificação Modelo de Arquitetura


Workflow orkflow Arquitetura Arquitetur a Diagrama de Deployment O que é Diagrama de Deployment? Variações Variações tradução: • Diagrama de Deployment <=> Diagrama de Implantação • Diagrama de Deployment <=> Diagrama de Distribuição

É um diagrama que exibe a arquitetura física do hardware hardware e do software software no sistema. Pode apresentar os computadores e periféricos, juntamente com as conexões que eles estabelecem entre si. Podemos mostrar também os tipos de conexões entre esses computadores. Especifica-se os componentes executáveis e objetos que são alocados para exibir quais unidades de software são executados e quais computadores. O diagrama de deployment demonstra a arquitetura “runtime” de processadores, dispositivos físicos e de software que executam no ambiente onde o sistema desenvolvido será utilizado. É o último diagrama da topologia topologia do sistema, descrevendo a estrutura de hardware e software que executam em cada unidade.


Workflow orkflow Arquitetura Arquitetur a Diagrama de Deployment Elementos: c apacidade de Processor (Processador): É qualquer máquina que possua a capacidade processamento. Os servidores, estações de trabalho por exemplo. Servidor

processador

finali dade ou finalidade limita. Os Device (Dispositivo): É qualquer máquina com finalidade dispositivos são os itens como impressoras, roteadores, raids, storages, s torages, scanners, leitoras de código de barra e etc. Impressora

Dispositivo


Workflow orkflow Arquitetura Arquitetur a Diagrama de Deployment Elementos: Connection (conexão): conexão): A conexão é o vinculo entre processadores e dispositivos. Geralmente representam as conexões de rede físicas (rede local ou distribuída). estereotipo

Cliente

<>

Servidor

<>

conexão

Processador (Nó)

Impressora

Dispositivo (Nó)


Workflow orkflow Arquitetura Arquitetur a Diagrama de Deployment Elementos: Os processadores e os dispositivos podem ser chamados de nó. Um nó é um elemento físico que existe em tempo de execução e representa um recurso r ecurso computacional. <> WebBrowser

<> Apache <>

<> Impressora

Nós <> JBoss

<>

<> Cliente

<> Oracle


Workflow orkflow Arquitetura Arquitetur a Diagrama de Deployment O diagrama de Deployment pode ser substituído por outro diagrama que exibam com maiores detalhes e/ou com ícones mais apropriados. Apesar de não ser uma boa recomendação, pois, estaríamos deixando de lado a UML, mas em algumas vezes se s e faça necessário.

WebServer Apache

Banco de Dados

Oracle Application Server JBoss


Workflow orkflow Arquitetura Arquitetur a Diagrama de Deployment & Diagrama de Componentes Adicionando ao Diagrama de Deployment o “Diagrama de Componentes”, podemos ter uma visão mais “clara” da arquitetura baseada na UML


Workflow orkflow Arquitetura Arquitetur a Diagrama de Componentes. Introdução: Os componentes são utilizados para a modelagem de coisas físicas que podem residir em nó, como executáveis, bibliotecas, tabelas, arquivos e documentos. Um componente tipicamente representa o pacote físico de elementos lógicos, como classes, interfaces, colaborações. Bons componentes definem abstrações com interfaces bem-definidas, desta forma é possível atualização de componentes, ou seja, trocar os componentes mais velhos por outros componentes mais novos ou por novas versões. Componente A

Dependência

Componente genérico

Componente B

Nome do componente


Workflow orkflow Arquitetura Arquitetur a Diagrama de Componentes O que é um Diagrama de Componentes? É um diagrama que exibe o sistema por um lado funcional, expondo as relações entre seus componentes e a organização de seus módulos durante sua execução. O diagrama de componente descreve os componentes de software e suas dependências entre si, representando a estrutura do código gerado. Eles são tipicamente os arquivos implementados no ambiente de desenvolvimento. Diagrama de componente representa uma visão física, é um pedaço de software de sistema e seus relacionamentos. Quando um componente colabora com outro componente, está colaboração é ilustrada com uma dependência entre o componente cliente e o componente de serviço. ReservaUI Dependência

Room

ReservaService

Reserva Service_ stub

Component

Interface


Workflow orkflow Arquitetura Arquitetur a Diagrama de Componentes. Definições: Componente: Um componente é a parte física e substituível de um sistema ao qual se adapta e fornece a realização de um conjunto de interfaces. i nterfaces. Interfaces: Uma interface é coleção de operações utilizadas para especificar um serviço de uma classe cl asse ou de um componente. O relacionamento entre componente e interface é muito importe. As tecnologias mais populares usam interfaces na implementação de componentes, tais como: - Enterprise Java Beans; - Corb Corbaa (CCM) (CCM) e - Microso Microsoftft COM+ COM+..


Workflow orkflow Arquitetura Arquitetur a Diagrama de Componentes. Exemplo: CatalogHome

Catalog Home Stub

Catalog.jsp

CatalogHome

Catalog EJB Home

Catalog Business Delegate CatalogRemote

Catalog Remote Stub

CatalogRemote

Catalog EJB Object

Catalog Bean

CatalogRemote


Workflow orkflow Arquitetura Arquitetur a Diagrama de Componentes Tipos de Componentes: Existem três tipos de componentes: - Componentes de Implantação: Implantação: São os componentes necessários para montar um sistema executável, como as DLLs e os arquivos EXEs. A definição da UML para componentes é abrangente, inclui componentes mais populares (COM+, CCM e EJB), além de modelos alternativos como páginas web, tabelas de banco de dados e etc... CheckIT.exe {versão 1.}

Video.dll

Disk.dll Floppy.dll


Workflow orkflow Arquitetura Arquitetur a Diagrama de Componentes Tipos de Componentes: (continuação) - Componentes do Produto do Trabalho: Trabalho: Esses componentes são essencialmente o é parte do processo de desenvolvimento, formados por arquivos de código fontes, arquivos de dados, ícones. Esses componentes não fazem parte (diretamente) em sistema executável, mas são os produtos de desenvolvimento, usados para criação do sistema executável. Cliente.class Conta.class

Conta.jar {versão 1} Historico.class

Conta.java

- Componentes de Execução: Execução: Esses componentes são criados como uma conseqüência de um sistema em execução, como um componente COM+, que é sofre “instance” a partir de uma DLL.


Workflow orkflow Arquitetura Arquitetur a Diagrama de Componentes. Elementos: Elementos: A UML define cinco estereótipos-padrão que se aplica aos componentes: 1 - Executável: Especifica um componente que poderá ser executado em um nó 2 - Biblioteca: Especifica uma biblioteca de objetos estática ou dinâmica 3 - Tabela: Especifica um componente que representa uma tabela de banco de dados 5 - Arquivo: Especifica um componente que representa um documento contendo código-fonte ou dados 6 - Documento: Especifica um componente que representa um documento.


Workflow orkflow Arquitetura Arquitetur a Diagrama de Componentes Tipos de Componentes: - Componente: Componente: O ícone de componente representa um módulo (pedaço) de software com uma interface bem definida. Na especificação de componente definimos o estereótipo como: ActiveX, Applet, Application, DLL e EXE. Nome do Componente


- Especificação e corpo do subprograma: subprograma : Estes ícones representam a especificação visível de um subprograma e o seu corpo de implementação. i mplementação. Um subprograma costuma ser uma coleção de sub-rotinas. Os subprogramas não contém c ontém definições de classe. New NewSubpr ubprog ogSp Speec

NewS ewSubpr ubprog ogB Body


Workflow orkflow Arquitetura Arquitetur a Diagrama de Componentes Tipos de Componentes: - Programa Principal: Principal: Este ícone representam o programa principal. princi pal. Um programa principal que contém a raiz de um programa. Na linguagem Java seria o programa que tem o método “main”. MainProgram

Programa princial (método main)

- Especificação e corpo do pacote: pacote : Um pacote é a implementação impl ementação de uma classe. Uma especificação de pacote constitui-se em um arquivo de cabeçalho, o qual contém as informações referentes ao protótipo de função para a classe. Package Specification

Na linguagem C++, as especificações de pacote são os arquivos .h (header). Em Java usamos o ícone de especificação de pacote para representar os arquivos .java

Package Body

Um corpo de pacote pode apresentar o código para as operações da classe. Em C++, os corpos de pacotes são os arquivos .cpp


Workflow orkflow Arquitetura Arquitetur a Diagrama de Componentes Tipos de Componentes: - Especificação e corpo da tarefa: Estes ícones representam os pacotes que possuem linhas independentes de controle. Uma arquivo executável é geralmente representado como uma especificação de tarefa com uma extensão .exe NewTaskS skSpec

NewTaskB skBody

Além de modelar o componente propriamente dito, podemos modelar o relacionamento entre o componente e sua interface. Veja o exemplo abaixo:


Interface


Workflow orkflow Arquitetura Arquitetur a Arquitetura.Diagrama de Componentes. Exemplo: Neste exemplo criaremos um diagrama de componentes para a funcionalidade “cesta de compra”. Neste momento identificaremos as classes que são necessárias para realizar o caso de uso “adicionar item na cesta de compra”. Como alguns

casos de usos são embutidos, novos componentes serão adicionados ao diagrama. A tecnologia deste exemplo é Java. Component view

Boundary

Services

Entities

Visão principal do Diagrama de Componentes


Workflow orkflow Arquitetura Arquitetur a Arquitetura.Diagrama de Componentes. Exemplo: Todos os componentes do pacote Entities. Entities. Esses são os componentes que conterão as classes de entidades. entidades. Component view Cesta

Entities

Cesta Item

As classes Entidades

Produto


Workflow orkflow Arquitetura Arquitetur a Arquitetura.Diagrama de Componentes. Exemplo: Todos os componentes do pacote Services. Services. Esses são os componentes que conterão as classes de serviços ou de controle. controle . Component view CestaService

Services

ProdutoService

As classes de Serviços ou Controle


Workflow orkflow Arquitetura Arquitetur a Arquitetura.Diagrama de Componentes. Exemplo: Todos os componentes do pacote Boundaries. Boundaries. Esses são os componentes que conterão as classes de Boundaries (ou de interface com usuário). usuário) . Component view

CestaInterface Boundary

As classes de Interfaces


Workflow orkflow Arquitetura Arquitetur a Arquitetura.Diagrama de Componentes. Exemplo: Uma visão dos componentes e relacionamentos MainProgram

CestaInterface

CestaService ProdutoService

Cesta

Cesta Item

Produto


Workflow orkflow Arquitetura Arquitetur a Arquitetura.Diagrama de Componentes. Exemplo: Um novo exemplo, o cenário fazer Reserva de apartamento.

View

Menu Principal

ReservaUI

Controller

ReservaService ClienteService

Model

Cliente

ApartamentoService

Reserva

Apartamento


Workflow orkflow Arquitetura Arquitetur a Diagrama de Componentes. Identificação de Componentes: Componentes: Componentes são grupos de classes que representam uma funcionalidade funcionali dade dentro de sistema. Como faço o diagrama de componentes ?

Componentes

Componentes são identificados usando coesão e acoplamento. Grupos de classes que exigem alta coesão e baixo acoplamento formam um componente. Como identificar os componentes ?

Na fase de Projeto Projet o os componentes são desenhados da seguinte forma: • O Diagrama de Classe são revisados e grupos de classes são identificados usando coesão e acoplamento . • Este grupos representaram os componentes.


Workflow orkflow Arquitetura Arquitetur a Conceitos: Acoplamento e Coesão Independência Independência Funcional

Independência Funcional: •Coesão e • Acoplamento

Conceito que está diretamente relacionado a modularidade, abstração e encapsulamento encapsulamento de informação. Principais características: – função de propósito único. – Interfaces simples quando visto de outras partes da estrutura do programa. – É medida usando-se dois critérios qualitativos: coesão e acoplamento .

Coesão e Acoplamento ajudaram na divisão de classe dentro de componente.


Workflow orkflow Arquitetura Arquitetur a Conceitos: Acoplamento e Coesão Coesão (High Cohesion) É uma medida de força funcional relativa de um módulo. Uma classe coesiva executa uma única tarefa, exigindo pouca interação com outras classes ou objetos. Alta coesão é o desejável. Como manter a alta coesão ?


- Solução: Atribuir Atribuir uma responsabilidade de forma que a coesão permaneça alta. Como manter a complexidade sob controle ?

Em termos de projeto orientado a objetos, a coesão c oesão (ou mais especificamente, coesão funcional) é uma medida de quão fortemente relacionadas e focalizadas são as responsabilidades responsabili dades de uma classe. Uma classe com responsabilidade altamente relacionadas e que não executa um formidável volume de trabalho tem coesão alta.


Workflow orkflow Arquitetura Arquitetur a Conceitos: Acoplamento e Coesão Coesão: (continuação)


Uma classe com coesão baixa faz muitas coisas não-relacionadas, ou executa demasiado trabalho. Tais Tais classes são s ão indesejáveis, elas sofrem dos seguintes problemas: - São difíceis difíceis de compree compreender; nder; - São difíceis de reusar; reusar; - São difíceis difíceis de de manter; manter; - São muito muito sensíveis sensíveis a mudança; mudança; Classes de coesão baixa representam, geralmente, uma abstração abstr ação de “grande granularidade” ou atribuíram responsabilidades que deveriam ter

sido delgadas a outras classes ou objetos


Workflow orkflow Arquitetura Arquitetur a Conceitos: Acoplamento e Coesão Coesão: (continuação) Exemplo:


Neste exemplo é demonstrado a baixa coesão, coesão, uma vez que a classe Nota Fiscal assume a responsabilidade de fazer o cálculo dos imposto Tributo - codi codigo go - nome nome

NotaFiscal

Cliente

- núme número ro - data emissão emissão - tipo tipo +calcularImposto() +getNumero +setNumero ....

- codi codigo go - nome nome +getCodigo() +setCodigo() +getNome()

NotaFiscalItem

Produto

- item item[[ ] - quantidad quantidadee +getQuantidade() +setQuantidade() ...

- codi codigo go - descr descriçã içãoo +setCodigo() +getCodigo()


Workflow orkflow Arquitetura Arquitetur a Conceitos: Acoplamento e Coesão Tributo

Coesão: (continuação)

- codi codigo go - nome nome

Exemplo:


Solução é delegar a responsabilidade de cálculo de imposto para uma classe especializada neste assunto (usamos aqui o mecanismo de delegação). Desta forma teremos uma alta coesão. Produto - codi codigo go - descri descriçã çãoo +setCodigo() +getCodigo() +gerProduto

NotaFiscal - núme número ro - data emissão emissão - tipo tipo +getNumero +setNumero ....

CalculoImposto +calcularImposto()

NotaFiscalItem

Cliente

- quantida quantidade de

- codi codigo go - nome nome +getCodigo() +setCodigo() +getNome() +get/cliente()

+getQuantidade() +setQuantidade() ...


Workflow orkflow Arquitetura Arquitetur a Conceitos: Acoplamento e Coesão Coesão: (continuação) Tipos de coesão funcional:

•

Coesão Muito Baixa: –


Uma classe é a única responsável por muitas coisas em áreas funcionais muito diferentes

•

Coesão Baixa:

•

Uma classe é a única com a responsabilidade de uma tarefa complexa em área funcional Coesão Alta: – Uma classe tem a responsabilidade moderadas em uma área funcional e colabora com outras classes para levar a termo as tarefas

•

Coesão Moderada:

–

–

Uma classe tem peso leve e responsabilidade exclusivas exclusivas em umas poucas áreas diferentes que estão logicamente relacionadas ao conceito da classe, mas não entre si.


Workflow orkflow Arquitetura Arquitetur a Conceitos: Acoplamento e Coesão Coesão: (continuação) Benefícios:

• • • •


Clareza e a facilidade de compreensão do projeto aumentam; A manutenção e as melhorias são simplificadas; Freqüentemente, o baixo acoplamento é favorecido; A granularidade fina de funcionalidades altamente relacionadas suporta o aumento do potencial de reúso, porque uma classe altamente coesiva pode ser usada para finalidade muito específica..


Workflow orkflow Arquitetura Arquitetur a Conceitos: Acoplamento e Coesão Acoplamento Acoplamento (Low Coupling) É uma medida da interdependência relativa entre as classes. Depende da complexidade de interface entre as classes. Baixo acoplamento é o desejável Como manter o baixo acoplamento ?


- Solução: Solução: Atribuir Atribuir uma responsabilidad responsabilidadee de forma que o acoplamento permaneça fraco Como suportar uma dependência baixa e aumentar o reúso?

O acoplamento é uma medida de quão fortemente uma classe está ligada a uma ou mais classes, tem conhecimento das mesmas ou depende delas. Uma classe com acoplamento baixo (fraco) não é dependente de muitas classes.


Workflow orkflow Arquitetura Arquitetur a Conceitos: Acoplamento e Coesão Acoplamento Acoplamento (continuação) Uma classe com acoplamento alto (forte) depende de muitas outras classes. Tais Tais classes são indesejáveis; indesej áveis; elas sofrem dos seguinte problemas: • Mudança em classes relacionadas forçam mudanças locais • Mais difícil de compreender isoladamente • Mais difícil de reusar porque o seu uso requer a presença adicional das classes que ela depende.

Independência Funcional: Benefícios: •Coesão e • Acoplamento • Não afeta por mudanças em outros componentes • •

simples de entender conveniente para o reúso.


Workflow orkflow Arquitetura Arquitetur a Conceitos: Acoplamento e Coesão Acoplamento. Tipos:

Abaixo os possíveis tipos de acoplamento: Acoplamento Acoplamento Abstrata: Cliente

Service

<>

Cliente

Service

{abstract}


Service

Service

Sem acoplamento Cliente

Service

Com acoplamento Cliente Service

Service

Service

Forte acoplamento Cliente

Service


Workflow de Projeto, Arquitetura Conceitos: Acoplamento e Coesão Acoplamento

Princípio da Dependência Inversa: “Abstração não deve depender classe concreta. Uma classe concreta deve depender de uma abstração”

Exemplo: Independência Funcional: •Coesão e • Acoplamento

Moeda

MaskMoeda

- valo valorr +getValor +setValor

+maskFormat()

dependência

Este modelo tem alguns problemas: 1 - Herança. Todos Todos que herdarem a classe Moeda são obrigados obrigados a herdar também a classe MaskMoeda e as vezes somente precisamos da classe Moeda.


Workflow orkflow Arquitetura Arquitetur a Conceitos: Acoplamento e Coesão Acoplamento

Princípio da Dependência Inversa (continuação): Moeda - valo valorr

MaskMoeda

+getValor +setValor


+maskMoeda()

dependência

2 - O relacionamento de dependência dependência inibe a extensibilidade da classe Moeda. Vamos Vamos analisar o seguinte cenário: Em uma aplicação financeira que lida com mercado internacional, precisamos ter uma classe Moeda com as seguintes responsabilidades de saber o valor, formatação de acordo padrão monetário e exibir o respectivo símbolo da moeda (cifrão).


Workflow orkflow Arquitetura Arquitetur a Conceitos: Acoplamento e Coesão Acoplamento

Princípio da Dependência Inversa (continuação): Aplicando a DIP, DIP, podemos resolver a situação, veja os modelos abaixo: DIP com Classe Abstrata: Cliente


DIP com Interface: <>

Cliente

Service

Service

{abstract}

Service

Service

Service

Solução para a classe Moeda: Moeda

MoedaMask {abstract}

Real

Dolar

Service


Workflow orkflow Arquitetura Arquitetur a Conceitos: Acoplamento e Coesão Acoplamento Relacionamento de Realização Problema:


A classe Cliente realiza a interface iPessoa (isto quer dizes que todos os métodos assinados na interface deve ser implementado na classe) Uma vez que se declare uma nova assinatura de método na interface iPessoa será necessário implementar este novo método na classe Cliente.

<> iPessoa

Cliente

Realização


Workflow orkflow Arquitetura Arquitetur a Conceitos: Acoplamento e Coesão Acoplamento Relacionamento de Realização


Solução: Criação de nova classe PessoaAdapter esta classe se relacionará com a interface iPessoa, desta forma todas as modificações ou novos implementações serão feitas nesta classe. Desta forma reduziremos o acoplamento entre a interface e a classe Cliente <> iPessoa

Realização PessoaAdapter

Cliente


Workflow orkflow Arquitetura Arquitetur a Diagrama de Componentes Exemplo: A partir do diagrama de classe, tentamos agrupar classes cl asses usando técnicas de coesão e acoplamento.

Exemplo: Acoplamento Coesão e Componentes


Workflow orkflow Arquitetura Arquitetur a Diagrama de Componentes Exemplo: Temos o seguinte resultado:

Exemplo: Acoplamento Coesão e Componentes


Workflow orkflow Arquitetura Arquitetur a Diagrama de Componentes

e r a w t f Exemplo 2: o S Diagrama de Classes: e d a i r a h n e g n E o ã ç a t i c a p a C


Workflow orkflow Arquitetura Arquitetur a UML. Diagrama de Componentes Exemplo 2: A partir do diagrama de classe, agrupar classes usando os conceitos de coesão e acoplamento.

Pedido Cesta de Compra Produto FormaPagto


Workflow de Projeto, Arquitetura Diagrama de Componentes

e r a w t f Exemplo 2: o S Diagrama de Componentes e d a i r a h Pedido n e g n Cesta de Compra E o ã Produto ç a t i c FormaPagto a p a C

Produto

Cesta

Pedido

FormaPagto


Workflow orkflow Arquitetura Arquitetur a Projetando um Modelo de Arquitetura: Arquitetura: Sugestão para modelo de Arquitetura para aplicações Web de três camadas: Servidor de Aplicação JBoss

Cliente

Servidor de Banco de Dados

HTTP TCP/IP

Oracle

HTML

Windows

Linux Suse

Linux Suse


Workflow orkflow Arquitetura Arquitetur a Projetando um Modelo de Arquitetura para Camada Cliente: Cliente Servidor. Fazendo acesso utilizando o RMI (Remoto Method Invocation)

DeskTop

Servidor de Aplicação

ReservaUI

Reserva

<>

Funcionário << Stub>>

<>

RMI


Workflow orkflow Arquitetura Arquitetur a Projetando um Modelo de Arquitetura para Camada Cliente: Web Browser FormConsulta

Cliente

HTTP

WebServer

Servlet

Tabelas de Reserva

ServletsController

JSP JavaBeans

<< Reserva>>

<< ConnDB>>

Banco de Dados

HotelSchema


Workflow orkflow Arquitetura Arquitetur a Projetando um Modelo de Arquitetura para Camada Cliente: Web Cliente Browser FormConsulta

Apresentação ServletsController

Negócio << Reserva>>

Integração JDBC 2.0

HTTP << ConnDB>>

Cliente

HTML

Recursos

Servlet/JSP

JavaBeans

Banco de Dados

SQL


Workflow orkflow Arquitetura Arquitetur a Implementando os Requisitos Não Funcionais: Neste momento devemos construir modelo de arquitetura para atender todos os RNF e os casos de uso mais relevante ao negócio. A seguir demonstraremos um exemplo de como criar uma arquitetura para RNF. Considerando o cenário de Loja Virtual, numa transação de pagamento. Browser FormPagamento Cliente

Fazer Pedido

<>

Cliente

HTTPs (HTTP + SSL) Fazer Pagamento

<> Fechar Pedido

WebServer ServletsController

CartaoCredito

Pagamento

Requisito Não Funcional: Segurança: Todas Todas as transações de pagamento deve ser realizado em ambiente seguro


Quer Mais Gostou quer mais, gostaria de receber outros materiais sobre o mesmo tema e novas versões deste material... e r Envie um e-mail para com subject : “Quero entrar na comunidade” para [email protected] que te a enviaremos um convite para participar da nossa comunidade w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C

http://etecnologia.ning.com/

Desenho Sobre o Análise autor: eRildo F. Orientado Santos a Objetos com UML Coach e Consultor de Gestão de Negócios, Inovação e Tecnologia para a Gestão 2.0, a Gestão Ágil.

e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C

A Gestão Ágil ajuda as empresas a responder r esponder mais rápido as demandas de negócio e mudanças. A Gestão 2.0, abrange Planejamento Estratégico, Gestão por Processos Ágeis, Gestão de Projetos Ágeis, Tecnologia da Informação (Métodos Ágeis), Inovação e Lider ança.

Minha Experiência: Tenho mais de 10.000 horas de experiência em Gestão de Negócios, Gestão de Inovação, Governança e Engenharia de Software. Formado em Administração de Empresas, Pós-Graduado em Didática do Ensino Superior e Mestre em Engenharia de Software pela Universidade Mackenzie. Fui instrutor de Tecnologia de Orientação a Objetos, UML e Linguagem Java na Sun Microsystems e na IBM. Conheço Métodos Ágeis (SCRUM, Lead, FDD e XP), Arquitetura de Software, SOA (Arquitetura Orientado a Serviço), RUP/UP Processo Unificado, Business Intelligence, Gestão de Risco de TI entre outras tecnologias. Sou professor de curso de MBA da Fiap e fui professor de pós-graduação da Fasp e IBTA. Possuo fortes conhecimentos de Gestão de Negócio (Inteligência de Negócio, Gestão por Processo, Inovação, Gestão de Projetos e GRC Governance, Risk and Compliance), SOX, Basel II e PCI; E experiência na implementação de de Governança de TI e Gerenciamento de Serviços Serviços de TI. Conhecimento dos principais frameworks e padrões: ITIL, Cobit, ISO 27001 e ISO 15999; Desempenhei diversos papéis como: Estrategista de Negócio, Gerente de Negócio, Gerente de Projeto, Arquiteto de Software, Projetista Proj etista de Software e Analista de Sistema em diversos segmentos: Financeiro, Telecomunicações, Seguro, Saúde, Comunicação, Segurança Pública, Fazenda, Tecnologia, Varejo, Distribuição, Energia e Petróleo e Gás. Possuo as certificações: certificações: CSM - Certified SCRUM Master, CSPO CSPO - Certified SCRUM Product Owner , SUN Java Certified Instrutor, Instrutor, ITIL Foundation e sou Instrutor Oficial de Cobit Foundation e Cobit Games; Sou membro do IIBA-International IIBA-International Institute of Business Analysis Analysis (Canada)

Onde estou: Twitter: http://twitter.com/rildosan http://twitter.com/rildosan Blog: http://rildosan.blogspot.com/ http://rildosan.blogspot.com/

Análise e Desenho Orientado a Objetos com UML Marcas Marcas Registradas: Registradas: e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C

Todos os termos mencionados e reconhecidos recon hecidos como Marca Registrada e/ou comercial são de responsabilidade de seus proprietários. O autor informa não estar associada a nenhum produto e/ou fornecedor apresentado neste material. No decorrer deste, imagens, nomes de produtos e fabricantes podem ter sido utilizados, e desde já o autor informa que o uso é apenas ilustrativo e/ou educativo, não visando ao lucro, favorecimento f avorecimento ou desmerecimento do produto/fabricante.

Melhoria e Revisão: Este material esta em processo constante de revisão e melhoria, se você encontrou algum problema ou erro envie um e-mail nós.

Criticas e Sugestões: Nós estamos abertos para receber criticas e sugestões que possam melhorar o material, por favor envie um email para nós. Imagens: Google, Flickr e Banco de Imagem.

Rildo F dos Santos ([email protected])

Licença: e r a w t f o S e d a i r a h n e g n E o ã ç a t i c a p a C



o s L o h t M n e j e U s b e O D a m o e c o e s d i a l t á n n e A i r O

Rild Ri ldo o F Sant Santos os [email protected] [email protected]

Twitter: @rildosan Blog: http://rildosan.blogspot.com/

Analise e Desenho Orientado a Objetos Com UML

Recommend Documents