analise e desenho orientado a objetos com uml

Análise e Desenho Orientado a Objetos com UMLC

ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are

Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007

An

áli

se e

Des

enh

o

Ori

enta

do

a O

bje

tos

com

UM

L

Versão 27 |

Rildo F [email protected]

[email protected]

Twitter: @rildosan

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


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are

Rildo F Santos ([email protected])Versão 27Todos os direitos reservados e protegidos © 2006 e 2007 2

Conteúdo

Parte 1 - Principais Conceitos da Orientação a Objetos e introdução

UML

Parte 2 – Especificação de Requisitos de Software

Parte 3 – Analise Conceitual

Parte 4 – Desenho (design) do Modelo de Especificação de Software

Parte 5 – Arquitetura de Software


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


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


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


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.

Objetivo

Orientação a Objetos. Principais Conceitos:


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Introdução. Desenvolvimento de Software Orientada a Objetos

Metodologia/Fases

WorkFlows

Atividades

Ferramentas

e

Artefatos

Tecnologia OO

Influência escolha da

Ferramentas

Suporte as atividades

Jacobson pyramid “rational enterprise philosophy”



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


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”

Veja alguns exemplos de objetos:

Pessoa Cão BarcoPartida

de Futebol

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, uma ligação

telefônica, uma conta corrente e etc...)

Objetos do Mundo Real



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Objetos

O termo orientação a objetos significa organizar o mundo real

como uma coleção de objetos que incorporam estrutura de

dados (propriedades ou características) e um conjunto de

operações que manipulam estes dados.

Propriedades Operações

Nome

Data de Nascimento

Massa (peso)

Altura

Andar

Correr

Trabalhar

Chorar

Dançar

Objeto: Pessoa

Espécie

Cor das penas

Tamanho

Peso

Andar

Correr

Voar

Pousar

Propriedades OperaçõesObjeto: Pássaro



Classes

Objetos

Atributos

Métodos

Abstração de Dados

Herança

Polimorfismo

Encapsulamento

Interface


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


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

Operações

Ano-fabricação

acelerar

parar

Identificador

O que são operações ?

- Coisas que objeto deve

saber fazer

Carro




ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Quando atribuímos valores aos objetos, ou seja, as propriedades (atributos), podemos dizer que

ele tem um estado

cor

Número chassi

Operações

Ano-fabricação

acelerar

parar

VW1003G345

branco

1966

IdentificadorCarro

Atributos


estado



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


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, verificar, calcular e etc

cor

Número chassi

Operações

Ano-fabricação

acelerar

parar

VW1003G345

branco

1966

Identificador

Atributos

Carro

Substantivo

verbos




ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Modelagem de objeto:

cor

Número chassi

Operações

Ano-fabricação

acelerar

parar

VW1003G345

branco

1966

Identificador

Atributos

Carro

Carro

cor

número chassi

ano-fabricação

acelerar

parar


Representação na

Orientação a objetos

Nome (identificador)

Propriedades

(atributos)

Operações



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Modelagem de objeto:

Carro

cor

número chassi

ano-fabricação

acelerar

parar


O que é

uma classe ?

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.

Representação na

Orientação a objetos



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Classe

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 classes podem incluir abstrações que são parte 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 e até itens que sejam

somente conceituais.

Exemplo:

A classe Pessoa deverá ter atributos e métodos comuns

Definição de Classe:

Uma classe descreve um conjunto de objetos que compartilham os

mesmos atributos, operações, métodos, relacionamentos e semântica

Pessoa

nome

idade

getNome()

getIdade()

setNome()

setIdade()

Nome da Classe

Atributos

Métodos

Classes

Objetos

Atributos

Métodos


Herança

Polimorfismo

Encapsulamento

Interface

Nota: Dicionário Aurélio

Em programação ou modelagem orientada a objetos (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.



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Classe

Exemplo de Classe:

Livro1

2

Legenda:

1 – Objeto no mundo real

2 – Classe Livro

3 – Objeto da classe Livro

3

Classes

Objetos

Atributos

Métodos


Herança

Polimorfismo

Encapsulamento

Interface

ISBN 0747551006

Titulo: Harry Potter and the

Order of the Phoenix

Autor: J. K. Rowling



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Classe e Objeto

Classe e Objeto. Exemplo:

ISBN 8571643512

Titulo: AS JANELAS DO

PARATII

Autor: Amir Klink

ISBN 0747551006

Titulo: Harry Potter and the

Order of the Phoenix

Autor: J. K. Rowling

ISBN 0747551006

Titulo: O Poder da inteligência

Emocional

Autor: Daniel Goleman

Uma coleção de livros

pode ser representada

por uma classe chamada

Livro.

Cada livro desta coleção é

“instance” (objeto) da classe livro.

Classes

Objetos

Atributos

Métodos


Herança

Polimorfismo

Encapsulamento

Interface



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


cor

Número chassi

Operações

Ano-fabricação

acelerar

parar

VW1003G345

branco

1966

Identificador

Atributos

Carro

Carro

cor

número chassi

ano-fabricação

Acelerar()

parar()

Classe (Modelo)

fusca:Carro

cor=“branco”

número chassi=“VW1003G345

ano-fabricação=1966

Objeto (“instance”)



Classe e Objeto


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


nome

cpf

idade

Cliente

Cliente: clientehomem

nome = Felipe

cpf = 039.217.908-22

idade = 42

Cliente: clientemulher

nome = Marina

cpf = 022.200.708-12

idade = 16

Classes

Objetos

Atributos

Métodos


Herança

Polimorfismo

Encapsulamento

Interface


Classe

Objetos


Classe e Objeto


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Classes

Objetos

Atributos

Métodos


Herança

Polimorfismo

Encapsulamento

Interface

Responsabilidades

Definição de 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, data, tipo de pagamento e etc.

TransacaoPagamento

numero

valor

data

situação

TipoPagamento

Responsabilidade:

-- Saber o número da

transação, data, valor

-- Conhecer o tipo de

pagamento...

Responsabilidades


Classe, Responsabilidade e Colaboração


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Classes

Objetos

Atributos

Métodos


Herança

Polimorfismo

Encapsulamento

Interface

Colaboração:

Definição de Colaboração:

Ás vezes uma classe precisa colaborar com outra classe para

cumprir suas responsabilidades

A classe Transação de Pagamento tem a responsabilidade pelo conhecimento das

seguintes informações: número da transação, situação, 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 de pagamento. Exemplo: 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 da

transação, data, valor

-- Conhecer o tipo de

pagamento...

CartaoCredito

BoletoBancarioColaboração




ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Classes

Objetos

Atributos

Métodos


Herança

Polimorfismo

Encapsulamento

Interface

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 os

dados dos aluno:

Nome

Número da Matricula

Curso

Matricula

Pessoa

Curso

Cartão




ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


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

Uma classe possui:

• Atributos

• Métodos

• Responsabilidades (o que ela sabe fazer)

• Colaboração (interação com outras classes)

Classes

Objetos

Atributos

Métodos


Herança

Polimorfismo

Encapsulamento

Interface



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Atributo

Definindo Atributo:

• É uma características (propriedade) presente no objeto.

• Valor de todos os atributos é igual Estado do Objeto.

• Somente atributos que são de interesse do sistema devem ser

descritos na classe.

nome

cpf

idade

Cliente

Cliente: clientemulher

nome = Marina

cpf = 022.200.708-12

idade = 16

atributos

Classes

Objetos

Atributos

Métodos


Herança

Polimorfismo

Encapsulamento

Interface



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


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

getCodigo()

setCodigo()

getNome()

setNome()

Métodos

Classes

Objetos

Atributos

Métodos


Herança

Polimorfismo

Encapsulamento

Interface

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”



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Método

Definição de Método:

Chamando os métodos

Para chamar um método de um 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

setDeposito()

getSaldo()

setSaque()

Métodos

Classes

Objetos

Atributos

Métodos


Herança

Polimorfismo

Encapsulamento

Interface

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.



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


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

Classes

Objetos

Atributos

Métodos


Herança

Polimorfismo

Encapsulamento

Interface



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


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.

Desta forma podemos dizer que os métodos “encapsulam” os

atributos.

Classes

Objetos

Atributos

Métodos


Herança

Polimorfismo

Encapsulamento

Interface



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Classe Concreta e 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.

E a Classe abstrata ?

Bem, veremos a seguir o que é

uma classe abstrata...

public class Pessoa {

//Atributos

private String nome;

private int idade;

//métodos

public String getNome(){

return nome; }

public void setNome(String

nome){

this.nome = nome; }

public int getIdade(){

return idade; }

public void setIdade(int

idade){

this.idade = idade; }

}



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Abstração de DadosExemplo:

Um a empresa de transporte possui uma frota de veículo, esta frota é composta por caminhões, peruas

e motos.

Estes veículos têm algumas características semelhantes como cor, peso, tamanho e capacidade de

carga. Entretanto cada veículo possui outras características diferentes como número de eixos sistema

de freio, tipo de motor e etc.

A abstração de dados é utilizada neste caso para identificar todas as propriedades comuns e reuni-las

em novo conjunto, isto lembra alguns princípios da matemática como fatoração.

Desta forma estaríamos fazendo um melhor aproveitamento de informações que se repetem e também

estamos fazendo que características diferente seja tratada de forma diferenciada.

O que é

abstração

de dados ?



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Definição de Abstração de Dados:

Qual é a função da abstração ?

A função da abstração é capturar as propriedades e os comportamentos essenciais,

como se fosse uma fatoração, desta forma determina-se o que é importante e o que

não é.

Exemplo

especialização

Classes

Objetos

Atributos

Métodos


Herança

Polimorfismo

Encapsulamento

Interface

Veículo

Navio

Abstração

Definição de abstração:

“Habilidade mental que permite aos seres humanos visualizarem os problemas

do mundo real com vários graus de detalhe, dependendo do contexto corrente do

problema. (Jim Rumbaugh).

Avião




ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Exemplo de Abstração de Dados:

MeiodeComunicação

Carta Telefone Jornal

As classes Contribuinte e MeiodeComunuicação neste caso são abstratas e

ambas podem representam um domínio.

Exemplo

Generalização

Especialização

Abstração: nos ajuda a lidar com a complexidade.

Classes

Objetos

Atributos

Métodos


Herança

Polimorfismo

Encapsulamento

Interface




ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Abstração de Dados:

public abstract class ContaBancaria extends Object {

public ContaBancaria() { }

protected int numerocontacorrente;

public abstract int getNumeroContaCorrente();

public abstract void setNumeroContaCorrente(int numerocontacorrente);

}

Uma classe abstrata é uma classe que:

• Provê organização

• Não possui “instances”, ou seja, não possui objetos.

• Possui uma ou mais operações (métodos) abstratasClasses

Objetos

Atributos

Métodos


Herança

Polimorfismo

Encapsulamento

Interface




ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


//métodos

public abstract String getNome()

public void setNome(String nome){

this.nome = nome;

}

public abstract int getIdade()

public void setIdade(int idade)

{

this.idade = idade;

}

Veja agora a classe Pessoa, que é

abstrata, pois, possui um método

abstrato.

public abstract class Pessoa {

}

public abstract int calcIdade(Date

d1, Date d2);

Um método abstrato não possui

implementação somente assinatura

(declaração)

Um método concreto possui implementação

assinatura e implementação.

public void setIdade(int idade)

{

this.idade = idade;

}




ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Resumo: Abstração de Dados

Resumindo:

Uma classe abstrata deve ter pelo menos um 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”

Classes

Objetos

Atributos

Métodos


Herança

Polimorfismo

Encapsulamento

Interface

Como eu faço

para usar uma

classe abstrata ?



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Comparação entre Classe Abstrata e Classe Concreta

Classe Abstrata Classe Concreta

Os métodos devem ser somente assinadosOs métodos podem ser assinados e

implementados

Não pode sofrer “instance” Poder sofrer “instance”

Relacionamento somente através de

HERANÇATodos os tipos de relacionamentos




ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


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)Classes

Objetos

Atributos

Métodos


Herança

Polimorfismo

Encapsulamento

InterfaceAnimal

Animal SelvagemAnimal Doméstico

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 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:



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


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.

Graduação Pós-Graduação

Curso

Universitário

Especialização Extensão

Hierarquia de Classes

Super classes

extends

Sub classe

Classes

Objetos

Atributos

Métodos


Herança

Polimorfismo

Encapsulamento

Interface



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


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

calcularConta(telefone)

Telefone Móvel

Telefone Fixo

Classes

Objetos

Atributos

Métodos


Herança

Polimorfismo

Encapsulamento

Interface



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


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.

Classes

Objetos

Atributos

Métodos


Herança

Polimorfismo

Encapsulamento

Interface

Polimorfismo



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Overridde de Método

Classes

Objetos

Atributos

Métodos


Herança

Polimorfismo

Encapsulamento

Interface

Uma subclasse pode mudar o comportamento herdado da Superclasse, ou

seja, um método herdado poderá ser modificado. 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), entretanto para cada tipo de

Conta ele tem uma implementação diferente. Por exemplo:

- Para apurar o saldo da Conta Corrente saldo atual = (soma dos depósitos + saldo anterior) -

saques

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

saques

Para a conta de investimentos seria saldo atual = (soma dos aplicações + saldo anterior +

juros) - resgates - ir

Polimorfismo



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Principais 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

Classes

Objetos

Atributos

Métodos


Herança

Polimorfismo

Encapsulamento

Interface

Encapsulamento



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Benefícios do Encapsulamento:

Benefícios

- Segurança:

Protege os atributos dos objetos de terem seus valores corrompidos por

outros objetos.

- Independência:

“Escondendo” seus atributos, um objeto protege outros objetos de

complicações de dependência de sua estrutura interna

nome getNome()setNome()

idade getIdade()setIdade()

encapsulamento

nome

idade

Pessoa

setNome()

getNome()

setIdade()

getIdade()

Classes

Objetos

Atributos

Métodos


Herança

Polimorfismo

Encapsulamento

Interface

Encapsulamento



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


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

também para prover:

- Organização e padronização de assinatura de métodos;

- Simular herança múltipla e

- Fazer relacionamentos de classes com responsabilidade distintas.

Classes

Objetos

Atributos

Métodos


Herança

Polimorfismo

Encapsulamento

Interface

Interface



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Exemplo de Interface:

Representação:

getcodigo()

setcodigo()

<<interface>>

Codigo

getcodigo()

setcodigo()

Produto

getcodigo()

setcodigo()

Fornecedor

realização

cpf cnpj

Contrato

Classes

Objetos

Atributos

Métodos


Herança

Polimorfismo

Encapsulamento

Interface

Interface



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


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.

Classes

Objetos

Atributos

Métodos


Herança

Polimorfismo

Encapsulamento

Interface

Introdução a Orientação a Objetos

Interface



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


UML. Linguagem de Modelagem Unificada

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


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


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 de um sistema;

3 - Os modelos proporcionam um guia para a construção do sistema;

4 - Os modelos documenta o sistema.

O Que é Modelagem Visual?

Introdução

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



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


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 de Modelagem Unificado) é

padrão mantido pelo OMG (www.omg.org/uml).

Introdução



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


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

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 do processo, apesar de ser

perfeitamente utilizada em processo orientado a casos de usos, centrado na arquitetura,

iterativo e incremental.

Introdução



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


ESTÁTICOS

. Diagrama de Classes

. Diagrama de Objetos

. Diagrama de Componentes

. Diagrama de Distribuição

DINÂMICOS

. Diagrama de Casos de Uso

. Diagramas de Interação

- Diagrama de Seqüência

- Diagrama de Colaboração

. Diagrama de Atividade

. Diagrama de Estados

Modela o comportamento do sistema

Modela a estrutura do sistema

Principais Digramas:



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Processo de Desenvolvimento:

Processo de Desenvolvimento

VisãoAnáliseClasses

Defeitos

Modelo Casos

Uso de Negócio

Modelo Objetos

de NegócioModelo de Classes

Componentes

Desenho Classes

Script de Testes

Casos de Teste

Modelo de

Casos de Uso

Necessidades dosStakeholders

Realização dos Casos de Uso



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


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



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


• 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

Elementos:



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Visões:

Visão de Projeto

Funcionalidade

Vocabulário

Visão da Implementação

Codificação

Montagem

Visão do Processo

Desempenho

Escalabilidade

Throughput

Visão da Implantação

Topologia do Sistema

Distribuição

Instalação

Conceitual Físico

Visão de Caso de Uso



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


• A visão do caso de uso abrange os casos de usos que descrevem o comportamento do sistema

conforme é visto pelos seus usuários finais, analista e pessoal de teste. Essa visão não especifica

realmente a organização do sistema de software. Porém , ela existe para especificar as forças que

determinam a forma da arquitetura do Sistema. Com a UML, os aspectos estáticos dessa visão

são representados em diagramas de caso de uso, enquanto os aspectos dinâmicos são

representados em diagrama de interação., diagrama de gráfico de estados e diagrama de

atividades

• 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.

Visão de Caso

de Uso

Visão de Projeto

Visões:



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


• A visão do processo abrange os “threads” e os processos que formam os mecanismos de

concorrência e de sincronização do sistema. Essa visão tem com objetivo principal tratar questões

de desempenho, à crescimento escalar e ao “throughput” do sistema. Com a UML, os aspectos

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 processos.

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

programas ou parte.

• A visão de implementação de um sistema abrange os componentes e os arquivos utilizados

para a montagem e fornecimento do sistema físico. Essa visão envolve principalmente o

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.

Visão de Implementação

Visão de Processo

Visões:



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


• A visão de implantação de um sistema abrange os nós que formam a topologia de hardware em

que o sistema é executado. Essa visão direciona principalmente a distribuição, o fornecimento e a

instalação das partes que constituem o sistema físico. Com a UML, os aspectos estáticos dessa

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.

Visão de Implantação

Cada uma dessas visões pode ser considerada isoladamente, permitindo que diferentes

participantes orientem seu foco para os aspectos da arquitetura do sistema que mais lhes

interessem. Essas cincos visões também interagem entre si, por exemplo:

Os nós na visão de implantação contêm componentes da visão de implementação que, por sua vez,

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

de projeto e de processo.

Visões:



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Exemplo: de Projeto Software Orientado a Objetos:

unidades

Use case view

Logical view

Casos de Uso

Diagrama de Seqüência e/ou

Diagrama de Colaboração

Diagrama de Estado

Diagrama de Atividades

Diagrama de Pacotes

Formulários

Diagrama de ClassesDiagrama de Estado


Diagrama de Pacotes

Component view

Diagrama de Componentes

Diagrama de Deployment

Deployment view



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Big Picture. Requisitos e Análise

Glossário de

conceitos

Modelo Conceitual

Análise Conceitual

Casos de Uso

Engenharia de Requisitos

Requisitos Funcionais

Requisitos Não

Funcionais

Análise de Requisitos Especificação de Requisitos

(Visão de Caso de Uso)

Coleta de Requisitos

Documento

de Visão

Business Case

Arquitetura Inicial

4



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Introdução. Artefatos:

Produtos dos Workflows de Requisitos e de Análise:

Documento de Visão

Especificação de Requisitos (Casos de Uso)

Vocabulário do Sistema

Modelo Conceitual ou Modelo de Domínio

Documento de Requisitos

Análise

Requisitos


Modelo de Arquitetura Inicial


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Big Picture.

Modelo Conceitual

4

Análise

Diagrama de Classes

Projeto (Visão Lógica)

4

: visitante : Categoria : Produto : Catalogo : FormBusca

exibirCategoria( )

exibirProduto( )

selecionarCategoria

selecionarProduto( )

getDescricao( )

getDescricao( ) getQuantidade( )

Receber Pedido

Preencher Pedido

Receber Pagamento

Enviar Fatura

Entrega durante

a noiteEntrega Regular

[pedido urgente] [senão]

Encerrar Pedido

Entrega

Especificação de Requisitos


Análise & Projeto



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Diagrama de Sequência / Colaboração

Diagrama de Classes


Principais Produtos (Artefatos):

Projeto

Diagrama de Estados



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Big Picture. Projeto &Arquitetura

Diagramas


4


exibirCategoria( )

exibirProduto( )

selecionarCategoria


getDescricao( )


Receber Pedido

Preencher Pedido

Receber Pagamento

Enviar Fatura

Entrega durante



Encerrar Pedido

Entrega

Projeto (Visão de Componentes e

Visão de Deployment)



Arquitetura



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are



Diagrama de Distribuição(Deployment)

Principais Produtos (Artefatos):

Arquitetura

Modelo de Arquitetura



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are



de SoftwareObjetivo desta parte:

É apresentar e discutir o Ciclo de Requisitos de Software:

– Elicitação, Análise, Especificação de Requisitos de

Software com Caso de Uso


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Um entendimento completo dos requisitos de software é essencial para um o sucesso do

desenvolvimento do software. Não importa quão bem projetado ou quão bem codificado

seja, um programa mal analisado e especificado frustrará o usuário.

Análise de requisitos é um processo de descoberta, refinamento, modelagem e

especificação.

O escopo do software, inicialmente estabelecido pelo Analista de Sistemas e refinado

durante o planejamento do projeto de software, é aperfeiçoado em detalhes.

Modelos, diagramas, fluxos são criados para melhor compreensão do problema.

O analista e o usuário desempenham um papel ativo na análise e especificação de

requisitos.

O cliente (usuário) tenta reformular um conceito de função e desempenho de software, às

vezes nebuloso, sem detalhes concretos. O analista age como indagador, consultor e

solucionador de problemas.

Entretanto, a análise e especificação de requisitos pode parecer uma tarefa relativamente

simples, mas as aparências enganam. O grau comunicação é elevado. Daí, surgem as

oportunidades de interpretações errôneas e informações falsas. A ambigüidade é provável.

O dilema com o qual se depara um analista pode ser mais bem entendido, repetindo-se a

declaração de um cliente anônimo:

“Sei que você acredita que entendeu o que acha que eu disse, mas não estou certo

que percebeu que aquilo que ouviu não é o que eu pretendia dizer...”

Análise de Requisitos: Introdução

Introdução


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Big Picture. Requisitos

Glossário de

conceitos

Modelo Conceitual

Análise Conceitual

Casos de Uso



Requisitos Não

Funcionais




Documento

de Visão

Restrições

Business Case

Arquitetura Inicial

Ferramenta de Desenvolvimento de Software

4


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Arquitetura

Analista de Sistema

PapéisArtefatosWorkflow

Requisitos

Workflow Requisitos

Analista de Requisitos

Documento de Visão


(Casos de Uso)



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


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.


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Requisitos

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 especificação

ou outros documentos impostos formalmente.

3) Uma representação documentada de uma condição ou capacidade, conforme os itens

(1) e (2).


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Documento de Visão

Fazer identificação e elicitação

de requisitos

Requisitos

Requisitos. Road Map

Fazer Análise de Requisitos

Fazer Especificação de Requisitos

Documento de

Requisitos

Documento de

Especificação

de Requisitos

Usuários e

Clientes

Documentos Fazer Validação de Requisitos

Regras de

negócio

http://egemsource.com/images/pic/main_column/check_mark.jpg


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Por que o “elicitação” é importante:

O sucesso no desenvolvimento de um projeto de software depende 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.

• Identificar os documentos e procedimentos que definem as políticas de negócios da empresa.

Requisitos

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

Elicitação RuimElicitação Boa

Diagnóstico ineficiente Bom Diagnóstico

Soluções medíocres Soluções eficientes

Insatisfação dos usuários Satisfação dos usuários

Problemas operacionais e financeiros Melhoria dos processos e redução de custo

Uma Simples Comparação:


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Documento (Artefato) desta etapa: “Documento de Visão”

Objetivo:

Descrever

a visão inicial

do software

Documento

de visão

Participantes:

Analistas e

Especialista

em Negócios

identificação/

elicitação de

Requisitos

entrevistas

documentosreuniões

Participantes:

Usuário,

Clientes,

Fornecedores e

Patrocinadores


Requisitos


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


As fases da Identificação/Elicitação de Requisitos:

Um projeto de elicitação de requisitos têm as seguintes fases:

Planejamento

Elicitação de

Requisitos

Documentação

Documento de Visão

Identificar FontesTécnicas

Como deve ser feito ?

O que devo coletar ?

Como devo documentar ?

Identificar Funcionalidades

Identificar Restrições e Riscos

Requisitos



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


As informações podem ser identificadas ou encontradas em diversas fontes:

- Usuários;

- Documentos;

- Especificações;

- Clientes;

- Patrocinadores;

- Analista de Negócios (“Domain Experts” - Especialista em uma ou mais área de negócio)

Requisitos


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ões;

- Entrevistas;

- Questionários;

- Workshop;

- Brainstorming;

- JAD (Join Application Development)

- Fast;

- Documentos;

- Sistemas Legados.


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Identificação dos Requisitos: Tipos de RequisitosOs Requisitos de Software podem ser divididos em duas categorias:

Análise de Requisitos

Requisitos

Requisitos

Funcionais

Requisitos

Não-Funcionais


Os requisitos funcionais descrevem o que o

sistema deve fazer, isto é, as funções

(funcionalidades) necessárias para atender os

objetivos. O que sistema deve saber fazer.

Exemplos: Buscar cliente, Registrar pedido

Calcular conta de consumo, Calcular tributos e

etc.

Os requisitos não funcionais dizem respeito as

características que descrevem qualidade do serviço

(QoS).

A omissão ou esquecimento desses requisitos constitui

uma das principais razões de uma eventual

insatisfação dos usuários com relação a um software.

Os Requisitos Não Funcionais (RNF) também são

chamamos de “Requisito Suplementares.”

Exemplos: performance, disponibiliade, confiabilidade,

segurança, usabilidade e etc.


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Identificação dos Requisitos:Os requisitos de software podem ser identificados no texto da “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 funcionais e

- Requisitos não funcionais.

Texto da Declaração do Problema

Requisitos



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Data: ________ | Autor: ________ | Revisão: ____

Índice:

1.0 - Introdução

1.1 Objetivo do documento

1.2 Escopo

1.3 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

Exemplo: Documento de Visão:

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 Stakeholders

- Lista dos Requisitos

- Lista dos Riscos

- Lista das Restrições


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Documento de Visão


de requisitos

Requisitos




Documento de

Requisitos

Documento de

Especificação

de Requisitos

Usuários e

Clientes


Regras de

negócio



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


A análise de requisitos procura sistematizar o processo de definição de requisitos.

Essa sistematização é necessária porque a complexidade dos sistemas exige que se preste mais

atenção ao correto entendimento do problema antes do comprometimento de uma solução. Uma

definição para requisitos é apresentada a seguir.

O Documento de Visão é um artefato importante na Análise de Requisitos, destacamos algumas

razões:

- Da perspectiva da engenharia de software, a elicitação de requisitos é talvez a mais parte mais critica

do processo de desenvolvimento de software.

Análise de Requisitos: Introdução

Requisitos

A Análise de Requisitos deve ser:

Correta: Quando cada requisito expresso nela for encontrado no software;

Não Ambígua: Cada requisito deve ter somente uma interpretação (definição);

Completa: Quando incluir todos os requisitos significativos relacionados as funcionalidades e requisitos

relacionados a qualidade do serviço (também conhecidos como requisitos não funcionais)

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

Verificável: Quando for possível verificar/validar cada requisito;

Modificável: Quando os requisitos podem ser facilmente alterados.


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


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.

Análise de Requisitos

Requisitos

Detalhar os


Descrever os Usuários

e Entidades Externas


Classificar os

Requisitos não Funcionais

Fazer Plano de Redução

de Risco


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Requisitos Funcionais:

Os requisitos funcionais devem ser detalhados. Devemos usar um formato padrão para

esta atividade. Veja o exemplo:

Análise de Requisitos. Detalhar

Requisitos

Lista de Requisitos funcionais

Nome Descrição

Fazer ReservaEsta 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)

Autor: Revisão: Data Atualização:

RF01E

Código


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


id Nome da Regra

Nome do Projeto Serviço de Atendimento e Reserva de Apartamento

ObjetivoDescrever todas as regras de negócio para para o serviço de atendimento e reserva de apartamentos.

Data

01/01/08 RFS 2.1

Nome / Equipe Versão

RN01

Descrição das Regras de Negócio

Descrição da Regra de Negócio

Registrar Reserva de

Apartamento

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.

Vigente

Status

Nome Descrição

Registrar Reserva

de Apartamento

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, cancelar, alterar e consultar reservas.

Requisitos Funcional

ID

RFC01


Requisitos

Nome: Reserva Descrição: Serviço de Atendimento e Reserva de ApartamentoRN: RN01

Os código permitem a rastreabilidade


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Requisitos Não Funcionais:

Agora vamos descrever os Requisitos Não Funcionais. Entretanto, precisamos

categorizar estes requisitos, as mais frequente são:

Análise de Requisitos. Classificar

Requisitos

- 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

- Flexibilidade:

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.


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are



Bem vamos descrever os requisitos não funcionais. Como na descrição dos Requisitos

funcionais, precisamos ter um padrão

Análise de Requisitos. Classificar e Detalhar

Requisitos

Lista de Requisitos Não funcionais

Descrição

Fazer

Consulta

As consultas que serão realizadas pelo cliente não poderão

exceder ao tempo de resposta de 15 segundos


Categoria: Performance

Req. Funcional Código

RNFP1

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, no caso de mudanças.


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are



Continuação:

Requisitos

Lista de Requisitos Não funcionais

Categoria: Usabilidade

RF /

AplicaçãoDescrição

AplicaçãoAs cores, as fontes e logotipos devem seguir o Manual de

Identidade Visual da empresa.


AplicaçãoAs interfaces com usuário devem seguir padrão de interfaces

estabelecido pelo Manual de Sistema

Código

RNFU1

RNFU2

Análise de Requisitos. Classificar e Detalhar


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Lista de Stakeholders:

Precisamos descrever todos as pessoas e/ou organização que influenciam a tomada de

decisão ou participam direta ou indiretamente do processo de construção do software.

Mais uma vez criaremos um formato padrão. Veja o exemplo:

Requisitos

Lista de Stakeholders

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



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Continuação:

Requisitos

Lista de Entidades Externas

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.



Lista de Stakeholders:

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.


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Documento de Requisitos:

Objetivo:

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 Funcionais

- Requisitos Não Funcionais

- Lista dos Stakeholders

- Plano de Redução de Risco

Análise de Requisitos. Artefato

Requisitos

Data: ________ | Autor: ________ | Revisão: ____

Índice:

1.0 - Introduçã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

Exemplo:Documento de Requisitos:


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Documento de Visão


de requisitos

Requisitos




(Casos de Uso)

Documento de

Requisitos

Documento de

Especificação

de Requisitos

Usuários e

Clientes


Regras de

negócio



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Especificação de Requisitos:

Casos de Uso

Seqüência Colaboração

Classes

DistribuiçãoImplementação

Estrutura

Comportamento interno

Comportamento externo

Especificação de RequisitosR

equ

isit

os

Fu

nci

on

aisDocumento

de Visão

Req

uis

itos

Não

Fu

nci

on

ais

Modelo de

Arquitetura

do Software

Documento de

Requisitos

Requisitos

O produto que devemos ter após Análise de Requisitos é a “A especificação de Requisitos” é feita

através de Casos de Uso, conforme definido pela UML. Um conjunto de casos de uso é importante

para se compreender o que o usuário quer. Um caso de uso descreve uma funcionalidade (“requisito”)

a ser oferecida pelo sistema, ou seja, um serviço.


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are



Objetivos:

• Identificar os atores;

• Identificar os casos de uso;

• Desenhar os casos de uso e

• Escrever cenários.

Análise de Casos de Uso:

•Casos de uso expressam o diálogo entre os usuários e o sistema

•Casos de uso expressam “o quê” o sistema deverá fazer. E não “como” fazer.

•Casos de uso formam a base para testes e documentação do sistema

•O modelo de casos de uso expressam todos os casos de uso do sistema e os seus

relacionamentos.

•As técnicas para criar e expressar casos de uso em uma aplicação Web são as

mesmas para construir outros sistemas de software.

Requisitos


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are



Cliente

Emitir NF

Fazer Pedido

Fazer Cadastro

Calcular Total

Funcionário

Transformar os Requisitos

Funcionais em Casos de Uso:

Requisitos


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Atividades e Passos:


Requisitos

Fazer Diagrama de

Casos de Uso

Escrever cenários Rational Rose

Identificar Atores /

Casos de Uso

Escrever Formulário

Fazer Diagrama de

Caso de Uso


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Casos de Uso

O que são Caso de Uso?São diagramas de que permitem visualizar, especificar e documentar o comportamento de umelemento. Esses diagramas 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.

Gerenciar

Reserva

Ator

Caso de Uso

Nome

Usuário

Os nomes de casos de uso

são breves expressões verbais

ativas.

Requisitos

Introdução:

Caso de Uso é uma representação gráfica e semântica da interação do usuário e o sistema.

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.


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Casos de UsoCasos de Uso e Cenários:

Os casos de uso exibem a funcionalidade na perspectiva do usuário. Entretanto, podemos ter vários

caminhos para completar esta função. Um cenários é como uma “instance” do Caso de uso, isto é, um

caminho lógico com início e fim.

Principais características:

- Cenários não contém declarações condicionais;

- Pode ter mesmo começo, mas, com final diferente;

- Um cenário é narrativa de uma situação e

- Os cenários devem descrever os bons caminhos e maus também.

Requisitos

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.


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Casos de UsoCasos de Uso e Fluxo de Eventos:

Uso caso de uso descreve “o quê” um sistema (ou subsistema, classe, ou interface) faz,

ele não especifica “como” isso é feito. Ao fazer uma modelagem, importante manter clara a separação

de questões entre a visão interna e externa.

Podemos especificar o comportamento de um caso de uso pela descrição do fluxo de eventos no texto

de maneira suficientemente clara para que qualquer pessoa possa entende-lo facilmente. Ao

escrevermos o fluxo de eventos devemos incluir como e quando o caso de uso inicia e termina, como e

quando o caso de uso interage com os atores e o fluxo básico e fluxo alternativo do comportamento.

Tipos de fluxos:

• Fluxo de eventos principal e

• Fluxo alternativo de eventos.

Requisitos

Tipicamente descrevemos um fluxo de eventos para um caso 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 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.


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Casos de Uso

Casos de Uso e Formulário:

Os formulários devem ter as seguinte informações:

- Ponto de ativação (momento que caso de uso começa)

- Nome do caso de uso

- Objetivo

- Atores que participam do caso de uso

- Pré-condição

- Fluxo Normal

- Fluxo Alternativo

- Pós-condição.

Opcionalmente podemos acrescentar outros itens ao Formulário de Caso Uso.

Exemplos:

- Nome ou código dos Requisitos (RN e RNF) que estão associados a este caso de uso

Requisitos


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Casos de UsoExemplos de Casos de Uso:

Professor

Selecionar curso

para ensinar

Pedir lista dos

matriculados

Gerente

Manter informação de

aluno

Manter informação de

professor

Gerar catalogo

Manter informações dos

cursos

Sistema de

cobrançaMatrícula nos

Cursos

Aluno

Requisitos


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Casos de UsoCasos de Uso e Formulário

Exemplo:

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 seleciona a página de busca

2 - O visitante seleciona a categoria para busca

3 - O visitante informar o produto

4 - O visitante pressiona o botão buscar

5 - O sistema processa a busca

6 - Retorna as informações sobre o produto

Fluxo Alternativo:

1 - O Visitante seleciona a página de busca

2 - O visitante seleciona a categoria para busca

3 - O visitante informar o produto

4 - O visitante pressiona o botão buscar

5 - O sistema processa a busca

6 - Retorna as uma mensagem “produto não encontrado”

Pós-condição: Busca realizada

Requisito Funcional: RF002 -Fazer Busca do Produto

Requisito Não Funcional: ---

Requisitos


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Casos de Uso

Elementos dos Caso de Uso:

Ator:Um ator representa um conjunto coerente de papéis que os usuários de casos de uso desempenham quanto interagem com esses casos de uso. Geralmente um ator representa um papel, que pode ser de pessoa, de um sistema ou de um dispositivo e etc...

Cenários:É narrativa de determinado fato ou de uma situação.“O caso de uso deve ser descrito através de cenários. Devem ser construídos tantos cenários quantos forem necessários para se entender completamente todo o sistema. Podem ser considerados como teste informais para validação dos requisitos do sistema.”

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

Requisitos


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Casos de Uso. Relacionamentos

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

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 a partir de outros casos de uso que

ele inclui) e fatorar variantes (obtendo esse comportamento em outros casos de uso que o estendem)


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Generalização:

Podemos usar a generalização entre casos de

uso, pelo mesmo motivo que utilizamos

nas classes, para compartilhar comportamento:

Pagto Cartão de Crédito

Receber Pagamento


Requisitos

generalização

Pagto Cartão de Débito

A generalização também pode ser aplicado aos

atores e seus respectivos papéis. Veja o exemplo:

Funcionário

RecepcionistaGerente de

Reservas


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Extends:

Podemos usa-lo para “Demonstrar 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 de Comportamento. Exemplo:


Requisitos

Alterar status do carro Consulta Cliente

<<include>>

Devolver Veículo

Calcular Multa

<<extend>><<include>>

Locadora de Automóveis

Fazer Ligação

Fazer Ligação

(Conference call)

<<extend>>

Usuário

Sala de Conferência


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Fazer Pedido

<<include>>

Acompanhar Pedido

Validar Usuário<<include>>

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. Você pode pensar na inclusão como o caso de uso base que o obtém o

comportamento a partir do fornecedor do caso de uso. Você utiliza um relacionamento de inclusão para

evitar descrever o mesmo fluxo de eventos várias vezes, incluindo o comportamento comum em um caso

de uso próprio. O relacionamento de inclusão é essencialmente um exemplo de delegação, você coleta

um conjunto de responsabilidades do sistema e o captura um único local (o caso de uso incluído); depois,

permite que outras partes do sistema (outros casos de uso) incluam a nova agregação de

responsabilidade sempre que precisamos utilizar essa funcionalidade.

Exemplos:


Requisitos

Fazer Check IN

<<include>>

Gerenciar

Reserva

Fazer Check OUT

Receber

Pagamento<<include>>


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


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

Os atores não fazem parte do sistema - eles representam qualquer um e qualquer coisa

que faça interação com sistema. Podendo ser uma pessoa, software, hardware e etc.

Uma ator pode:

- Apenas fornecer informações ao sistema

- Apenas receber informações do sistema

- Fornecer e receber informações ao 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 será usado ?

- Quais áreas serão usuárias do sistema ?

- O sistema usará recurso externo ?

- Quem será o responsável pelo sistema ?

- Quem serão os usuários do sistema ?

Requisitos


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Casos de Uso.Dicas

Um engano comum na identificação de casos de uso é representar como Caso de uso

passos individuais, operações ou transações.

Exemplo:

No domínio de ponto de venda, alguém pode definir um caso de uso chamado

“Imprimindo o Recibo”, quando de fato, a operação de impressão é meramente um passo

no processo muito mais abrangente do caso de uso Comprar Itens

Lembre-se:

Um caso de uso é uma descrição completa de processo,

que inclui outros passos ou transações.

Requisitos


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Especificação de Requisitos. Exemplo:

Documento de

Visão

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 base, capacidade de pessoas

- Tipo (Single, double, triplo ou suite)

O preço de cada apartamento está relacionado com seu tipo e 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 .

Refinado pelo


• Gerenciar Reserva

•...

12

Requisitos

„

Documento

de Requisitos


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are




Cenários

Gerenciar ReservaUsuário

Formulário

Caso de Uso

AssociaçãoAtor

3

Caso de Uso: Gerenciar Reserva

Requisitos


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are



Escrevendo os Cenários:

Cenários

Requisitos

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 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.


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 confirma a 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 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.


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


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

Compilar os Cenários em Formulário:

Requisitos

Cenário

Gerenciamento de Reserva:

O Setor de Reserva do Hotel recebe um telefonema de cliente que solicita uma reserva

de apartamentos para data.


ele precisa.

O funcionário do Setor de Reserva, verifica a disponibilidade do apartamento e confirma a

reserva.

Pré- condição

Pós- condição

Identificando a pré-condição e pós-condição:

Cenários Formulário


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


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

Compilar os Cenários em Formulário:

Requisitos

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:

Fluxo Alternativo:

Pós-condição: Reserva confirmada

Primeiras linhas do cenário

Última linha do cenário

Gerenciar Reserva

“caminho feliz”

Gerenciar Reserva

“caminho alternativo”


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Especificação de Requisitos. Exemplo:Escrevendo o Formulário de Descrição de Caso de Uso:

Requisitos


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



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 faz proposta de outro apartamento para cliente

O cliente aceita e então o funcionário confirma a reserva



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are




Cenários

Formulário

Gerenciar ReservaFuncionário

Caso de Uso

AssociaçãoAtor

3

Caso de Uso: Gerenciar Reserva

Requisitos


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


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


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


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;

3 - Dê um nome para o CASO DE USO, lembre-se que este nome deve ser único

no modelo;

4 - Escreva os CENÁRIOS para o CASO DE USO;

5 - Compile os CENÁRIOS em único FORMULÁRIO e

6 - Faça o Diagrama de Caso de Uso.

Requisitos


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Especificação de Requisitos. Template:Template do “Formulário”:

Requisitos

Nome: <nome do caso de uso>

Ponto de ativação: <informar o ponto de ativação>

Ator: <informar os atores>

Objetivo: <descrever o objetivo>

Pré-condição: <descrever a pré-condição>

Fluxo Normal:

<descrever o fluxo normal>

Fluxo Alternativo:

<descrever o fluxo alternativo>

Pós-condição: <descrever a pós-condição>

RF: <informar os código ou nomes dos RFs>

RNF: <informar os código ou nomes dos RNFs>

Data: ______ | Autor: ________ | Revisão: ____

Rastreabilidade


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Documento de Visão


de requisitos

Requisitos




Documento de

Requisitos

Documento de

Especificação

de Requisitos

Usuários e

Clientes


Regras de

negócio



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Requisitos

Validação de Requisitos

Deve preocupa-se em mostrar que os requisitos definem o sistema que o cliente/usuário

deseja.

Validação é importante uma vez que o custo para remover um erro de requisitos é

grande.

Pequeno Check List de Requisitos:

Validade. O sistema fornece as funções que melhor atende as necessidades do usuário?

Consistência. Existem conflitos de requisitos?

Completeza. Todas as funções necessárias para o cliente estão incluídas?

Realismo. Os requisitos podem ser implementados com a tecnologia e orçamento

disponíveis?

Facilidade de verificação. Os requisitos podem ser checados?


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Requisitos

Validação de RequisitosTécnicas de validação de requisitos

Revisão de requisitos:

- Análise manual sistemática dos requisitos

Prototipação:

- Uso de um modelo executável do sistema para checar os requisitos.

Geração de casos de teste:

- Desenvolver testes para os requisitos a fim de verificar a “testabilidade”.

Análise automatizada da consistência:

- Uso de ferramenta para verificar a consistência do modelo.


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Requisitos

Validação de RequisitosTécnicas de validação de requisitos

Revisão de requisitos:

- Revisões regulares devem ocorrer durante a formulação da definição dos requisitos

- Tanto o cliente quanto a equipe contratada devem estar envolvidos nas revisões

- As revisões podem ser formais (com documentos completos) ou informais. Uma boa

comunicação entre os desenvolvedores, clientes e usuários pode resolver problemas em

estágios iniciais

Verificação de revisões:

- “Verificabilidade”. O requisito é realisticamente testável?

- Compreensibilidade. O requisito é propriamente entendido?

- Rastreabilidade. A origem do requisito é claramente estabelecida?

- Adaptabilidade. O requisito pode ser modificado sem grande impacto sobre outros

requisitos?


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Formato do documento de especificação de requisitos sugerido pela 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 de projeto, características de

qualidade.

4. Apêndices

5. índice

Requisitos


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Análise Conceitual


É apresentar e discutir a Análise Conceitual suas técnicas,

conceitos e modelos.


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Big Picture. Requisitos e Análise

Glossário de

conceitos

Modelo Conceitual

Análise Conceitual

Casos de Uso



Requisitos Não

Funcionais




Documento

de Visão

Business Case

Arquitetura Inicial

4


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Arquitetura

Analista de Sistema


Analise

Workflow Analise

Analista de Requisitos

Arquiteto de SoftwareVocabulário do Sistema

Modelo Conceitual ou Modelo

de Domínio

Modelo de Arquitetura Inicial


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


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.

Introdução:

Workflow de Análise

Visão de ProjetoFuncionalidade

Vocabulário


Codificação

Montagem

Visão do ProcessoDesempenho

Escalabilidade

Throughput

Visão da ImplantaçãoTopologia do Sistema

Distribuição

Instalaçã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.

FuncionárioGerenciar Reserva


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Apresentar e discutir como elaborar o Modelo Conceitual (também chamado de modelo de

domínio) e o Vocabulário de Conceitos. Para isto apresentaremos um algumas técnicas

para identificação dos candidatos a classes.

Os objetivos desta etapa são:

1 - Apresentar técnicas para identificação dos candidatos a classes, atributos e

associações;

2 - Elaborar o Modelo Conceitual ou modelo de domínio e

3 - Elaborar o Vocabulário de Conceitos.

Objetivo:



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Modelo Conceitual

Fazer Análise Conceitual

Atividades.Road Map

Fazer Vocabulário

Vocabulário

Documento de

Visão

Caso de Uso


Definir o modelo de

Arquitetura



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Para este workflow as principais atividades e artefatos são:

Workflow de Requisitos:

Atividade:

Coletar Requisitos

Fazer Análise de Requisitos.

Fazer Especificação de Requisitos;

Artefatos: Documento de Visão


Caso de Uso


Atividade:


Fazer Vocabulário de Conceitos

Artefatos: Modelo Conceitual e

Vocabulário do Sistema.

Atividades e Artefatos:



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


“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 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 de Uso

- Digrama de Classes (na verdade o Modelo Conceitual).

Análise Conceitual. Introdução:


Os objetivos são:

1 - Apresentar técnicas para identificação dos candidatos a classe classes, atributos e

associações e

2 - Elaborar o Modelo Conceitual ou Modelo de Domínio.


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are



Atividade: Fazer Análise Conceitual

Modelo Conceitual


Documento de

Visão

Caso de Uso


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


O modelo de classe têm pelo três níveis de abstração:

- Modelo Conceitual de Classes: Representa as classes no domínio do

desenvolvimento do software, este modelo 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 Especificação: É derivado do Modelo Conceitual. 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.

Análise Conceitual. Modelos:



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


- Modelo de Classes de Implementação: É derivado 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.

Análise Conceitual. Modelos

nome

idade

Pessoa

<<refines>>

-nome

-idade

Pessoa

+setNome()

+getNome()

+getIdade()

+getIdade()

Workflow de ProjetoWorkflow de Análise

Modelo Conceitual ou

Modelo de DomínioModelo de Especificação



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are



Selecionar uma técnica

Identificar os candidatos

a classe

Fazer a Lista de

Candidatos

Desenhar o Modelo

Conceitual


Análise Conceitual. Atividades e Passos:

Definir a Arquitetura

Inicial

4


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


- Método dirigido a dados:

Neste método, a ênfase está na identificação da estrutura dos conceitos

relevantes para o domínio do negócio, resultando em Modelo Conceitual.

- Método dirigido a responsabilidades:

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.

Análise Conceitual. Identificação das Classes:


Um software orientado a objetos é composto de uma coleção de objetos que colaboram

para realizar seus requisitos. Entretanto, sabemos que os objetos são “instances” das

classes.

Para identificar as classes, podemos usar um método simples. O primeiro passo é fazer

uma lista de todas classes que encontramos, esta lista pode ser chamada de “Lista de

Classes Candidatas”.

E depois usando algum critério, eliminamos as classes irrelevantes e aí teremos uma lista

definitiva. Existem dois métodos principais para realizar a identificação das classes de

domínio de um software:


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are



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.

UML. Introdução


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


O Diagrama de Classes nasce no Workflow de Análise com Modelo Conceitual (modelo de

domínio), mais tarde no Workflow de Projeto este o modelo será refinado ganhando

adornos, novos tipos de relacionamentos, operações (métodos) e até novas classes.

Agora faremos apenas o Modelo Conceitual que podemos considerar como o primeiro

“esboço” do que mais tarde se tornará o Diagrama de Classes.

Diagrama de Classes. Introdução



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Elementos estruturais:

Classe, Interface, Colaboração, Caso de Uso, Classe Ativa, Nó e

Componente

Elementos de agrupamento:

Pacote e Subsistema

UML. Elementos:



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


• Dependência

• Associação

– Associação

– Composição

– Agregação

• Generalização

Mecanismos de Extensibilidade:

• Estereótipo

• “Tagged value”

• Restrição (Constraint)

UML. Elementos:



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Diagrama de Classes

O diagrama de classes deve

capturar o Vocabulário* do

sistema



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


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.

Usuario Senha

Associação

classe classe



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


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.

Cliente Pedidofaz

Associação


Nome da associação

Direção do nome

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.


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Navegação:

Indica qual é a direção da associação. A direção da associação pode ser unidirecional (onde

somente uma das pontas da linha de associação tenha a seta) ou bidireciona (não existem

setas em nenhum dos lados)

Cliente Pedido

Associação

Navegação

Associação



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Definição de Role Name:

É um identificador (nome) do papel da associação, podendo cada ponta ter um nome

especifico.

Modificadores:

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


Role Name:


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Definição:

A especificação de uma faixa de números cardinais, que um conjunto pode assumir.

Multiplicidade Faixa Válida:

0....1 | 0..* | * | 1 | 1..*


Multiplicidade

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

como uma expressão equivalente a um intervalo de valores ou de uma valor explícito.

Eqüivale a muitos


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Exemplo:

Multiplicidade

Para cada objeto (instance) da classe Pessoa a classe

Empresa poder ter uma ou muitos objetos.


Role Name e Multiplicidade


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Inspeção

GramaticalCRC

Outras

Técnicas

Scott Ambler

Graig Larman

Kent BeckAbbot

Peter Coad


Análise Conceitual. Técnicas:

Análise de

Caso de Uso

UML


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Modelo Conceitual. Técnica: Inspeção Gramatical


Introdução:

A primeira etapa na construção do Modelo Conceitual é identificar 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, 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.


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are



1º Lista Lista FinalDeclaração de

Visão

Identificação dos

candidatos a classe,

associações e atributos

Fazer revisão da lista:

Eliminar conceitos os repetidos,

ambíguo, irrelevantes e etc..

Lista de Candidatos:

Conhecimento do Negócio Interações



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Lista de Candidatos

Artefatos:

Vocabulário de Conceitos

4

Modelo Conceitual




ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are




Classe

Atributo

Associação

Multiplicidade

Nome da associação

Reserva

numero

data-entrada

data-saida

Cliente

id

nome

documento

Apartamento

numero

tipo

situacao

11..* feita por

0..*

1..*

hospede


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Declaração do Problema:

O cliente solicitou o desenvolvimento de software para apoiar uma rede bancária

computadorizada incluindo caixas humanos e máquinas de auto atendimento (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 de seus

bancos proprietários. Os caixas 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 com o sistema central para executar

transações, 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 e para a rede. O custo do sistema compartilhado deve ser

distribuído pelos bancos de acordo com número transações realizadas.

Modelo Conceitual. Técnica: Inspeção Gramatical - Exemplo



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


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




ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Software Rede Bancária Caixa

ATM Consórcio Banco

Computador do Banco Conta Transação

Terminal do caixa Dados de contas Dados de transações

Computador Central Cartão Magnético Usuário

Dinheiro Extrato Sistema

Manutenção do

arquivo de Registro

Reserva de segurança Acesso

Preço Cliente

Identificando os conceitos:




Classes da ATM originadas do conhecimento do domínio do problema

Linha de Comunicação Registro de transação


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Identificando os conceitos:


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, Banco, Computador do Banco, Cartão Magnético, Caixa Terminal do Caixa, Computador

Central, Consórcio, Cliente e Transação


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Identificando as Associações:

Qualquer dependência entre duas ou mais conceitos é uma associação. Uma referência

de uma classe a outra é uma associação.

As associações muitas vezes correspondem a verbos estáticos ou a locuções verbais.

Isso inclui localização física:

- junto a, parte de, contido em e etc

Ações indiretas:

- direciona, comunica-se (fala a), propriedade (tem, parte de), ou satisfação de alguma

condição (trabalha para, casado com, gerencia).

Tente identificar as associações, lembre-se que nem todas, estão explicitas, pode haver

muitas transações implícitas e algumas associação dependem do conhecimento do

mundo real, ou seja, do negócio.

Extraia todas as candidatas do enunciado do problema e as escreva em uma lista, e

depois refine-as.




ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are



Lista (Frases verbais):

Rede de bancária inclui caixas e 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 com o computador 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




ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are



Lista (Frases 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




ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


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 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.




ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are



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 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.




ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Conceito de

classes e atributos

Classes

Workflow de Análise Workflow de Projeto

Transacao

Datahora:Timestamp

+getTransacao()

+setDataHora()

+getDataHora()

Transacao

Datahora

Modelo Conceitual vs Modelo de Especificação




ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Modelo Conceitual:




ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


CRC

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, 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.

Método dirigido a responsabilidades:

Neste método, a ênfase está na identificação das classes a partir de seus comportamentos

relevante ao sistema.



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


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 outros objetos do software

para cumprir com sua responsabilidade.

Responsabilidades:

(o que objeto conhece e o que faz)

Objeto

Colaborações:

(outras classes que são associadas,

para a interação entre os objetos)+



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


CRC. Elementos:

O nome do cartão é o mesmo nome da classe, as responsabilidades são as coisas que a

classe dever saber fazer e coisas que ela deve conhecer.

As colaborações as informações que a classe precisa e que está alocada em outra classe,

desta forma temos que fazer o relacionamento entre classes, para que ela

cumpra com sua responsabilidade.

Modelo:

Responsabilidades:

Nome da Classe

Lista das responsabilidades

Colaborações:

Lista de colaborações


Melhores Práticas:

Os candidatos a classe cujo a responsabilidade não foi encontrada, este candidato deve

ser descartado. Pois, não podemos ter classe sem nenhuma responsabilidade.


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


CRC. Exemplos:

Responsabilidades:

Classe: Reserva

Conhecer o período da reserva

(datas)

Saber o nome do cliente

Saber o número do apartamento

Colaborações:

Apartamento

Cliente

Responsabilidades:

Classe: Cliente


Saber a Reserva do Cliente

Colaborações:

Reserva



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Modelo Conceitual. Técnica: Inspeção Gramatical & CRC

Lista de Candidatos

Identificação dos candidatos

Inspeção Gramatical


Responsabilidades:

Classe: Cliente



Colaborações:

Reserva

Responsabilidades:

Classe: Cliente



Colaborações:

Reserva

Responsabilidades:

Classe: Cliente



Colaborações:

Reserva

CRC

Identificação das Responsabilidade Modelo Conceitual

UML


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


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 Requisitos Funcionais. Nesta análise é identificado os candidatos

a classe.

Cenários

Gerenciar ReservaUsuário

Formulário

Caso de Uso

AssociaçãoAtor

Listas de Candidatos



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Análise de Caso de Uso. Big Picture

Cenários

Gerenciar ReservasUsuário

Formulário

AssociaçãoAtor

Casos de Uso


Lista de Requisitos

Funcionais

Lista de Requisitos

Não Funcionais

Análise de RequisitosEspecificação de Requisitos


Documento de VisãoLista de

Candidatos1

4


2

3


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


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.


Gerenciar ReservaUsuário Reserva é provável candidato a classe

Criar Reserva

Atualizar Reserva

Remover Reserva

Cadastrar Cliente

Buscar Apartamento

<<include>>

<<include>>Funcionário

prováveis candidatos a classe


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Como fazer. Cenários:2 - Os cenários devem usados para identificação dos candidatos. Ache os substantivos,

exemplo:


Cenários:

Cenários

Gerenciar de Reserva:

O Setor de Reserva do Hotel recebe um telefonema de cliente que solicita uma reserva

de apartamentos para data.


ele precisa.

O funcionário do Setor de Reserva, verifica a disponibilidade do apartamento e informa

que não tem disponibilidade de apartamento para o período informado pelo cliente e

oferece um outro tipo de apartamento.

O cliente não aceita a proposta do funcionário e a reserva não é confirmada.

Prováveis candidatos a classe

Análise de Caso de Uso: Identificando os candidatos a classe


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are



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



Fluxo Normal:

O cliente informa o tipo de apartamento

O cliente o período (data de chegada e partida)


O funcionário confirma a reserva

Fluxo Alternativo:

...


O funcionário faz proposta de outro apartamento para cliente

O cliente aceita e então o funcionário confirma a reserva


Análise de Caso de Uso: Atividades

Como fazer. Formulário:3 - Os Formulários também devem usados para identificação dos candidatos. Ache os

substantivos, exemplo:


Formulários

Prováveis candidatos a classe


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Modelo Conceitual. Técnica: Inspeção Gramatical & CRC

Lista de Candidatos

Identificação dos candidatos

Análise de Caso de Uso


Responsabilidades:

Classe: Cliente



Colaborações:

Reserva

Responsabilidades:

Classe: Cliente



Colaborações:

Reserva

Responsabilidades:

Classe: Cliente



Colaborações:

Reserva

CRC

Identificação das Responsabilidade Modelo Conceitual

UML


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Dicas: Scott Ambler

Para encontrar as classes, vejamos algumas dicas:

1 - Considere que as classes são lugares, eventos, conceitos, pessoas e etc.

2 - Atores são classes em potencial;

3 - Identifique os clientes;

4 - Siga o dinheiro, podemos identificar produtos, serviços, eventos como venda,

compra e etc;

5 - Conceitos são classes em potencial;

6 - Eventos são classes em potencial e

7 - Entende o negócio.

Use a técnica CRC para atribuir ou descobrir as responsabilidades e colaborações

das classes encontradas



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Graig Larman

Larman sugere a que a identificação dos substantivos, que são os candidatos a classe ou

conceitos seja feito através dos Casos de Uso “expandidos”, pois, eles fornecem uma

excelente descrição a serem usadas como fontes para este tipo de análise.

Exemplo:

Exemplo de Caso de Uso expandido:

Seqüência típica de eventos:

1 - Este caso de uso começa quando um Cliente chega a um ponto de venda e deseja

comprar alguns itens.

2 - O Caixa registra o código do produto de cada item

...

Entretanto esta técnica exige uma ou mais revisão nos conceitos encontrados, pois,

diferentes substantivos podem representar o mesmo conceito.



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


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

Especificação, projeto, ou descrição de coisas Especificação de produtoDescrição de vôo

Objeto físico ou tangível Terminal de ponto-de-vendaAvião

Lugares LojaAeroporto

Transações Venda, PagamentoReserva

Exemplos

Itens de transação Itens de vendaParcelas de pagamento

Papéis de pessoas OperadorPiloto



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


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 Resposta do Sistema

1. Este caso de uso começa quandoum Cliente chega no caixa com itenspara comprar.2. O Operador registra o identi-ficadorde cada item.

Se há mais de um do mesmo item, oOperador também pode informar aquantidade.

3. Determina o preço do item eadiciona informação sobre o item àtransação de venda em anda-mento.

Mostra a descrição e o preço do itemcorrente.



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Peter Coad

A Proposta de Coad & Yourdon:

O método Análise Orientada a Objetos, proposto por Peter Coad e Yourdon e denominado

OOA (Object Oriented Analysis), consiste basicamente em cinco passos:

1 - Localização de classes-&-objetos: entende-se por objetos como a abstração de alguma

coisa, em um domínio de problema, cujas informações devam ser manipuladas pelo

sistema. Uma classe corresponde ao conjunto de objetos semelhantes.

2 - Identificação de estruturas: que podem ser classificadas em:

Generalização-especialização: quando uma classe é\ um tipo de uma outra classe.

Exemplo: a classe carro é uma especialização da classe veículos;

Todo-parte: quando uma classe é formada por outras classes. Exemplo: as classes

motor e chassis fazem parte da classe carro.

3 - Definição de assuntos: onde cada qual se relaciona a diferentes partes do modelo,

permitindo minimizar a complexidade de projetos extensos.



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Dicas: Peter Coad

A Proposta de Coad & Yourdon

4 - Definição de atributos: um atributo é definido como uma propriedade, uma 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 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 relacionamentos entre objetos.

5 - Definição de Serviços: um serviço é um comportamento específico que um objeto

deve 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,

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.



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Modelo Conceitual


Vocabulário.Road Map:

Fazer Vocabulário

Vocabulário

Documento de

Visão

Caso de Uso



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Vocabulário:

Fazer Vocabulário:

Devemos fazer um Vocabulário de todas as classes presente no Modelo Conceitual.

O vocabulário consiste em simples descrição do conceito.


Transacao

Datahora

Transação – Uma única solicitação integral para operações nas

contas de um único cliente. Especificamente somente que as ATM

podem entregar dinheiro, mas não podemos eliminar a

possibilidade da impressão de cheques ou de receber dinheiro ou

cheques. Também queremos prover a flexibilidade de operar as

contas de diferente clientes, embora isso não seja exigido. As

diferentes operações devem fechar apropriadamente.

Fazer Vocabulário

Descrever os conceitos


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Modelo Conceitual.



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Vocabulário:

ATM – Uma estação que permite os clientes introduzem suas próprias transações

utilizando cartões magnéticos como identificação. A ATM interage com o cliente para

obter informações sobre transações, envia as informações sobre transações para o

computador central para validação e processamento e entrega de dinheiro ao usuário.

Presumimos que uma ATM não necessita operar independente de rede.

Banco – Uma instituição financeira que mantém contas de cliente e emite cartões

magnéticos autorizando o acesso às contas através da ATM.

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.

Vocabulário. Exemplo:



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


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. Cada cartão contém um código de banco e um

número de cartão, codificados de acordo com os padrões definidos pelo Bacen (Banco

Central) sobre cartões de créditos e cartões magnéticos.

O código do banco identifica inequivocamente 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.




ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Vocabulário:

Computador Central - Computador operado pelo consórcio que despacha transações entre as ATM e

os computadores dos bancos. O computador central valida códigos de bancos mas não processam

transações diretamente.

Consórcio – Organização de bancos que comissiona e opera a rede ATM. A rede só manipula

transações do consórcio.

Conta – Única conta no banco contra a qual as transações podem ser aplicadas. As contas podem ser

de vários tipos, no mínimo de cheques e de poupança. Um cliente pode manter mais de uma conta.

Terminal de caixa – Terminal no qual os caixas introduzem transações para os clientes. Os caixas

entregam a recebem dinheiro e cheques; a impressora do terminal imprime extratos. O terminal do

caixa comunica-se com o computador central do banco para validar e processar transações.

Transações – Uma única solicitação integral para operações nas contas de um único cliente.

Especificamente somente que as ATM podem entregar dinheiro, mas não podemos eliminar a

possibilidade da impressão de cheques ou de receber dinheiro ou cheques. Também queremos prover

a flexibilidade de operar as contas de diferente clientes, embora isso não seja exigido. As diferentes

operações devem fechar apropriadamente.




ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Diagrama de Objetos

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 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:

Atributo: Valor do atributo

:Nome do Objeto

Atributo: Valor do atributo

Nome do Objeto

vínculo

objeto


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.


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Diagrama de ObjetosRecomendamos o uso do Diagrama de Objetos para validar o Diagrama de Classes.

Exemplo:

-Nome: String

-Data: Date

Aluno

-Matricula: int

-Curso: String

Matricula

Diagrama de Classe

Nome: “Fulano de Tal”

Data: 23-02-2001

:Aluno

Matricula: 201-23-02-01

Curso: Adm Empresas

201-23-02-01:Matricula

Nome da

associação

vinculo

objeto

Valor do atributoAtributo

Nome do

objeto“Instance”

Diagrama de Objetos



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Diagrama de Objetos

Conteúdo do Diagrama de Objetos:

Objetos e Vinculo

Nome: “Fulano de Tal”

Data: 23-02-2001

:Aluno

Matricula: 201-23-02-01

Curso: Adm Empresas

201-23-02-01:Matricula

Diagrama de Objetos

vínculo

objeto

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.



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Diagrama de Objetos

Como fazer a modelagem de um estrutura de objetos:

• Identifique o mecanismo cuja modelagem você deseja fazer. Um mecanismo

representa algum requisito ou comportamento da parte do sistema cuja a

modelagem você está fazendo e que é resultante da 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 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.

Como posso

validar o

diagrama de

classes?



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Modelo Conceitual


Arquitetura Inicial.Road Map

Fazer Vocabulário

Vocabulário

Documento de

Visão

Caso de Uso


Definir o modelo de

Arquitetura



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Modelo de Inicial de Arquitetura

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”.


4

Camada

apresentação

Banco de

Dados


Camada de

serviço

(controle)

Camada

regra de

negócio

Definir o Modelo de

Arquitetura

Definir o Modelo de

Arquitetura Inicial


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Diagrama de Pacotes

Como podemos definir o diagrama de pacotes?

A definição de Pacote é uma generalização, ou seja, um agrupamento, com o propósito de

organizar as Classes de Objetos em grupos. Esta abordagem facilita a análise a medida

que o número de Classes de Objetos cresce num do cenário. O tipo de relacionamento é

linha pontilhada com uma seta que indica dependência. Os diagramas de pacote podem

ser usados para fazer decomposição funcional.

A notação usada pela UML para representar pacotes é:

Nome do

Pacote

Nome do Pacote

Nome do

Pacote

Dependência

(import)

Nome do

Pacote

Apêndice


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Diagrama de Pacotes

Decomposição. “Dividir para conquistar...”

Algumas aplicações podem ser enormes ou ter um grau muito alto de complexidade ou

ambas as coisas. Para facilitar é necessário fazer uma decomposição.

A idéia da decomposição é simples. É fazer uma divisão para simplificar o entendimento, a

modelagem ou processo de desenvolvimento de um software.

Veja o exemplo abaixo:

Nome do Pacote

Dependência

(import)

Contas a

Pagar

Contas a

Receber

Fluxo de

Caixa

Subsistema

Apêndice


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Desenho (design) do Modelo de

Especificação de Software


É apresentar e discutir o desenho (modelo de especificação)

seus conceitos, técnicas e modelo.


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Apresentar e discutir o Workflow de Projeto, também conhecida como “Fase de

Especificação”, agora faremos uso da intenso da UML para fazer os modelos (diagramas)

e a documentação.

As principais atividades são:

- Construção do Modelo de Especificação (Projeto)

- Construção do Modelo de Arquitetura

- Fazer validação do modelo.

Objetivo:

Workflow de Projeto


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Introdução. UML, Visões:

Conceitual Físico

Visão de Projeto

Funcionalidade

Vocabulário


Codificação

Montagem

Visão do Processo

Desempenho

Escalabilidade

Throughput



Distribuição

Instalação


Workflow de Projeto


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Workflow de Projeto


• A visão do processo abrange os “threads” e os processos que formam os mecanismos de

concorrência e de sincronização do sistema. Essa visão tem com objetivo principal tratar questões

de desempenho, à crescimento escalar e ao “throughput” do sistema. Com a UML, os aspectos

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 processos.

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

programas ou parte.

Visão de Processo

• 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.

Visão de Projeto


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


O Workflow de Análise é determinado pelo “aspecto estrutural estático”, que permite

entender como uma software está estruturado internamente para atender os requisitos.

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.

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

Workflow de Projeto

No Workflow de Projeto, faremos a modelagem dos aspectos dinâmicos do sistema, estes

aspectos são capturados em digramas (diagrama de interação, diagrama de estados e

diagrama de atividades).

E assim podemos representar os comportamentos internos e desta forma teremos novas

visões do software e aí conseguiremos compreender melhor o software.


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


ESTÁTICOS

. Diagrama de Classes

. Diagrama de Objetos

. Diagrama de Componentes

. Diagrama de Distribuição

DINÂMICOS

. Diagrama de Casos de Uso

. Diagramas de Interação

- Diagrama de Seqüência

- Diagrama de Colaboração

. Diagrama de Atividade

. Diagrama de Estados

Modela o comportamento do sistemaModela a estrutura do sistema

Workflow de Projeto

UML. Principais Diagramas:

Workflow de ProjetoWorkflow de Análise

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


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


A Workflow de Projeto depende da Workflow de

Análise:


Workflow de Projeto

Análise

Projeto

Introdução

dependência

Workflow de Projeto


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


A Workflow de Projeto refina a Workflow de

Análise:

Cliente

codigo

nome

Cliente

-codigo: int

-nome: String

+getCodigo()

+setCodigo()

+getNome()

+setNome()


modelo conceitual

Workflow de Projeto

Diagrama de Classes

<<refine>>

métodos

Atributos:

Tipo de dados

Introdução

Atributos:

Visibilidade

Workflow de Projeto


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Big Picture. Projeto

Modelo Conceitual

4

Análise

Diagrama de Classes


4


exibirCategoria( )

exibirProduto( )

selecionarCategoria


getDescricao( )


Receber Pedido

Preencher Pedido

Receber Pagamento

Enviar Fatura

Entrega durante



Encerrar Pedido

Entrega



Workflow de Projeto


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Arquitetura

Analista de Sistema

Projetista de Software


Arquitetura

Arquiteto de Software

Workflow de Projeto

Diagrama de Seqüência /

Colaboração

Diagrama de Classes


Diagrama de Estados


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Modelo de Especificação

Fazer Modelo de Especificação

Atividades.Road Map

Fazer Modelo de Arquitetura

Modelo de Arquietura

Modelo

conceitual

Caso de Uso

Workflow de Projeto


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Fazer Modelo Especificação

Fazer Diagrama de

Interação

Identificar as classes de

Especificação

Fazer a Diagrama de

Atividades / Estados*

Refinar o Modelo

de Classes

Projeto. Atividades e Passos:

Workflow de Projeto

Modelo de

Especificação


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


selecionar categoria

buscar produtos

<<include>>

visitante

Formulário

Diagrama de Sequência


exibirCategoria( )

exibirProduto( )

selecionarCategoria


getDescricao( )


Diagrama de Estado

Casos de Uso. RevisãoUso caso de uso descreve “o quê” um sistema faz, ele não especifica “como” isso é feito.

Ao fazer uma modelagem, importante manter clara a separação de questões entre a visão

interna e externa. “O como” é modelado pelo Diagrama de Interação.

“O quê”

“O como”

Workflow de Projeto


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Diagrama de Interação são modelos que descrevem como grupos de objetos colaboram

para atender comportamento.

Tipicamente, um diagrama de interação captura o comportamento de um único caso de

uso. O diagrama deve mostrar os vários objetos e as mensagens que são passadas entre

estes objetos.

Diagrama de Interação. Introdução

Existem dois tipos de diagramas:

• Diagrama de Seqüência:

O foco deste diagrama é maneira que as mensagens são enviadas ao longo do tempo.

• Diagrama de Colaboração:

Aqui o foco é o relacionamentos estrutural entre os objetos de uma interação e então

considerar como as mensagens são passadas no contexto dessa estrutura.

Workflow de Projeto


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


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.

Ator:

:Objeto 1 :Objeto 2

1: mensagem 1

2: mensagem 2

3: mensagem 3

Notação:

Diagrama de Seqüência

Workflow de Projeto


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are



Diagramas de Seqüência:

Workflow de Projeto


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are



Aluno:

formulários de

registro

formulário de

matrícula

cursos

disponíveis

entrar com senha de

acesso

validar acesso

entrar com o

semestre

criar nova matrícula

apresentar em tela

obter cursos

Diagramas de Seqüência:

Workflow de Projeto


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Diagrama de InteraçãoDiagramas de Seqüência. Elementos:

: Atendente : Cliente : Veiculo : Locacao

getDadosCliente( )

[* se cliente cadastrado

verificar divida ]

getDivida( )

getDisponibilidade( )

[* se veículo

disponível ]

setSaida( )

ator

Instance das classes

Linha do tempo

As interações entre os

objetos

Restrição ou

condição

Autodelegação

Workflow de Projeto


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are



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


2: exibirCategoria( )

6: exibirProduto( )

3: selecionarCategoria

7: selecionarProduto( )

1: getDescricao( )

4: getDescricao( ) 5: getQuantidade( )

Diagramas de Seqüência. Numerando as seqüências das mensagens.

Workflow de Projeto


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are



Quando usar o diagrama de Colaboração ?

Se a ênfase do diagrama for o decorrer do tempo, é melhor escolher o

diagrama de seqüência, mas se a ênfase for relacionamentos estrutural

entre os objetos de uma interação, é melhor dar prioridade ao diagrama

de colaboração. Podemos também escolher ambos.

Diagrama de Seqüência é mais usual.

O que é Diagrama de Colaboração?

É um diagrama que mostra a colaboração dinâmica entre os objetos, semelhante ao

diagrama de seqüência.

No diagrama de colaboração, além de mostrar a troca de mensagens entre os objetos,

percebe-se também as colaborações dos objetos.

A interação de mensagens é mostrada em ambos os diagramas.

Diagrama de Colaboração tem a maioria de suas características semelhantes ao

Diagrama de Seqüência.

Workflow de Projeto


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are



O que é Diagrama de Colaboração ?

O diagrama de colaboração é desenhado como um diagrama de objeto, onde os diversos

objetos são mostrados juntamente com seus relacionamentos. As setas de mensagens

são desenhadas entre os objetos para mostrar o fluxo de mensagens entre eles. As

mensagens são nomeadas, que entre outras coisas mostram a ordem em que as

mensagens são enviadas. Também podem mostrar condições, interações, valores de

resposta, e etc. O diagrama de colaboração também pode conter objetos ativos, que

executam paralelamente com outros.

Exemplo:

Diagrama de Colaboração

6:obter cursos

Ator (José)

formulários de registro

2: validar acesso

1:entrar com chave

de acesso3:entrar com o

semestre

4:criar nova matrícula

formulário de matrículacursos disponíveis

5:apresentar

em tela

Workflow de Projeto


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are



Gerando Diagramas de Colaboração:

Na ferramenta “Rational Rose”, após criarmos o diagrama de seqüência. Selecionar:

~ Menu Browse e depois a opção F5 (Create colaboration Diagram)

: visitante

:

Categori

:

Produto

: Form

Busca

: Catalogo

2: exibirCategoria( )

3: selecionarCategoria

5: getQuantidade( )

6: exibirProduto( )

7: selecionarProduto( )

1: getDescricao( )

4: getDescricao( )

Workflow de Projeto


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Fazer Modelo Especificação

Fazer Diagrama de

Interação

Identificar as classes de

Especificação

Fazer a Diagrama de

Atividades / Estados*

Refinar o Modelo

de Classes

Projeto. Atividades e Passos:

Workflow de Projeto

Modelo de

Especificação


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Diagrama de Estado

O que é Diagrama de Estado?

É um diagrama que tipicamente complementa a descrição das classes. Pois, este

diagrama exibe todos os estados possíveis que objetos de uma certa classe podem se

encontrar. Mostra também quais as variações de comportamento provocam tais

mudanças.

Não necessário escrever o diagrama de estado para todas as classes de um sistema,

mas, apenas para aquelas que possuem um número definido de estados conhecidos e

onde o comportamento das classes é afetado e modificado pelos diferentes estados.

Diagramas de estado capturam o ciclo de vida dos objetos, subsistemas e sistemas.

Aplicação:

Um diagrama de estado pode ser aplicado a diversos elementos da UML, tais como:

- Classes e Casos de Uso

Workflow de Projeto


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


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 Transição

Início do fluxoFinal do fluxo

Diagrama de Estado

Workflow de Projeto


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Diagrama de Estado

Exemplo:

ocioso

início

Ativo

fora do gancho

no gancho

transição

Estado

Workflow de Projeto


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Exemplo 1:

Diagrama de Estado

Trata

Evento

Inicializa o

Objeto

Finaliza

Objeto

Espera por

Evento

on

off

Lamp

On

Lamp

Off

off

on/print(”on”)

stop

Workflow de Projeto


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Diagrama de EstadoExemplo 2: (Completo)

início

Verificando Expedindo

Aguardando

Cancelamento

cancelamento

Entregue

cancelado

[Todos os itens

verificados e

alguns itens não

estão disponíveis]

[Todos os itens verificados e

os todos itens disponíveis]

Item recebido

[os todos itens

disponíveis]

final

[Nem todos os itens verificados]/pegar

próximo item

[itens ecebidos

[alguns itens não

estão disponíveis]

Workflow de Projeto


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Exemplo:

Caso de Uso

Diagrama de Estado

Autenticar

Senha

Cliente

Consultar

Pedido

Cancelar

Pedido

Gerenciar

Pedido

Pedido

Confirmar

<<extends>>

FuncionárioUpdateStatus

Pedido

Logistica

<<include>>

Verificando Status

Cancelando Pedido

Mudando Status[Pedido não entregue]

Diagrama de Estado

Workflow de Projeto


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


O que é Diagrama de Atividade?

É um diagrama que exibe o fluxo seqüencial das atividades, é geralmente utilizado para

demonstrar as atividades executadas por uma operação específica do sistema, como por

exemplo seleção de um item do menu principal.

Consistem em estados de ação, que contém a especificação de uma atividade a ser

desempenhada por uma operação do sistema. Decisões e condições, como execução

paralela, também podem ser representados no diagrama de atividade.

O diagrama também pode conter especificações de mensagens enviadas e recebidas

como partes de ações executadas.

Diagramas de atividade capturam ações e seus resultados. Eles focam o trabalho

executado na implementação de uma operação (método), e suas atividades numa

“instance” de um objeto. O diagrama de atividade é uma variação do diagrama de estado

e possui um propósito um pouco diferente do diagrama de estado, que é o de capturar

ações (trabalho e atividades que serão executados) e seus resultados em termos das

mudanças de estados dos objetos.


Workflow de Projeto


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Elementos

Fazer Pedido

Cliente

Processar Pedido

Separar Produtos

Enviar Pedido

Cobrar Cliente

Fechar Pedido

Receber Pedido

Pagar Fatura

Vendas Estoque

raias

junção

separação

atividade

Elementos e Exemplo com comentários:


Atividade

atividade

decisão

Barras de

sincronização

transição

responsabilidades

Workflow de Projeto


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Os estados no diagrama de atividade mudam para um próximo estágio quando uma ação é

executada (sem a necessidade de especificar nenhum evento).

Outra diferença entre o diagrama de atividade e o de estado é que podem ser colocadas como

swimlanes (raias). Uma swimlane agrupa atividades, com respeito a quem é responsável e onde

estas atividades residem na organização, e é representada por retângulos que englobam todos os

objetos que estão ligados a ela (swimlane).

Um diagrama de atividade é uma maneira alternativa de se mostrar interações, com a possibilidade

de expressar como as ações são executadas, o que elas fazem (mudanças dos estados dos objetos),

quando elas são executadas (seqüência das ações), e onde elas acontecem (swimlanes).


Workflow de Projeto

Um diagrama de atividade pode ser usado com diferentes propósitos inclusive:

Para capturar os trabalhos que serão executados quando uma operação é disparada (ações). Este

é o uso mais comum para o diagrama de atividade.

Para capturar o trabalho interno em um objeto.

• Para mostrar como um grupo de ações relacionadas podem ser executadas, e como elas vão afetar

os objetos em torno delas.

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

Para mostrar como um negócio funciona em termos de trabalhadores (atores), fluxos de trabalho,

organização, e objetos (fatores físicos e intelectuais usados no negócio).

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

fluxograma.


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Receber Pedido

Preencher Pedido

Receber Pagamento

Enviar Fatura

Entrega durante



Encerrar Pedido

Entrega


Exemplo 2:

Workflow de Projeto


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


- Quando utilizar Diagrama de Atividade:

Como a maioria das técnicas de modelagem comportamental, os diagramas de

atividades têm 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 destes diagramas é que eles não deixam muito claro as ligações entre as

ações e objetos.

Você pode definir uma ligação para um projeto rotulando uma atividade com um nome

de objeto ou usando raias que dividem uma diagrama de atividades em base em

responsabilidades, mas, isso não tem a clareza simples de diagramas de interação.


Workflow de Projeto


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Quando utilizar Diagramas de Atividades:

Podemos utilizar diagrama de atividade nas seguintes situações:

- Analisando um caso de 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.

- Compreendo workflow: Os diagramas de atividades são muito úteis para compreensão de

um processo de negócio.

- Descrevendo um algoritmo sequencial 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: Neste caso o

diagrama de estado é o mais indicado.


Workflow de Projeto


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


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 é derivado do Modelo Conceitual (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.

Diagrama de Classes. Introdução

Workflow de Projeto


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


• O diagrama de classe é um elemento estrutural

Diagrama de Classe. Revisão:

Workflow de Projeto


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Diagrama de Classe. Exemplo:

Workflow de Projeto


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Diagrama de Classe. Revisão:

Refinamentos:

1 - Refinamento:

Atributos: Acrescentar tipos de dados e visibilidade

exemplo: codigo

-codigo: int (private int codigo)

2 - 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

Cliente

codigo

nome

Cliente

-codigo: int

-nome: String

+getCodigo()

+setCodigo()

+getNome()

+setNome()

Fase de Análise

modelo

conceitual

Fase de Projeto

Diagrama de

Classes

<<refine>>

métodos

Atributos:

Tipo de dados e

Visibilidade

Pessoa

nome

ItemPedito

Quantidade

Cliente

cpf

codigo

1

Relacionamento

Herança

Pedido

Data

Status

Numero

item1..n

Workflow de Projeto


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Diagrama de Classes. Refinamento

1 - Refinamento:

Exemplo: Atributos e Métodos:

Cliente

codigo

nome

Cliente

-codigo: int

-nome: String

+getCodigo()

+setCodigo()

+getNome()

+setNome()

+getCliente()

Fase de Análise

modelo conceitualFase de Projeto

Diagrama de Classes

<<refine>>

métodos

Atributos:

Tipo de dados e

Visibilidade

Workflow de Projeto


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are



1 - Refinamento:

Atributos: Acrescentar tipos de dados e visibilidade e métodos.

exemplo: codigo

-codigo: int (private int codigo)

Método: Definir os Métodos

Cliente

codigo

nome

Cliente

-codigo: int

-nome: String

+getCodigo()

+setCodigo()

+getNome()

Fase de Análise


Diagrama de Classes

<<refine>>

métodos

Atributos:

Tipo de dados e Visibilidade

Workflow de Projeto


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are



2 - Refinamento:

Acrescentar: outros tipos de relacionamento entre as classes

exemplo: agregação, composição, herança

Acrescentar: Navegação, Role Name (papéis) e Multiplicidade

Pessoa

nome

Fase de Análise


Diagrama de Classes

<<refine>>

cliente

PessoaFisica

codigo

cpf

Pessoa

cpf

nome

PessoaFisica

codigo Role name

Relacionamento

Herança

Workflow de Projeto


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are



Herança, Agregação, Composição, Associação

Graduação Pós-Graduação

Curso

Universitário

Especialização Extensão

Herança

extends

extends

Podemos dizer que Pós-

Graduação é tipo de Curso

Universitário, assim como

Curso de Especialização ou

de Extensã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.

Workflow de Projeto


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are




EspecialidadeMédica

Ortopedia Pediatria

generalização

especializaçãoTipo de Tipo de

ContaBancaria

ContaCorrente ContaPoupança

Tipo de Tipo de

Workflow de Projeto


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are




Figura

Retangulo Circulo

Tipo de

TipoPagamento

CartaoCredito CartaoDebito

Tipo de

Tipo de

Herança:

Quais associações são inválidas:

Ponto

Tipo de

Cartao

Workflow de Projeto


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Refinamentos:

3 - Refinamento:

Acrescentar: Associação Qualificada (qualificador),

associações reflexivas e Constraint (restrições)

4 - Refinamento:

Acrescentar: Classes Associativas, Interfaces e Dependência

CPF-cpf

Cliente

-codigo: int

-nome: String

-idade: int

+getCodigo()

+setCodigo()

+getNome()

+setNome()

+getIdade()

+setIdade()

getCPF()

setCPF(){ idade > 18}

CPF-cpf

getCPF()

setCPF()

Sociio

-codigo: int

-idade: int

+getCodigo()

+setCodigo()

+getIdade()

+setIdade()

{ idade > 18}

<Interface>

Pessoa-nome: String

+getNome()

+setNome()

Livro

-isbn

-titulo

getISBN()

setISBN()

setTitulo()

getTitulo()Emprestimo

-data

-status

getData()

setDAta()

setStatus()

getStatus()

**

Workflow de Projeto

Diagrama de Classes Avançado. Refinamento


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


3 - Refinamento:



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, isto quando, precisamos ter recurso de pesquisa em uma das extremidades da

associação.

qualificador

Classe

atributos

Nome da

associação0..1

Classe

atributospapelpapel

Workflow de Projeto



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


3 - Refinamento:



Associação Qualificada

Pedido Produto

ItemPedido

quantidade: intLinha de item

0..1

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. Para fazer

acesso a um item de pedido em especifico, é necessário identificar o produto como

argumento.

Workflow de Projeto



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


3 - Refinamento:


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.

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.

Classe*

1Nome da associaçãopapel

papéis

Workflow de Projeto



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


3 - Refinamento:


Associações Reflexivas e Constraint (restrições)

Associação Reflexiva:

Exemplo

Empregado*

1

Supervisão

Supervisor

Supervisionado

Neste exemplo existe uma associação reflexiva objetos de 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



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


3 - Refinamento:


Associações Reflexivas e Constraint (restrições)

Duas opções para representar restrições em UML:

• Informal, a UML permite usar qualquer notação para representar as restrições,

entretanto , as estas devem ser especificadas dentro de chaves “{ }”, podemos usar a

linguagem formal, por exemplo.

• Formal, UML fornece linguagem formal de restrições de objetos. (OCL - Object

Constraint Language).

Veja mais: http://www.omg.org/technology/documents/formal/ocl.htm

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..1Classe

atributospapelpapel

Workflow de Projeto



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


3 - Refinamento:


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, or

overlapping e transient.

0..1

Contrato

atributos

Pessoafisica

atributos

PessoaJuridica

atributos

{ ou }

0..1

Veja o exemplo: da restrição

“ou”.

Workflow de Projeto



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


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.

4 - Refinamento:


Classe

atributos

*Classe

atributos

*

Nome da Associação

atributos

Classe de Associação

Workflow de Projeto



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Classe Associativa

Exemplo

Fornecedor

atributos

*Produto

atributos

*

ProdutoFornecido

atributos

Associação de muitos:muitos

Classe de associação

4 - Refinamento:


Workflow de Projeto



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Interface:

O que é interface ?

(Representa a forma mais pura de abstração de dados - 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.

<<interface>>

Nome Interface

Métodos (assinatura)

Assinatura do

métodos

Estereotipo e

nome da interface

4 - Refinamento:


Nota: Na interface também podemos declarar constantes (public static final).

Workflow de Projeto



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Interface:

Exemplo

Interface, realização e classes

<<interface>>

PessoaJuridicagetCNPJ()

setCNPJ()

setContrato()

getContrato()

PrestadorServico

atributos

Fornecedor

atributos

4 - Refinamento:


Realização

Workflow de Projeto



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


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.

4 - Refinamento:


FilmClip

play(c: Channel)

start()

stop()

pause()

Channel

dependência

Workflow de Projeto



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Granularidade:

Geralmente para cada atributo criamos um par de métodos getter e setter, estes

métodos garantem o encapsulamento dos dados. Entretanto, quando estamos em um

ambiente distribuído (de rede), fazer a manipulação de vários e métodos e atributos,

um a um, pode causar um péssimo desempenho, temos que considerar latência de

rede, largura de banda e etc.

Para evitar esta situação podemos criar um método chamado getCliente(), que

contempla todos os dados do cliente, desta forma estaríamos fazendo um única

requisição.

Workflow de Projeto

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: Cada atributo tem seu par de método.

Diagrama de Classes. Outros conceitos: Granularidade


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Diagrama de Classes. GranularidadeGranularidade: Exemplo

Cliente

-codigo: int

-descricao: String

+getCodigo()

+setCodigo()

+getDescricao()

+setDescricao()

+getCliente()

Granularidade Grossa

Granularidade Fina

Workflow de Projeto


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Diagrama de Classes. Construtores:

Cliente

- codigo: int

- nome: String

- tipo: Tipo

dependência<<construtores>>

+Cliente(codigo: int, nome: String)

+Cliente(codigo: int, nome: String, tipo: Tipo)

<<métodos>>

+ getCodigo(): int

+ getNome(): String

+ setCodigo(int codigo)

+ setNome(String nome)

+ getTipo(): Tipo

+ setTipo(tipo Tipo)

+ getCliente(): String

Tipo

-descricao: String

+getDescricao(): String

+setDescricao(d: String)

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 pelo Java. Mas existem casos que se faz necessário a declaração explícita

dos construtores.

Workflow de Projeto


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


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, 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



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Quantos construtores pode ter uma classe ?

Uma classe pode ter vários construtores, entretanto, eles devem seguir a regra de

overloading;

Posso ter construtores com mesmo nome, mas com a lista de argumentos diferente

(quantidade de argumentos, tipos de dados, ordem e etc)

public class Mamifero {

private int idade;

public Mamifero(int idade)

{

this.idade = idade;

}

public Mamifero()

{

}

//Métodos

}

construtores

Workflow de Projeto



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Diagrama de Classes. Propriedades:

Propriedades dos Atributos:Existem três propriedades definidas que poderão ser utilizada como os atributos:

TaxaJuro

- valor: double {frozen}

<<métodos>>

+ getValor(): double

+ setValor(double valor)

- Changeable: 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.

- Frozen: O valor do atributo não pode poderá ser modificado depois que o objeto for

iniciado

Propriedade

Workflow de Projeto


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Propriedades dos Atributos:Existem três propriedades definidas que poderão ser utilizada como os atributos:

TaxaJuro


<<métodos>>



- Changeable: 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.

- Frozen: O valor do atributo não pode poderá ser modificado depois que o objeto for

iniciado

Propriedade

Workflow de Projeto



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Propriedades dos Atributos:Implementando a propriedade Frozen em Java:

TaxaJuro


<<métodos>>



Modificador Final (constantes)

Para declarar uma variável, um ou uma classe como 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 class TaxaJuro {

private final double VALOR;

public TaxaJuro(double valor)

{

VALOR = valor;

}

public static void main(String args[])

{

TaxaJuro taxa = new TaxaJuro(21.30);

System.out.println(taxa.VALOR);

}

}

Workflow de Projeto



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


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


<<métodos>>



Workflow de Projeto



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Definição de Delegação:

A habilidade de um objeto enviar uma mensagem a outro objeto como resposta a uma

mensagem.

Diagrama de Classes. Delegação:

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


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Cliente

codigo

nome

Senha

senhapossui

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.

Workflow de Projeto



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Cliente

codigo

nome

senha

Em segunda sugestão de modelo, como classe Cliente tem como atributo senha, desta

forma a classe Senha não seria necessário.

Quais são as implicações

que o atributo “senha” pode

causar ao modelo ?

Workflow de Projeto



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Ao modelarmos devemos ter os seguintes cuidados:

1 - Identificar todas classes que fazem uso ou que tem um determinado atributo,

neste caso, Cliente e Funcionário tem o atributo “senha”. Isto deve está explícito no

documento “Domínio do Problema”. Veja o exemplo:

Cliente

codigo

nome

senha

Funcionario

codigo-funcional

nome

senha

O mesmo conceito

Conceito diferente

Workflow de Projeto



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Ao modelarmos devemos ter os seguintes cuidados: (continuação)

- Uma sugestão para solução do problema:

Cliente

codigo

nome

Funcionario

codigo-funcional

nome

Senha

senha

possui possuiHistoricoCliente

Pedido

Workflow de Projeto



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Cliente

codigo

nome

senha

qde_dias_expiracao_senha


2 - Uma vez que senha é um atributo de cliente como podemos implementar regras de

negócio a senha, se implementarmos dentro da classe Cliente, teríamos um erro de

conceito (semântica). Veja o exemplo:

Este atributo somente é regra

que se aplica somente a senha e

não a cliente.

Workflow de Projeto



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Cliente

codigo

nome

senha


3 - Reúso:

- O atributo senha poderá ser utilizado por outra aplicação, que nem sempre deverá

ver os outros atributos de cliente.

Workflow de Projeto


Podemos concluir, que no exemplo apresentado duas regras da orientação a

objetos foram violadas:

- Semântica e

- Baixo reúso


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Mitos e Lendas

O que é dito:

- Modelo de entidade e relacionamento (MER), deve ser feito antes do diagrama de

classes.

Entretanto, a realidade é outra...

Quando estamos a metodologia de orientação a objetos os dados são

encapsulados. Assim o “MER” deve ser derivado do modelo de

classes.

Workflow de Projeto


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Arquitetura de Software


É apresentar e discutir Arquitetura de Software, conceitos

modelos e técnicas


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Apresentar e discutir a Arquitetura de Software. Arquitetura é parte do Workflow de Projeto,

nesta fase criamos os componentes, modelos físicos e como serão distribuídos. Os

principais diagramas UML são:

- Diagrama de Deployment e

- Diagrama de Componentes.

Também nesta fase refinamos o Modelo de Arquitetura. Objetivo primário da arquitetura é

atender os requisitos não funcionais. O artefato deste passo é:

- Modelo de Arquitetura.

Objetivo:

Workflow Arquitetura


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Big Picture. Arquitetura

Diagramas


4


exibirCategoria( )

exibirProduto( )

selecionarCategoria


getDescricao( )


Receber Pedido

Preencher Pedido

Receber Pagamento

Enviar Fatura

Entrega durante



Encerrar Pedido

Entrega

Projeto (Visão de Componentes e

Visão de Deployment)



Arquitetura



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Digrama de Componentes


Arquitetura

Analista de Sistema

Projetista de Software


Arquitetura

Arquiteto de Software




ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are



Conceitual Físico

Visão de Projeto

Funcionalidade

Vocabulário


Codificação

Montagem

Visão do Processo

Desempenho

Escalabilidade

Throughput



Distribuição

Instalação




ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are



• A visão de implementação de um sistema abrange os componentes e os arquivos utilizados

para a montagem e fornecimento do sistema físico. Essa visão envolve principalmente o

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.

Visão de Implementação

• A visão de implantação de um sistema abrange os nós que formam a topologia de hardware em

que o sistema é executado. Essa visão direciona principalmente a distribuição, o fornecimento e a

instalação das partes que constituem o sistema físico. Com a UML, os aspectos estáticos dessa

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.

Visão de Implantação



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are



Cada uma dessas visões pode ser considerada isoladamente, permitindo que diferentes

participantes orientem seu foco para os aspectos da arquitetura do sistema que mais lhes

interessem. Essas cincos visões também interagem entre si, por exemplo:

Os nós na visão de implantação contêm componentes da visão de implementação que, por sua vez,

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

visões de projeto e de processo.



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


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”.

Passos:

1 - Selecionar o Modelo de Arquitetura

2 – Refinar o Modelo de Arquitetura Inicial.



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


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 ajuda a definir e a esclarecer as interfaces entre as diferentes partes de

um sistema. 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 também auxiliar 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 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.

Decomposição e Camadas



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


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. Os diagramas de pacote podem

ser usados para fazer decomposição funcional.

A notação usada pela UML para representar pacotes é:

Nome do

Pacote

Nome do Pacote

Nome do

PacoteDependência

(import)

Nome do

Pacote

Workflow de Arquitetura


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Decomposição. “Dividir para conquistar...”

Algumas aplicações podem ser enormes ou ter um grau muito alto de complexidade ou

ambas as coisas. Para facilitar é necessário fazer uma decomposição.

A idéia da decomposição é simples. É fazer uma divisão para simplificar o entendimento, a

modelagem ou processo de desenvolvimento de um software.

Veja o exemplo abaixo:

Nome do Pacote

Dependência

(import)

Contas a

Pagar

Contas a

Receber

Fluxo de

Caixa

Subsistema

UML. Diagrama de Pacotes



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Separação em camadasCamada:

Uma aplicação de grande escala pode ser complexo e difícil de desenvolver e gerenciar.

A camada é um padrão para a decomposição. A decomposição leva uma fragmentação

lógica do sistema em subsistemas e módulos, e as camadas agrupam e separam esses

subsistemas, assim limitando quem pode usar os subsistemas, componentes e módulos.

O Rational Unified Process (RUP) ou simplesmente UP identifica duas abordagens para a

camada:

- Camada baseada em responsabilidade e

- Camada baseada em reúso.

Camada baseada em responsabilidade:

Estas as camadas são bem definidas, significando que cumprem um papel específico no

esquema geral das coisas. Tais camadas também são conhecidas como níveis.

Níveis:

Os níveis podem ser mapeados para as camadas baseada em responsabilidades, neste

caso um nível torna-se sinônimo de cumprir um papel específico no sistema, como a

apresentação, a lógica de negócio, apresentação e etc.

Uma arquitetura baseada em níveis facilitam a manutenção, disponibilidade e separação

de funcionalidades e de papéis de uma aplicação



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Separação em camadas

Níveis:

A forma de se conseguir a distribuição em arquitetura com n níveis é alinhar as camadas

específicas com cada nível, exemplo:

- O nível de cliente, lida com interação com usuário

- O nível de apresentação, lida com apresentação dos dados

- O nível de negócio, contém as regras de negócios e as entidades

- O nível de dados, fornece a interface para armazenamento de dados

<<tier>>

Cliente

<<tier>>

Apresentação

<<tier>>

Negócios

<<tier>>

Dados



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


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, view e controller.

Onde:

Model: Representa o dado ou objeto. Ele é que manipula e objetos, exemplo: JavaBeans

e EJB.

View: É visão de como os dados serão apresentados, exemplo: páginas JSP e ASP

Controller: Recebe as requisições, faz validação e define o model que manipulará os

dados.

Algumas vantagens do MVC:

- Decomposição;

- Reúso;

- Possibilita o desenvolvimento em paralelo;

- Separação de responsabilidades e papéis;

- Isolamento e separação das camadas e

- Baixo acoplamento.

MVC podem ser implementado de duas maneiras o modelo 1 e modelo 2, como

veremos a seguir.

Pattern. Model View Controller



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Model 1: O cliente faz uma requisição para uma página dinâmica (JSP ou ASP) que pode

chamar um model (componente) ou outra página dinâmica que faz algum processamento

e devolve para cliente a resposta

Model View Controller. Model 1

Web Server Model

ViewViewView



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Model 2: O cliente faz uma requisição para a camada controller que redireciona para

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

Model View Controller. Model 2

Web

Server

View View

Controller

Componentes (Model)

View



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Aplicação do MVC em ambiente de três camadas (Web)

Model View Controller

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

diferentes “Look and Feel” (aparências - skins). Diferentes Views podem interagir

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 as

requisições e determinar qual o Model apropriado para atende-la. Ele também poder

tratar a resposta.



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Model View ControllerAplicaçã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+



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Os softwares podem ter arquitetura e ambiente simples, ou seja, “rodar” um único servidor

e em diversas estações clientes em ambiente de rede local.

Atualmente, os softwares podem ter uma arquitetura mais complexa, ou seja, eles podem

ser distribuídos, ou seja, rodar em uma rede distribuída, com diversos servidores, quando

alocamos algum recurso remotamente (componentes, por exemplo), temos que garantir o

funcionamento (desempenho) deste software é missão mais difícil e até critica.

Introdução:

O papel do “Arquiteto de Software” é garantir o funcionamento do software e atendimento

pleno dos Requisitos Não Funcionais (Desempenho, “Escalabilidade”, Confiabilidade,

Segurança e etc) e das Restrições, como uso de determinada tecnologia (protocolos,

linguagens de programação, banco de dados e etc)

As responsabilidades do Arquiteto de Software:

- Selecionar uma tecnologia adequada e projetar um modelo robusto, flexível e eficiente.

- Propor um plano de redução de risco.Um ambiente complexo tem um risco maior, cabe ao

Arquiteto desenvolver um plano para redução de risco.

- O Arquiteto também deve sugerir o uso de Patterns de Arquitetura que são as boas

práticas para a construção do Modelo.

O papel da Arquitetura:



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


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.



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Arquitetura.Road Map

Fazer Diagramas

Modelo de

Especificação

Documentos

de Requisitos

Caso de Uso

Fazer Modelo de Arquitetura

Digrama de

Componentes

Digrama de

Deployment

View Controller Model Resources

JSP/HTML Servlet EJBBanco de

Dados


Modelo de

Arquitetura Inicial


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Fazer Modelo Arquitetura

Fazer Diagrama de

Componentes

Refinar Modelo de

Arquitetura (RNFs)

Refinar o Modelo

de Especificação

Arquitetura. Atividades e Passos:


Digrama de

Componentes

Fazer Diagrama de

Deployment

Selecionar uma

Arquitetura

Digrama de

Deployment


Modelo de

Arquitetura Inicial


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


O que é Diagrama de Deployment?

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 e do 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 do sistema, descrevendo

a estrutura de hardware e software que executam em cada unidade.




ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


processador

Elementos:

Processor (Processador): É qualquer máquina que possua a capacidade de

processamento. Os servidores, estações de trabalho por exemplo.

Dispositivo


Servidor

Device (Dispositivo): É qualquer máquina com finalidade ou finalidade limita. Os

dispositivos são os itens como impressoras, roteadores, raids, storages, scanners,

leitoras de código de barra e etc.

Impressora



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Elementos:

Connection (conexão): A conexão é o vinculo entre processadores e dispositivos.

Geralmente representam as conexões de rede físicas (rede local ou distribuída).


Servidor

Impressora

Cliente <<TCP/IP>>

<<RS 232>>

conexão

Dispositivo

(Nó)

Processador

(Nó)

estereotipo



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Elementos:

Os processadores e os dispositivos podem ser chamados de nó. Um nó é um elemento

físico que existe em tempo de execução e representa um recurso computacional.


Impressora

WebBrowser

<<Cliente>>

<<RS 232>>

Apache

<<WebServer>>

<<HTTP>>

JBoss

<<Application Server>>

Oracle

<<Banco de Dados>>

Cliente

<<Client-Server>>

<<RMI>>

Nós



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


O diagrama de Deployment pode ser substituído por outro diagrama que exibam com

maiores detalhes e/ou com ícones mais apropriados. Apesar de não ser uma boa

recomendação, pois, estaríamos deixando de lado a UML, mas em algumas vezes se

faça necessário.


Oracle

Banco de Dados

Application Server

JBoss

WebServer

Apache



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Adicionando ao Diagrama de Deployment o “Diagrama de Componentes”, podemos ter uma

visão mais “clara” da arquitetura baseada na UML

Diagrama de Deployment & Diagrama de Componentes



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


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

Componente

B

Dependência

Componente

genérico

Nome do

componente



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are



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.

Reserva

Service_

stub

ReservaServiceReservaUI

Component

Dependência

Interface

Room



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


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.

Interfaces:

Uma interface é coleção de operações utilizadas para especificar um serviço de uma classe

ou de um componente. O relacionamento entre componente e interface é muito importe.

As tecnologias mais populares usam interfaces na implementação de componentes, tais

como:

- Enterprise Java Beans;

- Corba (CCM) e

- Microsoft COM+.



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Catalog

Business

Delegate

Catalog

Home

Stub

CatalogHome

Catalog

Remote

Stub

CatalogRemote

Catalog

EJB

Home

Catalog

EJB

Object

Catalog

BeanCatalogRemote

CatalogRemote

CatalogHome

Catalog.jsp

Diagrama de Componentes. Exemplo:



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are



Tipos de Componentes:

Existem três tipos de componentes:

- Componentes de Implantação: São os componentes necessários para montar um

sistema executável, como as DLLs e os arquivos EXEs. A definição da UML para

componentes é abrangente, inclui componentes mais populares (COM+, CCM e EJB),

além de modelos alternativos como páginas web, tabelas de banco de dados e etc...

CheckIT.exe

{versão 1.}

Disk.dll

Video.dll

Floppy.dll



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are



Tipos de Componentes: (continuação)

- Componentes do Produto do Trabalho: Esses componentes são essencialmente o é

parte do processo de desenvolvimento, formados por arquivos de código fontes, arquivos

de dados, ícones. Esses componentes não fazem parte (diretamente) em sistema

executável, mas são os produtos de desenvolvimento, usados para criação do sistema

executável. Cliente.class

Conta.jar

{versão 1}

Historico.class

Conta.class

Conta.java

- Componentes de 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.



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


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.



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are




- 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

Componente

genérico

- Especificação e corpo do subprograma: Estes ícones representam a especificação

visível de um subprograma e o seu corpo de implementação. Um subprograma costuma

ser uma coleção de sub-rotinas. Os subprogramas não contém definições de classe.

NewSubprogSpec NewSubprogBody



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are




- Programa Principal: Este ícone representam o programa principal. Um programa

principal que contém a raiz de um programa. Na linguagem Java seria o programa que

tem o método “main”. MainProgram

Programa princial

(método main)

- Especificação e corpo do pacote: Um pacote é a implementaçã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 Package Body

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

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



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are




- Especificação e corpo da tarefa: Estes ícones representam os pacotes que possuem

linhas independentes de controle. Uma arquivo executável é geralmente representado

como uma especificação de tarefa com uma extensão .exe

NewTaskSpec NewTaskBody

Componente

genérico

Interface

Além de modelar o componente propriamente dito, podemos modelar o relacionamento

entre o componente e sua interface. Veja o exemplo abaixo:



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


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.

Boundary

Services

Entities

Component view

Visão principal do Diagrama de Componentes



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are



Todos os componentes do pacote Entities. Esses são os componentes que conterão as

classes de entidades.

Component view

As classes Entidades

Entities

Cesta

Cesta Item Produto



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are



Todos os componentes do pacote Services. Esses são os componentes que conterão as

classes de serviços ou de controle.

Component view

As classes de Serviços ou Controle

CestaService

ProdutoService

Services



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are



Todos os componentes do pacote Boundaries. Esses são os componentes que conterão

as classes de Boundaries (ou de interface com usuário).

Component view

As classes de Interfaces

CestaInterface

Boundary



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are



Uma visão dos componentes e relacionamentos

CestaInterfaceMainProgram

CestaService

ProdutoService

Cesta

Cesta ItemProduto



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are



Um novo exemplo, o cenário fazer Reserva de apartamento.

ReservaUIMenu Principal

ReservaService

ClienteService

Cliente Reserva Apartamento

ApartamentoService

Model

Controller

View



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Componentes

Componentes:

Componentes são grupos de classes que representam uma funcionalidade

dentro de sistema.

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 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.

Diagrama de Componentes. Identificação de Componentes:

Como faço

o diagrama de

componentes ?



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Conceitos: Acoplamento e Coesão

Independência

Funcional:

•Coesão e

•Acoplamento

Independência Funcional

Conceito que está diretamente relacionado a modularidade,

abstração e 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.



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Independência

Funcional:

•Coesão e

•Acoplamento

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 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 (ou mais

especificamente, coesão funcional) é uma medida de quão

fortemente relacionadas e focalizadas são as responsabilidades

de uma classe.

Uma classe com responsabilidade altamente relacionadas e que

não executa um formidável volume de trabalho tem coesão alta.




ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Independência

Funcional:

•Coesão e

•Acoplamento

Coesão: (continuação)

Uma classe com coesão baixa faz muitas coisas não-relacionadas, ou

executa demasiado trabalho. Tais classes são indesejáveis, elas sofrem

dos seguintes problemas:

- São difíceis de compreender;

- São difíceis de reusar;

- São difíceis de manter;

- São muito sensíveis a mudança;

Classes de coesão baixa representam, geralmente, uma abstração de

“grande granularidade” ou atribuíram responsabilidades que deveriam ter

sido delgadas a outras classes ou objetos




ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Independência

Funcional:

•Coesão e

•Acoplamento


Exemplo:

Neste exemplo é

demonstrado a baixa

coesão, uma vez que a

classe Nota Fiscal

assume a

responsabilidade de

fazer o cálculo dos

imposto

NotaFiscal

- número

- data emissão

- tipo

+calcularImposto()

+getNumero

+setNumero

....

NotaFiscalItem

- item[ ]

- quantidade

+getQuantidade()

+setQuantidade()

...

Produto

- codigo

- descrição

+setCodigo()

+getCodigo()

Cliente

- codigo

- nome

+getCodigo()

+setCodigo()

+getNome()


Tributo

- codigo

- nome



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Independência

Funcional:

•Coesão e

•Acoplamento


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.

NotaFiscal

- número

- data emissão

- tipo

+getNumero

+setNumero

....

NotaFiscalItem

- quantidade

+getQuantidade()

+setQuantidade()

...

Produto

- codigo

- descrição

+setCodigo()

+getCodigo()

+gerProduto

Cliente

- codigo

- nome

+getCodigo()

+setCodigo()

+getNome()

+get/cliente()

CalculoImposto

+calcularImposto()

Conceitos: Acoplamento e CoesãoTributo

- codigo

- nome



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Independência

Funcional:

•Coesão e

•Acoplamento


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 em umas poucas

áreas diferentes que estão logicamente relacionadas ao conceito da classe,

mas não entre si.




ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Independência

Funcional:

•Coesão e

•Acoplamento


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..




ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Independência

Funcional:

•Coesão e

•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: Atribuir uma responsabilidade 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.




ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Independência

Funcional:

•Coesão e

•Acoplamento

Acoplamento (continuação)

Uma classe com acoplamento alto (forte) depende de muitas outras

classes. Tais classes são 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.

Benefícios:

• Não afeta por mudanças em outros componentes

• simples de entender

• conveniente para o reúso.




ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Independência

Funcional:

•Coesão e

•Acoplamento

Acoplamento. Tipos:


Abaixo os possíveis tipos de acoplamento:

Cliente Service{abstract}

Service Service

Acoplamento Abstrata:

Cliente<<Interface>>

Service

Service Service

Cliente

Sem acoplamento

Service

Cliente Service

Com acoplamento

Cliente Service

Forte acoplamento

tight



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Independência

Funcional:

•Coesão e

•Acoplamento

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:

Moeda

- valor

+getValor

+setValor

MaskMoeda

+maskFormat()

dependência

Este modelo tem alguns problemas:

1 - Herança. Todos que herdarem a classe Moeda são obrigados

a herdar também a classe MaskMoeda e as vezes somente

precisamos da classe Moeda.

Workflow de Projeto, Arquitetura


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Independência

Funcional:

•Coesão e

•Acoplamento

Acoplamento

Princípio da Dependência Inversa (continuação):


Moeda

- valor

+getValor

+setValor

MaskMoeda

+maskMoeda()

dependência

2 - O relacionamento de dependência inibe a extensibilidade da

classe Moeda.

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).



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Independência

Funcional:

•Coesão e

•Acoplamento

Acoplamento

Princípio da Dependência Inversa (continuação):


Aplicando a DIP, podemos resolver a situação, veja os modelos

abaixo:

Cliente Service{abstract}

Service Service

DIP com Classe Abstrata:

Cliente<<Interface>>

Service

Service Service

DIP com Interface:

Moeda MoedaMask{abstract}

Real Dolar

Solução para a classe Moeda:



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Independência

Funcional:

•Coesão e

•Acoplamento

Acoplamento


<<interface>>

iPessoa

Cliente

Realização

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.



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Independência

Funcional:

•Coesão e

•Acoplamento

Acoplamento


<<interface>>

iPessoa

Cliente

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

PessoaAdapter

Relacionamento de Realização



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Exemplo:

Acoplamento

Coesão

e Componentes

Exemplo:

A partir do diagrama de classe, tentamos agrupar classes usando

técnicas de coesão e acoplamento.




ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Exemplo:

Acoplamento

Coesão

e Componentes

Exemplo:

Temos o seguinte resultado:




ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Exemplo 2:

Diagrama de Classes:




ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


331

Exemplo 2:

A partir do diagrama de classe,

agrupar classes usando os

conceitos de coesão

e acoplamento.

UML. Diagrama de Componentes

Pedido

Cesta de Compra

Produto

FormaPagto



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Exemplo 2:



Cesta

Pedido

Produto

FormaPagto

Pedido

Cesta de Compra

Produto

FormaPagto

Workflow de Projeto, Arquitetura


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Projetando um Modelo de Arquitetura:

Oracle

Servidor de

Banco de Dados

Servidor de Aplicação

JBoss

HTML

Windows

Cliente

HTTP

Linux Suse Linux Suse

TCP/IP

Sugestão para modelo de Arquitetura para aplicações Web de três camadas:



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Cliente Servidor. Fazendo acesso utilizando o RMI (Remoto Method Invocation)

Projetando um Modelo de Arquitetura para Camada Cliente:

DeskTop Servidor de Aplicação

Funcionário

<<JRMP>>

ReservaUI

<< Stub>>

Reserva

<<Skeleton>>

RMI



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Web


WebServer

Cliente

<< Reserva>>

Browser

FormConsulta

HTTP

JavaBeans

ServletsController

Banco de

Dados<< ConnDB>>

HotelSchema

Tabelas de Reserva

JSP

Servlet



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Web


Cliente

<< Reserva>>Browser

FormConsultaHTTP

Cliente

ServletsController

Banco de

Dados<< ConnDB>>

Servlet/JSP JavaBeansHTML

Apresentação Negócio Integração

JDBC 2.0

Recursos

SQL



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Considerando o cenário de Loja Virtual, numa transação de pagamento.

Implementando os Requisitos Não Funcionais:

ClienteFazer Pedido

Fechar Pedido

<<include>>

Fazer Pagamento

CartaoCredito

<<include>>

Requisito Não Funcional:

Segurança: Todas as transações de pagamento deve ser realizado em ambiente seguro

Cliente

WebServer

Pagamento

Browser

FormPagamento

HTTPs (HTTP + SSL)

ServletsController


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.


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


338

Quer Mais

http://etecnologia.ning.com/

Gostou quer mais, gostaria de receber outros materiais sobre o mesmo tema e novas versões deste material...

Envie um e-mail para com subject: “Quero entrar na comunidade” para [email protected] que te

enviaremos um convite para participar da nossa comunidade


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Sobre o autor: Rildo F. Santos Coach e Consultor de Gestão de Negócios, Inovação e Tecnologia para a Gestão 2.0, a Gestão Ágil.

A Gestão Ágil ajuda as empresas a responder mais rápido as demandas de negócio e mudanças. A Gestão 2.0, abrange Planejamento

Estratégico, Gestão por Processos Ágeis, Gestão de Projetos Ágeis, Tecnologia da Informação (Métodos Ágeis), Inovação e Liderança.

Minha Experiência:

Tenho mais de 10.000 horas de experiência em Gestão de Negócios, Gestão de Inovação, Governança e Engenharia de Software. Formado

em Administração de Empresas, Pós-Graduado em Didática do Ensino Superior e Mestre em Engenharia de Software pela Universidade

Mackenzie.

Fui instrutor de Tecnologia de Orientação a Objetos, UML e Linguagem Java na Sun Microsystems e na IBM.

Conheço Métodos Ágeis (SCRUM, Lead, FDD e XP), Arquitetura de Software, SOA (Arquitetura Orientado a Serviço), RUP/UP -

Processo Unificado, Business Intelligence, Gestão de Risco de TI entre outras tecnologias.

Sou professor de curso de MBA da Fiap e fui professor de pós-graduação da Fasp e IBTA.

Possuo fortes conhecimentos de Gestão de Negócio (Inteligência de Negócio, Gestão por Processo, Inovação, Gestão de Projetos e GRC -

Governance, Risk and Compliance), SOX, Basel II e PCI;

E experiência na implementação de Governança de TI e Gerenciamento de Serviços de TI. Conhecimento dos principais frameworks e

padrões: ITIL, Cobit, ISO 27001 e ISO 15999;

Desempenhei diversos papéis como: Estrategista de Negócio, Gerente de Negócio, Gerente de Projeto, Arquiteto de Software, Projetista de

Software e Analista de Sistema em diversos segmentos: Financeiro, Telecomunicações, Seguro, Saúde, Comunicação, Segurança Pública,

Fazenda, Tecnologia, Varejo, Distribuição, Energia e Petróleo e Gás.

Possuo as certificações: CSM - Certified SCRUM Master, CSPO - Certified SCRUM Product Owner , SUN Java Certified Instrutor, ITIL

Foundation e sou Instrutor Oficial de Cobit Foundation e Cobit Games;

Sou membro do IIBA-International Institute of Business Analysis (Canada)

Onde estou:

Twitter: http://twitter.com/rildosan



ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Marcas Registradas:

Todos os termos mencionados e reconhecidos como Marca Registrada e/ou comercial são de responsabilidade de

seus proprietários. O autor informa não estar associada a nenhum produto e/ou fornecedor apresentado neste

material. No decorrer deste, imagens, nomes de produtos e fabricantes podem ter sido utilizados, e desde já o

autor informa que o uso é apenas ilustrativo e/ou educativo, não visando ao lucro, favorecimento ou

desmerecimento do produto/fabricante.

Melhoria e Revisão:

Este material esta em processo constante de revisão e melhoria, se você encontrou algum problema ou erro envie

um e-mail nós.

Criticas e Sugestões:

Nós estamos abertos para receber criticas e sugestões que possam melhorar o material, por favor envie um e-

mail para nós.

Rildo F dos Santos ([email protected])

Imagens:

Google, Flickr e Banco de Imagem.


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


Licença:


ap

ac

ita

çã

o E

ng

en

ha

ria

de

So

ftw

are


An

áli

se e

Des

enh

o

Ori

enta

do

a O

bje

tos

com

UM

L

Versão 27 |

Rildo F [email protected]

[email protected]

Twitter: @rildosan


analise e desenho orientado a objetos com uml

Documents